4 ms·

Project Zero is a (very public) Google project though. If they stand behind their choices and policies, they should live by them.

joshuamorton 5y ago
In what way is Google not standing by their policies (for example, have they criticized or tried to prevent this person from disclosing publicly)?
- e40 5y ago
  The clear implication is by not fixing the bug in the same time frame.
  - joshuamorton 5y ago
    What is the thing being implied? Like as far as I can tell, Google's position seems to be that "it is best if vuln researchers have the freedom to disclose unfixed issues, especially after reporting them". People criticize P0 for publishing issues despite companies asking for extensions. But we're criticizing Google here for...what? They didn't ask for an extension, they didn't try to prevent this person from disclosing. Where is the hypocritical thing?
    - staticassertion 5y ago
      They didn't fix it within that timeline. I don't know why everyone is saying "well they didn't stop disclosure in 90 days", but they didn't fix it in the timeline that they have allocated as being reasonable for all vulns they report.
      - jsnell 5y ago
        At the limit, what you're saying would mean that vendors should feel obligated to fix issues they don't consider to be vulnerabilities, as long as they're reported as such. That'd clearly be absurd. Is there maybe some additional qualifying factor that's required to trigger this obligation that you've left implicit?
        staticassertion 5y ago
        > what you're saying would mean that vendors should feel obligated to fix issues they don't consider to be vulnerabilities Why would it? > Is there maybe some additional qualifying factor that's required to trigger this obligation that you've left implicit? That they consider it a vulnerability seems fine.
        jsnell 5y ago
        If you're leaving the determination to the vendor, they could just avoid the deadline by claiming it is not a vulnerability. That seems like a bad incentive. There are things that literally cannot be fixed, or where the risk of the fix is higher than the risk of leaving the vulnerability open. (Even if it is publicly disclosed!) It seems that we're all better off when these two concerns are not artificially coupled. A company can both admit that something is a vulnerability, and not fix it, if that's the right tradeoff. They're of course paying the PR cost of being seen as having unfixed security bugs, and an even bigger PR cost if the issue ends up being exploited and causes damage. But that's just part of the tradeoff computation.
        staticassertion 5y ago
        I don't know what point you're trying to make here. Google acknowledges that this is a vulnerability ("nice catch"), Google pushes every other company to fix vulns in 90 days (or have it publicly disclosed, which is based on the assumption that vulns can be fixed in that time), and Google did not fix it in 90 days. If you're asking me to create a perfect framework for disclosure, I'm not interested in doing that, and it's completely unnecessary to make a judgment of this single scenario. > A company can both admit that something is a vulnerability, and not fix it, if that's the right tradeoff. Google's 90 days policy is designed explicitly to give companies ample time to patch. And yes, this is them paying the PR cost - I am judging them negatively in this discussion because I agree with their 90 day policy.
        jsnell 5y ago
    - sirdarckcat 5y ago
      Might be worth noting, 90 days are how long Google thinks it is reasonable to keep vulnerabilities secret without a fix. The longer it is kept secret, the benefits of the public knowing about it outweigh the risks. Not all vulnerabilities can be fixed in 90 days, but they can be disclosed.
    - dataflow 5y ago
      The complaint is that Google's stance with Project Zero is "90 days is plenty sufficient; you're a bad vendor if you can't adhere to it", and then Google itself doesn't adhere to it, which implicates themselves here. I see what they're saying if you lump them together; I just think it makes sense to treat P0 a little independently from Google. But otherwise it's got a point.
      - joshuamorton 5y ago
        Can you point out the second part, specifically where "you're a bad vendor if..." is either stayed or implied py P0? See instead https://news.ycombinator.com/item?id=27680941 https://news.ycombinator.com/item?id=27680941, which is my understanding of the stance p0 takes.
        dataflow 5y ago
        > See instead https://news.ycombinator.com/item?id=27680941 https://news.ycombinator.com/item?id=27680941, which is my understanding of the stance p0 takes. That's a common sentiment I just don't buy. People here love to hand-wave about some vague "benefit to the public", and maybe there is some benefit when the vulnerability can be mitigated on the user side, but it literally cannot be the case for the fraction of vulnerabilities that entities other than the vendor can do nothing about. The only "benefit" is it satisfies peoples' curiosity, which is a terrible way to do security. Yet P0 applies that policy indiscriminately. > Can you point out the second part, specifically where "you're a bad vendor if..." is either stayed or implied py P0? As to your question of when this is implied by P0, to me their actions and lack of a compelling rationale for their behavior I explained above is already plenty enough to imply it. But if you won't believe something unless it's in an actual quote from themselves, I guess here's something you can refer to [1]: - "We were concerned that patches were taking a long time to be developed and released to users" - "We used this model of disclosure for over a decade, and the results weren't particularly compelling. Many fixes took over six months to be released, while some of our vulnerability reports went unfixed entirely!" - "We were optimistic that vendors could do better, but we weren't seeing the improvements to internal triage, patch development, testing, and release processes that we knew would provide the most benefit to users." - "If most bugs are fixed in a reasonable timeframe (i.e. less than 90 days), [...]" All the "reasonable time frame (i.e. < 90 days)", "your users aren't getting what they need", "your results aren't compelling", "you can do better", etc. are basically semi-diplomatic ways of saying you're a bad vendor when you're not meeting their "reasonable" 90-day timeline. [1] https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html https://googleprojectzero.blogspot.com/p/vulnerability-discl...

