WebAppSec WG Teleconference, 13-Aug-2013

13 Aug 2013


See also: IRC log


DaneshIrani abarth bhill2 devditz ekr garrettR gmaone grobinson jeffh jww abarth mkwst_ neilm puhley tanvi tlr wseltzer
bhill2, ekr


<bhill2> wendy, is that a joke, or have you recently moved?

<wseltzer> bhill2, I just moved, and my "11 am" Verizon appointment turned into 4:30 pm

<ekr> I am not sure if I am Mozilla or Mozilla.a

<ekr> Doubt it matters

<bhill2> agenda: http://lists.w3.org/Archives/Public/public-webappsec/2013Aug/0032.html

<bhill2> zakim IPcaller is dveditz

<dveditz> thx

<bhill2> argh

<bhill2> scribenick: mkwst_

<jww_and_abarth> We're trying to dial in but are being told that our pin is invalid. Anyone else having trouble?

<bhill2> 92794

<bhill2> we should still have a few lines available

<jww_and_abarth> okay, seems like we're dialed in via Adam's cell

Agenda Approval

<bhill2> http://www.w3.org/2013/07/16-webappsec-minutes.html

bhill2: Approve minutes?
... Approved!

Action items in tracker

<bhill2> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner

bhill2: ACTION-141, abarth.

abarth: Talked to Anne. Don't quite see eye-to-eye.
... Issues around workers.
... Will discuss further.

bhill2: ACTION-143, erorr handling behavior.

abarth: not yet.

bhill2: ACTION-144

abarth: Same as ACTION-141, blocking 141.

bhill2: ACTION-145, done?

abarth: Done!

<bhill2> trackbot CLOSE ACTION-145

<trackbot> Closed ACTION-145.

bhill2: ACTION-124, did that yesterday.
... New repository next to the CSP one for CORS (on GitHub).
... Added tests for various statuses that should be treated as success.
... 308 is implemented interoperably, as well as 20x codes.

<bhill2> trackbot CLOSE ACTION-124

<trackbot> Closed ACTION-124.

bhill2: Look good to go for moving to PR.
... Leave next two open.

<bhill2> trackbot CLOSE ACTION-147

<trackbot> Closed ACTION-147.

bhill2: neilm proposed hash text to the list, done.
... ACTION-135, probably not going to happen. troessler is moving from the W3C to Google.

<bhill2> trackbot CLOSE ACTION-135

<trackbot> Closed ACTION-135.

bhill2: troessler is amazing, btw.
... dveditz and mwest haven't done their work.

<bhill2> action to bhill2 get patent release on referer control proposal from LAFS authors

<trackbot> Error finding 'to'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.

mikew: Do I need to wait for the referrer policy to be proposed on the list?

<bhill2> action bhill2 get patent release on referer control proposal from LAFS authors

<trackbot> Created ACTION-148 - Get patent release on referer control proposal from lafs authors [on Brad Hill - due 2013-08-20].

bhill2: I'll follow up with them to ensure they propose it under the patent policy.
... Agenda bashing.
... Anything?

mikew: Maybe the stack stuff re: the JavaScript API?

New script hash proposal

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Aug/0031.html

bhill2: Sure, we can touch on that.

neilm: Has anyone had a chance to look at the proposal?

bhill2: Might have been simpler not as a diff.

neilm: Ok. I think I addressed all the comments that came up, and went against some of the choices we made.
... Willing to discuss each and all of them. UTF-8, for instance.
... All valid JavaScript code falls into UTF-8, anything else is data, and shouldn't be in a script tag.

abarth: Issue in DOM Core. the contents of the script tag are represented as a sequence of ... ?
... not all those sequences can be represented in utf-8.
... if you do that, you'd always fail the hashes, which is fine with me.
... think of it as a pipeline.
... bites on a wire. encoding document is in transcode those bytes into code points.
... put those code points into the DOM, where they're just a string of 8 bit items.
... javascript can screw with those items as will.
... weird edge case.
... might be able to simply say that those don't run if we use hashing.

dveditz: one script modifies another before it's hashed?

abarth: script is half-represented in the dom before execution. another script can manipulate before execution.
... using utf-8 is fine. just say that if the thing you're checking fails to decode as utf-8, it should autofail the hash test.

deveditz: only perform the hash after the script is in the DOM? not the literal bytes?

abarth: there's a moment in the spec where the script is executed.
... at that moment, we'd want to capture the data in the DOM and check the hash.

neilm: I offered a bytes on the wire option.

abarth: that's hard.
... bytes stream slowly, half-built tag. just data in the dom that can be manipulated, which means that what you execute might not be what you got over the wire.

neilm: might also be easier for developers if we use the DOM representation.

abarth: replacement characters, for example.

neilm: proposed only supporting SHA-256.
... crypto agility is a problem, but maybe not a big enough problem to override the simplicity.
... rfc6920, no truncation, drop content-type.
... if you're producing dynamic javascript, we can't save you. might be reasonable to allow truncation.

???: regarding agility, perhaps SHA-256 at minimum?

???: "Support this as a minimum, perhaps in the future support something better."

<bhill2> who was speaking before ekr?

ekr: mistake not to support some kind of agility

dveditz: syntax needs to be extensible.

neilm: syntax is extensible, lots of complexity with multiple hashes.
... matches one hash but not the other, etc.
... perhaps only support only one hash type per policy?

