IRC log of webappsec on 2013-04-25
Timestamps are in UTC.
- 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