Recent searches
Search options
Administered by:
Some people are like "don't use browser forks, they will get you pwned" and while I haven't look into that, from a distance this looks like "Don't roll your own crypto".
And similar to how we don't want to discourage people from learning how to implement cryptographt, so it's more of a "Don't (let people) rely on your own crypto"
we also shouldn't discourage people from learning to work on these inscrutable behemoths that we call browser engines, so we advise people to just not rely on them
1/
But it seems to me that the browaer engine ecosystem isn't as healthy as cryptography implementation ecosystem these days.
It seems more like pre-PGP times (which I don't remember because I wasn't alive back then, so correct me if I'm wrong):
The only widely established implementations are opaque and developed by insular groups with questionable agendas.
IOW, unlike with libssl or libsodium, we desoerately need forks of browser engines.
2/
But let's take a step back: why are browser engines, which are one of the most comolex pieces of software in the world, so security critical?
Is it a skill issue that forks fail to keep the same security level as Chromium and Gecko?
Or are these two projects trying to achieve something that shouldn't be done, and they're lucky to have any resemblence of security?
Maybe Stallman was right to only open a few trusted websited in his browser, and read every other site through a sandboxed wget...
Maybe the browser we use to log in to our bank account or domain registrar should not run with the same OS privileges as the browser we use to explore random websites or watch videos
Or looked at the code of popular cryptographic libraries? Because a lot of them are downright scary and wouldn't pass an audit (remember OpenBSD reaction to OpenSSL?).
Hence why I've only ever seen serious usage of "Don't roll your own crypto" to mean "Don't make your own algorithms".
As for browsers and the like, usages should be separated *but* it should be comfortable. Because attackers will exploit your stress (check articles from people who got phished), which is where you'll choose the easiest and most immediate path, which should still be secure.
(That sadly means getting proper security on smartphones for most people)
@lanodan I've seen "don't implement crypto algorithms yourself because you'll make a timing sidechannel, a padding oracle, or just, you know, accidentally override the key with all zeros"
I've also seen
"Don't build your own protocols on top of AES and SHA-256 because cryptogrqphic primitives are not lego bricks"
Like what's the difference between TLS (specially ClientHello+ServerHello) and the various kinds of Diffie-Hellman in terms of security?
But if someone implements TLS and makes sure that their implementations passes the tests… Short of doing an actual audit (which seems to be barely ever done, almost nobody reads code), it's probably as good at any other TLS implementation.
@lanodan can't say that about browsers, can we?
It makes sense to just reuse existing code for this because it's huge.
But there's sustainability to take into question. If ffmpeg didn't exists (or wasn't as good) and you'd have to fork a full blown video player, then it would be an horrible task.
And this is why to me Mozilla throwing reusability of Firefox's engine is so disgusting. (And to me Chromium forks by small teams is just a way to burn developers)
@lanodan I like how you assumed using gstreamer is worse than forking a video player
No, re-read.
Opposite of that, forking a video player which it's own codec support is an horrible idea.
Same shit as forking a browser with it's own html/css/… support.
@lanodan no no
You said if ffmpeg didn't exist, you'd have to fork an existing video player, which is horrible.
This implies by omission that gstreamer is not your 2nd choice after ffmpeg :P
@lanodan which brings me to my next point:
It's not enough to have reusabke components. GNOME has reusable components (eg. gtk) but a lot of them have GNOME policy embedded in them - they will only do what GNOME needs them to do, and of you want to do things differently, tough luck, go write your own GUI toolkit.
We need unopinionated reusable components.
And even if say, we actually have an unopinionated implementation, being maintained forever isn't a thing.
Which is why I think it's a lot better to have a diversity of implementations than a monopoly or duopoly.
And reusability helps a lot there, specially because it often then allows to swap components either ship-of-thesus style (see Unix-like systems), or with switching to another dependency+API.
Like you can move from GTK to Qt, and probably will be able to move from WebKit to Servo. But move from being a Firefox fork to being a Chromium fork? Probably not.
@lanodan
(meant to reply earlier but forgot)
Maybe the software, as in a snapshot of source code, can't be absolutely unopinionated. But it's a spectrum.
And you can look at the process of developing that software and see in which direction decisions are made.
1/
@lanodan
For example: if I make a pull request that says "hey, this library does $X which makes sense in your project but doesn't make sense in mine, so I let's make this behaviour configurable like this"
Do the maintainers approach it constructively, and work with you to find a solution that works for both/all projects using that library?
Or do they just reject the PR because "this is incompatible with $project's human interface guidelines" ?
But problem with unopinionated is you'd effectively have to support everything and every use case, or actually have to state that no "unopinionated" isn't part of the project.
I see it quite frequently with Gentoo when people try to push what they want through "Gentoo is about choice" when it's more like maintainers allowing some choices that they can (or need to) maintain.
There's lines that need to be drawn, and there's things where it's going to be fairly unopinionated (Qt about theming for example), and ones where it's going to be opinionated (typical ones being: which platforms are supported, positions around proprietary software, APIs deprecation, …).
@lanodan
re support - that's why it's ideal when all projects using the reusable component co-maintain it
WebKit comes to mind (see https://webkit.org/team/ ), but not everyone is included in there (like Haiku maintains a port of WebKit, and they're not in there, which seems okay).
@lanodan
wayland-protocols is a good example, although not exactly a reusable component...
Also, kubernetes and a lot of the CNCF stuff comes to my mind
And I wouldn't see it as a good example, it has so much bikeshedding because it's a bit too much like if say POSIX would be involved for all base system APIs of all Unix-likes rather than just a specific common subset of them.
@lanodan idk, I think wayland-protocols is better than the alternative of gtk only working on GNOME and Qt only working on KDE.
@lanodan I mean it'd still work on the other DEs but only with the most basic features
Like it makes sense for it to take time reaching consensus (after all consensus has "consent" in it), but I think it's too much.