IRC log of webappsec on 2012-11-01
Timestamps are in UTC.
- 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|-> 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