See also: IRC log
<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
<bhill2> http://www.w3.org/2013/07/16-webappsec-minutes.html
bhill2: Approve minutes?
... Approved!
<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?
<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.
<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!