Please don't project strawmen onto other users, it's intellectually weak and rude besides.
Also, I fundamentally disagree with your example. If they did an adequate investigation, using a 3rd party service, and found no evidence of my data being accessed by a 3rd party, and then fixed it- I'd say, "Good job checking up on yourselves" and move on.
Security is still incredibly hard to get right. I'm willing to bet your service has security holes in it, right now- and that's not a hit against you. We haven't mastered these systems and anyone who thinks they have is just waiting to get bit in the ass. Every security professional knows: It's never, ever, a question of "if", but of "when".
We've absolutely mastered these systems.
We just prioritize rapid development time and ease of use over security.
People make fun of DoD / space price tags (and admittedly, there's still a lot of crap sold there), but it's a trade off.
If we wanted computers to cost $x0,000 and OSes to cost $x,000, and the pace of progress to be glacial, we could have completely secure systems today.
It's a choice, not an impossibility.
> If we wanted computers to cost $x0,000 and OSes to cost $x,000, and the pace of progress to be glacial, we could have completely secure systems today.
> It's a choice, not an impossibility.
Progress in core OSes and conventional hardware has already slowed down to a glacial pace, compared with previous decades. Rapid development is often used to just create a churn of useless sidegrades and other poorly thought out things (deceptively sold as upgrades).
It might be time to make that different set of choices.
That's an interesting theory that's not supported by historical evidence as far as I can tell. When computers were expensive, there just were less people with access. The systems were not any more secure.
For example, the parent article, the one this comment is ostensibly in response to, has nothing to do with operating system security.
A better example is maybe instead of Google spending $xxx,000 to develop the system that was found insecure they should have spent $x,000,000 so they had more resources devoted to the security aspects.
Perhaps this is too high for this system to exist; well maybe that system just shouldn't exist if it can't be secured properly with the budget for it.
there's two points there
acknowledging it's impossible to have zero bugs ... and ... acknowledging that there will be exploits.
sure you can do better than average but "completely secure" is a myth
as for DoD there's this from 3 days ago
Which is my point and why the broad assertion is wrong.
Look at a VxWorks type OS. Or OpenBSD. Limited capability and compatibility, very strong security guarantees.
"Completely secure" isn't a mythical unicorn. It just costs time and money. A LOT of time and money.
If a company is disincentivized to look for security holes because it's highly likely it will find them; that company is on the fast-track to failing.
> If they did an adequate investigation, using a 3rd party service, and found no evidence of my data being accessed by a 3rd party
They found no evidence of data being accessed, but they also don't share how this particular system tracks data that is accessed. This system was vulnerable for 2-3 years. What if you left your car at my house and you found a dent on it, but I claim that I didn't have any security footage of someone damaging your car without mentioning that I don't actually have security cameras.
> I'm willing to bet your service has security holes in it...
You're right, and it I find that my NTP service is exploitable and anyone can DDOS me I'll fix it and move on. There's no need to disclose that I'm an idiot when it doesn't affect other people. But when I accidentally leave my servers mis-configured and my API unprotected against unauthorized access I would make a post about it. We're not talking about an arbitrary vulnerability that lets people echo hello on a Google server. They left data exposed. I would like to know if it involves me.
I don't see any evidence to back up this assertion. FWIW I don't believe this is true.
Sony hasn’t failed yet.
I don’t think your opinion matches with reality.
But is that really what would happen? Vulnerabilities are frequently found and publicly reported. The reaction depends on the type of vulnerability (how stupid it sounds) and on whether or not the vulnerability resulted in a breach. You don't get hit equally hard for all security issues.
I think both users and developers have to be mature enough to deal with this sort of thing without resorting to secrecy. Secrecy creates distrust as the reaction to this particular Google+ issue shows.
With big enough repercussions it should incentivize processes that don't allow it to happen in the first place. This is how HIPPA and various other things work already and it does a decent job (not perfect though).
I'd also say that we need decide if mistakes are forgivable and whether or not if it's based on impact.
Perhaps for a small data leak it's forgivable, and we won't hit them with a huge fine or whatever. If it's a big leak then maybe we need to jail people.
It's a bit of a strawman to say everything has security holes because it's assuming the problem is unfixable from the start.
It's a bit like launching a person into space. "We know that probability we'll be sending people to their death is high, let's not bother then." We decided to do it anyway but we set extremely high bars for safety.
Were this actually the case, the CSV list (not even mentioning Google's own Project Zero) would have disincentivized companies and projects years ago.
How'd you feel then?
Also bridges are built with a much bigger lifetime in mind and require (proving GP's point) a much bigger investment.
Especially given the way Google, quite rightly, expose vulnerabilities through Project Zero.
That means that Google was proactively checking it’s work to make sure it was secure, unlike your example where nobody was likely ever going to notice that bucket was misconfigured.
They’re the gold standard because they find and clean up their own shit, even when nobody is pressing them to do it.
Furthermore, if every potential vulnerability that might have been exploited needs to be reported as a breach... then each and every bug in any library and other dependency you use likely needs a breach report too - after all, you typically cannot verify retrospectively whether that exploit wasn't independently discovered and abused before the fix.
I'm not even positive such a reporting requirement would really be a bad idea, but it would definitely needs some more mature reporting and population education to tell the two classes of issue apart, especially since it's pretty vague where you draw the line on what needs publication once you get that far.
This is the information that was possibly was exposed: https://developers.google.com/+/web/api/rest/latest/people
Plus, were this the case, the CSV list would have stunted vulnerability exploration across the board. Have you seen the list of vulnerabilities discovered in curl?
It isn't that it is Google that makes the difference, but the extent of the damage.
Really? If Google has access logging on its content, and as in your example an AWS bucket can be configured for access logging then it would be fairly straightforward to identify if the data was accessed.
You're supposed to be above this here on HN.
So besides applications, infrastructure, distributed systems, reliability, money & security what have the Romans ever given us?
Please stop pretending this isn't a big deal just because of a hard-on for Google. If you'll put a 10 man company out of business for their complacency and ignorance you should be lining up at Google HQ with pitchforks over this. They're supposed to be above this. They are hailed as a gold standard.