An obligation to announce findings would create a moral hazard as well, since the incentives would suddenly tilt sharply towards not looking for security vulnerabilities.

A good point. There is also the fact that the average Internet user has no clue what things like a vulnerability, or a bug, or even a log is or what it means. Data mining, web scraping or data harvesting--no clue.

I just saw a TV report this weekend that stated CA hacked FB. Well on second thought, maybe that's better than trying to explain that even though "thisisyourdigitallife" you really need to spend some time and effort to understand what it all actually means.

The default P0 timeline is 90 days... do we know when Google found this vulnerability in Google+? Does Google apply the P0 deadline to their own vulnerabilities? Is it fair to expect them to?

P0 "competes" on an even playing field with everyone else doing public vulnerability research and, to a reasonable approximation, has access to the same information that everyone else does. Internal security assessment teams have privileged information not available to public researchers, and rely on that information to get assessment work done in a reasonable amount of time.

When P0 discovers a bug, it has (again, to an approximation) proven that any team of researchers could reasonably find that same bug --- everyone's using roughly the same sources and methods to find them (albeit P0's are done at a much higher level of execution than most amateur teams). That's the premise under which P0 bugs are announced on a timeline: what P0 has done is spent Google engineering hours surfacing and refining public information.

If you want to go a little further into it: the 90 day release window has a long history in vulnerability research. It's the product of more than a decade of empirical results showing that if you don't create a forcing function, vulnerabilities don't get patched at all; vendors will back-burner them indefinitely. Google's internal teams don't have that problem: when Google bugs get found by internal teams (and, presumably, by external ones), they get fixed fast. There's no incentive problem to solve with an announcement window.

Another lens to look at this through is the P0 practice of announcing after the publication of patches, regardless of where the window is. That's because, again, P0 is doing public research. Typically, when a P0 bug is patched, the whole world now has access to a before/after snapshot that documents the bug in enough detail to reproduce it. At that point, not announcing does the operator community a disservice, because the bug has been disclosed publicly, just in a form that is only "available" to people motivated to exploit the bug.

And again: not at all the case with internal assessments.

This wasn't a Project Zero bug, was it? Project Zero is a very special team with a distinct and notable charter. They aren't "Google's Security Folks". Certainly Project Zero has discovered and disclosed bugs in Google products in the past.

https://www.cms.gov/Outreach-and-Education/Medicare-Learning...

edit: less-than sign wrong way

> https://www.cms.gov/Outreach-and-Education/Medicare-Learning...

> edit: less-than sign wrong way*

Breaches, not vulnerabilities. The discussion is not whether or not breaches should be disclosed[0], but whether newly discovered and believed-to-be-unexploited vulnerabilities should be disclosed.

[0]: They should of course, after a reasonable period in which to patch the vulnerability used.

you cannot prove the negative (realistically). If you have a vulnerability, you must treat it as though it has been exploited.

You can want the world to work differently, but to do so coherently I think you should explicitly engage with the unintended consequences of such a policy.

edit: Within reason, anyway. Obviously if your vulnerability includes write access to logs or something then you're poked.

> We made Google+ with privacy in mind and therefore keep this API’s log data for only two weeks. That means we cannot confirm which users were impacted by this bug. However, we ran a detailed analysis over the two weeks prior to patching the bug, and from that analysis, the Profiles of up to 500,000 Google+ accounts were potentially affected. Our analysis showed that up to 438 applications may have used this API.

^ the above statement, but couched with this:

> We found no evidence that any developer was aware of this bug, or abusing the API, and we found no evidence that any Profile data was misused.

Devil's advocate: Do you believe that proactive security assessments would still be performed if each vulnerability found was required to be disclosed as though it had been exploited?

It is required by law to report breaches of data, though I can assure you that in practice, this does not happen nearly as often as you'd expect or hope.

There is, however, no requirement to disclose vulnerabilities for which there is no evidence of exploitation or data breach, or to disclose vulnerabilities that were provably never exploited.

In my case, it was usually not a computer issue. It was usually a case of "We sent a check or letter to the wrong address" and it was weirdly common for the reason to be "Because your dad, brother or cousin with a similar name and address also has a policy with us and you people are nigh impossible to tell apart."

And we couldn't say anything like that.

Point being that divulging the issue comes with risks of making the problem worse. So it's not as simple and straight forward as it seems.

https://www.oag.ca.gov/privacy/databreach/reporting

If there is a reasonable belief that data was exposed, all of the exposed CA residents need to be notified, and if > 500, the Atty General of CA needs to additionally be notified.

> California law requires a business or state agency to notify any California resident whose unencrypted personal information, as defined, was acquired, or reasonably believed to have been acquired, by an unauthorized person.

With links to more specifics in the CA Civil code.

Is it 100% confirmed that the logs would show it?

What they said was "We found no evidence that any developer was aware of this bug, or abusing the API, and we found no evidence that any Profile data was misused."

That seems only to say they couldn't find anything. Not that it absolutely didn't happen.

