Probably stored under the same security infrastructure as Gmail and hangouts messages.

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.

> Which, IIRC, means no human is given direct access without the account holder's permission.

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.

A "suitably clever Googler", an insider threat, is something that Google actively defends against, at multiple levels. The general assumption is that you can't blindly trust internal users, devices, etc. See the BeyondCorp paper for an example. The internal security infrastructure (monitoring, logging, auditing, analysis) probably consumes more CPU cycles than what's needed to run a large number of entire business out there, especially after the China incident -- remember who alerted the 30+ companies that got infiltrated.

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...

"Russia, if I Googled correctly." You clearly trust Google to some extent, since you search with it.

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 you can accuse Google of not taking security seriously.

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).

Additionally: The google of tomorrow != the google of today. Even if you assume that google currently has the best security/privacy setup in place, they could suddenly turn around tomorrow and hand that to whoever they wanted.

Exactly how does almost singlehandedly transitioning the global Internet to forward-secure curve-based TLS help their security and not yours? All I can see in that work is cost for them.

That's easy, TLS is great for Google as ISPs and wifi providers can't replace ads with their own in transit.

That is some Alex Jones level reasoning. There's no end-user security you can provide that can't be reframed that way.

Belatedly seen this. For the record I just want to note that I claimed that Google have sound business reasons to promote TLS, i.e. that their ads can't be MITMed. I have no clue why tptacek would go ballistic at that suggestion.

What he said isn't even entirely wrong... both adware and shitty ISPs do this, mostly as a vector for malware. Google has admitted as such, and migrating their ad platform to https and teaching Chrome and Firefox to refuse mixed content was part of not allowing their service to be abused for this.

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).

Google's business is based on destroying what you and I consider to be privacy, so I don't see how you could expect them to change their minds about that.

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'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.

Theoretically, just like they could prepare a broken version of iOS that disables security and push it to targeted users. In reality, such a software/infrastructure does not exist today, and we've been shown what happens when Apple is asked to write it.

I don't think that is enough. Here we are relying on Google being magnanimous enough to not use the data to increase their profitability. And even beyond that, your opinion is a little naive to hold in a post-snowden world.

How is it necessarily wrong if Google uses the data to increase their profitability?

Right - their policies may be perfect today but they may not even exist tomorrow.

That's fine as far as trusting Google keeping their employees from doing bad things.

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.

Well if you trust Google you don't need on-disk encryption in the first place. SSL already solved the transport issue.

My point that you have no control over the data once you send it to Google. You don't even know if they even encrypt it on their disk/server anyway.

That's really just BS. What's the point of encryption if both the keys and the content is known by Google? They could as well use just SSL and that wouldn't make it safer than this kind of "encryption".

The benefits of this sort of encryption & privacy infrastructure:

* 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.

The rest of points are not addressed by this sort of encryption because the keys are on disk too. Google employees have access to the keys. It's like leaving the keys into the lock and claiming it's more secure because it has a lock. In practice the data is protected only by ACL. Encryption is just a marketing keyword in this case.

On disk somewhere (encrypted, with a different key) is not the same as "leaving the keys into the lock" in a large distributed system designed to avoid single points of failure.

There are always weaknesses, but think about why a bank employee can't just decide to take your money. Internal controls are a thing.

>> 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.

I think you're defining "security" and "privacy" to mean what you want them to mean. The absolutist definition that's popular in certain circles isn't the common definition.

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.

You and me have different views about privacy. I think you should have control over your data. Google indirectly provides your email information to advertisers. Example: You receive a flight notification. Google reads your email and targets you with ads related to your trip(i.e. hotels, things to do etc based on your age, gender etc) though various channels(i.e. gmail UI, google search, Google Now/AI etc). It wants to do the same with this Allo application. The encryption they claim it's in place it's worthless because it doesn't protect you from this. They try to claim your data is `private` because it's encrypted.

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.

> SSL only handles the first two bullet points.

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.

Google does not work like every other data center in the world. All internal services communicate over SSL (or similarly encrypted links)

Though only because they discovered their internal unencrypted links were being systematically compromised on a truly massive scale for years.

False. There was already internal encrypted traffic and the revelations only sped up the migration for the rest.

https://www.washingtonpost.com/business/technology/google-en...

