See also: IRC log
<PeteF> +1.315.849.aabb is Pete Freitag... just listening in
<ekr> [Mozilla] has ekr
<bhill2> Scribe: Mike West
<bhill2> Scribenick: mkwst
bhill: Objections to last time's
bhill: How do we get subint to FPWD?
dveditz: Is redirection part of the leakage discussion?
bhill: Blobs, dveditz?
mkwst: Current language is that blobs need to be whitelisted explicitly as 'blob:'.
dveditz: Should be ok.
... One thing.
... 'data:' should not match '*'.
... 'blob:' too. They should be treated as 'unsafe-inline'.
mkwst: Propose some text?
dveditz: Sure, where?
mkwst: In the matching algorithm section. Could add a note anywhere thought.
dveditz: Intent is to include blob and data.
mkwst: will find some language for you.
bhill: CfC for UI Security to
LCWD last week.
... Moved frame-options out into mainline CSP 1.1
... Push previous spec with that bit removed.
... No objections to CfC.
... Motion to move UI Security to LCWD?
ekr: So moved.
bhill: Objection to unanimous
... None heard. LCWD!
<bhill2> RESOLVED: UI Security to be advanced to Last Call Working Draft
bhill: Proposals from Mike,
dveditz: Summary is that we're screwed. Need to either lose functionality, or live with a bad feature.
<bhill2> option 1: (Egor's proposal) only enforce policy on initial fetch, not on subsequent redirects
... Two options: 1. Allow redirects for source expressions with paths. This would avoid the biggest problem (reading paths cross-origin via brute force).
<bhill2> option 1 engenders some concern due to widespread presence of open redirectors on many domains
mkwst: 2. drop reporting, drop the DOM event, pretend that a resource failed to load just as if a network error occurred.
<bhill2> option 1 also doesn't really solve the problem, it just rate-limits or makes the attacker use tactics like using a frame-per path tested
dveditz: Reporting isn't the problem. Can tell from the page whether or not the resource loaded.
mkwst: 'script-src example.com/js'. would allow example.com/js/redirect -> evil.com
<bhill2> option 3: fallback to checking only at domain granularity on redirects
dveditz: why wouldn't we fall back to domain level granularity?
mkwst: Complexity. Seems reasonable to have distinct behavior for paths/no-paths.
bhill: <individual> Option
#1 probably isn't so bad.
... Part of the trust decision for an origin.
... less likely that there's redirects past a whitelisted path
<bhill2> I think that option 1 is the best... <hat = individual>
bhill: not that complicated.
<bhill2> simple to implement, explain, trust decision is obvious (including implication of possibility of redirects)
dveditz: Require paths to be a full match for a path segment?
<bhill2> and trust / risk of including a redirector can be reduced by specifying a path instead of a full host
dveditz: Suggested that we not
report redirects, report more information about the URL in the
... Want to drop that suggestion.
... Shouldn't report URL for same-origin redirects.
... No. I'm saying dont' change the stripping aspect of the spec.
... One more question: has the reporting turned out to be useful for real-world use cases?
bhill: Folks I've talked to find
... Report-only is useful. Anomaly detection, etc.
... Thought-leader with regard to reporting in the security space.
dveditz: Reporting isn't always awesome.
ekr: Might not be a Mozilla consensus.
glenn: Worked with a spec that's
making reporting optional, except when report-only is used.
Might be reasonable to look at.
... Not yet public.
bhill: Reporting does have users. Would make folks unhappy to lose it.
<bhill2> looks like approaching something like:
bhill: Extension note discussion.
glenn: New information, reopening for discussion?
bhill: Groundswell of interest. Folks expressing concern at the resolution of the objection.
<bhill2> "User agents may allow users to modify or bypass CSP enforcement, through user preferences and/or third-party additions to the user-agent" so that we're not tied to specifically bookmarklets and extensions."
<bhill2> or rather "User agents may allow users to modify or bypass CSP enforcement, through user preferences and/or third-party additions to the user-agent."
glenn: Trying to be accommodating of new suggestions. Last suggestions seems close to something we could accept.
dveditz: Normative or non-normative.
<gmaone> What about "User agents should not prevent users from modifying or bypass etc..."?
dveditz: Suggestions for UA should not be normative.
(or Should? :) )
... Don't want to tacitly accept malware.
... "User-instigated third-party additions"?
bhill: Wide leeway,
... Chrome doesn't allow side-loaded extensions, for example.
... Don't want to ask for special treatment in that sideloading sense.
... Can the editors add that language to the spec? Seems satisfactory to everyone in the community who has expressed interest and concern.
glenn: Ok with this.
... Neglected to remove a related piece of language in 184.108.40.206.
... "ignore this step" bookmarklets.
... Should be remove as well.
... Falls into the category of "user preferences" or "third-party additions".
... But tied to the earlier language. Haven't looked at the editing history, but seem closely related.
... Suggesting that this one should be removed as well.
<bhill2> "User agents may allow users to modify or bypass CSP enforcement, through user preferences, bookmarklets, and/or third-party additions to the user-agent"
glenn: New language covers both.
mkwst: fine with that.
ekr: I don't care. SHOULD vs MAY vs SHOULD NOT. Not useful.
bhill: This text seems
reasonable. Let's do it.
... Reflects the consensus. May choose to do this, but not required to.
... Not going to satisfy everyone, but we can live with it. Should close it and move on.
wseltzer: Won't be surprised if we see more argument next week.
<terri> that was me, actually
bhill: Not everyone's ever going to be happy about anything.
<terri> (not wseltzer, who I haven't heard today)
(Sorry, Terri! Bad with voices...)
<bhill2> ACTION: mkwst to remove 220.127.116.11 [recorded in http://www.w3.org/2014/02/26-webappsec-minutes.html#action01]
bhill: Should remove the 18.104.22.168 text as well.
<trackbot> Error finding 'mkwst'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
(bhill: I'm mwest2)
glenn: Should we update CSP 1.0
... We can edit CR before PR, yes?
bhill: New topic. We have so far
declared that we've got consensus on CSP 1.0, moved on. If we
want to reopen that, take a poll on the list.
... Discussion has been in regards to 1.1. Let's bring it up on the list.
glenn: Fine with that. Just want to point out, Cox will comment at the PR timeframe.
bhill: Lightning round!
... Outstanding issues with regard to <meta>, terri?
terri: If the answer is "nobody knows", that's an answer. We can discuss later.
dveditz: We had policy-uri. Folks outside Mozilla hated it because of latency, and it was in an HTTP header anyway.
terri: Brainstormed other
... Link to discussion?
dveditz: Before the WG.
grobinson: policy-uri being removed from Firefox. Latency.
bhill: search the list (sorry
there's no pointer). There was discussion when opening
... Application use cases were described.
terri: I think I was around for that.
bhill: Next call in two
... IETF meeting! Exciting! Security and privacy next week in London!
<freddyb_> minor note about process: is it possible to send the notes (or a link to them) to the public-webappsec list?
bhill: Participate remotely!
<freddyb_> fwiw, I found them hard to google :-) maybe it's just me though
<freddyb_> but it would make the outcome of the call more transparent too