Hacker News Reader

Comment by jdp23 | Hacker News Reader

Yikes. A release in November introduced an API bug that was active for about 6 days, impacting 52.5 million users.

* With respect to this API, apps that requested permission to view profile information that a user had added to their Google+ profile—like their name, email address, occupation, age (full list here)—were granted permission to view profile information about that user even when set to not-public.

* In addition, apps with access to a user's Google+ profile data also had access to the profile data that had been shared with the consenting user by another Google+ user but that was not shared publicly.

View on HN

FWIW, also from the blog post:

> We discovered this bug as part of our standard and ongoing testing procedures and fixed it within a week of it being introduced. No third party compromised our systems, and we have no evidence that the app developers that inadvertently had this access for six days were aware of it or misused it in any way.

> we have no evidence

I know you can't say "no one did", but I wish announcements like this gave some level of confidence. "All API calls are logged and no 3rd party made calls that exploited this vulnerability" is very different from "We have no idea if anyone used this, but there's no proof that they did".

I mean, one has to assume your data was exposed anyway, but still, it'd be nice to know.

Yeah, testing in production. I wish the tech industry would stop this madness and do QA before releasing. It's all about code velocity and shipping things, we need to hold ourselves to higher standards. I'm afraid unless there will be legal pressure and a framework it will continue this way.

There's nothing that says there's no QA/testing before releasing. "Testing in production" doesn't remove the ability to do testing before production.

You should be testing your software at every step of its lifecycle, especially in production. Production is where it matters if there's bugs.

That doesn't get as many clicks!

It still indicates a fairly massive failure in terms of process. If you have the tools to discover this in an automated fashion but those tools are not part of your release process so you find out about them in production a week later then something is quite borked.

If Google Drive had a failure like this it would be a lot worse than Google+. And that's a much more complex environment.

Drive doesn't have the dumb "shared and yet marked as private" superposition of user intent flags that g+ profiles do.

The technical constraints that protect data are pretty solid, and I have no concern at all about any kind of generalized breach or exposure with one of Google's core data systems like drive, docs, and Gmail. But looking at the sharing configuration for g+, it's just not intuitive what's shared and with whom, because the states seem to contradict each other.

You can have proper technical controls managing your permissions only if you can articulate what those permissions are supposed to be. And you can't just v2 the API with a better sharing model because users have already expressed their intent using the old model. You'd have to reacquire user intent, which is basically a non-starter.

So either you put up with a crap sharing model which is impossible to get right, or you delete everything and start over. It's no wonder they're killing it.

Weren't they also saying somewhere that they are only keeping the logs from the last 3 months or so? So saying "we don't have evidence" might be true, but means nothing compared to the 6 year span the bug was present.

6 days, not years.

A 'bug'. Don't give them so much credit. They could be selling the data off.

Reply on news.ycombinator.com