<trackbot> Date: 25 April 2013

<wseltzer> scribenick: abarth

starting with open issues

starting with CSP 1.0

then moving to CSP 1.1

Should we be considering refining the bookmarklet language in 1.0 or 1.1?

mkwst_: I think we shouldn't change 1.0 at this point

dveditz: I agree
... Not enough people are using CSP to know whether this is a real problem yet. it's speculative at this point
... the spec gives us the flexibily to change our behavior if needed

bhill2: most of these issues are 1.1 issues

dveditz: what about column numbers?
... it would be nice to get the column numbers into 1.0

abarth: would that trigger a bunch of process?

dveditz: depends on the test suite

tlr: adding new features in CR would be a problem
... this feature would be borderline

bhill2: other outstanding change would be allowing cross-origin JSON posts
... doesn't appear elsewhere in the ecosystem
... could change the mime type or use an anonymous fetch
... that would trigger some process in the CR too

tlr: the point of CR is for the spec to be stable and implement it
... the entrance to PR is when you have test and interoperability reports
... if there are a set of changes that affect the test suite, you should consider going back to a Last Call and then jump back to PR immediately
... making a bunch of changes that change interoperablity isn't so good, but it's not a hard rule
... would a change be likely to invalidate previous review? is a key question

bhill2: to the extent that it would change interop, it would change people who are processing reports

dveditz: realistically, I don't think anyone cares about the mime type they're getting

abarth: I think this is a minor issue

dveditz: hard to discuss because annevk is the person who raised the issue and he's not here

bhill2: I think he's concerned about a history of working with CORS
... this doesn't follow the rules we set out for CORS
... I think there's a good reason to make it an anonymous request

dveditz: the referer header is in the body of the request even if we strip it from the HTTP headers

bhill2: I think annevk wants us to use the anonymous version of the fetch algorithm
... I think that's a reasonable request
... It wouldn't lose a lot
... it wouldn't break any existing implementations

dveditz: in the back of our minds at moz, we were thinking that the cookies with the report on some site would help sites debug the issue
... if its reflected, it might be in the request
... but if its stored, its helpful to know which account is concerned
... but that's mostly useful for same-origin reports

bhill2: we could make it anonymous if its cross-origin and non-anonymous if it's same-origin

dveditz: if the site is having problems they could move the report-uri to the same site to debug more

bhill2: does that sound reasonable and appropriate?

neil: that works for me

abarth: I think that behavior makes sense, it's just a question fo whether it's worth re-opening 1.0

mkwst_: the cost of re-opening 1.0 depends on how long it will take to close it again

bhill2: do we think this is going to generate objections to moving to PR?

tlr: can you explain the context in more detail

dveditz: (explains how report-uri works in the spec)

<wseltzer> [https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-1.0-specification.html]

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

<bhill2> is the thread that started this discussion

tlr: sounds like a completely reasonable change (to start with)
... my recommendation would be that if we all think it is the right thing to do, then make the change and then look at the total set of changes to see if we need to re-open the spec
... In any case, I think we can keep the delay down to four weeks

dveditz: I think the set of people in the room would rather make the change in the 1.1 spec but we're worried about running into resistance in the tag

wseltzer: has their been a privary review of this issue?
... this might be something they'll pick up on

neil: At the risk of complicating this further, we could consider relaxing the notion of same-origin (e.g., http to https)
... The concept of upgrading security

dveditz: this is an issue with the moz implementation

neil: this issue would arise again with this change

dveditz: the simplest way to make the change is in the CORS spec, and there an origin is an origin
... we certainly wouldn't want to go the other way

<tlr> transition requirements: http://www.w3.org/2005/10/Process-20051014/process.html#transition-reqs

abarth: I think it makes sense to use the same origin concept everywhere

tlr: to the extent to that you can sell it as a bug fix, you can get it in
... but it's getting sufficient discussion that it should probably go back to last call
... if everyone is on board, then it's easier, but if it requires deeper thought
... if there are a sufficiently large number of these bug fixes, then that changes things

bhill2: I don't think we have any other issues (other than typos)
... I think it's a small thing. it's just a one sentence change. I'd prefer to see it in 1.0

abarth: I'm becoming convinced that we should fix it

tlr: what about WebKit?
... we used to have them represented via the chrome team

bhill2: ekr has reached out to othermjs
... we're encourging them to send someone

tlr: one question for this is whether the webkit folks are on board

dveditz: this will be an issue with 1.1

bhill2: it's likely we'll find bugs in 1.0

mkwst_: sorry :(

<mkwst_> abarth: :)

tlr: can we communicate with them?

abarth: I can do that right now, but I'll have to stop scribing to do that :)

bhill2: That's it for 1.0 issues that are open
... except for test cases

<bhill2> http://www.w3.org/2011/webappsec/track/actions/open

bhill2: let's go though the tracker for 1.0 issues

<bhill2> we'll start with tracker for 1.1 issues, return to agenda summary

sorry, 1.1 issues

<wseltzer> action-97?

<trackbot> ACTION-97 -- Daniel Veditz to propose spec language for policy-uri directive -- due 2012-11-09 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/97

dveditz: I don't know if we have an agreement to do policy-uri, but people inside mozilla want to use it
... the spec would be to treat it as if it were an additional header
... the old language said that there couldn't be any other header, but that's likely a mistake

abarth: I think the issue is that it's s sync request
... do the folks in moz want to use it on the network, or for packaged apps

dveditz: the folks who want to use it are the marketplace

abarth: one thing we could do is put it in the spec for now and get some implementation feedback

dveditz: we could resrict it to only working in the header (no the meta tag)
... I guess it's no worse than blocking on a script tag

bhill2: I wonder if we look a little bit ahead to proposals for http2, we can see header compression, which helps here
... for me the interesting use case is whether it can be cross-origin
... if it's cross origin, we you can outsource it, which unlocks some interesting use cases
... do you have thoughts on that?

