16:07:10 <RRSAgent> RRSAgent has joined #webappsec
16:07:10 <RRSAgent> logging to http://www.w3.org/2013/04/25-webappsec-irc
16:07:12 <trackbot> RRSAgent, make logs world
16:07:12 <Zakim> Zakim has joined #webappsec
16:07:14 <trackbot> Zakim, this will be
16:07:14 <Zakim> I don't understand 'this will be', trackbot
16:07:15 <trackbot> Meeting: Web Application Security Working Group Teleconference
16:07:15 <trackbot> Date: 25 April 2013
16:08:53 <wseltzer> wseltzer has changed the topic to: Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2013Apr/0054.html
16:09:02 <virginie> virginie has joined #webappsec
16:12:03 <wseltzer> zakim, who is here?
16:12:03 <Zakim> sorry, wseltzer, I don't know what conference this is
16:12:04 <Zakim> On IRC I see virginie, Zakim, RRSAgent, tlr, bhill2, timeless, bhill, mkwst_, odinho, wseltzer, trackbot
16:12:14 <wseltzer> zakim, this is WEBAPPSEC
16:12:15 <Zakim> sorry, wseltzer, I do not see a conference named 'WEBAPPSEC' in progress or scheduled at this time
16:12:28 <tlr> zakim, this is waswg
16:12:28 <Zakim> ok, tlr; that matches SEC_WASWG(F2F)12:00PM
16:12:38 <wseltzer> zakim, who is here?
16:12:39 <Zakim> On the phone I see Paypal, +1.650.488.aaaa
16:12:39 <Zakim> On IRC I see virginie, Zakim, RRSAgent, tlr, bhill2, timeless, bhill, mkwst_, odinho, wseltzer, trackbot
16:12:59 <wseltzer> zakim, aaaa is mkwst_
16:13:00 <Zakim> +mkwst_; got it
16:25:06 <wseltzer> zakim, Paypal has bhill, abarth, drogersuk, wseltzer, Dan_Veditz
16:25:07 <Zakim> +bhill, abarth, drogersuk, wseltzer, Dan_Veditz; got it
16:25:19 <wseltzer> zakim, Paypal also has tlr
16:25:19 <Zakim> +tlr; got it
16:27:17 <dveditz> dveditz has joined #webappsec
16:27:19 <wseltzer> zakim, who's here?
16:27:19 <Zakim> On the phone I see Paypal, mkwst_
16:27:20 <Zakim> Paypal has bhill, abarth, drogersuk, wseltzer, Dan_Veditz, tlr
16:27:20 <Zakim> On IRC I see dveditz, virginie, Zakim, RRSAgent, tlr, bhill2, timeless, bhill, mkwst_, odinho, wseltzer, trackbot
16:27:55 <abarth> abarth has joined #webappsec
16:28:38 <wseltzer> scribenick: abarth
16:29:34 <wseltzer> zakim, Paypal also has Neil_Matatall
16:29:34 <Zakim> +Neil_Matatall; got it
16:29:50 <drogersuk> drogersuk has joined #webappsec
16:29:55 <abarth> starting with open issues
16:30:00 <abarth> starting with CSP 1.0
16:30:04 <abarth> then moving to CSP 1.1
16:30:22 <abarth> Should we be considering refining the bookmarklet language in 1.0 or 1.1?
16:30:38 <abarth> mkwst_: I think we shouldn't change 1.0 at this point
16:30:42 <abarth> dveditz: I agree
16:31:04 <abarth> dveditz: Not enough people are using CSP to know whether this is a real problem yet.  it's speculative at this point
16:31:18 <abarth> dveditz: the spec gives us the flexibily to change our behavior if needed
16:31:31 <abarth> bhill2: most of these issues are 1.1 issues
16:31:58 <abarth> dveditz: what about column numbers?
16:32:28 <abarth> dveditz: it would be nice to get the column numbers into 1.0
16:33:06 <abarth> abarth: would that trigger a bunch of process?
16:33:15 <abarth> dveditz: depends on the test suite
16:33:28 <abarth> tlr: adding new features in CR would be a problem
16:33:41 <abarth> tlr: this feature would be borderline
16:34:11 <abarth> bhill2: other outstanding change would be allowing cross-origin JSON posts
16:34:31 <abarth> bhill2: doesn't appear elsewhere in the ecosystem
16:34:48 <abarth> bhill2: could change the mime type or use an anonymous fetch
16:35:01 <abarth> bhill2: that would trigger some process in the CR too
16:35:12 <abarth> tlr: the point of CR is for the spec to be stable and implement it
16:35:30 <abarth> tlr: the entrance to PR is when you have test and interoperability reports
16:36:25 <abarth> tlr: 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
16:36:44 <abarth> tlr: making a bunch of changes that change interoperablity isn't so good, but it's not a hard rule
16:37:05 <abarth> tlr: would a change be likely to invalidate previous review? is a key question
16:37:20 <abarth> bhill2: to the extent that it would change interop, it would change people who are processing reports
16:37:35 <abarth> dveditz: realistically, I don't think anyone cares about the mime type they're getting
16:37:54 <abarth> abarth: I think this is a minor issue
16:37:57 <jin> jin has joined #webappsec
16:38:10 <abarth> dveditz: hard to discuss because annevk is the person who raised the issue and he's not here
16:38:22 <abarth> bhill2: I think he's concerned about a history of working with CORS
16:38:35 <abarth> bhill2: this doesn't follow the rules we set out for CORS
16:38:58 <abarth> bhill2: I think there's a good reason to make it an anonymous request
16:39:01 <jeffh> jeffh has joined #webappsec
16:39:28 <abarth> dveditz: the referer header is in the body of the request even if we strip it from the HTTP headers
16:39:52 <abarth> bhill2: I think annevk wants us to use the anonymous version of the fetch algorithm
16:40:05 <abarth> bhill2: I think that's a reasonable request
16:40:13 <abarth> bhill2: It wouldn't lose a lot
16:40:23 <abarth> bhill2: it wouldn't break any existing implementations
16:40:55 <abarth> 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
16:41:06 <abarth> dveditz: if its reflected, it might be in the request
16:41:23 <abarth> dveditz: but if its stored, its helpful to know which account is concerned
16:41:36 <abarth> dveditz: but that's mostly useful for same-origin reports
16:42:03 <abarth> bhill2: we could make it anonymous if its cross-origin and non-anonymous if it's same-origin
16:42:19 <abarth> dveditz: if the site is having problems they could move the report-uri to the same site to debug more
16:42:29 <abarth> bhill2: does that sound reasonable and appropriate?
16:42:44 <abarth> neil: that works for me
16:43:20 <abarth> abarth: I think that behavior makes sense, it's just a question fo whether it's worth re-opening 1.0
16:43:46 <abarth> mkwst_: the cost of re-opening 1.0 depends on how long it will take to close it again
16:44:09 <abarth> bhill2: do we think this is going to generate objections to moving to PR?
16:44:39 <abarth> tlr: can you explain the context in more detail
16:44:52 <abarth> dveditz: (explains how report-uri works in the spec)
16:44:57 <wseltzer> [https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-1.0-specification.html]
16:45:53 <bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Mar/0094.html
16:46:00 <bhill2> is the thread that started this discussion
16:46:02 <abarth> tlr: sounds like a completely reasonable change (to start with)
16:46:42 <abarth> tlr: 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
16:46:51 <abarth> tlr: In any case, I think we can keep the delay down to four weeks
16:47:24 <wseltzer> q+
16:47:31 <abarth> 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
16:47:45 <abarth> wseltzer: has their been a privary review of this issue?
16:47:55 <abarth> wseltzer: this might be something they'll pick up on
16:47:59 <wseltzer> ack ws
16:48:24 <abarth> neil: At the risk of complicating this further, we could consider relaxing the notion of same-origin (e.g., http to https)
16:48:33 <abarth> neil: The concept of upgrading security
16:48:44 <abarth> dveditz: this is an issue with the moz implementation
16:48:53 <abarth> neil: this issue would arise again with this change
16:49:05 <abarth> dveditz: the simplest way to make the change is in the CORS spec, and there an origin is an origin
16:49:12 <abarth> dveditz: we certainly wouldn't want to go the other way
16:49:19 <tlr> transition requirements: http://www.w3.org/2005/10/Process-20051014/process.html#transition-reqs
16:49:48 <abarth> abarth: I think it makes sense to use the same origin concept everywhere
16:50:01 <abarth> tlr: to the extent to that you can sell it as a bug fix, you can get it in
16:50:13 <abarth> tlr: but it's getting sufficient discussion that it should probably go back to last call
16:50:31 <abarth> tlr: if everyone is on board, then it's easier, but if it requires deeper thought
16:51:06 <abarth> tlr: if there are a sufficiently large number of these bug fixes, then that changes things
16:51:20 <abarth> bhill2: I don't think we have any other issues (other than typos)
16:51:58 <abarth> bhill2: I think it's a small thing.  it's just a one sentence change.  I'd prefer to see it in 1.0
16:52:28 <abarth> abarth: I'm becoming convinced that we should fix it
16:52:39 <abarth> tlr: what about WebKit?
16:52:50 <abarth> tlr: we used to have them represented via the chrome team
16:53:04 <abarth> bhill2: ekr has reached out to othermjs
16:53:25 <abarth> bhill2: we're encourging them to send someone
16:53:51 <abarth> tlr: one question for this is whether the webkit folks are on board
16:53:57 <abarth> dveditz: this will be an issue with 1.1
16:54:16 <abarth> bhill2: it's likely we'll find bugs in 1.0
16:54:41 <mkwst_> chair: *squeek*
16:54:49 <abarth> mkwst_: sorry :(
16:55:00 <mkwst_> abarth: :)
16:55:31 <abarth> tlr: can we communicate with them?
16:55:46 <abarth> abarth: I can do that right now, but I'll have to stop scribing to do that :)
16:55:57 <abarth> bhill2: That's it for 1.0 issues that are open
16:56:03 <abarth> bhill2: except for test cases
16:56:40 <wseltzer> zakim, Paypal also has Jeff_Hodges
16:56:40 <Zakim> +Jeff_Hodges; got it
16:58:09 <bhill2> zakim, PayPal also has puhley
16:58:09 <Zakim> +puhley; got it
16:58:51 <bhill2> http://www.w3.org/2011/webappsec/track/actions/open
16:58:58 <abarth> bhill2: let's go though the tracker for 1.0 issues
16:59:01 <bhill2> we'll start with tracker for 1.1 issues, return to agenda summary
16:59:08 <abarth> sorry, 1.1 issues
16:59:33 <wseltzer> action-97?
16:59:33 <trackbot> ACTION-97 -- Daniel Veditz to propose spec language for policy-uri directive -- due 2012-11-09 -- OPEN
16:59:33 <trackbot> http://www.w3.org/2011/webappsec/track/actions/97
17:00:11 <abarth> dveditz: I don't know if we have an agreement to do policy-uri, but people inside mozilla want to use it
17:00:23 <abarth> dveditz: the spec would be to treat it as if it were an additional header
17:00:43 <abarth> dveditz: the old language said that there couldn't be any other header, but that's likely a mistake
17:01:04 <abarth> abarth: I think the issue is that it's s sync request
17:01:40 <abarth> abarth: do the folks in moz want to use it on the network, or for packaged apps
17:01:50 <abarth> dveditz: the folks who want to use it are the marketplace
17:02:22 <abarth> abarth: one thing we could do is put it in the spec for now and get some implementation feedback
17:02:34 <abarth> dveditz: we could resrict it to only working in the header (no the meta tag)
17:02:46 <abarth> dveditz: I guess it's no worse than blocking on a script tag
17:03:06 <abarth> bhill2: I wonder if we look a little bit ahead to proposals for http2, we can see header compression, which helps here
17:03:25 <abarth> bhill2: for me the interesting use case is whether it can be cross-origin
17:03:41 <abarth> bhill2: if it's cross origin, we you can outsource it, which unlocks some interesting use cases
17:03:51 <abarth> bhill2: do you have thoughts on that?
17:03:58 <abarth> dveditz: I had assumed it would be same origin
17:04:05 <abarth> dveditz: but it might be interesting
17:04:21 <abarth> puhley: would that end up with a chicken-and-egg problem
17:04:30 <abarth> dveditz: you could use the policy-uri statement as the grant
17:05:02 <abarth> bhill2: I think sites are smart enough to decide whether they want to take the latency hit
17:05:15 <abarth> bhill2: but http2 might make the whole thing not worthwhile
17:05:30 <abarth> dveditz: I can imagine a bunch of sibling domains with a central server that sets the policy
17:05:46 <abarth> dveditz: but we don't have good ways of telling which domains are siblings
17:05:57 <abarth> dveditz: we do have some huerstiics
17:06:45 <abarth> abarth: I think it's worth experimenting with
17:06:54 <abarth> dveditz:  this is an opt-in thing
17:07:33 <abarth> abarth: if we do allow crossorigin, we should use CORS so that we know the other origin is ok with you using their policy
17:08:53 <abarth> abarth: 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
17:10:00 <abarth> neil: I haven't thought about this feature much, but the concept of sending these across domains is kind of scary
17:10:08 <abarth> bhill2: is that different than an iframe
17:10:49 <abarth> dveditz: can you clarify what you're worried about
17:11:24 <abarth> neil: the policy is third-party, but the report-uri is first-party again
17:11:39 <abarth> neil: and the third-party gets compromised
17:12:07 <abarth> bhill2: I think if you're going to get your policy from a third-party, you've got to trust them
17:12:37 <abarth> bhill2: I think it's interesting to consider for the spec is whether we're creating opportunities for folks to make the ecosystem more secure
17:12:53 <abarth> bhill2: many folks might like the opportunity to outsource this tricky stuff
17:14:14 <abarth> ACTION-115?
17:14:14 <trackbot> ACTION-115 -- Adam Barth to raise ISSUE-15 on the mailing list -- due 2013-02-05 -- OPEN
17:14:14 <trackbot> http://www.w3.org/2011/webappsec/track/actions/115
17:14:37 <abarth> mkwst_: the 1.1 spec certainly says some things about blob
17:15:08 <abarth> issue-15?
17:15:08 <trackbot> ISSUE-15 -- How to handle srcdoc, blob:, di: and ways of directly creating content -- open
17:15:08 <trackbot> http://www.w3.org/2011/webappsec/track/issues/15
17:15:50 <abarth> abarth: the srcdoc would inherit the policy from its parent
17:16:37 <wseltzer> [1.1: https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html ]
17:16:40 <abarth> dveditz: its covered by implication, but we should be explicity
17:17:15 <abarth> abarth: someone just needs to work through the spec and propose how to handle all these cases
17:18:18 <abarth> dveditz: oh, you mean where does it get the policy from
17:18:30 <abarth> dveditz: for data URIs, we get the policy from the parent document
17:18:36 <abarth> abarth: we should do that for srcdoc too
17:18:42 <abarth> abarth: we just need to write that in the spec somewhere
17:19:49 <abarth> dveditz: there's an interop issue because different user agents treat data URIs different w.r.t. security
17:19:53 <abarth> action-109?
17:19:53 <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
17:19:53 <trackbot> http://www.w3.org/2011/webappsec/track/actions/109
17:20:09 <abarth> dveditz: I sent mail to the list about that already
17:20:20 <abarth> dveditz: once I get the password, I'll edit the spec to incorporate that
17:21:45 <abarth> bhill2: we have some spec text in the spec already
17:22:02 <abarth> bhill2: we ignore report-uri
17:22:12 <abarth> abarth: on the list we talked about ignoring sandbox too
17:22:28 <abarth> dveditz: and for frame-options
17:22:42 <abarth> dveditz: the browser needs to know about these at the beginning
17:22:53 <abarth> dveditz: for frame-options and sandbox
17:23:41 <abarth> abarth: we actually support an x-frame-options meta tag, but I think it's find to skip it for CSP
17:24:07 <abarth> bhill2: idea to stop honoring the meta tag after the document reaches the "interactive" state
17:24:45 <abarth> abarth: I don't remember when the doc gets to interactive
17:24:58 <abarth> mkwst_: google web toolkit might use this technique
17:25:44 <abarth> bhill2: dveditz previously thought that was crazy, do you still think that?
17:25:49 <jeffh> jeffh has joined #webappsec
17:25:54 <abarth> dveditz: event allowing it in the head allow some things to be loaded
17:26:11 <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.
17:26:17 <abarth> dveditz: that's more defensible than allowing the document to becoming active
17:26:44 <abarth> dveditz: I think having in the header is unsafe, but probably defensible in some circumstances
17:27:02 <abarth> dveditz: if the meta tag comes late, how do we know if it's an attack?
17:27:17 <abarth> bhill2: is this less necessary now that we allow paths?
17:28:31 <abarth> abarth: I think it's mostly folks the eval is the real issue
17:28:41 <abarth> neil: would the DOM API help with this?
17:29:04 <abarth> 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)
17:29:49 <abarth> action-121?
17:29:49 <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
17:29:49 <trackbot> http://www.w3.org/2011/webappsec/track/actions/121
17:30:40 <abarth> mkwst_: we got hung up on the syntax
17:30:49 <abarth> mkwst_: I can take an action to make a strawman proposal
17:31:01 <abarth> mkwst_: we want to leave some room in the syntax for a hash potentially
17:31:18 <abarth> mkwst_: I think someone was going to put together an experimental implementation, but I'm not sure how far that got
17:31:32 <abarth> bhill2: we had some language for how to calcuate it for script
17:31:51 <abarth> dveditz: how does it interact with inline?
17:32:09 <abarth> dveditz: does the nonce need to be on everything?
17:32:51 <abarth> abarth: the nonce is an argument to the script-src directive
17:32:56 <bhill2> <script nonce="foo">alert(1)</script>
17:33:09 <abarth> abarth: so you can list whatever you like
17:33:23 <abarth> abarth: e.g., script-src 'self' 'nonce-foo'
17:33:23 <bhill2> <img nonce="foo" src="data:afaewrq3r432q"/>
17:33:50 <abarth> abarth: which means you could either load from yourself or with a nonce
17:34:02 <abarth> mkwst_: most valuable for script and style, but we could support it for the other types
17:34:14 <abarth> bhill2: maybe we should just do it as a generic source type
17:34:41 <abarth> bhill2: if I want to use data URLs, then if I whitelist all of data, that kind of defeats the point
17:35:12 <abarth> mkwst_: Yeah, i think that makes sense
17:35:18 <abarth> mkwst_: its probably easier to specify that way anyway
17:35:33 <abarth> mkwst_: I'm happy to add it if there's consensus to add it
17:36:09 <abarth> neil: are we worried about compat?
17:37:35 <abarth> abarth: I think we want to make sure that content targeting version X continues to work in versions >X as well
17:38:09 <abarth> but I don't think we need to constain content targeting version X to also work with version <X
17:38:24 <abarth> bhill2: do we want a length requirement for the nonce?
17:38:37 <abarth> dveditz: the important thing is that it's not constant
17:38:44 <abarth> bhill2: the spec already requires that
17:39:01 <abarth> niel: that's different than for hash
17:39:31 <abarth> jeffh: the way i've seen this done before is to have a guideline in the spec
17:39:38 <abarth> jeffh: but not necessarily a strict requirement
17:40:31 <abarth> tlr: have we thought about interactions with cache?
17:40:39 <abarth> abarth: it should work fine with caching
17:41:03 <abarth> tlr: the server should know that the client might get an "old" nonce from the cache
17:41:18 <abarth> wseltzer: yet another tracking mechanism!
17:41:26 <tlr> well, the server might not know that -- that's exactly my point. :)
17:41:28 <abarth> tlr: it's no worse that a global javascript variable
17:41:52 <abarth> tlr: (sorry, that's what I meant---I just scribed it poorly)
17:42:30 <abarth> action-125?
17:42:30 <trackbot> ACTION-125 -- Mike West to investigate WHATWG spec text vs RFC 3986 for normalization in CSP -- due 2013-04-02 -- OPEN
17:42:30 <trackbot> http://www.w3.org/2011/webappsec/track/actions/125
17:43:24 <abarth> bhill2: I'm going to assume that this action is closed
17:43:29 <abarth> mkwst_: yes
17:43:36 <abarth> bhill2: ok, i'm going to make it as closed
17:44:39 <abarth> issue-34?
17:44:39 <trackbot> ISSUE-34 -- Discuss use cases / risks of script access to CSP information, solicit specific public comment on this feature with FPWD -- open
17:44:39 <trackbot> http://www.w3.org/2011/webappsec/track/issues/34
17:44:40 <bhill2> https://www.w3.org/2011/webappsec/track/issues/34
17:44:52 <abarth> bhill2: one of the proposals was to add an HTTP only directive
17:45:01 <abarth> bhill2: that would prevent scripts from getting access to the content of the header
17:45:12 <abarth> bhill2: more importantly see what the report-uri is set to
17:45:28 <abarth> dveditz: do you mean by using XHR to request the page itself
17:45:36 <abarth> bhill2: no, I mean via the DOM APIs
17:45:51 <abarth> niel: what's the threat we're trying to protect?
17:46:16 <abarth> dveditz: the nonce could be sensitive
17:46:23 <abarth> mkwst_: you can just read it off a script tag that has it
17:46:26 <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
17:46:32 <abarth> bhill2: maybe the report URI?
17:46:53 <abarth> dveditz: who are you hiding the report-uri from?
17:47:06 <abarth> dveditz: you can just load the page yourself, it's unlikely to change
17:47:29 <abarth> bhill2: the site might have a user unique value encoded into the report URI
17:47:43 <abarth> mkwst_: also related to extensions that inject policies
17:48:03 <abarth> mkwst_: maybe the page wants to prevent the page from getting reports via the DOM event
17:48:13 <abarth> ^^^ the extension wants to prevent the page
17:48:28 <abarth> bhill2: maybe the security policy group is not 100% friends with the developers
17:48:48 <abarth> abarth: that's why the DOM API is read only
17:49:02 <abarth> dveditz: we also don't allow a meta policy to be added if there's already an HTTP policy
17:49:51 <abarth> bhill2: is there a use case for having report-uri in the DOM API at all??
17:50:24 <abarth> 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
17:51:18 <abarth> 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
17:51:42 <abarth> dveditz: currently the spec is just a read only version of the effective policy
17:52:34 <abarth> bhill2: if I wrote an ad block that work via CSP by querying the DOM API
17:52:46 <abarth> bhill2: the page could figure out if it were active
17:53:17 <abarth> abarth: they could also just trying the request
17:53:26 <abarth> dveditz: what's the use case for the API at all?
17:53:58 <abarth> abarth: it's to let library authors know what the rules are
17:54:53 <abarth> dveditz: the use case for the first three properties seem reasonable
17:55:06 <abarth> dveditz: the per-resource ones seem to have weaker use cases
17:55:23 <abarth> dveditz: I'm not sure what "is active" is for
17:55:41 <abarth> bhill2: maybe isactive is good as a early-exist from querying
17:55:51 <abarth> neil: we definitely want the isactive available
17:56:03 <abarth> s/exist/exit/
17:56:11 <abarth> dveditz: neil: do you need the other bits?
17:56:18 <abarth> neil: we just need the first four
17:56:43 <abarth> bhill2: maybe the http only option resolves this
17:56:55 <abarth> dveditz: that means we'd have to lie about the four at the bottom
17:57:36 <abarth> 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
17:57:43 <abarth> mkwst_: I think alex is going to be mad at me :)
17:57:59 <abarth> mkwst_: we can try it and then circle back around if there are compelling use cases
17:58:11 <abarth> bhill2: maybe ask alex to email the list if he doesn't like the change
17:59:16 <abarth> dveditz: I'm really opposed to exposing the list of report URIs.  there needs to be a really compelling use case.
17:59:32 <abarth> dveditz: I'd like to avoid adding an HTTP only botch to work around this problem we're creating for ourselves
17:59:48 <abarth> dveditz: http only in cookies is a mistake
17:59:53 <abarth> dveditz: the page doesn't need to know everything
18:00:15 <abarth> dveditz: do we need to hide CSP headers from XMLHttpRequest?
18:00:39 <abarth> niel: would and XHR response with a CSP header have any effect?
18:01:00 <abarth> dveditz: I'm not sure if it's going to be specific to the user... maybe something in the report uri
18:01:12 <abarth> dveditz: by default XHR makes all the headers available, but some are blacklisted
18:02:19 <abarth> abarth: you can always load a same-origin page in an iframe
18:02:28 <abarth> abarth: cross-origin won't get credentials
18:02:31 <abarth> dveditz: that's true
18:02:39 <abarth> bhill2: did we already just resolve this issue?
18:03:01 <abarth> abarth: I don't think it's an issue
18:03:14 <abarth> dveditz: my main worry was the nonce, but that's really the site being silly
18:03:29 <abarth> bhill2: if you can XHR, then you can already get this information from the body
18:04:20 <abarth> niel: does this negate removing the DOM APIs?
18:04:32 <abarth> abarth: not for extension-added CSP, which won't show up on the network
18:04:50 <abarth> dveditz: our privacy folks were concerned about exposing information about extension-added CSP
18:06:05 <abarth> bhill2: let's take 5 and then come back
18:16:38 <Zakim> -mkwst_
18:17:45 <mkwst_> (rejoining in a moment)
18:19:06 <Zakim> +mkwst_
18:24:17 <bhill2> you there mike?
18:24:20 <wseltzer> zakim, Paypal also has Tanvi
18:24:20 <Zakim> +Tanvi; got it
18:24:22 <mkwst_> i am.
18:25:24 <abarth> bhill2: should we talk about mutability?
18:25:43 <abarth> abarth: I think the main thing is wanting to turn off eval if its already on
18:25:53 <abarth> dveditz: Also inline script and inline style
18:26:01 <abarth> dveditz: the risk is that a script coudl break the pag
18:26:09 <abarth> dveditz: but that's already possible
18:26:28 <mkwst_> (would you mind speaking up a bit, dveditz?)
18:26:30 <abarth> dveditz: it's less safe than starting off with everything off, but it can be hard to root out eval from all the libraries
18:26:54 <jeffh> may want to splain in that action wrt "one-way mutablility" what that nominally means
18:26:58 <abarth> dveditz: but some libraries use eval on an on-gong basis
18:27:11 <jeffh> oh ok, it's getting noted
18:27:11 <tanvi> tanvi has joined #webappsec
18:27:28 <abarth> bhill2: should we restrict to the head?
18:27:39 <jeffh> "be able to turn off (bunt not on) eval, inline script, incline css
18:27:42 <jeffh> "
18:27:46 <abarth> 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
18:28:15 <abarth> mkwst_: the current "API" is to inject a meta tag, which also lets you further limit the page (but not loosening)
18:28:24 <abarth> dveditz: do you mean once the page has loaded?
18:28:37 <abarth> mkwst_: yes
18:28:53 <abarth> abarth: I think that's a workaround for the lack of a real API.  we probably want to have a real one instead
18:28:59 <abarth> mkwst_: yeah
18:29:23 <wseltzer> action-127?
18:29:23 <trackbot> ACTION-127 -- Adam Barth to add one-way mutability to policy points exposed in script interface -- due 2013-05-02 -- OPEN
18:29:23 <trackbot> http://www.w3.org/2011/webappsec/track/actions/127
18:29:40 <abarth> mkwst_: I'll put together a strawman and then we can have deeper discussion on the list
18:29:56 <abarth> mkwst_: one option is to let the page supply a textual policy
18:30:05 <abarth> mkwst_: another option is an explicit toggle
18:30:12 <abarth> neil: I line of like the explicit toggle
18:30:16 <abarth> jeffh: me too
18:31:02 <abarth> abarth: one possibility is to make the attributes not be read only but then ignore writes that we don't like
18:31:14 <abarth> mkwst_: what about limiting the scope of sources?
18:31:37 <abarth> dveditz: it seems cleaner for you to specify the subdirecty to start with
18:32:07 <abarth> mkwst_: I can imagine wanting to load libraries at the beginning but then dropping them later
18:32:18 <abarth> bhill2: that works with the meta tag, maybe we should keep that
18:32:34 <abarth> mkwst_: I'm not sure its worth making it that complex for starting
18:32:44 <abarth> mkwst_: we can start with the four-points, but we should keep in mind what use cases we're not addressing
18:33:03 <abarth> dveditz: I can see the use, but our concern about the meta tag is that it could be an injected attack
18:33:30 <abarth> dveditz: one way to address our concern is to have a non-meta bit in the policy
18:33:46 <abarth> dveditz: I'm not sure if that make sense
18:34:04 <abarth> bhill2: I'm not sure dropping sources is as important any more now that we have path restrictions
18:34:15 <abarth> jeffh: and the hash
18:34:32 <abarth> bhill2: now that we're more grainular, now load and then lock isn't as needed
18:35:28 <abarth> abarth: IMHO, we should just start with the first three and then add more in the future if needed
18:35:55 <abarth> mkwst_: It's not that complex to implement
18:36:06 <bhill2> https://www.w3.org/2011/webappsec/track/
18:36:07 <abarth> mkwst_: but I think it's fine to start with these and move on from there
18:36:16 <bhill2> https://www.w3.org/2011/webappsec/track/actions/127
18:36:40 <mkwst_> i'll just add "it's not that complex" to my list of things i might regret saying in the future. :)
18:36:54 <abarth> dveditz: the spec currently says that if you have a header, then no meta is allowed
18:36:59 <abarth> dveditz: do you want to re-open that issue
18:37:01 <abarth> ?
18:37:13 <abarth> dveditz: I think that's something we should discuss on the mailing list
18:37:27 <abarth> mkwst_: I think if we have this API, then there's much less value to letting people injection meta tags
18:37:56 <abarth> abarth: you mean meta tags in the precence of HTTP headers, no in the absence
18:37:58 <abarth> mkwst_: correct
18:39:54 <abarth> issue-36?
18:39:54 <trackbot> ISSUE-36 -- Are we interested in considering script-hash as a CSP 1.1 directive? -- open
18:39:54 <trackbot> http://www.w3.org/2011/webappsec/track/issues/36
18:40:03 <abarth> bhill2: seems like a good idea inline with nonce
18:40:39 <abarth> bhill2: probably don't want a "script-nonce" directive.  instead use a syntax more like a source that can apply to other types
18:40:45 <abarth> dveditz: how is this related to content integrity
18:40:53 <abarth> bhill2: there are potentially interesting interactions
18:41:08 <abarth> bhill2: we could say hash applies to an external script
18:41:37 <abarth> tanvi: I think it's more interesting for remote content
18:41:52 <abarth> tanvi: nonce might be more appropriate for inline content
18:41:57 <abarth> bhill2: hash works well for static documents
18:42:18 <abarth> tanvi: with hash, CSP header doesn't need to have every single source listed
18:42:31 <abarth> tanvi: If the javascript changes, then the web sites will break
18:42:42 <abarth> neil: it should be pre-computed on deploy
18:42:49 <abarth> tanvi: I'm worried about remote content
18:42:59 <abarth> tanvi: e.g., google-analytics
18:43:15 <abarth> bhill2: introduces brittleness that we don't have with URIs
18:43:26 <abarth> tanvi: maybe we should just keep that in the content integrity spec for later
18:43:36 <abarth> bhill2: the proposal on the table is to have hash for inline content only
18:43:48 <abarth> bhill2: you don't think it's useful for line content
18:43:55 <abarth> tanvi: I don't think it's that useful for inline content
18:44:13 <abarth> neil: it reduces the complexity
18:44:25 <abarth> bhill2: e.g., CDNs
18:44:47 <bhill2> abarth: one option is list all hashes in policy
18:45:01 <bhill2> ... other is that script needs to have hash value to execute for remote scripts
18:45:43 <bhill2> dveditz: second is to allow author to relax mixed-content ui or specify a particular version of a resource
18:46:09 <abarth> dveditz: doesn't protect from injection
18:46:33 <abarth> bhill2: you're talking about the subresource integrity deliverable
18:47:11 <abarth> abarth: seems that the two are related
18:47:18 <bhill2> script-src hash:abcde
18:47:24 <abarth> abarth: different use cases, but you want to at least use the same hash algorithm
18:47:42 <bhill2> let's say abcde is the hash of :   "alert(foo)"
18:47:49 <abarth> script-src 'self' hash-iuneinwoen
18:47:49 <bhill2> there are a couple of options
18:47:58 <bhill2> script-src hash:abcde could match:
18:48:33 <bhill2> <script src="foreign.com/fooalert.js">   where the content body is "alert(foo)"
18:48:42 <abarth> dveditz: that would be more difficult for moz to implement because of when we make our decision about when to load something
18:49:44 <abarth> <script hash="abcde" src=....">
18:50:32 <abarth> dveditz: it would mean you could make requests to domain that are otherwise not allowed
18:51:43 <abarth> abarth: one way to do this is to have document integrity specify how to hash subresources
18:51:55 <abarth> abarth: and CSP just says which of those hashes are allowed
18:52:12 <abarth> dveditz: hashes might be shorter than paths
18:52:37 <abarth> bhill2: if i'm just going to include a single remote resource, I can use the (shorter) hash rather than the (long) URL
18:53:19 <bhill2> bhill2 has joined #webappsec
18:53:28 <bhill2> test
18:53:32 <abarth> dveditz: doesn't acutally help with CSRF
18:53:47 <abarth> tanvi: it's not just CSRF, it's also the cookies and other things in the clear
18:54:05 <abarth> dveditz: by including the hash, you've loosened some of the restrictions
18:54:12 <abarth> dveditz: because the requests go out
18:54:34 <abarth> bhill2: similar to loading from my own site
18:54:42 <abarth> bhill2: but it has a different referer header
18:55:03 <abarth> bhill2: maybe that's a reason not to have hashes apply to remove resources
18:55:16 <abarth> tanvi: maybe that's in a separate spec
18:55:24 <abarth> bhill2: so if we did hash, it would only be for inline content
18:55:51 <abarth> abarth: so, CSP's hash is about whether inline resources excute
18:56:02 <abarth> abarth: document integrity is about the integrity of remote resources
18:56:08 <abarth> (nods around the room)
18:58:07 <abarth> bhill2: this proposal lets us be more creative or compact with the syntax
18:58:27 <abarth> bhill2: if its only referring to inline content, we don't need to collide with URI trickiness
18:58:32 <abarth> jeffh: yeah, that's something to think about
18:59:26 <abarth> bhill2: lets get some food, and talk while we eat a bit
18:59:57 <jeffh> file:///home/hodges/doc/IETF/internet-drafts/draft-farrell-decade-ni-10.txt
19:00:39 <jeffh> ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q
19:02:22 <tanvi> tanvi has joined #webappsec
19:07:28 <Zakim> + +1.781.369.aabb
19:08:17 <gopal> gopal has joined #webappsec
19:18:30 <bhill2> let's give it another 20 minutes here on a few more csp 1.1 issues
19:19:13 <abarth> mkwst_: ^^^
19:19:27 <mkwst_> thanks, abarth.
19:20:21 <abarth> bhill2: base-uri
19:20:59 <abarth> bhill2: (looking at the spec text for base-uri)
19:21:08 <abarth> bhill2: we had talked about making this a reverse policy
19:21:24 <abarth> bhill2: it would be enforced by default
19:21:39 <abarth> mkwst_: I'm vaguely in favor of that
19:22:11 <abarth> abarth: we could experiment to see how big an impact that would be
19:22:26 <abarth> mkwst_: my gut feeling is that it's miniscule, but we can measure and get an estimate
19:22:45 <abarth> bhill2: to be reasonable effective, we'd have to specify them all the time, which seems bloaty
19:23:41 <abarth> abarth: we could also try to figure out how many sites would benefit from this directive
19:23:51 <abarth> abarth: there is an attack scenario, the only question is how prevalent it is
19:25:59 <abarth> bhill2: (is entering an issue for this topic)
19:26:16 <abarth> dveditz: hixie used to run these sorts of experiments on google search data
19:27:06 <wseltzer> issue-48?
19:27:06 <trackbot> ISSUE-48 -- injection of a <base> tag to change effective location of relative resources -- raised
19:27:06 <trackbot> http://www.w3.org/2011/webappsec/track/issues/48
19:28:10 <abarth> tanvi: what would the default be?
19:28:22 <abarth> abarth: we could either main the default 'self' or match default-src
19:28:30 <abarth> tanvi: I think using 'self' by default is a good idea
19:28:36 <abarth> dveditz: 'self' is what HTML defaults to
19:28:45 <abarth> dveditz: so it would be good to match that
19:29:19 <abarth> abarth: the first question is the compatibility risk
19:30:04 <abarth> dveditz: maybe that should come into play if your policy has one of the URL loading diretives
19:30:36 <abarth> bhill2: on to response code in reports
19:31:07 <abarth> niel: This was my request
19:31:19 <abarth> neil: it was useful only in one specific case
19:31:40 <abarth> neil: the use case is that we had a 404 response that triggered a report
19:32:06 <abarth> neil: that was the only time it ever came up, but it's another data point
19:32:23 <abarth> mkwst_: it doesn't seem to expose any information that's privacy relevant
19:32:37 <abarth> mkwst_: so it seems like there's no harm but it's potentially useful
19:33:11 <abarth> abarth: maybe we should wait for the second person to ask for it?
19:33:24 <abarth> neil: it was useful in one situation.  it hasn't come up again
19:33:41 <abarth> 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
19:34:34 <wseltzer> issue-49?
19:34:34 <trackbot> ISSUE-49 -- add http response code to report? -- raised
19:34:34 <trackbot> http://www.w3.org/2011/webappsec/track/issues/49
19:34:55 <abarth> bhill2: next up: plugin-types and iframes
19:37:10 <abarth> 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
19:37:23 <wseltzer> action-129?
19:37:23 <trackbot> ACTION-129 -- Adam Barth to research and propose spec text for applying plugin-types to iframes -- due 2013-05-25 -- OPEN
19:37:23 <trackbot> http://www.w3.org/2011/webappsec/track/actions/129
19:37:24 <abarth> bhill2: how about just saying the plugin-types applies to frames as well?
19:37:53 <abarth> 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
19:38:42 <abarth> mkwst_: what about differences for how IE specifies plugins
19:39:00 <abarth> abarth: IE uses GUIDs rather than mime types for plugins.  maybe we just need to let the policy contain GUIDs?
19:39:21 <abarth> abarth: we need to check with MS folks to see what they need here
19:39:32 <abarth> dveditz: the mapping is in the Windows registry
19:39:40 <wseltzer> issue-50?
19:39:40 <trackbot> ISSUE-50 -- plugin-type directive and media source list for IE CLSID guids -- raised
19:39:40 <trackbot> http://www.w3.org/2011/webappsec/track/issues/50
19:39:53 <abarth> bhill2: if we don't hear back, I can do the research to figure out what's needed here
19:40:05 <abarth> bhill2: as a first-cut, allowing a GUID is probably good enough
19:40:52 <abarth> puhley: in the case if plugin iframes, need to understand what parts of the policy inherit
19:41:17 <abarth> abarth: my proposal was to just have the plugin-types directive propagate
19:41:22 <abarth> puhley: makes sense
19:42:03 <abarth> bhill2: 15-20 minute break
19:45:19 <Zakim> - +1.781.369.aabb
19:50:17 <Zakim> -mkwst_
20:03:58 <bhill2> mike, we are back
20:04:04 <bhill2> looks like you dropped off zakim
20:04:09 <bhill2> zakim, who is here?
20:04:09 <Zakim> On the phone I see Paypal
20:04:10 <Zakim> Paypal has bhill, abarth, drogersuk, wseltzer, Dan_Veditz, tlr, Neil_Matatall, Jeff_Hodges, puhley, Tanvi
20:04:10 <Zakim> On IRC I see gopal, bhill2, jeffh, drogersuk, abarth, Zakim, RRSAgent, tlr, timeless, bhill, mkwst_, odinho, wseltzer, trackbot
20:04:23 <mkwst_> yeah, hopping back on.
20:04:26 <tanvi> tanvi has joined #webappsec
20:04:46 <wseltzer> [restarting]
20:04:53 <gopal> I dropped off the call, will join shortly
20:05:09 <Zakim> +mkwst_
20:05:26 <dveditz> dveditz has joined #webappsec
20:05:36 <dveditz> Zakim, who is here?
20:05:36 <Zakim> On the phone I see Paypal, mkwst_
20:05:37 <Zakim> Paypal has bhill, abarth, drogersuk, wseltzer, Dan_Veditz, tlr, Neil_Matatall, Jeff_Hodges, puhley, Tanvi
20:05:37 <Zakim> On IRC I see dveditz, tanvi, gopal, bhill2, jeffh, drogersuk, abarth, Zakim, RRSAgent, tlr, timeless, bhill, mkwst_, odinho, wseltzer, trackbot
20:05:50 <wseltzer> scribenick: dveditz
20:06:11 <wseltzer> rrsagent, draft minutes
20:06:11 <RRSAgent> I have made the request to generate http://www.w3.org/2013/04/25-webappsec-minutes.html wseltzer
20:06:20 <bhill2> rrsagent, set logs public visible
20:07:28 <wseltzer> chair: bhill
20:08:14 <Zakim> + +1.781.369.aacc
20:10:16 <puhley> puhley has joined #webappsec
20:10:26 <dveditz> the tahoe-lafts reference is to referer-blocking, discussed as far back as our first face-2-face
20:10:51 <wseltzer> [link: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1890]
20:10:51 <dveditz> bhill2: the strawman would be to restrict referer on non-same-origin loads
20:11:25 <dveditz> abarth: a referer-restricting proposal is on the whatwg wiki
20:11:43 <abarth> http://wiki.whatwg.org/wiki/Meta_referrer
20:11:58 <dveditz> dveditz: we (mozilla) have also had referer-restricting add-ons
20:12:21 <dveditz> abarth:  options: none, always, truncate, default (normal behavior)
20:12:29 <dveditz> tanvi: chrome has implemented this?
20:12:32 <dveditz> abarth: yes
20:12:40 <dveditz> tanvi:  there's a mozilla bug on this as well
20:12:52 <dveditz> abarth:  integrating with CSP is better than a one-off proposal
20:13:06 <dveditz> abarth: we have customers interested in this, one of them is facebook
20:13:18 <dveditz> tanvi:  facebook is contributing to the mozilla implementation
20:13:47 <dveditz> abarth: now that facebook is switching to always https there are sites who still need to know facebook was the referring site
20:13:52 <tanvi> mozilla's bug on this - https://bugzilla.mozilla.org/show_bug.cgi?id=704320
20:14:01 <dveditz> bhill2: I'm drafting an action for mike since he expressed interest
20:14:16 <dveditz> bhill2: haven't heard any objections, calling that done
20:14:28 <dveditz> bhill2: moving on to no-mixed-content
20:14:28 <wseltzer> action-130?
20:14:28 <trackbot> ACTION-130 -- Mike West to draft text on referer control policy -- due 2013-05-25 -- OPEN
20:14:28 <trackbot> http://www.w3.org/2011/webappsec/track/actions/130
20:15:00 <dveditz> bhill2: dveditz calls it ugly cruft and then says he supports the change
20:15:10 <tanvi> there are some objections to the "always" behavior - https://bugzilla.mozilla.org/show_bug.cgi?id=704320#c57
20:16:00 <dveditz> neil: I was confused when we talked about this on the list... what happens when you specify a raw host?
20:16:45 <dveditz> bhill2: lets talk about a new directive "no-mixed-content". will it be useful if browsers support the csp 1.1 spec language
20:16:54 <virginie> virginie has joined #webappsec
20:17:20 <drogersuk> drogersuk has joined #webappsec
20:17:22 <dveditz> abarth: I was originally a supporter but I think the spec's default behavior is better
20:17:35 <dveditz> neil: I agree [neil originally proposed this directive]
20:18:40 <dveditz> 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
20:18:58 <wseltzer> issue-38?
20:18:58 <trackbot> ISSUE-38 -- Discuss no-mixed-content further as a 1.1 experimental directive -- open
20:18:58 <trackbot> http://www.w3.org/2011/webappsec/track/issues/38
20:19:15 <dveditz> bhill2: ok so we'll call that one closed
20:19:34 <dveditz> bhill2: last one is json-src/json-sink I proposed
20:20:00 <dveditz> bhill2: twitter folks expressed interest in handling legacy URLs this way
20:20:25 <dveditz> neil: sticking with adam's "two requests" policy we can probably drop this -- we don't need it anymore
20:20:41 <neil> neil has joined #webappsec
20:21:06 <dveditz> bhill2: we don't have an ISSUE for that but we can declare it tabled until a customer requests it
20:21:16 <dveditz> bhill2: any other proposed directives?
20:21:53 <dveditz> [looking at wiki]
20:22:11 <dveditz> abarth: I have two proposals I mentioned at the beginning of the mtg
20:22:38 <wseltzer> [http://www.w3.org/Security/wiki/Content_Security_Policy]
20:22:53 <bhill2> http://www.w3.org/Security/wiki/Content_Security_Policy
20:23:02 <dveditz> bhill2: we've incorporated all the wiki items from the 1.1 list... looking at experimental
20:23:11 <dveditz> bhill2: no-external-navigation looks interesting
20:23:29 <dveditz> bhill2: no-user-js (protect against self-xss in the url bar)
20:23:39 <dveditz> bhill2: all browsers have implemented that implicitly already
20:24:02 <dveditz> tanvi: we talked about whether it's still needed for "developer tools/consoles"
20:24:25 <dveditz> bhill2: option to restruct srcipt-src to specific content-types
20:26:12 <dveditz> bhill2: looking at the list on the screen, is there anyone who wants to see one of these progress further?
20:26:27 <dveditz> tanvi: what about policy-uri?
20:26:43 <dveditz> bhill2: we talked about that earlier, dveditz is drafting spec languages
20:26:54 <dveditz> bhill2: I'll take an action to clean up this page
20:27:39 <dveditz> bhill2: inclined to look at proposals from zalewski [looking at no-external-navigation on screen]
20:28:29 <dveditz> bhill2: time-of-check/time-of-use with the navigation bar changing but the page contents not appearing to
20:28:50 <dveditz> bhill2: you have to have script injection to do this, right?
20:29:15 <dveditz> abarth: you can do that in other ways, like named-window navigation. chrome tries to prevent that in different ways
20:29:48 <Zakim> - +1.781.369.aacc
20:30:20 <dveditz> abarth: I'm not sure this attack is super practical (without script injection)
20:30:46 <dveditz> bhill2: you didn't think it was worth trolling through old ideas unless we had more recent expressions of interest
20:31:28 <dveditz> 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
20:31:49 <dveditz> abarth: "please sandbox this and give it NAME so I know I am talking to it"
20:32:01 <dveditz> jeffh: is this written down?
20:32:17 <dveditz> abarth: yes
20:33:00 <dveditz> abarth: preface -- not saying "we should adopt this", bringing this forward as a useful idea to see what people think
20:33:39 <dveditz> dveditz: what about malicious intentional name collisions
20:33:58 <dveditz> abarth:  the proposal tries to address that by having a browser-supplied component
20:34:53 <dveditz> abarth:  I can't share this document, I'll try to write up one I can share
20:35:19 <dveditz> abarth: the other, he's having some success deploying CSP in parts of google, but others trying to deploy it is a mess
20:36:15 <dveditz> abarth: half the xss mz sees is server-xss (stored/reflected), the other half is dom-xss
20:36:51 <dveditz> abarth: his proposal is a way to assign a policy per element
20:37:00 <dveditz> abarth: "below this element apply this policy"
20:37:10 <jeffh> https://www.owasp.org/index.php/DOM_Based_XSS
20:37:19 <dveditz> abarth: "turn innerHTML into textContent"
20:37:35 <dveditz> abarth: people have thought about this in terms of a "jail" tag
20:38:17 <dveditz> abarth: but he's thinking in terms of a parsed dom tree -- assume you've parsed the HTML the way the site intended
20:38:48 <dveditz> abarth:  "in this subtree don't allow forms"
20:39:13 <dveditz> bhill2: is this a declarative thing in terms of csp or is this a dynamic set of rules ala .mario et al
20:39:39 <dveditz> abarth: he likes the declarative aspect of csp but the global nature of it introduces problems
20:40:16 <dveditz> bhill2: declarative policies can be simpler, but at some point declarative becomes more complex than a simple dynamic hook
20:40:41 <neil_> neil_ has joined #webappsec
20:41:11 <dveditz> bhill2: a "reference monitor" script (specified in a privileged place like a header) might be simpler
20:42:06 <dveditz> neil: I like bhill2's proposal better. mz's approach lends itself to static checking
20:42:16 <dveditz> neil: (a good thing)
20:43:19 <dveditz> abarth: I don't think he's tried any of these, these are just ideas
20:43:35 <dveditz> bhill2: let me find a reference to the gareth heyes approach
20:44:01 <dveditz> abarth: what would you like to get out of the dom monitor, neil?
20:44:18 <dveditz> neil_: haven't thought about it much yet, we're just starting to look into it
20:44:31 <dveditz> bhill2: JSLR is what it's called -- that's something different though
20:45:01 <dveditz> bhill2: but mario heiderach has talked about this kind of DOM jailing
20:45:27 <dveditz> abarth: just tossing these out for high-level feedback
20:45:48 <dveditz> bhill2: bring these up on the list for more feedback
20:45:57 <dveditz> abarth: sounds like there was more interest in the first proposal
20:46:37 <dveditz> bhill2: mark still want to talk about bookmarklets? "What does it mean to support bookmarklets?"
20:47:20 <dveditz> mkwst_: twitter and other sources report they're being overwhelmed with reports from blocked content injected by user-intended mechanisms
20:47:30 <dveditz> mkwst_: clearly we want bookmarklets to execute
20:48:02 <dveditz> mkwst_: 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
20:48:30 <dveditz> mkwst_: looking for thoughts from others, especially other implementors
20:48:54 <dveditz> neil_: philosophically a user intended the bookmarklet to run
20:49:14 <dveditz> abarth: I think the question is more technical -- how close can we get to that intent, safely?
20:49:34 <dveditz> abarth: what if the bookmarklet calls a function that the page defined?
20:50:01 <dveditz> neil_: if it injects a script that violates the policy it should be allowed to do that
20:50:16 <dveditz> bhill2: the simplest implementation is that if you fire a bookmarklet you turn off CSP
20:50:25 <dveditz> neil_: do you turn it back on again after?
20:50:49 <dveditz> bhill2: if that's the simplest model, is that OK?
20:51:11 <dveditz> abarth: what if it turns off CSP for the whole document, are you ok with that?
20:51:34 <dveditz> neil_: I'm uncomfortable with that -- sometimes these days you never leave a page. turned off from now until forever?
20:52:03 <dveditz> neil_: running a bookmarklet should be like "sudo"
20:53:04 <dveditz> 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?
20:53:45 <dveditz> mkwst_: 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
20:54:25 <dveditz> bhill2: this is the same issue as extensions?
20:54:38 <dveditz> abarth: not quite, extensions have their own context so it's somewhat simpler
20:55:06 <dveditz> mkwst_: in chrome we have the concept of an isolated world where the extension doesn't have access to the content of the page
20:56:09 <dveditz> bhill2: so the current model of a bookmarklet is that it's just inline script injected into a document?
20:56:46 <dveditz> bhill2: what if we gave the bookmarklet access to the CSP dynamically?
20:56:57 <tanvi1> tanvi1 has joined #webappsec
20:57:07 <dveditz> abarth: libraries and extensions are easier to get changed since there are fewer authors
20:57:29 <dveditz> abarth: but there are thousands of bookmarklets and they don't have updates
20:57:44 <dveditz> neil_: can we infer the behavior from it's actions?
20:59:01 <dveditz> dveditz: neil, do you know this traffic actually omes from bookmarklets vs extensions?
20:59:29 <dveditz> abarth:  the translate thing in chrome is something we know about and we're working on a solution
20:59:56 <dveditz> neil_: translate is the one we see mostly, plus lastpass
21:00:39 <dveditz> abarth: maybe we need to convince lastpass to be more like an extension and less like a bookmarklet, and then solve the extension problem
21:00:58 <dveditz> bhill2: is this the end of our csp discussion? any other items?
21:02:13 <dveditz> bhill2: we're going to meet with the webapps folks later, they're proposing Web Components
21:02:30 <dveditz> bhill2: would make me sad if those are just syntactic suger for <script src=>
21:03:10 <dveditz> bhill2: because in that case buggy components from popular providers (e.g. facebook, twitter) could break the web
21:03:40 <dveditz> bhill2: 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
21:04:02 <dveditz> abarth: I agree this is an important issue. I tried to think about it and didn't come up with a solution
21:04:37 <dveditz> abarth: 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
21:05:07 <dveditz> abarth: unappealing from a security POV where we've isolated part of the object and not the scripts
21:05:36 <dveditz> bhill2: not just the page reaching into the shadow dom, it's also the widget reaching out into the page
21:05:51 <dveditz> abarth: good example is a tab-switcher component
21:06:35 <dveditz> abarth: 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
21:06:59 <dveditz> abarth: you wouldn't want the author of the tab-switcher to be able to look inside the tabs themselves
21:07:30 <dveditz> abarth: the tab-switcher offers "whats the current tab" or "go to next tab" which means there's scvript contact between the two
21:07:57 <dveditz> abarth: 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
21:10:14 <dveditz> abarth: 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
21:10:45 <dveditz> neil_: you could accomplish the goal using frames and postMessage, but it'd be ugly and janky, right?
21:11:21 <dveditz> abarth: yes, you could do it something like that. it works, but the api designers found it cumbersome ("it sucks")
21:11:47 <dveditz> bhill2: it's nice syntactic sugur but it does so by erasing the security boundary completely
21:12:08 <dveditz> bhill2: maybe there's some kind of declarative boundary we could give to components through something like CSP
21:12:28 <dveditz> bhill2: I want to at least raise this concept with the WF
21:12:30 <dveditz> WG
21:13:11 <dveditz> 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.
21:14:16 <dveditz> bhill2: www.w3.org/TR/components-intro/
21:14:23 <dveditz> (old, but links to the latest)
21:14:32 <bhill2> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
21:18:40 <Zakim> -mkwst_
21:19:09 <wseltzer> rrsagent, make minutes
21:19:09 <RRSAgent> I have made the request to generate http://www.w3.org/2013/04/25-webappsec-minutes.html wseltzer
21:39:30 <tanvi> tanvi has joined #webappsec
21:49:04 <jeffh> jeffh has joined #webappsec
22:15:33 <puhley> puhley has joined #webappsec
22:36:50 <bhill2> bhill2 has joined #webappsec
22:36:55 <bhill2> zakim, who is here?
22:36:55 <Zakim> On the phone I see Paypal
22:36:56 <Zakim> Paypal has bhill, abarth, drogersuk, wseltzer, Dan_Veditz, tlr, Neil_Matatall, Jeff_Hodges, puhley, Tanvi
22:36:56 <Zakim> On IRC I see bhill2, jeffh, abarth, Zakim, RRSAgent, tlr, timeless, bhill, mkwst_, odinho, wseltzer, trackbot
22:37:07 <drogersuk> drogersuk has joined #webappsec
22:37:20 <virginie> virginie has joined #webappsec
22:38:55 <puhley> puhley has joined #webappsec
22:39:00 <bhill2> scribenick: bhill2
22:39:04 <tanvi> tanvi has joined #webappsec
22:39:09 <bhill2> tlr: we are out of charter by a month, my bad
22:39:32 <bhill2> tlr: new charter is a good opportunity to advertise v.next of CSP and encourage other with interest to join
22:39:45 <bhill2> tlr: will be getting it to the advisory committee in the relatively new future
22:40:00 <bhill2> tlr: but we have one last chance to put additional pieces of scope in if we think it is important
22:40:37 <bhill2> tlr: from today's perspective, are there things people think should be in the charter?
22:40:48 <bhill2> tlr: and I think this is a good braintrust that is important to keep around in the w3c
22:40:58 <bhill2> abarth: in tc39 we are working on string template mechanism
22:41:13 <bhill2> ... idea that we can stick an HTML marker in front of a string and it will be "safe"
22:41:29 <bhill2> ... not necessarily the right expertise in TC39, maybe here
22:41:42 <bhill2> ... official term is "HTML quasi handler"
22:42:31 <bhill2> ... something like `hello ${{foo}}!`
22:42:43 <bhill2> ... this looks like big xss hole
22:42:54 <bhill2> so what if we put "html" in front of it and it makes it not xss
22:43:09 <bhill2> ... we could help explain what that would mean to prevent xss
22:44:30 <bhill2> ... or might be `hello <h1>${{name_here}}</h1>`
22:44:46 <bhill2> dveditz: what if this is not in a browser context?
22:45:15 <bhill2> abarth: yes, they are very interested in this, so have a pluggable slot for a quasi-handler that can produce many kinds of output
22:45:33 <bhill2> ... so a quasi-handler that understands html and can do it safely is what they think would be nice
22:45:48 <bhill2> ... so we can either convince them it is a bad idea, or help them figure out what to put in that box
22:46:26 <bhill2> bhill2: like safeHTML in MSOffice?
22:46:47 <bhill2> abarth: no, because that still produces a string sent over network, in the browser context we can just generate dom nodes directly
22:47:04 <bhill2> dveditz: can still be a string over network, e.g. in node.js
22:47:34 <bhill2> adrianb: have exposed in IE exposed .toStaticHTML that exposes office's safeHTML component
22:47:44 <tanvi1> tanvi1 has joined #webappsec
22:47:49 <bhill2> ... since IE 8, used throughout web platform at MS
22:47:55 <wseltzer> zakim, Paypal also has adrianb
22:47:55 <Zakim> +adrianb; got it
22:47:58 <bhill2> ... HTML email, string contexts, etc
22:48:23 <bhill2> ... sounds like a good workstream, not sure something producing nodes is a better solution
22:48:56 <bhill2> ... given use cases we do see for toStaticHtml, a node tree as a result isn't what I necessarily want to see
22:49:15 <bhill2> dveditz: has been lots of resistance to accepting .tostatichtml in the html standard?
22:49:29 <bhill2> ... lots of people have asked for it, not showing up, don't know why
22:49:58 <bhill2> adrianb: to my knowledge, no conversations in the last 2-3 years about adding this
22:50:03 <bhill2> dveditz: people desperately need it
22:50:28 <bhill2> adrianb: possibly last discussion was 4-5 years ago, world is a different place, shouldn't assume absence from current spec suggests anything
22:50:52 <bhill2> abarth: a good problem space for this group to take on, regardless of exact character of solution
22:51:28 <bhill2> adrianb: yes, and there are problems, changing spec, underlying infrastructure for safeHTML is richer than exposed to the browser
22:51:40 <bhill2> ... at a high level a good area to engage in
22:52:53 <bhill2> tlr: other ideas?
22:53:14 <bhill2> dveditz: blocking mixed active content, mozilla encountering same problems as chrome / webkit
22:53:27 <bhill2> ... 3 major browsers have made different choices as to what gets blocked and not
22:53:45 <bhill2> ... maybe incomplete reverse engineering, maybe not knowing who to follow
22:53:51 <bhill2> ... might be nice for it to be consistent
22:54:35 <bhill2> adrianb: would value discussion from this community on these choices, e.g. with regard to XHR
22:55:31 <bhill2> ... e.g. want to make a CORS request for data on an insecure endpoint, but maybe not sensitive information... e.g. weather data
22:56:00 <bhill2> abarth: would be good to have a spec to point to documenting these choices
22:56:54 <bhill2> 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
22:57:13 <bhill2> ... not lots of sites currently broken, but things we want to support that are currently blocked
22:57:39 <bhill2> dveditz: we talked with CSP about how to effectively block this
22:57:56 <bhill2> ... does seem to be overlap between CSP we are specifying and mixed content blocking
22:58:19 <bhill2> tlr: discussion of integrity protections imply this is all one ball of hair
22:58:52 <bhill2> tanvi: say the only thing the spec says is, block mixed javascript, and browsers can decide to do more?
22:59:10 <Zakim> +[Microsoft]
22:59:26 <bhill2> abarth: I see the fetch spec getting hooks for CSP to turn and off, can define default policy for this regarding mixed content
22:59:56 <bhill2> dveditz: we could make up a rule and say we will block mixed scripts unless you put it in csp
23:00:04 <bhill2> abarth: different issue from explaining what browsers do by default
23:00:06 <dross> dross has joined #webappsec
23:00:35 <bhill2> dveditz: there is value in both specifying and opt out for use cases broken by what we already agree upon
23:00:46 <bhill2> tlr: deserves a problem statement
23:01:20 <bhill2> ACTION bhill2 to write a problem statement exploring the space of mixed content specifications
23:01:21 <trackbot> Created ACTION-131 - Write a problem statement exploring the space of mixed content specifications [on Brad Hill - due 2013-05-02].
23:01:40 <bhill2> ACTION bhill2 to write a problem statement exploring the space of HTML templating / safe HTML
23:01:40 <trackbot> Created ACTION-132 - Write a problem statement exploring the space of HTML templating / safe HTML [on Brad Hill - due 2013-05-02].
23:02:35 <bhill2> dveditz: we are seeing reports from users about active mixed content blocking breaking sites, and different behavior between IE, Chrome
23:02:55 <bhill2> abarth: I value interop higher than any of the particular details
23:03:19 <bhill2> tanvi: have been trying to reverse engineer the behavior, e.g. with children, grandchildren, etc.  would be nice to know uniform behavior
23:04:04 <wseltzer> zakim, Microsoft has David_Ross
23:04:04 <Zakim> +David_Ross; got it
23:07:20 <bhill2> drogers: is there formal remit for this group to do sec reviews of other specs like web crypto?
23:07:50 <bhill2> abarth: we have internal groups that do that inside Google, route feedback through individual participants or Security IG
23:08:05 <bhill2> dvetitz: we do similar, make sure feedback gets to SSOs as we do implementations
23:08:20 <bhill2> adrianb: we would be cautious about adding something like that to the WG charter
23:13:40 <bhill2> 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
23:14:16 <bhill2> ... 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
23:19:06 <dveditz> dveditz has joined #webappsec
23:28:56 <puhley> puhley has joined #webappsec
23:32:15 <tanvi1> tanvi1 has joined #webappsec
23:32:17 <bhill2> https://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html
23:32:57 <dveditz> scribenick: dveditz
23:33:49 <dveditz> bhill2: a week ago sent out a call for comments on the UI safety draft
23:34:17 <dveditz> bhill2: I have not seen any substantive comments, agreements, disagreements
23:34:49 <dveditz> bhill2: the one piece of substantial disagreement was removing the top-only directive
23:35:25 <dveditz> dross: yes... [missed] ... its an artificial limitation, but we can discuss it
23:35:43 <dveditz> bhill2: made editorial decision. there's no compatibility base that will break by removing it
23:35:50 <dveditz> dross: not exactly compat, but a limitation
23:36:12 <dveditz> dross:  ms.com hosting live.com hosting a ms.com frame -- that's where you see the difference
23:36:56 <dveditz> dross: if you look at that scenario--not sandbox frame which caused the full ancestor check--that's a legitimate case
23:37:30 <dveditz> dross: you have to make everything align on the same domain if you don't have the top-only directive
23:37:48 <dveditz> dross: (allow-from might solve many cases we can identify)
23:38:11 <dveditz> dross: live.com and ms.com are essentially the same entity
23:38:24 <dveditz> bhill2: any frame above you in the stack can attack you
23:38:39 <dveditz> dross: but you're trusting the top-level, which is in this case ms.com
23:39:12 <dveditz> bhill2: but you're trusting the top context not to frame someone you don't trust, or to make a mistake
23:39:47 <dveditz> dross: if you look at this scenario w/out sandbox frames....
23:40:14 <dveditz> abarth: are yoiu saying nowhere on ms.com you ever frame an untrusted domain? if you do that once you lose
23:40:38 <dveditz> dveditz: but that's the kind of bug this feature is trying to provide airbags for
23:41:10 <dveditz> bhill2: what if the user has navigated the subframe somewhere not actually expected by the top-level site?
23:41:25 <dveditz> bhill2: if there's no csp frame-src directive to restrict that then you can also lose
23:41:43 <dveditz> dross: good point. wasn't saying top-only should be the default
23:41:59 <dveditz> dross: maybe it makes things more simplistic to get rid of top-only
23:42:12 <dveditz> dross: {sigh} yeah
23:42:42 <dveditz> bhill2: what we're trying to achieve is to make it easier  to construct a simple policy that is safe than unsafe
23:42:53 <dveditz> dross: not disagreeing that the default should be the full ancestor check
23:43:21 <dveditz> bhill2: do you know of specific sites that need this feature to function properly
23:43:25 <dveditz> dross: no
23:43:58 <dveditz> 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
23:44:23 <dveditz> bhill2: let's bikeshed it until we hear more people who need it, for now remove top-only
23:44:32 <dveditz> bhill2: feedback on the rest of the content?
23:44:36 <dveditz> dross: no, that was about it
23:45:01 <dveditz> bhill2: have you seen anne's feedback? would you like to see more concrete descriptions of when these checks happen
23:45:08 <dveditz> bhill2: relative to the fetch spec
23:45:40 <dveditz> 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
23:46:39 <dveditz> bhill2: from anne -- concerned that the blocked-target-xpath introduces too much complexity
23:47:11 <dveditz> bhill2: I think this is using standard constructs from dom level 2 core and shouldn't be a problem -- is this an insane idea?
23:47:45 <dveditz> bhill2: annes thought that unless you had a lot of state information an app wouldn't know how to construct the right page
23:48:10 <dveditz> 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
23:50:19 <dveditz> abarth: 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
23:50:46 <dveditz> abarth: and ids
23:51:57 <dveditz> abarth: you have an unsafe atrtibute on ui elements , lisntfor events
23:52:48 <abarth> foo.addEventListener("click", safeEventsPlease(function(event) { ... handleTheEvent ... }));
23:53:13 <dveditz> abarth: we had this problem with postMessage() where we specified a default behavior that was unsafe and it was hard to write safe code
23:54:02 <wseltzer> issue-52?
23:54:02 <trackbot> ISSUE-52 -- unsafe attribute requires every handler to check -- raised
23:54:02 <trackbot> http://www.w3.org/2011/webappsec/track/issues/52
23:54:30 <dveditz> abarth: have a dependency on touch events but some people don't like touch events
23:55:20 <dveditz> (sorry, having issues and missed a bit)
23:56:05 <dveditz_> dveditz_ has joined #webappsec
23:56:31 <dveditz_> abarth: a concrete example -- in chrome w're working on out of process iframes
23:57:09 <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
23:57:22 <dveditz_> bhill2: an interesting problem, how do we deal with it
23:58:04 <dveditz_> abarth: I don't want to be super negative, just telling you issues we're seeing in the spec
23:58:54 <dveditz_> scribenick: dveditz_
23:59:40 <dveditz_> reposting because I had the wrong nick:
23:59:41 <dveditz_> [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