9 ms·

Company finds a security vulnerability caused by a bug. Logs show that it has never been used by anyone. It patches the vulnerability. [Honest question] Should

Company finds a security vulnerability caused by a bug. Logs show that it has never been used by anyone. It patches the vulnerability. [Honest question] Should the company announce it publicly? PS: Keeping in mind that this is part of the Murdoch vs. Google war going on for about 10 years: https://www.npr.org/sections/money/2009/11/murdoch_vs_google.html https://www.npr.org/sections/money/2009/11/murdoch_vs_google... https://www.thedrum.com/news/2017/03/28/timing-everything-rupert-murdoch-s-google-rebellion-returns-news-corp-eyes-more-ad https://www.thedrum.com/news/2017/03/28/timing-everything-ru... https://www.theverge.com/2018/1/22/16920254/news-corp-rupert-murdoch-carriage-fee-facebook-google-journalism-media https://www.theverge.com/2018/1/22/16920254/news-corp-rupert... [Edit: added the "Honest Question" tag] Edit 2: Related post by Google: https://blog.google/technology/safety-security/project-strobe/ https://blog.google/technology/safety-security/project-strob...

hoos97 8y ago
Yes, because when you go public with the issue you are able to control the narrative. Bad judgement to assume that these issues will never reach the public eye. Especially knowing that a patched was successfully applied...instead Google looks like it is having trouble living up to it's Don't Be Evil motto.
- lostmsu 8y ago
  No, they would have to issue like 10 reports a day. Bugs that are never exploited in web sites are rarely published for multiple reasons. Definitely not something to blame Google for.
  - hoos97 8y ago
    If it wasn't exploited makes it even better...shows that you are being aggressive in identifying issues and applying corrections. Take advantage of opportunities to show transparency in a good light as well as meet your commitments to be transparent when events have not gone your way. This shouldn't be about how many reports you have to issue. Google can afford the staff to make that happen.
    - SahAssar 8y ago
      That's probably not how end users would see it though. If there was a report every other day that google or facebook found and fixed a security bug people would either ignore it or trust another company that wasn't as open much more.
creaghpatr 8y ago
>PS: Keeping in mind that this is part of the Murdoch vs. Google war going on for about 10 years: Changes the facts of the story 0%
- ucaetano 8y ago
  Given that nobody here knows the full facts, only the subset of the interpretations published by the WSJ, this is very relevant.
  - vatueil 8y ago
    I wish I could trust the WSJ's coverage, but I have to agree that they do seem to have an odd tendency to go off the rails on certain issues. A recent example that comes to mind is their Gmail API article, which at best badly misrepresented the situation: - https://www.wsj.com/articles/techs-dirty-secret-the-app-developers-sifting-through-your-gmail-1530544442 https://www.wsj.com/articles/techs-dirty-secret-the-app-deve... - https://www.androidpolice.com/2018/09/21/opinion-no-one-get-email-apps-gmail-add-ons-work/ 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).
tptacek 8y ago
I don't know if it should or it shouldn't, but it absolutely is not the norm for companies to announce those vulnerabilities publicly. Every year, most moderate-and-up-sized tech companies (really, a pretty big swathe of the Fortune 500 outside tech, as well) contract multiple penetration tests, and those tests turn up thousands upon thousands of sev:hi vulnerabilities, none of which are ever announced. 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.
- creaghpatr 8y ago
  It's the norm in healthcare (HIPAA), disclosure is required for breaches that affect 500+ persons, and even <500 person breaches have to be reported annually to HHS and to the individual at the time of discovery. https://www.cms.gov/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNProducts/Downloads/HIPAAPrivacyandSecurityTextOnly.pdf https://www.cms.gov/Outreach-and-Education/Medicare-Learning... edit: less-than sign wrong way
  - charleselegans 8y ago
    IANAL but it doesn't seem that the way they define a breach (https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html https://www.hhs.gov/hipaa/for-professionals/breach-notificat...) includes issues that provably haven't been exploited.
  - dv_dt 8y ago
    That's a requirement in general for CA. https://www.oag.ca.gov/privacy/databreach/reporting 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.
    - russell_h 8y ago
      Is there a required timeframe for doing so?
