US senator urges investigation into Google+ bug ‘coverup’(sociable.co)
sociable.co
US senator urges investigation into Google+ bug ‘coverup’
https://sociable.co/business/us-senator-google-coverup/
84 comments
> Tens of thousands are found every year by internal teams and contractors at companies around the country
It's fair to say "Google followed current best practice." It's not fair to say "current practice is how it should always be."
What is acceptable for a company selling razors to Minessotans may not be for a behemoth with troves of personal data on every American. The question, "should Google have heightened disclosure requirements around confirmed and potential breaches," is not invalid.
It's fair to say "Google followed current best practice." It's not fair to say "current practice is how it should always be."
What is acceptable for a company selling razors to Minessotans may not be for a behemoth with troves of personal data on every American. The question, "should Google have heightened disclosure requirements around confirmed and potential breaches," is not invalid.
The link I posted does a better job of directly addressing that argument than I could do by retyping it here.
So the argument in the linked article is this:
"A mandate to disclose internal vulnerabilities would change incentives. Firms would have a reason not to want to find vulnerabilities."
My problem with this thinking is that it could be extended to finding breaches. If you have to publish every breach you're not going to want to find them.
It's impossible to prove that a vulnerability has not resulted in a breach and so an argument could be made that every vulnerability has to be considered a breach.
That would not be very pragmatic though, especially if we also take the view that every bug is a vulnerability (as the linked article does).
I think if the ultimate goal is to protect users, we can't be dogmatic or formalistic about which incidents to publish. It has to depend on the likelihood and the severity of any damage.
If a vulnerability concerns highly sensitive data and we don't know whether or not there was a breach then users should be told about the incident so they can protect themselves or change their behaviour in the future.
I also think that in this particular event Google tried to downplay the likelihood of a breach. Bad idea.
"A mandate to disclose internal vulnerabilities would change incentives. Firms would have a reason not to want to find vulnerabilities."
My problem with this thinking is that it could be extended to finding breaches. If you have to publish every breach you're not going to want to find them.
It's impossible to prove that a vulnerability has not resulted in a breach and so an argument could be made that every vulnerability has to be considered a breach.
That would not be very pragmatic though, especially if we also take the view that every bug is a vulnerability (as the linked article does).
I think if the ultimate goal is to protect users, we can't be dogmatic or formalistic about which incidents to publish. It has to depend on the likelihood and the severity of any damage.
If a vulnerability concerns highly sensitive data and we don't know whether or not there was a breach then users should be told about the incident so they can protect themselves or change their behaviour in the future.
I also think that in this particular event Google tried to downplay the likelihood of a breach. Bad idea.
The difference between internal work to find vulnerabilities and breach response is that one is optional and the other effectively isn't. There are incentives at play in breach response as well, but they are attenuated.
And, again: so far as anyone knows, there was no breach. All software is in a continuous state of "likely breach". But words mean things: a breach happens when a vulnerability is exploited maliciously, not when it's discovered.
And, again: so far as anyone knows, there was no breach. All software is in a continuous state of "likely breach". But words mean things: a breach happens when a vulnerability is exploited maliciously, not when it's discovered.
I didn't dispute the meaning of the words, and I agree that making internally discovered vulnerabilities public should be (legally) optional.
But that raises the question which ones should and which ones shouldn't be disclosed.
In my opinion, knowing for sure that there was a breach is not the right threshold in all cases.
A high profile public API that had a glaring vulnerability for years seems far more likely to have been breached than most other software.
Also, the more high profile the software the greater the reputational risk of being wrong.
What if the bug gets leaked eventually? What if there was in fact a breach and it only becomes known later when people have already suffered the consequences?
If that happens, people will question the decision not to publish and the damage to trust will be far greater. This has to be factored into the incentive structure of any disclosure or non-disclosure.
I think the best course of action is to routinely disclose all vulnerabilities but not necessarily alert all end-users to all vulnerabilities.
But that raises the question which ones should and which ones shouldn't be disclosed.
In my opinion, knowing for sure that there was a breach is not the right threshold in all cases.
A high profile public API that had a glaring vulnerability for years seems far more likely to have been breached than most other software.
Also, the more high profile the software the greater the reputational risk of being wrong.
What if the bug gets leaked eventually? What if there was in fact a breach and it only becomes known later when people have already suffered the consequences?
If that happens, people will question the decision not to publish and the damage to trust will be far greater. This has to be factored into the incentive structure of any disclosure or non-disclosure.
I think the best course of action is to routinely disclose all vulnerabilities but not necessarily alert all end-users to all vulnerabilities.
I don't know where to start with this, so I'll just shotgun my answers:
* The vulnerability we're talking about, like all G+ vulnerabilities, has no half-life. It's fixed decisively the instant they deploy the fix to prod. There is no user response we're looking for to mitigate the vulnerability.
* The incentive problem isn't eliminated just because you only target Google with the new norm. When we demand that "high-profile" companies disclose vulnerabilities, we create the sentiment, across the industry and in low-profile companies as well, that vulnerability discovery is a bad event, to be avoided. The exact opposite thing is true.
* Internal vulnerabilities in high-profile applications are discovered so often that people will quickly tune them out (until someone sets out to take a scalp). It could even wind up benefiting companies with actual breaches, whose announcements will be lost in the noise, and more easily PR-spun.
The basic problem here is very simple: found- and- fixed vulnerabilities aren't breaches. A vulnerability and its successful exploitation are not the same thing. It does not matter if the vulnerability is "leaked eventually", so long as it's fixed when it's found.
If Google had discovered this vulnerability and then just decided to ignore it for 6 months, that would be a story. That's not what happened.
* The vulnerability we're talking about, like all G+ vulnerabilities, has no half-life. It's fixed decisively the instant they deploy the fix to prod. There is no user response we're looking for to mitigate the vulnerability.
* The incentive problem isn't eliminated just because you only target Google with the new norm. When we demand that "high-profile" companies disclose vulnerabilities, we create the sentiment, across the industry and in low-profile companies as well, that vulnerability discovery is a bad event, to be avoided. The exact opposite thing is true.
* Internal vulnerabilities in high-profile applications are discovered so often that people will quickly tune them out (until someone sets out to take a scalp). It could even wind up benefiting companies with actual breaches, whose announcements will be lost in the noise, and more easily PR-spun.
The basic problem here is very simple: found- and- fixed vulnerabilities aren't breaches. A vulnerability and its successful exploitation are not the same thing. It does not matter if the vulnerability is "leaked eventually", so long as it's fixed when it's found.
If Google had discovered this vulnerability and then just decided to ignore it for 6 months, that would be a story. That's not what happened.
>The basic problem here is very simple: found- and- fixed vulnerabilities aren't breaches.
What makes this less than simple is that we may not know whether or not a particular vulnerability was exploited (i.e if a breach has occurred).
My opinion is that the likelihood of an undiscovered breach and the potential damage of any such breach should be taken into account when deciding whether or not to disclose a particular vulnerability.
>The incentive problem isn't eliminated just because you only target Google with the new norm.
I have no interest in targeting Google specifically (I'm actually a shareholder). They just happen to be big and have a lot of personal data. They are in the crosshairs of regulators and politicians as well, which is another reason to err on the side of transparency.
I'm also not trying to eliminate the incentive problem by limiting it to Google (or other big companies). On the contrary, my opinion is that disclosing vulnerabilities in a timely fashion should be seen as building trust and become the new normal. Making it the new normal is what should fix the incentive problem over time as people get used to it.
People tuning out is not a bad thing. The difference between an actual breach and a fixed vulnerability will not be lost just because vulnerabilities are no longer kept secret.
But as I said, I don't think end-users should be notified of every single vulnerability.
What makes this less than simple is that we may not know whether or not a particular vulnerability was exploited (i.e if a breach has occurred).
My opinion is that the likelihood of an undiscovered breach and the potential damage of any such breach should be taken into account when deciding whether or not to disclose a particular vulnerability.
>The incentive problem isn't eliminated just because you only target Google with the new norm.
I have no interest in targeting Google specifically (I'm actually a shareholder). They just happen to be big and have a lot of personal data. They are in the crosshairs of regulators and politicians as well, which is another reason to err on the side of transparency.
I'm also not trying to eliminate the incentive problem by limiting it to Google (or other big companies). On the contrary, my opinion is that disclosing vulnerabilities in a timely fashion should be seen as building trust and become the new normal. Making it the new normal is what should fix the incentive problem over time as people get used to it.
People tuning out is not a bad thing. The difference between an actual breach and a fixed vulnerability will not be lost just because vulnerabilities are no longer kept secret.
But as I said, I don't think end-users should be notified of every single vulnerability.
Any response I could write to this would just be repeating things I said previously.
> The link I posted does a better job of directly addressing that argument than I could do by retyping it here
An argument that wouldn't have been made if we weren't having this discussion. I'm not saying Google messed up. I'm simply defending the debate.
An argument that wouldn't have been made if we weren't having this discussion. I'm not saying Google messed up. I'm simply defending the debate.
I'm sorry, I can't follow your argument at this point. In what way do you disagree with the points I made in the post I linked?
The law need not match your personal idea of morality. We have religion if you want to live by someone else's moral code.
> The law need not match your personal idea of morality
Agreed. But it should reflect our collective views. The process for finding that collective agreement is discussion.
Judicial proceedings are based on law, not morals. Legislative proceedings consider morality. If something shouldn’t happen but does, we can address that through the law.
Agreed. But it should reflect our collective views. The process for finding that collective agreement is discussion.
Judicial proceedings are based on law, not morals. Legislative proceedings consider morality. If something shouldn’t happen but does, we can address that through the law.
> What an embarrassment. Blumenthal should leave the performative infosec policymaking to his colleague Ron Wyden.
Blumenthal is also the senator behind the abomination that is SESTA[0]. He's an opportunistic scumbag - it's not that he's simply ignorant about technology; he's actively malevolent and uses his knowledge to that effect.
[0] https://www.eff.org/deeplinks/2018/03/how-congress-censored-...
Blumenthal is also the senator behind the abomination that is SESTA[0]. He's an opportunistic scumbag - it's not that he's simply ignorant about technology; he's actively malevolent and uses his knowledge to that effect.
[0] https://www.eff.org/deeplinks/2018/03/how-congress-censored-...
This is not as black and white as you portray it.
1. They don't actually know if the breach was exploited, because of the limited log window.
2. It appears that Google intentionally avoided the congressional hearings last month because of this breach, if they asked a question such as "are there any other incidents you have not disclosed" they would have had to either perjure themselves or kick off a PR fiasco in front of lots of TV cameras in real time. When you're evading authorities because of an incident like this it's far worse than any hack itself.
Maybe it is high time for software companies to start disclosing internal vulnerabilities (whether they can demonstrate it has been exploited or not) in light of the massive, worldwide societal impact these companies now have.
People everywhere should be mad as hell that these mega corporations are so powerful that they regularly evade oversight to continue building their monopolies. It's not about disruption or innovation anymore, it's become something far more evil.
1. They don't actually know if the breach was exploited, because of the limited log window.
2. It appears that Google intentionally avoided the congressional hearings last month because of this breach, if they asked a question such as "are there any other incidents you have not disclosed" they would have had to either perjure themselves or kick off a PR fiasco in front of lots of TV cameras in real time. When you're evading authorities because of an incident like this it's far worse than any hack itself.
Maybe it is high time for software companies to start disclosing internal vulnerabilities (whether they can demonstrate it has been exploited or not) in light of the massive, worldwide societal impact these companies now have.
People everywhere should be mad as hell that these mega corporations are so powerful that they regularly evade oversight to continue building their monopolies. It's not about disruption or innovation anymore, it's become something far more evil.
I don't think we're going to get anywhere if you casually use the word "breach" to describe the discovery, by a firm's own security team, of a security vulnerability and its subsequent fix. I can't write a better rebuttal to your comment than I already did in the post I linked at the root of the thread.
> It is not and never has been a norm for SAAS vendors to disclose internal vulnerabilities that have not been discovered independently by third parties.
The bug sounds like it would need reporting to a data protection authority under the GDPR, which doesn't make a distinction on who discovered the breach. But I'm not sure if the fact that there is no evidence of the bug being abused means they didn't need to report after all.
The bug sounds like it would need reporting to a data protection authority under the GDPR, which doesn't make a distinction on who discovered the breach. But I'm not sure if the fact that there is no evidence of the bug being abused means they didn't need to report after all.
Someone claimed this on Twitter, so I took the time to finally read through the GDPR to validate the claim, and I don't find anything anywhere that requires the discovery of a vulnerability --- at all, by anyone --- to prompt a report to an external authority. I didn't look very hard, but maybe you can point me at it?
GDPR is clear about breach reporting, that is true. But a vulnerability is not a breach.
GDPR is clear about breach reporting, that is true. But a vulnerability is not a breach.
With a bit of searching I found "Guidelines on Personal data breach notification under Regulation 2016/679"[1] which states:
> Although the GDPR introduces the obligation to notify a breach, it is not a requirement to do so in all circumstances: > - Notification to the competent supervisory authority is only triggered where a breach is likely to result in a risk to the rights and freedoms of individuals. > - Communication of a breach to the individual is only triggered where it is likely to result in a high risk to their rights and freedoms.
After some clarification, it also states:
> Regardless of whether or not a breach needs to be notified to the supervisory authority, the controller must keep documentation of all breaches, as Article 33(5) explains: > “The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article.” > This is linked to the accountability principle of the GDPR, contained in Article 5(2). Controllers are therefore encouraged to establish an internal register of breaches, regardless of whether they are required to notify or not.
So the answer seems to be "it depends". But when Google says "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." I'd argue it's better to err on the side of caution and report it.
[1]: http://ec.europa.eu/newsroom/document.cfm?doc_id=47741
> Although the GDPR introduces the obligation to notify a breach, it is not a requirement to do so in all circumstances: > - Notification to the competent supervisory authority is only triggered where a breach is likely to result in a risk to the rights and freedoms of individuals. > - Communication of a breach to the individual is only triggered where it is likely to result in a high risk to their rights and freedoms.
After some clarification, it also states:
> Regardless of whether or not a breach needs to be notified to the supervisory authority, the controller must keep documentation of all breaches, as Article 33(5) explains: > “The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article.” > This is linked to the accountability principle of the GDPR, contained in Article 5(2). Controllers are therefore encouraged to establish an internal register of breaches, regardless of whether they are required to notify or not.
So the answer seems to be "it depends". But when Google says "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." I'd argue it's better to err on the side of caution and report it.
[1]: http://ec.europa.eu/newsroom/document.cfm?doc_id=47741
All of those excerpts refer to breaches, not vulnerabilities. Vulnerabilities aren't breaches, either in common parlance or as a term of art.
The distinction the GDPR is making here is between intrusions that don't include exfiltration of data (ie, what happens when most teenager hackers break into something for the sport of it) and those that do.
The distinction the GDPR is making here is between intrusions that don't include exfiltration of data (ie, what happens when most teenager hackers break into something for the sport of it) and those that do.
In plain English a breach is the hole in ones defenses. To breach is to take advantage of a breach or to create a breach. So "breach reporting" could be read either way.
Like you, I've only ever seen it read in the verbal sense, but that isn't obviously correct.
Edit: expanded definition of breach.
Like you, I've only ever seen it read in the verbal sense, but that isn't obviously correct.
Edit: expanded definition of breach.
Sorry, but you can't simply change the definition of "breach" to include "all vulnerabilities" and then charge Google with covering up your new supposed "breach". By that definition, practically every company in the world is constantly covering up breaches. You can say, "yes, they are", but at that point in the discussion the GDPR is out the window.
I didn't change anything. I pointed out a fact.
According to UK Data Protection Authority:
> A personal data breach can be broadly defined as a security incident that has affected the confidentiality, integrity or availability of personal data. In short, there will be a personal data breach whenever any personal data is lost, destroyed, corrupted or disclosed; if someone accesses the data or passes it on without proper authorisation; or if the data is made unavailable, for example, when it has been encrypted by ransomware, or accidentally lost or destroyed.
https://ico.org.uk/for-organisations/guide-to-the-general-da...
The wording around data breach is quite specific i.e. "security incident that has affected ...".
They also give 6 examples:
- access by an unauthorised third party;
- deliberate or accidental action (or inaction) by a controller or processor;
- sending personal data to an incorrect recipient;
- computing devices containing personal data being lost or stolen;
- alteration of personal data without permission; and
- loss of availability of personal data.
Quite obviously enforcing disclosing security vulnerabilities was not the main goal of the authority or they would mention it explicitly.
Also, if they would want to process all security vulnerabilities they would need way, way more stuff. Just reporting CVEs (Common Vulnerabilities and Exposures) from products used by all companies would lead to hundreds of millions of reports. CVE list more than 100 000 vulnerabilities * all companies that use these products.
Note that DPAs have issues with processing actual data breaches where numbers are in thousands.
> A personal data breach can be broadly defined as a security incident that has affected the confidentiality, integrity or availability of personal data. In short, there will be a personal data breach whenever any personal data is lost, destroyed, corrupted or disclosed; if someone accesses the data or passes it on without proper authorisation; or if the data is made unavailable, for example, when it has been encrypted by ransomware, or accidentally lost or destroyed.
https://ico.org.uk/for-organisations/guide-to-the-general-da...
The wording around data breach is quite specific i.e. "security incident that has affected ...".
They also give 6 examples:
- access by an unauthorised third party;
- deliberate or accidental action (or inaction) by a controller or processor;
- sending personal data to an incorrect recipient;
- computing devices containing personal data being lost or stolen;
- alteration of personal data without permission; and
- loss of availability of personal data.
Quite obviously enforcing disclosing security vulnerabilities was not the main goal of the authority or they would mention it explicitly.
Also, if they would want to process all security vulnerabilities they would need way, way more stuff. Just reporting CVEs (Common Vulnerabilities and Exposures) from products used by all companies would lead to hundreds of millions of reports. CVE list more than 100 000 vulnerabilities * all companies that use these products.
Note that DPAs have issues with processing actual data breaches where numbers are in thousands.
In common English, a breach is the damage left be an attack (often a hole in the case of penetrating ordinance, as in "a breach in the hull of a ship"). Breach definitely does not, in common English, refer to a theoretical, unexploited hole in one's defenses. I would be interested if you could point out any instance in literature or professional writing where it is used that way.
Also common English is notoriously unimportant when arguing over legal definitions, so this is all beside the point.
Also common English is notoriously unimportant when arguing over legal definitions, so this is all beside the point.
No.
A breach is when data actually escapes.
A breach is when data actually escapes.
The difference between a breach and a independent discovery is utilization by third parties. Through logging and other measures one can often determine whether exploits have been utilized to engage unauthorized access. Google's defense in this case is not good. They are simply claiming ignorance. 'We don't have any idea if this exploit was utilized, as we were not logging access to the privileged information.' It really defies belief that Google, who's entire business is based on data, would not be logging access to confidential user information (even by the users' themselves). But it's an issue whether true or false. If true it means Google was and/or is likely engaging in poor security practice. If false, it's far worse as it means not only was user information likely accessed by parties that should not have had access to it, but it would also mean that Google then lied about this. An investigation is wholly justified here.
This is word salad. In fact, Google is engaging in excellent security practice. They re-audited an application, found a minor vulnerability, and fixed it. Most tech companies don't do any of this.
Didn't the WSJ say that Google shut down G+ in response to this vulnerability? Would it be fair to say "They re-audited an application, found a minor vulnerability, and fixed it, decided the impact was so severe that G+ should not exist anymore"?
No! That is not at all a fair read, even if you take the statement at face value, which nobody does. What they're saying is that they audited the application, found a vulnerability, and then re-evaluated the project in light of its importance to the company and commercial prospects, and decided that the work required to keep maintaining and securing it to the standard they had set for themselves --- again, a standard far higher than most tech companies --- wasn't justified by the returns they'd get on the investment. Better to stop doing it at all than to gradually slide into doing it half-assed.
I think the biggest tell here was that Google had discussed disclosing it, and chose not to out of fear of regulation and bad press. This wasn't an everyday internal vulnerability. And they have no proof it wasn't used. But they chose to keep it secret specifically because they were afraid of the backlash, and the fact that it would demonstrate their security wasn't significantly different from Facebook's, it was just that they had a vastly less successful product.
Their decision wasn't about what was best for users, it was about what they thought they could get away with. I'm not shocked Congress is interested in that, because the memo is far more condemning than anything about the actual bug.
As an additional note, we can't rely on Ron Wyden to keep Google in check: Google is one of his larger sponsors, spending somewhere around $20,000 a year on him.
Their decision wasn't about what was best for users, it was about what they thought they could get away with. I'm not shocked Congress is interested in that, because the memo is far more condemning than anything about the actual bug.
As an additional note, we can't rely on Ron Wyden to keep Google in check: Google is one of his larger sponsors, spending somewhere around $20,000 a year on him.
Companies find RCE and SQLI, fix them, don't conduct gigantic forensics investigations to determine if they'd ever been exploited, and get on with their lives. It happens routinely. What's so interesting about this bug? Did you read the details about it? I wasn't kidding when I called it a sev:low.
I don't think people at Google would agree with that characterization, given that they decided to couple it's disclosure with shutting down the whole product.
How would you characterize this versus the data leak used by Cambridge Analytica, if you remove the difference in the scale of product users and developers building on the API? Being able to scrape a lot of API data that users explicitly defined as private is a pretty big deal, especially when you consider that Google pretty much forced G+ integration on everyone in the first place, causing them to have accounts they might not even want.
How would you characterize this versus the data leak used by Cambridge Analytica, if you remove the difference in the scale of product users and developers building on the API? Being able to scrape a lot of API data that users explicitly defined as private is a pretty big deal, especially when you consider that Google pretty much forced G+ integration on everyone in the first place, causing them to have accounts they might not even want.
> ...they decided to couple it's disclosure with shutting down the whole product.
Let's not pretend the product was shut down because of this bug. Google Plus was a failed product. This security issue was just a convenient event to which they chose to attach the news.
Google's own words on the matter:
> This review crystallized what we’ve known for a while: that while our engineering teams have put a lot of effort and dedication into building Google+ over the years, it has not achieved broad consumer or developer adoption, and has seen limited user interaction with apps. The consumer version of Google+ currently has low usage and engagement: 90 percent of Google+ user sessions are less than five seconds.[0]
[0] https://www.blog.google/technology/safety-security/project-s...
Let's not pretend the product was shut down because of this bug. Google Plus was a failed product. This security issue was just a convenient event to which they chose to attach the news.
Google's own words on the matter:
> This review crystallized what we’ve known for a while: that while our engineering teams have put a lot of effort and dedication into building Google+ over the years, it has not achieved broad consumer or developer adoption, and has seen limited user interaction with apps. The consumer version of Google+ currently has low usage and engagement: 90 percent of Google+ user sessions are less than five seconds.[0]
[0] https://www.blog.google/technology/safety-security/project-s...
Oh, no doubt G+ was a failure. And that's coming from someone who was with it since its launch and still uses it today.
But it was closed due to this bug and the drama surrounding it. It wasn't "convenient" to announce closure alongside the bug, the bug actually became much more widely discussed because it was attached to a product shutdown. I can't imagine anyone at Google wanted this to go down that way, it would've been better to quietly shutter it at a different time.
But the Wall Street Journal announced it, as part of the memo that they got internally. So Google had to announce it at the same time in the same post, and it was definitely the cause of the product shutdown.
But it was closed due to this bug and the drama surrounding it. It wasn't "convenient" to announce closure alongside the bug, the bug actually became much more widely discussed because it was attached to a product shutdown. I can't imagine anyone at Google wanted this to go down that way, it would've been better to quietly shutter it at a different time.
But the Wall Street Journal announced it, as part of the memo that they got internally. So Google had to announce it at the same time in the same post, and it was definitely the cause of the product shutdown.
For starters, the Cambridge Analytica leak was vastly more impactful than this one, and is known to have been actually exploited?
I feel in this thread sort of like how I do in those bug bounty threads where someone is trying to convince me that a logout CSRF should merit a $10,000 payout because a competitor could use it to make a UX experience worse and then shift all the customers to their product and after all Google is such a huge company they shouldn't have CSRF at all and $10,000 is a drop in the bucket.
I mean that's not what you're saying but I feel like we're playing Six Degrees Of Kevin Bacon the same way to get from this very marginal bug that they themselves found and fixed to "this merits federal legislative attention."
I feel in this thread sort of like how I do in those bug bounty threads where someone is trying to convince me that a logout CSRF should merit a $10,000 payout because a competitor could use it to make a UX experience worse and then shift all the customers to their product and after all Google is such a huge company they shouldn't have CSRF at all and $10,000 is a drop in the bucket.
I mean that's not what you're saying but I feel like we're playing Six Degrees Of Kevin Bacon the same way to get from this very marginal bug that they themselves found and fixed to "this merits federal legislative attention."
> How would you characterize this versus the data leak used by Cambridge Analytica...
That wasn't a leak as much as misusing data that FB happily gave out to anyone who asked -- which FB "disclosed" to great fanfare during the Obama presidential run to show how they could be leveraged for more than looking at pictures of your former college roommate's cat.
That wasn't a leak as much as misusing data that FB happily gave out to anyone who asked -- which FB "disclosed" to great fanfare during the Obama presidential run to show how they could be leveraged for more than looking at pictures of your former college roommate's cat.
Sure. First hold Equifax accountable, then we'll talk about Google.
Half the job of a politician is to get re-elected. This is part of that half. There's outrage and standing up for the people against a big company. Someone will be dragged before Congress and get embarrassed publically. And then we move on.
This reminded me of a story:
In an op-ed promoting campaign finance reform, the Oracle of Omaha, Warren Buffett, proposed raising the limit on individual contributions from $1,000 to $5,000 and banning all other contributions. No corporate money, no union money, no soft money. It sounds great, except that it would never pass.
Campaign finance reform is so hard to pass because the incumbent legislators who have to approve it are the ones who have the most to lose. Their advantage in fundraising is what gives them job security. How do you get people to do something that is against their interest? Put them in what is known as the prisoners’ dilemma. According to Buffett:
Well, just suppose some eccentric billionaire (not me, not me!) made the following offer: If the bill was defeated, this person—the E.B.—would donate $1 billion in an allowable manner (soft money makes all possible) to the political party that had delivered the most votes to getting it passed. Given this diabolical application of game theory, the bill would sail through Congress and thus cost our E.B. nothing (establishing him as not so eccentric after all).
Consider your options as a Democratic legislator. If you think that the Republicans will support the bill and you work to defeat it, then if you are successful, you will have delivered $1 billion to the Republicans, thereby handing them the resources to dominate for the next decade. Thus there is no gain in opposing the bill if the Republicans are supporting it. Now, if the Republicans are against it and you support it, then you have the chance of making $1 billion.
Thus whatever the Republicans do, the Democrats should support the bill. Of course, the same logic applies to the Republicans. They should support the bill no matter what the Democrats do. In the end, both parties support the bill, and our billionaire gets his proposal for free. As a bonus, Buffett notes that the very effectiveness of his plan “would highlight the absurdity of claims that money doesn’t influence Congressional votes.”
This situation is called a prisoners’ dilemma because both sides are led to take an action that is against their mutual interest. In the classic version of the prisoners’ dilemma, the police are separately interrogating two suspects. Each is given an incentive to be the first to confess and a much harsher sentence if he holds out while the other confesses. Thus each finds it advantageous to confess, though they would both do better if each kept quiet.
From the book The Art of Strategy. Great book.
In an op-ed promoting campaign finance reform, the Oracle of Omaha, Warren Buffett, proposed raising the limit on individual contributions from $1,000 to $5,000 and banning all other contributions. No corporate money, no union money, no soft money. It sounds great, except that it would never pass.
Campaign finance reform is so hard to pass because the incumbent legislators who have to approve it are the ones who have the most to lose. Their advantage in fundraising is what gives them job security. How do you get people to do something that is against their interest? Put them in what is known as the prisoners’ dilemma. According to Buffett:
Well, just suppose some eccentric billionaire (not me, not me!) made the following offer: If the bill was defeated, this person—the E.B.—would donate $1 billion in an allowable manner (soft money makes all possible) to the political party that had delivered the most votes to getting it passed. Given this diabolical application of game theory, the bill would sail through Congress and thus cost our E.B. nothing (establishing him as not so eccentric after all).
Consider your options as a Democratic legislator. If you think that the Republicans will support the bill and you work to defeat it, then if you are successful, you will have delivered $1 billion to the Republicans, thereby handing them the resources to dominate for the next decade. Thus there is no gain in opposing the bill if the Republicans are supporting it. Now, if the Republicans are against it and you support it, then you have the chance of making $1 billion.
Thus whatever the Republicans do, the Democrats should support the bill. Of course, the same logic applies to the Republicans. They should support the bill no matter what the Democrats do. In the end, both parties support the bill, and our billionaire gets his proposal for free. As a bonus, Buffett notes that the very effectiveness of his plan “would highlight the absurdity of claims that money doesn’t influence Congressional votes.”
This situation is called a prisoners’ dilemma because both sides are led to take an action that is against their mutual interest. In the classic version of the prisoners’ dilemma, the police are separately interrogating two suspects. Each is given an incentive to be the first to confess and a much harsher sentence if he holds out while the other confesses. Thus each finds it advantageous to confess, though they would both do better if each kept quiet.
From the book The Art of Strategy. Great book.
[deleted]
Wow. That sounds both brilliant and diabolical. But what stops politicians from flipping the switch again? Just that they have large coffers? Somehow I'm not convinced any amount of money would satisfy them.
> How do you get people to do something that is against their interest?
You remove them from the system. This is why we have a process through which the states can amend the Constitution.
You remove them from the system. This is why we have a process through which the states can amend the Constitution.
The prisoner's dilemma hinges on lack of communication between the prisoners. In the original scenario, communicating prisoners would both choose to stay silent. In the above scenario, communicating politicians would choose to never let the bill out of committee.
> communicating politicians would choose to never let the bill out of committee
This presumes every politician is equally dependent on outside financing. Self-financed and small-donation financed politicians would be politically incentivized to bunch together and knock the legs out from under the competition's money machine.
Politics is complicated. Condemning campaign finance reform is premature. (Saying it's a tough fight would be accurate.)
This presumes every politician is equally dependent on outside financing. Self-financed and small-donation financed politicians would be politically incentivized to bunch together and knock the legs out from under the competition's money machine.
Politics is complicated. Condemning campaign finance reform is premature. (Saying it's a tough fight would be accurate.)
The only job of a politician is to get elected.
> This is part of that half
The other half, selling proposed legislation to one's own (and one's colleagues') constituents, involves the same process.
The other half, selling proposed legislation to one's own (and one's colleagues') constituents, involves the same process.
whether rightly or wrongly, this is an East Coast Democrat taking a swipe at one of California's most important tax revenue sources. but California is the Democratic Party's heartland.
i'm not trying to make a political statement here, just an observation that the Democratic party is of two minds when it comes to tech nowadays. it didn't used to be this way. further evidence of an emerging political realignment.
i'm not trying to make a political statement here, just an observation that the Democratic party is of two minds when it comes to tech nowadays. it didn't used to be this way. further evidence of an emerging political realignment.
May also be evidence of the problem of only having two parties. Surely there's many valid left wing positions worthy of sparring in the political arena.
> First hold Equifax accountable, then we'll talk about Google
They're both screw-ups. If someone breaks into your house, we don't say "first let's solve peace in the Middle East; then we'll talk about your house."
Something being second (or further down the list) doesn't mean it should be ignored. It's just another reason to look at the issue.
Google is more politically vulnerable than Equifax because more people know what it is. That makes it a better whipping boy for getting public support behind any resulting legislation.
They're both screw-ups. If someone breaks into your house, we don't say "first let's solve peace in the Middle East; then we'll talk about your house."
Something being second (or further down the list) doesn't mean it should be ignored. It's just another reason to look at the issue.
Google is more politically vulnerable than Equifax because more people know what it is. That makes it a better whipping boy for getting public support behind any resulting legislation.
What Google did isn't even a scandal. The whole story is "Google fixes security bug". Companies fix bugs all the time without notifying anyone. This is the silliest non-story.
> What Google did isn't even a scandal
There is a case to be made that tech companies hoarding sensitive data should have heightened disclosure requirements around confirmed and potential breaches. It doesn't have to be a public process. But maybe there should be some process.
Regarding "it's just a bug," I personally disagree. A bug that takes down the video player is different from a bug that could expose data. ("Could expose" isn't language we like to use in technology, but the law is fine with such ambiguity.)
Analogy: we don't wait for bridges to fail before giving a damn about the cracks. Google et al have never been treated as critical infrastructure. This is a discussion about whether that should change.
There is a case to be made that tech companies hoarding sensitive data should have heightened disclosure requirements around confirmed and potential breaches. It doesn't have to be a public process. But maybe there should be some process.
Regarding "it's just a bug," I personally disagree. A bug that takes down the video player is different from a bug that could expose data. ("Could expose" isn't language we like to use in technology, but the law is fine with such ambiguity.)
Analogy: we don't wait for bridges to fail before giving a damn about the cracks. Google et al have never been treated as critical infrastructure. This is a discussion about whether that should change.
There's a case to be made, but it's not a good one. Under the proposal you're making, there would be a non-stop firehose of "potential breach" disclosures from every major company. It would provide zero value to the public, who would quickly become inured to such reports. And it would significantly increase the friction involved in doing business.
> the public...would quickly become inured to such reports
Who said mandatory public notices? There are lots of options between staying silent and broadcasting every bug.
Who said mandatory public notices? There are lots of options between staying silent and broadcasting every bug.
I've seen your response to this effect in another branch of this thread. Your suggestions there seemed pretty half-baked and none of them seemed like they would solve any real extant problem.
We need to stop using analogies with hardware. Software is fundamentally different and they don't apply in a lot of cases. And in my opinion this is one of them.
While I agree that not all bugs are the same level of severity, if there is no evidence of abuse of a bug, and it has been fixed, I see no reason to have them disclose it in any way. It would be akin to forcing companies to disclose when they repremand an employee, or when they change an internal HR process to avoid interpersonal problems.
While I agree that not all bugs are the same level of severity, if there is no evidence of abuse of a bug, and it has been fixed, I see no reason to have them disclose it in any way. It would be akin to forcing companies to disclose when they repremand an employee, or when they change an internal HR process to avoid interpersonal problems.
Google is not saying there is no evidence that user information was accessed by third parties. They are claiming that they have no idea and supposedly were not logging access to privileged information. This seems highly questionable. And if this passes for acceptable, it creates a significant incentive for all companies to do away with logging as suddenly they can just claim ignorance on everything.
Actually that's exactly what Google has said. Note that this is different from saying there's positive evidence that no user data was accessed.
Oh, and are we going to be mad at Google for purging logs now? I thought our hobby horse was Google retaining unneeded logs, but I guess it's even more fun to be mad at them for both so we can be mad no matter what they do.
Oh, and are we going to be mad at Google for purging logs now? I thought our hobby horse was Google retaining unneeded logs, but I guess it's even more fun to be mad at them for both so we can be mad no matter what they do.
Google is relentless in collecting data on everybody and everything. Until suddenly collecting data could possibly incriminate them in an action, at which point they suddenly claim to lack any data whatsoever. Occam's razor would indicate that Google is being less than truthful.
Yes, it's bizarre how the media has siezed on the passive mention of a bug patched in a blog post about Google+ that revealed basically no information of value and turned it into a story. I suppose it's just a reminder how little the media, public and of course the gov't understand this industry. Google certainly thought of it as a non issue or they wouldn't have made it an anecdote...
Equifax is arguably a more serious breach, with more obvious problems in security - complete lack of forethought in security.
One is a known breach/leak which produced demonstrable harm. The other is a bug that can't be shown not to have been used past the stored logging.
One is the known burglary of your hotel room with your items for sale online. The other hotel used locks that could be bypassed, but only has security footage saved for the last month to show you weren't robbed then.
One is the known burglary of your hotel room with your items for sale online. The other hotel used locks that could be bypassed, but only has security footage saved for the last month to show you weren't robbed then.
Not a big Google fan (actually actively minimizing Google products use) but I do not agree with you.
Having your SSN/all details about your credit history exposed is way way worse than having your google account compromised.
People know what a credit bureau is as good or better than what google is. There should be real, measurable consequences to the Equifax leak (as in they should no longer be allowed to operate).
As far as Google goes and how they choose to handle this: I for one think they should have closed the security hole, keep monitoring it and kill the service separately after a while. It does not look good for them that they did it in one go, but at the end of the day, you are free not use google.
> Having your SSN/all details about your credit history exposed is way way worse than having your google account compromised
I'm not disagreeing with you. I'm just saying these are both examples of privately-owned American digital infrastructure being vulnerable. In one case, we have evidence of a breach. In the other, we do not.
Taken together, these cases don't argue against each other. They argue together. That's why this is getting Congressional attention. The "how dare they ask these questions" tone on this thread, while understandable given how most of us earn our keep, is a bit off the mark.
I'm not disagreeing with you. I'm just saying these are both examples of privately-owned American digital infrastructure being vulnerable. In one case, we have evidence of a breach. In the other, we do not.
Taken together, these cases don't argue against each other. They argue together. That's why this is getting Congressional attention. The "how dare they ask these questions" tone on this thread, while understandable given how most of us earn our keep, is a bit off the mark.
Yes and no. When it comes to Google I have a choice. When it comes to credit I do not.
> Sure. First hold Equifax accountable, then we'll talk about Google.
Nah, first hold OPM accountable then we'll talk about the private sector.
Nah, first hold OPM accountable then we'll talk about the private sector.
Please stop. Whataboutism is not helpful.
So not only should companies have to publish hacks, they also have to publish when they internally find a bug?
Do I also need to publish if I left my keys in the door for two hours, but nobody broke in?
Do I also need to publish if I left my keys in the door for two hours, but nobody broke in?
How do you know nobody broke in?
And if you're responsible for storing personal data for millions of people in your home, and you left the keys in the door for a few hours, and you can't prove that nobody broke in, then maybe you should let people know that there's a chance their data has been compromised.
And if you're responsible for storing personal data for millions of people in your home, and you left the keys in the door for a few hours, and you can't prove that nobody broke in, then maybe you should let people know that there's a chance their data has been compromised.
Server logs are more or less equivalent the video recordings of the front door in this analogy. So the answer is you can know that nobody broke in by looking at the logs/recordings.
Google explicitly said in their post that they don’t have more than two weeks of logs (ironically, for privacy reasons).
> How do you know nobody broke in?
This applies to almost every security-related bug ever, so the analogy holds.
If you run a company with PII in your mysql, and mysql has a bug (not uncommon), are you now required to tell all your customers that someone may have hacked your database, and then erased the logs?
What if you irresponsibly didn't have a firewall (or your firewall allowed connections from business partners, to some non-PII tables)?
It's possible that between the time the bug was introduced (or made public), and the time you patched, that someone at your business partner stole personal information, and it's not feasible for you to in all cases know if this happened. No matter how good you are, it's not feasible in the real world.
> And if you're responsible for storing personal data for millions of people in your home, and you left the keys in the door for a few hours, and you can't prove that nobody broke in, then maybe you should let people know that there's a chance their data has been compromised.
Maybe I should. And in this case, I did. But not right away.
But it's a long way from "maybe you should" to "you MUST (by power of law) IMMEDIATELY".
Read up on some "keys left in the door" scenarios about nuclear weapons security. We tend to not find out about those right away either.
This applies to almost every security-related bug ever, so the analogy holds.
If you run a company with PII in your mysql, and mysql has a bug (not uncommon), are you now required to tell all your customers that someone may have hacked your database, and then erased the logs?
What if you irresponsibly didn't have a firewall (or your firewall allowed connections from business partners, to some non-PII tables)?
It's possible that between the time the bug was introduced (or made public), and the time you patched, that someone at your business partner stole personal information, and it's not feasible for you to in all cases know if this happened. No matter how good you are, it's not feasible in the real world.
> And if you're responsible for storing personal data for millions of people in your home, and you left the keys in the door for a few hours, and you can't prove that nobody broke in, then maybe you should let people know that there's a chance their data has been compromised.
Maybe I should. And in this case, I did. But not right away.
But it's a long way from "maybe you should" to "you MUST (by power of law) IMMEDIATELY".
Read up on some "keys left in the door" scenarios about nuclear weapons security. We tend to not find out about those right away either.
> they also have to publish when they internally find a bug?
Has anybody actually proposed this? There are a lot of options between staying silent and public disclosure.
Has anybody actually proposed this? There are a lot of options between staying silent and public disclosure.
What are they? Because making a forced bugfix reporting system seems like pointless busywork if the public can't have access to it (and to be honest, it sounds pointless even if they do).
> What are they?
Off the top of my head, for companies above a certain threshold:
* Require disclosure to senior management. If Nest finds a serious bug, they have to Cc someone upstairs in Alphabet.
* Require disclosure to the Board.
* Encourage disclosure to a federal agency in exchange for limited liability if a breach using the vulnerability is later discovered.
I don't know. But I think it's worth a discussion.
Off the top of my head, for companies above a certain threshold:
* Require disclosure to senior management. If Nest finds a serious bug, they have to Cc someone upstairs in Alphabet.
* Require disclosure to the Board.
* Encourage disclosure to a federal agency in exchange for limited liability if a breach using the vulnerability is later discovered.
I don't know. But I think it's worth a discussion.
Im open to discussion, but I fail to see how any of this would benefit the user in any way.
The first 2 are basically unenforceable, and depending on the definition would happen so often as to make it easier to hide real issues, or would only happen when a public disclosure should happen, like user data was compromised. (I say "should" because I'm not sure if it's required in the US right now, and if it's not I absolutely think it should be).
The last one makes this situation worse, as now the incentive to correctly fix it is gone. Who cares if further issues with the fix are found? Their liability is limited, so they can half-ass whatever fix they want and be safe. Not to mention that it basically requires the federal agency to have full access to the source and development of all (I'm assuming publicly traded) companies code. Even if I trusted the agency with that information, now it's another target for attackers, and it still doesn't do anything to make code safer for the user.
I understand those were just discussion points or suggestions you are putting out there, and I get that you don't claim to have all the answers at this point, but I genuinely don't see any way that this can help the user in any way at all.
Edit: immediately after posting this I had a thought from re-reading your comments. I'd be open to an "OSHA for programming". An agency or group which creates guidelines or rules you must follow to safely handle data in companies. However I think we would need to be VERY careful to not enforce specific ways of working or specific algorithms to avoid a cryotographic monoculture or codify exploits into the law. And it would need to target only practices which are grossly negligent to avoid being a "shutdown any company at any time" button.
I'm honestly not sure it's possible to make a group like that and ensure it doesn't get out of control, or become so toothless it's just a waste of money. But if that's what you were trying to say, I can see the merit in the idea, but I still don't think it's a good idea.
The first 2 are basically unenforceable, and depending on the definition would happen so often as to make it easier to hide real issues, or would only happen when a public disclosure should happen, like user data was compromised. (I say "should" because I'm not sure if it's required in the US right now, and if it's not I absolutely think it should be).
The last one makes this situation worse, as now the incentive to correctly fix it is gone. Who cares if further issues with the fix are found? Their liability is limited, so they can half-ass whatever fix they want and be safe. Not to mention that it basically requires the federal agency to have full access to the source and development of all (I'm assuming publicly traded) companies code. Even if I trusted the agency with that information, now it's another target for attackers, and it still doesn't do anything to make code safer for the user.
I understand those were just discussion points or suggestions you are putting out there, and I get that you don't claim to have all the answers at this point, but I genuinely don't see any way that this can help the user in any way at all.
Edit: immediately after posting this I had a thought from re-reading your comments. I'd be open to an "OSHA for programming". An agency or group which creates guidelines or rules you must follow to safely handle data in companies. However I think we would need to be VERY careful to not enforce specific ways of working or specific algorithms to avoid a cryotographic monoculture or codify exploits into the law. And it would need to target only practices which are grossly negligent to avoid being a "shutdown any company at any time" button.
I'm honestly not sure it's possible to make a group like that and ensure it doesn't get out of control, or become so toothless it's just a waste of money. But if that's what you were trying to say, I can see the merit in the idea, but I still don't think it's a good idea.
> Do I also need to publish if I left my keys in the door for two hours, but nobody broke in?
You are not a giant company that stores the personal data of hundreds of millions of people. So, presumably, no.
You are not a giant company that stores the personal data of hundreds of millions of people. So, presumably, no.
The thing that makes this unique is that Google is claiming that they have no idea whether the bug was used by third parties. In my opinion this already seems questionable. And it's a big deal whether true or false. If true it means that Google is likely engaging in questionable security practice by not even logging remote access to privileged information, if false it's far worse for them as it almost certainly means that they believe the information was accessed by unauthorized parties, and they then chose to lie about it.
No, Google is claiming that all of their evidence, including research and data gathering, shows that the bug wasn't known or abused, but for privacy reasons they only keep two weeks of logs, so that particular chunk of evidence (the server logs) doesn't cover enough time to be definitive.
It's a really shitty job by Google PR people. Who in their right mind would close product in response to a security vulnerability? It was bound to grow out of proportions.
Headlines like "500 000 people at risk! The bug was so serious that Google shuts down their social network!" just write themselves.
Headlines like "500 000 people at risk! The bug was so serious that Google shuts down their social network!" just write themselves.
[deleted]
It is not and never has been a norm for SAAS vendors to disclose internal vulnerabilities that have not been discovered independently by third parties. Tens of thousands are found every year by internal teams and contractors at companies around the country, many of them far more severe than the G+ bug (which would probably win a sev:low on a real assessment, less impactful than an XSS bug). You hear about none of them.
A coherent argument that this is as it should be: http://flaked.sockpuppet.org/2018/10/09/internal-disclosure-...
You can argue that things should be different for shrink-wrap software and hardware products, where vulnerabilities have a half-life and users need to be notified to patch. I won't disagree, but I will note that the norm of not disclosing internal discoveries holds there as well.