4 ms·

Google acting like this is a programming error. Any programmer would know this would have to be an edge case, perfect-storm type of bug for it to just magically

by junon 6y ago

Google acting like this is a programming error. Any programmer would know this would have to be an edge case, perfect-storm type of bug for it to just magically decide google.com and youtube.com are not included in the wipe. I call bullshit. Google is an evil company, this is nothing new.

ashtonkem 6y ago
Honestly, it’s an insultingly bad lie on Google’s part.
- burnerfi5724 6y ago
  As someone who works on Chrome at google and know people working on fixing it.... it really is kinda a perfect storm bug but you obviously don't have to believe me.
  - junon 6y ago
    Feel free to explain. We'd love to know.
    - burnerfi5724 6y ago
      https://chromium.googlesource.com/chromium/src.git/+/f800edbd1b50ecc13a0d3391f5f45ba9c84625be https://chromium.googlesource.com/chromium/src.git/+/f800edb... Best context I can give is the actual CL for the fix.
      - dingaling 6y ago
        That doesn't explain how the original change made it through testing without the bug being flagged. Test clearing all private data -> not all private data cleared.
  - ashtonkem 6y ago
    I could be convinced, but given Google's behavior they've lost the presumption of good faith, and the bar of evidence required to convince me that this is an accident is much higher than it would be normally.
dlgeek 6y ago
Well...they already treat Google and Youtube as special, because logging into them also logs you into the browser as well. It wouldn't surprise me if that special-ness had unintended consequences and that's the bug. It /also/ wouldn't surprise me if it's exactly the way you describe.
- junon 6y ago
  Circumventing otherwise strict security rules for their own domains is shady in its own right. In either scenario, it's equally bad.
  - shadowgovt 6y ago
    > Circumventing otherwise strict security rules for their own domains is shady in its own right. In most fights between adding a user feature and protecting user privacy, if the feature cannot be added otherwise, feature wins. It's only "shady" if you're already assuming the feature vendor is a hostile actor. The consistent Chrome experience enabled by logging the browser in is hells useful (especially in this era of mobile device + desktop device; no more having to remember if I bookmarked that article on my phone or my desktop or my work PC, etc.).
    - junon 6y ago
      > In most fights between adding a user feature and protecting user privacy, if the feature cannot be added otherwise, feature wins. /Not/ protecting user privacy is always shady, regardless of who the actor is. When done knowingly, it's almost always hostile.
      - shadowgovt 6y ago
        The easiest way to protect user privacy is to never implement any features. Can't hack what isn't there. Once we assume that's not the decision that'll be made (because obviously), the question becomes whether the feature can be implemented at all while respecting user privacy. And if the answer is yes, we can expect it to happen.
AdmiralAsshat 6y ago
Does this "bug" exist in the open-source Chromium as well? Wouldn't we be able to tell when they push the fix?
- deleted 6y ago
  [deleted]
furyofantares 6y ago
> Any programmer would know On the other hand, a very large majority of the time that a programmer speculates on the internet about something that's obviously true about code I've written or am otherwise privy to, they're wrong
- junon 6y ago
  > a very large majority of the time On the other other hand, most vague and fabricated statistics about anecdotal, speculative or subjective topics tend to have very little weight when making a point...
  - furyofantares 6y ago
    Too true. I guess my point is that complex products tend to have complex interdependencies that one isn't likely to guess exist from the outside. Things that look clearly intended can easily be programming errors, things that seem like they should be easy can be hard. I think the reverse can be true too but not as often. So I don't think the thought that any programmer would know this is a ridiculous edge case is one that holds any real weight here.
londons_explore 6y ago
The commit that did this ~4 years ago was very much in the open, and had rationale in the commit message. I think it's pretty sad that nobody here has linked to it... It's as if the people who care about this stuff aren't the same ones who write and review code for a living...
- junon 6y ago
  You could have linked it yourself to refute what I said, then. But you didn't. You didn't waste any time insulting someone, though.
- _qulr 6y ago
  Incorrect. The commit was 5 months ago, and it's linked here: https://news.ycombinator.com/item?id=24841118 https://news.ycombinator.com/item?id=24841118
shadowgovt 6y ago
Having seen the source code for web browsers, I'm 100% willing to believe it's a programming error. The likeliest point of introduction is where Google added account login to the browser itself. At that point, either ambiguity of specification or failure to test as though the user thinks Google is a privacy-hostile agency (while using a browser that allows them to login to Google) could have resulted in someone adding a special case to refrain from throwing the credentials away that keep the browser logged in that inadvertantly failed to throw the credentials away that keep a session logged in.
- junon 6y ago
  Why is something like browser identity (which is NOT a w3 standardization) at all linked with session identity?
  - shadowgovt 6y ago
    Because code reuse is a virtue... Until it introduces an unexpected bug.

