Bear in mind that proving no abuse is impossible, as it's always possible that the hypothetical abuser got one step further than your investigation and covered their tracks.
When such a vulnerability is discovered the right thing to do is to inform the users of its possible severity and the duration during which it was available.
Always.
At which point why not just stop being proactive?
Hardline stances sell great on forums, that doesn't make them right.
The attitude that absence of evidence should be treated as if it didn't happen leads to exactly that conclusion - that it's better to not be able to tell what's happening.
I'd love for that to happen. Maybe then everyone will start to pick up on the fact that all of our computer systems are insanely insecure.
Canada is going to require disclosure of breaches starting November 1. That may allow for companies to still fail to disclose the _possibility_ of breaches, however.
https://globalnews.ca/news/4122202/data-breach-canada-privac...
Long story short, California requires labeling of things that may contain chemicals hazardous for a variety of reasons. The idea was simple - never not inform. The intentions were pure.
The result is that basically everything has a vague and uninformative label about how it may contain chemicals that could be hazardous. The labels are spectacularly uninformative and incredibly numerous. They are universally ignored by everyone, as they constitute a sea of noise.
The net result is that a wonderful, laudable, pure, kind, and compassionate idea - never not inform - has led to a deluge of useless informational notices in which actual useful notices are impossible to find.
It might be worth considering that there could be a lesson in there.
Warning labels have dubious efficacy, as evidenced by decades of grotesque warnings upon cigarette packaging and their limited success at reducing consumption; but that's not to say we ought not be able to know about the potential harms of a product or service, just that product labels sort of suck as a method of informing users.
OTOH, Canada requires nutritional information on all food, and that's reasonably useful and successful _because_ the content of that label is strictly defined and reasonably useful.
Nutritional information is relatively easy to provide is thoroughly exhaustive detail. How does one go about informing about data events that may or may not have occurred, and may or may not occur in the future, in a way that's comprehensible to users who must be assumed to have absolutely no technical grounding whatsoever?
The most useful informative warning I think that could be reasonably provided runs like this: "Please be aware that any data you provide this service, and any data this service gathers, could previously, presently, or in the future be the subject of a data breach that may or may not be detected."
While the warning could of course be improved by being made more specific about what data is concerned, this does not seem like a good way to produce useful and informative warnings. Instead, it seems to me that attempting to pursue that most wonderful of ideals - never fail to inform - could easily produce a sea of overcautious attempts to ensure a user is never not informed, and instead over-informed into oblivion.
While such labels might potentially be successful in scaring users into using services less, this might not be the same as informing users.
I do hope I've communicated clearly here. Please let me know if anything could have been better-written. More importantly, I've clearly failed to understand some of your wise and well-made points. Can you help me with what I've missed?
X Authentication
X Financial
X Communications
X Property
Or such, so I can be aware at-a-glance that my user name, password, credit card information, private messages, or personal documents may have been compromised. I wouldn't be over-informed into oblivion, or at least not as likely to be, if the information available were suitably informative-yet-terse. Like a nutrition label.However, that's just my pie-in-the-sky desire!
Pragmatically, as a technical person, I'd personally be happy with regular release notes of product revisions, including SaaS products, and which are paired with a technical-oriented blog that details the notes in further clarity for the technically adept. The role of journalists can step in here, and appropriately severe information will spread much as it does now.
The upshot is that technical folks like us may learn a thing or two via such an open communication. If everyone did it then there would be less fear to do it and there would be more information avaialable about common risks and their mitigations.
Companies tend not to be terribly good at articulating where we are on that sort of scale.
Even the companies who are the very best at communications will tend to struggle to communicate clearly when filtered through a press that have strong incentives to construe everything as a data breach. Lay people reading either of your statements will tend to stop at "there's no evidence" and go "What do you mean, 'no evidence'!? I want certainty!". Witness how readily and widely this whole G+ event has been mis-reported as MASSIVE DATA BREACH.
While you're completely correct, perhaps there's room for subtlety here.
After reading it, I got the impression they have no idea what did, or did not happen.
Keep in might that effectively means you'd need to report a potential breach every patch tuesday if you're running on windows, and similarly frequently for most linux distros. Oh, and you'd need to report all vulnerabilities in any dependencies of any software you build on, such as webframeworks, libraries, other apps... everything. Oh, and svn had a sha1 collision vulnerability, so any software that ever used SVN, and anything that depended on it might need to report a breach. With meltdown and spectre... OK, we've basically arrived at the point that if your business was somehow in nebulous proximity to a computing device it may well have posed the risk of a breach. Where does it stop?
I mean - I'd love to live in a world where that were a realistic strategy, but in the I WANT MOAR DEPENDENCIES world we live in, which is just waking up to dealing with security issues, I'm not sure this is realistic, nor helpful.
So it's a shame that the best we have is the absence of evidence - but for all my frustration about the cavalier risks google took here, I do actually believe that's pretty plausible evidence of actual absence. After all, if this had been discovered and meaningfully exploited, I really doubt the exploiter would have stopped.
Reporting this kind of stuff as a breach is basically FUD. Essentially: You're distracting from real security issues, of which there are legion. No need to get all hypothetical about it - yet. Google made a shameful bug, but this isn't breach, not by any useful definition of breach.