ocdtrekkie 8y ago
Your statement: "Logs show that it has never been used by anyone." 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."
- stochastic_monk 8y ago
  “We don’t know of any misuse” is very different from “we know it was not misused”. Thank you for being clear about which statement is true.
thomastjeffery 8y ago
It is generally in the company's best interest to publicly disclose the vulnerability, and its effects. 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.
dx87 8y ago
I think they should announce it. It seems pretty optimistic to have an application with buggy code that exposes user data, yet claim that there is no chance that an error or oversight prevented it from being logged. Saying "if we didn't detect the hack then it didn't happen" doesn't inspire confidence.
- kerng 8y ago
  Getting insight to all security bugs of all cloud providers could be interesting- it certainly would increase transparency. Companies have security bugs all the time that they fix when found internally without telling anyone.
blihp 8y ago
Unless they are 100% certain it hasn't been exploited, yes. The reputational and legal risk to appearing to not disclose / cover up an issue is far larger than the issue itself. That changes if they are absolutely certain it was not exploited: then it's just a bug that they fixed and there's no impact beyond that.
- UncleMeat 8y ago
  How many vulns do you think companies find internally daily? Should every vuln be publicized?
  - blihp 8y ago
    If they potentially expose sensitive data, yes. Again, if an organization is certain that it hasn't then I'd say no. Sure, certain is a high bar but there's absolutely no way for people to make informed decisions and/or mitigate issues otherwise.
    - candiodari 8y ago
      Okay ... and how to enforce this ? 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.
      - blihp 8y ago
        I'm not advocating any external enforcement action. Merely taking the position that if there's an internal conversation which goes along the lines of 'that vulnerability could have been really bad but based on what information we have it doesn't look like it's been exploited... should we tell anyone?' then the answer should be yes, it should be disclosed. That sounds like pretty much the conversation that happened inside Google only they decided 'no, better not... we might get in trouble'. That's a red flag right there.
    - UncleMeat 8y ago
ben_jones 8y ago
"We made Google+ with privacy in mind and therefore keep this API's log data for only two weeks" Does anyone read the article anymore? Or do they just read it for what they want to see and ignore the rest?
quickben 8y ago
That didn't stop them so far from making everybody else look bad. The latest in Google's unfair competitive practices: "Google discloses Microsoft Edge security flaw before a patch is ready" https://www.theverge.com/2018/2/19/17027138/google-microsoft-edge-security-flaw-disclosure https://www.theverge.com/2018/2/19/17027138/google-microsoft...
- DannyBee 8y ago
  Having a security disclosure policy and following it to the letter for everyone (including Google) is suddenly an "unfair competitive process".
  - deleted 8y ago
    [deleted]
  - quickben 8y ago
    Is the security disclosure policy 3 business days? https://www.theverge.com/2013/5/23/4358400/google-engineer-bashes-microsoft-discloses-windows-flaw https://www.theverge.com/2013/5/23/4358400/google-engineer-b... Do you think Google acted in a fair or unfair matter?
    - DannyBee 8y ago
      It's interesting you have to go back to 2013 to find something. 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.
      - quickben 8y ago
        I wasn't going down some reverse chronological timeline. It was in the first page of many of results. About 1,2 and 3, if you would zoom a bit out, you have an advertising company that is, by it's intentional actions, making the rest look bad. Outside of contacting the relevant companies, they don't have to push the exploits to the world, yet they do. The rest is just how one spins the story depending on the size of the paycheck received from Google. There is nothing left to conclude, I am out of this thread.
craftyguy 8y ago
> Logs show that it has never been used by anyone 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.
- notatoad 8y ago
  a vulnerability that allows some unauthorized access to user data via the API and a vulnerability that allows edting logs are very different types of vulnerabilities.
  - craftyguy 8y ago
    Well, the comment I was responding to didn't specify: > Company finds a security vulnerability caused by a bug Remote execution vulnerabilities do exist..
    - puzzle 8y ago
      The logs live somewhere else. If you had some magic exploit that let you run code on Google systems AND delete logs, you could do much more damaging things than just reading G+ data.
      - deleted 8y ago
        [deleted]
