Live data from Hacker News

Google Exposed User Data, Feared Repercussions of Disclosing to Public

wsj.com

201–210 of 277 posts

Re: Google Exposed User Data, Feared Repercussions of Disclosing to Public

#201

non-paywall version: http://archive.is/rpuA1

Does anyone else get rubbed the wrong way by this sort of irreverent infringement? Even if you have zero concern for journalists’ copyrights, it puts this forum at risk.

Nope

Re: Google Exposed User Data, Feared Repercussions of Disclosing to Public

#202
post #114

Earlier quoted context omitted.

> 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?

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.

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.

Re: Google Exposed User Data, Feared Repercussions of Disclosing to Public

#203

non-paywall version: http://archive.is/rpuA1

Does anyone else get rubbed the wrong way by this sort of irreverent infringement? Even if you have zero concern for journalists’ copyrights, it puts this forum at risk.

No I don’t, and no it doesn’t.

Re: Google Exposed User Data, Feared Repercussions of Disclosing to Public

#204
post #116
post #98

>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. Wait, so they only keep two weeks worth of logs and within these logs they did not find anyone abusing this flaw. How can they be certain for any time period from two week prior ?

The company which consider every single bit of data as "gold" decided not to keep their API's access log > 2 weeks? wow!

Our default policy is to keep generic RPC server logs for O(weeks). It's best practice as we log a lot of structured data that can be large -- especially at our QPS. Furthermore, we have data retention timelines to keep.

Re: Google Exposed User Data, Feared Repercussions of Disclosing to Public

#205
post #116

Earlier quoted context omitted.

The company which consider every single bit of data as "gold" decided not to keep their API's access log > 2 weeks? wow!

Our default policy is to keep generic RPC server logs for O(weeks). It's best practice as we log a lot of structured data that can be large -- especially at our QPS. Furthermore, we have data retention timelines to keep.

>Our default policy is to keep generic RPC server logs for O(weeks).

Out of curiosity, when was this policy adopted? After these security holes were discovered?

Re: Google Exposed User Data, Feared Repercussions of Disclosing to Public

#206

Wow the Wall St. Journal and Murdoch really does not like Google. This article makes this sound like this is something that it appears to not be. Did this all start when Google fired Damore? Or does it date further back?

>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 only kept two weeks of logs, yet this bug was accessible over a three year window. So out of 156 weeks they can only rule out 2 weeks where data was not accessed. I think that's pretty pathetic for a company that stores your precise location, search history, photos, email, text messages, calendar, social network, date of birth, etc.

This is a very big story. Hence why Google executives sat on it for six months.

Re: Google Exposed User Data, Feared Repercussions of Disclosing to Public

#207
post #31

Companies internally find and fix security bugs all the time and dont talk about it if no known breach occured. Is there a requirement to do this? Maybe there should be a requirement to document that due diligence occurred to understand if it was exploited?

They only kept 2 weeks worth of logs. So the correct statement is: in 2 of 156 weeks since the bug was accessible no known breach occurred.

Re: Google Exposed User Data, Feared Repercussions of Disclosing to Public

#208

non-paywall version: http://archive.is/rpuA1

Does anyone else get rubbed the wrong way by this sort of irreverent infringement? Even if you have zero concern for journalists’ copyrights, it puts this forum at risk.

Websites like WSJ manage to get listed high in the Google rankings by presenting the actual article, instead of a paywall, to the Googlebot and to requests with Google in the Referer field (as I understand it). I gather that they do the same thing to the Archive scraper. As far as I'm concerned, that's a cheap trick the website performs, and using a cheap trick to get around it seems fine to me.

Re: Google Exposed User Data, Feared Repercussions of Disclosing to Public

#209

A lot of the time I feel Google gets a bad rep on HN as the comments are so often filled with hyperbole. In this case however Google did a very poor job of disclosing this leak in their sunsetting Google+ announcement post. I would have much preferred an incident report explaining what really happened, even if they couldn't find any examples of abuse.

Conveniently for them, they only kept 2 weeks of logs (this is a 3 year old bug). I might implement that at my company. Take two weeks to patch and test the security hole, then review my two weeks of logs for any evidence of a breach. Then tell customers we haven't found any evidence of illicit access.

Re: Google Exposed User Data, Feared Repercussions of Disclosing to Public

#210
post #97

Earlier quoted context omitted.

Maybe even three stories; there's another bit in that Google blog post about Google making their API permission prompts for Gmail, Drive, Calendar, and contacts more fine-grained and locking them down with policy measures.

This is extremely problematic for us. We're bootstrapped and now Google is suddenly asking for up to $75,000 (or more) for a security audit. This despite the fact that we've been publicly asking for more limited OAuth scopes for years (c.f. my HN posting history and my tickets on the Google issue tracker), and the fact that we've had zero security incidents in over three years. All to ensure that we're not risking ex…

Appears that (wording is somewhat vague) apps which only store user data on the device do not need to go through this external security assessment.

Agree that this is Google pushing their security costs onto developers and effectively killing bootstrapped SAAS apps.

Post reply on HN