tanvi: makes sense.

dveditz: what happens if the policy specifies a hash that the user agent can't deal with?

neilm: fail closed. if you can't support it, you can't validate it, and you can't execute it.

bhill2: CDN + developers = multiple hashes in a policy is likely to happen in the wild.

dveditz: how do multiple headers work?
... match each policy? in that case, we'd fail one of the policies.
... at least if we're trying to shoehorn this into script-src.

bhill2: how to deal with unsafe-inline and script-hash?
... does a different directive name make that easier to deal with?

???: source expression has a lot of benefits. is a clear representation.

dveditz: we do have to worry about forwards compat.

neilm: if there's a hash, we'd discard unsafe-inline in browsers that support that.

dveditz: two headers?

abarth: per-policy basis.
... for a given policy, we'd ignore unsafe-inline if nonce/hash is present.

???: <echo>

???: if hashes/nonces only whitelist inline resources, then there's no usecase. if they can annotate external resources, then there's a usecase.

mwest: nonces are useful for passing ability to inject script to third parties.

tanvi: script hash might be useful for external content. may want to ensure that the script you're pulling is the script you thought it was.

dveditz: is the web ever going to have a content integrity spec?
... perhaps we should simply do that rather than making script-hash do that work.

bhill2: we have that in our charter.
... start simple, would suggest to kill unsafe-inline when hash/nonce is present.

dveditz: still juggling nonce and hash.

bhill2: strong preference to do only one. hash seems to have more going for it.
... will need a more formal CfC.

dveditz: hash is more verbose. nonce is easier to screw up (forgetting to randomize, reusing), does make it possible to pass capability to third-party.
... they only have to be passed the nonce, rather than them passing the hashes to you.

abarth: settle on a script-hash proposal, implement it, see if folks like it.
... users like twitter can give us feedback. twitter sounds like it would prefer hashes.
... google has some internal customers that we could also ask.

neilm: would love to experiment.

abarth: i worry that hashing looks great, but will be difficult to implement, bloat headers, etc.
... would be good to experiment to see how it works in the real world.

bhill2: moving on, let's skip to suborigin proposal.

Suborigins Proposal

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Aug/0020.html

jww: hi!
... suborigin policy.
... idea is to add a primitive to the browser to allow hosts to separate origins to compartmentalize their applications.
... per-page suborigins.
... http response header will give you the name of a suborigin.
... 4th component of a traditional origin.
... could be a CSP directive, could be a separate header.
... suborigins can communicate with other origins via CORS or postMessage.
... no permissions that a normal page would have. similar to an iframe sandbox.
... same set of limited things they could access, but named, so easy to communciate with.
... could add permissions over time if that makes sense.
... document online: http://www.chromium.org/developers/design-documents/per-page-suborigins

tanvi: would adding a name to a sandbox solve the problem?

abarth: outer page can force a sandbox. don't want outer page to be able to name the suborigin.

jww: only way to enter a sandbox is via an http header. server only.

dveditz: would have to not honor it if in a meta tag.

bhill2: alternative strawman, sandbox directive ... <echo>.
... concern with suborigin is that it's an additional string. flash, java, plugins, and http that isn't the DOM don't respect it.
... might be able to solve it in a different way that doesn't break plugins' expectations.
... new field changes expectations for existing projects.

jww: 1. plugins and etc. don't know about suborigins. that's why we're starting off without plugins in the suborigin (similar to sandbox).
... 2. we talked about wedging suborigin into the origin as it stands. afraid of how this would (from a UX perspective) work in the address bar for instance.
... could inadvertently expose to the user, which they wouldn't understand.

bhill2: sandbox origin is never exposed to the user.

tanvi: would cookies be extended to have a suborigin flag?

jww: we said no cookies in the suborigin, would have to communicate with main origin to get cookies.

dveditz: cookies are tricky. if you don't honor cookies, things will break.

abarth: cookie http header != document.cookie JavaScript API.
... iframe sandbox still sends HTTP header. javascript API is blocked.
... something like that might make sense here too.

tanvi: cookies specific to suborigin?

dveditz: already don't follow same-origin policy.

mwest: cookies sent with request, can't determine that beforehand if the page would respond with a suborigin.

abarth: similar to sandbox. just adds ability to name the sandbox.

mwest: that's valuable. was only able to do something similar with message ports. suborigin seems cleaner.

tanvi: browser would treat request as same-origin, right?
... cookie sent, treated as that origin.

abarth: this is more about how to treat the response from the server.
... very client-side based mechanism.

mwest: if this is something we're interested in, i'd like to see it as a csp directive rather than bloating the header space.

jww: sure i can put together a proposal.

dveditz: backwards compat?
... old client will ignore it.
... frames would be able to talk in old clients.

deveditz: new clients would be protected.

jww: right.

mwest: similar to iframe sandbox in that regard.

dveditz: how does this impact postMessage.
... named suborigins?

jww: would need to specify suborigin.
... suggested something in the proposal, don't feel too strongly about it, but we'd need to include somethin.

bhill2: that's why i think combining it with today's origins might be a good idea, rather than rippling the change through the whole platform.
... out of time, perhaps we can get to the other things next time?
... CORS, will deal with CfC next time as well.
... thanks!

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2017/02/15 22:32:51 $