On Thu, Dec 27, 2018 at 8:22 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > I can't speak for Mozilla here, but I tried to lay out some clear > expectations: > 1) This is an extension of an existing incident, rather than treating it as > an exception to some long-standing or new rule > 2) This is being treated as part of the remediation (revocation) plan, > rather than as an intentional violation of some other requirement > This framing is technically correct and quite helpful in this situation, but I am concerned about what it appears to imply for other ambiguous requirements. Seeking clarity through a discussion and vote, as happened here, is more orderly than a sudden declaration that a practice is forbidden. This particular situation is a bit like a law that is challenged in court, then upheld by the court and enforced, as opposed to a new law being retroactively enforced. > 3) Going forward, "they weren't prepared for revocation" is not really an > acceptable answer in and of itself, and for this particular incident, > concrete proposals for how "They weren't prepared for revocation" can be > addressed or mitigated go a long way to addressing the underlying root > cause here, and by proxy, demonstrate a healthy awareness of and balancing > of risk, and ways to concretely mitigate that for the future. > > Yes, this is the desired outcome. Thanks James, Jeremy, Matt, and Ryan - I really appreciate the ideas that have come out in this discussion. I'll be looking at ways to use some of this thinking to improve the Mozilla incident reporting process - suggestions are welcome. - Wayne _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