dveditz: I had assumed it would be same origin
... but it might be interesting

puhley: would that end up with a chicken-and-egg problem

dveditz: you could use the policy-uri statement as the grant

bhill2: I think sites are smart enough to decide whether they want to take the latency hit
... but http2 might make the whole thing not worthwhile

dveditz: I can imagine a bunch of sibling domains with a central server that sets the policy
... but we don't have good ways of telling which domains are siblings
... we do have some huerstiics

abarth: I think it's worth experimenting with

dveditz: this is an opt-in thing

abarth: if we do allow crossorigin, we should use CORS so that we know the other origin is ok with you using their policy
... one way to make progress is to put it in the spec for now, try it with moz marketplace, and get back some data from their experience

neil: I haven't thought about this feature much, but the concept of sending these across domains is kind of scary

bhill2: is that different than an iframe

dveditz: can you clarify what you're worried about

neil: the policy is third-party, but the report-uri is first-party again
... and the third-party gets compromised

bhill2: I think if you're going to get your policy from a third-party, you've got to trust them
... I think it's interesting to consider for the spec is whether we're creating opportunities for folks to make the ecosystem more secure
... many folks might like the opportunity to outsource this tricky stuff

ACTION-115?

<trackbot> ACTION-115 -- Adam Barth to raise ISSUE-15 on the mailing list -- due 2013-02-05 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/115

mkwst_: the 1.1 spec certainly says some things about blob

issue-15?

<trackbot> ISSUE-15 -- How to handle srcdoc, blob:, di: and ways of directly creating content -- open

<trackbot> http://www.w3.org/2011/webappsec/track/issues/15

abarth: the srcdoc would inherit the policy from its parent

<wseltzer> [1.1: https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html ]

dveditz: its covered by implication, but we should be explicity

abarth: someone just needs to work through the spec and propose how to handle all these cases

dveditz: oh, you mean where does it get the policy from
... for data URIs, we get the policy from the parent document

abarth: we should do that for srcdoc too
... we just need to write that in the spec somewhere

dveditz: there's an interop issue because different user agents treat data URIs different w.r.t. security

action-109?

<trackbot> ACTION-109 -- Daniel Veditz to add spec language to CSP 1.1 regarding certain directives not honored in META -- due 2013-01-22 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/109

dveditz: I sent mail to the list about that already
... once I get the password, I'll edit the spec to incorporate that

bhill2: we have some spec text in the spec already
... we ignore report-uri

abarth: on the list we talked about ignoring sandbox too

dveditz: and for frame-options
... the browser needs to know about these at the beginning
... for frame-options and sandbox

abarth: we actually support an x-frame-options meta tag, but I think it's find to skip it for CSP

bhill2: idea to stop honoring the meta tag after the document reaches the "interactive" state

abarth: I don't remember when the doc gets to interactive

mkwst_: google web toolkit might use this technique

bhill2: dveditz previously thought that was crazy, do you still think that?

dveditz: event allowing it in the head allow some things to be loaded

<mkwst_> document.readystate = "Returns "loading" while the document is loading, "interactive" once it is finished parsing but still loading sub-resources, and "complete" once it has loaded." according to MDN.

dveditz: that's more defensible than allowing the document to becoming active
... I think having in the header is unsafe, but probably defensible in some circumstances
... if the meta tag comes late, how do we know if it's an attack?

bhill2: is this less necessary now that we allow paths?

abarth: I think it's mostly folks the eval is the real issue

neil: would the DOM API help with this?

abarth: yes, especially if we let the "is eval allowed" state be mutable via the DOM API (either both directions or only in one direction)

action-121?

<trackbot> ACTION-121 -- Adam Barth to email the list with the generic src-nonce proposal (i.e., not specifically for each thing that could be srced) -- due 2013-02-19 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/121

mkwst_: we got hung up on the syntax
... I can take an action to make a strawman proposal
... we want to leave some room in the syntax for a hash potentially
... I think someone was going to put together an experimental implementation, but I'm not sure how far that got

bhill2: we had some language for how to calcuate it for script

dveditz: how does it interact with inline?
... does the nonce need to be on everything?

abarth: the nonce is an argument to the script-src directive

<bhill2> <script nonce="foo">alert(1)</script>

abarth: so you can list whatever you like
... e.g., script-src 'self' 'nonce-foo'

<bhill2> <img nonce="foo" src="data:afaewrq3r432q"/>

abarth: which means you could either load from yourself or with a nonce

mkwst_: most valuable for script and style, but we could support it for the other types

bhill2: maybe we should just do it as a generic source type
... if I want to use data URLs, then if I whitelist all of data, that kind of defeats the point

mkwst_: Yeah, i think that makes sense
... its probably easier to specify that way anyway
... I'm happy to add it if there's consensus to add it

neil: are we worried about compat?

abarth: I think we want to make sure that content targeting version X continues to work in versions >X as well

but I don't think we need to constain content targeting version X to also work with version <X

bhill2: do we want a length requirement for the nonce?

dveditz: the important thing is that it's not constant

bhill2: the spec already requires that

niel: that's different than for hash

jeffh: the way i've seen this done before is to have a guideline in the spec
... but not necessarily a strict requirement

tlr: have we thought about interactions with cache?

abarth: it should work fine with caching

tlr: the server should know that the client might get an "old" nonce from the cache

wseltzer: yet another tracking mechanism!

<tlr> well, the server might not know that -- that's exactly my point. :)

