3 ms·

I agree. This isn't as scary as people say. The threat is that Google does something evil and the web needs to adopt it. Thing is, Chromium is open source. Micr

I agree. This isn't as scary as people say. The threat is that Google does something evil and the web needs to adopt it. Thing is, Chromium is open source. Microsoft or anyone else can immediately fork it. Crisis averted.

WorldMaker 4y ago
The threat isn't just that Google does something intentionally evil. Imagine if there's a WebKit 0-Day that Blink inherited discovered tomorrow that breaks ~96% of today's browsers as soon as that bad actor discoverer weaponizes it. (Or worse uses it to send malware or as an RCE vector.) That's not something Google did intentionally. That's not something that forks can "immediately" fix. That's something that possibly forks make worse because everyone is going to be auditing different but similar codebases for the same bug and there may be some political infighting and finger pointing and accusations in a mexican standoff between the forks all accusing each other. Most importantly, that is a lot of potential devices at major security risk to a single ecology "family of forks" of a code base. What other piece of software does something like 96% of internet connected devices possibly have in common? We've got a variety of operating systems (Windows, Linux, macOS, iOS, Android, etc). We've got a variety of hardware stacks. We've got a variety almost everywhere but this one massive bottleneck growing worse. There's still some hope in the case of the hypothetical WebKit 0-Day that that diversity alone is enough to keep things from getting truly bad, but if you believe in software security you've probably had "defense in depth" drilled into your head and does "everyone uses the same browser codebase" sound like defense in depth? That's the biggest nightmare scenario. There's lots of little iterations of that, including all the various little ways that standards might slowly get ignored or broken until some day the future web is wondering where the standards specs even are and can't find its way out of the box it was trapped in. If it happens little-by-little enough ("boiling the frog" as the aphorism goes) no one sees it as a clear threat at the time and no one thinks to "immediately fork it" until it is already far too late. To repeat something that needs repeating a lot in these conversations: the problem with IE6 wasn't that it was terrible and "behind", the problem with IE6 was that it was amazing and forward thinking and had boiled some frogs building specifications too quickly ahead of the standards bodies. People didn't notice the problems they had from that until after they'd built websites and apps with IE6 in mind because it was great at the time. People didn't notice the problems until after Microsoft felt they had done enough and took their ball and stopped playing because they had "innovated enough". People mostly didn't notice the problems until it was too late to get out of the box they'd been trapped in without realizing it. IE6 today has a reputation as a terrible browser that was stuck "behind" standards, but that's not where it did the most damage. It did the most damage when it was "the best browser to use", "the most innovative and powerful browser" and "everyone uses IE6 and is happy with it".
- gerash 4y ago
  With that reasoning, do you also go and reimplement standard libraries just to create enough variance so that if one of them has a security flaw then your code might not inherit it? IMHO, some software (eg. OpenSSL, rendering engines, etc.) need to be heavily scrutinized and trying to keep multiple implementation around for the sake of diversity makes no sense to me. Of course if a new implementation of say a rendering engine with a radically different approach emerges I'm all for it taking over.
  - WorldMaker 4y ago
    OpenSSL is, I think, another "case in point" example: Heartbleed was an amazingly awful 0-Day that afflicted OpenSSL and I can only imagine how much worse things might have been if Windows didn't use SChannel and FreeBSD (and thus iOS/macOS) didn't use LibreSSL (and if LibreSSL's fork auditing hadn't made a difference in that situation). Even (especially?) highly scrutinized libraries seem to need diversity in implementation to avoid single point of failure problems.

WorldMaker 4y ago

The threat isn't just that Google does something intentionally evil. Imagine if there's a WebKit 0-Day that Blink inherited discovered tomorrow that breaks ~96% of today's browsers as soon as that bad actor discoverer weaponizes it. (Or worse uses it to send malware or as an RCE vector.) That's not something Google did intentionally. That's not something that forks can "immediately" fix. That's something that possibly forks make worse because everyone is going to be auditing different but similar codebases for the same bug and there may be some political infighting and finger pointing and accusations in a mexican standoff between the forks all accusing each other. Most importantly, that is a lot of potential devices at major security risk to a single ecology "family of forks" of a code base. What other piece of software does something like 96% of internet connected devices possibly have in common? We've got a variety of operating systems (Windows, Linux, macOS, iOS, Android, etc). We've got a variety of hardware stacks. We've got a variety almost everywhere but this one massive bottleneck growing worse. There's still some hope in the case of the hypothetical WebKit 0-Day that that diversity alone is enough to keep things from getting truly bad, but if you believe in software security you've probably had "defense in depth" drilled into your head and does "everyone uses the same browser codebase" sound like defense in depth? That's the biggest nightmare scenario. There's lots of little iterations of that, including all the various little ways that standards might slowly get ignored or broken until some day the future web is wondering where the standards specs even are and can't find its way out of the box it was trapped in. If it happens little-by-little enough ("boiling the frog" as the aphorism goes) no one sees it as a clear threat at the time and no one thinks to "immediately fork it" until it is already far too late. To repeat something that needs repeating a lot in these conversations: the problem with IE6 wasn't that it was terrible and "behind", the problem with IE6 was that it was amazing and forward thinking and had boiled some frogs building specifications too quickly ahead of the standards bodies. People didn't notice the problems they had from that until after they'd built websites and apps with IE6 in mind because it was great at the time. People didn't notice the problems until after Microsoft felt they had done enough and took their ball and stopped playing because they had "innovated enough". People mostly didn't notice the problems until it was too late to get out of the box they'd been trapped in without realizing it. IE6 today has a reputation as a terrible browser that was stuck "behind" standards, but that's not where it did the most damage. It did the most damage when it was "the best browser to use", "the most innovative and powerful browser" and "everyone uses IE6 and is happy with it".

gerash 4y ago
With that reasoning, do you also go and reimplement standard libraries just to create enough variance so that if one of them has a security flaw then your code might not inherit it? IMHO, some software (eg. OpenSSL, rendering engines, etc.) need to be heavily scrutinized and trying to keep multiple implementation around for the sake of diversity makes no sense to me. Of course if a new implementation of say a rendering engine with a radically different approach emerges I'm all for it taking over.
- WorldMaker 4y ago
  OpenSSL is, I think, another "case in point" example: Heartbleed was an amazingly awful 0-Day that afflicted OpenSSL and I can only imagine how much worse things might have been if Windows didn't use SChannel and FreeBSD (and thus iOS/macOS) didn't use LibreSSL (and if LibreSSL's fork auditing hadn't made a difference in that situation). Even (especially?) highly scrutinized libraries seem to need diversity in implementation to avoid single point of failure problems.