3 ms·

Google shouldn’t be trusted as a key steering voice for web standards. However given their browser share and that these issues have visibility mostly in tech co

Google shouldn’t be trusted as a key steering voice for web standards. However given their browser share and that these issues have visibility mostly in tech communities, I’m not sure if they will get the political attention they deserve. Or perhaps that is only true in the US and someone like the EU will use all these controversies as motivation to clamp down on big US tech companies and encourage local competitors.

skohan 5y ago
It would have to be the EU. Unfortunately anti-trust has been completely eroded in the US over the past decades.
- Y_Y 5y ago
  Impressive to be able to erode anti-trust and trust simultaneously.
  - esarbe 5y ago
    I see what you did there.
KennyBlanken 5y ago
Google's fingers are going deeper than just "web standards." Filippo Valsorda, the Go lead for security, was one of the authors of TLS 1.3. He has refused to allow for configuration of TLS 1.3 ciphers in Go: https://github.com/golang/go/issues/29349 https://github.com/golang/go/issues/29349 Thanks to this decision: if a particular cipher is found to be weak or vulnerable, people using Go won't be able to immediately disable it. Instead, they'll be forced to wait for a release or patch, and possibly have to backport it to the version they're running in production. Another scenario, as pointed out in that ticket: sometimes other vendors don't properly implement ciphers on their end, and there's an incompatibility. Prior to TLS 1.3, one could just disable that particular cipher, perhaps even just for a particular connecting client. His response was, paraphrasing: "TLS 1.3 is amazing and awesome and will not have the same problems prior TLS versions had. It needs to Just Work, if there's a security issue we'll issue a patch, and if you can't apply it in a timely fashion you're incompetent." He seems unaware that not everyone uses Google's "just roll it out to a few hundred nodes and keep an eye on them" approach to SRE, or that major organizations don't have time to wait for a patch - they need a quick switch flip until the patch is out and can pass their normal validation before moving to production.
- bawolff 5y ago
  Wait, the security lead of the language designed by google is associated with google! What a conspiracy! I know we're on a google is evil thread, but not literally everything they're involved with is a conspiracy.
  - rapind 5y ago
    > I know we're on a google is evil thread, but not literally everything they're involved with is a conspiracy. 100% agree, and yet one of the downsides of their recently exposed behaviour is an erosion of trust in everything they touch. For good or bad. Especially big important security considerations. The more crap like this I hear about, the less I’m willing to trust their products. For example, I almost chose GCP for a project but decided against it because I just don’t trust them not to hose me due to something completely out of my control. These things pile up and tarnish their brand and anyone closely associated with their brand.
  - theduder99 5y ago
    what do you think about that guy's opinion about how ciphers should be handled?
    - bawolff 5y ago
      There's pros and cons. There's lots of evidence that people make bad choices when allowed to configure crypto, and there has generally been a movement towards having more opaque interfaces where users have less rope to hang themselves. People who don't have the ability to deploy updates will also be screwed when normal security issues happen, so i dont find that super compelling. Additionally there are some privacy implications about letting users configure. Otoh, personally i like the ability to config things if i really have to, and such a policy might lead to people running custom forks which is bad.
  - passivate 5y ago
    That is true, but this is a normal thing that happens when there is a trust deficit.

skohan 5y ago

It would have to be the EU. Unfortunately anti-trust has been completely eroded in the US over the past decades.

Y_Y 5y ago
Impressive to be able to erode anti-trust and trust simultaneously.
- esarbe 5y ago
  I see what you did there.

KennyBlanken 5y ago

Google's fingers are going deeper than just "web standards." Filippo Valsorda, the Go lead for security, was one of the authors of TLS 1.3. He has refused to allow for configuration of TLS 1.3 ciphers in Go: https://github.com/golang/go/issues/29349 https://github.com/golang/go/issues/29349 Thanks to this decision: if a particular cipher is found to be weak or vulnerable, people using Go won't be able to immediately disable it. Instead, they'll be forced to wait for a release or patch, and possibly have to backport it to the version they're running in production. Another scenario, as pointed out in that ticket: sometimes other vendors don't properly implement ciphers on their end, and there's an incompatibility. Prior to TLS 1.3, one could just disable that particular cipher, perhaps even just for a particular connecting client. His response was, paraphrasing: "TLS 1.3 is amazing and awesome and will not have the same problems prior TLS versions had. It needs to Just Work, if there's a security issue we'll issue a patch, and if you can't apply it in a timely fashion you're incompetent." He seems unaware that not everyone uses Google's "just roll it out to a few hundred nodes and keep an eye on them" approach to SRE, or that major organizations don't have time to wait for a patch - they need a quick switch flip until the patch is out and can pass their normal validation before moving to production.

bawolff 5y ago
Wait, the security lead of the language designed by google is associated with google! What a conspiracy! I know we're on a google is evil thread, but not literally everything they're involved with is a conspiracy.
- rapind 5y ago
  > I know we're on a google is evil thread, but not literally everything they're involved with is a conspiracy. 100% agree, and yet one of the downsides of their recently exposed behaviour is an erosion of trust in everything they touch. For good or bad. Especially big important security considerations. The more crap like this I hear about, the less I’m willing to trust their products. For example, I almost chose GCP for a project but decided against it because I just don’t trust them not to hose me due to something completely out of my control. These things pile up and tarnish their brand and anyone closely associated with their brand.
- theduder99 5y ago
  what do you think about that guy's opinion about how ciphers should be handled?
  - bawolff 5y ago
    There's pros and cons. There's lots of evidence that people make bad choices when allowed to configure crypto, and there has generally been a movement towards having more opaque interfaces where users have less rope to hang themselves. People who don't have the ability to deploy updates will also be screwed when normal security issues happen, so i dont find that super compelling. Additionally there are some privacy implications about letting users configure. Otoh, personally i like the ability to config things if i really have to, and such a policy might lead to people running custom forks which is bad.
- passivate 5y ago
  That is true, but this is a normal thing that happens when there is a trust deficit.