tlr: it's no worse that a global javascript variable
... (sorry, that's what I meant---I just scribed it poorly)

action-125?

<trackbot> ACTION-125 -- Mike West to investigate WHATWG spec text vs RFC 3986 for normalization in CSP -- due 2013-04-02 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/125

bhill2: I'm going to assume that this action is closed

mkwst_: yes

bhill2: ok, i'm going to make it as closed

issue-34?

<trackbot> ISSUE-34 -- Discuss use cases / risks of script access to CSP information, solicit specific public comment on this feature with FPWD -- open

<trackbot> http://www.w3.org/2011/webappsec/track/issues/34

<bhill2> https://www.w3.org/2011/webappsec/track/issues/34

bhill2: one of the proposals was to add an HTTP only directive
... that would prevent scripts from getting access to the content of the header
... more importantly see what the report-uri is set to

dveditz: do you mean by using XHR to request the page itself

bhill2: no, I mean via the DOM APIs

niel: what's the threat we're trying to protect?

dveditz: the nonce could be sensitive

mkwst_: you can just read it off a script tag that has it

<jeffh> whether nonce value is a "strict requirement" or not spec-wise depends on the nature of the spec -- for example in a crypto spec it'd likely be MUST level requirements, here it's likely "SHOULD at least" with some further guidance for implementors

bhill2: maybe the report URI?

dveditz: who are you hiding the report-uri from?
... you can just load the page yourself, it's unlikely to change

bhill2: the site might have a user unique value encoded into the report URI

mkwst_: also related to extensions that inject policies
... maybe the page wants to prevent the page from getting reports via the DOM event

^^^ the extension wants to prevent the page

bhill2: maybe the security policy group is not 100% friends with the developers

abarth: that's why the DOM API is read only

dveditz: we also don't allow a meta policy to be added if there's already an HTTP policy

bhill2: is there a use case for having report-uri in the DOM API at all??

mkwst_: I'm not sure there's a good use case, but alex russel thinks we should have a robust API that lets you read everything

abarth: If we're going to make it mutable, I'd much rather add the ability to turn off eval (if it's currently enabled). that seems way more useful than being able to add report URIs

dveditz: currently the spec is just a read only version of the effective policy

bhill2: if I wrote an ad block that work via CSP by querying the DOM API
... the page could figure out if it were active

abarth: they could also just trying the request

dveditz: what's the use case for the API at all?

abarth: it's to let library authors know what the rules are

dveditz: the use case for the first three properties seem reasonable
... the per-resource ones seem to have weaker use cases
... I'm not sure what "is active" is for

bhill2: maybe isactive is good as a early-exit from querying

neil: we definitely want the isactive available

dveditz: neil: do you need the other bits?

neil: we just need the first four

bhill2: maybe the http only option resolves this

dveditz: that means we'd have to lie about the four at the bottom

abarth: if there aren't strong use cases, maybe we should trim down to just the first four rather than adding yet another nob to turn

mkwst_: I think alex is going to be mad at me :)
... we can try it and then circle back around if there are compelling use cases

bhill2: maybe ask alex to email the list if he doesn't like the change

dveditz: I'm really opposed to exposing the list of report URIs. there needs to be a really compelling use case.
... I'd like to avoid adding an HTTP only botch to work around this problem we're creating for ourselves
... http only in cookies is a mistake
... the page doesn't need to know everything
... do we need to hide CSP headers from XMLHttpRequest?

niel: would and XHR response with a CSP header have any effect?

dveditz: I'm not sure if it's going to be specific to the user... maybe something in the report uri
... by default XHR makes all the headers available, but some are blacklisted

abarth: you can always load a same-origin page in an iframe
... cross-origin won't get credentials

dveditz: that's true

bhill2: did we already just resolve this issue?

abarth: I don't think it's an issue

dveditz: my main worry was the nonce, but that's really the site being silly

bhill2: if you can XHR, then you can already get this information from the body

niel: does this negate removing the DOM APIs?

abarth: not for extension-added CSP, which won't show up on the network

dveditz: our privacy folks were concerned about exposing information about extension-added CSP

bhill2: let's take 5 and then come back

<mkwst_> (rejoining in a moment)

<bhill2> you there mike?

<mkwst_> i am.

bhill2: should we talk about mutability?

abarth: I think the main thing is wanting to turn off eval if its already on

dveditz: Also inline script and inline style
... the risk is that a script coudl break the pag
... but that's already possible

<mkwst_> (would you mind speaking up a bit, dveditz?)

dveditz: it's less safe than starting off with everything off, but it can be hard to root out eval from all the libraries

<jeffh> may want to splain in that action wrt "one-way mutablility" what that nominally means

dveditz: but some libraries use eval on an on-gong basis

<jeffh> oh ok, it's getting noted

bhill2: should we restrict to the head?

<jeffh> "be able to turn off (bunt not on) eval, inline script, incline css

<jeffh> "

abarth: I'm not sure that's needed. the reason to limit meta to the head is to make sure you know who's giving you the policy

mkwst_: the current "API" is to inject a meta tag, which also lets you further limit the page (but not loosening)

dveditz: do you mean once the page has loaded?

mkwst_: yes

abarth: I think that's a workaround for the lack of a real API. we probably want to have a real one instead

mkwst_: yeah

<wseltzer> action-127?

<trackbot> ACTION-127 -- Adam Barth to add one-way mutability to policy points exposed in script interface -- due 2013-05-02 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/127

mkwst_: I'll put together a strawman and then we can have deeper discussion on the list
... one option is to let the page supply a textual policy
... another option is an explicit toggle

neil: I line of like the explicit toggle

jeffh: me too

abarth: one possibility is to make the attributes not be read only but then ignore writes that we don't like

mkwst_: what about limiting the scope of sources?

dveditz: it seems cleaner for you to specify the subdirecty to start with

mkwst_: I can imagine wanting to load libraries at the beginning but then dropping them later

bhill2: that works with the meta tag, maybe we should keep that

mkwst_: I'm not sure its worth making it that complex for starting
... we can start with the four-points, but we should keep in mind what use cases we're not addressing

dveditz: I can see the use, but our concern about the meta tag is that it could be an injected attack
... one way to address our concern is to have a non-meta bit in the policy
... I'm not sure if that make sense

bhill2: I'm not sure dropping sources is as important any more now that we have path restrictions

jeffh: and the hash

bhill2: now that we're more grainular, now load and then lock isn't as needed

abarth: IMHO, we should just start with the first three and then add more in the future if needed

mkwst_: It's not that complex to implement

<bhill2> https://www.w3.org/2011/webappsec/track/

mkwst_: but I think it's fine to start with these and move on from there

<bhill2> https://www.w3.org/2011/webappsec/track/actions/127

<mkwst_> i'll just add "it's not that complex" to my list of things i might regret saying in the future. :)

dveditz: the spec currently says that if you have a header, then no meta is allowed
... do you want to re-open that issue

?

dveditz: I think that's something we should discuss on the mailing list

mkwst_: I think if we have this API, then there's much less value to letting people injection meta tags

abarth: you mean meta tags in the precence of HTTP headers, no in the absence

mkwst_: correct

issue-36?

<trackbot> ISSUE-36 -- Are we interested in considering script-hash as a CSP 1.1 directive? -- open

<trackbot> http://www.w3.org/2011/webappsec/track/issues/36

bhill2: seems like a good idea inline with nonce
... probably don't want a "script-nonce" directive. instead use a syntax more like a source that can apply to other types

dveditz: how is this related to content integrity

bhill2: there are potentially interesting interactions
... we could say hash applies to an external script

tanvi: I think it's more interesting for remote content
... nonce might be more appropriate for inline content

bhill2: hash works well for static documents

tanvi: with hash, CSP header doesn't need to have every single source listed
... If the javascript changes, then the web sites will break

neil: it should be pre-computed on deploy

tanvi: I'm worried about remote content
... e.g., google-analytics

bhill2: introduces brittleness that we don't have with URIs

tanvi: maybe we should just keep that in the content integrity spec for later

bhill2: the proposal on the table is to have hash for inline content only
... you don't think it's useful for line content

tanvi: I don't think it's that useful for inline content

neil: it reduces the complexity

bhill2: e.g., CDNs

<bhill2> abarth: one option is list all hashes in policy

<bhill2> ... other is that script needs to have hash value to execute for remote scripts

<bhill2> dveditz: second is to allow author to relax mixed-content ui or specify a particular version of a resource

dveditz: doesn't protect from injection

bhill2: you're talking about the subresource integrity deliverable

abarth: seems that the two are related

<bhill2> script-src hash:abcde

abarth: different use cases, but you want to at least use the same hash algorithm

<bhill2> let's say abcde is the hash of : "alert(foo)"

script-src 'self' hash-iuneinwoen

<bhill2> there are a couple of options

<bhill2> script-src hash:abcde could match:

<bhill2> <script src="foreign.com/fooalert.js"> where the content body is "alert(foo)"

dveditz: that would be more difficult for moz to implement because of when we make our decision about when to load something

<script hash="abcde" src=....">

dveditz: it would mean you could make requests to domain that are otherwise not allowed

abarth: one way to do this is to have document integrity specify how to hash subresources
... and CSP just says which of those hashes are allowed

dveditz: hashes might be shorter than paths

bhill2: if i'm just going to include a single remote resource, I can use the (shorter) hash rather than the (long) URL

<bhill2> test

dveditz: doesn't acutally help with CSRF

tanvi: it's not just CSRF, it's also the cookies and other things in the clear

dveditz: by including the hash, you've loosened some of the restrictions
... because the requests go out

bhill2: similar to loading from my own site
... but it has a different referer header
... maybe that's a reason not to have hashes apply to remove resources

tanvi: maybe that's in a separate spec

bhill2: so if we did hash, it would only be for inline content

abarth: so, CSP's hash is about whether inline resources excute
... document integrity is about the integrity of remote resources

(nods around the room)

bhill2: this proposal lets us be more creative or compact with the syntax
... if its only referring to inline content, we don't need to collide with URI trickiness

jeffh: yeah, that's something to think about

bhill2: lets get some food, and talk while we eat a bit

<jeffh> file:///home/hodges/doc/IETF/internet-drafts/draft-farrell-decade-ni-10.txt

<jeffh> ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q

<bhill2> let's give it another 20 minutes here on a few more csp 1.1 issues

mkwst_: ^^^

<mkwst_> thanks, abarth.

bhill2: base-uri
... (looking at the spec text for base-uri)
... we had talked about making this a reverse policy
... it would be enforced by default

mkwst_: I'm vaguely in favor of that

abarth: we could experiment to see how big an impact that would be

mkwst_: my gut feeling is that it's miniscule, but we can measure and get an estimate

bhill2: to be reasonable effective, we'd have to specify them all the time, which seems bloaty

abarth: we could also try to figure out how many sites would benefit from this directive
... there is an attack scenario, the only question is how prevalent it is

bhill2: (is entering an issue for this topic)

dveditz: hixie used to run these sorts of experiments on google search data

<wseltzer> issue-48?

<trackbot> ISSUE-48 -- injection of a <base> tag to change effective location of relative resources -- raised

<trackbot> http://www.w3.org/2011/webappsec/track/issues/48

tanvi: what would the default be?

abarth: we could either main the default 'self' or match default-src

tanvi: I think using 'self' by default is a good idea

dveditz: 'self' is what HTML defaults to
... so it would be good to match that

abarth: the first question is the compatibility risk

dveditz: maybe that should come into play if your policy has one of the URL loading diretives

bhill2: on to response code in reports

niel: This was my request

neil: it was useful only in one specific case
... the use case is that we had a 404 response that triggered a report
... that was the only time it ever came up, but it's another data point

mkwst_: it doesn't seem to expose any information that's privacy relevant
... so it seems like there's no harm but it's potentially useful

abarth: maybe we should wait for the second person to ask for it?

neil: it was useful in one situation. it hasn't come up again

bhill2: I'll add it as an issue. we can decide to punt to 1.2 when we're doing a final review of issues

<wseltzer> issue-49?

<trackbot> ISSUE-49 -- add http response code to report? -- raised

<trackbot> http://www.w3.org/2011/webappsec/track/issues/49

bhill2: next up: plugin-types and iframes

abarth: one option is to have the "plugin document" that's created for the plugin inherit the plugin-type directive---but need to study how this works in the HTML spec

<wseltzer> action-129?

<trackbot> ACTION-129 -- Adam Barth to research and propose spec text for applying plugin-types to iframes -- due 2013-05-25 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/129

bhill2: how about just saying the plugin-types applies to frames as well?

abarth: that makes sense to me, but we need to check exactly how this is modeled in spec-land to make sure the text we write actually does what we think it does

mkwst_: what about differences for how IE specifies plugins

abarth: IE uses GUIDs rather than mime types for plugins. maybe we just need to let the policy contain GUIDs?
... we need to check with MS folks to see what they need here

dveditz: the mapping is in the Windows registry

<wseltzer> issue-50?

<trackbot> ISSUE-50 -- plugin-type directive and media source list for IE CLSID guids -- raised

<trackbot> http://www.w3.org/2011/webappsec/track/issues/50

bhill2: if we don't hear back, I can do the research to figure out what's needed here
... as a first-cut, allowing a GUID is probably good enough

puhley: in the case if plugin iframes, need to understand what parts of the policy inherit

abarth: my proposal was to just have the plugin-types directive propagate

puhley: makes sense

bhill2: 15-20 minute break

<bhill2> mike, we are back

<bhill2> looks like you dropped off zakim

<mkwst_> yeah, hopping back on.

<wseltzer> [restarting]

<gopal> I dropped off the call, will join shortly

<wseltzer> scribenick: dveditz

<wseltzer> chair: bhill

the tahoe-lafts reference is to referer-blocking, discussed as far back as our first face-2-face

<wseltzer> [link: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1890]

bhill2: the strawman would be to restrict referer on non-same-origin loads

abarth: a referer-restricting proposal is on the whatwg wiki

<abarth> http://wiki.whatwg.org/wiki/Meta_referrer

dveditz: we (mozilla) have also had referer-restricting add-ons

abarth: options: none, always, truncate, default (normal behavior)

tanvi: chrome has implemented this?

abarth: yes

tanvi: there's a mozilla bug on this as well

abarth: integrating with CSP is better than a one-off proposal
... we have customers interested in this, one of them is facebook

tanvi: facebook is contributing to the mozilla implementation

abarth: now that facebook is switching to always https there are sites who still need to know facebook was the referring site

<tanvi> mozilla's bug on this - https://bugzilla.mozilla.org/show_bug.cgi?id=704320

bhill2: I'm drafting an action for mike since he expressed interest
... haven't heard any objections, calling that done
... moving on to no-mixed-content

<wseltzer> action-130?

<trackbot> ACTION-130 -- Mike West to draft text on referer control policy -- due 2013-05-25 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/130

bhill2: dveditz calls it ugly cruft and then says he supports the change

<tanvi> there are some objections to the "always" behavior - https://bugzilla.mozilla.org/show_bug.cgi?id=704320#c57

neil: I was confused when we talked about this on the list... what happens when you specify a raw host?

bhill2: lets talk about a new directive "no-mixed-content". will it be useful if browsers support the csp 1.1 spec language

abarth: I was originally a supporter but I think the spec's default behavior is better

neil: I agree [neil originally proposed this directive]

abarth: there are edge cases, csp applies to an iframe URL but not the contents of the iframe. originally no-mixed-content would apply all the way down

<wseltzer> issue-38?

<trackbot> ISSUE-38 -- Discuss no-mixed-content further as a 1.1 experimental directive -- open

<trackbot> http://www.w3.org/2011/webappsec/track/issues/38

bhill2: ok so we'll call that one closed
... last one is json-src/json-sink I proposed
... twitter folks expressed interest in handling legacy URLs this way

neil: sticking with adam's "two requests" policy we can probably drop this -- we don't need it anymore

bhill2: we don't have an ISSUE for that but we can declare it tabled until a customer requests it
... any other proposed directives?

[looking at wiki]

abarth: I have two proposals I mentioned at the beginning of the mtg

<wseltzer> [http://www.w3.org/Security/wiki/Content_Security_Policy]

<bhill2> http://www.w3.org/Security/wiki/Content_Security_Policy

bhill2: we've incorporated all the wiki items from the 1.1 list... looking at experimental
... no-external-navigation looks interesting
... no-user-js (protect against self-xss in the url bar)
... all browsers have implemented that implicitly already

tanvi: we talked about whether it's still needed for "developer tools/consoles"

bhill2: option to restruct srcipt-src to specific content-types
... looking at the list on the screen, is there anyone who wants to see one of these progress further?

tanvi: what about policy-uri?

bhill2: we talked about that earlier, dveditz is drafting spec languages
... I'll take an action to clean up this page
... inclined to look at proposals from zalewski [looking at no-external-navigation on screen]
... time-of-check/time-of-use with the navigation bar changing but the page contents not appearing to
... you have to have script injection to do this, right?

abarth: you can do that in other ways, like named-window navigation. chrome tries to prevent that in different ways
... I'm not sure this attack is super practical (without script injection)

bhill2: you didn't think it was worth trolling through old ideas unless we had more recent expressions of interest

abarth: two more, both from Michal. he likes sandbox in how it isolates various origins, but he's sad because he doesn't know who he's talking to when postMessaging
... "please sandbox this and give it NAME so I know I am talking to it"

jeffh: is this written down?

abarth: yes
... preface -- not saying "we should adopt this", bringing this forward as a useful idea to see what people think

dveditz: what about malicious intentional name collisions

abarth: the proposal tries to address that by having a browser-supplied component
... I can't share this document, I'll try to write up one I can share
... the other, he's having some success deploying CSP in parts of google, but others trying to deploy it is a mess
... half the xss mz sees is server-xss (stored/reflected), the other half is dom-xss
... his proposal is a way to assign a policy per element
... "below this element apply this policy"

<jeffh> https://www.owasp.org/index.php/DOM_Based_XSS

abarth: "turn innerHTML into textContent"
... people have thought about this in terms of a "jail" tag
... but he's thinking in terms of a parsed dom tree -- assume you've parsed the HTML the way the site intended
... "in this subtree don't allow forms"

bhill2: is this a declarative thing in terms of csp or is this a dynamic set of rules ala .mario et al

abarth: he likes the declarative aspect of csp but the global nature of it introduces problems

bhill2: declarative policies can be simpler, but at some point declarative becomes more complex than a simple dynamic hook
... a "reference monitor" script (specified in a privileged place like a header) might be simpler

neil: I like bhill2's proposal better. mz's approach lends itself to static checking
... (a good thing)

abarth: I don't think he's tried any of these, these are just ideas

bhill2: let me find a reference to the gareth heyes approach

abarth: what would you like to get out of the dom monitor, neil?

neil_: haven't thought about it much yet, we're just starting to look into it

bhill2: JSLR is what it's called -- that's something different though
... but mario heiderach has talked about this kind of DOM jailing

abarth: just tossing these out for high-level feedback

bhill2: bring these up on the list for more feedback

abarth: sounds like there was more interest in the first proposal

bhill2: mark still want to talk about bookmarklets? "What does it mean to support bookmarklets?"

mkwst_: twitter and other sources report they're being overwhelmed with reports from blocked content injected by user-intended mechanisms
... clearly we want bookmarklets to execute
... to what extent can we separate the execution of the bookmarklet form the execution of the page in which it lives so it can bypass the page's security policy
... looking for thoughts from others, especially other implementors

neil_: philosophically a user intended the bookmarklet to run

abarth: I think the question is more technical -- how close can we get to that intent, safely?
... what if the bookmarklet calls a function that the page defined?

neil_: if it injects a script that violates the policy it should be allowed to do that

bhill2: the simplest implementation is that if you fire a bookmarklet you turn off CSP

neil_: do you turn it back on again after?

bhill2: if that's the simplest model, is that OK?

abarth: what if it turns off CSP for the whole document, are you ok with that?

neil_: I'm uncomfortable with that -- sometimes these days you never leave a page. turned off from now until forever?
... running a bookmarklet should be like "sudo"

mkwst_: I'm also sympathetic to the idea that running a bookmarklet or extension should be like using "sudo". what are we giving up by doing that?
... bookmarlets should bypass CSP, but if it calls into page codeand that code violates CSP it would get blocked. seems like a nice distinction to make if possible

bhill2: this is the same issue as extensions?

abarth: not quite, extensions have their own context so it's somewhat simpler

mkwst_: in chrome we have the concept of an isolated world where the extension doesn't have access to the content of the page

bhill2: so the current model of a bookmarklet is that it's just inline script injected into a document?
... what if we gave the bookmarklet access to the CSP dynamically?

abarth: libraries and extensions are easier to get changed since there are fewer authors
... but there are thousands of bookmarklets and they don't have updates

neil_: can we infer the behavior from it's actions?

dveditz: neil, do you know this traffic actually omes from bookmarklets vs extensions?

abarth: the translate thing in chrome is something we know about and we're working on a solution

neil_: translate is the one we see mostly, plus lastpass

abarth: maybe we need to convince lastpass to be more like an extension and less like a bookmarklet, and then solve the extension problem

bhill2: is this the end of our csp discussion? any other items?
... we're going to meet with the webapps folks later, they're proposing Web Components
... would make me sad if those are just syntactic suger for <script src=>
... because in that case buggy components from popular providers (e.g. facebook, twitter) could break the web
... I don't have a proposal on how to provide a security boundary, but interested to hear what folks in this room think about that before we head over there

abarth: I agree this is an important issue. I tried to think about it and didn't come up with a solution
... web components have the notion of a "shadow dom" where part of the object is public and part is private. works well with dom nodes but there's only one javascript context
... unappealing from a security POV where we've isolated part of the object and not the scripts

bhill2: not just the page reaching into the shadow dom, it's also the widget reaching out into the page

abarth: good example is a tab-switcher component
... you have a tab-switcher element with some children. from the DOM view that's how it looks, but implementation has lots of hidden code and elements
... you wouldn't want the author of the tab-switcher to be able to look inside the tabs themselves
... the tab-switcher offers "whats the current tab" or "go to next tab" which means there's scvript contact between the two
... in gecko there's technology that could potentially be applied to this problem, maybe dan could comment, but my impression has been that it's difficult
... my understanding is that they're intentionally doing it without a security boundary because they've learned (mozilla XBL experience) that security boundaries are too porous

neil_: you could accomplish the goal using frames and postMessage, but it'd be ugly and janky, right?

abarth: yes, you could do it something like that. it works, but the api designers found it cumbersome ("it sucks")

bhill2: it's nice syntactic sugur but it does so by erasing the security boundary completely
... maybe there's some kind of declarative boundary we could give to components through something like CSP
... I want to at least raise this concept with the WF

WG

abarth: hard to make progress without a technical proposal, and that's what's missing. the webapp WG was sympathetic to the general idea but don't know how to do it.

bhill2: www.w3.org/TR/components-intro/

(old, but links to the latest)

<bhill2> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html

<bhill2> scribenick: bhill2

tlr: we are out of charter by a month, my bad
... new charter is a good opportunity to advertise v.next of CSP and encourage other with interest to join
... will be getting it to the advisory committee in the relatively new future
... but we have one last chance to put additional pieces of scope in if we think it is important
... from today's perspective, are there things people think should be in the charter?
... and I think this is a good braintrust that is important to keep around in the w3c

abarth: in tc39 we are working on string template mechanism
... idea that we can stick an HTML marker in front of a string and it will be "safe"
... not necessarily the right expertise in TC39, maybe here
... official term is "HTML quasi handler"
... something like `hello ${{foo}}!`
... this looks like big xss hole

so what if we put "html" in front of it and it makes it not xss

scribe: we could help explain what that would mean to prevent xss
... or might be `hello <h1>${{name_here}}</h1>`

dveditz: what if this is not in a browser context?

abarth: yes, they are very interested in this, so have a pluggable slot for a quasi-handler that can produce many kinds of output
... so a quasi-handler that understands html and can do it safely is what they think would be nice
... so we can either convince them it is a bad idea, or help them figure out what to put in that box

bhill2: like safeHTML in MSOffice?

abarth: no, because that still produces a string sent over network, in the browser context we can just generate dom nodes directly

dveditz: can still be a string over network, e.g. in node.js

adrianb: have exposed in IE exposed .toStaticHTML that exposes office's safeHTML component
... since IE 8, used throughout web platform at MS
... HTML email, string contexts, etc
... sounds like a good workstream, not sure something producing nodes is a better solution
... given use cases we do see for toStaticHtml, a node tree as a result isn't what I necessarily want to see

dveditz: has been lots of resistance to accepting .tostatichtml in the html standard?
... lots of people have asked for it, not showing up, don't know why

adrianb: to my knowledge, no conversations in the last 2-3 years about adding this

dveditz: people desperately need it

adrianb: possibly last discussion was 4-5 years ago, world is a different place, shouldn't assume absence from current spec suggests anything

abarth: a good problem space for this group to take on, regardless of exact character of solution

adrianb: yes, and there are problems, changing spec, underlying infrastructure for safeHTML is richer than exposed to the browser
... at a high level a good area to engage in

tlr: other ideas?

dveditz: blocking mixed active content, mozilla encountering same problems as chrome / webkit
... 3 major browsers have made different choices as to what gets blocked and not
... maybe incomplete reverse engineering, maybe not knowing who to follow
... might be nice for it to be consistent

adrianb: would value discussion from this community on these choices, e.g. with regard to XHR
... e.g. want to make a CORS request for data on an insecure endpoint, but maybe not sensitive information... e.g. weather data

abarth: would be good to have a spec to point to documenting these choices

adrianb: new use cases coming along because of webcrypto, expecting to use the API on the client, but don't want to deploy this on SSL endpoints
... not lots of sites currently broken, but things we want to support that are currently blocked

dveditz: we talked with CSP about how to effectively block this
... does seem to be overlap between CSP we are specifying and mixed content blocking

tlr: discussion of integrity protections imply this is all one ball of hair

tanvi: say the only thing the spec says is, block mixed javascript, and browsers can decide to do more?

abarth: I see the fetch spec getting hooks for CSP to turn and off, can define default policy for this regarding mixed content

dveditz: we could make up a rule and say we will block mixed scripts unless you put it in csp

abarth: different issue from explaining what browsers do by default

dveditz: there is value in both specifying and opt out for use cases broken by what we already agree upon

tlr: deserves a problem statement

ACTION bhill2 to write a problem statement exploring the space of mixed content specifications

<trackbot> Created ACTION-131 - Write a problem statement exploring the space of mixed content specifications [on Brad Hill - due 2013-05-02].

ACTION bhill2 to write a problem statement exploring the space of HTML templating / safe HTML

<trackbot> Created ACTION-132 - Write a problem statement exploring the space of HTML templating / safe HTML [on Brad Hill - due 2013-05-02].

dveditz: we are seeing reports from users about active mixed content blocking breaking sites, and different behavior between IE, Chrome

abarth: I value interop higher than any of the particular details

tanvi: have been trying to reverse engineer the behavior, e.g. with children, grandchildren, etc. would be nice to know uniform behavior

drogers: is there formal remit for this group to do sec reviews of other specs like web crypto?

abarth: we have internal groups that do that inside Google, route feedback through individual participants or Security IG

dvetitz: we do similar, make sure feedback gets to SSOs as we do implementations

adrianb: we would be cautious about adding something like that to the WG charter

tlr: is it useful to have an informal place to share information about internal security reviews of specs and make some of that information public
... very very informal and lightweight coordination and publication to have them happen as much as possible at the same time and get communicated in a timely manner to the WGs

https://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html

<dveditz> scribenick: dveditz

bhill2: a week ago sent out a call for comments on the UI safety draft
... I have not seen any substantive comments, agreements, disagreements
... the one piece of substantial disagreement was removing the top-only directive

dross: yes... [missed] ... its an artificial limitation, but we can discuss it

bhill2: made editorial decision. there's no compatibility base that will break by removing it

dross: not exactly compat, but a limitation
... ms.com hosting live.com hosting a ms.com frame -- that's where you see the difference
... if you look at that scenario--not sandbox frame which caused the full ancestor check--that's a legitimate case
... you have to make everything align on the same domain if you don't have the top-only directive
... (allow-from might solve many cases we can identify)
... live.com and ms.com are essentially the same entity

bhill2: any frame above you in the stack can attack you

dross: but you're trusting the top-level, which is in this case ms.com

bhill2: but you're trusting the top context not to frame someone you don't trust, or to make a mistake

dross: if you look at this scenario w/out sandbox frames....

abarth: are yoiu saying nowhere on ms.com you ever frame an untrusted domain? if you do that once you lose

dveditz: but that's the kind of bug this feature is trying to provide airbags for

bhill2: what if the user has navigated the subframe somewhere not actually expected by the top-level site?
... if there's no csp frame-src directive to restrict that then you can also lose

dross: good point. wasn't saying top-only should be the default
... maybe it makes things more simplistic to get rid of top-only
... {sigh} yeah

bhill2: what we're trying to achieve is to make it easier to construct a simple policy that is safe than unsafe

dross: not disagreeing that the default should be the full ancestor check

bhill2: do you know of specific sites that need this feature to function properly

dross: no

bhill2: we've been taking the stance today that until we know of two independent sites needing a feature we're not going to actively consider a feature at this time
... let's bikeshed it until we hear more people who need it, for now remove top-only
... feedback on the rest of the content?

dross: no, that was about it

bhill2: have you seen anne's feedback? would you like to see more concrete descriptions of when these checks happen
... relative to the fetch spec

dross: seemed like there was enough to go on there, but I'm not even on the IE team itself. if they run into issues I'm sure they're bring it up but I don't have anything myself at this point

bhill2: from anne -- concerned that the blocked-target-xpath introduces too much complexity
... I think this is using standard constructs from dom level 2 core and shouldn't be a problem -- is this an insane idea?
... annes thought that unless you had a lot of state information an app wouldn't know how to construct the right page

abarth: woiuld be better to tell the browser directly what you want rather than try to construct an xpath to try to get where you want
... a dumb xpath that only has element names may not be useful in identifying the exact element. class names should help, spec should be explicit
... and ids
... you have an unsafe atrtibute on ui elements , lisntfor events

<abarth> foo.addEventListener("click", safeEventsPlease(function(event) { ... handleTheEvent ... }));

abarth: we had this problem with postMessage() where we specified a default behavior that was unsafe and it was hard to write safe code

<wseltzer> issue-52?

<trackbot> ISSUE-52 -- unsafe attribute requires every handler to check -- raised

<trackbot> http://www.w3.org/2011/webappsec/track/issues/52

abarth: have a dependency on touch events but some people don't like touch events

(sorry, having issues and missed a bit)

abarth: a concrete example -- in chrome w're working on out of process iframes
... this means the process handling these events won't be able to know what's outside the frame since the compositing is happening in another process

bhill2: an interesting problem, how do we deal with it

abarth: I don't want to be super negative, just telling you issues we're seeing in the spec

<scribe> scribenick: dveditz

reposting because I had the wrong nick:

[16:56] <dveditz> abarth: a concrete example -- in chrome w're working on out of process iframes [16:57] <dveditz> abarth: this means the process handling these events won't be able to know what's outside the frame since the compositing is happening in another process [16:57] <dveditz> bhill2: an interesting problem, how do we deal with it [16:58] <dveditz> abarth: I don't want to be super negative, just telling you issues we're seeing in the spec

abarth: I can tell you a little how we deal with similar issues. compositor is able to do hit testing (3d graphics has multiple buffers, kind of like that, one "layer" is touch)

bhill2: this will be something to melt my brain against

abarth: I can link to some design documents

bhill2: that would be helpful

<wseltzer> issue-53?

<trackbot> ISSUE-53 -- UI Security model for composited drawing models -- raised

<trackbot> http://www.w3.org/2011/webappsec/track/issues/53

bhill2: 5:00 -- anyone have any fundamental rewrites they want to suggest in the next 30 seconds?

[all] no!

bhill2: are the issues just raised something that should block a new working draft? show of hands for moving to the next round

<bhill2> RESOLVED: advance current ED to WD for UI Security

(consensus assent, no objections)

bhill2: with that we'll call it a day, start tomorrow at 9:30

tlr: one second... the UI-safety piece is exceeding the old charter?

bhill2: no, it's explicitly part of the old chartter, andy insisted it was there as a condition of my being a chair of the WG
... virginie wanted to update us on web crypto

virginie: nothing specific, but just let everyone know the statue

<wseltzer> [WebCrypto: http://www.w3.org/2012/webcrypto/ ]

virginie: working one main API, Web Crypto api.
... you can create a key, shape it iwht the right parameters and use that to sign things
... we are almost done in terms of functionality -- everything is drafted. w have some sensitive functions we would like to add
... so we are planning to go for Last Call in october. PWD in May
... most of you have delegates participating in the spec.also have another spec with same timeline, web crypto discovery api
... do you have pre-existing keys you want to use, led by Mark (?) from Netflix
... we also have a spec with use cases and requirements
... it would be great for yoiu guys to have a look at the spec
... another topic not in the WG because too much politics, tryin to describe the security model of the web
... crypto we need to define trust, never ending discussions on where the trust boundaries were. we're just supposed to deliver a tool
... hoping you can help define the web security model or we (both groups) can work together to define it
... how to integrate that into the W3C documentation effort

bhill2: I pointed them at the paper abarth wrote with Devdatta

drogersuk: there's a lot of good will toward doing this and there's a potential home in Web platform. need to reach out to OWASP out of courtesy

abarth: glad the webcrypto group is taking security seriously

drogersuk: lot of detractors as well, flaming on twitter etc

bhill2: what is a principal, how does same-origin policy relate to server-side and client-side code
... "crypto is useless because you can't defend against the site that delivered it to you"

virginie: do we need to specify, "to be secure you need to use X.Y.Z technologies"
... in order to use the Web Crypto api as it is you have to have high crypto skills. detractors say web developers aren't so smart and it's a footgun (not her term)

tanvi: are extensions using the same API as developers working on web sites, or are there multiple layers and extensions have access to a lower leve'?

virginie: we did not make that distinction

drogersuk: we tried to get into the high level api, but it became very complex -- different groups needed different things. didn't reach a proper conclusion on it

virginie: we will document how to use the low level API correctly. High level is not existing, we hope people will write libraries to do higher level services

drogersuk: that went alongisde the dev docs, describing how people were using these insecurely
... the level of documentation we're at is different from what most web developers need. needs to be friendlier, more explanations. developers are creating large amounts of insecurity by trying to work around the current web capabilities

bhill2: chair discretion, we need to call a halt now. we have scheduled to talk about this tomorrow

tlr: what time?

bhill2: we have dimitri coming at 9:30, maybe can get to this at 10:30?

tanvi: have we decided on tpac?

bhill2: we need to send it to the list and see how people respond definitively

exeunt

<wseltzer> trackbot, end meeting