lern_too_spel 8y ago
> Logs show that it has never been used by anyone. 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.
394549 8y ago
> Company finds a security vulnerability caused by a bug. Logs show that it has never been used by anyone. 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.
tyingq 8y ago
"Logs show that it has never been used by anyone" 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.
- jacquesm 8y ago
  You can't prove a negative. All you can do is hope that your logs are not tampered with and that they show that nobody used the hole that you are aware of.
  - yebyen 8y ago
    I don't know how you could prove whether anyone exploited this or not, unless you found a breach list posted on the open internet... even if you had the access logs: > 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...
    - jacquesm 8y ago
      That's sort of the point. You can only prove positively that a breach has been exploited because there can be proof of that. But there can never be 100% ironclad proof that it wasn't exploited.
  - tyingq 8y ago
    Well a little bit of detail as to whether exploiting this bug even creates a log entry might be interesting.
tzs 8y ago
> Logs show that it has never been used by anyone 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?
- yebyen 8y ago
  Seems likely they actually didn't. Apparently the further down this comment thread you go, the more times this has already been mentioned. (I read the top comment in the thread having already understood this, and thus interpreted it as a hypothetical question. But in this case, it wasn't provable at all, according to Google themselves' own statement.)
- tptacek 8y ago
  I have no idea, but another thing to consider is that they probably have longer-term access to the binaries of all the applications that ever used this API, and they certainly have tools for automated/large-scale inspection of applications.
  - joshuamorton 8y ago
    One obvious example is that you can continue monitoring for evidence of attempts to use the vulnerability. A delayed honeypot, so to speak. 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.
huy-nguyen 8y ago
Isn’t the news section of the Journal walled off from the editorial section? As a regular reader of the Journal’s news section (but not the editorial), I find its reporting to be quite solid usually.
lurker456 8y ago
Yes, it's been part of the regulations in the EU, even before GDPR. Being forced to disclose in a timely manner ensures it can't be swept under the rug because they squint at the logs just right.
EpicEng 8y ago
>Logs show that it has never been used by anyone. It patches the vulnerability. >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.
justinclift 8y ago
> Logs show that it has never been used by anyone. They don't have log coverage for 90%+ of the time period, so that's not something their logs could even possibly show.
glenrivard 8y ago
What did Google do to piss off Murdoch? Fox News spends most nights railing on Google also.

hoos97 8y ago

Yes, because when you go public with the issue you are able to control the narrative. Bad judgement to assume that these issues will never reach the public eye. Especially knowing that a patched was successfully applied...instead Google looks like it is having trouble living up to it's Don't Be Evil motto.

lostmsu 8y ago
No, they would have to issue like 10 reports a day. Bugs that are never exploited in web sites are rarely published for multiple reasons. Definitely not something to blame Google for.
- hoos97 8y ago
  If it wasn't exploited makes it even better...shows that you are being aggressive in identifying issues and applying corrections. Take advantage of opportunities to show transparency in a good light as well as meet your commitments to be transparent when events have not gone your way. This shouldn't be about how many reports you have to issue. Google can afford the staff to make that happen.
  - SahAssar 8y ago
    That's probably not how end users would see it though. If there was a report every other day that google or facebook found and fixed a security bug people would either ignore it or trust another company that wasn't as open much more.

creaghpatr 8y ago

>PS: Keeping in mind that this is part of the Murdoch vs. Google war going on for about 10 years: Changes the facts of the story 0%

