WebAppSec WG Teleconference 26-Feb-2014

26 Feb 2014


See also: IRC log


+49.162.102.aaaa, terri, BHill, [GVoice], gmaone, grobinson, glenn, mkwst, ekr, PeteF, +1.831.246.aacc, dveditz
bhill2, ekr
Mike West


<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

Minutes approval

<bhill2> http://www.w3.org/2014/02/12-webappsec-minutes.html

bhill: Objections to last time's minutes?
... Approved!

Agenda Bashing

bhill: How do we get subint to FPWD?

dveditz: Is redirection part of the leakage discussion?

mkwst: yes.

Open Actions Reveiw

<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.

Call for consensus on UI Security LCWD

<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

Paths, Redirects and information leakage in CSP

<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.

Extension note text in CSP

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
... "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 [recorded in http://www.w3.org/2014/02/26-webappsec-minutes.html#action01]

bhill: Should remove the 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

Summary of Action Items

[NEW] ACTION: mkwst to remove [recorded in http://www.w3.org/2014/02/26-webappsec-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-03-10 21:39:31 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]