joshuamorton 5y ago

In what way is Google not standing by their policies (for example, have they criticized or tried to prevent this person from disclosing publicly)?

e40 5y ago
The clear implication is by not fixing the bug in the same time frame.
- joshuamorton 5y ago
  What is the thing being implied? Like as far as I can tell, Google's position seems to be that "it is best if vuln researchers have the freedom to disclose unfixed issues, especially after reporting them". People criticize P0 for publishing issues despite companies asking for extensions. But we're criticizing Google here for...what? They didn't ask for an extension, they didn't try to prevent this person from disclosing. Where is the hypocritical thing?
  - staticassertion 5y ago
    They didn't fix it within that timeline. I don't know why everyone is saying "well they didn't stop disclosure in 90 days", but they didn't fix it in the timeline that they have allocated as being reasonable for all vulns they report.
    - jsnell 5y ago
      At the limit, what you're saying would mean that vendors should feel obligated to fix issues they don't consider to be vulnerabilities, as long as they're reported as such. That'd clearly be absurd. Is there maybe some additional qualifying factor that's required to trigger this obligation that you've left implicit?
      - staticassertion 5y ago
        > what you're saying would mean that vendors should feel obligated to fix issues they don't consider to be vulnerabilities Why would it? > Is there maybe some additional qualifying factor that's required to trigger this obligation that you've left implicit? That they consider it a vulnerability seems fine.
        jsnell 5y ago
        If you're leaving the determination to the vendor, they could just avoid the deadline by claiming it is not a vulnerability. That seems like a bad incentive. There are things that literally cannot be fixed, or where the risk of the fix is higher than the risk of leaving the vulnerability open. (Even if it is publicly disclosed!) It seems that we're all better off when these two concerns are not artificially coupled. A company can both admit that something is a vulnerability, and not fix it, if that's the right tradeoff. They're of course paying the PR cost of being seen as having unfixed security bugs, and an even bigger PR cost if the issue ends up being exploited and causes damage. But that's just part of the tradeoff computation.
        staticassertion 5y ago
        I don't know what point you're trying to make here. Google acknowledges that this is a vulnerability ("nice catch"), Google pushes every other company to fix vulns in 90 days (or have it publicly disclosed, which is based on the assumption that vulns can be fixed in that time), and Google did not fix it in 90 days. If you're asking me to create a perfect framework for disclosure, I'm not interested in doing that, and it's completely unnecessary to make a judgment of this single scenario. > A company can both admit that something is a vulnerability, and not fix it, if that's the right tradeoff. Google's 90 days policy is designed explicitly to give companies ample time to patch. And yes, this is them paying the PR cost - I am judging them negatively in this discussion because I agree with their 90 day policy.
        jsnell 5y ago
  - sirdarckcat 5y ago
    Might be worth noting, 90 days are how long Google thinks it is reasonable to keep vulnerabilities secret without a fix. The longer it is kept secret, the benefits of the public knowing about it outweigh the risks. Not all vulnerabilities can be fixed in 90 days, but they can be disclosed.
  - dataflow 5y ago
    The complaint is that Google's stance with Project Zero is "90 days is plenty sufficient; you're a bad vendor if you can't adhere to it", and then Google itself doesn't adhere to it, which implicates themselves here. I see what they're saying if you lump them together; I just think it makes sense to treat P0 a little independently from Google. But otherwise it's got a point.
    - joshuamorton 5y ago
      Can you point out the second part, specifically where "you're a bad vendor if..." is either stayed or implied py P0? See instead https://news.ycombinator.com/item?id=27680941 https://news.ycombinator.com/item?id=27680941, which is my understanding of the stance p0 takes.
      - dataflow 5y ago
        > See instead https://news.ycombinator.com/item?id=27680941 https://news.ycombinator.com/item?id=27680941, which is my understanding of the stance p0 takes. That's a common sentiment I just don't buy. People here love to hand-wave about some vague "benefit to the public", and maybe there is some benefit when the vulnerability can be mitigated on the user side, but it literally cannot be the case for the fraction of vulnerabilities that entities other than the vendor can do nothing about. The only "benefit" is it satisfies peoples' curiosity, which is a terrible way to do security. Yet P0 applies that policy indiscriminately. > Can you point out the second part, specifically where "you're a bad vendor if..." is either stayed or implied py P0? As to your question of when this is implied by P0, to me their actions and lack of a compelling rationale for their behavior I explained above is already plenty enough to imply it. But if you won't believe something unless it's in an actual quote from themselves, I guess here's something you can refer to [1]: - "We were concerned that patches were taking a long time to be developed and released to users" - "We used this model of disclosure for over a decade, and the results weren't particularly compelling. Many fixes took over six months to be released, while some of our vulnerability reports went unfixed entirely!" - "We were optimistic that vendors could do better, but we weren't seeing the improvements to internal triage, patch development, testing, and release processes that we knew would provide the most benefit to users." - "If most bugs are fixed in a reasonable timeframe (i.e. less than 90 days), [...]" All the "reasonable time frame (i.e. < 90 days)", "your users aren't getting what they need", "your results aren't compelling", "you can do better", etc. are basically semi-diplomatic ways of saying you're a bad vendor when you're not meeting their "reasonable" 90-day timeline. [1] https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html https://googleprojectzero.blogspot.com/p/vulnerability-discl...