ucaetano 8y ago
Given that nobody here knows the full facts, only the subset of the interpretations published by the WSJ, this is very relevant.
- vatueil 8y ago
  I wish I could trust the WSJ's coverage, but I have to agree that they do seem to have an odd tendency to go off the rails on certain issues. A recent example that comes to mind is their Gmail API article, which at best badly misrepresented the situation: - https://www.wsj.com/articles/techs-dirty-secret-the-app-developers-sifting-through-your-gmail-1530544442 https://www.wsj.com/articles/techs-dirty-secret-the-app-deve... - https://www.androidpolice.com/2018/09/21/opinion-no-one-get-email-apps-gmail-add-ons-work/ 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).

tptacek 8y ago

I don't know if it should or it shouldn't, but it absolutely is not the norm for companies to announce those vulnerabilities publicly. Every year, most moderate-and-up-sized tech companies (really, a pretty big swathe of the Fortune 500 outside tech, as well) contract multiple penetration tests, and those tests turn up thousands upon thousands of sev:hi vulnerabilities, none of which are ever announced. 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.

creaghpatr 8y ago
It's the norm in healthcare (HIPAA), disclosure is required for breaches that affect 500+ persons, and even <500 person breaches have to be reported annually to HHS and to the individual at the time of discovery. https://www.cms.gov/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNProducts/Downloads/HIPAAPrivacyandSecurityTextOnly.pdf https://www.cms.gov/Outreach-and-Education/Medicare-Learning... edit: less-than sign wrong way
- charleselegans 8y ago
  IANAL but it doesn't seem that the way they define a breach (https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html https://www.hhs.gov/hipaa/for-professionals/breach-notificat...) includes issues that provably haven't been exploited.
- dv_dt 8y ago
  That's a requirement in general for CA. https://www.oag.ca.gov/privacy/databreach/reporting 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.
  - russell_h 8y ago
    Is there a required timeframe for doing so?

ocdtrekkie 8y ago

Your statement: "Logs show that it has never been used by anyone." 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."

stochastic_monk 8y ago
“We don’t know of any misuse” is very different from “we know it was not misused”. Thank you for being clear about which statement is true.

thomastjeffery 8y ago

It is generally in the company's best interest to publicly disclose the vulnerability, and its effects. 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.

dx87 8y ago

I think they should announce it. It seems pretty optimistic to have an application with buggy code that exposes user data, yet claim that there is no chance that an error or oversight prevented it from being logged. Saying "if we didn't detect the hack then it didn't happen" doesn't inspire confidence.

kerng 8y ago
Getting insight to all security bugs of all cloud providers could be interesting- it certainly would increase transparency. Companies have security bugs all the time that they fix when found internally without telling anyone.

blihp 8y ago

Unless they are 100% certain it hasn't been exploited, yes. The reputational and legal risk to appearing to not disclose / cover up an issue is far larger than the issue itself. That changes if they are absolutely certain it was not exploited: then it's just a bug that they fixed and there's no impact beyond that.

UncleMeat 8y ago
How many vulns do you think companies find internally daily? Should every vuln be publicized?
- blihp 8y ago
  If they potentially expose sensitive data, yes. Again, if an organization is certain that it hasn't then I'd say no. Sure, certain is a high bar but there's absolutely no way for people to make informed decisions and/or mitigate issues otherwise.
  - candiodari 8y ago
    Okay ... and how to enforce this ? 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.
    - blihp 8y ago
      I'm not advocating any external enforcement action. Merely taking the position that if there's an internal conversation which goes along the lines of 'that vulnerability could have been really bad but based on what information we have it doesn't look like it's been exploited... should we tell anyone?' then the answer should be yes, it should be disclosed. That sounds like pretty much the conversation that happened inside Google only they decided 'no, better not... we might get in trouble'. That's a red flag right there.
  - UncleMeat 8y ago

ben_jones 8y ago

"We made Google+ with privacy in mind and therefore keep this API's log data for only two weeks" Does anyone read the article anymore? Or do they just read it for what they want to see and ignore the rest?

quickben 8y ago

That didn't stop them so far from making everybody else look bad. The latest in Google's unfair competitive practices: "Google discloses Microsoft Edge security flaw before a patch is ready" https://www.theverge.com/2018/2/19/17027138/google-microsoft-edge-security-flaw-disclosure https://www.theverge.com/2018/2/19/17027138/google-microsoft...

