07:18:07 <RRSAgent> RRSAgent has joined #webappsec
07:18:07 <RRSAgent> logging to http://www.w3.org/2012/11/01-webappsec-irc
07:35:59 <bhill2> zakim, please call St_Clair_2
07:35:59 <Zakim> sorry, bhill2, I don't know what conference this is
07:36:07 <bhill2> zakim, this is 92794
07:36:07 <Zakim> sorry, bhill2, I do not see a conference named '92794' in progress or scheduled at this time
07:42:04 <bhill2> https://www.w3.org/2002/09/wbs/35125/TPAC2012/registrants#WebAps
07:59:09 <bradee-oh> bradee-oh has joined #webappsec
08:02:30 <bhill2> zakim, this is 92794
08:02:30 <Zakim> sorry, bhill2, I do not see a conference named '92794' in progress or scheduled at this time
08:07:38 <bhill2> for folks hoping to dial in, my apologies
08:07:55 <bhill2> I got the offset from UTC wrong in scheduling the call, so our bridge won't be available until 11:00 am local time
08:08:00 <bhill2> trying to get tomorrow's call time adjusted
08:14:48 <timeless> timeless has joined #webappsec
08:19:43 <tanvi> tanvi has joined #webappsec
08:23:09 <tanvi1> tanvi1 has joined #webappsec
08:34:17 <bhill2> we may try to move some of the UISafety discussion agenda time to tomorrow afternoon
08:34:39 <bhill2> to accomodate Giorgio's participation, as I forgot that today is a holiday in Catholic countries
08:35:02 <bhill2> but we will keep the Accessibility discussion, at least, on today's agenda
08:39:24 <bhill2> looks like Giorgio won't be able to make it in any case, so we'll leave the schedule unchanged
08:45:43 <bhill2> Meeting: WebAppSec Face to Face, Day 1, TPAC, 1-Nov-2012
08:45:48 <bhill2> Chair: bhill2, ekr
08:46:06 <bhill2> Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0090.html
08:47:21 <DanD> DanD has joined #webappsec
08:48:00 <ekr> ekr has joined #webappsec
08:48:03 <ekr> scribe ekr
08:48:40 <ekr> rrsagent, begin
08:49:30 <ekr> bhill: major issue with testing/CORS is identifying what coverage we have and what features may be at risk because of test coverage
08:50:15 <ekr> bhill: there is a CORS fork in WHATWG
08:50:46 <ekr> ... want to discuss how to deal with this.
08:51:29 <ekr> dveditz: what's the reason for the fork?
08:51:46 <ekr> odin: Anne was unhappy about the Invited Expert agreement.
08:52:53 <ekr> bhill: only substantive change seems to be changes to references in WHATWG spec.
08:53:32 <ekr> ... best strategy may be to discuss the changes with him.
08:53:51 <gopal> gopal has joined #webappsec
08:54:15 <ekr> ekr: which specs do the vendors intend to follow
08:54:30 <ekr> odin: we usually follow the most updated specs.
08:54:31 <sgodard> sgodard has joined #webappsec
08:55:38 <ekr> bhill: I don't think we should drop this. It's part of our package.
08:56:38 <fanfi> fanfi has joined #webappsec
08:57:28 <ekr> correction to above: there is a change to referrer handling
08:58:28 <ekr> bhill: let's ask Anne about that.
08:58:42 <ekr> ... does Mozilla have anything to say about which set of specs they intend to track.
08:59:40 <ekr> dveditz:we would expect to follow the CORS spec, but if there is an updated spec in another standards body, we might follow that?
09:00:25 <ekr> bhill: so we would need to decide how to handle future updates
09:00:41 <tanvi> can we have a link to the fork?
09:05:00 <ekr> [discussion of whether we can take this material]
09:05:06 <ware> ware has joined #webappsec
09:05:14 <ekr> ekr: what is the IPR status of this contribution
09:05:18 <bhill2> https://github.com/whatwg/fetch
09:05:31 <bhill2> ^^^ link to fork of CORS
09:06:59 <ekr> bhill: there is a mechanism for independent contributions that aren't invited experts.
09:07:50 <odinho_> s|https://github.com/whatwg/fetch|-> https://github.com/whatwg/fetch GitHub link to fork of CORS|
09:07:52 <ekr> ... so maybe we can get such an agreement in place when there is a fixed list of WHATWG changes.
09:07:56 <odinho_> s|^^^ link to fork of CORS||
09:08:26 <ekr> odinho: this is happening with a bunch of other specs as well.
09:08:59 <ekr> bhill: let's start by asking Anne what he is doing with other specs and then we can follow up with W3C staff
09:09:12 <ekr> ... we had a set of objections to CSP on the basis of privacy
09:09:40 <ekr> ... post-LC comments about reporting mechanism as a back channel and feature reporting as a fingerprinting vector.
09:09:57 <ekr> ... we had consensus in the WG but I hosted a plenary session yesterday to forestall external issues
09:10:05 <ekr> .... will post my presentation
09:10:10 <bhill2> http://www.w3.org/wiki/Fingerprinting
09:10:21 <ekr> ... basic idea was to establish a set of guidelines for these discussions
09:11:10 <ekr> ... background for privacy interest group on the security community's assessment of the situation.
09:11:30 <ekr> ... with the hope that their guidelines will take into consideration meaningful threat modelling
09:11:52 <ekr> ... hopefully will give us better framework for the future.
09:11:58 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-webappsec-minutes.html odinho_
09:12:18 <ekr> ekr: some people may not be entirely convinced
09:13:40 <ekr> dveditz: there was that other guy who wanted to have reporting on user-agent injected addons. I'm less sympathetic to tht
09:13:43 <ware> ware has joined #webappsec
09:14:42 <ekr> dveditz: edward's problem is something we should address
09:15:04 <ekr> dveditz: ingo chow wants to report on add-ons to see if someone is trying to target his site
09:15:08 <bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0069.html
09:15:15 <tlr> tlr has joined #webappsec
09:15:39 <ekr> dveditz: concern is a malicious add-on adding scripts
09:15:48 <ekr> ... but in that case it could probably turn off CSP reporting
09:16:04 <ekr> ... from a privacy standpoint it's not the server's business
09:16:26 <ekr> ... what the client runs
09:16:35 <odinho_> Present+ Odin_Horthe_Omdal Brad_Hill
09:16:42 <odinho_> Present+ Tanvi_Vyas
09:17:04 <ekr> bhill: an issue of priority of constituencies
09:17:28 <ekr> ... what about an add-on that injects ads
09:18:13 <ekr> ekr: it's the user's browser
09:19:32 <ekr> bhill: example of intermediaries injecting ads, rewritign scripts, etc.
09:20:12 <ekr> odinho: add-ons are effectively part of the browser and shouldn't be influenced by comments
09:20:39 <ekr> dveditz: we haven't fixed mozilla with addons reporting
09:21:31 <ekr> ... would like an add-on that injects content in the CSP page should be able to override CSP but should have to explicitly do so.
09:22:20 <ekr> bhill: should add-ons be able to disable reporting
09:22:25 <ekr> ... can do it by brute force method
09:22:40 <ekr> odinho: absolutely.
09:23:29 <ekr> dveditz: you can always suppress it some other way
09:24:22 <ekr> bhill: to wrap up the privacy thread...
09:24:38 <ekr> ... replies from dveditz and mike west that it's not CSP's job to police extensions
09:24:54 <ekr> ... is this something we want to resolve as the WG
09:25:16 <ekr> odinho: maybe in a FAQ
09:25:33 <ekr> bhill: there seems to be consensus in the WG.
09:25:59 <ekr> dveditz: it's a statement on behalf of the server to enforce a policy, not a binding rule
09:26:01 <odinho_> Present+ Peleus_Uhley
09:26:24 <odinho_> Present+ Dan_Druda
09:27:10 <bhill2> proposed resolution: The priority of constituencies followed by this WG is that the user is in control of their user agent, and CSP is not a mechansim to allow resource owners to override user preferences or policy on how resources are rendered/modified/etc., including by user agent add-ons
09:27:15 <DanD> s/Dan_Druda/Dan_Druta
09:27:22 <bhill2> so resolved
09:27:56 <bhill2> action to bhill2 respond to ingo chao on official WG position re: csp policies for add-on modifications to resources
09:27:56 <trackbot> Sorry, couldn't find to. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
09:28:10 <bhill2> action bhill2 respond to ingo chao on official WG position re: csp policies for add-on modifications to resources
09:28:10 <trackbot> Created ACTION-82 - Respond to ingo chao on official WG position re: csp policies for add-on modifications to resources [on Brad Hill - due 2012-11-08].
09:28:19 <odinho_> s/action to bhill2 respond to ingo chao on official WG position re: csp policies for add-on modifications to resources//
09:28:50 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-webappsec-minutes.html odinho_
09:29:38 <bhill2> we are taking a 30 minute break
09:29:42 <odinho_> Present+ Daniel_Veditz
09:29:46 <bhill2> reconvening at 11:00 local time
09:30:07 <bhill2> next agenda topic: CORS and WHATWG fork of "Fetch", guest speaker annevk
09:44:40 <puhley> puhley has joined #webappsec
09:52:38 <bhill2> zakim, this is 92794
09:52:38 <Zakim> bhill2, I see SEC_WASWG(TPACSES)6:00AM in the schedule but not yet started.  Perhaps you mean "this will be 92794".
09:52:51 <bhill2> zakim, this will be 92794
09:52:51 <Zakim> ok, bhill2; I see SEC_WASWG(TPACSES)6:00AM scheduled to start in 8 minutes
09:53:41 <bhill2> zakim, call St_Clair_2
09:53:41 <Zakim> ok, bhill2; the call is being made
09:53:42 <Zakim> SEC_WASWG(TPACSES)6:00AM has now started
09:53:44 <Zakim> +St_Clair_2
09:54:56 <bhill2> call bridge is now open
09:55:29 <Zakim> + +1.781.369.aaaa
09:55:40 <ware> ware has joined #webappsec
09:58:15 <bradee-oh> bradee-oh has joined #webappsec
10:00:12 <annevk> annevk has joined #webappsec
10:00:20 <annevk> http://fetch.spec.whatwg.org/
10:00:28 <annevk> https://github.com/whatwg/fetch/commits
10:04:16 <bhill2> annevk: Last-Event-ID, etc. should not be on the simple header whitelist
10:04:29 <bhill2> annevk: it is about what developers can set, not what the spec can send
10:05:09 <bhill2> dveditz: clarify developers in above comment
10:05:26 <bhill2> annevk: developers are web content developers, web UA developers are "implementers"
10:05:49 <tlr> tlr has joined #webappsec
10:06:07 <odinho_> Present+ Anne_van_Kesteren
10:06:55 <ekr> ekr has joined #webappsec
10:07:17 <bhill2> annevk: diagram is buggy, should include "send"
10:07:51 <bhill2> annevk: hello world arrow at end should go all the way to dotted line
10:08:03 <bhill2> annevk: access check happens in network library, not in the XHR
10:08:20 <bhill2> annevk: long term plan is to integrate it with HTML fetch algorithm
10:08:37 <bhill2> annevk: just going to wait for implementations to stabilize
10:08:50 <odinho_> -> http://odin.s0.no/tmp/Hodges_odinho-CORS-Diagram-SimpleRequest.svg Draft of a very simple CORS overview
10:08:51 <ekr_> ekr_ has joined #webappsec
10:08:57 <bhill2> annevk: fetch handled by network layer
10:11:56 <bhill2> annevk: referrer source was feedback from mozilla about fetch algorithm
10:12:07 <bhill2> ... in some cases didn't like the header the algorithm would come up with
10:12:23 <bhill2> ... introduced concept to pass through explicit referer to override what would normally be computed
10:12:49 <bhill2> ... in certain cases you can make a choice what the appropriate referrer is
10:13:07 <bhill2> ... wanted ability to do explict setting
10:13:26 <bhill2> .. is an algorithm in a specification that invokes fetch, but control is not given to web developers
10:13:40 <bhill2> tanvi: this is for a resource to check referer when servicing a request
10:13:58 <bhill2> annevk: this is to indicate what the referrer should be for the user agent
10:14:17 <bhill2> annevk: it could be a script that invokes the XHR, or it could be the URL associated with the XHR object
10:14:37 <bhill2> annevk: could be invoked from another resource accessing using SOP
10:14:49 <bhill2> annevk: referrer includes path,etc. so might be different, even if Origin is the same
10:15:32 <bhill2> other changes are 308 status code
10:15:43 <bhill2> dveditz: should do this as it is a legitimate code
10:15:52 <bhill2> annevk: yes, other browsers do this too in other places with redirects
10:16:13 <bhill2> annevk: in practice all 3xx are not handled, need to be explicit in what ones should be
10:16:31 <bhill2> annevk: only two major changes, a typo fix, added julian and phllip to acks
10:16:38 <odinho_> Present+ Jonas_Sicking
10:17:30 <bhill2> annevk: no outstanding bugs that would cause changes to fetch algorithm
10:17:40 <bhill2> annevk: hixie and I want to wait on further work on fetch
10:17:52 <bhill2> annevk: to merge it with CORS, but that is 4 years down the road
10:18:15 <bhill2> annevk: there is one thing where developers complain, want more flexibility with access-control-allow-origin header
10:18:35 <bhill2> annevk: is * or a single value at the moment, maybe should be comma separated value for static resources with multiple consumers
10:18:48 <bhill2> annevk: need to set vary header today, lots of problems with that, proxies, etc.
10:19:23 <bhill2> jonas: if it's a static file, why would you want to protect it?
10:19:32 <bhill2> annevk: phone people are complaining because of licensing issues
10:20:35 <DanD> DanD has joined #webappsec
10:20:58 <bhill2> s/phone/font
10:21:41 <odinho_> [ discussion about dynamic vs. static ]
10:22:00 <bhill2> devditz: concerns with multiple headers could easily be addressed by resources that care
10:22:18 <bhill2> jonas: one of original concerns was that adding multiple would lead to introducing patterns, etc.
10:22:24 <bhill2> annevk: don't want to add regexs
10:22:43 <bhill2> jonas: one other problem: at time of making request, need to know if in CORS mode or not when initating fetch algorithm
10:22:47 <ware> ware has joined #webappsec
10:23:11 <bhill2> jonas: when you load script elements would like to do fetch without CORS headers without declaring in advance
10:23:20 <bhill2> annevk: that exists today
10:24:00 <bhill2> annevk: no CORS, anonymous, and cross-origin modes
10:24:14 <bhill2> annevk: want to use "potentially CORS-enabled fetch" algorithm
10:24:22 <bhill2> odinho: has a no-CORS path
10:24:40 <annevk> http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch
10:24:57 <sicking> sicking has joined #webappsec
10:25:50 <bhill2> annevk: doesn't work as I thought
10:25:56 <bhill2> jonas: only place it is useful is script tags
10:25:59 <bhill2> annevk: images too
10:26:24 <bhill2> jonas: for images, either going to use image or not, if you need it, need to set CORS anyway
10:26:40 <bhill2> annevk: either way, change would be in fetch algorithm, not in CORS
10:26:53 <bhill2> odinho: also in track, for subtitles
10:28:05 <bhill2> annevk: only outstanding possible change is comma separated origins
10:28:16 <bhill2> dveditz: need to see if browsers would take that change
10:28:25 <bhill2> annevk: shouldn't be a problem, browsers don't object
10:28:43 <bhill2> annevk: origin spec allows space-separated origins
10:29:11 <bhill2> annevk: I think this is a bug in origin, tried to errata, but errata process doesn't apply to changing spec semantics
10:29:49 <bhill2> odinho: likely to result in bugs from users that just match a string
10:30:08 <bhill2> jonas: worried this will affect fonts, mozilla is only one using CORS for fonts
10:30:24 <bhill2> jonas: didn't realize that origin is changed to null on redirects, breaks fonts
10:30:31 <bhill2> annevk: needs to set * in that case on the resource
10:30:57 <bhill2> dveditz: reason origin spec had a list was interest in using it as an anti-CSRF spec
10:31:15 <bhill2> annevk: but implemenations differ, webkit is consistently null
10:31:44 <bhill2> ... allowing choice, as is done in origin spec, is bad
10:31:55 <bhill2> ... servers can't rely on it then
10:33:25 <bhill2> ... is worth pointing out in the syntax that the null behavior is explicitly specified as the behavior vs. the multi-origin option in Origin spec
10:34:47 <bhill2> dveditz: asymmetric to do multiple values for servers, not for redirect from client
10:35:04 <bhill2> annevk: best chocie is to get patent committments and go all the way to Rec quickliy
10:35:17 <bhill2> annevk: can go directly to PR if we have evidence of implemenations
10:35:36 <bhill2> annevk: a year later we can incorporate any updates
10:36:19 <bhill2> bhill2: only concern here is that we have knowledge of implemenations so we can know what is "at risk"
10:36:36 <bhill2> odinho: only know about opera, have implemented everything in spec, hopefully is correct and no omissions
10:36:49 <bhill2> gopal, are you there?
10:36:52 <gopal> yes
10:37:38 <bhill2> based on your knowledge of tests, any features at risk?
10:37:50 <bhill2> gopal: hard to comment on that, will address in next agenda item
10:38:07 <bhill2> ... lots of tests, hard to associate with what parts of spec the tests cover
10:38:31 <bhill2> ... syntax elements from section 5 have lots of coverage, but not clear, should walk through tests to identify at risk items
10:38:44 <bhill2> ... can go through analysis in the afternoon when returned from lunch
10:39:35 <bhill2> bhill2: will do that after lunch, go directly to PR if no at risk features
10:41:12 <bhill2> gopal: allow origin header currently says origin list, but below says single origin, star or null
10:41:23 <bhill2> annevk: that's true, why I tried to follow errata
10:41:28 <bhill2> s/follow/file
10:42:04 <bhill2> annevk: already a note under access-control-allow-origin, syntax is constrained by resource processsing model and what browsers check against
10:42:13 <bhill2> annevk: so no changes needed there
10:42:40 <bhill2> annevk: confusion was whether this was a list of servers allowed, when really it was a redirect stack
10:42:55 <bhill2> odinho: parser in spec is future compliant
10:43:40 <bhill2> annevk: would be good to update to allow more than one access-control-allow-access headers? need to do ua sniffing anyway for future compat
10:44:02 <bhill2> odinho: if current impls read only first value and ignore later
10:44:07 <bhill2> annevk: still broken, need sniffing
10:44:32 <bhill2> annevk; main problem is caching and broken proxies wrt: vary
10:44:48 <bhill2> ... don't want to cache three versions of a font because of access control variance
10:45:21 <bhill2> ... proxies and caches need to deal with that situation already
10:45:35 <bhill2> ... don't know how much it impacts real world
10:46:05 <bhill2> ... if current is broken, would have been for a long time, haven't heard screaming
10:46:22 <bhill2> ... would just leave it as-is until complaints grow
10:46:55 <bhill2> bhill2: then let's stabilize, stabilize test suite and try to go to REC
10:47:01 <bhill2> annevk: text i s all consistent
10:48:53 <bhill2> ... want want to prevent other specs from using a space separated list of origins representing a redirect stack in the origin header
10:49:12 <bhill2> dveditz: shouldn't have multiple values in Origin header for redirects
10:49:51 <bhill2> annevk: would prefer to obsolete optional behavior in Origin RFC
10:50:10 <bhill2> ... all API specs have to hook into fetch algo so in practice not a problem
10:51:45 <Zakim> - +1.781.369.aaaa
10:51:48 <bhill2> adjourned for 2 hours for lunch
10:52:19 <bhill2> next agenda topic is detailed test coverage review of CORS, identification of any at risk features or features for which we lack enough coverage to decide on at risk status
10:53:00 <puhley> puhley has left #webappsec
11:04:42 <sicking> sicking has joined #webappsec
11:32:56 <bradee-oh> bradee-oh has joined #webappsec
12:51:23 <tpacbot> tpacbot has joined #webappsec
12:54:12 <sicking> sicking has joined #webappsec
12:55:51 <npdoty> npdoty has joined #webappsec
13:00:16 <gopal> yes, they are supposed to be there at 14:00
13:03:08 <bradee-oh> bradee-oh has joined #webappsec
13:05:20 <Zakim> + +1.781.369.aabb
13:09:30 <ware> ware has joined #webappsec
13:11:53 <ware> Still waiting for everyone to get back from lunch.
13:13:07 <bhill2> bhill2 has joined #webappsec
13:13:16 <bhill2> zakim, who is here?
13:13:16 <Zakim> On the phone I see St_Clair_2, +1.781.369.aabb
13:13:17 <Zakim> On IRC I see bhill2, ware, bradee-oh, npdoty, sicking, tpacbot, gopal, timeless, RRSAgent, Zakim, trackbot, odinho, odinho_, caribou, tobie
13:13:37 <npdoty> Zakim, aabb is gopal
13:13:37 <Zakim> +gopal; got it
13:14:34 <npdoty> I'm Nick Doty, W3C, working on privacy across our standards
13:15:04 <dveditz> dveditz has joined #webappsec
13:16:39 <DanD> DanD has joined #webappsec
13:17:09 <dveditz_> dveditz_ has joined #webappsec
13:17:34 <gopal> http://w3c-test.org/webappsec/tests/testRunner/
13:18:30 <odinho_> q+
13:19:37 <dveditz> gopal: we still need a lot of acceptance tests
13:20:11 <dveditz> … sections 1,2,3 and 4 we don't need coverage
13:20:19 <gopal> 1. not required
13:20:20 <gopal> 2. not required
13:20:22 <gopal> 3. not required
13:20:23 <gopal> 4. not required
13:21:16 <dveditz> … the most important sections to cover are 5.1-5.9 (various response and request headers)
13:21:32 <gopal> .1  basic.htm, credentials-flag.htm, errors-async.htm, request.htm, simple-request.htm
13:21:34 <gopal> 5.2 credentials-flag.htm, request.htm
13:21:46 <dveditz> … several tests already go through some of the headers
13:21:57 <odinho_> Present+ Nick_Doty
13:22:07 <dveditz> … but we need consolidated set of pass/fail tests for each specific item in the spec
13:23:00 <gopal> 6.1.1 	5.1
13:23:02 <gopal> 6.1.2 	5.2
13:23:04 <gopal> 6.1.3 	5.2
13:23:05 <gopal> 6.1.4 	5.3
13:23:07 <dveditz> … section 6 is a mapping to headers in section 5.*
13:23:45 <odinho_> ScribeNick: dveditz
13:24:17 <dveditz> … tests for section 7 also have correspondence with tests for sections 5.*
13:24:42 <seo> seo has joined #webappsec
13:25:12 <odinho_> Scribe: Daniel Veditz
13:25:19 <tanvi> tanvi has joined #webappsec
13:25:23 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-webappsec-minutes.html odinho_
13:25:38 <odinho_> ack me
13:25:40 <dveditz> … we need to document the mapping and that eventual consolidated tests cover the specific section 5.* feature and also the mapped section 6 and 7 texts
13:26:41 <gioma1> gioma1 has joined #webappsec
13:26:50 <dveditz> … browsers cache responses which somewhat invalidate the tests
13:27:03 <dveditz> … need to aggressively bust caching for valid tests
13:27:24 <dveditz> the previous two lines were odinho_
13:28:09 <odinho_> s/… we need to/odinho_: we need to/
13:28:14 <tanvi1> tanvi1 has joined #webappsec
13:28:45 <dveditz> bhill2: thanks for the summary, sounds like we've made a lot of progress. Is this something we should work on today?
13:29:16 <dveditz> gopal: setting up the test environment is pretty easy, if you need help gopal can help with that
13:29:44 <dveditz> gopal: hard to tell what parts are at risk from the current tests
13:30:15 <dveditz> gopal: once we start putting it together [i.e. mapped to specific test sections] it will be clearer
13:30:58 <dveditz> gopal: some people from Mozilla pointed out test errors but also provided fixes which will increase success percentage
13:31:12 <dveditz> gopal:  need help going through the failing tests looking for errors
13:32:23 <dveditz> DanD: is there any way to set up the test environment without having to hit the w3c test environment?
13:33:01 <dveditz> odinho_: brad set it up a VM that runs standalone, and odinho_  just runs his own instance of apache
13:33:38 <gopal> to test locally: use VM image from Brad or set up /etc/hosts with w3c-org in your local environment
13:33:44 <bhill2> http://dl.dropbox.com/u/76057758/WebAppSecTestsuite.vdi.bz2
13:34:41 <bhill2> That is the latest VM image.  Sun VirtualBox image of an Ubuntu, all free software
13:34:50 <bhill2> user/pass is webappsec/webappsec
13:35:09 <bhill2> that link seems dead
13:35:39 <bhill2> https://dl.dropbox.com/u/76057758/webappsecVM.tar.bz2
13:36:03 <dveditz> bhill2: use the second one
13:36:11 <puhley> puhley has joined #webappsec
13:36:36 <puhley> puhley has left #webappsec
13:37:15 <dveditz> bhill2: I was talking to some of the organizers of the "test the web forward" group to see if they'd like to sign on to maintaining this environment
13:37:30 <dveditz> bhill2: (for more than just webappsec tests)
13:37:44 <puhley> puhley has joined #webappsec
13:38:15 <dveditz> gopal: brad, are all the recommended w3c ports enabled in that VM?
13:38:42 <gopal> port 80, 81
13:38:48 <dveditz> bhill2: I didn't realize that, that's one of the reasons it would be good to have a dedicated person to maintain this
13:39:04 <bhill2> action bhill2 to update port numbers on apache for test vm; 80-83
13:39:04 <trackbot> Created ACTION-83 - Update port numbers on apache for test vm; 80-83 [on Brad Hill - due 2012-11-08].
13:39:05 <dveditz> gopal: so if you see test failures you need to set up those ports
13:39:58 <gopal> W3C Web test server exposes the following domain names for testing purpose as of 2011-06-07:
13:39:59 <gopal> http://w3c-test.org/
13:40:01 <gopal> http://www.w3c-test.org/
13:40:03 <gopal> http://www1.w3c-test.org/
13:40:04 <gopal> http://www2.w3c-test.org/
13:40:06 <gopal> http://天気の良い日.w3c-test.org/
13:40:08 <gopal> http://élève.w3c-test.org/
13:40:16 <dveditz> bhill2: is there anything further to do today to identify tests that need updating?
13:40:51 <dveditz> gopal: we can take that offline and see if there are any other topics to discuss here
13:41:27 <dveditz> bhill2: I mentioned "Test the Web Forward", because testing is the main step to get from CR to Recommendation
13:42:20 <dveditz> bhill2: for Cors and CSP. Will be a challenge for the UI safety proposals since testing ui events like clicking will be trickier to set up
13:42:57 <dveditz> odinho_: met up in Paris, a lot of developers came. First day "how do you test the spec, how do ref tests work"
13:43:19 <dveditz> … had some lightning talks also (odinho_ gave an indexedDB talk, for example)
13:43:36 <dveditz> … different experts were there on different topics, sat down and wrote some tests.
13:43:43 <dveditz> … 404 tests written that day
13:44:18 <dveditz> … CSP is a little harder because of the netword requirements, HTML tests easier
13:44:42 <dveditz> … creating CSP tests would work well in a setting like that
13:45:10 <dveditz> … first was in San Franciso, next in Beijing, most recent in Paris, doubling the number of tests written
13:45:44 <dveditz> bhill2: need to create a harness for sending UI events, then can copy that into multiple tests
13:46:36 <bhill2> odinho: chrome, opera have webdriver, moz has marionette which will be web driver when it's finished
13:48:16 <dveditz> bhill2: Giorgio is working on a standalone version of ClearClick
13:48:40 <dveditz> bhill2: would be nice not to need 5 different versions of each test for each driver/browser
13:48:52 <dveditz> bhill2: what are next actions?
13:49:13 <dveditz> gopal: create list of acceptance tests, especially those related to section 5.* collected in one area
13:50:12 <dveditz> bhill2: want actions in the tracker so we know what's left and how we are progressing
13:50:17 <bhill2> action gopal to create acceptance tests for section 5
13:50:22 <trackbot> Created ACTION-84 - Create acceptance tests for section 5 [on Gopal Raghavan - due 2012-11-08].
13:50:24 <ekr> ekr has joined #webappsec
13:51:02 <bhill2> action gopal to create acceptance tests for section 6
13:51:02 <trackbot> Created ACTION-85 - Create acceptance tests for section 6 [on Gopal Raghavan - due 2012-11-08].
13:51:04 <dveditz> bhill2: wanted to create some actions here, assigned to gopal by default but encourage other people to take some of this on
13:51:09 <bhill2> action gopal to create acceptance tests for section 7
13:51:09 <trackbot> Created ACTION-86 - Create acceptance tests for section 7 [on Gopal Raghavan - due 2012-11-08].
13:51:30 <bhill2> action odinho to fix transient CORS test failures due to caching
13:51:30 <trackbot> Sorry, couldn't find odinho. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
13:51:43 <dveditz> gopal: someone from Mozilla pointed out errors, we need to reach out to see if they're ready to contribute that
13:51:56 <bhill2> action oomdal to fix transient CORS test failures due to caching behavior
13:51:56 <trackbot> Created ACTION-87 - Fix transient CORS test failures due to caching behavior [on Odin Hørthe Omdal - due 2012-11-08].
13:52:59 <bhill2> odinho: there is a meta help header that allows linking of test cases to the section they test
13:53:11 <bhill2> gopal: that's great, allows us to measure coverage without duplicating tests
13:53:25 <bhill2> odinho: have that set up on the next cases I will check in to the repository
13:53:52 <dveditz> bhill2: any other actions to talk about for this section of the agenda?
13:54:35 <dveditz> bhill2: to take an action for himself to see what the granularity of "at risk" is
13:54:52 <bhill2> bhill2: what is the granularity of "at risk"?
13:54:54 <dveditz> odinho_: as far as I've seen that much is up to the chair to decide
13:55:42 <dveditz> gopal: pre-flight section 3.1 (2.1?), referenced in section 6 and 7
13:56:23 <gopal> section 6.2, item 7
13:56:24 <dveditz> gopal: section 6.2 item 7
13:57:13 <dveditz> bhill2: that's referring to a resource that advertises as requiring credentials
13:57:21 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-webappsec-minutes.html odinho_
13:57:24 <dveditz> bhill2: it can't then turn around and grant to all callers
13:57:53 <odinho_> Present+ Ryan_Ware
13:58:22 <dveditz> bhill2: what's the UA behavior -- not specified
13:58:29 <dveditz> dveditz: do we need to fix that in the spec?
13:58:37 <dveditz> bhill2: I'm going to take an action to figure that out
13:58:54 <bhill2> action bhill2 to talk to annevk and clarify UA behavior on section 6.2 if resource asks for credentials and gives * to preflight
13:58:54 <trackbot> Created ACTION-88 - Talk to annevk and clarify UA behavior on section 6.2 if resource asks for credentials and gives * to preflight [on Brad Hill - due 2012-11-08].
13:59:01 <dveditz> gopal: section 6.2 item 10 need clarification
13:59:43 <dveditz> … similar issue-- what's the expected behavior
14:00:40 <dveditz> odinho_: section 6 is for the resource, section 7 is for the UA and it probably says there
14:00:45 <dveditz> bhill2: does it say?
14:01:05 <dveditz> odinho_: yeah, we filed it as a bug when we implemented it if it wasn't there
14:01:34 <dveditz> bhill2:  are we implementing test cases for the resource side of this spec? or only for user agents
14:02:01 <dveditz> odinho_: that can be outreach -- "we have a testsuite you can run against your server implementation"
14:02:36 <dveditz> bhill2: we don't necessarily need to cover the resource-specified behavior, it's outside our scope
14:02:40 <dveditz> <general agreement
14:02:41 <dveditz> >
14:03:18 <bhill2> http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html
14:03:27 <bhill2> next part of discussion will be on UISafety directives
14:03:29 <odinho_> s/>//
14:03:34 <dveditz> bhill2: scheduled for a break now… if you haven't looked at the UI safety directives now would be a good time to do so
14:03:36 <seo> seo has left #webappsec
14:03:39 <odinho_> s/<general agreement/<general agreement>/
14:03:44 <dveditz> bhill2: going to have a guest expert
14:04:15 <dveditz> bhill2: on accessibility, we don't want to deny users with accessibility requirements access to web content
14:04:23 <kevin> kevin has joined #webappsec
14:04:52 <dveditz> odinho_: when were we going to discuss the <style> issues with Jonas Sicking present?
14:05:09 <sicking> i'll be right over
14:05:12 <dveditz> tanvi: jonas isn't going to be here tomorrow, will try to find him on the break
14:06:17 <dveditz> RRSAgent: make minutes
14:06:17 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-webappsec-minutes.html dveditz
14:06:31 <odinho_> s/RRSAgent: make minutes//
14:07:31 <npdoty> the first [CSP] reference in the UI Safety Directives is incorrect, accidentally pointing to rfc2119
14:07:31 <bhill2> rrsagent, set logs public-visible
14:08:03 <ekr> ekr has joined #webappsec
14:08:27 <bhill2> we are sticking around to discuss CSP and CSS issues while Jonas Sicking is here
14:08:32 <bhill2> mailing list archives are at: http://lists.w3.org/Archives/Public/public-webappsec/
14:08:34 <odinho_> Present+ Eric_Rescolra
14:08:54 <bhill2> part of the relevant thread is at: http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0065.html
14:08:57 <tanvi> csp and inline styles - http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0049.html
14:08:59 <odinho_> s/Eric_Rescolra/Eric_Rescorla/
14:09:40 <tanvi> http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0060.html
14:11:19 <bhill2> jonas: right now, spec draws arbitrary line that blocks css from DOM attributes and DOM elements
14:11:39 <bhill2> ... sorry, CSS from text or attribute nodes is considered inline
14:11:56 <bhill2> ... but CSSOM methods like element.style.foo or element.style.csstext isn't blocked
14:12:01 <bhill2> ... even though they are feature equivalent
14:12:22 <bhill2> ... so line currently in the spec is obviously not correct
14:12:40 <bhill2> ... Adam might have some disagreement, but I think he generally agrees that we need to do something
14:12:50 <bhill2> ... my argument is that the threat doesn't come out of elements and attributes
14:13:02 <bhill2> ... but whether we are starting with a piece of text and turning it into something dangerous
14:13:29 <bhill2> ... concern is whether trusted code will take strings from untrusted locations and parse it into something dangerous
14:13:43 <bhill2> dveditz: long history of people doing dangerous evals, but style stuff more likely to be hard coded
14:13:53 <tanvi> ... into script or data or somewhere.
14:14:06 <bhill2> jonas: might be more likely that people will do bad things with eval, but doesn't mean they aren't also making css mistakes
14:14:27 <bhill2> jonas: if we think people aren't following dangerous practices, then we shouldn't block
14:14:57 <bhill2> dveditz: would be OK with that; argument for blocking them is that they may evolve to be more selector-like in the future
14:15:16 <bhill2> jonas: Adam has mentioned examples where css rules can mine data out of the DOM
14:15:26 <bhill2> dveditz: CSRF token is a better example
14:16:02 <bhill2> jonas: yes, but attack example requriese multiple loads, CSRF token may not be stable
14:16:08 <odinho_> scribe: bhill2
14:16:18 <bhill2> bhill2: not necessarily, may be stable across entire sesission
14:16:18 <odinho_> ScribeNick: bhill2
14:16:53 <bhill2> jonas: concern is that you can grab entire values out of page, but can't find a way today to send that out with current model
14:17:00 <bhill2> ... but CSS is very close to being able to do that
14:17:12 <tanvi> … in a version or two.  they just added calc.
14:17:24 <bhill2> ... calc, addr, eventually will likely have a way to concatenate strings
14:17:24 <odinho_> i/odinho_: when were we going to discuss the <style> issues with Jonas Sicking present?/Topic: CSP and inline styles
14:17:41 <bhill2> ... then you won't need a rule, can just set, e.g. element.style.background = untrusted data
14:17:45 <bhill2> ... could let you send something to a server
14:18:05 <bhill2> npdoty: not a problem unique to CSP, shouldn't we address that in CSS?
14:18:24 <bhill2> jonas: what CSP is trying to protect is when you have untrusted data that gets transformed by trusted content
14:18:41 <bhill2> npdoty: if that were an attack you could do in CSS in general, seems like that would be dangerous
14:18:55 <bhill2> jonas: only dangerous if linking to untrusted CSS
14:19:09 <bhill2> npdoty: or if you can include user-generated content, would be like reflected XSS
14:19:16 <odinho_> i/gopal: we still need a lot of acceptance tests/Topic: CORS test status
14:19:57 <bhill2> npdoty: CSP should have a narrower scope?
14:20:09 <bhill2> jonas: but we clearly know of cases where CSS can be dangerous
14:20:33 <bhill2> jonas: blocking of style attributes is due to concerns that CSS will in future grow capabilties that make this dangerous
14:20:52 <bhill2> dveditz: also concerns with phishing by adding a floating div to cover up parts of content
14:21:06 <bhill2> jonas: key question is what kind of attacks we are trying to prevent
14:21:15 <bhill2> ... only answer was from Adam on the CSRF token example
14:21:21 <bhill2> dveditz: yes, not clear to me
14:21:29 <bhill2> jonas: defamation not clearly a goal
14:21:48 <bhill2> dveditz: defamation has been mentioned in some places
14:21:50 <tanvi> is the goal of csp 1.0 to prevent csrf tokens from being revelaed.  data exfiltration?  just xss?
14:21:55 <bhill2> bhill2: just HTML can do that
14:21:56 <odinho_> i|http://fetch.spec.whatwg.org/|Topic: CORS and WHATWG fork of "Fetch", guest speaker annevk
14:22:15 <bhill2> dveditz: depends where in the page you can inject, may need to use CSS to move attack to right place
14:23:01 <bhill2> jonas: example where untrusted content injected into markup of the page that caused a start style attribute to happen, all of content got appended, turned into a giant url
14:23:19 <bhill2> ... caused a request to go to a different server with all the legit data following that injection
14:23:27 <bhill2> dveditz: this is already solved by browsers
14:23:47 <bhill2> jonas: not so, request isn't invalid CSS being returned, it is the outbound URL being used to fetch the CSS
14:23:57 <tanvi> jonas: adam's point was that the css we get back is verified an dmake sure its valid.  but at that point it is already too late.  sending a request to the server that contains private data.
14:24:14 <puhley> puhley has joined #webappsec
14:24:22 <bhill2> dveditz: example from crhis evans... yahoo subject stealing
14:25:09 <bhill2> jonas: attack was a valid piece of CSS with a valid external URL reference containing part of the original text of the page
14:26:01 <bhill2> http://scarybeastsecurity.blogspot.com.es/2009/12/generic-cross-browser-cross-domain.html
14:26:05 <tanvi> wrapping piece of original context with css that causes an off domain request.  this would be stopped by image source.  background image request.  but woudln't be stopped by style source
14:26:12 <bhill2> jonas: this attack would be stopped by img-src, but not by style-src
14:26:47 <bhill2> jonas: this is particularly bad, but also easy to stop attack
14:27:05 <bhill2> ... fact he got it inserted into the markup stream can't work even with setAttribute
14:27:17 <bhill2> ... because it isn't a markup stream anymore, so much harder to combine real data with attacker data
14:27:34 <bhill2> ... seems totally possible to have javascript that contains data from different sources and then sticks that into CSS
14:27:57 <tanvi> dveditz - attack involved loading the email as a style sheet.
14:28:27 <puhley> puhley has joined #webappsec
14:28:28 <tanvi> fix by checking the mime type.  since its wrong, dont even load the style sheet
14:28:38 <tanvi> jonas - what i'm concerned about seems like a different attack, but still concern there
14:28:48 <bhill2> jonas: agree with adam's point, need to draw the line somewhere
14:28:54 <bhill2> ... made a proposal on where to draw line
14:29:09 <bhill2> dveditz: didn't understand proposal - understood part about adding css-text
14:29:14 <bhill2> ... anything else?
14:29:28 <bhill2> jonas: that is half of it, treating css-text as equivalent to setAttribute is half of it
14:29:40 <bhill2> dveditz: yes, that's innerHTML for CSS
14:29:45 <tanvi> treating as css-text equivalent to set attribute is half of it.
14:30:06 <bhill2> jonas: might be different in firefox, but injecting style rule is equivalently dangerous
14:30:16 <bhill2> ... more formal way to describe proposal
14:30:40 <bhill2> ... anything that can cause an arbitrary string to be parsed into a style should be blocked, just as we do with script
14:30:53 <tanvi> dveditz - woudln't block style.bg becaus e not an arbritrary property.
14:30:55 <tanvi> jonas - yeah
14:31:20 <bhill2> jonas: in theory can have defamation attacks, but at some point need to say it's your own fault
14:31:43 <bhill2> ... other half of proposal is that I'm in general concerned with trying to block outgoing request using -src rules
14:31:54 <bhill2> ... part of reason is to not send requests with sensitive information
14:32:13 <bhill2> dveditz: if that was only reason we'd have to do it globally
14:32:24 <bhill2> dveditz: any type of leak is equivalent
14:32:43 <bhill2> dveditz: is more like rules for mixed-script inclusion
14:32:50 <bhill2> dveditz: scripts are more dangerous than images
14:33:13 <bhill2> dveditz: so distinction in types of sources has to do with relative risk when including, not risk of exfiltration by retrieval
14:33:31 <bhill2> jonas: have enumerated a set of things to set policies for
14:33:39 <bhill2> dveditz: no font-src anymore
14:33:46 <bhill2> ... may still be in Mozilla, not in spec
14:34:02 <bhill2> jonas: there are other things that can cause loads, set of things that can cause loads is constantly growing
14:34:14 <bhill2> jonas: either keep adding more things to CSP spec and to policy
14:34:23 <bhill2> ... or we create a better fallback mechanism than default-src
14:34:36 <bhill2> ... have we considered that gecko supports loading SVG filters from CSS
14:35:03 <bhill2> ... why stylesheet -> stylesheet loading is blocked by style-src, but SVG filter is only blocked by default-src
14:35:22 <bhill2> ... unless explicit policy like font-src, anything loaded from a stylesheet should be required to be under style-src
14:35:49 <bhill2> ... there will be more things added in the future like SVG filters, to falling back to style-src before default-src makes sense
14:35:56 <bhill2> dveditz: implementation-wise, might be difficult in gecko
14:36:07 <bhill2> dveditz: (earlier) font-src still actually in spec
14:36:30 <bhill2> jonas: in gecko, just treat SVG loads just like stylesheet loads as far as CSP goes
14:36:41 <bhill2> devditz: but other SVG loads that don't happen in that context
14:36:56 <bhill2> jonas: even when SVG links to other SVG, SVG is style-ish...
14:37:04 <bhill2> dveditz: to now we treat it more like an image
14:37:09 <bhill2> jonas: even for a filter
14:37:22 <bhill2> bhill2: can't you have script in SVG
14:37:34 <bhill2> dvedits: only run it for whole document SVG, not as an image or inline
14:37:50 <bhill2> joanas: we can solve it in Gecko, see what other implementers can do in their products
14:38:09 <bhill2> jonas: but maybe we should treat SVG from SVG as img-src, not style-src
14:38:39 <tanvi> bhill2 - how do we have forward compatibality as keep adding new types of resources.  maybe new tag type with remote resource added to html
14:38:49 <tanvi> bhill2 - thats an issue with csp
14:39:01 <bhill2> jonas: treat it under whatever resource type seems most appropriate
14:39:11 <bhill2> ... and only update CSP if it doesn't fit anywhere else
14:39:43 <bhill2> dveditz: should be a cascade of fallbacks - font -> style -> default
14:39:55 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-webappsec-minutes.html odinho_
14:39:56 <bhill2> jonas: may be same issue with shaders, but not proposing we add it right now
14:40:29 <tanvi> dveditz  - are images a subset of style?
14:40:29 <bhill2> dveditz: are images a subset of style? predate style by years
14:41:11 <tanvi> bhill2 - is this a complication that is useful to people when writign policies?  or is it a complication that makes sense to security people who have incredible knowledge of how the DOM and CSS interact?
14:41:18 <odinho_> s/scribe ekr/scribe: ekr/
14:41:54 <odinho_> i/annevk: Last-Event-ID, etc./scribe: bhill2
14:41:57 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-webappsec-minutes.html odinho_
14:42:05 <tanvi> jonas - it does make the spec harder.  the other way has to make you understand more of the platforms
14:42:31 <tanvi> currently nothing needing more than 2 layers of cascade.  currently just have default-sr
14:42:48 <tanvi> s/default-sr/default-sr
14:42:54 <tanvi> s/default-sr/default-src
14:43:38 <tanvi> if currently loading svg one way, and in the future decided its controlled by some other directive, then we might break things.
14:44:11 <tanvi> dveditz - tricky if we change way things are currently covered and how they are covered in the future.
14:45:33 <tanvi> jonas - acceptable if we have to keep updating the spec for more fine grained control.  its not a really acceptable if autthros will have to update all their policies everytime a new capability has been added
14:45:47 <tanvi> … makes it too hard to for them to write policy
14:47:28 <odinho_> i/for folks hoping to dial in, my apologies/scribe: ekr/
14:47:31 <tanvi> bhill2 - chosen so far that we have a best effort blacklist and we will always allow forward compatability.  other idea of its a whitelist.  that may not be wrong, but not the philosophy we've had so far.  shoudlnt' be changing it at this point when about to go to cr
14:48:49 <tanvi> bhill2 - we dont have svg-src, we are still treating it as img-sr.c.  if we didn't have media-src, do we it include it in default-src or img-src?
14:49:54 <bhill2> jonas: one concrete place to change this is to make font-src be a multi-fallback type through style-src, then to default-src
14:50:17 <bhill2> ... that would be concrete change to make, then up to implementers to choose for things like SVG filters
14:50:19 <odinho_> :w
14:50:24 <bhill2> ... css shaders, etc.
14:50:25 <odinho_> s/:w//
14:51:11 <tanvi> jonas to make proposal to text.  and bring it up on the next call when adam and mike west are also there.
14:51:28 <tanvi> s/proposal to text/proposal for text/
14:51:28 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-webappsec-minutes.html odinho_
15:03:09 <LeonieWatson> LeonieWatson has joined #webappsec
15:03:34 <bhill2> http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html
15:03:49 <bhill2> is the current latest editor's draft, set to go to FPWD on Tuesday
15:04:04 <Zakim> +??P16
15:04:13 <bradee-oh> bradee-oh has joined #webappsec
15:04:28 <gioma1> Zakim, ??P16 is gioma1
15:04:28 <Zakim> +gioma1; got it
15:04:36 <gioma1> hi
15:04:49 <gioma1> lots of noise here, but I can har you
15:04:49 <bhill2> can you  hear us?
15:05:04 <ekr> gioma, can you mute?
15:05:22 <gioma1> I'm muted, are you talking? I don't hear you anymore
15:05:29 <bhill2> better, thanky ou
15:09:08 <bhill2> http://www.w3.org/Security/wiki/Clickjacking_Threats
15:09:20 <odinho_> scribe: ekr
15:09:49 <odinho_> [ introductions, and going through the wiki-page just pasted ]
15:11:41 <ekr> dveditz: some of the "quick UI change" attacks may not work with accessibility modes
15:12:43 <npdoty> npdoty has joined #webappsec
15:12:49 <ekr> leoniewilson: the screenreader makes a copy of the key and then you interact with that.
15:13:07 <ekr> ... my assumption is that the screenreader would make the overlay manifest
15:13:17 <ekr> peleus: how do screenreaders deal with floating ads?
15:13:39 <ekr> leoniewilson: screenreaders generally don't care about anything that happens dynamically. they are almost exclusively concerned with the html
15:13:57 <ekr> peleus: would it read the ad back to you
15:14:18 <ekr> leoniewilson: would read the advert back to you because it doesn't care much about where it is occluded
15:14:47 <ekr> dveditz: this is the kind of technique used to obscure stuf
15:14:54 <ekr> leoniewilson: do you have any test cases?
15:15:00 <ekr> bhill2: not yet really
15:15:13 <JeffH> JeffH has joined #webappsec
15:15:26 <ekr> leoniewilson: a screen magnifier is probably about as susceptible, though they are often keyboard reliant
15:16:22 <ekr> bhill2: concern is that people with screenreaders will probably be ok, but that people who use other assistive devices (magnifiers, high contrast) etc. might be susceptible
15:16:31 <npdoty> npdoty has left #webappsec
15:17:19 <ekr> bhill: [describes the proposed mechanism]
15:21:47 <Zakim> + +1.866.317.aacc
15:23:18 <ekr> bhill: do we need to improve the second paragraph of section 9.
15:24:46 <ekr> bhill: objective is to not have these heuristics deny access to users of assistive technologies to
15:24:56 <ekr> bhill: don't want this to deny access when AT is cause of the trigger
15:25:08 <ekr> ... can we tell if an AT is in use?
15:26:31 <ekr> ... can the application get signals that an AT is in use from the OS?
15:26:46 <ekr> ... and compensate?
15:27:45 <ekr> leoniewilson: might work well for builtins but maybe a problem for third-party ATs
15:28:05 <JeffH> "AT" ?
15:28:18 <ekr> AT -> Assistive Technologies
15:28:35 <JeffH> zakim, aacc is JeffH
15:28:35 <Zakim> +JeffH; got it
15:28:40 <ekr> bhill2: [describes multi-window clickjacking]
15:29:54 <gioma1> gioma1: @ bhill: I don't believe we use OS screenshots agains multi-window CJ - as far as I can tell we use delays on rapid-fire clicks on different sites
15:30:15 <ekr> peleus: could you just have automatic disabling.
15:30:48 <ekr> bhill2: first goal is to avoid denying access in the case of an attack.
15:31:21 <ekr> ... second goal is to have these heuristics work with ATs
15:32:22 <Zakim> -gopal
15:33:01 <bhill2> public-webappsec@w3.org
15:33:23 <ekr> bhill2: this is an enabling technology. there are some susceptible sites/technologies but generally people avoid using vulnerable modalities.
15:34:12 <ekr> bhill2: timeline is over the next year or so.
15:36:01 <Zakim> +gopal
15:37:47 <ekr> bhill: let's walk through the spec
15:37:51 <odinho_> i/I'm muted, are you talking?/Topic: Detailed review of FPWD of UI Safety directives (+ a11y descussion)
15:38:39 <ekr> dveditz: i don't understand issue 3
15:39:27 <ekr> bhill2: you only set the unsafe attribute in report-only mode
15:41:57 <ekr> ... does this mean anything useful to an application author
15:42:50 <ekr> dveditz: should UAs supply this without sites opting in?
15:43:12 <ekr> bhill
15:43:12 <ekr> ;
15:43:25 <ekr> bhill2: if you didn't set that policy you probably aren't listening for unsafe=true
15:43:32 <ekr> dveditz: just block?
15:43:49 <ekr> bhill2: you don't think we should have a report-only mode?
15:43:53 <LeonieWatson> LeonieWatson has joined #webappsec
15:45:09 <bhill2> ISSUE if browsers apply this heuristic without an explicit opt-in policy, should we always block and not have the unsafe UIEvent property
15:45:22 <ekr> dveditz: if this is opt-in for the site, then this sort of reporting mode makes sense. if it's something that the site applies automatically, then you should just block
15:45:37 <ekr> s/site applies automatically/browser applies automatically/
15:46:40 <bhill2> ISSUE: if browsers apply this heuristic without an explicit opt-in policy, should we always block and not have the unsafe UIEvent property
15:46:41 <trackbot> Created ISSUE-20 - If browsers apply this heuristic without an explicit opt-in policy, should we always block and not have the unsafe UIEvent property ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/20/edit .
15:47:00 <bhill2> ISSUE: do assistive technologies send real events or synthetic events?
15:47:00 <trackbot> Created ISSUE-21 - Do assistive technologies send real events or synthetic events? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/21/edit .
15:47:04 <ekr> dveditz: we should have asked Leonie if ATs generate real or synthetic events
15:48:23 <ekr> dveditz: does this require per-browser adaptation for the ATs
15:48:44 <ekr> bhill2: unclear if they already have this problem b/c of kbd nav
15:49:41 <ekr> bhill2: two issues (a) if we do this automatically, should we just block (b) should we have an unsafe attribute mode.
15:50:13 <bhill2> ISSUE: are there cases of synthetic UIEvents where it would be useful to set the unsafe attribute even if the policy is block (so event is not delivered)
15:50:31 <trackbot> trackbot has joined #webappsec
15:50:51 <bhill2> ISSUE: are there cases of synthetic UIEvents where it would be useful to set the unsafe attribute even if the policy is block so event is not delivered
15:50:51 <trackbot> Created ISSUE-23 - Are there cases of synthetic UIEvents where it would be useful to set the unsafe attribute even if the policy is block so event is not delivered ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/23/edit .
15:50:59 <ekr> action: ()()()(
15:50:59 <trackbot> Sorry, bad ACTION syntax
15:51:25 <ekr> ISSUE: ();
15:51:25 <trackbot> Created ISSUE-24 - (); ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/24/edit .
15:52:29 <ekr> bhill: frame options. I believe it belongs in this WG
15:52:38 <ekr> ... not in IETF
15:53:36 <JeffH> couldn't hear dveditz
15:54:39 <ekr> dveditz: complaints about frame options being part of CSP is that it was a policy of how to treat that content that you are loading rather than one describing how to render other parts included in that resource
15:54:50 <ekr> ... but now we also have sandbox which is the same type of directive
15:55:00 <ekr> ... so frame options does not seem quite the oddball
15:55:08 <ekr> jeffh: does tha tmean the concern is moderated
15:55:37 <ekr> dveditz: we have now staked out that CSP is not just policy of rendering of document but can also affect rendering of document that tries to include it
15:55:56 <ekr> ... sandbox and frame options are aimed to other documents that try to include that content
15:56:02 <bhill2> ISSUE: do frame-options directives (or other UISafety directives) make sense in a meta tag context?
15:56:02 <trackbot> Created ISSUE-25 - Do frame-options directives (or other UISafety directives) make sense in a meta tag context? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/25/edit .
15:56:02 <ekr> ... but neither one makes sense in a meta tag
15:56:13 <bhill2> ISSUE: does the sandbox directive make sense in a meta tag context?
15:56:13 <trackbot> Created ISSUE-26 - Does the sandbox directive make sense in a meta tag context? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/26/edit .
15:56:45 <ekr> jeffh: is it worthwhile to differentiate on that basis
15:59:40 <ekr> bhill: I objected to from-origin (1) violates priority of constituencies b/c it favors resource owner over that of user (2) wrong location to make the security decision b/c the client will turn it off
16:00:43 <ekr> bhill: point of x-frame-options is that it is operating in user's interest
16:01:51 <ekr> bhill: what happened to from-origin
16:01:59 <ekr> dveditz: I don't think anyone was interested.
16:02:02 <JeffH> JeffH has joined #webappsec
16:02:37 <ekr> dveditz: I feel a little like we should help people who have resources that they don't want leached
16:03:20 <ekr> bhill: I'm sympathetic to that, but I think if you create a mechanism that is visibly making the user less happy, we create an incentive that the users have an interest in turning off.
16:03:58 <ekr> dveditz: a little worried about users turning off frame-options
16:04:47 <ekr> tanvi: we do frame-ancestors
16:05:42 <ekr> dveditz: from-origin isn't really a security feature
16:05:47 <ekr> ... except perhaps for jsonp
16:08:05 <ekr> bhill2: if we want to start using a totally different mechanism it will create unhappiness at websec
16:08:34 <ekr> ... if we want to do something totally different, IETF might spec frame options.
16:09:21 <ekr> ... this looks and behaves like frame options.
16:09:32 <ekr> ... but default behaves more like frame ancestors
16:11:09 <ekr> bhill2: x-frame-options compatible version is top-only
16:11:48 <bhill2> action: bhill2 rewrite abnf production of frame-options to have deny alternating with top-only and ancestor versions
16:11:48 <trackbot> Created ACTION-89 - Rewrite abnf production of frame-options to have deny alternating with top-only and ancestor versions [on Brad Hill - due 2012-11-08].
16:12:11 <ekr> dveditz: should frame options apply to pluginc ontent
16:13:41 <ekr> dveditz: was IETF OK with us taking frame options
16:14:40 <ekr> jeffh: I think we did close on this with IETF. We should talk to Tobias in Atlanta
16:15:45 <ekr> dveditz: why not allow multiple hosts?
16:15:55 <ekr> bhill2: IETF felt very strongly about it.
16:18:03 <bhill2> http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
16:18:05 <ekr> jeffh: original blog post proposed that server dynamically generate the header
16:18:12 <bhill2> think this is the blog post JeffH is referring to
16:19:16 <JeffH> what is bhill reading from?"
16:19:22 <JeffH> o
16:19:25 <JeffH> oh, ok
16:19:48 <JeffH> there's more than one x-frame-opt blog post, pls put uri in here
16:20:34 <bhill2> ACTION: bhill2 to sync up with David Ross and Eric Lawrence on XFO justification for ALLOW-FROM single origin restriction
16:20:34 <trackbot> Created ACTION-90 - Sync up with David Ross and Eric Lawrence on XFO justification for ALLOW-FROM single origin restriction [on Brad Hill - due 2012-11-08].
16:21:57 <bhill2> dveditz: is there a reason to do this as a seperate spec vs. as part of CSP 1.1?
16:23:45 <bhill2> bhill2: two reasons - one, mechanism is independent of CSP 1.1 details, could be as an add-on to 1.0 without doing 1.1 stuff
16:24:00 <bhill2> ... second reason has to do with clarity of obsolesence mechanisms for X-Frame-Options
16:24:17 <bhill2> ... UAs should ignore XFO if it sees a CSP header with any of the directives of the UISafety spec
16:24:33 <ekr> jeffh: who is proposing we do XFO as a separate spec?
16:24:46 <ekr> bhill2: why don't we do the entire UI safety spec as extra directives in CSP 1.
16:24:47 <ekr> 1
16:25:06 <ekr> (that was Dan's proposal)
16:25:23 <ekr> bhill's response is (1) and (2) above.
16:27:01 <ekr> ekr: is this baked enough to go into CSP 1.1
16:27:20 <ekr> bhill: also, it has a confusing compliance story since you need to do the whole spec whereas CSP is generally a la carte
16:27:29 <ekr> ... this isn't CSP, it
16:27:41 <ekr> 's a different spec which uses CSP as a delivery mechanism
16:28:47 <ekr> ... security considerations are really different
16:29:39 <ekr> dveditz: does frame-options apply to redirected resources?
16:29:45 <ekr> bhill2: not specified
16:30:00 <ekr> dveditz: content loading stuff on CSP checks on redirects as well
16:31:49 <ekr> bhill2: there was a bunch of refactoring of the input protection directives.
16:32:51 <ekr> ... I think Giorgio thought it was clearer to have separate directives in terms of readability
16:33:25 <ekr> bhill2: last edit we had one input direction directive and then a lot of hints
16:34:58 <gioma1> also, CSS selectors parsing and multiple hints in one directive would clash
16:36:10 <bhill2> ISSUE: implementation concern on how to enforce display-time : should we provide more advice on how to do this efficiently?
16:36:10 <trackbot> Created ISSUE-27 - Implementation concern on how to enforce display-time : should we provide more advice on how to do this efficiently? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/27/edit .
16:36:22 <ekr> dveditz: what does being tolerant mean?
16:36:44 <dveditz> is it a percentage of pixels difference?
16:36:49 <gioma1> tolerant means percent of checked pixels which may not match
16:37:04 <ekr> peleus: from a baseline perspective there are going to be some pixel differences (E.g., color correction)
16:37:11 <gioma1> personally, I'm against to keep it in an opt-in context, but it may be useful to lower the false positive rate in a default mode
16:37:26 <bhill2> puhley: might need sub-pixel tolerances to prevent e.g. color-correction from causing total failure
16:37:53 <bhill2> ... if using OS-level screenshots
16:38:32 <dveditz> gioma1: we discussed that a little, that to be generally useful browsers should just implement it
16:38:58 <gioma1> does using OS-level screenshots provide any advantage over browser-based ones?
16:39:08 <ekr> bhill: do you have an example we could do a test case for.
16:39:48 <bhill2> giorgio, I know that David's InContext work used OS-level screenshots to prevent the double-click attacks where click one closes an overlaid window and click two is delivered to the window beneath
16:40:17 <bhill2> sounds like you think that protection can be afforded using display-time without relying on OS-level facilities?
16:40:18 <gioma1> bhill: in that case you just need ensure that the surface you're clicking has not been repainted too recently
16:40:31 <gioma1> bhill2, yes indeed
16:40:43 <ekr> ekr: what value would you use?
16:40:45 <gioma1> (after a click on a different domain)
16:40:49 <bhill2> ISSUE: what specific attacks are prevented by OS screenshots, should this be recommended against generally?
16:40:50 <trackbot> Created ISSUE-28 - What specific attacks are prevented by OS screenshots, should this be recommended against generally? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/28/edit .
16:40:58 <gioma1> I currently use 600ms
16:41:29 <gioma1> ekr, I defaulted to 800ms in the spec because it's opt-in
16:42:18 <ekr> peleus: people probably start with 0, break everything, and then will whipsaw back to 99. maybe we could have a max value of 20 or 25 or something.
16:42:31 <bhill2> so many things might be simpler if we could recommend implementing entirely in the browser, and never going to the OS
16:42:43 <bhill2> no issues with color correction, assistive technologies at OS level, etc.
16:43:42 <ekr> odin: I just tested red shift on Linux and it only changes output gamma
16:44:11 <ekr> bhill2: input-protection-clip
16:45:53 <ekr> ... centered on the mouse event. keyboard event is centered on text entry
16:46:01 <bhill2> giorgio, any reason to use before/after/above/below vs. more CSS-standard top/bottom/left/right?
16:46:15 <bhill2> dveditz: before/after creates confusing with text directionality
16:46:25 <gioma1> because top, bottom etc are traditionally relative to the viewport
16:46:32 <gioma1> (or the parent element)
16:47:14 <bhill2> puhley: could use positiveX, negativeX, etc..
16:47:36 <bhill2> dvedits: could we just specify width and height, instead of an offset rectangle?
16:47:50 <bhill2> s/dvedits/dveditz/
16:47:58 <bhill2> dveditz: why are there four values?
16:47:59 <gioma1> dveditz: because we may want not to have it centered always
16:48:18 <ekr> dveditz: so you are sayingi f the important thing on the page is lopsided compared to where you click...
16:48:25 <gioma1> for instance, if I click on a form button, I'm probably biased toward left and top (in a ltr page, that is)
16:48:26 <bhill2> so if I have a pay button with a dollar value printed to the right
16:48:41 <bhill2> want to have that protected from being obscured, but may not care about context to the left
16:50:22 <ekr> peleus: concerned about doing exact math on text that wraps. need to have a recommendation for this.
16:50:58 <ekr> dveditz: do you always have to specify all 4 sizes
16:51:02 <gioma1> peleus, if that's a concern, you may use input-selector to match the container
16:51:15 <ekr> bhill2: they are able to be specified independently. defaults are 250...
16:53:03 <Zakim> -gopal
16:53:40 <ekr> peleus: if the page is longer than the visible area of the screen, does the screenshot account for that
16:53:45 <bhill2> gioma, how does screenshot account for clipping from a scrollbar?
16:54:04 <bhill2> when "the whole document's body" is used for comparison according to the algorithm?
16:54:18 <gioma1> bhill2, it doesn't.
16:54:27 <gioma1> bhill2: "whole body" is the like button case
16:54:41 <gioma1> bhill2, Facebook Like, that is.
16:54:47 <bhill2> aha, ok
16:55:06 <gioma1> bhill2, so if you've got a complex page, you'd better use input-protection-selectors or input-protection-clip
16:55:28 <bhill2> should that be default if clip isn't specified then, or should the 250,250,50,50 values be a more sane default?
16:55:29 <gioma1> (the latter even with no values, using the default form-biased rectangle)
16:56:52 <gioma1> bhill2, I think there's where I and David disagreed, and we went with his idea of the whole body as the default IRC
16:57:08 <dveditz> gioma1:  I'm slightly confused that input-protection-clip defaults to 250,250,50,50 but input-protection-selectors defaults to 0,0,0,0
16:57:26 <bhill2> sounds like we should raise an issue on this for broader discussion when David can also join
16:57:48 <gioma1> dveditz, ooops, selectors should be a CSS string? did I miswrite a default value somewhere?
16:57:59 <bhill2> ISSUE: what are sane defaults for clipping with clipping or selectors?
16:58:00 <trackbot> Created ISSUE-29 - What are sane defaults for clipping with clipping or selectors? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/29/edit .
16:58:02 <dveditz> no, I'm shorthanding
16:58:22 <dveditz> "may be omitted, taking 0 (zero) as their default values."
16:58:34 <dveditz> vs "The default value for this directive is before=250 above=250 after=50 below=50. "
16:59:23 <gioma1> dveditz: ah ok, because in my view you usually want to select the container, rather than the protected element, when using selectors
17:00:33 <gioma1> dveditz, in other words, if you can't control the DOM and shoot in the dark, you use clip, otherwise you can use CSS selectors and have the padding from the DOM itself
17:00:43 <jeffh> jeffh has joined #webappsec
17:00:54 <jeffh> meeting over?
17:02:09 <dveditz> gioma1: oh! I missed that the calculations were different
17:02:11 <dveditz> also
17:02:12 <bhill2> rrsagent, draft minutes
17:02:12 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-webappsec-minutes.html bhill2
17:02:19 <bhill2> zakim, who is here?
17:02:19 <Zakim> On the phone I see St_Clair_2, gioma1, JeffH
17:02:20 <Zakim> On IRC I see jeffh, trackbot, puhley, ekr, tanvi, gioma1, dveditz, bhill2, tpacbot, timeless, RRSAgent, Zakim, odinho, odinho_, caribou, tobie
17:02:25 <bhill2> zakim, list attendees
17:02:25 <Zakim> As of this point the attendees have been St_Clair_2, +1.781.369.aaaa, +1.781.369.aabb, gopal, gioma1, +1.866.317.aacc, JeffH
17:02:27 <dveditz> just assumed they were both the event point
17:02:45 <gioma1> dveditz, no they aren't, that's the point :)
17:02:56 <Zakim> -JeffH
17:03:42 <jeffh> sorry I missed the question about XFO directed to me by ekr in the chat -- followup via email?
17:03:44 <Zakim> -St_Clair_2
17:03:45 <dveditz> got it. thought the point was to use both and have a default area around events, and then specify a (presumably bigger) area around particularly important elements
17:04:41 <gioma1> dveditz, in facts, you can use both.
17:05:05 <gioma1> dveditz, the text says selectors override clip when the clicked element or an ancestor matches the CSS
17:05:38 <gioma1> dveditz, otherwise clip applies if specified (so you can both shoot in the dark and make some DOM-based fine tuning)
17:06:35 <dveditz> gioma1: so the default input-protection-clip size is 500px across? seems pretty big -- especially for a mobile device!
17:06:55 <dveditz> what happens if the specified clip area is bigger than the display area, or runs off the edge of a page?
17:07:06 <gioma1> dveditz: it's 300x300 as far as I can tell
17:07:21 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-webappsec-minutes.html odinho_
17:08:00 <bhill2> bhill2 has left #webappsec
17:08:06 <gioma1> dveditz: what ClearClick actually does is sliding the minsize rectangle inside the viewport if possible, otherwise trigger
17:08:17 <bhill2> bhill2 has joined #webappsec
17:08:39 <gioma1> dveditz: in an opt-in context I'd be tempted to be stricter, since the author is specifying his preferred rectangle
17:09:38 <bhill2> gioma1, I think we are wrapping up here
17:09:49 <bhill2> thanks for joining on a holiday, and best of luck tomorrow
17:10:03 <gioma1> bhill2: sorry, I'm leaving. Thank you, I hope it's not too painful :) Bye
17:10:17 <bhill2> bhill2 has left #webappsec
17:10:26 <gioma1> gioma1 has left #webappsec
17:11:16 <dveditz> RRSAgent, make minutes
17:11:16 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-webappsec-minutes.html dveditz
17:57:57 <trackbot> trackbot has joined #webappsec
17:58:57 <trackbot> trackbot has joined #webappsec
17:59:16 <trackbot> trackbot has joined #webappsec
18:05:00 <Zakim> disconnecting the lone participant, gioma1, in SEC_WASWG(TPACSES)6:00AM
18:05:03 <Zakim> SEC_WASWG(TPACSES)6:00AM has ended
18:05:03 <Zakim> Attendees were St_Clair_2, +1.781.369.aaaa, +1.781.369.aabb, gopal, gioma1, +1.866.317.aacc, JeffH
19:25:27 <gopal> gopal has joined #webappsec
20:35:22 <Zakim> Zakim has left #webappsec
22:07:04 <gopal> gopal has joined #webappsec
22:08:28 <dveditz> dveditz has joined #webappsec
23:23:03 <gopal> gopal has joined #webappsec
23:49:07 <gopal> gopal has joined #webappsec