Q4 Goals Recap -
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.

Q4 Goals

Roadmap

Question: When a user enables mixed script content on a page (unblocks), how long should that decision persist? What should happen in the following cases:
- Refresh
- Back and Forward Events (how does click to play handle this? bfcache or beyond that)
- New tab/window
- Firefox restart with session restore or a new session
- New session will not remember unless you do something explicit to make it remember (i.e. just don't add it to session restore)
- Trying to explain this will be hard without consistency, so we should be consistent in across these.
- Session timeout?
- Our APIS are per load (geolocation, click to play)
- Solution - do what click to play does.
Question: If a user enables mixed script content on a specific page, how do they disable it if they change their mind?
- Solution: Put a button in the site identity
Question: Once we land the full Mixed Blocker experience, should a user be able to universally unblock mixed active content (via about:config security.mixed_content.block_active_content)?
- Option 1 - Pull it out when it is on beta (once we know its not going to break stuff) or perhaps go through a release of it.
- Option 2 - Leave it in. Because technically, blocking mixed content is violating the HTML spec. There may be perfectly compliant pages which may be perfectly safe if on a vpn.
- We should add telemetry to see how many people actually flip that pref. (discussion of Firefox Health Check)

ian talked to jonas
in general seems as if we need more discussion/guidance from the WG
jonas feels (so does ian) that the distinction between different means of setting styles is somewhat arbitrary and the list of methods to set styles laid out in bug 763879 are all fundamentally equivalent
attack jonas pointed out in bug 763879 relies on being able to set images as background using CSS injection - a restrictive img-src rule could mitigate this but we can't count on this being present
in Gecko, CSS filters can link to files - same 'phone-home' source of attack. only Gecko has CSS filters AFAICT
webkit might have another vector - CSS rule linking to a shader program, also 'phone home'
TL;DR - what can we do to get the WG/spec to address these issues and make the spec more explicit about what it means to 'block style attributes' ? perhaps it can be more explicit about the threats CSP style-src is intended to mitigate ? or be more explicit about exactly what should be blocked (it shouldn't be de facto 'what webkit blocks in their implementation')
imelven will email the WG to bring all of this up

Wait until we have the how-to-get-on-the-list problem more figured out?
Can still probably blog about it even if we're not done. Talk about the sticky spots.