I think the load-balancers do not communicate over SSL. At least not the ones in front of Appengine applications. Perhaps only inter-services communication is encrypted(i.e. app service with database service).

Most datancenters are lost once the internal network is hacked so I think that's a different issue. Encryption wouldn't help either because the attacker could get the keys too.

Encrypted links between processes inside a data center is still a good thing: It protects against malicious actors sniffing traffic (without compromising the machines in the data center)

So again... how is this better than end to end SSL?

I actually trust Google. And I believe they do their best to make it work this way. What I don't trust is the government. :(

Bad news then... Google is not what it seems. http://www.newsweek.com/assange-google-not-what-it-seems-279...

Extremely hard. I am so sick of hearing this. It all boils down to hand waving and assumptions instead of verification and scrutiny.

This is the first time I'm reading about that sort of restrictions at Google. What are your sources? Or did/do you work there?

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)

It doesn't matter how well its designed. Once they get an NSL, they would need to make compromises, unless the messages are not in a readable form.

All that Google has accomplished, is convinced me to steer clear of Allo.

> but you do have to trust Google's privacy infrastructure.

The NSA have already backdoored it.

In order to receive government protection and favors, they have to play their game. Its not like their advertisement profiling algorithms isn't useful for intelligence gathering and profiling.

> extremely hard for a Googler or product team to do something directly nefarious

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?

[1] https://en.wikipedia.org/wiki/File:Prism_slide_5.jpg

And that is exactly why open IM protocols and 3rd party clients are so important.

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.

[1] https://pidgin.im/

[2] https://conversations.im/

I've seen this sentiment in a couple of places now -- and the news media and non-technical folks seem to refer to "encryption" very loosely to mean "protected in the way I want it to be protected at the times I want it to be protected".

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.

Perhaps it's some kind of homeomorphic encryption scheme. Hey it technically leaves the original message encrypted!

Ifmeaningful homomorphic encryption was an option, then we'd be living in a quite different world.

Surprisingly, homomorphic encryption is now practical enough to run a Kaggle-like data science competition, but without disclosing data. At least one such competition is known to run with real money prize.

https://medium.com/@Numerai/encrypted-data-for-efficient-mar...

This reads like fake smoke and mirrors to trick investors/data providers/participants instead of anything that's real cryptographically.

Very true. I was just making a tongue-in-cheek conjecture about the justification/rationalization that might be employed.

As rad as it would be if Google started doing privacy-friendly-ish datamining on user data by homomorphically encrypting it, you and I both know that's not what they're doing. You forgot the `/s`, sadly.

Along those lines, there's RAPPOR:

http://research.google.com/pubs/pub42852.html

They could be using some form of homomorphic encryption here, in which case it would still be meaningfully encrypted.

Homomorphic encryption isn't currently practical, even for small-ish problems. It needs to use constant space, and every operation needs to flip on average half of the bits. There aren't obvious ways around these restrictions, though off hand I can only come up with a quick hand-wavy "proof" that this must always be so if less than one bit of the unencrypted state is to be lost with every state update.

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.

That is only true for fully homomorphic encryption. There are simpler cryptosystems (e.g. ElGamal for a trivial example) that have more constrained homomorphisms that theoretically could be used here.

The OP was talking about encrypting the chat data and performing machine learning on encrypted data without decrypting it. I really wouldn't know where to begin to construct such a thing using a simpler cryptosystem, such as ElGamal. Do you have any hints as to where to begin?

There is actually some research work on this front because it is highly valuable to analyze some data but not have access to it.

However, it's better just to encrypt everything and not be tempted by the advertising surveillance dollars.

  So, not meaningfully encrypted at all then?

One could also think of it as your private key being with (1) you, (2) Google.

It's in safe hands ;-)

Sure, whatever safe hands mean. Safe in an NSA datacenter. Safe in the hands of the Chinese government. Safe with whatever sysadmin has access to it.

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.

> just keep it accessible only to me

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.

And that's a little scary, you sell a bit of yourself to get access to a service. It's not really the best case scenario I would want.

> One could also argue that the service is free and the service provider needs a (or yet another) way to monetize it.

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.

ahem Perhaps not https://en.wikipedia.org/wiki/PRISM_(surveillance_program)