4 ms·

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 introduc

by morley 8y ago

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.

foepys 8y ago
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.
- foota 8y ago
  6 days, not years.
theWheez 8y ago
That doesn't get as many clicks!
- jacquesm 8y ago
  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.
  - tylerl 8y ago
    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.
ergothus 8y ago
> 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.
kerng 8y ago
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.
- scrollaway 8y ago
  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.

by morley 8y ago

foepys 8y ago

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.

foota 8y ago
6 days, not years.

theWheez 8y ago

That doesn't get as many clicks!

jacquesm 8y ago
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.
- tylerl 8y ago
  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.

ergothus 8y ago

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

kerng 8y ago

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.

scrollaway 8y ago
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.