SecurityEngineering/MeetingNotes/07-18-13

From MozillaWiki
Jump to: navigation, search

Standing Agenda

  • Q3 Goals Recap ( https://intranet.mozilla.org/2013Q2Goals#Security_Engineering )
  • Review roadmap priorities to ensure they accurately reflect active projects and Mozilla's priorities
  • Suggest additions or changes to roadmaps
  • Detailed discussion of features or outstanding issues as time permits
  • Additional Items
  • Upcoming events, OOO/travel, etc.

Last week: https://wiki.mozilla.org/SecurityEngineering/MeetingNotes/07-11-13

Agenda 07-18-13

  • Q3 Goals Recap
    • For our Q3 goals we tried to figure out what other teams need to be involved and make sure they are aware that we are on the hook for Q3.
  • nsIStrictTransportSecurityService refactor proposal
  • Passcode unlock on B2G

Q3 Goals

  • Finish first phase of Sandboxing
    • Outcome: seccomp in e10s/Larch or on nightly + clear roadmap
    • DRI: Sid
    • Team interdependencies: e10s team

@ E10S contributions to make it reasonably usable in nightly. (without extensions/plugins) @@ Fix window.crypto to work in E10S @@ Fix CSP tests to work in E10S @ land seccomp for Linux (min bar for sandboxing) @ Prioritize secomp tightening steps, begin executing it evilpie's addon compatibility: https://docs.google.com/spreadsheet/ccc?key=0AhFRRYurPzRndHQwUVNscThIbFBsYmNRaU44LVlDdlE#gid=0

  • Cookie Clearinghouse
    • Outcome: Identify feasibility and nail down spec
    • DRI: Monica
    • Team Interdependencies: network, services (mmayo), privacy/policy

@ spec out and make go/nogo decision on implementation @ drive Stanford effort to stable spec

  • Implement alternative revocation checking mechanisms
    • Outcome: must-staple + pinning + insanity on by default in nightly
    • DRI: Camilo
    • Team Interdependencies: QA and Services/IT (for key pinning)

@ Enable insanity::pkix validation by default on nightly @ Land key pinning[built in only] @ Land must-staple support

@ Land app reputation system with whitelist support @ Switch SafeBrowsing to use HTTPS == nsIStrictTransportSecurityService refactor proposal The STS service parses HSTS headers and tells the rest of the browser to upgrade sites. There are new headers coming in that look a lot like it, why can't we just reuse this machinery?

  • Currently using permission manager for storage -- not the right idea. We should add a new service/storage mechanism like the permission manager.
    • Permission manager drawbacks (reasons it's not good for STS):
      1. Not threadsafe the way we need it
      2. Uses nsIPrincipals (specifically, in a way that normalizes uris across apps, so all information is shared across the platform. This means that apps can fingerprint the user.)
      3. "Inappropriate to store key information the permission manager" (maybe just an issue of arguing with permission manager owners)

Passcode unlock on B2G

We store the PIN for unlocking the phone in plaintext. We need to fix that. Pauljt is aware of this and is hoping to solve this during an upcoming hackday.

Retrieved from "https://wiki.mozilla.org/index.php?title=SecurityEngineering/MeetingNotes/07-18-13&oldid=679446"