Hacker News Reader

Comment by olliej | Hacker News Reader

Why would google have access to that material? Is their general secret mechanism not E2EE? I'm fairly cynical on google's approach to privacy but I would be shocked if they're normal syncing isn't actually secure and private.

View on HN

That this is indeed the case is the topic of TFA.

Chrome passwords are encrypted with your Google password by default, it's just not e2ee. This isn't even encrypted in that way it seems.

The only real "threat" is your Google account itself being compromised by a third party able to phish their way into your account or bypass your 2fa mechanisms (e.g. by SMS sim swapping). As always, https://landing.google.com/advancedprotection/

The people here saying "privacy" are speaking of some doomsday scenario where Google itself leaks all of this data, which would be unprecedented and is unlikely with how many safeguards there are for employees to access any user data at all within Google.

Chrome sync has let you set a separate password for end to end encryption for as long as I can remember, though badly until January 2020. https://bugs.chromium.org/p/chromium/issues/detail?id=820976

That's not end-to-end, that's just regular old symmetric encryption.

"End to end encryption" can mean either a scheme in which each device has its own key and arranges to trust others, or a scheme in which a key is shared across devices (symmetric).

Just because there is only one key doesn't disqualify the solution from e2ee status. If the middleman does not have the key, it's still end to end secure.

Assymetric keys aren't a requirement for E2EE. In fact, in most cases, assymetric encryption is only used to exchange a symmetric key to use for data decryption anyway. Assymetric cryptography is way too inefficient to encrypt and decrypt more than short secrets.

The whole reason you'd enable this feature is for when you lose your phone and need to provision a replacement. There's not really any way to do the whole key exchange dance if you don't have access to the original source. A password derived key is essential in this case.

> doomsday scenario where Google itself leaks all of this data, which would be unprecedented and is unlikely ... (emphasis added)

From the linked article [1]:

> December 2018: Google+ Bug Exposes 52.5 Million Users’ Data Google+ faced its second big breach of 2018 when a November update created an API bug that exposed data from 52.5 million Google+ accounts. Google fixed the bug within six days, and moved up Google+’s burial date from August to April 2019.

> Google originally decided to terminate Google+ after another breach became public earlier in 2018

and an earlier Google+ bug that was reported in WSJ [2]

> Google Exposed User Data, Feared Repercussions of Disclosing to Public

> Google opted not to disclose to users its discovery of a bug that gave outside developers access to private data. It found no evidence of misuse.

[1]: https://firewalltimes.com/google-data-breach-timeline

[2]: https://www.wsj.com/articles/google-exposed-user-data-feared... (Oct, 2018)

Don't forget about this: https://www.businessinsider.com/google-fired-employees-abusi...

>Chrome passwords are encrypted with your Google password by default, it's just not e2ee.

Source?

Chrome settings -> sync -> encryption

I believe that's off by default (even when you turn on sync), and I believe that if you do turn it on, it's not using your Google password, but a separate password of your choosing.

How does https://passwords.google.com work then?

I think the default behaviour is not E2EE.

Reply on news.ycombinator.com