4 ms·

All of your characterization here is correct, but does it really make sense to classify it as an internally discovered security problem instead of a potential-o

All of your characterization here is correct, but does it really make sense to classify it as an internally discovered security problem instead of a potential-or-real-breach when it was present for years, trivially exploitable by third parties, and is impossible to vet? There's no way to know whether or not it was used because there was no logging in place for third-party use of user data, and apparently no audits (manual or automated) were ever performed of these APIs. Google more or less admitted that all they had to go on here was an examination of the third parties who potentially had access to the data, because they have no way to know what they actually did with it and apparently can't contact them to find out. The reporting is definitely exaggerating the significance of the data that was exposed and making it sound like it's known that the data was collected by third parties, but it's absolutely the case that the ball was dropped here and it's inappropriate to pretend nothing happened. There's simply no way to know, which is itself a breach of user trust. It's kind of a no-win situation here given the way the media reports on these matters, but attempting to keep it quiet was incredibly foolish - everything remotely bad that happens at Google is going to get leaked by internal troublemakers now, and legal/pr should know that and should have gotten ahead of this.

tptacek 8y ago
There is nothing remarkable about finding a vulnerability that had been latent in a codebase for years. It is not clear to me what "ball" you believe has been "dropped" here. If it's that the first N groups of security testers that looked at this code missed the vulnerability that their N+1th found, sorry, no: that happens all the time.
- kevingadd 8y ago
  If the vulnerability is 'any one of our API users could have accessed <large set of private data> over the past 3 years' that's a lot more than 'we found an obscure latent security issue'. Especially if you can't prove it didn't happen by examining logs (which they can't, because they didn't keep logs) or auditing your API users (which they couldn't). It doesn't feel like splitting hairs to separate this from things like 'we found an obscure xss exploit internally which is now fixed'. It is explicitly a Possible Breach, not just a Bug. If you're arguing that Possible Breaches don't require disclosure, well, that's a choice to make, but it worked out poorly in this case and it will probably keep working out poorly because everything G does is under a microscope until the far right gets bored with them.
  - spoondan 8y ago
    There’s a strong argument against disclosure of internally discovered bugs (security or otherwise) that have no evidence of user impact. Internal efforts to find and fix bugs improve actual quality/safety but, if indiscriminately announced, harm perceived quality/safety. We have seen repeatedly how bad security reporting of actual weaknesses can drive users to more risky alternatives or behaviors, lowering actual security and privacy. It’s just too easy to say that all major security defects should be announced or that no major defects should ever exist. There are about 430 developers that could have exploited this vulnerability. There was no evidence in the available two weeks of logs of it being exploited. And the number of users and types of data available make Google+ a low value target. The decision to not announce was reasonable, common, legal, and moral. It sets a poor standard to suggest they should have acted different because they’re now under fire from people with far darker motives than reporting truth or advocating for consumer privacy. Those exploiting the story for their own gain should be shamed rather than capitulated to.
  - tptacek 8y ago
    The vulnerability that was discovered here was less significant than an "obscure XSS exploit", not that it matters at all to the analysis.
  - UncleMeat 8y ago
    An xss bug exposes even more data than this vuln. Why would that be less severe?
UncleMeat 8y ago
> but does it really make sense to classify it as an internally discovered security problem instead of a potential-or-real-breach Literally all security bugs can be described this way. "Company closes security bug" is not really news, nor should it be. How many XSS bugs have been closed at your place of business? Those are literally all potential breaches. Should each one of those get published in the news? Or does this requirement only exist for the major companies? I'd wager that FAANG companies are closing thousands of similar bugs annually. The only reason this one is treated differently is the chosen narrative by the journalists.

tptacek 8y ago

There is nothing remarkable about finding a vulnerability that had been latent in a codebase for years. It is not clear to me what "ball" you believe has been "dropped" here. If it's that the first N groups of security testers that looked at this code missed the vulnerability that their N+1th found, sorry, no: that happens all the time.

kevingadd 8y ago
If the vulnerability is 'any one of our API users could have accessed <large set of private data> over the past 3 years' that's a lot more than 'we found an obscure latent security issue'. Especially if you can't prove it didn't happen by examining logs (which they can't, because they didn't keep logs) or auditing your API users (which they couldn't). It doesn't feel like splitting hairs to separate this from things like 'we found an obscure xss exploit internally which is now fixed'. It is explicitly a Possible Breach, not just a Bug. If you're arguing that Possible Breaches don't require disclosure, well, that's a choice to make, but it worked out poorly in this case and it will probably keep working out poorly because everything G does is under a microscope until the far right gets bored with them.
- spoondan 8y ago
  There’s a strong argument against disclosure of internally discovered bugs (security or otherwise) that have no evidence of user impact. Internal efforts to find and fix bugs improve actual quality/safety but, if indiscriminately announced, harm perceived quality/safety. We have seen repeatedly how bad security reporting of actual weaknesses can drive users to more risky alternatives or behaviors, lowering actual security and privacy. It’s just too easy to say that all major security defects should be announced or that no major defects should ever exist. There are about 430 developers that could have exploited this vulnerability. There was no evidence in the available two weeks of logs of it being exploited. And the number of users and types of data available make Google+ a low value target. The decision to not announce was reasonable, common, legal, and moral. It sets a poor standard to suggest they should have acted different because they’re now under fire from people with far darker motives than reporting truth or advocating for consumer privacy. Those exploiting the story for their own gain should be shamed rather than capitulated to.
- tptacek 8y ago
  The vulnerability that was discovered here was less significant than an "obscure XSS exploit", not that it matters at all to the analysis.
- UncleMeat 8y ago
  An xss bug exposes even more data than this vuln. Why would that be less severe?

UncleMeat 8y ago

> but does it really make sense to classify it as an internally discovered security problem instead of a potential-or-real-breach Literally all security bugs can be described this way. "Company closes security bug" is not really news, nor should it be. How many XSS bugs have been closed at your place of business? Those are literally all potential breaches. Should each one of those get published in the news? Or does this requirement only exist for the major companies? I'd wager that FAANG companies are closing thousands of similar bugs annually. The only reason this one is treated differently is the chosen narrative by the journalists.