3 ms·

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 t

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?

jstanley 8y ago
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.
- orev 8y ago
  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.
  - dgellow 8y ago
    Google explicitly said in their post that they don’t have more than two weeks of logs (ironically, for privacy reasons).
- knorker 8y ago
  > 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.
JumpCrisscross 8y ago
> 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.
- Klathmon 8y ago
  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).
  - JumpCrisscross 8y ago
    > 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.
    - Klathmon 8y ago
      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.
brandonmenc 8y ago
> 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.
TangoTrotFox 8y ago
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.
- tylerl 8y ago
  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.

jstanley 8y ago

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.

orev 8y ago
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.
- dgellow 8y ago
  Google explicitly said in their post that they don’t have more than two weeks of logs (ironically, for privacy reasons).
knorker 8y ago
> 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.

JumpCrisscross 8y ago

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

Klathmon 8y ago
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).
- JumpCrisscross 8y ago
  > 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.
  - Klathmon 8y ago
    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.

brandonmenc 8y ago

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

TangoTrotFox 8y ago

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.

tylerl 8y ago
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.