07:35:52 RRSAgent has joined #webappsec 07:35:52 logging to http://www.w3.org/2016/09/22-webappsec-irc 07:40:53 Gloria has joined #webappsec 07:47:18 bhill2 has joined #webappsec 07:48:18 jcj_moz has joined #webappsec 07:48:34 JeffH has joined #webappsec 07:48:51 weinig has joined #webappsec 07:50:05 present+ 07:58:19 wonsuk has joined #webappsec 08:00:20 francois has joined #webappsec 08:00:57 Crystal_ has joined #webappsec 08:02:39 bhill2 has joined #webappsec 08:04:02 bhill2 has changed the topic to: https://docs.google.com/document/d/1yAsZiacMJ55JUPWC6kZAfBzzW1HNc0H7noPtEzcdxqI/edit# 08:04:03 present+ 08:04:10 present+ dveditz 08:04:58 present+ francois 08:05:18 jcj_moz has joined #webappsec 08:05:39 present+ 08:06:04 Zakim has joined #webappsec 08:06:23 Axel has joined #webappsec 08:06:23 rrsagent, start logging 08:06:23 I'm logging. I don't understand 'start logging', bhill2. Try /msg RRSAgent help 08:06:40 Meeting: WebAppSec TPAC 2016 F2F Day 1 08:06:46 Chairs: bhill2, dveditz 08:06:54 Agenda: https://docs.google.com/document/d/1yAsZiacMJ55JUPWC6kZAfBzzW1HNc0H7noPtEzcdxqI/edit# 08:07:11 yoav has joined #webappsec 08:07:17 Remote participation available at: https://talky.io/webappsec 08:07:26 present+ francois 08:07:32 Please ask here to have comments voiced to the room 08:09:19 mikepie has joined #webappsec 08:09:21 ckerschb__ has joined #webappsec 08:09:26 tarawhalen has joined #webappsec 08:09:29 bhill: Introductions! 08:09:30 jungkees has joined #webappsec 08:09:31 rbarnes has joined #webappsec 08:09:43 ... We can use talky.io for some remote folks. Will set that up when we get there. 08:09:50 ... [Introduces self] 08:09:59 [Introductions] 08:10:00 Present+ Jungkee_Song 08:11:08 present+ bhill2 08:11:32 [awkward walking around the table to get the mic back] 08:11:47 ... Agenda at https://docs.google.com/document/d/1yAsZiacMJ55JUPWC6kZAfBzzW1HNc0H7noPtEzcdxqI/edit?usp=sharing 08:12:34 ... [Walking through agenda] 08:14:06 ... Any additional agenda items? 08:14:16 [crickets] 08:14:23 present+ tarawhalen 08:15:00 present+ teddink 08:15:24 scribenick: bhill2 08:15:28 present+ jochen__ 08:15:30 mkwst: have various specs close to Rec 08:15:41 ... CSP2 is one, been CR for a long time, trying to move to PR 08:15:48 present+ JeffH 08:16:03 mkwst: ... how is the PR request going? 08:16:11 ArturJanc has joined #webappsec 08:16:12 present+ jcj_moz 08:16:35 TOPIC: Moving "finished" specs forward. 08:16:47 mkwst: CSP2 exists. Transition request from CR to PR sent. 08:16:54 ... Some concerns from director about test suite. 08:17:06 ... Brad's done heroic work to get the test suite into better shape. 08:17:13 ... Some TODOs causing concern. 08:17:20 [Once the tests are complete, I believe Director will be ready to approve] 08:17:40 [and yes, thanks Brad for pushing the tests so far] 08:18:40 ted: we may have some tests that we have or will soon push to WPT 08:20:24 mkwst: don't think there is any value in editorial nits at this time, just patent protection from getting to REC 08:20:33 ... let's focus on making sure that CSP3 is right, not going back in time to 2012 08:21:01 mkwst: Mixed Content just went back to CR 08:21:06 ... think we can move to PR 08:22:00 bhill2: Agree, we can go ahead and move to PR. 08:22:32 ... solid implementations of everything in it, block-all-mixed-content was last thing and now implemented in Firefox 08:23:12 mkwst: upgrade insecure requests has been CR for ~1yr 08:23:20 ... nothing left in this doc, moving to PR seems reasonable 08:24:18 mkwst: next is Secure Contexts, just went to CR 08:24:23 ... chrome is missing some pieces 08:24:34 [when drafting Transition Requests, please make reference to the Chair's declaration of consensus, not just the Call for Consensus, thanks, from the team] 08:24:34 ... good to work on a shared test suite to demonstrate interoperability 08:24:46 ... I think we are a little bit far away from a PR at this point in terms of interop 08:24:52 ... move to PR hopefully early next year 08:25:05 s/, thanks/. Thanks/ 08:25:05 bhill2: Are there features AT RISK? 08:25:12 mkwst: a few, added late in the process 08:25:25 ... mozilla wanted some sandbox behavior 08:25:41 ... changed localhost behavior, domainame 'localhost' is not a secure context due to DNS issues that popped up 08:25:54 ... there are some ongoing discussions on that, maybe browsers should bypass resolution for this name 08:26:17 ... even though that is not what system resolvers would do 08:26:48 ???: we use localhost a lot for service workers to do testing 08:27:05 mkwst: we expect localhost to resolve to loopback but it actually goes to the network in various cases b/c system level resolver 08:27:19 ... that ambiguity doesn't consider localhost a secure context, but 127.0.0.1 is a secure context 08:27:29 ... and browsers should provide a mechanism to declare that an origin is secure for testing 08:29:04 mkwst: further discussion here: https://github.com/w3c/webappsec-secure-contexts/issues/43 08:29:06 ... Allow "localhost" as long as it actually resolves to a localhost address #43 08:29:25 dankaminsky: I think that localhost should bypass resolver, it surprises less people 08:30:02 kaorumaeda has joined #webappsec 08:30:20 dveditz: doesn't seem totally terrible 08:31:11 mkwst: from my perspective this is about how we do DNS resolution, not an issue for secure contexts 08:31:34 ... totally happy with secure contexts spec saying this is a secure context if that is true, but if there is ambiguity 08:31:42 ... that is strange, surprising and bad and am less happy doing that 08:31:53 ... don't know who the right people are to talk to about changing the underlying assumptions 08:32:03 ... this is surprising for developers and would be good to change 08:32:21 mkwst: as written I think the spec is technically correct 08:32:33 ... would be nice to make it more developer friendly, but it is accurate as-is 08:32:47 ... can drop that if we figure out how to make it work during CR, hence marked at-risk 08:34:04 ... concern is that going to a coffeeshop with crazy DNS would expose highly permissioned configuration to not actually localhost 08:34:52 ... CR period is a time for implementation, so hope browsers will implement or tell us what is bad to implement 08:37:17 ... my goal is PR first half of next year 08:38:34 freddyb has joined #webappsec 08:38:55 ???: PR being opened to HTML to disown opener when a secure context is created from insecure one 08:40:12 mkwst: CSP2, MIX ready for PR, Upgrade Insecure needs a test suite, and Secure Contexts should be ready some time next year 08:40:18 ... any comments or feedback on that? 08:40:57 rbarnes: Priming! 08:41:00 rbarnes has joined #webappsec 08:41:08 ... https://mikewest.github.io/hsts-priming/ 08:41:15 ... Implementation is in final review, should be landing soon. 08:41:19 ... Two prefs to Firefox: 08:41:23 TOPIC: HSTS Priming 08:41:36 ... 1. When the browser encounters something it would block as mixed content, it sends a priming request to check for HSTS header. 08:41:51 ... Caches the result, positive or negative, for next time. 08:42:00 ... Won't keep priming against the resource. 08:42:09 ... 2. Flips MIX and HSTS. 08:42:19 ... HSTS takes effect before checking whether a resource is mixed content. 08:42:34 ... This allows HSTS to upgrade the request, ensuring that it won't be treated as mixed content. 08:43:08 ... Plan right now is to release the priming request bits first. Should have zero compat impact. 08:43:26 ... The MIX/HSTS flip will ride out to Beta, won't ship until more experience and implementation from other browsers. 08:43:31 ... to avoid compat risk. 08:43:56 rbarnes has joined #webappsec 08:44:21 https://bugzilla.mozilla.org/show_bug.cgi?id=1246540 08:44:43 mkwst: there was some issue about revealing information to a divergent host 08:44:58 ... have now decided that I am not concerned about that, http/https should be considered the same, forbes aside 08:45:50 rbarnes: we have a bunch of telemetry so will be able to give data about how much difference this makes to the web 08:46:06 ... so for a chair's POV we should be accelerating this spec 08:47:14 bhill2: are there errata necessary to HSTS re: switching ordering of MIX / HSTS checks? 08:47:28 mkwst: that's in Fetch, not in HSTS? 08:47:35 jeffh: not sure 08:47:55 ... would write up changes the way cookie changes have been done and send to websec@ietf.org mailing list 08:48:04 ... if we think a 6797bis is appropriate 08:48:14 mkwst: I don't think it is explicit enough that changes are needed 08:48:18 ... if you look at fetch 08:48:22 https://fetch.spec.whatwg.org/#main-fetch 08:48:30 jcj_moz has joined #webappsec 08:50:25 rbarnes: for priming, we are doing a head request to the resource 08:50:50 ... spec says something different 08:52:25 mkwst: we were trying to avoid revealing information 08:52:40 bhill2: also some sites may not send HSTS header for all resources, only well-known entry points 08:53:08 mkwst: we could add telemetry, flip between actual resource and / 08:53:30 looks like the patch sends the request to the resource itself, vs. the origin. so slight mismatch with the spec 08:58:20 adjourned until 10:30 08:58:35 ??? is junkees 08:59:01 s/???/junkees/g 09:11:15 weinig has joined #webappsec 09:19:54 Gloria has joined #webappsec 09:21:34 kaorumaeda has joined #webappsec 09:25:51 JeffH has joined #webappsec 09:28:23 yoav has joined #webappsec 09:31:29 rbarnes has joined #webappsec 09:32:24 Tomoyuki has joined #webappsec 09:32:58 resumed 09:33:05 TOPIC: Clear Site Data 09:33:13 Tomoyuki has left #webappsec 09:33:19 tarawhalen has joined #webappsec 09:33:19 weiler has joined #webappsec 09:33:31 mkwst: gives a website ability to remove all data it created on a user's machine 09:33:49 ... e.g. logout, want to make sure everything is deleted, G+ wants this so locally stored images get wiped 09:33:57 ... have to iterate through localstorage, cookies, cache today 09:34:03 ... would like a more complete mechanism 09:34:43 ... chrome has an incomplete implementation behind a flag that only works for navigational, not subresource requests 09:34:51 ... enthusiastic about the future 09:35:07 ... gives us all the infrastructure to do a "forget this site" feature similar to what Firefox has 09:35:17 ... syntax is fairly terrible; header sent in response 09:35:24 ... JSON object with list of types 09:35:34 ... turn into bare words 09:35:42 ... open question what kind of syntax we want 09:36:08 ... flip the flag and play around in Chrome 53 09:36:22 crystal_ has joined #webappsec 09:36:43 where is conversation w/HTTP WG re: JSON in HTTP headers 09:36:52 timbl has joined #webappsec 09:37:02 mkwst: they are reluctant to do so, deficiencies with JSON, inconsistencies in parsers for things like floats 09:37:15 ... my perspective is that its a good thing for developers to create a readable header with some structure 09:37:22 ... but there are challenges to using it in practice 09:37:29 ... http wg considering a few things 09:37:37 ... 1) reinvent the wheel with a new format 09:37:52 2) go with a "web safe" subset of JSON 09:38:10 mkwst: ... don't use floats, use ASCII, not Unicode strings 09:38:24 ... I'm torn. A number of headers we'd like to define in forward compatible ways 09:38:33 ... don't want to wait for this, will take some time 09:38:57 ... want to make something compatible which will be regarded as not bad in a few years 09:39:09 ... for this spec we can avoid the problem by simplifying 09:39:26 ... but unquoted strings would require a new syntax if we go with JSON in the future 09:39:27 yoav has joined #webappsec 09:39:44 ... but quoted, comma-separated strings are already a JSON list 09:40:01 ... some folks seem to disagree, would love feedback on general issue 09:40:48 ... referrer policy is without quotes, question whether to add quotes in spec 09:41:14 ... referrer policy doesn't have a tree, just a value; need to define what happens when multiple values present, e.g. comma-coalescing multiple headers 09:41:32 ... brian smith wanted more power in referrer policy header in the future 09:41:40 ... we need more structure to get more power 09:42:18 ... most today do like CSP, keyword: value; keyword2: value2 09:42:28 ... but we can do better and not have unique snowflake parsers for each header 09:42:52 ... being forward compatible with JSON is reasonable, but downside is if we don't do that, we have unneeded quotes 09:43:01 ... don't see that as terrible, and would like to advocate for quotes 09:43:20 jeffh: trying to be forward compatible makes good sense 09:43:56 mkwst: do you or richard have opinions: where is issue going? 09:44:01 rbarnes: 09:44:29 i do not have a good read on the HTTP WG with regard to this issue 09:45:23 mkwst: some open questions, specifically around cookies w/different origin model 09:45:26 wonsuk has joined #webappsec 09:45:29 ... chrome's current impl is fairly draconian 09:45:41 ... when origin asks for cookies to be cleared, clears eTLD+1 not just origin 09:45:57 ... would be unclear what state an application would be in if we only deleted some of its cookies 09:46:21 dveditz: so would clearing cookies for maps.google.com also clear for foo.google.com? 09:46:36 mkwst: yes, would clear everything for google.com and ancestors 09:46:42 timbl: for github.com? 09:46:49 s/com/io 09:47:03 mkwst; different there because github.io is a public suffix 09:47:10 s/junkees/jungkees/g 09:48:13 mkwst: though draconian, was at least a reasonable thing to deal with, incomplete clearing not so clear what an application should do 09:48:48 dveditz: kind of conflicts with leave secure cookies alone spec, in that you try to preserve secure cookies and blow all cookies around 09:48:56 mkwst: clear site data is locked to secure contexts only 09:49:40 timbl: is it a long term goal of the group that github.io should not need to exist vs. protecting on a directory basis 09:49:45 mkwst: not really 09:49:48 bhill2: we have suborigins 09:50:02 mkwst: not the same, because suborigins are resource specific, and cookies 09:50:15 ... Public Suffix List is one way to deal with this, but going to have problems soon 09:50:26 ... afraid.org wanted to add 85k entries to the PSL recently 09:50:38 ... all are similar to github.io in semantics 09:50:52 ... but no way to scale support the way it is implemented 09:51:55 timbl: does public suffix have an API? 09:52:06 dank: should live in DNS 09:52:13 rbarnes, jeffh: working on it in IETF 09:52:17 yoav has joined #webappsec 09:52:24 mkwst: cookies are broken and we are stuck with it 09:52:41 "working" might be too strong; the DBOUND WG was chartered, but i don't think it made any progress 09:53:12 people are "talking" about it and recognize a problem exists. :) 09:53:21 https://tools.ietf.org/wg/dbound/ 09:53:38 ^^^ appears to be closed 09:54:57 facebook likes subdomain clearing properties of cookie, will there be an includeSubdomains for other things like local storage? 09:55:15 mkwst: some concern about one origin controlling another's storage 09:55:42 ... google working around by sending requests to those subdomains and they reply with statement to do it themselves 09:55:56 ... this can be expensive 09:56:03 ... clearing cache is expensive b/c no origin-based index 09:57:08 jungkees: did you consider service worker registration map as site data here? 09:57:29 ... is removed when user clears all site data from the browser menus 09:57:36 mkwst: plan is we will discard service workers too 09:57:47 weinig has joined #webappsec 09:59:01 ... spec needs flushing out, but some specs like webSQL don't have necessary things to refer to 09:59:34 dveditz: does this clear service worker's cache? 09:59:53 mkwst: want to clear cache API as well as disk cache, but currently chrome's implementation only clears disk cache 10:00:38 ... chrome presents to users "cookies and site data" which is everything, so being very granular doesn't align well with that 10:00:47 ... but would be open to feedback from developers 10:01:12 dveditz: on mozilla's UI side we have "forget about this site" but developer could consider service workers differently 10:02:04 TOPIC: Credential Management 10:02:16 mkwst: shipped in Chrome 51 and getting feedback from deveopers 10:02:30 ... hasn't been much change to this doc since last F2F 10:02:49 ... a few new issues from Mozilla and others not yet addressed, trying to get password manager team to take this over at Google 10:03:12 ... incremental improvements to the API 10:03:25 ... but pretty unhappy with how API ended up, very high-level and generic in nature 10:03:33 ... because we thought WebAuthn group would use it 10:03:39 jeffh: we tried 10:04:06 mkwst: I think we have an opportunity w/only one impl and only 30 websites using it at scale to take another look 10:04:27 ... decide if there are uses for high level API or if we can shrink down to tight focus on password and federated auth 10:04:59 ... we could make it a lot simpler if we just did something like navigator.passwordManager.get (not that but something like that) 10:05:25 ... given that more generic use cases have gone a different direction or not materialized 10:05:52 rbarnes: did federation go away? 10:06:16 mkwst: no, but current API is very generic with lots of indirection for extensibility, but could refocus for the only two cases we have today 10:06:55 timbl: does this give access to certificates? 10:07:14 mkwst: no it doesn't, provides only origin-locked credentials 10:07:22 https://developers.google.com/identity/casestudies/aliexpress-smartlock-casestudy.pdf 10:10:12 teddink: you said there were a small number of sites using it? 10:10:30 mkwst: I think like 30, I've worked directly with about 7, worked with a couple before I/O when we launched 10:11:07 ... case studies are more for Android to this point 10:11:08 https://developers.google.com/identity/smartlock-passwords/case-studies 10:12:28 bhill2: apple was interested in app-level authentication features for the web platform 10:12:29 bhill2: johnW had noted that a desired feature is a "login, and be logged-in forever" 10:12:48 mkwst: platforms have this, passwords are terrible, but password managers make passwords much less terrible 10:13:38 ... if people like it, it can go to CR, but if people want to propose something smaller, happy to work on that 10:13:51 ... we have shipped in chrome and there are deployments, so would need a really better API to justify the changes 10:13:53 weinig has joined #webappsec 10:13:54 ... but not too late 10:14:00 ... to suggest those kinds of changes 10:14:51 Virginie_ has joined #webappsec 10:14:56 ... Matthew at mozilla suggested some syntatic sugar to just dump a form into the API 10:15:42 Virginie has joined #webappsec 10:15:44 ???: can we fix the dealbreakers with WebAuthn WG use cases? 10:15:52 s/???/jochen/ 10:16:15 jeffh: I didn't drive that, kinda happened organically, probably worthwhile to re-check, folks who drove that decision aren't here 10:17:44 TOPIC: CORS RFC1918 10:18:00 mkwst: little to say beyond last F2F 10:18:15 ... idea is to protect local services from potentially malicious access by the Web 10:18:20 ... spotify, google, etc. 10:18:31 ... those local servers are very often doing a terrible job in protecting themselves from the web 10:18:40 ... see this especially recently in AntiVirus software packages 10:18:53 ... problematic for things like routers that never update and are vulnerable often to CSRF 10:19:08 ... proposal is to segregate local network and localhost from the web by creating a small onion 10:19:25 ... (((localhost)RFC1918)internet) 10:19:53 ... require a preflight to go deeper, accept origin and external request explicitly 10:20:45 ... new header Access-Control-Allow-External 10:21:08 ... implementation is problematic if public DNS names end up resolving to localhost or RFC1918 10:21:19 ... because of layering issues with network and name resolution stack, hard problem I haven't solved yet 10:21:36 ... no implementation outside blink 10:21:55 ... sounded like Crispin and other MSFT folks were *very* enthusiastic about this idea, but not aware that experimentation has started yet 10:22:08 ... very much like to see something like this happen to solve a real class problems, but it turns out to be hard 10:22:50 wonsuk has joined #webappsec 10:22:51 dank: enterprises ended up blocking previous work in this area where they deliberately link from "public" content into their intranet 10:23:01 mkwst: this will break things period 10:23:17 ... if you are not able to update, you shouldn't be accessible from the internet 10:23:35 danK: this is how we ended up with IE6 stuck on so many environments for years and years 10:24:10 mkwst: localhost seems straightforward enough, also want to protect routers by looking at gateway 10:24:38 ... would need some admin configuration, PAC files 10:25:05 ... worry about that later, solve the complex cases first, IPv6 makes this even harder 10:25:25 https://www.chromestatus.com/metrics/feature/timeline/popularity/530 10:25:30 ... according to Chrome's data, we see 1.3% of pageviews including something from an RFC1918 address which is significantly more than I want it to be 10:26:13 ... fairly certain that a large portion of this is AV injecting references to localhost 10:26:27 Karima has joined #webappsec 10:26:28 teddink: doesn't dropbox? 10:26:34 mkwst: and spotify, google, etc.. 10:27:31 wendy: can w3c help in information gathering? 10:27:57 (link shows % of pageview in blink that load RFC1918 content from a page on a non-RFC1918 address) 10:28:27 wendy: maybe information distribution about potential breakage 10:28:36 mkwst: for better or worse users will get caught in the middle 10:28:55 drogers: will be a problem with routers, internet may stop working 10:29:29 mkwst: synology does things that map public DNS to local hosts 10:29:47 Plex famous local media server https implementation also broken by this? 10:30:30 No idea how it is implemented, but I wonder if any of e.g. Comcast's automatic authorization of access to paid content when you are coming from inside their network relies on behavior like this 10:30:53 mkwst: will have to be behind a switch, test and find breakage, try to fix in advance 10:31:14 ... would like to coordinate with browsers so answer isn't just switch to a browser that doesn't do this 10:31:46 dveditz: Opera / Presto used to block like this, no longer does, but do they have implementation experience to share? 10:32:01 [/he hears W3C can help with publicity, outreach on the need to update] 10:32:18 jochen: could also for awhile disable the check for certain domains 10:32:33 s|/he|/me| 10:32:44 danK: is this like web USB? 10:33:04 ... means there is momentum in the marketplace for this style of thing 10:33:40 Zakim has left #webappsec 10:34:17 .... the "property" that generates the graph mkwst points at is "MixedContentPrivateHostnameInPublicHostname" 10:34:47 mkwst: only a counter, no URL information here 10:35:15 bhill2: UI Security. Dan, you want to talk about this? 10:35:33 ... [hooking things up to other things] 10:36:24 TOPIC: UI Security 10:36:54 dakami: Hi. 10:37:10 ... This is the first standards body I've ever been part of. Yay. 10:37:39 ... Content on the interet doesn't know if it's visible to users. 10:37:52 ... This is a security property, SOP means you shouldn't know things about other origins. 10:38:14 ... That said, it's actually quite useful to understand when a framed page is loaded. 10:38:24 ... Advertisers, for instance, wish to understand when their content is viewable. 10:38:34 ... They generally use bad mechanisms to do so. 10:38:45 ... IntersectionObserver is a better solution. Shipping in Chrome. 10:39:01 ... That said, it doesn't solve the whole problem. 10:39:25 ... If I want to buy an LED, I go to one origin, then navigate to PayPal. 10:39:40 ... This is crazy. I don't want to go to a store, then go somewhere else to buy it. 10:39:55 ... PayPal embeds itself in eBay because they have a special relationship. 10:40:13 ... But if you do this in untrusted contexts, it's possible to change the displayed UI. 10:40:27 ... PayPal's embed could go from $1000 to $1 with an overlayed image, for instance. 10:40:57 ... There are tons of ways to manipulate pixels. Lots of new CSS features can be dangerous. 10:41:45 ... So, folks send users elsewhere, or pop up windows in order to ensure that they're in control of the rendered pixels. 10:41:51 ... I want to solve clickjacking. 10:42:38 ... Initial approach was to dive into the GPU, and move the frame's layer up to the top of the stack, to ensure that the pixels can't be manipulated. 10:42:50 ... Been working on an implementation for the last ~year. 10:43:01 ... Back and forth with browser folks. 10:43:28 ... IntersectionObserver is an interesting model. 10:43:40 ... But doesn't correctly report things in edge cases that can cause problems. 10:43:41 https://github.com/WICG/IntersectionObserver/blob/gh-pages/explainer.md 10:43:54 ... The active approach is destructive, and potentially bad for perf. 10:44:05 ... Perhaps a passive approach is more compatible with browsers and sites. 10:44:16 ... Status right now: Working with paint folks on the Chrome team. 10:44:33 ... There's clearly interest and excitement in folding this into IntersectionObserver v2. 10:44:54 ... It's not obvious that a passive approach can work, but the browser-side interest makes it appealing. 10:45:51 ... Some question about cases in which developers legitimately overlay transparent things for user interaction. 10:46:04 bhill2: Plan is to consider as part of IntersectionObserver v2. 10:46:23 ... Initially only the IO API. Create observer, receive events, deal with those events. 10:46:39 ... Need to maintain the stack of visibility events, check whether you were visible enough when a click is received. 10:46:51 hadleybeeman has joined #webappsec 10:46:55 ... Once we've proven that, we can progress to something more declarative. 10:47:09 ... "If the click happens when these conditions aren't met, do something." 10:47:33 ... Facebook applies not-so-reliable heuristics today, it would be great to get something from the browser. 10:48:11 timbl: A declarative version sounds like a good idea. 10:48:34 ... If you're in a state where the click isn't going to work, do we show that to the user? 10:48:45 ... Bad to confuse users by swallowing their clicks without letting them know. 10:49:02 dakami: It's fuzzy. 10:49:18 ... Amazon has different rules for one-click than Facebook for Like. 10:49:32 ... It's not clear that we can choose one rule that works for everyone. 10:49:41 ... The imperative approach allows those sites to define their own rules. 10:50:19 ... Given the variation, that seems like a good approach to start with. 10:50:37 ... [Demo of https://autoclave.run/ ] 10:51:39 ... Looking for use-cases, interested folks, help building a passive version. 10:52:03 jochen: Will this come with some kind of library? Sounds hard to get this right. 10:52:27 ... For instance, if I reveal the frame just before I think a click is going to happen, that seems hard to deal with. 10:52:57 dakami: The declarative model could work well for this. "Until the frame has been visible for X milliseconds, and Y, and Z, don't accept the click." 10:53:12 ... Looking for use-cases to flesh out what those declarations might be. 10:53:28 ... The IntersectionObserver-style API pushes that work down to the developer. 10:53:36 ... v1 doesn't give enough data, v2 might. 10:53:48 bhill2: In practice, this will be a complicated API to get right. 10:53:55 ... You'll have to deal with a stream of events. 10:54:15 ... I imagine libraries will spring up, and we can learn from them what kinds of things developers need. 10:54:29 ... Use those as a springboard to inform a declarative API in the future. 10:54:39 ... Browser vendors prefer an incremental approach. 10:55:04 dakami: Right now, the hill to climb is moving from an active approach to a passive approach. 10:55:38 bhill2: I think we want to leave UI considerations up to the browser vendors. We don't want to grey things out while scrolling, for instance. 10:55:57 ... Those decisions are delegated to the user-interface developers for each site. 10:56:06 ... They can make informed decisions about what user experience they want to provide. 10:56:18 dakami: We can polyfill declarative approaches. 10:56:49 bill: You and bhill2 have been working a lot on this. Pushing fewer things to the browsers. 10:57:20 dakami: Inability to see visibility information means that a lot of things are being loaded in the background that aren't needed for the actual page. 10:57:46 bhill2: IntersectionObserver came up because of bad performance implications of visibility checks that advertisers perform. 10:57:52 ... Polling, Flash, etc. 10:58:06 jochen: Those visibility scripts were generally injected into first-party contexts. 10:58:11 ... Which makes things even worse. 10:58:33 ... IntersectionObserver allows the network to prove visibility without injecting into the first-party context. 10:58:46 teddink: Also tiny Flash objects. 10:59:04 dakami: 'isTopRect' is literally one of the calls in Flash. 10:59:14 ... Flash throttles if it knows it's not on screen. 10:59:30 ... So check if it's throttling, kill battery, etc. 10:59:56 bhill2: Sounds like we might deprecate this spec to NOTE, and then do most of the work in IntersectionObserver v2 in WICG. 11:00:31 ... Don't know if we need to make it a joint deliverable. Perhaps can graduate IntersectionObserver into this group once it's baked in WICG. 11:00:42 ... Will add that to the rechartering discussion tomorrow. 11:00:51 TOPIC: Lunch. 11:00:59 [om nom nom] 11:01:24 crystal_ has left #webappsec 11:01:49 agenda reminder: https://docs.google.com/document/d/1yAsZiacMJ55JUPWC6kZAfBzzW1HNc0H7noPtEzcdxqI/edit# 11:02:01 block of time for CSP is next at 13:00 11:02:16 ArturJanc_ has joined #webappsec 11:32:59 jeff has joined #webappsec 11:48:19 rbarnes has joined #webappsec 11:50:49 JeffH has joined #webappsec 11:54:50 rbarnes has joined #webappsec 11:57:03 weiler has joined #webappsec 12:04:34 rbarnes has joined #webappsec 12:05:38 Gloria has joined #webappsec 12:06:00 RRSagent, draft minutes 12:06:00 I have made the request to generate http://www.w3.org/2016/09/22-webappsec-minutes.html Gloria 12:08:08 about to begin again 12:08:27 remote participation reminder: https://talky.io/webappsec 12:09:14 rbarnes has joined #webappsec 12:09:52 TOPIC: finalizing strict-dynamic-syntax 12:10:26 aaj: I work on Google's security team, and do two things relevant to this group: 12:10:45 artur: I work at Google, on the panel rewarding vulnerability reports 12:10:46 ... 1. I work on Google's VRP team, so I reward folks who attack Google. 12:10:55 ... we reward more for impact and exploitablity 12:11:25 ... when we get it wrong, they complain, and so we have lots of knowledge of web vuln space and what google encounters, as well as our acquisitions with lots of different tech stacks 12:11:51 ... also work on building better frameworks, scanning, etc. 12:11:59 ... but will still have bugs 12:12:16 ... so we want to have protection for our users even when mistakes are made 12:12:24 ... we do "boring" things like moving apps to subdomains 12:12:47 ... a more promising thing is looking at web platform features like suborigins, CSP, isolation proposals 12:13:06 ... using things that web apps can't build themselves but have to rely on browsers for can help us a lot 12:13:36 ... over 60% of rewards and 60% of high risks bugs are XSS in last several years, over $1M paid 12:13:53 ... we care about XSS a lot and CSP is the only standard that can help us with XSS right now 12:14:19 ... strict-dynamic: drops the whitelist in script-src, propagates trust from scripts that already are allowed to execute, e.g. by a nonce or hash 12:14:42 ... not a big feature but hugely changes how we deploy CSP 12:14:54 ... some adoption stories from Google products over past several years 12:15:02 ... deployed to 15 apps, about half of which are user-facing 12:15:25 ... photos.google.com required maybe a 10 line change because the template system already had auto-noncing 12:16:06 ... cloud console app that lets people push code to their cloud instances, XSS there could allow code execution 12:16:39 ... had a plan a few years ago to add CSP, came up with 4 different policies depending on the part of the application 12:17:16 ... talked with my team in Zurich, already shipping in production, worked quite easily 12:17:41 kaorumaeda has joined #webappsec 12:17:47 ... a few other products already using whitelist based CSP were switched, developers are happy to not have to worry about the whitelist 12:17:53 ... but still get XSS protection 12:18:22 ... we can keep the whitelist and have a separate policy with strict-dynamic and the nonces 12:18:32 crystal___ has joined #webappsec 12:18:48 ... 300M monthly users; no significant blockers so far 12:19:14 ... did a study of over 100 XSS bugs in Google properties, about 3/4 would be mitigated by this kind of policy 12:19:29 ... HTML injections, JavaScript URIs.. 12:20:00 ... 1/4 of bugs would not be mitigated, but even big projects like automated scanners can only identify ~30% of bugs due to diversity of environments and bug classes 12:20:13 ... so this has gone really well and hoping to get more folks to implement it tonight and ship it tomorrow 12:20:32 mkwst: shipping in chrome since 52, two stable releases 12:21:30 francois: this is doing 2 things, propagating nonces and dropping whitelist, thought about splitting thost? 12:21:33 s/thost/that 12:21:51 artur: we could to that with two keywords, but almost any application would have to set both 12:22:26 ... but those policies would be unsafe because whitelists are bypassable 12:23:09 ... dropping whitelist but turning off trust propagation seemed like an edge case because there may be dynamic script loading in the future 12:23:43 ... also simpler to have one thing than two, syntax-wise 12:24:33 mkwst: conversation linked: wanted ability to whitelist a loader file, and then have propagation 12:24:41 ... some issues with that; isn't backwards compatible 12:25:10 ... if browser doesn't understand new syntax, things blow up 12:25:46 ... model so far has been to have policy mean something in an old browser, and new keywords can turn off some parts of policy and replace it with a stricter effect 12:25:55 ... such as nonces and hashes turning off unsafe-inline 12:26:03 Karima has joined #webappsec 12:27:23 ... I think there are good arguments that it is backwards compatible and shown to be deployable as-is today 12:28:33 artur: I worry about people using nonce propagation without dropping the whitelist 12:29:11 ... people would not add the whitelist drop directive if not needed for things to work, and thus the documented bypasses would still exist 12:29:27 (when whitelists are too broad) 12:29:38 francois: the backwards compatibility aspect is super useful 12:30:37 ... but someone who doesn't want dynamic propagation but would want to remove the whitelist seems useful 12:30:57 ... still have whitelist for CSP1 browsers that don't support nonces/hashes 12:31:31 teddink: in a few months IE will be last significant browser... 12:32:23 mkwst: you can get that by a policy that is whitelist + nonce, and then a policy with nonce only 12:32:28 ... depends on how implementation works 12:33:02 ... if implementation throws away a policy with no directives it understands or if it interprets that as "nothing passes" 12:34:54 artur: trying to prevent need to do user agent sniffing 12:36:21 ... security wise the benefit of the proposed change is APIs that take tainted data and dynamically load scripts 12:36:47 ... we have found very few vulnerabilities of that sort, nothing in the last year of 100+ real XSS bugs at Google 12:37:41 ... so I think cases where the uses of this would produce a concrete benefit are rare enough to not warrant splitting it out 12:38:43 christoph: was worried that we were making CSP too complex, but if it is in a backwards compatible way, maybe better than versioning the header. I see the benefit, but where to go from here? 12:38:54 ... do we find a year from now that we need something more? 12:40:08 mkwst: I hear from Francois it might be worth exploring a new keyword that gives whitelist dropping functionality without dynamic nonce propagation 12:40:35 ... if it seems valuable, you can write it up 12:40:43 christoph: that google is already deploying it to good effect convinces me 12:40:50 rrware has joined #webappsec 12:40:52 yoav has joined #webappsec 12:41:31 artur: if we had found vulnerabilities related to trust propagation, but that's not in the data set we have 12:41:46 christoph: is there a reduction in the bugs filed? 12:42:06 artur: we pay full amounts even if only one browser exploitable, so things that CSP mitigates still result in a bug payout 12:42:12 ... until we get full adoption 12:42:46 ... if you can inject scripts you can probably inject phishing content, so maybe no bug reduction 12:43:48 christoph: can we put stuff in web platform tests to make sure we are interoperable on edge cases around parser inserted scripts 12:44:02 kaorumaeda has left #webappsec 12:44:10 kaorumaeda has joined #webappsec 12:46:02 artur: so far only API where we had to manually pass the nonce was document.write 12:46:49 TOPIC: CSP3 12:46:55 mkwst: basically done from a feature perspective 12:47:02 ... two things that are open questions whether to add 12:47:12 ... generally speaking the things we've discussed as a group are in the doc 12:47:18 ... there is polish work to really call it done 12:47:36 ... but by and large the functionality is there that we want and a good job of explaining what the spec does in terms of HTML and Fetch 12:47:40 wonsuk has joined #webappsec 12:47:52 ... most of the hooks we need are in those documents and spelled out in ways they weren't before 12:47:55 https://w3c.github.io/webappsec-csp/#changes-from-level-2 12:48:01 timbl has joined #webappsec 12:48:03 ... some open questions about how to get that into W3C versions 12:48:22 ... there is an issue filed against relevant github for each cases and then listed in this doc 12:48:28 ... two things that are open questions are 12:48:33 ... 1) what to do with inline script hashes? 12:48:50 ... proposal in the doc, not backwards compatible wrt: older browsers 12:49:28 2) navigation 12:49:43 mkwst: there a few open issues in github having to deal with navigation 12:49:55 ... antimalware team at google wants to use something like this for advertising 12:50:22 ... would be work to hook into spec language for navigation 12:51:02 ... we already do this for form posts, do we also want to do it for window.open, regular navigation, etc. 12:51:40 mkwst: good time to look at the doc and give comments 12:52:54 ... a few 'breaking' changes like what does * mean for non-web content on custom schemes 12:53:42 ... some questions about what are we hashing - UTF-8 conversion first? 12:54:20 ... where native text mode is UCS-2 12:54:45 ... both chrome and ff appear to do UTF-8 encoding first before hashing, would love help to know if that is correct 12:56:44 facebook hat on, would support navigation source restrictions, people are doing this today with nested frames and frame-src 12:56:52 ok to not have it work on top-level browsing contexts 12:59:16 also: re: exfiltration and confinement, postMessage is an explicit channel that Deian wanted to control in context of COWL 12:59:59 mkwst: maybe better to solve by limiting when you have a handle 13:02:20 artur: reporting... 13:02:29 ... never been usable because of extensions tampering with pages 13:03:02 ... maybe not tractable, but maybe smart people have ideas 13:03:18 ... I would like to see if a particular report was caused by an extension 13:03:27 dveditz: if we knew, it wouldn't be a violation 13:03:44 artur: for example, could the report tell us if it was in content added to the DOM by an extension 13:04:52 Yoshiro has joined #webappsec 13:05:04 teddink: developers want line and column for every single time 13:05:16 ... and that is really hard sometimes depending on the context when it happens 13:05:24 mkwst: is best effort 13:06:49 christoph: sometimes we put a script sample in the report / console 13:06:59 mkwst: we have argued about that because it can leak cross-origin data 13:07:15 mikepie has joined #webappsec 13:07:45 artur: maybe something different for inline violations 13:08:16 mkwst: we currently set blocked uri to "inline" or "eval" but maybe there is metadata we can add there 13:16:02 TOPIC: What to do long-term with CSP? 13:16:36 terri: ping -- did you want to join the talk.io channel? 13:17:50 scribenick: dveditz 13:17:59 timbl has joined #webappsec 13:18:03 RRSAgent: scribenick dveditz 13:18:03 I'm logging. I don't understand 'scribenick dveditz', dveditz. Try /msg RRSAgent help 13:18:40 weinig has joined #webappsec 13:18:42 mkwst: reflecting on what we've been doing w/CSP and what's been working and what doesn't 13:19:19 ... do we carry on with "CSP4" in much the same way? or do we come up with a whole new "better" thing? 13:19:53 ... on the one hand I don't want to do just another CSP, and on the other building something new just to be new isn't appealing either 13:20:18 ... if we think about what we would have done differently maybe we can come to an answer 13:20:40 ckerschb__: do we rip stuff out then? 13:21:58 mkwst: browsers are slow to move, there's an advantage to tacking things on to existing CSP. then again if we didn't have historical baggage we could come up with some beautiful thing. 13:22:40 ... Artur is interested mainly in XSS preventing. other than script-src the rest of CSP is just getting in the way (hyperbole) 13:22:55 ... Jan is interested in stopping exfiltration 13:23:18 ... if we had a header that was just a nonce it would be clean and simple. would that be good enough? 13:23:32 ... would lose some of the good features we have such as containment and so on 13:24:11 ... At the end of the day we could definitely come up with better syntax, but from a high elevation it could be effectively the same 13:24:50 ... We put other things into CSP because it was a convenient place to put policy. upgrade-insecure-request, block-all-mixed-content, and so on 13:25:07 ... it's convenient, but is it worthwhile complexity? 13:25:19 mikepie has joined #webappsec 13:25:34 ... whether we have 5 new headers or one header with 5 options it's probably about the same 13:26:16 dankaminski: your proposal about isolation is beautiful. 13:26:34 rbarnes has joined #webappsec 13:27:05 mkwst: the nice thing about isolation is it's tied to an origin, rather than to a document like CSP. I think that's something we should build. 13:28:10 ... one aspect of origin policy is the ability to set headers/policy on the entire site, even if the site forgets to cover all pages (e.g. forgetting CSP on an error page) 13:28:29 ... maybe we could have done better with an origin-wide policy to start with 13:29:28 tbl: I'm always trying to find a way to do more rather than less. what if I wanted to turn on full errors for CORS -- normally seen as a security risk 13:30:40 mkwst: if the thing you're reading sets the policy "yes you can have error messages" then that would be OK. we could do something similar for "don't send me CORS pre-flights -- I understand CORS just go for it" 13:30:56 ... feature-policy is another organization-wide policy 13:30:58 rbarnes has joined #webappsec 13:31:26 ... could reduce threat surface by turning things off "I know I don't use WebRTC" 13:31:36 ... having a place for a policy like that is good 13:31:57 tbl: then you're restricting the abilities of sites 13:32:43 mkwst: the way we enhance site's abilities is by involving users. 13:34:19 tbl: this is going in a good direction toward trusted apps on the web. you could do a tradeoff. 13:35:02 ???: if I put my Crispin hat on, "don't ask the user security questions-- they don't know the answer or understand the consequences" 13:35:28 me s/???/Ted/ ? 13:35:42 tbl: if you believe users can't be trusted then we can't ever replace native apps, because users have answered the questions there 13:35:59 (thx JeffH) 13:37:02 artur: the messy state of CSP we have now is because developers didn't know what they were doing. they deployed policies they didn't understand that gave them things they didn't want. it's not just "users" who don't understand 13:37:34 ... the "next thing" should not have the same potential for misuse and misunderstanding as CSP 13:38:08 mkwst: then we need a clear definition of what we're making. even CSP 3 doc doesn't have a clear definition of what it's good for 13:38:33 bhill2: there isn't one true way of web devleopement, and not just one true way to secure web sites 13:40:04 ... if I didn't have a mechanism for central enforcement a small security team could not keep thousands of developers from importing random code from various places. 13:40:48 ... we have policies like don't load images from remote, because our traffic can melt sites. CSP enforces that we host a copy of the image/resource instead for example 13:41:08 artur: there's a good reason CSP is in the state it is -- different people want different things from it. 13:41:38 ... some people want whitelists, and we have a bunch of new keywords for additional features 13:42:01 ... we should examine our threat model (scheduled for tomorrow) 13:42:43 ... tries to solve XSS, clickjacking (frame-ancestors), ???, and half a thing is site hygiene 13:43:21 ... but it doesn't work for clickjacking -- need XFO as well because not all browsers support frame-ancestors 13:43:39 ... mixed-content blocking keyword, but all modern browsers already do most of that already 13:44:27 ... the two main things that help are XSS protection and origin hygiene. The security guarantees given by a whitelist are much lower than people assume. 13:44:39 ... completely bypassable if you have a nonce, for one thing. 13:45:22 ...there's value in having something like this, I'm just not sure these two features should be in the same mechanism 13:46:37 ... the whitelist was not the goal of CSP as much as a side-effect of the anti-injection goal 13:47:11 mkwst: I've seen tweets like "the best thing about CSP is the marketing folks have to come to me when they launch a new campaign" 13:47:29 artur: but if there's a nonce then the marketing dept can just get around it 13:47:38 bhill2: maybe there's not a nonce in the policy 13:47:57 artur: what would facebook be vulnerable to if this didn't exist? 13:48:09 kaorumaeda has joined #webappsec 13:48:45 bhill2: we're a valuable enough target that if we loaded scripts from 500 domains people would hack many of those domains to get at us. We can't guarantee how secure those sites are 13:49:19 ... if we don't have site control then it's equivalent to giving all those sites commit privs to our application. 13:51:10 ... we've never been able to _rely_ on CSP for protection because not all browsers support it, but enough big browsers do that the CSP keeps the developers from doing things outside our parameters 13:52:03 artur: for us killing off XSS is intractable without something like CSP, but script inclusion is easily handled with integration tests. sounds like it's the opposite for you 13:52:29 bhill2: there's no "one true way of software development" and I appreciate that CSP supports multiple approaches 13:52:52 ... how do we make it serve more people better without taking away some of the flexibility 13:53:32 wonsuk has joined #webappsec 13:54:13 francois: it's clear from artur's paper that the current policies are not effective against XSS, and if we want to focus on that then maybe a small simpler policy language would be better. 13:55:33 mkwst: if the problem we want to address is developer ergonomics maybe we need to develop a different language for that 13:56:42 ... we have a bunch of code that implements security policies (not all CSP) and even if we come up with something different browsers still have all this code and it's not going away. we should leverage that. 13:57:41 bhill2: as you said, a new header that supports a simpler syntax (nonce-only, for instance) that is underneath implemented as CSP might be helpful, without getting rid of CSP. 13:58:03 rbarnes: we still have IndexedDB right? very developer hostile, but it's still there and people use it 13:58:59 ... even if we factor things differently, if we end up with something that's effectively equivent then is it worth making that change? 13:59:44 francois: there's probably a group of devs who can handle the complexity of CSP and want that flexibility, but others who would be served better by a simpler subset 14:00:44 mkwst: my thought in 2012/13 was CSP is a great place for everything -- it's got "security policy" in the name! 14:00:59 ... for instance SRI -- should that be somewhere else? 14:01:49 artur: if we took out the whitelist aspect of CSP we'd be left with a set of flags of what we want the site to do and not do. would that be easier to understand? Put the whitelist in a separate place 14:02:37 mkwst: if we want to make a change with a different syntax, then we lose backwards compatibility and that gives us freedom. we might as well start over. Come up with something we think is pretty now, and in 5 years we'll be having this same conversation 14:03:26 ... if I gave you an Artur: header that let you define a nonce and solves your problem, and defines it in terms of CSP, then you'd be happy. 14:04:03 artur: regardless of syntax, CSP can do whatever we want at Google. I worry about everyone else -- they aren't getting what they think they are getting from it 14:05:14 ...if 3 years from now we ship the next big thing that's as hard to understand as CSP then we'll have the same results of people deploying policies they don't understand 14:05:59 francois: if you get the "Artur: Yes" header then you could ignore the complexity of CSP 14:06:53 artur: if there was something to replace CSP that was simpler and harder to misuse that would be easier to evangelize than "Here's CSP, but only use this bit of it and don't touch the rest if you don't know what you're doing" 14:07:35 ckerschb__: I'm torn. yesterday I thought we should rip everything out of CSP, today I feel differently, tomorrow who knows 14:08:07 ... if we did take everything out, where would "require SRI" go? where would "upgrade insecure request" go? then I have to think of 10 things instead of one thing 14:09:07 artur: if there was one central policy then you could have a site expert manage it and the individual developers just have to live within it. 14:10:22 dankaminsky: this is a developer budget issue -- time budget, thought budget. if there's one thing CSP is really good at people should do that 14:10:38 weiler has joined #webappsec 14:11:06 bhill2: I like the idea of a simpler header (but don't _call_ it Simple because it never is) 14:11:58 ... evangelize the simple solution, like a stereo with two simple buttons, and a glass slider that reveals dozens of knobs and switches that you rarely get into 14:13:39 dankaminsky: there are some JS frameworks that make security infeasible. yes they make development simpler but... 14:14:10 mkwst: nice thing about "Artur: yes" is it's polyfillable -- can rewrite it into a CSP policy automatically 14:15:50 ckerschb__: if we decided to start over from scratch and create something new and shiny, as we add new things to the web and then have to add them to the new thing and in a few years it's not so nice and shiny 14:16:19 bhill2: with feature-policy and origin-policy we have more places to put these kinds of policy things 14:16:44 jochen___: referrer policy is one case of something that was removed from CSP into it's own header 14:28:01 weinig has joined #webappsec 14:37:00 JeffH has joined #webappsec 14:38:03 timbl has joined #webappsec 14:38:12 Gloria has joined #webappsec 14:43:16 rbarnes has joined #webappsec 14:48:20 mikepie_ has joined #webappsec 14:53:20 yoav has joined #webappsec 14:53:34 TOPIC: Referrer Policy 14:54:43 jochen: we hope that we can move to PR pretty soon, currently two blocking issues 14:54:55 ... one is what we touched on earlier today: whether value should be quoted or not 14:55:04 s/PR/CR/ 14:55:19 ... other issue is want to add some text about CSS. CSS spec doesn't talk about how it loads resources. 14:55:28 ... and browser implementations don't do the same thing according to my tests 14:55:38 ... after talking over dinner with Anne came up with a proposal of what do to 14:55:41 Yoshiro has joined #webappsec 14:55:55 ... add some text to describe how it should be and wait for CSS to describe how they do it and update the spec 14:56:45 ... another question is module: can trigger loads, including for nested loads, not really clear what settings for fetch should be 14:57:13 ... in CSS loading a subresource, the stylesheet is sent as referrer in old implementation 14:57:22 annevk: pretty sure what you're saying doesn't match the HTML spec 14:57:38 ... once you do a module spec, it creates its own environment, so any further spec should use that environment's settings 14:57:53 jochen: would it send the module's origin? 14:58:00 annevk: origin is inherited from document 14:58:07 jochen: 2nd level inherits from where? 14:58:52 wonsuk has joined #webappsec 14:59:21 jochen: Now I have a microphone. 14:59:42 ... Modules: The loader spec isn't done yet. Would rather not address in the referrer policy spec. 14:59:52 annevk: The HTML spec defines how modules are loaded. 15:00:01 ... The loader spec is just hooks. Doesn't change how browsers load modules. 15:00:13 jochen: Using hooks is fine. The problem with CSS is that it doesn't have hooks. 15:00:34 ... Loader will integrate with Fetch, and then we're set because Fetch has a referrer policy on a request. 15:00:57 ie: https://html.spec.whatwg.org/#module-script ? 15:01:00 annevk: Not sure if modules should respect a policy set on them. 15:01:24 jochen: Differences in browsers is down to when inheritance takes place. 15:01:38 ... Insert a stylesheet, then use the history API to change the URL, and see what happens. 15:01:51 ... I think it makes sense to capture the state at the point at which the stylesheet is injected. 15:02:16 ... Similarly, it makes sense to snapshot at the time an `import()` statement is passed. 15:02:25 annevk: URL or referrer policy? 15:02:35 jochen: I'd like to capture both. 15:02:47 annevk: Why capture the URL? 15:02:55 jochen: 15:03:06 ... #foo { background-image: url(); } 15:03:10 ... pushState() 15:03:26 ... appendChild(createElement().id="foo") 15:03:30 ... What happens? 15:03:42 annevk: Uses the URL of the stylesheet, not the document. 15:03:52 ... Because the stylesheet creates the fetch. 15:03:58 ... I think that's how Firefox works. 15:04:01 jochen: Not always. 15:04:09 annevk: [skeptical noises] 15:04:15 cabanier_ has joined #webappsec 15:04:28 jochen: Point is, we should write this down. And that means teaching CSS about how fetching is supposed to work. 15:04:41 ... So this is why we need a section in the referrer policy document that describes the expectations. 15:04:50 annevk: You should convince the CSSWG to do the work. 15:04:54 ... Otherwise it's undefined. 15:05:07 jochen: Apparently people are looking into fixing this, but how long should we wait? 15:05:17 annevk: Referrer policy might not need any changes. 15:05:49 jochen: Either we don't say anything about CSS, leave it undefined, and then make sure that CSSWG puts in reasonable hooks for Fetch. 15:06:03 ... Or write something vague in referrer policy to specify what we'd like to see happen. 15:06:18 ... Should get URL and policy at the same point in time and from the same location. 15:06:25 annevk: I think bz disagrees. 15:06:33 ... Thinks it should be the Gecko model. 15:06:45 jochen: Gecko is weird, because gets the policy at a different point in time than the URL. 15:07:15 ... You can change the page's policy in the document, and see that it isn't captured. 15:07:32 annevk: Sure, might make sense to capture the policy, but always use the URL of the stylesheet. 15:07:42 jochen: I think all browsers agree on the referrer URL. 15:07:58 annevk: I don't think Gecko uses the referrer of the document. 15:08:19 jochen: Might be wrong. We can look. 15:08:43 ... Regardless I don't want to specify that in this specification. 15:09:12 annevk: If you're going to say "We haven't figured out CSS yet." that's fine. If you say "We haven't figured CSS yet, so just do what Chrome does." that might not be fine. 15:09:19 jochen: We could just not talk about CSS> 15:10:00 mkwst: I think we should say something high-level, but we shouldn't say nothing. 15:10:18 jochen: Requirements are possible in both models. 15:10:31 annevk: We inherit other things from the document, so why not the policy? 15:10:35 jochen: Why not the document's URL? 15:10:41 annevk: Because we have something better. 15:11:08 ... [discussion] 15:11:13 ... Talk to bz. 15:11:18 ... He has opinions. 15:11:32 jochen: Ok. 15:11:43 ... That's it. 15:11:52 bhill2: What resolution do you want on quotes or no quotes. 15:11:57 ... Show of hands? 15:12:06 jochen: Sure. 15:12:30 ... My personal opinion is that our policies are already pretty tree-like. We encode several complex ideas into a single keyword. 15:12:46 ... If we want something more complex with a JSON representation, we might as well scrap all the existing values. 15:12:57 ... From that point of view, no reason to be forward compatible. 15:13:37 ... If there's a strong belief that it should be JSON-like, just put quotes there. Whatever. 15:13:45 cabanier has joined #webappsec 15:13:52 annevk: You need to consider extensibility. How are you going to extend the API and attribute? 15:13:56 cabanier_ has left #webappsec 15:13:56 ... Back-compat? 15:14:20 ... The header idea of doing headers in JSON. 15:14:28 ... Mike seems to be the only one doing that. 15:14:53 jochen: Without an indication of what the future looks like, a new header is the right answer. 15:15:24 annevk: With an older header and a newer header, the old one still works for older browsers. 15:15:37 dakami: Of the tree protocols, JSON has a simple parser. 15:15:48 annevk: The HTTPWG hasn't done their homework on headers and parsing. 15:16:02 ... Was an informal gathering, and folks were opposed to JSON. 15:16:15 dakami: Between binary and JSON, JSON looks great. 15:16:26 ... Between JSON and status-quo, I don't know. 15:16:36 annevk: 5-10 a year? Usually very simple. 15:16:48 dakami: JSON encapsulates some of the garbage around header escaping and splitting. 15:16:57 ... Some standardization there is of value. 15:17:06 annevk: Header-combining intermediaries. 15:17:21 ... First half of a value in the first header, and the second header has the last bit. 15:17:32 ... If not combined, maybe or maybe not a valid value. 15:17:45 dakami: Requires a clear definition of how to combine headers. 15:18:16 annevk: If we define a list of headers parsed in the old way, and the rest in the new way, great. 15:18:36 ... Look at token binding, for instance. 15:18:48 mkwst: [complains about the bay area] 15:19:01 bhill2: Folks are sending unquoted values today. 15:19:15 ... If we introduce quoted values, then we'd have folks sending two formats, even before a new format. 15:19:29 ... If we need to add more values, not sure if we actually get forward compatibility. 15:19:33 ... So maybe don't add quotes? 15:19:41 ... That makes it simpler inside a meta tag, slightly. 15:20:02 dakami: I like the idea of some standardization of parsing. 15:20:11 ... Loose parsing is bad over time. 15:20:15 devd has joined #webappsec 15:20:31 bhill2: I think that's a decision made not here. 15:20:45 ... The decision to make here is whether it's worth trying to anticipate that decision in this and other headers. 15:21:19 From the implementor side, worth pointing out all the pain that quoting, CSP's syntax leads to 15:21:30 jochen: I hear that the easiest way forward is to stick with the plain value. 15:21:32 so if we can go straight to JSON instead, that would be best 15:22:08 dakami: How don't you end up with an attack vector? Request splitting, etc. 15:22:16 bhill2: We have a fixed set of known values here. 15:22:17 A JSON Encoding for HTTP Header Field Values: https://tools.ietf.org/html/draft-ietf-httpbis-jfv 15:22:32 ... If we quote them, great. If we don't, we need a new header. 15:23:05 annevk: Note that something more elaborate than JSON, then simple strings are incompatible. 15:34:41 15:35:10 tl;dr: forward compat story for e.g. HTML attributes and API is not clear in any case, they are enums today that accept a single string value 15:38:36 jochen: fundamentally the policy space for this header is not so large we couldn't just do it with an enum 15:39:08 ... only possibility is to be able to do something like map parts of url space to policies instead of annotating all anchors, etc. individually 15:41:50 RESOLVED: The group doesn't care. 15:41:59 But is going to run with unquoted strings. 15:42:12 TOPIC: CORS for Developers 15:42:26 bhill2: This is an attempt to write an explainer for CORS, which is sometimes somewhat difficult to understand. 15:42:44 ... [CORS] isn't exactly an up-to-date reference. 15:43:01 ... Published this note as an explanatory reference that's more up to date. 15:43:10 https://w3c.github.io/webappsec-cors-for-developers/ 15:43:42 ... Advice for developers. History lesson. 15:43:57 ... [Chat roulette interlude.] 15:43:59 annevk has joined #webappsec 15:44:12 ... Attempts to explain more simply with tables and etc. 15:44:19 ... Aimed at web developers, not browser implementers. 15:44:40 ... Anne had some comments, took those into account. Looking for more feedback. 15:45:09 ... Seemed to be support for producing this kind of documentation, aim to CfC to publish as a note. 15:45:38 ... Note, not a normative spec. Attempt to help developers out. 15:45:46 "pre-Javascript browsers" ?? 15:46:31 mkwst: Yay. More of this, please. 15:46:32 artur: Does it make sense to do something similar for CSP? 15:46:51 bhill2: I think it's a general problem that we write specs for browsers, but expect users to somehow understand them. 15:47:09 ... We need to do a better job explaining things to different audiences. 15:47:37 teddink: Reading Stack Overflow, it's clear that developers _do_ read the specs, but often don't understand the nuance, specialized language. 15:47:57 wseltzer: We hear from other groups that more explainers would be helpful. 15:48:24 bhill2: Folks still want a solution to "No, really, this is public even if you sent cookies." 15:48:50 ... It's not clear that we could do that without repeating the issues of the past (`crossdomain.xml`, etc). 15:49:26 annevk: We do leak timing information with `*` with `Timing-Allow-Origin`. 15:49:36 ... Which is actually somewhat important. 15:49:54 ... Inconsistent. Not clear how it got past security review, but it did. 15:50:22 ... Since no one is paying attention, maybe we can do that here too? 15:50:53 rbarnes: What's the issue with "*"? 15:51:05 bhill2: Can't send `*` in `Allow-Origin` for credentialed request. 15:51:34 annevk: A lot of the complexity resulted from a security review in 2006. 15:52:23 ... Might be worth reevaluating things with the folks paying attention these days. 15:53:12 ... On the other hand, the requirement isn't onerous. 15:54:53 wonsuk has joined #webappsec 15:55:44 annevk: [Chrome has problems. Probably Mike's fault.] 15:55:58 ... Also, Appcache is bad. 15:57:17 bhill2: Maybe an opt-in to refetch without credentials in some cases? 15:57:24 annevk: A library could do that. 15:57:34 ... Also, T-A-O allows multiple values. 15:57:41 ... We could do that too. 15:57:55 ... Could address a CDN that works with 5 domains, doesn't address the "truly-public" case. 15:59:08 yoav has joined #webappsec 15:59:56 annevk: If you make the request from a unique origin, the server can make a static response, as `null` is a reasonable non-`*` response. 16:00:31 bhill2: What about redirects? Do we no longer set the origin to `null`? 16:00:50 annevk: I don't think so? 16:03:45 RRSAgent, make minutes 16:03:45 I have made the request to generate http://www.w3.org/2016/09/22-webappsec-minutes.html bhill2 16:03:51 rrsagent, set logs world 16:13:23 yoav has joined #webappsec 16:23:19 weiler has joined #webappsec 16:25:35 devd has joined #webappsec 16:26:26 Karima has joined #webappsec 16:30:29 wonsuk has joined #webappsec 16:30:40 wonsuk_ has joined #webappsec 16:39:12 rbarnes has joined #webappsec 16:46:59 weiler has joined #webappsec 17:48:59 rbarnes has joined #webappsec 18:00:57 bhill2 has joined #webappsec 18:02:14 bhill2 has joined #webappsec 18:03:03 bhill2_ has joined #webappsec 18:14:03 rrware has joined #webappsec 19:03:11 bhill2 has joined #webappsec 19:10:37 bhill2 has joined #webappsec 19:59:48 rrware has joined #webappsec 21:38:30 weiler has joined #webappsec 21:39:45 weiler_ has joined #webappsec 21:46:17 bhill2_ has joined #webappsec 21:49:49 bhill2 has joined #webappsec 22:18:16 yoav has joined #webappsec 23:04:04 bhill2_ has joined #webappsec 23:38:07 kaorumaeda has joined #webappsec 23:44:24 kaorumaeda_ has joined #webappsec