DannyBee 8y ago
Having a security disclosure policy and following it to the letter for everyone (including Google) is suddenly an "unfair competitive process".
- deleted 8y ago
  [deleted]
- quickben 8y ago
  Is the security disclosure policy 3 business days? https://www.theverge.com/2013/5/23/4358400/google-engineer-bashes-microsoft-discloses-windows-flaw https://www.theverge.com/2013/5/23/4358400/google-engineer-b... Do you think Google acted in a fair or unfair matter?
  - DannyBee 8y ago
    It's interesting you have to go back to 2013 to find something. 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.
    - quickben 8y ago
      I wasn't going down some reverse chronological timeline. It was in the first page of many of results. About 1,2 and 3, if you would zoom a bit out, you have an advertising company that is, by it's intentional actions, making the rest look bad. Outside of contacting the relevant companies, they don't have to push the exploits to the world, yet they do. The rest is just how one spins the story depending on the size of the paycheck received from Google. There is nothing left to conclude, I am out of this thread.

craftyguy 8y ago

> Logs show that it has never been used by anyone 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.

notatoad 8y ago
a vulnerability that allows some unauthorized access to user data via the API and a vulnerability that allows edting logs are very different types of vulnerabilities.
- craftyguy 8y ago
  Well, the comment I was responding to didn't specify: > Company finds a security vulnerability caused by a bug Remote execution vulnerabilities do exist..
  - puzzle 8y ago
    The logs live somewhere else. If you had some magic exploit that let you run code on Google systems AND delete logs, you could do much more damaging things than just reading G+ data.
    - deleted 8y ago
      [deleted]

lern_too_spel 8y ago

> Logs show that it has never been used by anyone. 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.

394549 8y ago

> Company finds a security vulnerability caused by a bug. Logs show that it has never been used by anyone. 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.

tyingq 8y ago

"Logs show that it has never been used by anyone" 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.

jacquesm 8y ago
You can't prove a negative. All you can do is hope that your logs are not tampered with and that they show that nobody used the hole that you are aware of.
- yebyen 8y ago
  I don't know how you could prove whether anyone exploited this or not, unless you found a breach list posted on the open internet... even if you had the access logs: > 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...
  - jacquesm 8y ago
    That's sort of the point. You can only prove positively that a breach has been exploited because there can be proof of that. But there can never be 100% ironclad proof that it wasn't exploited.
- tyingq 8y ago
  Well a little bit of detail as to whether exploiting this bug even creates a log entry might be interesting.

tzs 8y ago

> Logs show that it has never been used by anyone 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?

yebyen 8y ago
Seems likely they actually didn't. Apparently the further down this comment thread you go, the more times this has already been mentioned. (I read the top comment in the thread having already understood this, and thus interpreted it as a hypothetical question. But in this case, it wasn't provable at all, according to Google themselves' own statement.)
tptacek 8y ago
I have no idea, but another thing to consider is that they probably have longer-term access to the binaries of all the applications that ever used this API, and they certainly have tools for automated/large-scale inspection of applications.
- joshuamorton 8y ago
  One obvious example is that you can continue monitoring for evidence of attempts to use the vulnerability. A delayed honeypot, so to speak. 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.

huy-nguyen 8y ago

Isn’t the news section of the Journal walled off from the editorial section? As a regular reader of the Journal’s news section (but not the editorial), I find its reporting to be quite solid usually.

lurker456 8y ago

Yes, it's been part of the regulations in the EU, even before GDPR. Being forced to disclose in a timely manner ensures it can't be swept under the rug because they squint at the logs just right.

EpicEng 8y ago

>Logs show that it has never been used by anyone. It patches the vulnerability. >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.

justinclift 8y ago

> Logs show that it has never been used by anyone. They don't have log coverage for 90%+ of the time period, so that's not something their logs could even possibly show.

glenrivard 8y ago

What did Google do to piss off Murdoch? Fox News spends most nights railing on Google also.