See also: IRC log
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0128.html
<PeteF> +1.315.849.aabb is Pete Freitag... just listening in
<ekr> [Mozilla] has ekr
<bhill2> Scribe: Mike West
<bhill2> Scribenick: mkwst
<bhill2> http://www.w3.org/2014/02/12-webappsec-minutes.html
bhill: Objections to last time's
minutes?
... Approved!
bhill: How do we get subint to FPWD?
dveditz: Is redirection part of the leakage discussion?
mkwst: yes.
<bhill2> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner
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.
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0092.html
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.
<gmaone> second
gmaone: seconded.
bhill: Objection to unanimous
consent?
... None heard. LCWD!
<bhill2> RESOLVED: UI Security to be advanced to Last Call Working Draft
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0127.html
bhill: Proposals from Mike,
Michal, etc.
... summarize?
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
mkwst: Summary.
... 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
document.
... 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?
... Twitter?
bhill: Folks I've talked to find
reporting useful.
... 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? :) )
grobinson: Third-party
additions?
... Don't want to tacitly accept malware.
... "User-instigated third-party additions"?
bhill: Wide leeway,
non-normative.
... 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
3.2.5.17.
... "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 3.2.5.17 [recorded in http://www.w3.org/2014/02/26-webappsec-minutes.html#action01]
bhill: Should remove the 3.2.5.17 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
as well?
... 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
ideas?
... 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
1.1.
... Application use cases were described.
terri: I think I was around for that.
bhill: Next call in two
weeks!
... 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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Mike West Found ScribeNick: mkwst Default Present: +49.162.102.aaaa, terri, BHill, [GVoice], gmaone, grobinson, glenn, mkwst, ekr, PeteF, +1.831.246.aacc, dveditz Present: +49.162.102.aaaa terri BHill [GVoice] gmaone grobinson glenn mkwst ekr PeteF +1.831.246.aacc dveditz Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0128.html Got date from IRC log name: 26 Feb 2014 Guessing minutes URL: http://www.w3.org/2014/02/26-webappsec-minutes.html People with action items: mkwst WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]