'using encryption that leaves the messages accessible to Google’s algorithms' So, not meaningfully encrypted at all then?
Which, IIRC, means no human is given direct access without the account holder's permission. Algorithms are allowed access, but only if they emit data that is similarly secured, or emits data in aggregate (where, I think, aggregate was defined as 100k+ users per aggregate data point)
It's extremely hard for a Googler or product team to do something directly nefarious, but you do have to trust Google's privacy infrastructure.
But that's not the first concern one would have. Pervasive surveillance programs have penetrated service providers' data centers. Law enforcement can get warrants to access this information too easily, and many service providers turn over information on request, rather than requiring a warrant.
* Protects you (user) from eavesdroppers between you and Google.
* Protects your data from eavesdroppers inside Google's data centers.
* Protects your data at rest (on disk).
* Protects your data from malicious employees.
* Enforces a great deal of scrutiny over who can access your data, and what they are allowed to see.
But, yes, they process and store your data, so there's no 100℅ secure approach to be had here.
---
SSL only handles the first two bullet points.
There are always weaknesses, but think about why a bank employee can't just decide to take your money. Internal controls are a thing.
That's what ACL is...The encryption doesn't improve the security of the data if the keys are not stored securely. Simply put the data security is as good as the ACL of the keys is. For your peace of mind you may want to know the processes(i.e. audits, ISO standards/certifications) rather than a marketing keyword("encryption", "military grade" etc). Encryption may be part of that framework but I don't think it's relevant enough to be advertised as a stand alone 'product'. You can be sure that your account balance is not encrypted. It's the ACL process that protects you from a rough employee.
We already know that Google has a relative good security process in place. However this is not about security in the first place. It's about privacy. And here encryption brings no privacy gain because Google has the keys so as I previously said it's just marketing BS. Most people are not worried that Google gets hacked. They are worried that Google is selling their data to 3rd parties for profit and to governments for political reasons.
Privacy is mostly not about keeping data from the government. Your bank account is private for most practical purposes though I'm sure with a warrant, law enforcement can find out about it. It's not going to show up in the news and your competitors aren't going to see your bank statements.
Also, Google isn't handing your private email over to advertisers - never has, probably never will.
Authentication and authorization (ACL's) are useful for both security and privacy. This is what makes cloud computing possible (along with encryption, too).
Yes, we can talk about weaknesses in our systems, but let's not completely dismiss the security and privacy features that are already there.
The other case which is uglier is that Google gives your data to foreign governments or other agencies. This may have great consequences. Cloud computing is based on trust and it's possible because the main players(i.e. US government, cloud providers such Amazon) are trusted not to spy their clients but I don't see many rushing to a chinese cloud vendor to host critical data(i.e. email) on their servers.
The security and privacy features we have are currently based on the good will of the provider (i.e. Google). If we talk about encryption of personal data I think it's worth to ask a bit more than a buzzword. One such thing is to do not share the encryption keys.
Only the first point. If Google works like every other data center in the world, then SSL stops the moment your data hits their first load balancer.
https://www.washingtonpost.com/business/technology/google-en...
Unless the user is the only party that can access the keys (i.e. they are only stored locally on the user's device), then I'm sure Google will it very easy to access personal information when a government demands access.
Or did we forget that Google is part[1] of PRISM?
The NSA have already backdoored it.
Or compulsion by any government to which Google is responsible (e.g. Russia, if I Googled correctly). Or a suitably clever Googler (as you note, it may be difficult, but 'difficult' ≠ 'cryptographically secure').
As when Facebook didn't think HTTPS made sense until someone sniffed Zuckerberg's password in a coffee shop, I don't think Google (or any other cloud firm) will take security seriously (as opposed to paying lip service to it for marketing purposes) until someone in the C-suite is materially embarrassed by its lack.
I don't think you can accuse Google of not taking security seriously. They are making a security tradeoff that allows governments and insiders access to private data. This is a legitimate tradeoff to make, and a legitimate thing to criticize them for. Apple makes a different choice, and it's important that we have a debate around which is the right security design.
But making a claim that Google is not serious about security does a disservice to the really good people there who move mountains to secure the service.
I don't think they take my security, and the security of my data, seriously. They seem to care very much about their security.
> They are making a security tradeoff that allows governments and insiders access to private data. This is a legitimate tradeoff to make
No, at this point I don't believe that it is legitimate, any more than it's legitimate to sell an oven which will explode if the temperature dial is set above 600° ('just don't set it that high!').
Yes, there are people at Google who work very hard to secure Google's data; there are people at Google (e.g. Adam Langley) who care a lot about users' data. There may even be people at Google who are working very hard to change its course on user privacy.
But Google, the company, does not take the security of user data against privacy threats seriously: if it did, it would use a better architecture (note that Apple doesn't take user-data security seriously, either, since they can MITM any time they want; nor does Mozilla, nor does Microsoft: no organization's hands are clean, so far as I can tell).
Google and similar companies have a coherent worldview in which they collect user data, protect it from outsiders and inside threats, and do benign and wonderful things for users in return. Within that worldview, they do an excellent and commendable job. Calling their beliefs on data collection a security issue muddies the debate.
I'm curious about your comments on Apple. If I back up my phone to iCloud, how can Apple "MITM any time they want"?
I was referring to iMessage: my understanding is that it Apple is the CA for all iMessage keys, and thus they can issue a certificate to anyone, if they wish to or are compelled to.
Just because Google sells something we don't like doesn't mean they're evil, but it means they have a responsibility to limit the attack surface outside attackers use. There is no way to eliminate all attack surface while still allowing third party admins or closed source code (technically, its impossible period, but w/e).
The security whitepaper gives only a hint of what's done, such as checks on former employees' accounts and so on:
https://static.googleusercontent.com/media/1.9.22.221/en//en...
All that Google has accomplished, is convinced me to steer clear of Allo.
Still, I wouldn't trust that. I can think of enough cases in which algorithms fed with that information would do things not in my interests. (You could easily imagine some internal scoring or profiling a lgorithms taking advantage of the data for example)
Telling "it's only algorithms" doesn't make it secure it I don't know what the algorithms do. (Which of course I can't as it is the core of their busyness)
If both you and your correspondents do use 3rd party IM client ([1], [2], etc), then just run OTR2 or OMEMO on top of the protocol, and let google store whatever it pleases - it's not going to be much use for them.
Can we please use technical terms with precision?
You can have data encrypted at rest and in transit that is still accessible to the provider and the fact that the provider can decrypt it for processing doesn't make it any less "encrypted". There is not a total ordering of encryption or security schemes.
If you would like to say that the data isn't end-to-end encrypted such that it is opaque to the service provider -- say that. Don't say it isn't meaningfully encrypted.
https://medium.com/@Numerai/encrypted-data-for-efficient-mar...
So, in order to perform machine learning on terabytes of data, you need to flip terabits for every update of the homomorphic state machine.
That being said, I could imagine someone coming up with a homomorphic encryption algorithm that starts out with a few megabits of excess entropy and leaks entropy at a bounded rate while remaining more efficient at calculation, and where the initial state is set up cleverly such that after a bounded number of steps, the state machine starts making nonsense computations and stops leaking entropy. Though, this just feels very brittle to intentionally leak entropy, and I have no idea how anything remotely like this could be actually constructed.
However, it's better just to encrypt everything and not be tempted by the advertising surveillance dollars.
So, not meaningfully encrypted at all then?
It's in safe hands ;-)
Instead of worrying about what "safe hands" mean, just keep it accessible only to me, and each respective conversation with the people I communicate with.
One could also argue that the service is free and the service provider needs a (or yet another) way to monetize it.
If the privacy settings are insecure by default, one shouldn't have high expectations anyways.
True, which is why I pay Apple money. No incentive to mine my data... in fact given that privacy is a big marketing angle Apple's incentives are to make it impossible for them to access your data even if subpoenaed or presented with a warrant.