The answer is clearly no as they only had two weeks worth of logs out of the three years during which this bug has existed. Here's what they're saying:

"We made Google+ with privacy in mind and therefore keep this API’s log data for only two weeks. That means we cannot confirm which users were impacted by this bug. However, we ran a detailed analysis over the two weeks prior to patching the bug [...]"

https://blog.google/technology/safety-security/project-strob...

> This data is limited to static, optional Google+ Profile fields including name, email address, occupation, gender and age. (See the full list on our developer site.) It does not include any other data

This is such a bogus statement out front. The first time I read it, I didn't even see "the full list" mentioned. The full list is much longer than this seemingly innocuous list of properties of a person. It includes such gems as:

> A list of places where this person has lived.

> A list of email addresses that this person has,

> The hosted domain name for the user's Google Apps account.

It's a little worse than they painted it to be, maybe not much, but at least they're being transparent, I guess...

Changes the facts of the story 0%

- https://www.wsj.com/articles/techs-dirty-secret-the-app-deve...

- https://www.androidpolice.com/2018/09/21/opinion-no-one-get-...

Given that, and the articles you pointed out regarding Murdoch's history (coupled with his unusual willingness to compromise the editorial independence of his media properties), I'm not sure the WSJ is a reliable source in this case. Not that I expect them to blatantly lie, but half-truths and misdirection can go a long way (cf. comments in this discussion that question whether the WSJ is making a mountain out of a molehill here).

Citation needed. Google's blog post wasn't very clear, but it sounds like an API that more than 400 developers use returned more data than was intended. Google thinks the developers didn't use this information, but logs wouldn't help Google come to this conclusion.

Murdoch has a vendetta, but Google isn't being transparent here either.

Some other article I saw quoted somewhere said that they only kept logs for a short time for this service. I wonder how they ruled out exploits older than the logs?

In other words, you don't have evidence that this vulnerability wasn't abused in 2 weeks, you have evidence that no one abused it in ~6 months. Still not perfect, but a more compelling argument that it wasn't abused.

>We made Google+ with privacy in mind and therefore keep this API’s log data for only two weeks. That means we cannot confirm which users were impacted by this bug.

They have no idea if it has been used.

The other parts to your question are:

1. Should the company be compelled to disclose the vulnerability?

I don't think that is reasonable. Enforcing this would be a nightmare anyway.

2. If they did not disclose the vulnerability, but it becomes public knowledge another way, should there be any recourse?

I think that should be decided and enforced by the users. Unfortunately, that is becoming steadily more difficult, as companies like Google grow, and there are fewer viable/available alternatives to their products.

3. Does a company have a moral imperative to share this information?

I think that the action to share such information takes a higher moral ground than to do otherwise.

That's not true. The logs show that it has never been used by anyone the two weeks they had logs for. It looks like the vulnerability existed for about three years. Given this is Google+ we're talking about, it's entirely believable that someone widely exploited the bug in the past, but stopped because Google+ is dead and no one updates it anymore.

> [Honest question] Should the company announce it publicly?

Yes, and they did. They just waited for six months to do it.

Does anyone read the article anymore? Or do they just read it for what they want to see and ignore the rest?

They don't have log coverage for 90%+ of the time period, so that's not something their logs could even possibly show.

The Wall Street Journal: "Because the company kept a limited set of activity logs, it was unable to determine which users were affected and what types of data may potentially have been improperly collected, the two people briefed on the matter said. The bug existed since 2015, and it is unclear whether a larger number of users may have been affected over that time."

"Google discloses Microsoft Edge security flaw before a patch is ready" https://www.theverge.com/2018/2/19/17027138/google-microsoft...

https://www.theverge.com/2013/5/23/4358400/google-engineer-b...

Do you think Google acted in a fair or unfair matter?

1. There's actually nothing here to suggest this was done as part of project zero or any part of tavis's job. In fact, this was before project zero even existed, AFAIK.

2. He published details about it in march (O(60) days), as he said. It was still a security bug then, just missing a working exploit.

3. This thread produced a working exploit.

I'm gonna go with "either unrelated or fair".

Unrelated if it wasn't done by Tavis as part of his job, and fair if it was given the timeline and disclosure policies that existed at the time.

So does that mean that every single time you patch a remote-exploitable hole, in your web server, et.al, you have to file a report with every single government saying that there might have been a leak of all our data from all of our users, but we're not sure? It will be like the California proposition 65 warning where there will be so many "could be potentially harmful to a fetus" warnings that they all fade into the noise.

Just think of all of the CVE's reported by Microsoft, Red hat, etc. Anyone of those _could_ be a vulnerability leading to the loss of user data, and there is no guarantees that you would be able to detect it via logs.

Because reality is that this would essentially require policing every commit that ever makes it to public serving in every company.

To call that unreasonable is vastly understating matters.

Yes, because the #1 thing on the mind of someone who gained unauthorized access (e.g. a remote execution vulnerability) to a system is to cover their tracks, which includes things like doctoring logs.

> Company finds a security vulnerability caused by a bug

Remote execution vulnerabilities do exist..