07:57:37 <RRSAgent> RRSAgent has joined #webappsec
07:57:37 <RRSAgent> logging to http://www.w3.org/2015/07/14-webappsec-irc
08:13:01 <dveditz> dveditz has joined #webappsec
08:15:06 <wseltzer> agenda: https://github.com/w3c/webappsec/blob/master/admin/berlin-f2f-july-2015-agenda.md
08:15:10 <bhill2> Meeting: WebAppSec F2F Berlin, 14-July-2015
08:15:15 <bhill2> Chairs: bhill2, dveditz
08:15:19 <bhill2> Scribe: Dan Veditz
08:15:22 <bhill2> Scribenick: dveditz
08:15:41 <dveditz> present+ dveditz
08:15:43 <wseltzer> Topic: Upgrade Insecure Requests
08:15:44 <dbaron> dbaron has joined #webappsec
08:15:45 <freddyb> present+ freddyb
08:15:47 <wseltzer> present+ wseltzer
08:16:02 <bhill2> present+ bhill2
08:16:04 <dveditz> mkwst: upgrade insecure requests spec -- implemented in Chrome and just recently Firefox
08:16:05 <dbaron> present+ dbaron
08:16:17 <wseltzer> https://w3c.github.io/webappsec/specs/upgrade/
08:16:18 <dveditz> ... getting good feedback from ppl in Google experimenting with this
08:16:33 <dveditz> ... trying to migrate over historical content
08:17:01 <dveditz> ... washington post is interested, w3c is interested. good to see. TAG review a couple months ago, suggestions for improvements
08:17:25 <dveditz> ... only one not implemented is changing the flat token to a source-style directive (to upgrade specified hosts)
08:17:51 <dveditz> ... this would allow continuing to serve insecure images from a particular site while upgrading your own content
08:18:14 <dveditz> ... this would be consistent with other parts of CSP and might be relatively trivial to add. Will probably add that in the relatively near future
08:18:30 <dveditz> ... Discussion going on right now about the name and the name of the signalling header
08:19:11 <dveditz> ... Sending a header "Https: 1" turns out to break sites for various reasons (infinite redirect loops, or try to redirect to https event hough they don't support it)
08:19:21 <dveditz> ... some have suggested just breaking those sites but I don't want to do that
08:19:43 <dveditz> ... current proposal is to use the current name upgrade-insecure-requests. bsmith wants "non-secure"
08:19:50 <dveditz> ... I don't want to argue for months
08:20:09 <dveditz> ... would like this group to bless a name so we're done
08:20:52 <dveditz> ... proposal to merge this feature spec into the Mixed content spec. Don't think it's a great idea
08:21:09 <dveditz> ... bsmith's argument is this is a mitigation strategy for mixed content, so it's totally related
08:21:19 <dveditz> wseltzer: I think we have other ways of doing that
08:21:55 <dveditz> francois: hypothetically if we did MIX-2 with opportunistic upgrade would it be appropriate to merge at that time?
08:22:03 <dveditz> mkwst: sure, nothing preventing us from doing that
08:22:48 <dveditz> ... spec seems to be doing good work, implementations are coming out -- have two compatible (or mostly) implementations for the core of it
08:23:09 <dveditz> dveditz: I don't think the Firefox patch included the signalling header yet. didn't see it in the patch (but could have missed it)
08:23:54 <dveditz> mkwst: looking through the github issues...
08:24:10 <dveditz> bhill2: for navigation requests... those are only upgraded for same-origin requests?
08:24:15 <dveditz> mkwst: correct
08:24:24 <dveditz> bhill2: how would that work with a source list
08:24:38 <dveditz> mkwst: could have two lists, or use the same lists for both resources and navigations
08:25:31 <dveditz> mkwst: or could have a list of resources and then if you navigate to those sites that would be covered
08:25:52 <dveditz> ... but '*' would be problematic in that sense because it will likely break for some sites.
08:26:20 <mkwst> https://github.com/w3c/webappsec/issues/184
08:26:22 <dveditz> ... splitting would explain the current behavior so maybe that's a good way to do it
08:26:40 <JonathanKingston> JonathanKingston has joined #webappsec
08:26:50 <dveditz> bhill2: that seems interesting to me to have those addressable independently
08:27:12 <dveditz> ... I can see a site having a constellation of hosts that will be upgraded together
08:27:35 <dveditz> ... or ebay and paypal upgrading together
08:27:50 <dveditz> mkwst: that's the only real outstanding issue from my perspective
08:28:01 <dveditz> ... couple of editorial issues
08:28:30 <dveditz> ... concept of a navigation set inside nested browsing contexts
08:29:06 <dveditz> ... that's an additive thing in nested contexts. This may be poorly explained in the spec (Yan, among others, were confused by it)
08:29:22 <wseltzer> present+ Axel, JonathanKingston, rbarnes, francois, mkwst
08:29:27 <wseltzer> present+ Yan
08:30:35 <dveditz> ... if I frame example.com and example.com says it can be upgraded, maybe we should propagate the navigation upwards as well
08:31:24 <dveditz> ... not clear we can do that for '*'. not sure it can be safe to support resources pushed up, but navigations should be.
08:32:28 <dveditz> ... pde wanted this in the **** client because they want to support Safari because it supports HSTS but doesn't support upgrade,
08:32:50 <mkwst> dveditz: confused about preloadable hsts hosts.
08:33:37 <dveditz> mkwst: we send a signalling header, want to reduce noise
08:33:52 <rbarnes> i totally do not understand the let's encrypt argument.  there is currently no browser-facing component to LE, except for the certs.
08:33:57 <dveditz> ... we need to send it to https because site needs to know if it's safe to set HSTS
08:35:02 <dveditz> ... lets say we go to w3c and if they don't get this header, they can redirect back to http because they can't support the upgrade
08:38:03 <dveditz> mkwst: no browser supports this feature that doesn't already support hsts. it would be more complicated if that were not true
08:38:58 <dveditz> slightlyoff: if conceivable that our preload list will get so large we use a bloom filter or some other lossy format. why wouldn't we send this header then?
08:39:24 <dveditz> mkwst: chrome doesn't actually implement this yet
08:40:02 <dveditz> ... I basically agree with you that the scenario when we can remove the signalling header is distant, but I'd like to remove it someday. I didn't want to send the header at all, but was convinced otherwise.
08:40:19 <dveditz> ... would still like to be able to remove it in the future, or reduce its use
08:41:15 <wseltzer> present+ mnot
08:41:35 <dveditz> bhill2: anything else on the topic?
08:42:19 <mnot> mnot has joined #webappsec
08:42:21 <yan1> yan1 has joined #webappsec
08:42:37 <dveditz> mkwst: would like a rubber stamp on the name of the header.... "upgrade-insecure-requests: 1"
08:42:51 <dveditz> bhill2: is that still what you want if we split the directives?
08:43:37 <dveditz> mkwst: yes, that's still the name of the feature so the second directive name is irrelevant wrt the signalling header
08:43:57 <wseltzer> [no objections]
08:43:59 <rbarnes> bhill2 for parliamentarian
08:44:02 <dveditz> bhill2: any objections? unanimous consent
08:44:20 <dveditz> mkwst: any objections to splitting the directive?
08:45:09 <dveditz> ... advantage is if you supported multiple navigation targets, but maybe ??
08:46:07 <dveditz> ... there was a CSP3 proposal to block navigations, but we were concerned about breaking navigations on the web (malware sites preventing people from leaving)
08:46:23 <dveditz> bhill2: this would be less restrictive and more useful
08:46:58 <dveditz> mkwst: upgrade-insecure-navigations? does that need a source list or is * good enough
08:47:32 <dveditz> yan1: the use case would be if you know one of your sub-sites doesn't support https yet
08:47:56 <dveditz> mkwst: that makes sense for the subresource case. does it make sense to make a distinction between subresources and navigations?
08:48:34 <dveditz> ... one pedantic reasons is we can't explain the current distinction between upgrading everything but only upgrading navigations to self
08:49:04 <dveditz> ... but it's easier to reason "upgrade all the resources i might use" vs. "I know everywhere I might navigate to is upgradable"
08:49:45 <dveditz> bhill2: it's useful to have them treated separately, is it useful to have something more granular than 'self' vs '*'
08:50:07 <wseltzer> present+ dka
08:50:15 <dveditz> mkwst:  splitting them in chrome would be pretty trivial
08:51:09 <dka> dka has joined #webappsec
08:51:22 <dveditz> ... one option would be the current directive is magic and makes the distinction between subresources (all) and navigations (self), but if you add a source list
08:51:53 <dveditz> ... then the source list applies to both subresources and navigations. Makes sense, but makes the bare directive pretty magic and hard to explain
08:52:17 <dveditz> ... so in that sense two directives would be easier to explain
08:53:29 <dveditz> ... acn I take the silent majority to be agreeing with what we've been talking about
08:53:58 <dka> present+ Dan Appelquist
08:54:05 <dveditz> rbarnes: rather than using this upgrade-insecure for navigations we could rely on HSTS on the destination to upgrade navigations
08:54:19 <dveditz> ... I'm also fine splitting them out
08:54:41 <dveditz> mkwst: I will fiddle with splitting those out to see what they look like, and I'll change the name of the signalling header in the spec
08:54:59 <dveditz> ... I think that will take care of the feedback we've gotten so should be able to go to CR with those changes
08:55:03 <dveditz> wseltzer: thank you
08:55:29 <bhill2> https://tools.ietf.org/html/draft-hoffman-trytls-02
08:55:42 <dveditz> bhill2: is it worth taking a moment to consider interactions with other mechanisms such as various opportunistic encryption mechanisms
08:55:59 <dveditz> ... not sure how much status this has other than "crazy idea"
08:56:07 <dveditz> mnot:  haven't heard much talk about it, just an idea
08:56:15 <dveditz> mkwst: expired in october, right?
08:56:34 <dveditz> rbarnes: there was strong resistant to doing anything fancy in dns like this because of the last-mile problems
08:57:00 <dveditz> mnot: there are people in ietf very enthusiastic about opportunistic encryption and don't understand the resistence
08:57:36 <dveditz> bhill2: an http header isn't apropriate for upgrading other protocols like IMAP or SNMP
08:58:15 <dveditz> ... ignoring last mile problems, if we magically know some domain wants to be upgraded what do we do?
08:58:56 <dveditz> axel: would upgrade impact currently unreachable URLs like chrome:// or about:
08:59:13 <dveditz> bhill2: this wouldn't impact other URL types
08:59:26 <dveditz> mkwst: the spec covers only http: and ws:, nothing else
09:00:28 <dveditz> bhill2: back to the previous questions... do we think it's appropriate for a web browser to accept signals not through the web channels to get this information
09:00:58 <dveditz> mkwst: we have this already, the hsts pre-load list, so using other sources (if we trust the mechanism) seems reasonable
09:01:38 <dveditz> bhill2: is thre a need to define the order of operations for all these different things so a new specification can define where in the process it is injected
09:02:33 <dveditz> mkwst: we currently have this in fetch. I have poked Annevk when I've needed hooks added to the fetch algorithm. adding steps to the fetch alg seems like the right general thing to do for this
09:02:41 <mkwst> https://fetch.spec.whatwg.org/#main-fetch
09:03:23 <dveditz> bhill2: that wraps up that topic, taking a quick break and then we can introduce new people and have a more freeform discussion of upgrading the web
09:23:54 <dka> dka has joined #webappsec
09:25:40 <mnot> mnot has joined #webappsec
09:28:25 <wseltzer> Topic: Securing the Web
09:29:18 <yan> yan has joined #webappsec
09:30:11 <dveditz> wseltzer: sorry, I can do it if no one else steps forth
09:30:14 <wseltzer> -> https://github.com/w3c/webappsec/blob/master/admin/100_percent_https_roadmap.md 100% HTTPS: Roadmap for the entire Web
09:30:35 <dveditz> <missed some>
09:31:06 <rbarnes> rbarnes has joined #webappsec
09:31:09 <dveditz> bhill2: I interested in places where WASWG and TAG and cooperate. specs, social, political... let's put it all on the table
09:31:43 <dveditz> slightlyoff: the TAG can make more sweeping statements on what's good and bad, would be good to have WASWG backup on @@
09:32:21 <dveditz> mkwst: from my perspective it would be good to understand what we can do in the browser to make it easier for developers to amek this switch. upgrade is one, I dont know if there are others
09:33:06 <wseltzer> q+
09:33:11 <dveditz> bhill2: WASWG can created technical specs, can do reviews, harder for us to "set policy" for other areas in w3c in terms of mandatory https and nuances in their specs
09:33:21 <rbarnes> 1?
09:33:23 <rbarnes> q?
09:33:28 <Zakim> Zakim has joined #webappsec
09:33:31 <dveditz> ... the TAG is in a better position as an elected body to make some of those statements
09:33:52 <dbaron> q+ wseltzer
09:33:57 <dveditz> ... what is the security model of the web platform and what will advance the platform
09:34:04 <mnot> q+
09:34:15 <dveditz> ... feature parity with mobile platforms which have a very different model
09:34:28 <dka> q?
09:34:30 <dka> q+
09:34:33 <dbaron> ack wseltzer
09:34:52 <dveditz> wseltzer: from the w3c perspective these groups are good places to help us know where the web should be and how we can get there
09:35:10 <dveditz> ... give pushes to those who have not yet realized their customers are demanding greater security
09:35:34 <dveditz> ... we've also been talking about stepping up the web security interest group to fill in some of those guidance pieces to users and developers
09:35:45 <dveditz> ... all these pieces coming together are very helpful
09:36:09 <dbaron> ack mnot
09:36:30 <dveditz> mnot: that sounds good. the focus on making https easier to use is good, lots more to do there
09:36:49 <dveditz> ... we haven't talked much about securiting http, that's a controversial topic
09:37:16 <dveditz> ... getting parity with https on http. if we want to sacrifice some of those guarantees that's where we get controversy. would love to hear that play out
09:37:27 <dveditz> ... to take into our discussion with TBL later in the week
09:37:51 <dveditz> bhill2: worth discussing in this group whether it's possible to do in some way
09:38:13 <dveditz> mnot: there's opportunistic encryption in httpbis, with at least one browser vendor interested in it
09:38:36 <dveditz> ... feedback we've heard is that subsetting those https guarantees is harmfull. is there any subset that would be useful?
09:39:07 <dbaron> ack dka
09:39:17 <dveditz> ... our customers are interested in http/2 but pushback about switching to https. you explain it and they're eventually OK
09:40:20 <dveditz> dka: when I go out and talk to developers at conferences about the move to https, people get interested in the possibility of a "secure http". maybe they're not thinking things all the wqay through, but the easier migration is interesting to them
09:41:21 <dveditz> ... As far as the conceptual model goes, web vs mobile platforms is that you have the user agent enforcing rules as a trusted 3rd party on the web
09:41:35 <dveditz> ... this came up on edgeconf in the discussion about "dropping the lock"
09:42:03 <mnot> q+
09:42:20 <dveditz> ... one of the things I talk about is that the web has a visible indication of security. I don't know if the visual indicator is as important as the concept that the neutral rd party is enforcing
09:43:13 <dveditz> yan: I don't have much to add to what mark said except to agree opportunistic encryption is controversial
09:43:15 <wseltzer> ack mnot
09:43:41 <dveditz> mnot: trying to channel ekr, users don't know or care about the lock...
09:43:54 <mkwst> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure, btw.
09:44:05 <dveditz> dka: when I was talking about the lock that was just a prompt to me thinking about the role the UA plays vs a native application
09:44:49 <dka> q?
09:44:51 <wseltzer> q+
09:44:52 <dbaron> q+
09:45:04 <dveditz> mnot: ... user experience in these discussions is a red herring. if you have secure http you always have the possibility of a downgrade attack
09:45:36 <wseltzer> q-
09:45:38 <dveditz> wseltzer: our goal is to serve as many of these users as we can, the ones who don't know what a lock is but want security, and those who would prefer "no web" to an insecure one
09:45:40 <dka> q+ to mention certs
09:46:09 <dveditz> dbaron: I was wondering about partitioning storage, cookies being separate for secure and insecure, is that an obstacle to migration?
09:46:16 <wseltzer> ack db
09:46:30 <dveditz> mkwst: yes, that's an obstacle. don't know how major, but it is an issue that comes up. a challenge
09:47:01 <dveditz> dbaron: could secure-http be helpful in that migration, where each site could have its own flag day
09:47:25 <dveditz> mkwst: would it be useful for a site to send a header/signal to say "please upgrade my insecure crap"
09:47:39 <dveditz> mnot: but it's not "his", it's the other origin's, that might not actually be his
09:48:22 <dveditz> bhill2: unfortunately the alternative is you suck everything out of one window and up to the server or post message to the "other" origin to convert.
09:48:36 <dveditz> ... that's no less secure than the proposal
09:48:53 <dveditz> mkwst: a one time conversion that neuters the data in the http origin
09:49:20 <rbarnes> q+
09:49:28 <dveditz> ... forbes.com proves everything -- one site is not the same as the other one
09:49:51 <rbarnes> q-
09:50:22 <dveditz> freddyb: maybe if we have hsts maybe we could in those sites suck over the data from http
09:50:29 <dveditz> ... it would have to be opt-in
09:50:52 <dveditz> mkwst: but the http: site could have bogus poisoned data populated by a local wifi attack.
09:51:34 <dveditz> dka: when it comes to flag days, one topic in the STRINT workshop is that cert warnings are broken and when there's an invalid cert users are encouraged to click through because of social factors
09:52:09 <dveditz> ... such as the apple employee going to their health care and called them and was told "that error's OK, that's how you know it's the right site"
09:52:51 <dveditz> bhill2: finding more progress through data driven research about populations rather than us smart people sitting in a room trying to imagine what users will/would do.
09:53:16 <dveditz> mkwst: apf has done research and data driven results.
09:53:25 <wseltzer> http://research.google.com/pubs/AdrienneFelt.html
09:53:44 <dveditz> bhill2: hsts does some of that... if there's an invalid cert give users no recourse, no click through
09:54:12 <dveditz> ... I'm not interested in making it easier to bypass warnings
09:54:44 <dveditz> ... the evidence I've seen is that (hard thing to measure) when you make it harder the abuse goes away but when you make it easier the abuse comes back
09:54:54 <dveditz> ... making it harder pushes the fraud to another part of the system
09:55:06 <dveditz> mnot: do you think UX is in scope for this group in any way?
09:55:14 <dveditz> bhill2: maybe a little?
09:55:27 <slightlyoff> q?
09:56:22 <wseltzer> q+
09:56:24 <dveditz> slightlyoff: I have concern about putting UI in scope for groups that are making specs. Chrome team has a principled objection to standardizing UI in W3c, doesn't allow us to adapt to user needs and changing situations
09:56:31 <bhill2> ack dka
09:56:31 <Zakim> dka, you wanted to mention certs
09:56:46 <slightlyoff> more importantly, we understand that things are _likely_ to change in UIs
09:56:49 <dveditz> wseltzer: I have zero interest in standardizing broken UI
09:56:52 <freddyb> ack wseltzer
09:57:18 <slightlyoff> and as a result, we need the flexibility to do better, improved UI without breaking conformance
09:57:34 <slightlyoff> Adrienne's research is proof of this principle
09:57:51 <dveditz> JonathanKingston: it's good to suggest consistent behavior between browsers in certain cases, even if the appearance is different
09:58:16 <wseltzer> https://github.com/w3c/webappsec/blob/master/admin/100_percent_https_roadmap.md
09:58:18 <dveditz> bhill2: this outline is kind of brainstormy
09:58:35 <dveditz> ... trying to avoid flag days where we chop off parts of the internet that haven't converted
09:58:56 <dveditz> ... URLs as data, urls as stable identifiers
09:59:22 <dveditz> ... urls that start http:// might be a stable identifier, could be hard to go through a codebase and just use sed to convert them all
09:59:49 <dveditz> ... if we had a system that supported all the capabilities of https in http
10:00:15 <dveditz> ... an http application can pull in http resources but not from an https instance of that application
10:00:51 <dveditz> ... starting assumptions: 1) users can't deal with nuanced security models. secure or not secure is about it
10:01:32 <dveditz> ... site authors would rather be completely insecure than partially secure where users see an indication of "not secure"
10:01:41 <dveditz> dka: but we just said users don't see indicators
10:02:03 <dveditz> bhill2: maybe the vast majority don't care, but a big enough minority that do notice and do care
10:02:20 <dveditz> dka: but that minority might be smart enough to know the diff between fully secure and partially secure
10:02:46 <dveditz> mkwst: I would be upset if browsers were making the assertions you were just making [NSA-proof vs pretty secure]
10:03:12 <dveditz> ... chrome is looking to see if we can get rid of the lock. tell users when they're insecure, not say when they're secure
10:03:41 <dveditz> dka: if we're trying to strengthen the encryption and make more things encrypted, isn't there a tension there?
10:04:08 <dveditz> mkwst: the browser can make a limited number of assertions. I'm talking to a server who claims to be XXX and the connection is encrypted
10:04:32 <dveditz> ... anything short of that should be a warning.
10:04:34 <wseltzer> s/claims to be XXX/is authenticated/
10:05:26 <dveditz> bhill2: even if I'm able to understand those nuances the effort to make subtle distinctions is just not worth it
10:05:43 <dveditz> ... big PITA to figure out if I should worry about this yellow triangle thing
10:06:11 <dveditz> axiom 2) not subsetting the guarantees of https (CIA)
10:06:32 <dveditz> [please see notes]
10:07:22 <dveditz> bhill2: [see notes The Invariants]
10:08:53 <dveditz> ... tranquility property is especially interesting
10:09:02 <dveditz> [No Read Up]
10:09:20 <dveditz> [No Read Down/No Write Up]
10:10:13 <dveditz> [No Write Down]
10:11:31 <dveditz> ... not enforced by today's browsers
10:15:41 <dveditz> [Tranquility]
10:16:08 <dveditz> ... doesn't get talked about a lot. application doesn't change from secure to insecure in the middle of a transaction
10:16:26 <dveditz> ... browser will enforce the concept of tranquility on this transaction
10:17:19 <dveditz> ... becomes an issue in any kind of scheme where downgrade is possible
10:17:43 <dveditz> ... such as an http app opportunistically upgraded, but then the next request fails and falls back to insecure
10:19:26 <dveditz> ... going back to the "open data" application example. code is loaded over https but some of the data is from insecure sources
10:19:56 <dveditz> ... could be perfectly safe, but the browser can't really tell the difference
10:20:24 <dveditz> ... no way for the app to say "I'm loading over https but don't show any security guarantees so that I don't get downgraded later"
10:20:52 <dveditz> mnot: as a user, if I type in https or hover over a link and see https:// the contract is already made
10:21:48 <dveditz> ... having https: mean "secure, unless the server doessn't want it to be" gives me the heebie-jeebies
10:22:04 <dveditz> ... often the server has one threat model in mind but the user has a different model in mind
10:22:17 <dveditz> wseltzer: and we may be imposing a model that matches neither
10:23:01 <dveditz> bhill2: currently mixed content blocks before hsts upgrades happen. we agreed to this yesterday
10:23:43 <dveditz> mkwst: I think it will be difficult to change this behavior
10:25:08 <dveditz> ... I'm skeptical we will come to another decision if we talk it through again
10:25:24 <dveditz> bhill2: what does it mean to be able to upgrade some of these
10:25:43 <dveditz> ... we have the upgrade draft to update insecure resources.
10:26:12 <dveditz> ... csp form-action can help some, upgrading navigations can help
10:26:20 <yan> q?
10:26:20 <dveditz> ... we have issues with existing local data
10:26:23 <yan> q+
10:26:56 <dveditz> ... what if I can upgrade entirely to https and never send any data in the clear
10:28:09 <dveditz> mkwst: would I be treating a page differently if I navigate it vs framing it?
10:28:22 <dveditz> ... that would be complicated
10:28:50 <dveditz> bhill2: how do we handle tranquility, what if we're assembling component parts and a later resource doesn't upgrade successfully?
10:29:43 <dveditz> ... new primitives: opportunistically secure without promising tranquility. could be a header required on every resource, or domain-wide flag
10:29:57 <dveditz> ... browsers wouldn't make any guarantee including not showing the 's' in https:
10:30:00 <rbarnes> for the record, this idea that we might selectively discard tranquility makes me really uncomfortable
10:30:06 <dveditz> ... what does it mean for the same origin policy
10:30:43 <dveditz> [see notes on details for new SOP and data flow rules]
10:31:14 <dveditz> mkwst: what's the problem we're trying to solve? seems the concern TBL and others have is that everyone has to do work for us to be able to grab their data
10:31:41 <wseltzer> [one problem solved by optimistic upgrade is some protection against the passive eavesdropper, but not an active attacker]
10:31:43 <dveditz> ... these proposals are similar to today's model except no one needs to change the scheme. doesn't seem like the problem we're being asked to solve
10:32:08 <dveditz> ... still blocks us from moving to https, worse makes us weaken the guarantees that we would otherwise give
10:32:33 <dveditz> ... this doesn't seem to solve the problem (still requires everyone else to do work) and if it does it does by reducing rather than increasing security
10:33:14 <dveditz> bhill2: the web exists out there with lots of http: links out there. What if LetEncrypt rolls out and everyone upgrades Apache and is magically https guaranteed
10:33:50 <dveditz> mkwst: if you're replacin the server anyway then you can add redirects
10:34:11 <dveditz> bhill2: but that violates tranquility ... I have to go out unencrypted first then get upgraded
10:34:32 <dveditz> ... what if I can try https first and get a better indication that we can do that?
10:37:48 <dveditz> ... the insecure web can interact with itself as a remnant and the general case is everything else can be upgraded
10:37:54 <mnot> q+
10:38:44 <wseltzer> ack yan
10:39:27 <dveditz> yan: a side comment. a lot of these upgrade things assume http/https are equivalent. HTTP Everywhere shows that's really not true. Lots of special case rules
10:39:43 <dveditz> mkwst: I understood a lot of those rewrites were because of cert errors
10:40:11 <dveditz> yan: that's one of the cases.
10:40:42 <dveditz> mnot: I want to know how upgrade-insecure-request goes and adoption rates. will it help? will it not be adopted?
10:41:02 <dveditz> ... I worry people won't understand, or understand just enough to abuse it
10:41:09 <dveditz> ... and not understand the tradeoffs being made
10:41:25 <dveditz> ... let's let upgrade-insecure bake for a while first
10:42:10 <dveditz> bhill2: who wants their name associated with the Why We Can't Have Nice Things documents
10:42:39 <dveditz> axel: http/2 solves part of the problem doesn't it?
10:43:37 <dveditz> ... Chrome warns me "this is a protential phishing site". why doesn't it have a collection of rules for "it's OK to use https on this site"
10:44:01 <dveditz> ... would it make admins lazy by helping them too much
10:44:44 <wseltzer> [the flip side of invisible upgrades is invisible failures]
10:44:49 <dveditz> yan: no... I used to be the maintainer of https everywhere. It was constantly breaking, site changed all the time
10:45:10 <dveditz> yan: would be hard to incorporate into browsers for the general public
10:45:37 <dveditz> mkwst: we have a mechanism by which sites can opt into this -- hsts preload lists
10:46:01 <dveditz> ... that puts it in the control of the site operator, something like https everywhere takes the control away
10:46:17 <dveditz> axel: I used this for years and haven't experienced things breaking
10:46:21 <dbaron> q+
10:46:22 <bhill2> q+
10:46:23 <mnot> q+
10:47:16 <dveditz> ... when browsers say "I won't give you access to this powerful feature unless you're secure" doesn't that conflict with saying site's should be in control
10:48:22 <dveditz> mkwst: the definition of "not breaking" is not simply "the site works". The site might not be ready to switch, maybe they know they're releasing a new application that doesn't work over https
10:48:56 <dveditz> ... for powerful features we prioritize users over the sites, but we shouldn't prioritize the browser itself over the site
10:49:29 <dveditz> ... in some cases taking control from sites is justified, but I don't think this is one of those cases
10:50:08 <dbaron> ack mnot
10:50:17 <bhill2> ack mnot
10:50:24 <bhill2> ack dbaron
10:51:00 <dveditz> mnot: the akamai folks hate https everywhere because https everywhere "fixes" people who have not bought certs
10:51:16 <dveditz> (some of the akamai folks)
10:51:42 <dveditz> dbaron: another factor is we don't want browsers to be gatekeepers. we want people to be able to publish on the web on an equal footing
10:52:14 <dveditz> ... things like the anti-phishing you mentioned is kind of a step away from that, but we have a set of known bad behaviors
10:52:16 <mnot> s/hate/dislike/
10:52:27 <dveditz> s/folks hate/folks dislike/
10:53:31 <dveditz> ... we've talked of lots of problems of silent automatic upgrades (sites taht don't match)
10:53:33 <bhill2> ack bhill2
10:53:48 <dveditz> wseltzer: difference between users saying (via an addon) and browsers just doing it on their own
10:54:19 <dveditz> bhill2: server operators need to opt in, or at least, doing so would help us know better when it's safe to do it
10:55:31 <dveditz> JonathanKingston: would you hard fail if securit guarantees were not maintained
10:55:54 <dveditz> bhill2: sometimes yes and sometimes no, depending on whether the site has opted into/out of Tranquility
10:56:54 <dveditz> ... you might have an upgraded site that has opted out of tranquility, but some other site that has not could use resources automatically upgraded from that site without breaking their own guarantees
11:03:58 <wseltzer> [brad draws on the whiteboard]
11:06:23 <wseltzer> [two state differences: lock/no lock; secure+tranquil/no-tranquil]
11:07:04 <wseltzer> mnot: right now, alt-services is non-blocking, so you're still sending lots of data in the clear
11:07:21 <wseltzer> ... we could come up with a blocking alt-svces, but it would be something different
11:08:31 <wseltzer> [lunch]
11:08:35 <wseltzer> rrsagent, make minutes
11:08:35 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/14-webappsec-minutes.html wseltzer
11:40:51 <dka> dka has joined #webappsec
11:42:36 <rbarnes> rbarnes has joined #webappsec
11:44:41 <yan> yan has joined #webappsec
11:47:27 <mnot> mnot has joined #webappsec
11:47:56 <wseltzer> [resume]
11:48:32 <mkwst> scribenick: mkwst
11:48:46 <mkwst> bhill2: agenda bashing!
11:48:52 <mkwst> dka: Uhhh.
11:49:04 <mkwst> dka: What would you like the TAG to talk about tomorrow?
11:49:13 <mkwst> dka: (Ha ha.)
11:49:23 <mkwst> dka: But seriously, what can the TAG do?
11:49:46 <mkwst> bhill2: Checking in on specs yesterday. MIX. SRI. Priviliged contexts.
11:49:55 <mkwst> dka: Outreach mechanism to web developers?
11:50:10 <mkwst> ... Move to HTTPS, secure contexts, etc.
11:50:29 <mkwst> ... Is there some coordinated effort we could make within W3C to get the word out?
11:50:44 <mkwst> ... At Edgeconf, we talked to an audience of developers who kinda know what's going on.
11:51:09 <mkwst> ... In Transylvania, this wasn't the case.
11:51:22 <mkwst> ... How do we address the awareness gap?
11:51:41 <mkwst> ... Working groups need to take some responsibility for advocacy.
11:51:51 <mkwst> ... TAG runs outreach events, what can WGs do?
11:52:12 <mkwst> JonathanKingston: Hurdles to adoption (CSP, for instance).
11:52:19 <mkwst> ... How do we get the message out?
11:52:37 <mkwst> ... Could carry on bashing out the HTTP->HTTPS discussion.
11:52:45 <mkwst> ... Lock icon, broken locks.
11:53:05 <mkwst> dveditz: Don't know concrete plans, but Chrome and FF have talked about degrading the HTTP iconography.
11:53:13 <mkwst> ... Negative for insecure rather than positive for secure.
11:53:30 <mkwst> slightlyoff: Discussion of a place folks could go to understand the landscape.
11:53:35 <mkwst> ... Statistics. Trends.
11:53:47 <mkwst> ... HTTPArchive? No good public place to centralize this information.
11:54:05 <mkwst> ... TLS needs a posse.
11:54:15 <mkwst> rbarnes: areweencryptedyet.com?
11:54:18 <mkwst> slightlyoff: who's registering it?
11:54:31 <mkwst> rbarnes: How do powerful feature restrictions fit into migrations.
11:54:32 <mkwst> ...
11:54:47 <mkwst> ... Process statements enforcing requirements onto new documents?
11:55:14 <mkwst> ... Would be useful to have clear discussion for requirements, use cases, etc. that are broken today by TLS.
11:55:20 <mkwst> mnot: Whatever Dan said.
11:55:35 <mkwst> ... Useful to continue with Brad's discussion.
11:55:45 <mkwst> ... Document that explains why these decisions aren't easy ones.
11:55:57 <mkwst> ... Don't understand how browser's power is being used.
11:56:23 <mkwst> ... Roles of the TAG are to do advocacy, talk about policy. Feedback about how they could help.
11:56:38 <mkwst> freddyb: Powerful features is interesting.
11:56:48 <mkwst> ... What is a powerful feature? Upcoming API integration.
11:56:54 <mkwst> dveditz: Deprecation?
11:57:28 <mkwst> francois: What about people that don't want to migrate? What do we do with that legacy content?
11:57:34 <mkwst> dveditz: Right. Abandoned sites, for instance.
11:57:42 <mkwst> ... TBL's concern involves those sites.
11:57:54 <mkwst> ... Using data from abandoned sites === lost data.
11:58:10 <mkwst> dbaron: Powerful features is interesting.
11:58:35 <mkwst> ... What are the barriers to folks migrating today.
11:58:45 <mkwst> ... What problems are hardest for them, what can we do to fix those?
11:58:49 <mkwst> ... Is there a list of those things?
11:59:18 <rbarnes> firefox historical telemetry on HTTPS usage, by pageview https://ipv.sx/telemetry/ssl-page-historical.html and by transaction https://ipv.sx/telemetry/ssl-tx-historical.html
11:59:24 <mkwst> wseltzer: Where do we want to be giving guidance to other groups?
12:00:07 <mkwst> ... Interested in whether we get to a point to where we can distinguish between user needs that we address. Thinking about sophisticated users with specific concerns. Distrust local network, censoring proxy, etc. Escaping those.
12:00:37 <mkwst> bhill2: How do we get to the end state, what are the barriers, how can we encourage.
12:00:52 <mkwst> dveditz: Nothing new to add.
12:01:16 <mkwst> francois: Some folks that come from various orgs. Akamai, for instance, might have specific problems that we could help solve.
12:01:33 <mkwst> ... Mike comes up with specs that help Google, perhaps others have distinct needs?
12:01:57 <mkwst> dveditz: Concerned most about legacy.
12:02:10 <mkwst> ... How we can help sites that want to use legacy data. Is there some way to allow them to do so?
12:02:29 <mkwst> ... "No, really, this is just anonymous data."
12:03:01 <mkwst> ... -1 powerful features. we agree that the concept is good, but individual feature decisions shouldn't be made by us.
12:03:26 <mkwst> dveditz: we can all individually have opinions, probably agreement on that, might want to lobby on behalf.
12:04:09 <mkwst> mkwst: Make the TAG make groups do things. Way around charter objections.
12:05:36 <dveditz> mkwst: was disappointed last week at edgeconf that all we talked about was https. once a site has moved to https it's not done, there's more to do
12:06:03 <dveditz> ... alex talked about storage isolation, are there other types of isolation that would be useful to provide for web developers
12:06:21 <dveditz> ... to reduce their attack surface or exposure to risk. Future looking planning
12:06:38 <dveditz> dka: would the summary of that be "now we have TLS everywhere, what now?"
12:07:04 <dveditz> mkwst: at Google we're mostly(?) all TLS, but we're not done. what more do we need to do
12:07:22 <mkwst> yan: What if you want to migrate, but subresources won't migrate.
12:07:26 <mkwst> ... Ads.
12:07:36 <mkwst> ... There's possibly more we can do in the spec space.
12:07:39 <mkwst> slightlyoff: Example?
12:08:02 <mkwst> yan: Stronger SRI on the resource, opportunisticly encrypted? Perhaps that's enough to not block it. Strawman. :)
12:08:23 <mkwst> dveditz: Harder to use SRI now, requires CORS.
12:08:48 <mkwst> wseltzer: Deprecate CORS.
12:08:53 <mkwst> ... Seems like an anti-pattern.
12:08:57 <mkwst> slightlyoff: Why?
12:09:15 <mkwst> wseltzer: Website has to state that it wants to be public, rather than the other way around. Opposite of the webby approach.
12:09:41 <mkwst> dveditz: Aspect of CORS is positive: enable one party to do something new, but only if the other party opts in. 'document.domain'
12:10:22 <mkwst> ... Imposition is bad. Maybe CORS isn't the best, but it's safer than potentially breaking things.\
12:10:32 <mkwst> mnot: Totally the right approach. When surprise is possible, opt-in is better.
12:10:45 <mkwst> ... The way that CORS works on the wire might be optimized, but the fundamentals are fine.
12:11:00 <mkwst> ... To the browser folks: can you imagine trading latency for a new security option?
12:11:20 <mkwst> rbarnes: To a degree that it's acceptable, it would depend on where the latency accrues.
12:11:33 <mkwst> mnot: Just first time I go to a website? Add a round-trip for first visit?
12:11:37 <mkwst> rbarnes: No hard answers!
12:11:43 <mkwst> mnot: Sure. Fuzzy answer?
12:11:50 <mkwst> rbarnes: Maybe?
12:12:04 <mkwst> dveditz: Reduce latency with QUIC/SPDY; some vendors would say no.
12:12:26 <mkwst> dbaron: how much latency, how much security?
12:12:49 <mkwst> rbarnes: accrue latency to insecure sites?
12:13:15 <mkwst> ... Open TLS connection, only open insecure if that fails.
12:14:46 <mkwst> bhill2: what are we voting for?
12:15:01 <mkwst> mnot: The thing on the board that bhill2 drew. Possible HTTP->HTTPS thing.
12:15:10 <mkwst> bhill2: What are the concrete problems?
12:15:28 <mkwst> [rbarnes is writing on the board]
12:15:34 <mkwst> [because bhill2 told him to]
12:16:30 <mkwst> [still writing on the board]
12:19:14 <mkwst> Problems:
12:19:20 <mkwst> * Changing links
12:19:27 <mkwst> * Subresources having to upgrade
12:19:31 <mkwst> * Data in storage
12:19:36 <mkwst> * Certificates
12:19:41 <mkwst> * Different content (forbes)
12:19:46 <mkwst> * UX incentives
12:19:52 <mkwst> * SNI / IP addresses
12:20:03 <mkwst> * Administration, key management
12:20:23 <mkwst> * Debugging (wireshark, telnet, etc)
12:22:13 <mkwst> * anonymity
12:22:43 <mkwst> bhill2: Things most interesting for us in this room to work on?
12:23:09 <mkwst> ... formal objections to working on UI/UX in this group. Also already in flight.
12:24:11 <mkwst> ... Debugging is interesting for "secure contexts"
12:24:29 <mkwst> ... SNI is probably outside our scope.
12:24:34 <mkwst> ... Anonymity is out of scope.
12:25:47 <mkwst> So we're left with:
12:25:50 <mkwst> * Changing links
12:25:56 <mkwst> * Subresource having to upgrade
12:26:00 <mkwst> * Data in storage
12:26:09 <mkwst> * Different content (forbes)
12:26:31 <mkwst> mnot: Different content is interesting. TLB seems to agressively think that we shouldn't allow that.
12:26:41 <rbarnes> fun fact: i filed a bug to fix "cypher" in NSS, and found that their API guarantees prevent fixing it
12:27:16 <mkwst> dveditz: Someone said that Google's internal study said 97% of HTTP/HTTPS were similar (not subresource, just top-level, etc.).
12:27:32 <mkwst> mnot: One approach is to assert that they're the same (HSTS).
12:27:33 <bhill2> rrsagent, make logs world
12:27:40 <mkwst> ... Other approach is is to assert that they're not the same
12:27:51 <mkwst> yan: Which is "being forbes.com"
12:28:03 <rbarnes> Forbes: 1
12:28:11 <mkwst> mnot: Making it opt-out seems "not cool".
12:28:39 <mnot> mnot has joined #webappsec
12:28:51 <mkwst> bhill2: HSTS is like an opt-in already.
12:29:12 <mkwst> dveditz: Would it be valuable to have a weaker assertion than HSTS?
12:29:27 <mkwst> slightlyoff: 99.7%. Not 97%.
12:29:58 <mkwst> mnot: HSTS adoption is low for top 10k sites.
12:30:23 <mkwst> slightlyoff: 99.7 includes the things that Google can find. Images, PDFs, top level documents. Not scripts, etc. Things that are in search.
12:30:29 <mnot> http://trends.builtwith.com/docinfo/HSTS
12:30:31 <mkwst> ... Adjust error bars accordingly.
12:31:02 <rbarnes> dbaron: fwiw, >90% of HTTPS transactions are TLS 1.2
12:31:50 <dbaron> rbarnes, yeah, but there are a bunch of sites I depend on that aren't... (though I didn't have that many problems with allowing only 1.2 and 1.1)
12:31:56 <mkwst> slightlyoff: [hedges wildly]
12:32:08 <rbarnes> dbaron: sounds like your problem :)
12:32:27 <mkwst> ... Doesn't include sites that don't have HTTP _and_ HTTPS. Doesn't include sites excluded via robots.txt.
12:32:35 <mkwst> bhill2: As percentage of traffic, small number?
12:33:18 <mkwst> mnot: What do we do in the address bar is one question. What we do for migration is another?
12:33:38 <mkwst> ... What's the plan here? Open 443 first? See if you get a handshake?
12:34:13 <mkwst> [discuss of latency; races]
12:34:35 <mkwst> ... timeouts, downgrade, dos.
12:36:17 <mkwst> mkwst: None of this is interesting unless there's hard failure somewhere.
12:36:28 <mkwst> [UC browser appeared somehow]
12:36:50 <mkwst> bhill2: that's the core of this proposal. outlining those situations in which hard-failure is appropriate.
12:37:01 <mkwst> ... not lots of latency outside the first request.
12:37:43 <mkwst> rbarnes: connection reuse might mean that h/2 is a net decrease in latency.
12:37:58 <mkwst> mnot: and coalescing.
12:38:46 <mkwst> bhill2: another problem is involuntary upgrade.
12:38:46 <mkwst> ...
12:38:56 <mkwst> ... I haven't bought the fancy Akamai package yet.
12:39:03 <mkwst> ... Can't serve HTTPS to everyone, etc.
12:39:23 <mkwst> rbarnes: mechanism in H/2 for disclaiming coalescing.
12:39:46 <mkwst> dveditz: another type of involuntary upgrade. framing with upgrade-insecure-requests.
12:40:03 <mkwst> ... Possibly problematic. Might be useful to do this as an attack.
12:40:11 <slightlyoff> areweencryptedyet.org has been registered :-)
12:41:19 <mkwst> [discussion of frame-ancestors, origin header, advocacy]
12:41:30 <mkwst> dveditz: would it be helpful if we didn't block credentialless xhr.
12:42:24 <mkwst> [discussion of mixed content]
12:45:14 <mkwst> [sorry, mkwst was talking]
12:45:38 <mkwst> bhill2: Can introduce non-tranquil HTTPS, remove it later to address the issue of upgrading content.
12:46:36 <mkwst> rbarnes: sounds to me less like non-tranquil HTTPS, but like HTTP that was loaded over TLS when you could.
12:47:20 <mkwst> bhill2: would do that to get telemetry on what else is going on, how it feels to live in the world where everything is loaded securely.
12:48:37 <mkwst> mkwst: we should make people feel bad about sending insecure content.
12:48:53 <mkwst> rbarnes: order of operations: first do brad's thing, then make people feel bad about doing it.
12:49:29 <mkwst> ... two models: for a given application, how do you get into one of those two states?
12:49:48 <mkwst> ... how do we determine whether TLS or TPC, how does the browser determine which security policy to apply.
12:49:59 <mkwst> ... currently tied together.
12:50:09 <mkwst> ... brad's proposal decouples scheme from that.
12:50:23 <mkwst> ... maybe allow one more combination of states: load over TLS, but treat as low-sec.
12:50:33 <mkwst> bhill2: yes, as a transitional state.
12:53:56 <mkwst> mkwst: I've missed something, explain?
12:54:01 <mkwst> bhill: [ explains ]
13:04:48 <mnot> Just to make sure people are aware: https://httpwg.github.io/http-extensions/encryption.html
13:04:50 <slightlyoff> dka: further inconveniences: sed -i doesn't actually fix things; as likely to break content  = (
13:07:45 <slightlyoff> mnot: so then like 1/3'd of an ad?
13:09:13 <rbarnes> rbarnes has joined #webappsec
13:15:08 <dka> dka has joined #webappsec
13:25:19 <wseltzer> bhill: should we add "migrate insecure data" to HSTS as a one-time option?
13:25:49 <wseltzer> mkwst: we should do it as a separate header, with requirements on HSTS longevity and @@
13:26:14 <wseltzer> ... do we need more protection against bad data?
13:26:25 <wseltzer> ... either manual, or event-triggered?
13:26:39 <wseltzer> i/should we add "migrate/Topic: Data in storage
13:27:12 <wseltzer> mkwst: it seems we need remove data from http, replace or merge
13:27:26 <wseltzer> ... the problem with a read API is differences in data storage mechanisms
13:27:48 <wseltzer> dveditz: exposing cookies would be problematic because some cookies are explicitly hidden from scripts
13:28:47 <wseltzer> mkwst: use case is "I've been working for a while offline and now the site upgraded to HTTPS"
13:29:06 <wseltzer> ... cookies don't matter, but localstorage, indexdb, sql
13:30:04 <wseltzer> freddyb: permissions?
13:30:11 <wseltzer> mkwst: probably not
13:30:35 <wseltzer> slightlyoff: a note of caution - sites will have to test pretty stringently
13:30:46 <wseltzer> ... whereas they could do a post-message
13:31:07 <wseltzer> bhill2: but once they've set HSTS, they lose the HTTP access
13:32:36 <wseltzer> [more discussion whether this is a sufficiently common use case to worry about]
13:36:00 <dveditz> slightlyoff: is the reason people want to use hsts preloading because we don't provide another way to do it?
13:36:25 <dveditz> ... like there was no way to set the header at first?
13:36:46 <dveditz> mkwst: that was HPKP, we always had the header for hsts. preloading just solves the initial window vuln
13:37:38 <dveditz> bhill2: do we discourage people from using hsts by not having a transfer mechanism, or is it small enough number of sites to not worry about
13:38:17 <dveditz> francois: it's just sites that have offline data that need to take a slower translation path, and they can use upgrade-insecure as an interim step
13:38:43 <dveditz> ... should our group create a guide for people converting their sites to https?
13:39:04 <dveditz> mkwst: yes, we should do that, and showcase the various specs we have produced that can help them
13:39:43 <dveditz> ... we currently have the TAG, this group, and the web security IG (which hasn't been doing much lately)
13:40:09 <dveditz> ... that could do something like this. Someone should, maybe it should be us
13:40:50 <wseltzer> q+
13:41:17 <dveditz> ... I was unhappy with our recent chartering process that had members in this room objecting to our group making recommendations
13:42:00 <dveditz> wseltzer: interest groups don't have to be "black holes". they can bring in invited experts and have fairly broad leeway
13:42:15 <dveditz> ... I invite people to help revitalize the security interest group
13:42:38 <wseltzer> q-
13:45:29 <wseltzer> ACTION: JonathanKingston to write Same-Origin documentation
13:45:29 <trackbot> Error finding 'JonathanKingston'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
13:46:45 <wseltzer> bhill2: I will semi raise my hand to write up "Why we can't have nice things?" why upgrades are complicated, origin model, etc.
13:47:45 <wseltzer> bhill2: and that dovetails to evangelism, outreach, education, TAG role
13:49:07 <wseltzer> dka: for publicitly purposes, the press seems to be looking for a package of things with a story
13:50:28 <wseltzer> mkwst: without a good mobile story, without Apple, it's hard to sell the package
13:50:39 <wseltzer> s/sell/tell/
13:51:00 <wseltzer> bhill2: we're close to rec on CSP2, Mix, Powerful Features, SRI
13:51:18 <wseltzer> We can invite Safari to implement
13:51:57 <wseltzer> dka: W3C could do press release, get statements fo support from implementers
13:53:35 <wseltzer> wseltzer: Great. W3C comms would like help in telling the story
13:53:43 <wseltzer> dka: I can help write stuff
13:54:00 <wseltzer> mkwst: CSP2 has implementations in chrome and firefox
13:54:15 <wseltzer> ... formally, we need to republish CR and wait, then move ahead
13:54:27 <wseltzer> bhill2: everyone's on Mix
13:54:33 <wseltzer> ... SRI has ff and chrome
13:56:11 <wseltzer> ... upgrade is pretty close
13:56:17 <wseltzer> ... powerful features needs a test suite
13:56:43 <wseltzer> ... TAG can take it forward
13:56:52 <bhill2> mixed content
13:57:45 <bhill2> referrer policy
13:58:06 <wseltzer> mkwst: referrer policy is in FF, chrome, safari
13:58:11 <wseltzer> ... not sure about IE
13:59:04 <wseltzer> bhill2: "W3C did 6 things" sounds press-worthy
13:59:39 <rbarnes> rbarnes has joined #webappsec
14:03:54 <wseltzer> mkwst: do we need a formal CfC to republish CSP2
14:04:00 <wseltzer> ?
14:04:54 <wseltzer> bhill2: any objections to removing unsafe-redirect and republishing CSP2 as discussed on list?
14:05:09 <wseltzer> ... discussion was open, we heard no objections, and hence
14:05:23 <wseltzer> RESOLVED: Republish CSP2 CR without unsafe-redirect
14:06:14 <wseltzer> mkwst: I'll republish
14:06:27 <wseltzer> mkwst: Was there interest in this group in "clear site data"?
14:06:47 <wseltzer> ... proposal for a header to reset state
14:06:51 <wseltzer> dveditz: secure?
14:06:58 <wseltzer> mkwst: still debate about it
14:07:16 <wseltzer> ... someone said, "if attacker can remove your data, reason to migrate"
14:07:27 <wseltzer> ... fits into scope of charter
14:07:34 <wseltzer> ... attack surface mitigation
14:07:59 <wseltzer> ... e.g., remove data on logout, gplus would like to store data locally, iff they can remove
14:08:42 <wseltzer> ... so providing this header seems good way to mitigate risk
14:08:47 <wseltzer> bhill2: sounds within scope
14:09:10 <wseltzer> mnot: I like it, perhaps option for cookies-only
14:09:40 <wseltzer> slightlyoff: what about the pwnd service worker case, where you want to lock out an old service worker
14:10:04 <wseltzer> ... API missing to prevent writes from existing contexts
14:10:17 <wseltzer> ... this is necessary predicate
14:10:39 <wseltzer> mkwst: sandbox all currently-open windows of that origin, then resume after clear event
14:10:45 <wseltzer> ... where the thread wound up
14:10:51 <wseltzer> slightlyoff: that sounds like good behavior
14:11:35 <wseltzer> mkwst: Great, I'll do it in this group.
14:12:14 <wseltzer> bhill2: I like that spec too, as Facebook
14:12:55 <wseltzer> rbarnes: powerful features, and what to ask the TAG to do
14:13:14 <wseltzer> rbarnes: as a strawman, ask TAG to set minimum security policy across W3C specs
14:13:27 <wseltzer> ... e.g. limitation to secure contexts
14:15:31 <wseltzer> dka: carrot and stick, both "here are some findings" and "here are some people who can help you meet them"
14:15:53 <wseltzer> ... and implied threat of non-approval of Rec if you don't meet them
14:17:24 <wseltzer> mkwst: what do we do with WGs who won't change, such as geolocation?
14:17:45 <wseltzer> dka: stage an intervention, i.e., call them together in the same room at TPAC
14:18:16 <wseltzer> ... if the right people aren't at TPAC, find another opportunity
14:18:39 <wseltzer> rbarnes: also a difference between existing features like geoloc and new things
14:20:24 <wseltzer> ... re advocacy, we can send a stronger message if implemtations are coordinated
14:22:11 <wseltzer> ... so you don't have to look at a chart to know where your feature will be supported
14:24:47 <wseltzer> mkwst: inconsistent implementation is problematic for some features
14:25:11 <wseltzer> ... e.g. nonces, where we have to take care that it doesn't break non-implementations
14:25:15 <mnot> mnot has joined #webappsec
14:27:23 <wseltzer> rbarnes: powerful features, impact on other specs
14:27:32 <wseltzer> mkwst: current spec defines secure contexxts
14:27:45 <wseltzer> ... not much on what a powerful feature is
14:27:52 <wseltzer> ... that's for TAG, others
14:28:42 <wseltzer> mkwst: it woudl be testable if we added an API for "is secure context?"
14:28:56 <mnot> mnot has joined #webappsec
14:29:05 <wseltzer> s/woudl/would/
14:31:26 <wseltzer> http://www.w3.org/2014/Process-20140801/#implementation-experience
14:32:12 <wseltzer> mkwst: feature detection seems like a reasonable thing to want
14:32:31 <wseltzer> slightlyoff: perhaps permissions API
14:32:40 <wseltzer> ... TAG has reviewed and said it isn't done yet
14:32:55 <wseltzer> ... could extend to include secure context detection
14:33:28 <wseltzer> dbaron: the easiest feature detection should be tied to the feature
14:35:17 <wseltzer> rbarnes: I was initially queasy about powerful features because it seemed to imply that some features weren't sensitive
14:35:28 <wseltzer> ... when we want to encourage the entire web to move to secure context
14:35:59 <wseltzer> rbarnes: I'd like to suggest that *all* new things should start from secure contexts
14:38:29 <wseltzer> mnot: give WGs the tools and vocabulary to make good decisions
14:39:04 <wseltzer> mkwst: get people in WG on-board
14:39:48 <wseltzer> mnot: we have Securing the Web finding, we have security/privacy review, we have Powerful Features/Secure Contexts
14:40:24 <wseltzer> rbarnes: IETF will publish a consensus document "things ought to be this way"
14:40:34 <wseltzer> ... groups can then use that as a starting point
14:40:45 <wseltzer> mnot: Securing the Web did put thumbs on the scale
14:40:51 <wseltzer> ... we're starting to explore fingerprinting
14:42:32 <wseltzer> rbarnes: "Secure Contexts" should ref Securing the Web http://www.w3.org/2001/tag/doc/web-https
14:43:48 <wseltzer> mkwst: I worry that the privacy/security questionnaire is getting too long
14:43:54 <wseltzer> ... need to compress, not expand
14:44:05 <wseltzer> ... haven't yet reviewed feedback from PING in detail
14:45:12 <wseltzer> mkwst: current structure is ask a question, talk about it from perspective of what other specs have done
14:47:38 <wseltzer> mkwst: it would be great if someone wanted to provide supplemental information based on answers
14:48:16 <wseltzer> mnot: TAG would prefer if people had already reviewed the questionnaire when they come to TAG for review
14:48:48 <wseltzer> bhill2: AOB?
14:49:13 <wseltzer> JonathanKingston: How's Credential Management?
14:49:21 <wseltzer> mkwst: mostly implemented in chrome
14:49:26 <wseltzer> rrsagent, draft mintues
14:49:26 <RRSAgent> I'm logging. I don't understand 'draft mintues', wseltzer.  Try /msg RRSAgent help
14:49:34 <wseltzer> rrsagent, draft minutes
14:49:34 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/14-webappsec-minutes.html wseltzer
14:50:27 <wseltzer> i/should we add "migrate insecure/scribenick: wseltzer
14:52:07 <wseltzer> mkwst: Axel is doing an implementation in firefox
14:52:17 <wseltzer> rrsagent, draft minutes
14:52:17 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/14-webappsec-minutes.html wseltzer
14:54:24 <rbarnes> axel's credentials API: https://github.com/AxelNennker/firefox_credentials
14:54:30 <wseltzer> JonathanKingston: Generating password missing
14:55:02 <wseltzer> mkwst: sounds reasonable to add. I haven't yet come up with an API
15:00:13 <wseltzer> [discussion about passwords' special-characters requirements]
15:01:04 <wseltzer> mnot: Mixed content on localhost?
15:01:13 <wseltzer> mkwst: browsers currently block mixed content on localhost
15:02:02 <wseltzer> mnot: talk of a CORS-dance. is that on the roadmap?
15:04:44 <wseltzer> ... if you've got attacker code running on your local machine, it's game-over
15:07:54 <bhill2> bhill2 has joined #webappsec
15:07:58 <wseltzer> [discussion adjourned to beer]
15:08:05 <wseltzer> rrsagent, draft minutes
15:08:05 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/14-webappsec-minutes.html wseltzer
15:08:10 <bhill2> rrsagent, make minutes world
15:08:10 <RRSAgent> I'm logging. I don't understand 'make minutes world', bhill2.  Try /msg RRSAgent help
15:08:22 <bhill2> rrsagent, set minutes public-visible
15:08:22 <RRSAgent> I'm logging. I don't understand 'set minutes public-visible', bhill2.  Try /msg RRSAgent help
15:08:32 <bhill2> rrsagent make logs world
15:08:39 <wseltzer> present+ slightlyoff
15:08:48 <wseltzer> rrsagent, draft minutes
15:08:48 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/14-webappsec-minutes.html wseltzer
15:09:04 <bhill2> bhill2 has joined #webappsec
15:12:22 <rbarnes> rbarnes has joined #webappsec
15:36:39 <rbarnes> rbarnes has joined #webappsec
16:03:34 <dka> dka has joined #webappsec
16:13:12 <tanvi> tanvi has joined #webappsec
16:14:46 <tanvi1> tanvi1 has joined #webappsec
17:03:13 <Zakim> Zakim has left #webappsec
18:35:40 <tanvi> tanvi has joined #webappsec
18:38:17 <tanvi> tanvi has joined #webappsec
20:31:48 <tanvi> tanvi has joined #webappsec
20:52:03 <dka> dka has joined #webappsec
21:41:32 <dveditz> dveditz has joined #webappsec
23:59:29 <yan> yan has joined #webappsec