SecurityEngineering/MeetingNotes/08-30-12

From MozillaWiki
Jump to: navigation, search

Standing Agenda

  • Q3 Goals Recap -
    • Implement security model for basecamp
    • Achieve go / no-go for Firefox sandboxing
    • Land "final" Click to Play experience (address correctness and UX)
    • Ship CSP compliant with W3C 1.0 spec (also helps B2G)
    • Lead security/privacy dev community event or workshop
  • Review currently active (P1) features against their established milestones, identify any blockers - Security/Roadmap + Privacy/Roadmap
  • 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/08-23-12

Goals

  • [ON TRACK] Security Model for basecamp
  • [ON TRACK] Sandboxing -- ian working on it
  • [ON TRACK] C2P user experience is on track
  • [AT RISK] CSP 1.0 compliance -- lots left to do, risking missing unless anyone wants to help
  • [DROPPED] community event or workshop

Roadmap

  • mixed content is getting closer !
  • CA pinning is making progress !
  • Click to play - keeler is _confident_ UI will be finished for FF18 - we should consider trying to uplift to FF17 Aurora so we can have click to play blocking in FF17 release.
  • Per Site 3rd Party Cookies - mmc has finished the backend and it has sr+
  • B2G App Permission - ddahl has been working on this - installation works, but still more to do
  • NEW IDEA - CSP our chrome pages a (new roadmap item proposed during sec assurance work week)
    • anyone want to write the feature page - Tanvi will write one

Additional Items

Visit from Yvan

  • Starting to plan a mozilla-focused security conference: targeting Q1-2013
    • Likely to be a Single-track conference with time set aside for workshops and such
    • lco suggests we have some usability/UX coverage
    • ping yvan if you want to provide feedback
  • Other items from Sec Assurance work week

Discussion with Larissa on mixed content text

http://people.mozilla.com/~lco/ProjectSPF/Mixed_Content/Mixed%20Content%20Spec%20v2.pdf

  • Users need to be able to trust firefox. The browser should be trustworthy.
    • 1. Gradually reveal information (avoids overwhelming users)
    • 2. Critical to explain what we've already done to protect the user
    • 3. Focusing on addressing how messaging affects what the user is trying to do. How will it affect what the user is trying to do (not what the security implication is). Will the page break? Will it stop them from the task?
    • 4. Sometimes we have opposing indicators; positive wording for actions users should take. For example, "Would you like to disable protection" instead of "would you like to enable mixed content".
Firefox has blocked insecure content on this page. [More Information Button]
    
Most websites will still work properly even when
insecure content is blocked.
    
If the page looks broken, ask the site to fix their insecure
content so that you can be safer on the Web.
How does insecure content make me unsafe?
Left Button: Technical Information
Right Button: Disable protection on this page
    
This site contains insecure content.
    
Your connection to this site is only partially
encrypted, and does not prevent
eavesdropping. To block insecure content,
refresh this site.
  • Technical Information button could point to something like this until we have the UI and code to show the user/developer what the mixed content is: https://developer.mozilla.org/en-US/docs/Security/MixedContent
  • It would be nice if we have a page with security symbols, explaining when they are used and what they mean. For the future ;)

search (tanvi)

  • the future of the search box (is it going away?)
  • sid is on it

HSTS preload list

  • Chrome has a big list of sites that are considered to be HSTS sites
  • But there are some sites in the list that are *not* HSTS sites, and their presence in the list is a "hole punch", or means that the listed (non HSTS) site is not required to be https.
  • Keeler's thinking is that all sites on the list should be secure by default.
    • But google's list is not just for HSTS
  • Plan : Go through the list and check which sites actually set HSTS. The sites that actually use HSTS is the subset of the list that we use.
  • If we want an HTTPS-by-default system, we can maybe do something like the public suffix list and have a cross-organization effort to maintain the list

update from Decoder

  • he has made some progress in determining what areas to look at for coverage analysis. and has added some data here : https://etherpad.mozilla.org/SecurityCoverageAnalysis
  • it describes how the data was generated, and it shows where we have most security problems (excluding the JS engine), based on where we have security bugs in the past
  • maybe it's useful for the engineering side to see where there might be more testing required - the next step is to cross-check this with C++ coverage in those areas and see if there is a lack of coverage
Retrieved from "https://wiki.mozilla.org/index.php?title=SecurityEngineering/MeetingNotes/08-30-12&oldid=467695"