16:03:02 <RRSAgent> RRSAgent has joined #webappsec
16:03:02 <RRSAgent> logging to http://www.w3.org/2016/05/16-webappsec-irc
16:03:04 <trackbot> RRSAgent, make logs world
16:03:04 <Zakim> Zakim has joined #webappsec
16:03:06 <trackbot> Zakim, this will be WASWG
16:03:06 <Zakim> ok, trackbot
16:03:07 <trackbot> Meeting: Web Application Security Working Group Teleconference
16:03:07 <trackbot> Date: 16 May 2016
16:03:11 <wseltzer> Meeting: WebAppSec F2F
16:05:03 <yoav> yoav has joined #webappsec
16:10:20 <tanvi> tanvi has joined #webappsec
16:11:41 <tanvi1> tanvi1 has joined #webappsec
16:23:27 <wseltzer> present+ bhill2
16:23:31 <wseltzer> present+ dveditz
16:23:42 <wseltzer> present+ joel
16:23:49 <wseltzer> present+ artur
16:24:00 <wseltzer> present+ estark
16:24:05 <wseltzer> present+ crispin
16:24:13 <wseltzer> present+ rbarnes
16:24:48 <francois> present+ francois
16:24:49 <emily> emily has joined #webappsec
16:24:49 <wseltzer> present+ john_wilander
16:24:50 <bhill2> Agenda: https://docs.google.com/document/d/1KQ_TWHBc1QBn4Xf2yJ7AYDQumuJioaGDfxbzwIJjxOI/edit#heading=h.vvzbltm8twb9
16:24:54 <bhill2> bhill2 has changed the topic to: https://docs.google.com/document/d/1KQ_TWHBc1QBn4Xf2yJ7AYDQumuJioaGDfxbzwIJjxOI/edit#heading=h.vvzbltm8twb9
16:24:54 <wseltzer> present+ JeffH
16:24:59 <wseltzer> present+ freddyb
16:25:08 <wseltzer> present+ raymes
16:25:11 <wseltzer> present+ tanvi
16:25:14 <jww> jww has joined #webappsec
16:25:16 <wseltzer> present+ francois
16:25:25 <wseltzer> present+ daniel_bates
16:25:45 <dydz> dydz has joined #webappsec
16:25:54 <estark> estark has joined #webappsec
16:25:57 <estark> present+ estark
16:26:01 <dveditz> present+ dveditz
16:26:16 <wseltzer> Topic: Welcome
16:26:31 <jww> present+ jww
16:26:34 <wseltzer> agenda: https://docs.google.com/document/d/1KQ_TWHBc1QBn4Xf2yJ7AYDQumuJioaGDfxbzwIJjxOI/edit#heading=h.vvzbltm8twb9
16:27:06 <JeffH> JeffH has joined #webappsec
16:27:11 <JeffH> present+
16:27:17 <yoav_> yoav_ has joined #webappsec
16:27:22 <wseltzer> bhill2: reviewing agenda
16:27:34 <artur_janc> artur_janc has joined #webappsec
16:30:22 <rbarnes> rbarnes has joined #webappsec
16:33:58 <wseltzer> Topic: CSP2 Feedback from Apple
16:34:23 <wseltzer> daniel: recently updated Webkit's CSP code to bring it up to level 2
16:34:32 <wseltzer> ... some feedback, proposals for change
16:35:05 <wseltzer> ... CSP has the concept of hash sources
16:35:25 <wseltzer> ... initially just for in-line scripts and style sheets
16:35:35 <yoav> yoav has joined #webappsec
16:36:00 <wseltzer> ... Mike extended it external scripts and styles, piggy-backing on SRI
16:36:32 <wseltzer> ... Could we extend SRI integrity attribute to in-line?
16:37:22 <wseltzer> [daniel sketches a policy on the whiteboard]
16:38:35 <jww> jww has joined #webappsec
16:38:52 <wseltzer> ... problem, inline scripts and styles don't specify which hash algorithm, and meta-tag doesn't specify which script
16:39:11 <wseltzer> ... so propose to add integrity attribute, for consistency and efficiency
16:40:03 <wseltzer> ... to match between inline script and policy element
16:41:52 <wseltzer> mkwst: possibly 2 proposals
16:41:58 <wseltzer> ... modify SRI to support in-line
16:42:11 <wseltzer> ... only execute this block if integrity attribute matches
16:42:25 <wseltzer> ... that seems pretty reasonable
16:42:42 <wseltzer> s/in-line/in-line integrity attribute/
16:42:58 <wseltzer> tanvi: XSS you could inject the whole thing
16:43:02 <wseltzer> mkwst: yes
16:43:27 <wseltzer> ... but separate concepts: integrity-checking the attribute, policy
16:43:53 <wseltzer> mkwst: are you asking for this to be a requirement, only use the integrity checking?
16:44:03 <wseltzer> ... that's not backwards-compatible
16:44:30 <wseltzer> jww: we don't have stats on script-hash
16:45:14 <wseltzer> bhill2: if you have a hash-source, everything inline has to have hash or nonce
16:45:51 <artur_janc> artur_janc has joined #webappsec
16:46:33 <rbarnes> rbarnes has joined #webappsec
16:46:36 <rbarnes> q+
16:46:38 <wseltzer> daniel: we could warn people about performance if using multiple hashes
16:46:47 <wseltzer> ... but I was hoping we could change the design
16:47:03 <rbarnes> q-
16:47:07 <wseltzer> jww: we have require-SRI directive
16:47:50 <wseltzer> rbarnes: if you have require-SRI and allow integrity attributes on inline
16:48:10 <wseltzer> jww: there's a pull-request on SRI to define a new CSP directive for require-SRI
16:48:21 <wseltzer> rbarnes: new directive, whatever assets you load must have SRI
16:48:47 <wseltzer> mkwst: you cna have multiple digests in an integrity attribute
16:48:53 <wseltzer> dveditz: implementation can pick
16:49:00 <wseltzer> mkwst: I think they all have to match
16:49:20 <wseltzer> john: do we generally say it's up to developers?
16:49:24 <crispin> crispin has joined #webappsec
16:49:49 <wseltzer> ... letting them get into these performance problems?
16:49:57 <wseltzer> dveditz: we have implementation notes
16:50:04 <wseltzer> mkwst: forward compatibility arguments
16:50:18 <wseltzer> ... you have multiple browsers with different hashes available
16:50:36 <wseltzer> john: we can at least recommend, way to make performant websites
16:50:45 <wseltzer> ... if there's an integrity attribute, go with that hash
16:51:31 <wseltzer> bhill2: one of the reasons for this behavior: making it easier to adopt CSP, where you can add a header, but can't modify the content
16:52:01 <wseltzer> ... so requiring modification to content defeats some of the purpose
16:52:10 <wseltzer> artur_janc: there's a use case for static content, cached
16:52:45 <wseltzer> ... making it mandatory would be a big pain
16:53:02 <wseltzer> john: if we don't make it mandatory, but if it's there, use it
16:53:29 <wseltzer> bhill2: or we could say, the UA will pick the strongest algorithm for which it sees any resource
16:54:07 <wseltzer> ... then say to devs if you use a hash, you need to use it everywhere
16:54:45 <wseltzer> daniel: if you're talking about pipelines where you can't modify content, you might not be able to update
16:55:08 <wseltzer> ... can you elaborate on the difficulties sites might have updating?
16:55:18 <wseltzer> ... where it's easier to add a header than modify content?
16:56:12 <wseltzer> ... e.g., hearing it's difficult for sites to find and replace
16:56:51 <wseltzer> rbarnes: we should ask our guest from Wired
16:57:00 <wseltzer> tanvi: could be legacy content
16:57:47 <wseltzer> jww: I believe SRI and script-hash define the hashing of different content
16:57:58 <wseltzer> ... script-hash is the raw return from fetch
16:58:12 <wseltzer> mkwst: after doing transport encoding
16:58:23 <wseltzer> rbarnes: seems useful to align
16:58:42 <wseltzer> jww: did SRI go a different direction to deal with downloads?
16:58:48 <wseltzer> rrsagent, draft minutes
16:58:48 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/16-webappsec-minutes.html wseltzer
16:58:52 <wseltzer> rrsagent, make logs public
16:59:21 <wseltzer> dveditz: originally, there was no overlap
16:59:43 <wseltzer> jww: they're defined differently.
17:00:09 <wseltzer> dveditz: if you change SRI to cover inline scripts, you don't have a fetched resource
17:00:34 <wseltzer> bhill2: re: adding attribute; at some orgs, there's a separation between development and security
17:00:59 <wseltzer> ... so having declarative policy
17:01:22 <wseltzer> daniel: I'd be interested to get more feedback on developer scenarios
17:01:42 <wseltzer> artur_janc: is the main concern performance?
17:02:10 <wseltzer> daniel: performance and consistency with Issue 78
17:02:13 <wseltzer> https://github.com/w3c/webappsec-csp/issues/78
17:02:32 <wseltzer> daniel: not be telling the devs there are two different things to do
17:02:57 <wseltzer> tanvi: if you ahve SRI, you have integrity in the script and the policy
17:03:15 <wseltzer> daniel: there is a duplication
17:03:53 <tanvi1> s/if you ahve SRI/if you have require-sri/
17:04:29 <wseltzer> artur_janc: data, about 25,000 distinct policies; about 250 use hashes
17:04:35 <tanvi> medium is 2 or 3 hashes per policy
17:04:54 <wseltzer> ... so not a huge concern for performance at this stage
17:05:41 <rbarnes> rbarnes has joined #webappsec
17:05:49 <wseltzer> crispin: I'm not the CSP guy, but he said to me, big pain point, that CSP2 is breaking change from CSP1, please don't do that again.
17:06:15 <wseltzer> mkwst: CSP3 won't be a breaking change from CSP2
17:06:28 <wseltzer> dveditz: spec is written differently, but not expected to behave differently
17:06:44 <wseltzer> mkwst: minor changes, * no longer matches non-http schemes
17:06:56 <wseltzer> ... no change near the scale of moving workers
17:07:06 <wseltzer> daniel: another point, the *
17:07:12 <wseltzer> ... good it only applies to HTTP, HTTPS
17:09:21 <wseltzer> daniel: we'd like to propose that * be restrictive in the default case
17:09:36 <wseltzer> ... propose exception when it's used in img-src and media-src directive
17:09:47 <wseltzer> ... propose that for img-src, * match http, https, and data
17:09:57 <wseltzer> ... and for media, those and blob.
17:10:17 <wseltzer> ... motivated by, as Moz found, lots of sites use data URLs
17:11:08 <wseltzer> dveditz: from security perspective, probably not less secure
17:11:17 <wseltzer> ... but consistency, it's harder to explain what * does
17:11:57 <wseltzer> mkwst: chrome has implemented blocking data and blob, in process of breaking custom schemes
17:12:10 <wseltzer> ... possible that will cause problems in webview, wait and see.
17:12:35 <wseltzer> daniel: webview on iOS and Mac was one of our motivations
17:12:47 <wseltzer> ... applications were depending on data or blob to load content
17:12:52 <wseltzer> ... and they were using CSP
17:13:09 <wseltzer> ... we also got bug reports from websites
17:13:58 <wseltzer> bhill2: FB did have to fix this in our policy
17:14:09 <wseltzer> daniel: Another point, plugin and image documents
17:14:41 <wseltzer> ... Plugin document: let's say an iframe refs content that needs a plugin
17:15:03 <wseltzer> ... we don't load the plugin directly, but create a new page with markup that contains an embed tag
17:15:42 <wseltzer> ... CSP spec gives a way for developers to restrict plugin content, object-src directive
17:16:04 <wseltzer> ... but if you read the spec in detail, that's not sufficient to block the plugin
17:16:33 <wseltzer> ... so web dev would need need to do an addendum on frame-src, further policy restriction
17:16:50 <wseltzer> ... so I'd like to propose that object-src directive be defined as mech for devs to restrict all plugin content
17:16:55 <wseltzer> ... or we propose another way to do that
17:17:06 <wseltzer> ... so devs have a clear way to say "I don't want any plugin content"
17:17:44 <wseltzer> ... object-src="non" , block the plugin from loading
17:17:47 <crispin_microsoft> crispin_microsoft has joined #webappsec
17:18:02 <wseltzer> ... since there are security implications from loading plugins that are black boxes
17:18:21 <wseltzer> ... even though iframe constrains the plugin, it's still a potential issue
17:18:37 <wseltzer> ... depends on plugin implementers' adherence to best practices
17:19:12 <wseltzer> artur_janc: but iframe has a different CSP
17:19:25 <wseltzer> daniel: I propose you implement as inheritance
17:20:52 <wseltzer> mkwst: wouldn't you have to cascade the policy into every child frame, regardless of whether it's a plugin?
17:21:17 <wseltzer> ... if the goal is to prevent plugin execution, you can't do that just by applying to plugin docs
17:21:31 <wseltzer> ... since you can still load plugins in context of page loaded in iframe
17:21:50 <wseltzer> daniel: if they whitelisted a page that had plugins, yes, they're stuck
17:23:50 <wseltzer> [Chris Palmer arrives]
17:23:57 <bhill2> rrsagent, make minutes
17:23:57 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/16-webappsec-minutes.html bhill2
17:24:07 <estark> related thread: https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0421.html
17:24:20 <wseltzer> mkwst: recalling a conversation with Dev, he was happier with iframe because encapsulation
17:25:23 <wseltzer> daniel: flash can escape the frame, and netscape plugin api
17:25:42 <wseltzer> jww: still confused about the attacker. why wouldn't they just load HTML page, then load plugin?
17:26:03 <wseltzer> daniel: you can block the loading of any page content.
17:27:39 <wseltzer> mkwst: are you asking, when creating plugin doc, cascade plugin-types and object-source directive?
17:29:20 <wseltzer> ... conceptually, sounds fine
17:29:37 <wseltzer> ... suggest filing a bug on github
17:30:27 <wseltzer> bhill2: Next topic on the agenda is Secure Contexts. keep going, or move on?
17:31:01 <wseltzer> Topic: Secure Contexts and related
17:31:10 <bhill2> scribenick: bhill2
17:31:49 <wseltzer> i|reviewing agenda|scribenick: wseltzer
17:31:55 <bhill2> mkwst: spec as-is is fairly complete, a few q's raised by mozilla impl
17:32:06 <bhill2> ... specifically whether a data iframe should be a secure context if embedded in a secure context
17:32:20 <bhill2> ... ff and chrome have different ideas of what a data iframe is wrt origin inheritance
17:32:36 <bhill2> firefox follows html spec and propagates origin to the data iframe, chrome does not
17:32:52 <bhill2> mkwst: also question about what sandboxing means
17:33:19 <bhill2> ... we added an IDL attribute that will hide APIs from non-secure contexts
17:33:34 <bhill2> ... haven't started implementing that in chrome yet, some concern about our ability to make DOM creation fast,
17:33:44 <rbarnes> rbarnes has joined #webappsec
17:33:54 <bhill2> ... specifically iframe creation, because the chrome impl is very different than Firefox, specifically it is synchronous
17:34:17 <bhill2> ... if we have to make a decision about feature availability the ability to cache the creation of a new context may be impacted
17:34:36 <bhill2> ... my perspective is that we can go along with what other browsers want to do and then make it fast
17:34:54 <bhill2> ... some feedback on the WebIDL piece would be helpful (not actually part of the secure contexts spec)
17:35:00 <bhill2> ... so basically done, would be happy to publish as-is
17:35:20 <bhill2> ... need to resolve conversation around data: URIs, based on historical implementation details
17:35:36 <bhill2> ... do we know what Edge does?
17:35:46 <bhill2> freddyb: think Edge changed from inheriting to not inheriting
17:35:49 <bhill2> tanvi: what are the reasons?
17:36:07 <bhill2> mkwst: FF has done the work to track who is creating an iframe
17:36:21 <bhill2> ... and iframes are open cross-origin, ability to reach up through parent stack and navigate it
17:36:40 <bhill2> ... ff has done the work to track creation and persist the origin of the creator
17:37:21 <bhill2> dveditz: consistent with srcdoc
17:37:39 <bhill2> mkwst: but in chrome we do allow that with srcdoc, because we know who can set that attribute
17:37:58 <bhill2> dveditz: may be open to changing, we're doing it for historical reasons, aware only FF has this behavior
17:38:13 <bhill2> ... from a security standpoint it is terrible because we treat it differently from everyone
17:39:41 <bhill2> mkwst: mozilla has a solid implementation and has submitted some spec patches
17:40:04 <bhill2> ... only real disagreement is on this fundamental issue of iframe origins, not sure these are blocking on the spec
17:40:20 <bhill2> ... would be happy to issue a call for consensus to move this to next phase
17:40:35 <palmer> palmer has joined #webappsec
17:40:41 <bhill2> ... if we want to publish in conjunction with the TAG, they signed off awhile ago, should they stamp it?  (nobody looking at it since Yan left)
17:41:14 <wseltzer> action: wseltzer to ask TAG for feedback on Secure Contexts
17:41:14 <trackbot> Created ACTION-217 - Ask tag for feedback on secure contexts [on Wendy Seltzer - due 2016-05-23].
17:42:51 <bhill2> johnwilander: some questions here, about context componetns
17:43:02 <mkwst> q+ to mention at some point in the future that Chrome has started locking down powerful features to secure contexts
17:44:35 <mkwst> bhill2: Let's talk about that later today in the new features block. Maybe tab state synchronization noq?
17:44:37 <bhill2> bhill2: maybe we should stick to agenda grouping - issues related directly to Secure Contexts today, vs. new features in the aftenroon block
17:45:11 <bhill2> johnwilander: if another tab that is same origin allows, e.g. a user-bypass certificate warning, should that impact another tab that didn't allow a bypass?
17:45:51 <bhill2> ... if you have e.g. 30 tabs and one or two are compromised
17:47:18 <bhill2> mkwst: regardless of what happens, what happens in an hour when you load it again?
17:47:36 <bhill2> ... we've talked about the idea of segregating origins based on the certs used to load them, haven't come up with anything we are really happy with
17:47:50 <bhill2> chrispalmer: we have a doc we could share but you would laugh at it
17:48:00 <bhill2> q+
17:48:41 <bhill2> mkwst: we were thinking about taking a hash of the cert and creating a new logical origin based on that, e.g.
17:49:05 <bhill2> tanvi: in mixed content case, old mixed content may  never go away, cookies, etc.
17:50:03 <bhill2> jeffh: one item to keep in mind, that secure tab is not just an origin it is a resource instance from a point in time
17:51:45 <bhill2> bhill2: what about cookies, etc. what is the threat model here?
17:52:07 <palmer> Cryptographic web origins, for your entertainment: https://docs.google.com/document/d/1izo3OeGa1qWjqAPesJW3ZPewFMrUXFnIgGNXZxFR5es/edit
17:52:18 <bhill2> jonhwilander: access to privileged APIs...  if a site with a cert warning is not considered a secure context, it doesn't get, e.g. location access
17:52:33 <bhill2> ... but could get that from a same-origin frame that didn't have the warning
17:53:29 <bhill2> rbarnes: if you can set cookies from a non-secure origin, why bother with the distinctions for secure origins?
17:54:06 <bhill2> johnwilander: we'd like to eventually have levels of secure contexts that are much better than just https, e.g. a csp policy with no insecure directives
17:56:07 <bhill2> johnwilander: what about sha1, etc.?
17:56:26 <bhill2> dveditz: we turn off the lock but we don't actually think it's insecure, we are encouraging site developers to migrate
17:56:44 <bhill2> jww: mixed passive content has pretty limited impact..
17:56:56 <bhill2> mkwst: and we still enforce mixed content
17:57:08 <bhill2> ack bhill2, mkwst
17:57:11 <bhill2> ack bhill2
17:57:14 <bhill2> ack bhill
17:57:17 <bhill2> ack mkwst
17:57:17 <Zakim> mkwst, you wanted to mention at some point in the future that Chrome has started locking down powerful features to secure contexts
17:57:58 <bhill2> johnwilander: it may make more sense later to disallow mixing with other context flags beyond what we have today
17:58:14 <dveditz> q+ worse than cookies/localstorage, one windows could have a direct reference to the other
17:58:16 <bhill2> tanvi: we could change the lock icon everywhere when the change happens in one tab
17:58:39 <dveditz> q? worse than cookies/localstorage, one windows could have a direct reference to the other
17:58:42 <deian> deian has joined #webappsec
17:58:50 <dveditz> q+
17:59:14 <bhill2> estark: could populate the cache...
17:59:20 <bhill2> ack dveditz
17:59:49 <bhill2> dveditz: with a direct window reference, you could manipulate the DOM if they are same origin
17:59:57 <bhill2> ... seems worse than what you're talking about
18:00:15 <bhill2> rbarnes: we do have some ways to set synchronous state across an entire origin, e.g. HSTS
18:00:34 <bhill2> ... so e.g. a require CT directive for HSTS, once one frame sets that it applies everywhere
18:01:00 <bhill2> estark: loading subresources with degraded security does lower the security indicator for the parent in chrome
18:01:02 <tanvi> we could change the lock icon everywhere when mixed active content is loaded or there is a certificate override, but i wouldn't necessary do that for the 1024 bit, sha1, or mixed passive content cases.
18:01:11 <bhill2> ... if subresource goes into memory cache that can propagate to other tabs
18:01:37 <bhill2> ... in chrome if you load active mixed content that downgrades the indicator, will carry over to reloading the page in the same context again
18:01:55 <bhill2> rbarnes: but only in the same process
18:02:43 <bhill2> raymes: same origin documents in different tabs are often in the same process
18:03:35 <bhill2> TOPIC: disallowing mixed trust in EV
18:03:37 <rbarnes> rbarnes has joined #webappsec
18:03:51 <bhill2> johnwilander: long topic of discussion where you pay more for the green bar bits in an EV cert
18:04:06 <bhill2> ... only top document needs to be from this org
18:04:16 <bhill2> ... below that only needs to be https, not from same org
18:04:30 <bhill2> ... would like to go to a model where green bar means all content is from one organization
18:04:51 <bhill2> ... propose three steps:  1. console warning + evangelism
18:05:31 <bhill2> ... 2. only EV, but mixed EV across orgs OK
18:05:38 <bhill2> ... 3. only EV from one org
18:06:01 <bhill2> rbarnes: but e.g. bank of america can choose to build their content from multiple sources
18:06:14 <bhill2> ccowan: can still be done on the backend
18:06:26 <bhill2> mkwst: can we get rid of the green bar? we've already done that on android?
18:06:40 <bhill2> tanvi: are we just keeping EV to keep the CAs happy?
18:06:51 <bhill2> rbarnes: I can imagine this coming in as an HSTS directive...
18:07:03 <bhill2> q+
18:07:21 <bhill2> ccowan: what is the threat actor here?
18:07:37 <bhill2> johnwilander: if you go to a bank site and believe content is coming from bank
18:07:46 <bhill2> ... but coming from 20 servers
18:10:18 <bhill2> bhill2: EV is about making phishing harder, not preventing MITM
18:10:35 <bhill2> jww: this may make security worse because it will be much harder to deploy EV at all
18:11:11 <bhill2> tanvi: maybe this isn't "EV" but some extra security state
18:11:22 <bhill2> wseltzer: agreed, maybe this is a different mechanism
18:12:34 <bhill2> johnwilander: what are we really telling users with EV?
18:12:48 <bhill2> ... would be nice to tell users they are only talking to one organization
18:13:51 <bhill2> ccowan: you can't cryptographically establish at the transport layer that there is non-collaboration
18:14:06 <bhill2> rbarnes: there may be some privacy benefit
18:14:14 <bhill2> artur: site can still do that on the backend
18:14:33 <bhill2> johnwilander: backend is different because of client side state like 3rd party cookies
18:16:27 <bhill2> bhill2: need to understand the use cases that are compelling; this would be a really big change
18:16:59 <bhill2> johnwilander: could still be a CDN, if you give them an EV cert
18:17:25 <bhill2> bhill2: is this a distinction without a difference?
18:17:40 <bhill2> johnwilander: Paypal could buy an EV cert and give it to Akamai
18:17:48 <bhill2> rbarnes: isn't that the same as adding a link?
18:18:00 <bhill2> johnwilander: links can be injected more easily
18:19:01 <bhill2> jeffhodges: you're going into layer 9, so what's the legal benefit, because that's where it's going?
18:19:24 <bhill2> estark: I could see if an org wants to say "only EV content", could send an directive
18:19:37 <bhill2> rbarnes: could see providing an opt-in mechanism like HSTS and see if anybody sees it as useful
18:20:30 <bhill2> ccowan: safari could just provide a new indicator when this happens, unilaterally as an experiment
18:20:41 <bhill2> johnwilander: more valuable when we agree to do this together
18:20:51 <bhill2> jww; some browsers don't agree with EV being more valuable
18:21:32 <tanvi1> tanvi1 has joined #webappsec
18:21:53 <bhill2> wseltzer: would help to build up use cases
18:22:15 <bhill2> estark: does this group have a position on standardizing browser UI?
18:22:33 <bhill2> wseltzer: as a general matter W3C tends not to
18:25:34 <rbarnes> rbarnes has joined #webappsec
18:26:49 <wseltzer> [lunch]
18:27:26 <bhill2> return at 12:15
18:27:34 <wseltzer> rrsagent, draft minutes
18:27:34 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/16-webappsec-minutes.html wseltzer
19:01:57 <estark> estark has joined #webappsec
19:04:27 <tanvi> tanvi has joined #webappsec
19:10:36 <dydz> dydz has joined #webappsec
19:16:27 <palmer> palmer has joined #webappsec
19:17:45 <bhill2> TOPIC: CORS and private IP address ranges
19:18:01 <tanvi> tanvi has joined #webappsec
19:18:07 <bhill2> https://mikewest.github.io/cors-rfc1918/
19:18:18 <bhill2> Modifications to Fetch which are intended to mitigate the risks associated with unintentional exposure of devices and servers on a client’s internal network to the web at large.
19:18:59 <bhill2> mkwst: generally speaking rfc1918 has been around 10-12 years defining a boundary between outside and inside networks
19:19:13 <dydz> dydz has joined #webappsec
19:19:22 <bhill2> ... would be nice if browsers could enforce this boundary, as well as between the internet and the localhost
19:19:24 <dveditz> q?
19:19:30 <dveditz> q+
19:19:52 <bhill2> ... bad things that have happened from internet routers being owned, to Project Zero issues with local antivirus products exploitable from the web
19:19:55 <bhill2> ack bhill
19:20:09 <bhill2> ... lots of software runs servers on your local machine
19:20:34 <bhill2> ... tried to put some of this into the Mixed Content spec because it was a little more aggressive than we could be with current deployments
19:20:56 <bhill2> ... and would break things that are legitimate, DropBox, Spotify have local clients that want to talk to the web
19:21:22 <bhill2> ... want to enable these to a limited extent, my opinion is we should only do so with explicit opt-in
19:21:42 <bhill2> ... boundary between internet and local surfaces can and should be stronger
19:22:41 <bhill2> ... we define external requests as any request crossing into a more restricted zone (Internet->intranet->localhost)
19:23:14 <bhill2> ... we require that these requests be identified by a header and that response opt-in by a header with a new preflight mechanism
19:23:21 <bhill2> ... this would apply to navigations, iframe loads, etc.
19:23:32 <bhill2> ... not just async requests like CORS
19:23:54 <bhill2> ... those that are never updated should never talk to the internet
19:24:19 <bhill2> ... would also like the user to be involved, Presto used to have some user consent / notification for these kind of requests
19:24:25 <bhill2> ccowan: why do you think that?
19:24:37 <bhill2> mkwst: my personal opinion, we can argue about that
19:25:03 <bhill2> ... have 20% of an impl in blink right now to play with, only does some kinds of requests and only does before DNS resolution, so works for IP addresses
19:25:29 <bhill2> ... doesn't catch spotilocal.com which resolves to 127.0.0.1, layering in blink makes it blind to what DNS is doing
19:25:43 <bhill2> ... proof of concept proves lots of stuff breaks, which is good, because it is supposed to
19:25:55 <bhill2> ... want to hear if this is a reasonable model to explore before doing the work to break all the boundaries
19:25:58 <rbarnes> rbarnes has joined #webappsec
19:26:30 <bhill2> ccowan: Microsoft has blocked this for 5 years in app container.  Nobody complained.  Only when we added Edge in app container did anyone care.
19:26:46 <bhill2> ... we compromised where the Internet does allow localhost, the intranet does not
19:27:12 <bhill2> ... this inversion exists because intranet has federated auth, and this allows you to potentially auth to the box as the user and escape
19:27:57 <bhill2> dveditz: localhost services are in many cases replacing plugins for native access
19:28:09 <bhill2> ccowan: are there localhost services that a web page has a legit business talking to?
19:28:15 <bhill2> ... for iOS, etc?
19:28:43 <bhill2> dveditz: on android we allow intent URLs which is not quite the same thing
19:30:07 <bhill2> bhill2: we've seen this before on android, debate about whether this can be routed through the backend anyway
19:30:30 <bhill2> ccowan: there are a lot of "naive" localhost services that assume "everything on the box is my friend"
19:30:45 <bhill2> ... there are things that are horribly vulnerable on this surface
19:31:13 <bhill2> ... one question is what about websockets?
19:31:27 <bhill2> mkwst: we can make it work for websockets, I don't know if we do CORS preflight for websockets
19:31:41 <bhill2> ... don't think so because there is an origin check
19:31:56 <bhill2> ... we can strengthen that
19:32:20 <bhill2> dveditz: concerned about defining this as a boundary because they are a way to alias address space
19:32:39 <bhill2> ... there are internal addresses that use static IPs that still should not be considered "internet"
19:32:52 <bhill2> ... it's not the actual inside/outside boundary
19:33:11 <bhill2> mkwst; would like to get Crispin's corporate historical knowledge on this
19:33:24 <bhill2> ccowan: IE had half a dozen zones, Edge has 3, you only see 2
19:33:39 <bhill2> ... there is "trusted sites"
19:35:15 <bhill2> bhill2: historically proxy autoconfig PAC files were the way to express the network topology to clients, "direct" was considered local intranet zone
19:35:15 <deian> deian has joined #webappsec
19:35:42 <bhill2> dveditz: do we want to create some allowances for this?
19:35:54 <bhill2> dev: should we differentiate between localhost and intranet IPs?
19:36:36 <bhill2> ... most companies may have a different mapping for e.g. company.com when accessed internally that goes to an internal IP address range
19:37:37 <bhill2> ... also this group usually works on how to enable web app authors to do things more securely, would like to see an opt-in adoption model
19:37:52 <bhill2> mkwst: suggestion is to start by sending a preflight and ignoring the response?
19:38:40 <bhill2> ccowan: on old browser things still work, on a new browser only new software will work that overtly opts in by acking the preflight
19:39:27 <bhill2> dev: we are motivated to do the right thing as authors
19:39:55 <bhill2> ... we have a desktop server (dev is from dropbox)
19:40:29 <bhill2> ccowan: one question was: can we whitelist legacy stuff?  answer, yes we can; needs an exit strategy
19:41:30 <bhill2> rbarnes: are we still talking RFC1918 or just localhost?
19:41:55 <bhill2> mkwst: both, localhost is more important to me right now; intranet is harder to define and seems like less excitement about doing it
19:42:13 <bhill2> ... prototype in blink does both, has three concentric zones
19:42:21 <bhill2> ... would be fine to start with just doing localhost first
19:43:03 <bhill2> rbarnes: localhost is more noticed by users, but is also software running locally that can therefore be upgraded vs. some ancient appliance in your local network
19:43:20 <bhill2> ccowan: PM for UAC in a previous job, not a fan of asking user stupid questions
19:43:36 <bhill2> mkwst: don't think it's a stupid question, local software has lots of privilege
19:43:44 <bhill2> ... you are likely to say no, that's generally the right thing to do
19:43:55 <bhill2> ccowan: what is the question you envision?
19:44:08 <bhill2> mkwst: don't know exactly yet....
19:44:23 <bhill2> ... first kill sync XHR
19:44:58 <bhill2> mkwst: probably something vague: can this website access "internal resources"
19:45:05 <bhill2> rbarnes: "other programs running on my computer"
19:45:37 <bhill2> mkwst: model in my head is whether Origin X can access internal stuff, but wouldn't differentiate between Origin X getting localhost vs. router
19:46:04 <bhill2> ccowan: users very quickly train to not read the prompt and click yes once they've seen it a few times
19:46:23 <bhill2> ... if they don't understand the question they interpret as 'do you want to get your work done'
19:47:02 <bhill2> mkwst: we want to get rid of this prompt, and may not ask for many apps, e.g. Dropbox because lots of users say yes
19:47:18 <bhill2> ... if users say no or don't affirm, maybe we just block without asking
19:47:31 <bhill2> ccowan: why are you asking the user?  how do they know?
19:48:07 <bhill2> q+
19:48:27 <bhill2> ccowan: what value add?
19:48:38 <bhill2> mkwst: less software on local machine
19:49:05 <bhill2> rbarnes: do we ask only if preflight fails?
19:49:15 <bhill2> mkwst: no, thinking user and software have to opt-in
19:49:40 <bhill2> q+ jww
19:49:52 <bhill2> ack dveditz
19:49:57 <wseltzer> ack bhill
19:51:04 <wseltzer> bhill2: can we do something like the masking done for websockets, XOR key
19:51:50 <bhill2> tanvi: is there a way for a website to say  no, never do this?
19:51:55 <bhill2> ... if website doesn't answer?
19:51:59 <bhill2> mkwst: that's a no
19:52:15 <bhill2> ccowan: a prompt is an unhandled security exception surfaced to the user
19:52:32 <bhill2> mkwst: AV software is still capable of exposing itself to danger by just opting in all the time
19:52:44 <bhill2> ccowan: if you install vulnerable software you get what you deserver
19:53:20 <bhill2> ccowan: whether to prompt or not may be outside the spec
19:53:28 <bhill2> ack jww
19:53:28 <wseltzer> ack jww
19:53:46 <bhill2> dev: can we just allow websockets because it's a pretty strong handshake already?
19:53:47 <palmer> q+
19:54:26 <bhill2> mkwst: maybe that's enough, would be nice to be consistent and have similar guarantees, would boil down to websocket server sending additional header
19:54:44 <bhill2> dev: if we want to allow localhost one problem is that mixed content blocks to 127.0.0.1
19:55:02 <bhill2> mkwst: see list discussion of a little while ago, only reasonable to relax if we do something like this
19:55:18 <bhill2> q+ johnwilander
19:55:35 <bhill2> ccowan: websocket already does handshake, would be unhappy to do more
19:55:55 <bhill2> estark: don't think you need to reflect, just get origin and can choose to accept/respond or not
19:56:10 <wseltzer> q?
19:56:30 <devd> devd has joined #webappsec
19:56:50 <bhill2> palmer: it seems we can move forward specifying that the user agent should or may put additional blocks and also I'm against the prompt
19:57:06 <bhill2> ... except as an escape hatch when you absolutely have to use some broken old thing, and could avoid it with top nav
19:57:50 <bhill2> bhill2: by "top-nav" do you mean typing in the address bar or clicking on a link in a top-level window?
19:58:02 <bhill2> palmer: hope we can get it enough to where prompting is minimal
19:58:09 <bhill2> ack palmer
19:58:12 <bhill2> ack johnwilander
19:58:24 <bhill2> johnwilander: have we thought about cases with using /etc/hosts ?
19:58:35 <JeffH> JeffH has joined #webappsec
19:58:41 <bhill2> mkwst: give developer some way to assert this is cool (as we do with mixed content, secure contexts)
19:59:01 <bhill2> ccowan: is there any legit case for some protocol besides http?
19:59:10 <bhill2> mkwst: websockets, webrtc
20:00:00 <bhill2> ccowan: could it talk, e.g. smtp
20:00:16 <bhill2> bhill2: how would you make the browser talk that protocol?
20:01:13 <bhill2> bhill2: gopher is a great example of this where you can send arbitrary text
20:01:50 <bhill2> mkwst: is this something we want to work on?  what are the contours?
20:02:04 <bhill2> ... sounds like limited subset focusing on localhost is most interesting place to start
20:02:14 <bhill2> palmer, dveditz: like the whole thing
20:02:31 <bhill2> dveditz: don't think we should piecemeal or we won't get there
20:02:43 <bhill2> rbarnes: the rest of the space is way more complex
20:02:53 <bhill2> dveditz: opera has done it and it didn't cause too many problems
20:03:35 <bhill2> wseltzer: maybe W3C can help gather stakeholder
20:03:42 <bhill2> ccowan: yes I want to do it
20:03:54 <bhill2> ... don't object to intranet, but need to understand it more
20:04:50 <bhill2> dveditz: I want to include because router pwnage is bad enough, adding IoT to that soon, should do what we can to isolate them
20:05:14 <bhill2> mkwst: one proposal at TPAC was some sort of handshake whereby we can assert trusted communication between 'stuff' and the browser
20:05:33 <bhill2> ... e.g. netflix wanted to do this with something like SPAKE to talk to TVs on the network
20:05:57 <wseltzer> Topic: Guest speaker: Zach Tollman from Wired: Implementer report on adopting HTTPS
20:06:11 <wseltzer> scribenick: mkwst
20:06:20 <wseltzer> rrsagent, draft minutes
20:06:20 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/16-webappsec-minutes.html wseltzer
20:06:22 <bhill2> TOPIC:  Guest speaker: Zach Tollman from Wired: Implementer report on adopting HTTPS
20:07:16 <wseltzer> Chair: Brad Hill, Dan Veditz
20:07:23 <wseltzer> rrsagent, this meeting spans midnight
20:07:28 <wseltzer> rrsagent, draft minutes
20:07:28 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/16-webappsec-minutes.html wseltzer
20:10:44 <dveditz> zacktollman: [wired switching to https, converted two sections of the site]
20:10:50 <wseltzer> zach_tollman: ad challenges, mixed content, CSP data
20:12:06 <wseltzer> ... it's complicated. at least 8 groups concerned with ads.
20:12:08 <dveditz> zach_tollman: ad challenges -- 8 different groups involved in serving an ad
20:12:22 <mkwst> back now.
20:12:28 <dveditz> ... Sales (on site), Creative (makes ad),
20:12:43 <mkwst> ... Ad ops.
20:12:56 <mkwst> ... They're the glue; they are aware of deals, bring everything together.
20:13:05 <mkwst> ... They sometimes own QA.
20:13:08 <mkwst> ... Ad tech:
20:13:23 <mkwst> ... They deal with the implementation; the JS we put on the page to deliver ads.
20:13:43 <mkwst> ... Wired is part of Conde Nast; lots of brands; want to be consistent across those properties.
20:13:48 <mkwst> ... Third-party exchanges:
20:13:53 <mkwst> ... We sell space on our site directly.
20:14:09 <mkwst> ... When we can't fill it, we go to these real-time bidding mechanisms.
20:14:18 <mkwst> ... Random stuff shows up on the site. Scary.
20:14:22 <mkwst> ... Verification:
20:14:35 <mkwst> ... Folks don't trust us, so they install third-party verifiers.
20:14:39 <mkwst> ... QA:
20:14:45 <mkwst> ... Brand:
20:14:49 <mkwst> ... Me and my team.
20:15:01 <mkwst> ... We take all of this stuff and make sure it works together.
20:15:16 <mkwst> ... Opportunities for success (failure)!
20:16:50 <mkwst> ... Incentive Misalignment
20:17:29 <mkwst> ... Folks building ads might not be able to QA all the pieces, and might not care to the same level about all the pieces.
20:17:40 <mkwst> ... Trackers might not work over HTTPS, for instance, though the ad itself does.
20:17:55 <mkwst> ... We're trying to close the feedback loop to the extent possible.
20:18:10 <mkwst> ... We noticed in the first few weeks that ads were rolling out and _looking_ correct.
20:18:24 <mkwst> ... But non-visible errors were missed. Tracking pixels, etc.
20:18:40 <mkwst> ... Those are hugely concerning, because it's directly relevant to revenue.
20:19:19 <mkwst> ... One of the best things we did was to stage the rollout: just went for it on one section of the site.
20:19:25 <mkwst> ... Working on tooling to make this more obvious.
20:20:04 <mkwst> ... Chrome's security panel does a great job of highlighting insecure origins.
20:20:16 <mkwst> dveditz: Why didn't the pixels load? Aren't they just images?
20:20:58 <mkwst> zach: Maybe an issue in particular browsers? Safari behavior fixed now in TP?
20:21:12 <mkwst> ... Could be a tracking script as well, which is blocked everywhere.
20:21:32 <mkwst> ... Mixed Content issues:
20:21:38 <mkwst> ... CSP makes life a lot easier.
20:22:33 <mkwst> ... Here's our CSP. We're pretty granular with directives so we get good reports in all browswer.
20:22:43 <mkwst> ... Some don't send 'violated' directive.
20:22:52 <mkwst> ... We're doing 'unsafe-inline'/'unsafe-eval'.
20:22:59 <mkwst> ... We add in blobs: for ads.
20:23:24 <mkwst> ... We use 'block-all-mixed-content'. Only in Chrome, landed in FF, hasn't hit stable yet.
20:23:50 <mkwst> ... We can only push forward as an org if things fail in a spectacularly visible way.
20:24:30 <mkwst> ... We use 'upgrade-insecure-requests', because 'block-all-mixed-content' only works in Chrome.
20:25:20 <mkwst> ... 'upgrade-insecure-requests' has an issue with redirects.
20:26:24 <mkwst> ... Another issue with 'upgrade-insecure-requests' something with a frame and document.write and another frame? Will reduce for a bug report.
20:26:24 <tanvi> it sounds like they use and prefer upgrade-insecure-requests, and then fallback to block-all-mixed-content for things that upgrade doesn't catch for wahtever reason
20:26:47 <mkwst> ... CSP reporting makes it possible to move to HTTPS. Without report-uri, we'd have nothing.
20:27:13 <mkwst> ... 'effective-directive' is super important.
20:27:29 <mkwst> ... Not all browsers are sending it, workaround is to be super-specific in the policy.
20:27:38 <mkwst> ... 'block-all-mixed-content' is helpful, if redundant.
20:27:47 <mkwst> ... 'upgrade-insecure-requests' is amazing.
20:27:50 <mkwst> ... Problems:
20:27:56 <mkwst> ... Inconsistencies across browsers.
20:28:09 <mkwst> ... Violation reports vary quite a bit across browsers.
20:28:15 <mkwst> ... Safari TP is up to spec, yay.
20:28:21 <mkwst> ... Firefox has closed bugs.
20:28:24 <mkwst> ... Blink is strong.
20:28:34 <mkwst> ... Inconsistencies are going away, which is wonderfully helpful.
20:28:59 <mkwst> crispin: You didn't mention Edge?
20:29:08 <mkwst> zach: We don't have a ton of users using Edge.
20:29:20 <mkwst> ... Edge clustered with Firefox; very similar reports.
20:29:30 <mkwst> ... I can look it up again and follow up with you.
20:29:39 <palmer> palmer has joined #webappsec
20:29:42 <mkwst> ... Just not a lot of folks using it on Wired.
20:30:14 <mkwst> crispin: What do you do with CSP for edge, given breaking changes?
20:30:22 <mkwst> zach: For basic violations, it's working.
20:31:34 <mkwst> ... <discussion of breaking changes in CSP1 vs CSP2>
20:31:46 <mkwst> ... "Good" thing about our policy is that it's not terribly restrictive.
20:31:51 <mkwst> ... So things just generally work.
20:31:53 <JeffH> https-secured portion of Wired webapp: https://www.wired.com/category/security/
20:33:36 <mkwst> dev: What was your experience with redirects and reports on redirects?
20:34:15 <mkwst> zach: We did see issues with ad providers pushing redirects that aren't upgraded.
20:34:43 <mkwst> ... The report should help you fix that problem. Let's talk about that in a bit.
20:35:01 <mkwst> ... UIR: Not all assets can be upgraded.
20:35:14 <mkwst> ... Some advertisers have distinct hosts for HTTP and HTTPS.
20:35:28 <mkwst> ... Wired has a mixed content issue right now with sponsored content we sometimes run.
20:35:42 <mkwst> ... Issues can be hard to track down.
20:36:11 <mkwst> ... I review the hotspots in reports. Looking at blocked URI popping up. Usually related to a specific campaign.
20:36:13 <artur_janc> artur_janc has joined #webappsec
20:36:34 <mkwst> ... I see the 'document-uri', I visit that document, but I don't see the issue.
20:37:05 <mkwst> ... A problem I have is that the 'blocked-uri' will only give you the origin if it's cross-origin to the protected resource.
20:37:27 <mkwst> ... It would be great to get more data. I understand the security concerns with paths and queries, but it's really useful data.
20:37:39 <mkwst> ... It takes hours to track down.
20:38:12 <mkwst> john: Fragment not reported. For single-pages sites, everything looks the same.
20:40:06 <mkwst> ... <discussion of what we can do in the redirect chain>
20:40:20 <mkwst> ... <dev wants all the origins>
20:40:26 <mkwst> ... <zach agrees>
20:41:07 <mkwst> ... <dev wants something with CORS: if the redirect response contains ACAO, include it in the report>
20:41:24 <mkwst> zach: Not all browsers upgrade.
20:41:26 <mkwst> ... WebKit.
20:41:28 <mkwst> ... Edge.
20:41:37 <mkwst> ... They don't do 'upgrade-insecure-requests'.
20:41:58 <mkwst> ... To deal with those browsers, we set HSTS with a short lifetime (2s).
20:42:07 <mkwst> ... That glosses over mixed content issues with wired.com.
20:43:26 <JeffH>   Strict-Transport-Security: max-age=2
20:43:28 <mkwst> ... (By upgrading same-origin passive mixed content to HTTPS)
20:45:28 <mkwst> rbarnes: We're kicking around the idea of reversing HSTS and mixed content checks.
20:45:47 <mkwst> ... It would be interesting to understand what the impact would be.
20:45:49 <mkwst> ... https://mikewest.github.io/hsts-priming/
20:46:06 <mkwst> zach: Sounds helpful? I just want everything to automatically work.
20:46:23 <mkwst> rbarnes: Are any advertisers doing HSTS?
20:46:28 <mkwst> zach: I haven't seen that.
20:46:33 <mkwst> ... I saw a CSP header once.
20:46:38 <mkwst> ... But not HSTS.
20:46:56 <mkwst> ... Verifiers are the ones we see most frequently.
20:47:10 <mkwst> ... There are only a handful of players, so if they did that, it would be great.
20:47:13 <mkwst> ... Data!
20:48:17 <mkwst> ... Browser extensions blow up the number of reports.
20:48:24 <mkwst> ... We're filtering them, same as everyone else.
20:48:30 <mkwst> ... 300-400 unique URIs a day.
20:48:52 <mkwst> ... Removed those that are only happening ~10 times, and removed known data.
20:49:12 <mkwst> ... Brings it down to a more manageable set of reports.
20:49:23 <mkwst> ... Metric for success is violations per page view.
20:49:36 <mkwst> ... 0.05 would be nice, though arbitrary.
20:50:13 <mkwst> aaj: Are you dropping reports generated by extensions? How do you implement that.
20:50:28 <mkwst> zach: We evaluate based on blocked-uri.
20:51:00 <mkwst> ... Strip out unknown protocols, 'chrome-extensions:', etc.
20:51:13 <mkwst> dev: That works for extensions, but superfish is hard to detect.
20:51:26 <mkwst> ... We just dropped everything that contains 'superfish'.
20:52:31 <mkwst> zach: I want to categorize reports, and ensure that "important" reports are triaged.
20:52:43 <mkwst> dveditz: Did you use report-only first?
20:52:49 <mkwst> zach: I went straight to blocking.
20:53:03 <mkwst> ... Difficult to serve an HTTP page with HTTPS content, so I would have gotten a lot of noise.
20:53:15 <mkwst> ... So went straight to blocking things in our staging server.
20:53:26 <mkwst> ... report-only was more trouble than it was worth.
20:54:29 <Devd__> Devd__ has joined #Webappsec
20:55:42 <mkwst> zach: WebKit generates a lot of reports. Then Chrome.
20:56:14 <mkwst> dev: What UA parser are you using?
20:56:22 <mkwst> ... Lots of things show up as Chrome, but aren't actually Chrome.
20:57:01 <mkwst> zach: I'm not sure how some UAs are being reported. Area to investigate further.
20:57:10 <Devd__> https://www.buzzfeed.com/jasonreich/buzzfeed-and-https just got posted  too
20:58:37 <mkwst> ... <discussion of UA string -> browser mapping>
20:58:42 <mkwst> ... <it's hard>
20:59:40 <mkwst> ... WebKit generates most violations per page view.
20:59:43 <mkwst> ... Then Edge.
21:00:15 <mkwst> ... Alerts for violations are important. Looking into that internally.
21:00:34 <mkwst> daniel_bratel: Can you elaborate on the difficulty of auditing your website and fixing links.
21:00:42 <mkwst> zach: Yeah. It's difficult and tedious.
21:01:00 <mkwst> ... We got to a point where we thought we were done.
21:01:07 <mkwst> ... Lots more variance in the real-world.
21:01:16 <mkwst> ... Acting on a violation report is incredibly difficult.
21:01:27 <mkwst> ... I wanted to find the three top-offending ads per day.
21:01:33 <mkwst> ... That took hours.
21:01:46 <mkwst> daniel: So you're able to fix your own content?
21:01:49 <mkwst> zach: Yes.
21:02:06 <mkwst> daniel: Why are the advertisers dragging their feet in adding the "s"?
21:02:17 <mkwst> zach: I think it's a human problem.
21:02:24 <mkwst> ... People have to figure out which ad is responsible.
21:02:29 <mkwst> ... In-house is easy and fast.
21:02:30 <mkwst> ...
21:02:36 <mkwst> ... Third-parties are difficult.
21:02:54 <mkwst> daniel: You could choose not to work with those third-parties?
21:03:08 <mkwst> zach: I would like to be able to highlight which agencies are dropping the ball.
21:03:17 <mkwst> ... Data don't have enough specificity.
21:03:44 <mkwst> ... Want to create accountability.
21:04:06 <mkwst> tanvi: Have you considered sandboxing ads?
21:04:17 <mkwst> zach: No.
21:04:35 <mkwst> ... What would be the value of doing that?
21:04:42 <mkwst> tanvi: Would restrict access to DOM.
21:05:01 <mkwst> zach: Would it help with HTTPS?
21:05:04 <mkwst> tanvi: No.
21:05:20 <mkwst> tanvi: Do you want 'block-all-mixed-content' or 'upgrade-insecure-requests'?
21:05:36 <mkwst> zach: I want upgrade, but to block everything that can't be upgraded.
21:06:36 <mkwst> john: We on WebKit hear you!
21:06:52 <mkwst> ... The third-party part is important, means that HSTS isn't at play here and you need 'upgrade-insecure-requests'.
21:07:07 <mkwst> ... I've heard there could be ~1000 actors in one ad being displayed.
21:07:18 <mkwst> ... Even if you could get HTTPS right, there's a lot of issues including malvertising, etc.
21:07:30 <mkwst> ... Do you have something about that on your roadmap?
21:07:43 <mkwst> zach: No, but I'd like to do something about that.
21:08:06 <mkwst> ... Alternate models are interesting. Selling direct to consumer, for instance.
21:08:14 <mkwst> ... Ad blockers are scaring publishers.
21:08:19 <mkwst> ... Need to diversify.
21:09:28 <mkwst> bhill2: One thing that might help would be to use automation APIs to load pages, collect violations off the console (webdriver, selenium, etc).
21:09:47 <mkwst> ... Set up a server to make a request as soon as the creative is submitted, generate reports.
21:10:06 <mkwst> zach: We have a project aimed at performance, using PhantomJS.
21:10:12 <mkwst> ... Might be able to lump in HTTPS as well.
21:10:15 <mkwst> ... Automation is great.
21:10:29 <mkwst> JeffH: Do you give a CSP to the advertisers?
21:10:40 <mkwst> zach: No, but that's a great idea!
21:10:51 <mkwst> JeffH: What are the differences between browsers?
21:11:03 <mkwst> ... Are these violations bugs in the browser, or bugs in the advertisers?
21:11:24 <mkwst> zach: I'm still trying to make sense of the data.
21:11:32 <mkwst> ... I was surprised to see so many reports from Chrome.
21:11:43 <mkwst> ... Not sure if it's a UA string misrepresentation or bugs in the browser.
21:12:29 <mkwst> ... <discussion of the data: is Chrome Chrome?>
21:13:04 <mkwst> daniel: Is there no way to associate a report with the request for the original webpage?
21:13:10 <mkwst> zach: Sometimes yes, sometimes no.
21:13:14 <Devd__> .... Terrible puns....
21:13:30 <mkwst> ... We turned on HTTPS for 24 hours in our business section.
21:13:53 <mkwst> ... We had targeted ads in business. We knew they would have run of site, so we knew they would be the only ad.
21:14:11 <mkwst> ... In those cases, we can easily identify.
21:14:24 <mkwst> ... But there are lots of complexities and randomness.
21:14:36 <mkwst> ... Targeting makes it difficult to find bad ads.
21:14:49 <mkwst> daniel: 'unsafe-inline', 'unsafe-eval'?
21:14:56 <mkwst> zach: I'd love to drop them, but ads use them.
21:15:01 <mkwst> ... Thinking about 'unsafe-eval'.
21:15:08 <mkwst> ... We need 'unsafe-inline'.
21:15:40 <mkwst> ... Hard enough to get the 's', once we've done that we can move to more interesting problems.
21:16:01 <mkwst> jww: How successful has outreach to ad networks been?
21:16:12 <mkwst> ... Is it at all successful, or is UIR the only thing that works?
21:16:18 <mkwst> zach: Moderate success?
21:16:26 <mkwst> ... Mostly focused internally, working on QA.
21:16:39 <mkwst> ... QA was focused on visual feedback, so missing the most important parts.
21:16:43 <mkwst> ... Beefing up QA internally.
21:16:50 <mkwst> ... Next, we need to reach out more to advertisers.
21:17:07 <mkwst> dveditz: Have you seen 'unsafe-dynamic'?
21:17:13 <mkwst> zach: No, but I saw it on the schedule.
21:18:06 <mkwst> ... <discussion of XSS vs mixed content protection>
21:18:19 <mkwst> aaj: This is a valuable policy, it just doesn't defend against XSS.
21:18:31 <mkwst> john: Ad bidding is cross-site scripting.
21:18:41 <mkwst> zach: A sanctioned XSS.
21:18:46 <jww> jww has joined #webappsec
21:30:54 <dydz> dydz has joined #webappsec
21:31:20 <wseltzer> if they know to send a subscribe request
21:31:39 <wseltzer> s/if they know to send a subscribe request//
21:31:40 <crispin> crispin has joined #webappsec
21:32:05 <yoav> yoav has joined #webappsec
21:32:47 <rbarnes> rbarnes has joined #webappsec
21:32:48 <wseltzer> rrsagent, draft minutes
21:32:48 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/16-webappsec-minutes.html wseltzer
21:33:51 <wseltzer> TOPIC: Permissions in Context
21:34:26 <wseltzer> bhill2: Permission Delegation to Iframes + CSP embedded enforcement, Feature Policy, and Secure Context Components
21:34:31 <estark> estark has joined #webappsec
21:35:38 <mkwst> palmer: We have a proposal for permission delegation.
21:35:56 <mkwst> ... TL;DR: https://noncombatant.github.io/permission-delegation-api/
21:36:09 <mkwst> ... What do we do when example.com embeds Google Maps?
21:36:16 <mkwst> ... There's a permission request for geolocation.
21:36:24 <mkwst> ... But what do we say to the user?
21:36:35 <mkwst> ... Does 'example.com' want the permission? Does 'google.com'?
21:36:47 <mkwst> ... Does the permission stick to the pair? To the main page? To the embedee?
21:37:01 <mkwst> ... How long should the permission stick?
21:37:23 <mkwst> ... If you grant `maps.google.com` permission in the context of `example.com` should it stick when loaded under `example.net`?
21:37:27 <mkwst> ... We did some studies.
21:37:38 <mkwst> ... People in the world don't understand composed applications.
21:37:51 <mkwst> ... The location bar is about the limit of what people can handle.
21:38:09 <mkwst> ... Not a fan of trying to surface composition via the omnibox.
21:38:20 <mkwst> ... Leaves us with some irreducible complexity.
21:38:35 <mkwst> ... We'd like to give the least privilege to the most specific principal.
21:38:45 <mkwst> ... But there's a limit to the principals that folks can understand.
21:39:11 <mkwst> ... Studies corroborate that.
21:39:23 <mkwst> ... Omnibox is already a simplification.
21:40:06 <mkwst> ... This simplification ~matches the status quo on other platforms.
21:40:29 <mkwst> ... Android apps grab data from everywhere. Might be composed, who knows? Can't surface to users.
21:41:02 <mkwst> ... Loading .so doesn't change SID. Still running as me after loading `goats.so`.
21:41:11 <mkwst> ... We're proposing to tie the permission grant to the embedder.
21:41:25 <mkwst> ... Violates the principal of least privilege.
21:41:42 <mkwst> ... But it's something that the user of `example.com` can have a chance of understanding.
21:41:52 <mkwst> ... The usual means for revoking the permission still apply.
21:42:57 <mkwst> ... We think the proposal as it is now is the best thing that's possible in the world we have with the people we are.
21:43:09 <mkwst> ... But, we know that reasonable folks can and do disagree.
21:43:22 <mkwst> ... We'd love to manage this tradeoff. Perhaps there are other options?
21:43:45 <mkwst> ... Maybe we can specify the mechanism, and leave UX to browsers?
21:43:49 <mkwst> ... Prove it out in the field.
21:44:15 <mkwst> ... Also, this ties into the purple box idea that John raised earlier.
21:44:30 <mkwst> ... "Wouldn't it be cool if we could promise to people that X is _not_ a composed application?"
21:44:46 <wseltzer> q+
21:44:59 <mkwst> ... It feels true that people would want it if they understood it? More research is warranted.
21:45:14 <mkwst> ... Composed apps have always posed a problem. Only on the web are we even thinking about going to a better place.
21:45:23 <mkwst> ... Which is why I love the web.
21:46:12 <mkwst> ... Composed applications that do use special APIs that require permissions are already below our depreciation threshold.
21:46:39 <mkwst> ... But we think it's super-useful, but now seems like a good time to standardize a better way of giving users understandable control.
21:46:49 <mkwst> ... Now seems like a good time to act.
21:47:21 <mkwst> bhill2: The numbers are low today? I mean, maps is everywhere?
21:47:44 <mkwst> raymes: Maps is a bad example for numbers, because the embedder passes in a location when loading the map.
21:47:55 <mkwst> john: There are ~3 things that make these cases different:
21:48:00 <mkwst> ... Native apps vs web apps.
21:48:10 <mkwst> ... 1. Native app is a static relationship.
21:48:15 <mkwst> palmer: Not really?
21:48:34 <mkwst> john: You can pull things in, but not in the same way or same frequency as the web.
21:48:38 <bhill2> (npm lol)
21:48:44 <mkwst> ... 2. Apps store. Trusted place to get the app.
21:49:05 <mkwst> palmer: My linux music player will crawl all over looking for a .so to open a file.
21:49:14 <mkwst> john: Sure, for desktop. Not for mobile.
21:49:19 <mkwst> ... 3. Apps are signed.
21:49:31 <mkwst> palmer: The permissions we're talking about are the ones that require HTTPS, which is a rough analog.
21:49:44 <mkwst> john: Except that the signature is over the content.
21:50:15 <mkwst> ... given those things, we would like to fix signatures, for instance.
21:50:23 <mkwst> ... require CSP without 'unsafe-*'
21:50:26 <wseltzer> q+ ccowan
21:50:29 <wseltzer> q+ artur
21:50:33 <wseltzer> ack cc
21:50:58 <mkwst> ccowan: I've spent ~20 years with least privilege. It's a bad idea to drill down too far in that direction.
21:51:15 <mkwst> ... In this case, it's a question of giving privilege to X or Y or XY.
21:51:19 <mkwst> ... Who cares?
21:51:30 <mkwst> ... If you don't give permission, they still have your location.
21:51:42 <mkwst> ... Users don't care.
21:51:45 <mkwst> palmer: I think they do care.
21:52:01 <mkwst> ... One company that has yelled at us about this serves an iframe that uses getUserMedia.
21:52:27 <mkwst> ... Our proposal is for anything that requires a permission prompt.
21:52:40 <mkwst> ccowan: The responsibility belongs to the embedder.
21:52:45 <mkwst> palmer: Yup. We think that too.
21:52:55 <mkwst> ... Embedee only gets permission upon explicit delegation.
21:52:59 <bhill2> q?
21:53:09 <mkwst> ... Zach talked about auctions.
21:53:21 <mkwst> ... It would be cool if Wired could simply not delegate permissions to ads.
21:53:28 <mkwst> ... They can't do that today.
21:53:47 <mkwst> q+ to ask Joel to enumerate the thing we're dropping from non-secure origins.
21:53:55 <mkwst> ... Relates to Feature Policy.
21:54:04 <wseltzer> q-
21:54:16 <mkwst> ... Maybe can fold into that proposal.
21:54:17 <bhill2> q+ do embedees lose ability to ask?
21:54:26 <mkwst> aaj: What's the proposal?
21:54:26 <bhill2> q+
21:54:31 <bhill2> ack artur
21:54:40 <mkwst> palmer: <iframe src="..." permissions="whatever goats more-goats">
21:54:55 <mkwst> ... The permissions attribute delegates the "goats" permission to "...".
21:55:16 <mkwst> ... Permission grant is to the top-level site.
21:55:27 <mkwst> dveditz: What about nesting?
21:55:31 <mkwst> palmer: I don't know?
21:55:42 <wseltzer> q+
21:55:49 <mkwst> raymes: I'd imagine we'd simply propagate it down.
21:55:56 <wseltzer> q+ to ask about enforcement-by-extension
21:56:00 <mkwst> ... Capability passed from the embedder, who can then do things.
21:56:24 <mkwst> danielb: What happens today when iframes request permission?
21:56:36 <mkwst> dveditz: Firefox shows the domain of the requesting frame.
21:56:45 <mkwst> ... I think gUM is top-level only.
21:56:56 <mkwst> danielb: So with this policy, the dialog would say what?
21:57:27 <mkwst> palmer: `example.com` wants whatever.
21:57:39 <mkwst> bhill2: But they can't even ask without delegation, right?
21:57:50 <mkwst> palmer: Right. The attribute gives the embedee the permission to ask.
21:57:57 <mkwst> danielb: Why the embedder?
21:58:11 <mkwst> palmer: Because that's the one users can perceive.
21:58:24 <mkwst> danielb: But they trust `example.com`!
21:58:42 <mkwst> ... It seems bad for us to abuse that trust.
21:58:51 <mkwst> raymes: They can do this today via `postMessage`.
21:59:17 <mkwst> danielb: But that's the site being disingenuous, whereas this is making the user agent complicit.
21:59:28 <mkwst> ... Not revealing the third-party that's really asking.
21:59:33 <dveditz> q?
21:59:50 <dveditz> q+ joelv
22:00:05 <dveditz> q+ MattN
22:00:11 <mkwst> palmer: What does your dad think about `wumble-wumble-wumble.627.ads.com` when he thinks he's on `noodle.com`?
22:00:26 <mkwst> ... "Why is my noodle asking me about wumble wumble wumble?!"
22:00:33 <jww> jww has joined #webappsec
22:00:46 <tanvi> q+
22:00:58 <mkwst> john: you're tricking the user!
22:01:06 <wseltzer> ack mkwst
22:01:06 <Zakim> mkwst, you wanted to ask Joel to enumerate the thing we're dropping from non-secure origins.
22:01:29 <tanvi> is this just for seucre context permissions?
22:01:44 <mkwst> danielb: Why a new attribute, rather than `sandbox`?
22:02:04 <estark> tanvi: I thought it's for all permissions, but now I'm not sure
22:02:32 <wseltzer> [what about the case where an untrusted site mashes with a service the user does trust?]
22:02:39 <tanvi> estark: mkwst says its for all
22:02:43 <mkwst> mkwst: Persistence?
22:03:06 <mkwst> palmer: `maps.google.com` doesn't get the permission persistently. `example.com` gets the permission, and can delegate it.
22:03:10 <yoav_> yoav_ has joined #webappsec
22:03:13 <mkwst> bhill2: Service worker? Notifications?
22:03:23 <deian> q+
22:03:24 <mkwst> ... Presumes a background thing.
22:03:47 <mkwst> raymes: The only permission granted to a service worker is push notifications.
22:04:06 <mkwst> ... the whole idea of service workers accessing permissions needs careful thought.
22:04:21 <mkwst> ... But once a tab is closed, the context is gone, and it has no permission persistence.
22:04:34 <mkwst> jww: All the APIs you're discussing aren't usable inside a service worker.
22:04:46 <mkwst> ... Was a limited list.
22:05:26 <mkwst> ... It's a bigger question of background permission in general.
22:06:03 <mkwst> jww: Deprecation of permission grants to non-secure contexts:
22:06:14 <mkwst> ... getUserMedia is deprecated.
22:06:19 <devd> devd has joined #webappsec
22:06:20 <mkwst> ... geolocation is mostly deprecated.
22:06:36 <mkwst> ... appcache offline fallback.
22:06:50 <mkwst> ... device motion/orientation
22:07:08 <mkwst> john: Long term?
22:07:24 <mkwst> jww: Policy is "powerful features".
22:07:30 <mkwst> ... question is "what is powerful"?
22:07:43 <mkwst> ... `localStorage` isn't on our list at this point.
22:07:58 <mkwst> ... New powerful features must be HTTPS-only.
22:08:09 <mkwst> ... Not as difficult; folks aren't arguing about that.
22:08:20 <mkwst> ... Notifications are annoying, but not powerful.
22:08:26 <mkwst> ... We might get rid of it because it's annoying.
22:08:36 <mkwst> ... Push notifications are, because they go through Service Workers.
22:08:36 <bhill2> q?
22:08:57 <wseltzer> ack bh
22:09:09 <mkwst> bhill2: If an origin already has a permission, does it keep them?
22:09:13 <rbarnes> http://memedad.com/memes/881794.jpg
22:09:21 <mkwst> ... Or are they all born naked and without permissions?
22:09:58 <mkwst> palmer: One thing we considered would be to pop up a full top-level document to ask for the persistent permission.
22:10:21 <mkwst> ... The pop-up proposal probably isn't great UX, but maybe that persistence would solve the problem.
22:11:02 <mkwst> raymes: The spec says that (draft) it wouldn't persist. If you go to `example.com` in the top-level and grant the permission, then load `example.com` in a frame, it wouldn't have the permission.
22:11:37 <mkwst> ... We saw the opposite as somewhat surprising to users.
22:11:54 <deian> q-
22:12:12 <mkwst> tanvi: Could also just leave it up to the UA.
22:12:32 <wseltzer> ack wseltzer
22:12:32 <Zakim> wseltzer, you wanted to ask about enforcement-by-extension
22:12:34 <dveditz> q+ tanvi
22:12:36 <mkwst> bhill2: Would be interesting to get data about the usage; would be bad if it broke things across the web.
22:13:25 <mkwst> wseltzer: What about extensions? Could they help?
22:13:43 <mkwst> palmer: I think Chrome exposes via Content Settings enough surface area to build such a thing.
22:13:51 <mkwst> ... Of course, it would require all the permissions.
22:14:10 <mkwst> wseltzer: What about things like Stripe, where you trust the embedee but not the embedder?
22:14:38 <mkwst> palmer: That's a big part about why I'm so sad. Principle of least privilege matters.
22:14:54 <wseltzer> ack joel
22:14:54 <mkwst> ... "Fall back on audit" is an answer, but not a great answer.
22:15:05 <dveditz> ack joelv
22:15:12 <mkwst> jww: Dishonesty to the user?
22:15:17 <mkwst> palmer: We have to face that problem.
22:15:23 <mkwst> ... But it's also the status-quo.
22:15:34 <mkwst> ... Iframes post all kinds of jibber-jabber to each other.
22:15:39 <mkwst> ... It would probably make you sad.
22:15:52 <mkwst> danielb: Shouldn't justify one evil with another.
22:16:01 <mkwst> jww: Perhaps we have a misunderstanding with the users.
22:16:19 <mkwst> ... Granting permission to a page doesn't actually do information flow prevention.
22:16:56 <mkwst> ... I have trouble imagining how we'd communicate the existence of other origins.
22:17:03 <mkwst> palmer: "Did you know..."?
22:17:26 <mkwst> dveditz: Users do know about `badads.com` if/when it requests permission.
22:17:41 <dveditz> s/do know/do not know/
22:17:49 <mkwst> palmer: Not justifying because of status quo. Claiming that the complexity is irreducible.
22:18:01 <dveditz> (context <script src=badads.com> in a goodsite.com page
22:18:04 <dveditz> )
22:18:18 <dveditz> not if it's a script
22:18:18 <mkwst> palmer: Linked to user studies in emails.
22:18:25 <dveditz> palmer's proposal works for frames
22:18:35 <dveditz> ack mattn
22:18:44 <wseltzer> q+ johnw
22:18:44 <mkwst> mattn: We're already not communicating this clearly.
22:19:32 <mkwst> raymes: One of the things that motivated us from the start was double-keying permissions, and communicating that keying.
22:19:35 <mkwst> ... It's complicated.
22:19:42 <mkwst> palmer: Communication is important.
22:19:48 <mkwst> ... I also don't like falling up to layer 8.
22:20:17 <mkwst> ... If you feel that `amazon.com` is trustworthy, they have to uphold that trust.
22:20:37 <mkwst> ... This gives them control over their embedees, which gives them the ability to do so.
22:20:48 <mkwst> ... If they don't, Taylor Swift will call them on it.
22:20:54 <bhill2> q?
22:20:59 <mkwst> ... <beautiful rubbery metaphor about roads, I think>
22:21:07 <mkwst> ... We can provide hooks for layer 8 to do it's job.
22:21:32 <jww> q+ devd
22:22:12 <wseltzer> zakim, close queue
22:22:12 <Zakim> ok, wseltzer, the speaker queue is closed
22:22:53 <mkwst> tanvi: I don't like not being able to grant permission to Stripe, but not the embedder.
22:22:59 <mkwst> ... But I don't want to grant to jumbo wumbo.
22:23:24 <mkwst> ... Perhaps instead of delegation, the embedder can simply control whether the embedee can request the permission.
22:23:29 <deian> I completely agree with tanvi
22:23:47 <mkwst> ... The distinction is that the prompt would say `embedee.com`.
22:23:58 <yoav> yoav has joined #webappsec
22:23:59 <mkwst> tanvi: Yup, and the embedder wouldn't get access to the data.
22:24:19 <mkwst> ... That does make the UI more complicated.
22:24:36 <mkwst> ... But this happens so rarely, so yes, in those cases you have a longer control center, but is that a big deal?
22:25:27 <palmer> I love how hard this problem is :)
22:25:33 <mkwst> bhill2: To continue the example, I grant Stripe permission in the context of `example.com`, do they have the permission under `example.org`? What if Stripe got the permission at the top level? What if the embedder doesn't grant the ability to ask?
22:25:51 <JeffH> is there a document or email thread for Tanvi's notion ?
22:26:06 <rbarnes> JeffH: i think it was on the mailing list
22:27:04 <dveditz> q?
22:27:07 <dveditz> ack tanvi
22:27:16 <mkwst> mkwst: Sounds like Feature Policy.
22:27:17 <tanvi> JeffH: i'll find the link
22:27:19 <dveditz> ack johnw
22:27:29 <mkwst> ... I like the delegation idea, but, Feature Policy might be a reasonable compromise.
22:27:53 <mkwst> john: Thinking about secure contexts.
22:27:57 <mkwst> ... Categories of security?
22:28:00 <mkwst> ... * Under policy
22:28:07 <mkwst> ... * Integrity-checked
22:28:11 <mkwst> ... * Signed
22:28:20 <mkwst> ... * Associated domains-only
22:29:00 <mkwst> ... We're perceived as slow to implement some powerful features, but this seems like a way to implement them safely more quickly.
22:29:12 <MattN> MattN has joined #webappsec
22:29:20 <mkwst> aaj: It's tough to do local reasoning about whether or not a given policy will actually usefully protect the page.
22:29:38 <mkwst> ... It's totally possible to build an insecure policy that doesn't use 'unsafe-inline', for instance.
22:29:59 <mkwst> ... On the other hand, 'unsafe-eval' doesn't negate the strength of a policy that only whitelists well-audited code, etc.
22:30:14 <mkwst> john: Sure. I know there are holes in CSP. I've mentioned two other things, though:
22:30:17 <JeffH> https://igrigorik.github.io/feature-policy/
22:30:28 <mkwst> ... Signed apps are interesting, since there's the ability to kill them in the wild.
22:30:35 <mkwst> ... This is a large topic, I'd like to discuss it.
22:30:46 <mkwst> dveditz: On the web, you have pieces from everywhere?
22:30:54 <tanvi> JeffH: https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0048.html
22:30:54 <mkwst> dev: I want signatures in SRI.
22:31:19 <bhill2> q+
22:31:22 <mkwst> dveditz: Proposals for content signing in the IETF.
22:31:24 <JeffH> tanvi: thx
22:31:27 <wseltzer> zakim, reopen queue
22:31:27 <Zakim> ok, wseltzer, the speaker queue is open
22:31:35 <bhill2> q+
22:32:04 <mkwst> jww: Why do y'all feel the need to have these properties?
22:32:32 <mkwst> john: Aside from security and privacy, there's power. We can assign power usage to apps for background usage, for instance.
22:32:33 <wseltzer> q+  on attribution
22:32:48 <mkwst> ... "You can't do that without 1, 2, and 4."
22:32:54 <tanvi> JeffH: that one is a bit dated, but has the general idea.
22:33:18 <mkwst> john: these are the kinds of discussions we're having.
22:33:33 <mkwst> jww: some of these sound like progressive web apps.
22:33:46 <mkwst> ... packaged thing that a user can recognize, seen as an app by the user.
22:34:00 <estark> q+
22:34:01 <mkwst> palmer: So far we've seen that HTTPS has been barrier enough, as Zach has noted.
22:34:28 <mkwst> john: Not enough carrots. If you had full camera access, you could build "Instagram of the web", for instance
22:34:30 <wseltzer> ack devd
22:34:44 <mkwst> dev: I prefer this kind of thing to extensions/app store.
22:35:02 <mkwst> john: With signed apps, if we had a kill switch, we could grant full filesystem access.
22:35:27 <mkwst> palmer: I'd say it was a mistake to do that for native apps.
22:35:46 <mkwst> john: Containerized, of course.
22:36:03 <rbarnes> q?
22:36:12 <wseltzer> ack bh
22:36:15 <mkwst> bhill2: We have a queue. I'm next on it.
22:36:27 <mkwst> ... It's tough to reason locally about whether CSP is secure or not.
22:36:49 <mkwst> ... Are you trying to protect yourself from accidental exploitation, or are you trying to protect against maliciousness.
22:37:02 <mkwst> ... Revocation is a recourse, but it's hard on the web.
22:37:08 <mkwst> ... TLS certs, for instance.
22:37:21 <mkwst> ... Facebook releases daily, not sure what the revocation mechanism is for that.
22:37:33 <mkwst> ... Don't want to revoke root cert because of an XSS on one page.
22:37:50 <mkwst> ... The experience we have with the web shows that revocation is really hard.
22:37:59 <mkwst> ... Need to think carefully about our threat models.
22:38:07 <mkwst> ... Seems like this proposal mashes several together.
22:38:10 <wseltzer> ack ws
22:38:10 <Zakim> wseltzer, you wanted to comment on attribution
22:38:10 <bhill2> q?
22:38:15 <bhill2> ack wseltzer
22:38:22 <jww> q?
22:38:27 <mkwst> wseltzer: One thing I find attractive about this model is that it gets us to attribution.
22:38:51 <mkwst> ... Can't trust the platform itself, but we want to trust an actor. A site can specify what it contains, etc.
22:39:03 <jww> q+
22:39:06 <mkwst> ... This is a component of building up to an application that you can blame.
22:39:16 <bhill2> q+
22:39:17 <dveditz> ack estark
22:39:25 <mkwst> estark: Is the proposal that these things would be part of the origin?
22:39:36 <mkwst> ... Would a page with a CSP be a distinct origin from a page without a CSP?
22:39:51 <mkwst> john: The browser makes runtime checks when granting permissions.
22:40:08 <mkwst> estark: If there's any page on the origin that doesn't meet these things, it can iframe a page that does?
22:40:16 <mkwst> john: Tie into the secure contexts spec.
22:40:56 <deian> q+
22:40:59 <mkwst> dev: Secure has a distinct protocol, so different origin.
22:41:47 <mkwst> john: If you're under this, maybe you get distinct storage, caches, etc?
22:43:07 <mkwst> ... <discussion of whether there's storage isolation in embedded frames>
22:43:30 <mkwst> aaj: Suborigins are kinda complicated.
22:43:38 <mkwst> ... We'll talk about it later, but it's complex.
22:43:50 <mkwst> jww: I don't think we have the plumbing in place for this.
22:44:00 <mkwst> john: I don't see the breakage.
22:44:08 <mkwst> ... You build an app, it has new storage.
22:44:18 <wseltzer> q?
22:44:37 <mkwst> jww: Could do this as an opt-in super-high-privilege mode.
22:44:52 <mkwst> ... Not a hash of the CSP or something. Just a binary set of checklists.
22:45:33 <mkwst> bhill2: Example: I have crypto material in my browser. I don't want `example.com` give me new code that has access to my crypto material. I want to be able to audit before I load it.
22:45:43 <mkwst> ... Specialized use case to put onus on the user.
22:45:59 <mkwst> ... Building the ability to do that at scale while maintaining an open platform is difficult.
22:46:08 <mkwst> ... Who pulls the revocation lever.
22:46:26 <mkwst> wseltzer: We could expose the data that allows folks to make the decision, as opposed to defining who makes the decision.
22:46:58 <mkwst> jww: I'm concerned that we're talking about things that need high privilege without asking whether we should give those privileges.
22:47:02 <bhill2> ack bhill
22:47:11 <dveditz> ack jww
22:47:16 <mkwst> ... Are we talking about things today that browsers have implemented? Or new things?
22:47:19 <mkwst> john: Both. \
22:47:32 <mkwst> ... Future proofing. We're going to keep doing new things, right?
22:47:47 <mkwst> deian: If filesystem is one of those, it's not clear how these four things help?
22:47:58 <mkwst> john: Containerized!
22:48:35 <mkwst> deian: Installation process, app store, etc. They run analysis on these binaries.
22:48:44 <mkwst> john: Not opposed to having an audit requirement.
22:49:04 <mkwst> deian: What's a reasonable policy? Is `script-src https:` enough?
22:49:31 <mkwst> john: All i'm saying is that if we want privileged APIs on the web, we need to ensure that folks behave, and maybe levels of behaving.
22:49:41 <mkwst> ... currently we have "secure contexts" which only means HTTPS.
22:49:47 <mkwst> ... It's the padlock from 20 years ago.
22:50:04 <mkwst> deian: Would Google/Facebook be ok with a third-party auditing their code?
22:50:15 <mkwst> john: Maybe we need X of these for Service Workers.
22:50:33 <mkwst> jww: before HTTPS, a user agent can't tell the user anything about who they're talking to. it's a baseline.
22:50:46 <mkwst> dev: But without pinning, that doesn't mean anything.
22:51:00 <mkwst> jww: Sure, this is why we're trying to make HTTPS better.
22:51:10 <dveditz> ack deian
22:51:20 <mkwst> ... There's a goal which is to tell the user agent who they're talking to.
22:51:25 <mkwst> ... Well-defined, if imperfect goal.
22:51:36 <mkwst> ... Would love to know what specifically we're trying to get at.
22:51:56 <mkwst> ... Shutting down openness to some degree.
22:52:05 <mkwst> ... Feel ok about HTTPS because of a well-defined goa
22:52:10 <mkwst> john: Security, privacy, performance.
22:52:25 <mkwst> ... Reducing the risk of injected code that uses powerful APIs in some malicious way.
22:52:36 <mkwst> jww: Attribution of the executing code?
22:52:52 <mkwst> john: Partially. Also, people make mistakes and write vulnerable apps.
22:53:03 <mkwst> estark: Isn't that what feature policy is about?
22:53:17 <JeffH> mkwst: u want scribe help?
22:53:19 <mkwst> john: that's the top-level saying "I don't want X", not the UA saying "You can't have X."
22:53:39 <mkwst> bhill2: Analogy to default CSP for chrome extensions?
22:53:54 <mkwst> raymes: People generally agree that these are good things?
22:54:40 <mkwst> raymes: Perhaps we restrict a feature if there's a reason. Website X gets Y if it does A, B, and C.
22:54:55 <mkwst> crispin: It's possible to be totally secure and malicious at the same time.
22:55:08 <mkwst> john: These are about reducing the risk of compromise. Necessary but not sufficient.
22:55:12 <mkwst> ... Also:
22:55:16 <mkwst> ... * no mixed trust.
22:55:22 <mkwst> ... * synchronized security state
22:55:35 <mkwst> deian: Seems like a new definition of a secure context.
22:55:39 <crispin> crispin has joined #webappsec
22:56:26 <mkwst> aaj: If you're worried about XSS protection, and that's sufficient for powerful features...
22:56:40 <mkwst> john: Also reducing the dynamism: I'm deploying X, Y, and Z, and only those.
22:57:00 <mkwst> aaj: Most of these criterion don't actually help you.
22:57:16 <mkwst> ... An app with an XSS bug will be able to meet these criteria.
22:58:36 <mkwst> mkwst: I think the suggestion is that the whole blob of everything is signed.
22:58:45 <mkwst> ... <missed some things>
22:59:05 <mkwst> dev: The filesystem example is worrying you too much.
22:59:24 <mkwst> ... The question is whether HTTPS is enough, or whether we can add more criteria to the secure contexts spec.
22:59:35 <mkwst> crispin: Web apps in a store solve this problem neatly.
22:59:44 <mkwst> ... signed, authenticated, embedded web control, etc.
22:59:54 <mkwst> ... Giving that powerful capabilities seems reasonable.
23:00:15 <mkwst> deian: Would rather give a website a permission than downloading an app the permission.
23:00:28 <mkwst> crispin: I'd rather give a packaged app from a store the permission to do whatever.
23:02:10 <mkwst> ... <discussion of XSS in apps>
23:02:29 <mkwst> john: It would be nice if we could enable powerful apis when developers do X, Y, and Z.
23:02:39 <mkwst> jww: So let's do that, and not go to a store.
23:02:56 <mkwst> ... Let's not rely on stores as the end result.
23:03:38 <mkwst> rbarnes: John is asserting that if we want web to have more permissions, we need to make them more like native apps.
23:03:56 <mkwst> JeffH: Web app vs web site?
23:04:03 <rbarnes> (note: i do not necessarily agree with that position)
23:04:07 <mkwst> crispin: Packaged app. Manifest. Know the principles.
23:04:44 <mkwst> jww: Would rather have a set of goals than a list of features to look for.
23:04:50 <mkwst> ... Attribution? Seems useful.
23:04:56 <mkwst> ... Reduce XSS?
23:05:02 <mkwst> ... Maybe a few other things.
23:05:40 <mkwst> ... My other fear is that we're aiming for a world in which we want to provide some permission, rather than asking if granting the permission is a good idea.
23:05:56 <mkwst> john: We're already at the point where different vendors have different opinions about what's fine on the open web.
23:06:09 <mkwst> ... Let's define a set of levers that can be pulled.
23:06:29 <mkwst> ... And let Edge, Chrome, etc. define different restrictions based on those levers.
23:06:47 <mkwst> crispin: We have apps stores. If you want apps, write a Windows app or an Apple app.
23:07:28 <mkwst> danielb: Just proposing new mechanisms for the purposes of attribution, etc. Not claiming that they are requirements.
23:07:37 <mkwst> john: Right. Requirements can be per-browser.
23:07:57 <mkwst> danielb: You still need discussions around permission requirements, delegation, etc.
23:08:14 <mkwst> jww: To be clear, I don't think this is a wrong thing to do, I'm just trying to find the goals.
23:09:08 <mkwst> bhill2: I liked Elisabeth Morant's talk at trustycon:
23:09:15 <mkwst> ... Not a question of access or not, but how much you get.
23:09:24 <mkwst> ... If you go here every day, maybe you get a lot.
23:09:29 <mkwst> ... Reputation, scoring, etc.
23:10:08 <mkwst> palmer: Choosers mitigate many of these risks.
23:10:37 <mkwst> crispin: I love choosers until Dropbox asks for root access.
23:11:07 <mkwst> palmer: I want Drobox to read `/Users/palmer/noodle`, but not `/Users`
23:11:20 <mkwst> dev: If it's long-lived, john is proposing doing something beyond HTTPS.
23:11:25 <wseltzer> zakim, close queue
23:11:25 <Zakim> ok, wseltzer, the speaker queue is closed
23:11:27 <wseltzer> q?
23:11:34 <mkwst> jww: The green lock doesn't convey enough information right now.
23:11:52 <mkwst> bhill2: There are ways to deprecate legacy features, make the platform more secure by default.
23:12:02 <mkwst> ... Misfeatures like `document.domain`, etc.
23:12:10 <mkwst> ... We probably need to move on.
23:12:29 <wseltzer> zakim, reopen queue
23:12:29 <Zakim> ok, wseltzer, the speaker queue is open
23:12:45 <wseltzer> Topic: Survey of current WebAppSec Portfolio
23:12:48 <dveditz> scribenick: dveditz
23:13:08 <wseltzer> rrsagent, draft minutes
23:13:08 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/16-webappsec-minutes.html wseltzer
23:13:15 <JeffH> bhill2:
23:13:38 <JeffH> ...<attempts to present taxonomy of webappsec work on proverbial table>
23:13:53 <dveditz> bhill2: list of specs, stars are specs that are done or all but technically done. green dots are things that are roughly done (as a spec)
23:13:55 <devd> devd has joined #webappsec
23:14:26 <dveditz> ... or star is "lack of outstanding issues"
23:14:31 <rbarnes> rbarnes has joined #webappsec
23:14:38 <JeffH> ...items in blue have lack of outstanding issues
23:14:40 <dveditz> ... there is a lot going on!
23:15:00 <JeffH> ...things in black with blue stars have strong proposals
23:15:18 <dveditz> scribenick: JeffH
23:15:44 <JeffH> ...how do we prioritize this list in order to deliver a platform that's relatively in sync?
23:16:03 <JeffH> ...notes that many items lack more than one impl
23:16:15 <dveditz> devd: as a web author I'd love to know what has a full implementation
23:16:40 <dveditz> ... as a baseline. CSP 1, maybe 2, and SRI I think
23:16:43 <JeffH> dev: have a baseline of things that do have 2 or more impls (eg a double dot)
23:17:06 <JeffH> ...< bhill adds count of impls to various items >
23:19:03 <JeffH> dev: ok, what is not impl'd and what's the priority of those things?
23:20:05 <JeffH> mkwst: what's the key things for browsers to restrict in order to reduce ambient authority
23:20:52 <JeffH> ....so CSP is pretty impt -- eg dynamic in CSP3 -- hope to prove that in chrome --- maybe pull out of CSP3 and promote & impl on its own -- took less than week to impl in chrome
23:21:08 <JeffH> ...things like suborigins take longer to impl, but they're impt
23:21:36 <JeffH> dev: another factor is how many webapps are using a particular feature...
23:21:36 <freddyb> s/dynamic in CSP3/unsafe-dynamic in CSP3/
23:22:09 <JeffH> mkwst: another top item is removinig barriers to migration to HTTPS -- rbarnes 2nds
23:22:58 <JeffH> rbarnes:   e.g. upgrade insecure... <others>
23:23:21 <JeffH> ... twitter wants to migrate t.co and needs Referrer Policy
23:24:26 <JeffH> mkwst: if you impl the  'origin for referrer policy' then you're a ways down the road (which road?)
23:24:44 <yoav> yoav has joined #webappsec
23:25:25 <JeffH> bhill:  mixed content in geeneral, then there's the "block-all-mixed-content" directive (?)
23:25:30 <wseltzer> [2 half ticks on mixed content are the lack of block-all-mixed-content]
23:25:54 <JeffH> rbarnes: wrt HSTS priming would fix ~ 1.5%  of mixed content
23:27:08 <JeffH> ?:  is there a discussion to have wrt prioritizing ?
23:27:33 <JeffH> bhill: crispin: if u were going to impl one feature in next yr what would it be?
23:27:42 <JeffH> crispin: 'localhost'
23:28:21 <rbarnes> no offence, devd and artur, but you guys have had HTTPS forever, so you might not be as sensitive to the HTTPS migration issues as other folks :)
23:28:22 <JeffH> bhill: present top two are https migration and CSP2 -- what's next two
23:28:53 <devd> hahaha yeah rbarnes
23:29:11 <devd> but I think the biggest enabler of https has been letsencrypt not w3c
23:29:12 <JeffH> ....if u want to have a captcha and a map etc -- unsafe-cynamic (in csp3) is a key feature
23:29:45 <rbarnes> devd: did you not listen to zack's comments?   getting a cert is not the barrier for big sites
23:29:52 <JeffH> mkwst: SRI is also getting some traction -- have 2 solid impls, more would be good, see it as valuable
23:30:12 <JeffH> tanvi: what about the cookie specs
23:30:28 <devd> lets chat after the meeting .. I actually don't think what I am saying is at odds with what zack said
23:31:17 <JeffH> bhill: wrt cookies: there's 'csp cookie controls" and then several in ietf
23:32:52 <JeffH> joel: secure atrtribte cookie stuff is impl'd, landing in dev channel soon
23:33:12 <JeffH> bhill: adds CSP Priming to list
23:34:23 <JeffH> mkwst: getup has adopted same-site cookies
23:34:38 <devd> *github
23:35:11 <JeffH> mkwst: doesn't think entrypoint reg is very impt -- same site cookies addresses largely
23:35:49 <JeffH> ... csp embedded enforcement -- ad folks don't like it --  thinks something is there regardless
23:36:08 <JeffH> ...csp cookie controls is "small" and ought to be progressed....
23:36:18 <wseltzer> -> https://igrigorik.github.io/feature-policy/ Feature Policy draft
23:36:34 <JeffH> ... it iterates on 'content performance policy'  (?)
23:37:37 <JeffH> .... so it might make sense to move the csp cookie policy to the feature-policy spec
23:39:43 <JeffH> mkwst:  .... csp pining is worth re-visiting due to header length issues.... there's lots of controls on webapps -- one ususally has a baseline config/policy for the webapp that's cacheable in some way would be good rather than issuing on every response...
23:40:46 <JeffH> bhill adds "origin defaults/pins for CSP / CORS" to list on board
23:41:45 <JeffH> mkwst/dveditz:  wondering about fixing behaviors in CORS but it is all server-side and tough to figure out what the issues are
23:42:28 <JeffH> bhill: one issue is not being able to propogate creds (ambient authn cookies?) cross-origin via CORS-authz'd requests  (?)
23:42:52 <wseltzer> [^ through redirects]
23:43:11 <JeffH> bhilll:  UI Security is something to not forget
23:43:45 <JeffH> johnw: that spec is tough to understand....
23:44:22 <wseltzer> [the ED is very different from the published WD]
23:44:37 <JeffH> bhill: editors' draft is very different, imperative & declaritive APIs, presents frame-raising approach....
23:45:33 <JeffH> ...new spec tries to fix the gpu-bottleneck issue
23:46:04 <rbarnes> tbh, this seems like it could be a separate wg
23:46:09 <JeffH> ... only tell the querier whether they are obscured or not
23:46:20 <rbarnes> not really sure the right expertise is in this room
23:46:25 <rbarnes> (this == UI sec)
23:46:46 <dveditz> it's explicitly in our charter though
23:46:50 <JeffH> palmer: there's an 'intersection observer' API
23:47:16 <JeffH> bhill: ed's copy of ui sec is similar to 'intersection observer'
23:47:43 <JeffH> ....but has a slightly diff characteristic that gives stronger assertions
23:48:18 <JeffH> ...diff impl strategy
23:48:32 <JeffH> johnw: will it work in a webview context?
23:48:46 <JeffH> dveditz:  webview won't know the app is 'on top'
23:48:59 <JeffH> bhill: you aren't really in web context when in web view
23:49:27 <JeffH> .... if webview is in malicioius app, u have bigger issues
23:50:01 <JeffH> dev: priority is jsut to get more browsers to impl CSP2
23:50:17 <JeffH> ...csp2 helped us to migrate to HTTPS
23:50:57 <JeffH> bhill: seems top choices for impl are CSP2 and upgrade-insecure
23:51:53 <JeffH> mkwst:  referrer policy is close impl-wise
23:52:23 <JeffH> bhill: what here is a get-off-out-plate ?
23:52:38 <JeffH> mkwst: has heard that from Moz wrt Cred Mgmt ?
23:52:52 <JeffH> rbarnes: we going to talk internally about that....
23:54:19 <JeffH> rbarnes: wrt UI Sec -- is related to rendering and such that we don't know about here....
23:54:39 <JeffH> ...it fulfills a sec purpose but relies on things we aren't familiar with
23:55:16 <JeffH> bhill: doesn't think it make sense in diff grp due to the sec component -- moving may cost more than leaving it here
23:55:27 <JeffH> ....IPR issues on moving it
23:55:58 <JeffH> mkwst: chrome prob not impl csp pining as-written
23:56:11 <JeffH> ...thinks it needs to be more generic
23:56:32 <JeffH> ....defining a more general pining mech would be more interesting...
23:56:46 <JeffH> dveditz: somilar to EPR....
23:57:00 <JeffH> mkwst: maybe bundle into manifest spec ?
23:57:28 <JeffH> ...csp pining hasn't gone far enuff to have worked out all the issues
23:58:47 <JeffH> johnw: some of these things under consideration -- see the webkit page
23:59:12 <dydz> dydz has joined #webappsec
23:59:47 <JeffH> ... there hasn't been a decision that we're definitely going to not do any of these items, but only the ones we've said are 'under consideration' are under consideration
00:00:52 <JeffH> ...webkit blog is getting more active
00:01:40 <JeffH> ...note that CSP2 is in Safari Tech Preview
00:06:38 <wseltzer> john: strong user story helps. We didn't really hear that for CSP1, but do for CSP2
00:07:26 <wseltzer> devd: SRI
00:08:03 <JeffH> bhill: hsts priming
00:08:40 <JeffH> mkwst:  will impl when chrome impls --
00:08:59 <JeffH> is hsts specific to browsers
00:09:02 <JeffH> ?
00:10:48 <JeffH> mkwst:  that spec reverses the order of hstas upgrade and mixed contexnt checking -- that's likely bwsr specific
00:11:45 <wseltzer> [conversation about HSTS work in IETF, coordination]
00:12:19 <wseltzer> john: HSTS supercookies discussion?
00:12:24 <MattN_> MattN_ has joined #webappsec
00:12:38 <wseltzer> JeffH: whenever you set state on client, there's some tracking potential
00:12:49 <wseltzer> john: private browsing?
00:13:05 <wseltzer> mkwst: mnot is drafting a doc on considerations for private browsing
00:13:15 <wseltzer> devd: request for cookie prefixes
00:13:23 <JeffH> rbarnes:  ponders way to perhaps not do hsts priming in webappsec ?
00:13:59 <wseltzer> ... privilege reduction is valuable; we want to subdomain isolate without 3d-pty cookie blocking
00:14:13 <wseltzer> ... so cookie prefixes.
00:15:02 <wseltzer> ... document.cookie session fixation
00:15:16 <wseltzer> ... "cookies lack integrity" paper at Usenix Sec
00:15:26 <wseltzer> ... host cookie prefixes
00:15:50 <wseltzer> ... it's not just trying to avoid 3d pty cookie blocking, because it's our own domain, just less trustworthy
00:16:04 <wseltzer> s/trustworthy/trusted content/
00:16:38 <wseltzer> ... dropbox uses it since chrome supported
00:16:51 <wseltzer> ... protect user authentication
00:17:07 <wseltzer> ... host cookie is impossible without browser support
00:17:27 <wseltzer> ... If you're not HSTS + include subdomains, someone can interfere
00:17:37 <wseltzer> dveditz: cookie prefixes require secure
00:17:50 <wseltzer> mkwst: require secure attribute on the cookie
00:18:02 <wseltzer> john: secure and insecure cookies share jar
00:18:14 <wseltzer> mkwst: cookie prefixes require secure attribute
00:18:35 <wseltzer> jww: secure attribute can be set only by secure origins
00:18:45 <wseltzer> mkwst: but we broke the web, and then unbroke it
00:19:26 <wseltzer> jww: cookie priorities in chrome
00:20:29 <wseltzer> mkwst: not breaking the web, breaking internal-to-google sites
00:21:10 <wseltzer> john: any problems with existing cookie jar?
00:21:42 <wseltzer> jww, rbarnes, dev: prefixes are easy, small number of sites setting secure cookies from insecure origins
00:22:24 <tanvi> reading off the whiteboard and trying to parse the ?/underlines/boxes, this is my understanding of the general priorities: https://public.etherpad-mozilla.org/p/jmceuoljS8
00:24:37 <wseltzer> Present: Dan Veditz, Mike West, Brad Hill, Francois Marier, Deian Stefan, Richard Barnes, Emily Stark, Joel Weinberger, Devdatta Akhawe, Tanvi Vyas, Wendy Seltzer, John Wilander, Frederik Braun, Arthur Janc, Jeff Hodges, Daniel Bates, Chris Palmer, Raymes Khoury, Crispin Cowan
00:24:42 <wseltzer> [adjourned]
00:24:46 <wseltzer> rrsagent, make minutes
00:24:46 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/16-webappsec-minutes.html wseltzer
00:24:59 <wseltzer> rrsagent, bye
00:24:59 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2016/05/16-webappsec-actions.rdf :
00:24:59 <RRSAgent> ACTION: wseltzer to ask TAG for feedback on Secure Contexts [1]
00:24:59 <RRSAgent>   recorded in http://www.w3.org/2016/05/16-webappsec-irc#T17-41-14