I guess my point is it goes far beyond Chrome. Google is running the Borg hive mind.
... Kubernetes, or "kube" for short. ;)
Source: https://en.wikipedia.org/wiki/Kubernetes?wprov=sfti1
(The Borg have cybernetic enhancements, I’m guessing that’s the link)
There's a lot of security theater around this where people will de-google their software and then run random binaries compiled by unknown people on the internet instead
It doesn't need to be compromised. The biggest ad and ad tracking company in the world has all that data.
How about a browser company that syncs your data on their servers but doesn’t examine it. Even better, they couldn’t do that even if they wanted to, because your data is encrypted on their servers. That company has also never been compromised. Does that sound better?
complete E2E encryption Signal style with you having sole access to the keys and sync is technically pretty non-trivial across multiple devices (also the reason they don't sync device history on previously unlinked devices), so there's a usability / security trade-off.
Honestly not certain whether that fits the need of most users for most data they have.
Signal is blocked in China, and I'm pretty sure it isn't handing the population's intel over to anyone.
Full disclosure I work at Google.
Fortunately, since I use Chrome, I was able to log in and get them clouded over. Whew!
It sounds like it'd add an additional layer of complexity to my situation without an obvious up-side over my existing solution.
Sure, they claim they are open source and that the infrastructure was audited, but this does not prevent them from just configuring their auto-update server to serve a very special update to user at a specific IP.
This is false. The decryption code was run on the server, which means the password was sent to the server briefly. Hushmail simply stored the password for a few accounts. No client code was modified nor any auto-update changed. In fact, if the criminals had used the Java applet, they'd likely have gotten away with it (assuming they didn't update it)
>However, installing Java and loading and running the Java applet can be annoying. So in 2006, Hushmail began offering a service more akin to traditional web mail. Users connect to the service via a SSL (https://) connection and Hushmail runs the Encryption Engine on their side. Users then tell the server-side engine what the right passphrase is and all the messages in the account can then be read as they would in any other web-based email account.
>The rub of that option is that Hushmail has -- even if only for a brief moment -- a copy of your passphrase. As they disclose in the technical comparison of the two options, this means that an attacker with access to Hushmail's servers can get at the passphrase and thus all of the messages.
Only if you enable it, right? And I don't think it's enabled by default, I think it prompts you asking whether you want to or not.
Full disclosure I work at Google, but not on anything related to this.