by junon 6y ago

ashtonkem 6y ago

Honestly, it’s an insultingly bad lie on Google’s part.

burnerfi5724 6y ago
As someone who works on Chrome at google and know people working on fixing it.... it really is kinda a perfect storm bug but you obviously don't have to believe me.
- junon 6y ago
  Feel free to explain. We'd love to know.
  - burnerfi5724 6y ago
    https://chromium.googlesource.com/chromium/src.git/+/f800edbd1b50ecc13a0d3391f5f45ba9c84625be https://chromium.googlesource.com/chromium/src.git/+/f800edb... Best context I can give is the actual CL for the fix.
    - dingaling 6y ago
      That doesn't explain how the original change made it through testing without the bug being flagged. Test clearing all private data -> not all private data cleared.
- ashtonkem 6y ago
  I could be convinced, but given Google's behavior they've lost the presumption of good faith, and the bar of evidence required to convince me that this is an accident is much higher than it would be normally.

dlgeek 6y ago

Well...they already treat Google and Youtube as special, because logging into them also logs you into the browser as well. It wouldn't surprise me if that special-ness had unintended consequences and that's the bug. It /also/ wouldn't surprise me if it's exactly the way you describe.

junon 6y ago
Circumventing otherwise strict security rules for their own domains is shady in its own right. In either scenario, it's equally bad.
- shadowgovt 6y ago
  > Circumventing otherwise strict security rules for their own domains is shady in its own right. In most fights between adding a user feature and protecting user privacy, if the feature cannot be added otherwise, feature wins. It's only "shady" if you're already assuming the feature vendor is a hostile actor. The consistent Chrome experience enabled by logging the browser in is hells useful (especially in this era of mobile device + desktop device; no more having to remember if I bookmarked that article on my phone or my desktop or my work PC, etc.).
  - junon 6y ago
    > In most fights between adding a user feature and protecting user privacy, if the feature cannot be added otherwise, feature wins. /Not/ protecting user privacy is always shady, regardless of who the actor is. When done knowingly, it's almost always hostile.
    - shadowgovt 6y ago
      The easiest way to protect user privacy is to never implement any features. Can't hack what isn't there. Once we assume that's not the decision that'll be made (because obviously), the question becomes whether the feature can be implemented at all while respecting user privacy. And if the answer is yes, we can expect it to happen.

AdmiralAsshat 6y ago

Does this "bug" exist in the open-source Chromium as well? Wouldn't we be able to tell when they push the fix?

deleted 6y ago
[deleted]

furyofantares 6y ago

> Any programmer would know On the other hand, a very large majority of the time that a programmer speculates on the internet about something that's obviously true about code I've written or am otherwise privy to, they're wrong

junon 6y ago
> a very large majority of the time On the other other hand, most vague and fabricated statistics about anecdotal, speculative or subjective topics tend to have very little weight when making a point...
- furyofantares 6y ago
  Too true. I guess my point is that complex products tend to have complex interdependencies that one isn't likely to guess exist from the outside. Things that look clearly intended can easily be programming errors, things that seem like they should be easy can be hard. I think the reverse can be true too but not as often. So I don't think the thought that any programmer would know this is a ridiculous edge case is one that holds any real weight here.

londons_explore 6y ago

The commit that did this ~4 years ago was very much in the open, and had rationale in the commit message. I think it's pretty sad that nobody here has linked to it... It's as if the people who care about this stuff aren't the same ones who write and review code for a living...

junon 6y ago
You could have linked it yourself to refute what I said, then. But you didn't. You didn't waste any time insulting someone, though.
_qulr 6y ago
Incorrect. The commit was 5 months ago, and it's linked here: https://news.ycombinator.com/item?id=24841118 https://news.ycombinator.com/item?id=24841118

shadowgovt 6y ago

Having seen the source code for web browsers, I'm 100% willing to believe it's a programming error. The likeliest point of introduction is where Google added account login to the browser itself. At that point, either ambiguity of specification or failure to test as though the user thinks Google is a privacy-hostile agency (while using a browser that allows them to login to Google) could have resulted in someone adding a special case to refrain from throwing the credentials away that keep the browser logged in that inadvertantly failed to throw the credentials away that keep a session logged in.

junon 6y ago
Why is something like browser identity (which is NOT a w3 standardization) at all linked with session identity?
- shadowgovt 6y ago
  Because code reuse is a virtue... Until it introduces an unexpected bug.