Senators Demand Google Hand Over Internal Memo Urging Google+ Cover-Up
zdnet.com
zdnet.com
That's a loaded first sentence. Here's another way of writing it: "Three Republican senators have sent a letter to Google today asking the company to please provide internal memo based on which Google decided to not disclose a Google+ bug that could have leaked data instead of going public as very few companies would."
Or break it up if that's too wordy. ZDNet and the writer of this article should be ashamed of themselves. How much more clearly can you out yourself as biased garbage?
To the contents of the letter itself [0], just answer the 8 questions straight up, and give the memo. Doesn't appear like a witch hunt quite yet. On questions 3, 4, and 5 just make it clear that software bugs are rampant, many have the ability to get bad things when exploited, and on 6 either inundate them with a deluge of security bugs or explain that there are probably thousands. On #7, the answer better be an emphatic "yes" or I will be very disappointed.
If it becomes more political, there needs to be legal requirements for disclosing all security vulns (instead of just exploited ones) or they need to recognize it's untenable to ask for them. Can't have it both ways and just pick a company's vuln because of an article about them and not ask other companies for theirs.
0 (PDF) - https://www.commerce.senate.gov/public/_cache/files/4852b311...
Are you really surprised, or are you just pretending to be?
This is par for the course for every major journalism outfit - from Fox to MSNBC down to NPR and PBS. There isn't a single major outlet, irrespective of funding model or platform, that isn't blatantly biased.
Biased based on your opinion.
I personally think this is a very big deal and I don't see anything wrong in that sentence. If you think Google is innocent, just look at the facts.
1) They had an internal memo discouraging public disclosure. 2) They only came clean with the leak after WSJ reached out for comment before the publication of a story. 3) They buried the "leak" announcement in a gigantic blog post. The blog post was meant to announce a new project, but about halfway through the middle they disclosed a data-leaking bug. I'd say the tone of the article is in response to Google's observed and recorded actions.
Yeah, I'd say the article and letter's tone is just about right.
That an article needs a "tone", and that it's right/wrong based on how big of a deal the reader thinks it is, is the issue. I await robot news that is a bulleted list of facts. We could argue about fact selection/placement, but I'll take that over arguing a particular organization's collective side of the bed they wake up on.
To your point, we disagree there wrt internal discussions of disclosure. What will be real scary is when there is a chilling effect to even performing rational discussion around these things. There is no such thing as disclose all, and when there is no such thing as talking about it either, you'll wish these rules were codified in law instead of applied selectively to issues you are ok with.
Interesting that you mention this, I'm not convinced that this will be a silver bullet. A couple of concerns that come to mind:
1. Something must bridge the robot to the physical world. The selection of which facts to include and exclude in this data source can create bias.
2. From the data source, the robot then would make its own decision about to to present facts, presumably performing some filtration of its own. Such a robot can have bias [0].
To be clear, I definitely agree that robojournalism could be an improvement. But we can't forget how it works and how it could be manipulated.
[0] - For example http://blog.conceptnet.io/posts/2017/how-to-make-a-racist-ai...
I await robot news that is a bulleted list of facts.
cat news.txt | sed 's/\. /.\n * Reportedly, /'All bias is based on opinion.
It's possible for everyone making a comment, including you and I, to be biased. In fact, in any political argument the chances that a commenter is unbiased are vanishingly small.
You have your bias. Kodablah has his/her own bias. There's nothing wrong with that. It certainly doesn't negate either of your arguments. Kodablah's point remains just as valid to consider.
First, there's no evidence to date that the vulnerability in question actually resulted in a data breach. This is distinct from there being actual, affirmative evidence supporting the idea that there was a breach. Here, I am using "vulnerability" to mean there was potential for exploitation and "breach" to mean an actual exploitation and exfiltration of data. I understand that some might opt regard this as a distinction without difference.
Second, it is not a common practice to make a loud media-friendly disclosure of every potentially-exploitable vulnerability. I've personally closed dozens of vulnerabilities, potentially exploitable vulnerabilities, in a variety of software packages for a variety of companies over the past decade. Of these, exactly one turned into a public notification of any sort. Hosted service companies in particular are unlikely to create what they would view as an undue media circus around bugs they find and fix internally.
With these items in mind, I submit that some people might find it reasonable that the phrasing of the article and the factual claims it makes might be at the very least unfair and potentially possessed of an opportunity to come into greater alignment with evidence-based reality.
That said, it might be slightly less than maximally honest for press outlets to claim that the one scenario is factually identical to the other to a public that is ill-equipped to appreciate the point you have so wisely made.
At this juncture, I think it's fair to say that Google's internal worries about public response were well-founded. They're being publicly crucified for going above and beyond the common standards of responsible behavior here.
Any other topic or company: the wording or journalistic techniques are an unimportant aside, if they get mentioned at all.
I don't have confidence that their staff don't have direct access to their accounts, their passwords are remotely strong, or they have any real OpSec. Hopefully, they have been forced to use something resembling 2FA.
Of course we can pick and choose analogies (hint: we'll never get it right, but that's what happens when comparisons are asked for). But if we're asking for disclosures for security holes that could lead (or have lead) to unauthorized access, I expect to see a seemingly interminable list.
But the users whose data was emitted should have been immediately notified. That's (a) law in some places, (b) common decency if one party holds another's PII and then fails to keep it private.
If we’re still talking about the same bug… I thought that there was no evidence that anybody’s data was exfiltrated through this vulnerability? Granted, absence of evidence is not evidence of absence, but who, exactly, are you saying should be notified?
I would say yes, if some person’s PII data was improperly disclosed, yes, disclose the breach to that person. But if there is not any evidence that some particular person’s data was exposed here, do you go around telling people that their data “could have” been accessed, “if”?
Physical security analogy—let’s say I found out that the window was unlocked. It’s been unlocked for three years, and I pull security tapes. Nobody is on tape coming in through the window, but the old tapes have been erased. I don’t have any evidence that anybody came in through the window, and yet I can’t disprove it either.
If you go too hard towards forcing disclosures you get pathological incentives to not retain the logs in the first place, the same way people at large companies these days will keep some discussions out of email so they can’t get subpoenaed. That’s not an excuse for bad behavior, but if you force companies to retain more logs for audit purposes, and you force companies to have PII retention policies that limit the retention period, you can easily force a company into a position where the cheapest way out is to reduce the detail in the logs to the point where they’re not useful for security audits any more (if this has the primary purpose of PII retention compliance).
And you're ignoring the biggest risk here. If this defense of claiming 'we see there was a trivially exploited issue to allow unauthorized access to data users had marked as private, but we threw away all logs so we can't be expected to see if it was exploited, or be held to any level of accountability' passes for acceptable, it's going to set a far worse precedent than any sort of legal action. Get hacked? Worried about regulatory requirements? No problem, just migrate to a two week cycle of completely deleting all logs, patch it, and stall for 2 weeks. There, you can now hoenstly say you have 'no evidence this attack ever happened.'
With that said, I don't think any of these require notification in the event of the abstract possibility, unsupported by any evidence, of a data breach. This is because there is a substantial difference between data that was emitted (factually sent somewhere) and exposed (could have been sent somewhere), and laws tend to trigger on the former.
If you're aware of relevant laws I have missed, I would love to know!
Basically you have to conduct an internal risk evaluation and depending on the overall risk assessment, you need or don't need to publicly report on it. Of course the bar is much lower than 'certain data leak'.
Try and name one company that reports all their bugs (security/non security) discovered internally.
People keep saying that there are certain kinds of companies where you have to disclose, and I have come to the conclusion that they are simply making that up because it sounds good to them.
Whether the vulnerability was discovered internally or not, they were leaking people's data, and the responsible thing to do is tell them. Even if it's only a possibility, people have the right to know.
The only question left is who was affected, and Google doesn't know because they deleted the logs. The responsible thing to do would be notify everybody using that part of the service.
The difference is between data being exposed and data being leaked. The difference is quite critical.
In any case, I don't believe their answer. Once the API response leaves the server with extra information there's no way for them to know which fields the caller looked at because it's all done client side.
They didn't say that, they stated that in the logs they had, which were not fully comprehensive, there was no evidence of abuse.
> am not sure how they are making the claim that their API was not abused.
They didn't claim this.
But one could, for example, set up a honeypot and monitor any suspicious activity going forward, then if anyone attempted to abuse the vulnerability before it was publicized, they would know it might have been abused, but lack of use over a long timescale could give reasonable certainty that no one took advantage of the vuln.
(I work at Google, but not on G+ and not on security).
Can you cover-up legal activity? No, of course not..non-story here