Web Application Security Working Group F2F -- 16 May 2016

<wseltzer> Meeting: WebAppSec F2F

Welcome

<wseltzer> agenda: https://docs.google.com/document/d/1KQ_TWHBc1QBn4Xf2yJ7AYDQumuJioaGDfxbzwIJjxOI/edit#heading=h.vvzbltm8twb9

<inserted> scribenick: wseltzer

bhill2: reviewing agenda

CSP2 Feedback from Apple

daniel: recently updated Webkit's CSP code to bring it up to level 2
... some feedback, proposals for change
... CSP has the concept of hash sources
... initially just for in-line scripts and style sheets
... Mike extended it external scripts and styles, piggy-backing on SRI
... Could we extend SRI integrity attribute to in-line?

[daniel sketches a policy on the whiteboard]

scribe: problem, inline scripts and styles don't specify which hash algorithm, and meta-tag doesn't specify which script
... so propose to add integrity attribute, for consistency and efficiency
... to match between inline script and policy element

mkwst: possibly 2 proposals
... modify SRI to support in-line integrity attribute
... only execute this block if integrity attribute matches
... that seems pretty reasonable

tanvi: XSS you could inject the whole thing

mkwst: yes
... but separate concepts: integrity-checking the attribute, policy
... are you asking for this to be a requirement, only use the integrity checking?
... that's not backwards-compatible

jww: we don't have stats on script-hash

bhill2: if you have a hash-source, everything inline has to have hash or nonce

daniel: we could warn people about performance if using multiple hashes
... but I was hoping we could change the design

jww: we have require-SRI directive

rbarnes: if you have require-SRI and allow integrity attributes on inline

jww: there's a pull-request on SRI to define a new CSP directive for require-SRI

rbarnes: new directive, whatever assets you load must have SRI

mkwst: you cna have multiple digests in an integrity attribute

dveditz: implementation can pick

mkwst: I think they all have to match

john: do we generally say it's up to developers?
... letting them get into these performance problems?

dveditz: we have implementation notes

mkwst: forward compatibility arguments
... you have multiple browsers with different hashes available

john: we can at least recommend, way to make performant websites
... if there's an integrity attribute, go with that hash

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
... so requiring modification to content defeats some of the purpose

artur_janc: there's a use case for static content, cached
... making it mandatory would be a big pain

john: if we don't make it mandatory, but if it's there, use it

bhill2: or we could say, the UA will pick the strongest algorithm for which it sees any resource
... then say to devs if you use a hash, you need to use it everywhere

daniel: if you're talking about pipelines where you can't modify content, you might not be able to update
... can you elaborate on the difficulties sites might have updating?
... where it's easier to add a header than modify content?
... e.g., hearing it's difficult for sites to find and replace

rbarnes: we should ask our guest from Wired

tanvi: could be legacy content

jww: I believe SRI and script-hash define the hashing of different content
... script-hash is the raw return from fetch

mkwst: after doing transport encoding

rbarnes: seems useful to align

jww: did SRI go a different direction to deal with downloads?

dveditz: originally, there was no overlap

jww: they're defined differently.

dveditz: if you change SRI to cover inline scripts, you don't have a fetched resource

bhill2: re: adding attribute; at some orgs, there's a separation between development and security
... so having declarative policy

daniel: I'd be interested to get more feedback on developer scenarios

artur_janc: is the main concern performance?

daniel: performance and consistency with Issue 78

https://github.com/w3c/webappsec-csp/issues/78

daniel: not be telling the devs there are two different things to do

tanvi: if you have require-sri, you have integrity in the script and the policy

daniel: there is a duplication

artur_janc: data, about 25,000 distinct policies; about 250 use hashes

<tanvi> medium is 2 or 3 hashes per policy

artur_janc: so not a huge concern for performance at this stage

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.

mkwst: CSP3 won't be a breaking change from CSP2

dveditz: spec is written differently, but not expected to behave differently

mkwst: minor changes, * no longer matches non-http schemes
... no change near the scale of moving workers

daniel: another point, the *
... good it only applies to HTTP, HTTPS
... we'd like to propose that * be restrictive in the default case
... propose exception when it's used in img-src and media-src directive
... propose that for img-src, * match http, https, and data
... and for media, those and blob.
... motivated by, as Moz found, lots of sites use data URLs

dveditz: from security perspective, probably not less secure
... but consistency, it's harder to explain what * does

mkwst: chrome has implemented blocking data and blob, in process of breaking custom schemes
... possible that will cause problems in webview, wait and see.

daniel: webview on iOS and Mac was one of our motivations
... applications were depending on data or blob to load content
... and they were using CSP
... we also got bug reports from websites

bhill2: FB did have to fix this in our policy

daniel: Another point, plugin and image documents
... Plugin document: let's say an iframe refs content that needs a plugin
... we don't load the plugin directly, but create a new page with markup that contains an embed tag
... CSP spec gives a way for developers to restrict plugin content, object-src directive
... but if you read the spec in detail, that's not sufficient to block the plugin
... so web dev would need need to do an addendum on frame-src, further policy restriction
... so I'd like to propose that object-src directive be defined as mech for devs to restrict all plugin content
... or we propose another way to do that
... so devs have a clear way to say "I don't want any plugin content"
... object-src="non" , block the plugin from loading
... since there are security implications from loading plugins that are black boxes
... even though iframe constrains the plugin, it's still a potential issue
... depends on plugin implementers' adherence to best practices

artur_janc: but iframe has a different CSP

daniel: I propose you implement as inheritance

mkwst: wouldn't you have to cascade the policy into every child frame, regardless of whether it's a plugin?
... if the goal is to prevent plugin execution, you can't do that just by applying to plugin docs
... since you can still load plugins in context of page loaded in iframe

daniel: if they whitelisted a page that had plugins, yes, they're stuck

[Chris Palmer arrives]

mkwst: recalling a conversation with Dev, he was happier with iframe because encapsulation

daniel: flash can escape the frame, and netscape plugin api

jww: still confused about the attacker. why wouldn't they just load HTML page, then load plugin?

daniel: you can block the loading of any page content.

mkwst: are you asking, when creating plugin doc, cascade plugin-types and object-source directive?
... conceptually, sounds fine
... suggest filing a bug on github

bhill2: Next topic on the agenda is Secure Contexts. keep going, or move on?

Secure Contexts and related

<bhill2> scribenick: bhill2

mkwst: spec as-is is fairly complete, a few q's raised by mozilla impl
... specifically whether a data iframe should be a secure context if embedded in a secure context
... ff and chrome have different ideas of what a data iframe is wrt origin inheritance

firefox follows html spec and propagates origin to the data iframe, chrome does not

mkwst: also question about what sandboxing means
... we added an IDL attribute that will hide APIs from non-secure contexts
... haven't started implementing that in chrome yet, some concern about our ability to make DOM creation fast,
... specifically iframe creation, because the chrome impl is very different than Firefox, specifically it is synchronous
... if we have to make a decision about feature availability the ability to cache the creation of a new context may be impacted
... my perspective is that we can go along with what other browsers want to do and then make it fast
... some feedback on the WebIDL piece would be helpful (not actually part of the secure contexts spec)
... so basically done, would be happy to publish as-is
... need to resolve conversation around data: URIs, based on historical implementation details
... do we know what Edge does?

freddyb: think Edge changed from inheriting to not inheriting

tanvi: what are the reasons?

mkwst: FF has done the work to track who is creating an iframe
... and iframes are open cross-origin, ability to reach up through parent stack and navigate it
... ff has done the work to track creation and persist the origin of the creator

dveditz: consistent with srcdoc

mkwst: but in chrome we do allow that with srcdoc, because we know who can set that attribute

dveditz: may be open to changing, we're doing it for historical reasons, aware only FF has this behavior
... from a security standpoint it is terrible because we treat it differently from everyone

mkwst: mozilla has a solid implementation and has submitted some spec patches
... only real disagreement is on this fundamental issue of iframe origins, not sure these are blocking on the spec
... would be happy to issue a call for consensus to move this to next phase
... 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)

<wseltzer> ACTION: wseltzer to ask TAG for feedback on Secure Contexts [recorded in http://www.w3.org/2016/05/16-webappsec-minutes.html#action01]

<trackbot> Created ACTION-217 - Ask tag for feedback on secure contexts [on Wendy Seltzer - due 2016-05-23].

johnwilander: some questions here, about context componetns

<mkwst> bhill2: Let's talk about that later today in the new features block. Maybe tab state synchronization noq?

bhill2: maybe we should stick to agenda grouping - issues related directly to Secure Contexts today, vs. new features in the aftenroon block

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?
... if you have e.g. 30 tabs and one or two are compromised

mkwst: regardless of what happens, what happens in an hour when you load it again?
... 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

chrispalmer: we have a doc we could share but you would laugh at it

mkwst: we were thinking about taking a hash of the cert and creating a new logical origin based on that, e.g.

tanvi: in mixed content case, old mixed content may never go away, cookies, etc.

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

bhill2: what about cookies, etc. what is the threat model here?

<palmer> Cryptographic web origins, for your entertainment: https://docs.google.com/document/d/1izo3OeGa1qWjqAPesJW3ZPewFMrUXFnIgGNXZxFR5es/edit

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
... but could get that from a same-origin frame that didn't have the warning

rbarnes: if you can set cookies from a non-secure origin, why bother with the distinctions for secure origins?

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
... what about sha1, etc.?

dveditz: we turn off the lock but we don't actually think it's insecure, we are encouraging site developers to migrate

jww: mixed passive content has pretty limited impact..

mkwst: and we still enforce mixed content

ack bhill2, mkwst

<Zakim> mkwst, you wanted to mention at some point in the future that Chrome has started locking down powerful features to secure contexts

johnwilander: it may make more sense later to disallow mixing with other context flags beyond what we have today

tanvi: we could change the lock icon everywhere when the change happens in one tab

estark: could populate the cache...

dveditz: with a direct window reference, you could manipulate the DOM if they are same origin
... seems worse than what you're talking about

rbarnes: we do have some ways to set synchronous state across an entire origin, e.g. HSTS
... so e.g. a require CT directive for HSTS, once one frame sets that it applies everywhere

estark: loading subresources with degraded security does lower the security indicator for the parent in chrome

<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.

estark: if subresource goes into memory cache that can propagate to other tabs
... in chrome if you load active mixed content that downgrades the indicator, will carry over to reloading the page in the same context again

rbarnes: but only in the same process

raymes: same origin documents in different tabs are often in the same process

disallowing mixed trust in EV

johnwilander: long topic of discussion where you pay more for the green bar bits in an EV cert
... only top document needs to be from this org
... below that only needs to be https, not from same org
... would like to go to a model where green bar means all content is from one organization
... propose three steps: 1. console warning + evangelism
... 2. only EV, but mixed EV across orgs OK
... 3. only EV from one org

rbarnes: but e.g. bank of america can choose to build their content from multiple sources

ccowan: can still be done on the backend

mkwst: can we get rid of the green bar? we've already done that on android?

tanvi: are we just keeping EV to keep the CAs happy?

rbarnes: I can imagine this coming in as an HSTS directive...

ccowan: what is the threat actor here?

johnwilander: if you go to a bank site and believe content is coming from bank
... but coming from 20 servers

bhill2: EV is about making phishing harder, not preventing MITM

jww: this may make security worse because it will be much harder to deploy EV at all

tanvi: maybe this isn't "EV" but some extra security state

wseltzer: agreed, maybe this is a different mechanism

johnwilander: what are we really telling users with EV?
... would be nice to tell users they are only talking to one organization

ccowan: you can't cryptographically establish at the transport layer that there is non-collaboration

rbarnes: there may be some privacy benefit

artur: site can still do that on the backend

johnwilander: backend is different because of client side state like 3rd party cookies

bhill2: need to understand the use cases that are compelling; this would be a really big change

johnwilander: could still be a CDN, if you give them an EV cert

bhill2: is this a distinction without a difference?

johnwilander: Paypal could buy an EV cert and give it to Akamai

rbarnes: isn't that the same as adding a link?

johnwilander: links can be injected more easily

jeffhodges: you're going into layer 9, so what's the legal benefit, because that's where it's going?

estark: I could see if an org wants to say "only EV content", could send an directive

rbarnes: could see providing an opt-in mechanism like HSTS and see if anybody sees it as useful

ccowan: safari could just provide a new indicator when this happens, unilaterally as an experiment

johnwilander: more valuable when we agree to do this together

jww; some browsers don't agree with EV being more valuable

wseltzer: would help to build up use cases

estark: does this group have a position on standardizing browser UI?

wseltzer: as a general matter W3C tends not to

<wseltzer> [lunch]

return at 12:15

CORS and private IP address ranges

https://mikewest.github.io/cors-rfc1918/

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.

mkwst: generally speaking rfc1918 has been around 10-12 years defining a boundary between outside and inside networks
... would be nice if browsers could enforce this boundary, as well as between the internet and the localhost
... bad things that have happened from internet routers being owned, to Project Zero issues with local antivirus products exploitable from the web
... lots of software runs servers on your local machine
... 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
... and would break things that are legitimate, DropBox, Spotify have local clients that want to talk to the web
... want to enable these to a limited extent, my opinion is we should only do so with explicit opt-in
... boundary between internet and local surfaces can and should be stronger
... we define external requests as any request crossing into a more restricted zone (Internet->intranet->localhost)
... we require that these requests be identified by a header and that response opt-in by a header with a new preflight mechanism
... this would apply to navigations, iframe loads, etc.
... not just async requests like CORS
... those that are never updated should never talk to the internet
... would also like the user to be involved, Presto used to have some user consent / notification for these kind of requests

ccowan: why do you think that?

mkwst: my personal opinion, we can argue about that
... 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
... doesn't catch spotilocal.com which resolves to 127.0.0.1, layering in blink makes it blind to what DNS is doing
... proof of concept proves lots of stuff breaks, which is good, because it is supposed to
... want to hear if this is a reasonable model to explore before doing the work to break all the boundaries

ccowan: Microsoft has blocked this for 5 years in app container. Nobody complained. Only when we added Edge in app container did anyone care.
... we compromised where the Internet does allow localhost, the intranet does not
... this inversion exists because intranet has federated auth, and this allows you to potentially auth to the box as the user and escape

dveditz: localhost services are in many cases replacing plugins for native access

ccowan: are there localhost services that a web page has a legit business talking to?
... for iOS, etc?

dveditz: on android we allow intent URLs which is not quite the same thing

bhill2: we've seen this before on android, debate about whether this can be routed through the backend anyway

ccowan: there are a lot of "naive" localhost services that assume "everything on the box is my friend"
... there are things that are horribly vulnerable on this surface
... one question is what about websockets?

mkwst: we can make it work for websockets, I don't know if we do CORS preflight for websockets
... don't think so because there is an origin check
... we can strengthen that

dveditz: concerned about defining this as a boundary because they are a way to alias address space
... there are internal addresses that use static IPs that still should not be considered "internet"
... it's not the actual inside/outside boundary

mkwst; would like to get Crispin's corporate historical knowledge on this

ccowan: IE had half a dozen zones, Edge has 3, you only see 2
... there is "trusted sites"

bhill2: historically proxy autoconfig PAC files were the way to express the network topology to clients, "direct" was considered local intranet zone

dveditz: do we want to create some allowances for this?

dev: should we differentiate between localhost and intranet IPs?
... most companies may have a different mapping for e.g. company.com when accessed internally that goes to an internal IP address range
... 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

mkwst: suggestion is to start by sending a preflight and ignoring the response?

ccowan: on old browser things still work, on a new browser only new software will work that overtly opts in by acking the preflight

dev: we are motivated to do the right thing as authors
... we have a desktop server (dev is from dropbox)

ccowan: one question was: can we whitelist legacy stuff? answer, yes we can; needs an exit strategy

rbarnes: are we still talking RFC1918 or just localhost?

mkwst: both, localhost is more important to me right now; intranet is harder to define and seems like less excitement about doing it
... prototype in blink does both, has three concentric zones
... would be fine to start with just doing localhost first

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

ccowan: PM for UAC in a previous job, not a fan of asking user stupid questions

mkwst: don't think it's a stupid question, local software has lots of privilege
... you are likely to say no, that's generally the right thing to do

ccowan: what is the question you envision?

mkwst: don't know exactly yet....
... first kill sync XHR
... probably something vague: can this website access "internal resources"

rbarnes: "other programs running on my computer"

mkwst: model in my head is whether Origin X can access internal stuff, but wouldn't differentiate between Origin X getting localhost vs. router

ccowan: users very quickly train to not read the prompt and click yes once they've seen it a few times
... if they don't understand the question they interpret as 'do you want to get your work done'

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
... if users say no or don't affirm, maybe we just block without asking

ccowan: why are you asking the user? how do they know?
... what value add?

mkwst: less software on local machine

rbarnes: do we ask only if preflight fails?

mkwst: no, thinking user and software have to opt-in

<wseltzer> bhill2: can we do something like the masking done for websockets, XOR key

tanvi: is there a way for a website to say no, never do this?
... if website doesn't answer?

mkwst: that's a no

ccowan: a prompt is an unhandled security exception surfaced to the user

mkwst: AV software is still capable of exposing itself to danger by just opting in all the time

ccowan: if you install vulnerable software you get what you deserver
... whether to prompt or not may be outside the spec

dev: can we just allow websockets because it's a pretty strong handshake already?

mkwst: maybe that's enough, would be nice to be consistent and have similar guarantees, would boil down to websocket server sending additional header

dev: if we want to allow localhost one problem is that mixed content blocks to 127.0.0.1

mkwst: see list discussion of a little while ago, only reasonable to relax if we do something like this

ccowan: websocket already does handshake, would be unhappy to do more

estark: don't think you need to reflect, just get origin and can choose to accept/respond or not

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
... except as an escape hatch when you absolutely have to use some broken old thing, and could avoid it with top nav

bhill2: by "top-nav" do you mean typing in the address bar or clicking on a link in a top-level window?

palmer: hope we can get it enough to where prompting is minimal

johnwilander: have we thought about cases with using /etc/hosts ?

mkwst: give developer some way to assert this is cool (as we do with mixed content, secure contexts)

ccowan: is there any legit case for some protocol besides http?

mkwst: websockets, webrtc

ccowan: could it talk, e.g. smtp

bhill2: how would you make the browser talk that protocol?
... gopher is a great example of this where you can send arbitrary text

mkwst: is this something we want to work on? what are the contours?
... sounds like limited subset focusing on localhost is most interesting place to start

palmer, dveditz: like the whole thing

dveditz: don't think we should piecemeal or we won't get there

rbarnes: the rest of the space is way more complex

dveditz: opera has done it and it didn't cause too many problems

wseltzer: maybe W3C can help gather stakeholder

ccowan: yes I want to do it
... don't object to intranet, but need to understand it more

dveditz: I want to include because router pwnage is bad enough, adding IoT to that soon, should do what we can to isolate them

mkwst: one proposal at TPAC was some sort of handshake whereby we can assert trusted communication between 'stuff' and the browser
... e.g. netflix wanted to do this with something like SPAKE to talk to TVs on the network

Guest speaker: Zach Tollman from Wired: Implementer report on adopting HTTPS

<wseltzer> scribenick: mkwst

<dveditz> zacktollman: [wired switching to https, converted two sections of the site]

<wseltzer> zach_tollman: ad challenges, mixed content, CSP data

<wseltzer> ... it's complicated. at least 8 groups concerned with ads.

<dveditz> zach_tollman: ad challenges -- 8 different groups involved in serving an ad...

... Brand:
... Me and my team.
... We take all of this stuff and make sure it works together.
... Opportunities for success (failure)!
... Incentive Misalignment
... Folks building ads might not be able to QA all the pieces, and might not care to the same level about all the pieces.
... Trackers might not work over HTTPS, for instance, though the ad itself does.
... We're trying to close the feedback loop to the extent possible.
... We noticed in the first few weeks that ads were rolling out and _looking_ correct.
... But non-visible errors were missed. Tracking pixels, etc.
... Those are hugely concerning, because it's directly relevant to revenue.
... One of the best things we did was to stage the rollout: just went for it on one section of the site.
... Working on tooling to make this more obvious.
... Chrome's security panel does a great job of highlighting insecure origins.

dveditz: Why didn't the pixels load? Aren't they just images?

zach: Maybe an issue in particular browsers? Safari behavior fixed now in TP?
... Could be a tracking script as well, which is blocked everywhere.
... Mixed Content issues:
... CSP makes life a lot easier.
... Here's our CSP. We're pretty granular with directives so we get good reports in all browswer.
... Some don't send 'violated' directive.
... We're doing 'unsafe-inline'/'unsafe-eval'.
... We add in blobs: for ads.
... We use 'block-all-mixed-content'. Only in Chrome, landed in FF, hasn't hit stable yet.
... We can only push forward as an org if things fail in a spectacularly visible way.
... We use 'upgrade-insecure-requests', because 'block-all-mixed-content' only works in Chrome.
... 'upgrade-insecure-requests' has an issue with redirects.
... Another issue with 'upgrade-insecure-requests' something with a frame and document.write and another frame? Will reduce for a bug report.

<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

zach: CSP reporting makes it possible to move to HTTPS. Without report-uri, we'd have nothing.
... 'effective-directive' is super important.
... Not all browsers are sending it, workaround is to be super-specific in the policy.
... 'block-all-mixed-content' is helpful, if redundant.
... 'upgrade-insecure-requests' is amazing.
... Problems:
... Inconsistencies across browsers.
... Violation reports vary quite a bit across browsers.
... Safari TP is up to spec, yay.
... Firefox has closed bugs.
... Blink is strong.
... Inconsistencies are going away, which is wonderfully helpful.

crispin: You didn't mention Edge?

zach: We don't have a ton of users using Edge.
... Edge clustered with Firefox; very similar reports.
... I can look it up again and follow up with you.
... Just not a lot of folks using it on Wired.

crispin: What do you do with CSP for edge, given breaking changes?

zach: For basic violations, it's working.
... <discussion of breaking changes in CSP1 vs CSP2>
... "Good" thing about our policy is that it's not terribly restrictive.
... So things just generally work.

<JeffH> https-secured portion of Wired webapp: https://www.wired.com/category/security/

dev: What was your experience with redirects and reports on redirects?

zach: We did see issues with ad providers pushing redirects that aren't upgraded.
... The report should help you fix that problem. Let's talk about that in a bit.
... UIR: Not all assets can be upgraded.
... Some advertisers have distinct hosts for HTTP and HTTPS.
... Wired has a mixed content issue right now with sponsored content we sometimes run.
... Issues can be hard to track down.
... I review the hotspots in reports. Looking at blocked URI popping up. Usually related to a specific campaign.
... I see the 'document-uri', I visit that document, but I don't see the issue.
... A problem I have is that the 'blocked-uri' will only give you the origin if it's cross-origin to the protected resource.
... It would be great to get more data. I understand the security concerns with paths and queries, but it's really useful data.
... It takes hours to track down.

john: Fragment not reported. For single-pages sites, everything looks the same.
... <discussion of what we can do in the redirect chain>
... <dev wants all the origins>
... <zach agrees>
... <dev wants something with CORS: if the redirect response contains ACAO, include it in the report>

zach: Not all browsers upgrade.
... WebKit.
... Edge.
... They don't do 'upgrade-insecure-requests'.
... To deal with those browsers, we set HSTS with a short lifetime (2s).
... That glosses over mixed content issues with wired.com.

<JeffH> Strict-Transport-Security: max-age=2

zach: (By upgrading same-origin passive mixed content to HTTPS)

rbarnes: We're kicking around the idea of reversing HSTS and mixed content checks.
... It would be interesting to understand what the impact would be.
... https://mikewest.github.io/hsts-priming/

zach: Sounds helpful? I just want everything to automatically work.

rbarnes: Are any advertisers doing HSTS?

zach: I haven't seen that.
... I saw a CSP header once.
... But not HSTS.
... Verifiers are the ones we see most frequently.
... There are only a handful of players, so if they did that, it would be great.
... Data!
... Browser extensions blow up the number of reports.
... We're filtering them, same as everyone else.
... 300-400 unique URIs a day.
... Removed those that are only happening ~10 times, and removed known data.
... Brings it down to a more manageable set of reports.
... Metric for success is violations per page view.
... 0.05 would be nice, though arbitrary.

aaj: Are you dropping reports generated by extensions? How do you implement that.

zach: We evaluate based on blocked-uri.
... Strip out unknown protocols, 'chrome-extensions:', etc.

dev: That works for extensions, but superfish is hard to detect.
... We just dropped everything that contains 'superfish'.

zach: I want to categorize reports, and ensure that "important" reports are triaged.

dveditz: Did you use report-only first?

zach: I went straight to blocking.
... Difficult to serve an HTTP page with HTTPS content, so I would have gotten a lot of noise.
... So went straight to blocking things in our staging server.
... report-only was more trouble than it was worth.
... WebKit generates a lot of reports. Then Chrome.

dev: What UA parser are you using?
... Lots of things show up as Chrome, but aren't actually Chrome.

zach: I'm not sure how some UAs are being reported. Area to investigate further.

<Devd__> https://www.buzzfeed.com/jasonreich/buzzfeed-and-https just got posted too

zach: <discussion of UA string -> browser mapping>
... <it's hard>
... WebKit generates most violations per page view.
... Then Edge.
... Alerts for violations are important. Looking into that internally.

daniel_bratel: Can you elaborate on the difficulty of auditing your website and fixing links.

zach: Yeah. It's difficult and tedious.
... We got to a point where we thought we were done.
... Lots more variance in the real-world.
... Acting on a violation report is incredibly difficult.
... I wanted to find the three top-offending ads per day.
... That took hours.

daniel: So you're able to fix your own content?

zach: Yes.

daniel: Why are the advertisers dragging their feet in adding the "s"?

zach: I think it's a human problem.
... People have to figure out which ad is responsible.
... In-house is easy and fast.
...
... Third-parties are difficult.

daniel: You could choose not to work with those third-parties?

zach: I would like to be able to highlight which agencies are dropping the ball.
... Data don't have enough specificity.
... Want to create accountability.

tanvi: Have you considered sandboxing ads?

zach: No.
... What would be the value of doing that?

tanvi: Would restrict access to DOM.

zach: Would it help with HTTPS?

tanvi: No.
... Do you want 'block-all-mixed-content' or 'upgrade-insecure-requests'?

zach: I want upgrade, but to block everything that can't be upgraded.

john: We on WebKit hear you!
... The third-party part is important, means that HSTS isn't at play here and you need 'upgrade-insecure-requests'.
... I've heard there could be ~1000 actors in one ad being displayed.
... Even if you could get HTTPS right, there's a lot of issues including malvertising, etc.
... Do you have something about that on your roadmap?

zach: No, but I'd like to do something about that.
... Alternate models are interesting. Selling direct to consumer, for instance.
... Ad blockers are scaring publishers.
... Need to diversify.

bhill2: One thing that might help would be to use automation APIs to load pages, collect violations off the console (webdriver, selenium, etc).
... Set up a server to make a request as soon as the creative is submitted, generate reports.

zach: We have a project aimed at performance, using PhantomJS.
... Might be able to lump in HTTPS as well.
... Automation is great.

JeffH: Do you give a CSP to the advertisers?

zach: No, but that's a great idea!

JeffH: What are the differences between browsers?
... Are these violations bugs in the browser, or bugs in the advertisers?

zach: I'm still trying to make sense of the data.
... I was surprised to see so many reports from Chrome.
... Not sure if it's a UA string misrepresentation or bugs in the browser.
... <discussion of the data: is Chrome Chrome?>

daniel: Is there no way to associate a report with the request for the original webpage?

zach: Sometimes yes, sometimes no.

<Devd__> .... Terrible puns....

zach: We turned on HTTPS for 24 hours in our business section.
... We had targeted ads in business. We knew they would have run of site, so we knew they would be the only ad.
... In those cases, we can easily identify.
... But there are lots of complexities and randomness.
... Targeting makes it difficult to find bad ads.

daniel: 'unsafe-inline', 'unsafe-eval'?

zach: I'd love to drop them, but ads use them.
... Thinking about 'unsafe-eval'.
... We need 'unsafe-inline'.
... Hard enough to get the 's', once we've done that we can move to more interesting problems.

jww: How successful has outreach to ad networks been?
... Is it at all successful, or is UIR the only thing that works?

zach: Moderate success?
... Mostly focused internally, working on QA.
... QA was focused on visual feedback, so missing the most important parts.
... Beefing up QA internally.
... Next, we need to reach out more to advertisers.

dveditz: Have you seen 'unsafe-dynamic'?

zach: No, but I saw it on the schedule.
... <discussion of XSS vs mixed content protection>

aaj: This is a valuable policy, it just doesn't defend against XSS.

john: Ad bidding is cross-site scripting.

zach: A sanctioned XSS.

Permissions in Context

<wseltzer> bhill2: Permission Delegation to Iframes + CSP embedded enforcement, Feature Policy, and Secure Context Components

palmer: We have a proposal for permission delegation.
... TL;DR: https://noncombatant.github.io/permission-delegation-api/
... What do we do when example.com embeds Google Maps?
... There's a permission request for geolocation.
... But what do we say to the user?
... Does 'example.com' want the permission? Does 'google.com'?
... Does the permission stick to the pair? To the main page? To the embedee?
... How long should the permission stick?
... If you grant `maps.google.com` permission in the context of `example.com` should it stick when loaded under `example.net`?
... We did some studies.
... People in the world don't understand composed applications.
... The location bar is about the limit of what people can handle.
... Not a fan of trying to surface composition via the omnibox.
... Leaves us with some irreducible complexity.
... We'd like to give the least privilege to the most specific principal.
... But there's a limit to the principals that folks can understand.
... Studies corroborate that.
... Omnibox is already a simplification.
... This simplification ~matches the status quo on other platforms.
... Android apps grab data from everywhere. Might be composed, who knows? Can't surface to users.
... Loading .so doesn't change SID. Still running as me after loading `goats.so`.
... We're proposing to tie the permission grant to the embedder.
... Violates the principal of least privilege.
... But it's something that the user of `example.com` can have a chance of understanding.
... The usual means for revoking the permission still apply.
... 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.
... But, we know that reasonable folks can and do disagree.
... We'd love to manage this tradeoff. Perhaps there are other options?
... Maybe we can specify the mechanism, and leave UX to browsers?
... Prove it out in the field.
... Also, this ties into the purple box idea that John raised earlier.
... "Wouldn't it be cool if we could promise to people that X is _not_ a composed application?"
... It feels true that people would want it if they understood it? More research is warranted.
... Composed apps have always posed a problem. Only on the web are we even thinking about going to a better place.
... Which is why I love the web.
... Composed applications that do use special APIs that require permissions are already below our depreciation threshold.
... But we think it's super-useful, but now seems like a good time to standardize a better way of giving users understandable control.
... Now seems like a good time to act.

bhill2: The numbers are low today? I mean, maps is everywhere?

raymes: Maps is a bad example for numbers, because the embedder passes in a location when loading the map.

john: There are ~3 things that make these cases different:
... Native apps vs web apps.
... 1. Native app is a static relationship.

palmer: Not really?

john: You can pull things in, but not in the same way or same frequency as the web.

<bhill2> (npm lol)

john: 2. Apps store. Trusted place to get the app.

palmer: My linux music player will crawl all over looking for a .so to open a file.

john: Sure, for desktop. Not for mobile.
... 3. Apps are signed.

palmer: The permissions we're talking about are the ones that require HTTPS, which is a rough analog.

john: Except that the signature is over the content.
... given those things, we would like to fix signatures, for instance.
... require CSP without 'unsafe-*'

ccowan: I've spent ~20 years with least privilege. It's a bad idea to drill down too far in that direction.
... In this case, it's a question of giving privilege to X or Y or XY.
... Who cares?
... If you don't give permission, they still have your location.
... Users don't care.

palmer: I think they do care.
... One company that has yelled at us about this serves an iframe that uses getUserMedia.
... Our proposal is for anything that requires a permission prompt.

ccowan: The responsibility belongs to the embedder.

palmer: Yup. We think that too.
... Embedee only gets permission upon explicit delegation.
... Zach talked about auctions.
... It would be cool if Wired could simply not delegate permissions to ads.
... They can't do that today.
... Relates to Feature Policy.
... Maybe can fold into that proposal.

aaj: What's the proposal?

palmer: <iframe src="..." permissions="whatever goats more-goats">
... The permissions attribute delegates the "goats" permission to "...".
... Permission grant is to the top-level site.

dveditz: What about nesting?

palmer: I don't know?

raymes: I'd imagine we'd simply propagate it down.
... Capability passed from the embedder, who can then do things.

danielb: What happens today when iframes request permission?

dveditz: Firefox shows the domain of the requesting frame.
... I think gUM is top-level only.

danielb: So with this policy, the dialog would say what?

palmer: `example.com` wants whatever.

bhill2: But they can't even ask without delegation, right?

palmer: Right. The attribute gives the embedee the permission to ask.

danielb: Why the embedder?

palmer: Because that's the one users can perceive.

danielb: But they trust `example.com`!
... It seems bad for us to abuse that trust.

raymes: They can do this today via `postMessage`.

danielb: But that's the site being disingenuous, whereas this is making the user agent complicit.
... Not revealing the third-party that's really asking.

palmer: What does your dad think about `wumble-wumble-wumble.627.ads.com` when he thinks he's on `noodle.com`?
... "Why is my noodle asking me about wumble wumble wumble?!"

john: you're tricking the user!

<Zakim> mkwst, you wanted to ask Joel to enumerate the thing we're dropping from non-secure origins.

<tanvi> is this just for seucre context permissions?

danielb: Why a new attribute, rather than `sandbox`?

<estark> tanvi: I thought it's for all permissions, but now I'm not sure

<wseltzer> [what about the case where an untrusted site mashes with a service the user does trust?]

<tanvi> estark: mkwst says its for all

mkwst: Persistence?

palmer: `maps.google.com` doesn't get the permission persistently. `example.com` gets the permission, and can delegate it.

bhill2: Service worker? Notifications?
... Presumes a background thing.

raymes: The only permission granted to a service worker is push notifications.
... the whole idea of service workers accessing permissions needs careful thought.
... But once a tab is closed, the context is gone, and it has no permission persistence.

jww: All the APIs you're discussing aren't usable inside a service worker.
... Was a limited list.
... It's a bigger question of background permission in general.
... Deprecation of permission grants to non-secure contexts:
... getUserMedia is deprecated.
... geolocation is mostly deprecated.
... appcache offline fallback.
... device motion/orientation

john: Long term?

jww: Policy is "powerful features".
... question is "what is powerful"?
... `localStorage` isn't on our list at this point.

<scribe> ... New powerful features must be HTTPS-only.

UNKNOWN_SPEAKER: Not as difficult; folks aren't arguing about that.
... Notifications are annoying, but not powerful.
... We might get rid of it because it's annoying.
... Push notifications are, because they go through Service Workers.

bhill2: If an origin already has a permission, does it keep them?

<rbarnes> http://memedad.com/memes/881794.jpg

bhill2: Or are they all born naked and without permissions?

palmer: One thing we considered would be to pop up a full top-level document to ask for the persistent permission.
... The pop-up proposal probably isn't great UX, but maybe that persistence would solve the problem.

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.
... We saw the opposite as somewhat surprising to users.

tanvi: Could also just leave it up to the UA.

<Zakim> wseltzer, you wanted to ask about enforcement-by-extension

bhill2: Would be interesting to get data about the usage; would be bad if it broke things across the web.

wseltzer: What about extensions? Could they help?

palmer: I think Chrome exposes via Content Settings enough surface area to build such a thing.
... Of course, it would require all the permissions.

wseltzer: What about things like Stripe, where you trust the embedee but not the embedder?

palmer: That's a big part about why I'm so sad. Principle of least privilege matters.
... "Fall back on audit" is an answer, but not a great answer.

jww: Dishonesty to the user?

palmer: We have to face that problem.
... But it's also the status-quo.
... Iframes post all kinds of jibber-jabber to each other.
... It would probably make you sad.

danielb: Shouldn't justify one evil with another.

jww: Perhaps we have a misunderstanding with the users.
... Granting permission to a page doesn't actually do information flow prevention.
... I have trouble imagining how we'd communicate the existence of other origins.

palmer: "Did you know..."?

dveditz: Users do not know about `badads.com` if/when it requests permission.

palmer: Not justifying because of status quo. Claiming that the complexity is irreducible.

<dveditz> (context <script src=badads.com> in a goodsite.com page

<dveditz> )

<dveditz> not if it's a script

palmer: Linked to user studies in emails.

<dveditz> palmer's proposal works for frames

mattn: We're already not communicating this clearly.

raymes: One of the things that motivated us from the start was double-keying permissions, and communicating that keying.
... It's complicated.

palmer: Communication is important.
... I also don't like falling up to layer 8.
... If you feel that `amazon.com` is trustworthy, they have to uphold that trust.
... This gives them control over their embedees, which gives them the ability to do so.
... If they don't, Taylor Swift will call them on it.
... <beautiful rubbery metaphor about roads, I think>
... We can provide hooks for layer 8 to do it's job.

tanvi: I don't like not being able to grant permission to Stripe, but not the embedder.
... But I don't want to grant to jumbo wumbo.
... Perhaps instead of delegation, the embedder can simply control whether the embedee can request the permission.

<deian> I completely agree with tanvi

tanvi: The distinction is that the prompt would say `embedee.com`.
... Yup, and the embedder wouldn't get access to the data.
... That does make the UI more complicated.
... But this happens so rarely, so yes, in those cases you have a longer control center, but is that a big deal?

<palmer> I love how hard this problem is :)

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?

<JeffH> is there a document or email thread for Tanvi's notion ?

<rbarnes> JeffH: i think it was on the mailing list

mkwst: Sounds like Feature Policy.

<tanvi> JeffH: i'll find the link

mkwst: I like the delegation idea, but, Feature Policy might be a reasonable compromise.

john: Thinking about secure contexts.
... Categories of security?
... * Under policy
... * Integrity-checked
... * Signed
... * Associated domains-only
... We're perceived as slow to implement some powerful features, but this seems like a way to implement them safely more quickly.

aaj: It's tough to do local reasoning about whether or not a given policy will actually usefully protect the page.
... It's totally possible to build an insecure policy that doesn't use 'unsafe-inline', for instance.
... On the other hand, 'unsafe-eval' doesn't negate the strength of a policy that only whitelists well-audited code, etc.

john: Sure. I know there are holes in CSP. I've mentioned two other things, though:

<JeffH> https://igrigorik.github.io/feature-policy/

john: Signed apps are interesting, since there's the ability to kill them in the wild.
... This is a large topic, I'd like to discuss it.

dveditz: On the web, you have pieces from everywhere?

<tanvi> JeffH: https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0048.html

dev: I want signatures in SRI.

dveditz: Proposals for content signing in the IETF.

<JeffH> tanvi: thx

jww: Why do y'all feel the need to have these properties?

john: Aside from security and privacy, there's power. We can assign power usage to apps for background usage, for instance.
... "You can't do that without 1, 2, and 4."

<tanvi> JeffH: that one is a bit dated, but has the general idea.

john: these are the kinds of discussions we're having.

jww: some of these sound like progressive web apps.
... packaged thing that a user can recognize, seen as an app by the user.

palmer: So far we've seen that HTTPS has been barrier enough, as Zach has noted.

john: Not enough carrots. If you had full camera access, you could build "Instagram of the web", for instance

dev: I prefer this kind of thing to extensions/app store.

john: With signed apps, if we had a kill switch, we could grant full filesystem access.

palmer: I'd say it was a mistake to do that for native apps.

john: Containerized, of course.

bhill2: We have a queue. I'm next on it.
... It's tough to reason locally about whether CSP is secure or not.
... Are you trying to protect yourself from accidental exploitation, or are you trying to protect against maliciousness.
... Revocation is a recourse, but it's hard on the web.
... TLS certs, for instance.
... Facebook releases daily, not sure what the revocation mechanism is for that.
... Don't want to revoke root cert because of an XSS on one page.
... The experience we have with the web shows that revocation is really hard.
... Need to think carefully about our threat models.
... Seems like this proposal mashes several together.

<Zakim> wseltzer, you wanted to comment on attribution

wseltzer: One thing I find attractive about this model is that it gets us to attribution.
... Can't trust the platform itself, but we want to trust an actor. A site can specify what it contains, etc.
... This is a component of building up to an application that you can blame.

estark: Is the proposal that these things would be part of the origin?
... Would a page with a CSP be a distinct origin from a page without a CSP?

john: The browser makes runtime checks when granting permissions.

estark: If there's any page on the origin that doesn't meet these things, it can iframe a page that does?

john: Tie into the secure contexts spec.

dev: Secure has a distinct protocol, so different origin.

john: If you're under this, maybe you get distinct storage, caches, etc?
... <discussion of whether there's storage isolation in embedded frames>

aaj: Suborigins are kinda complicated.
... We'll talk about it later, but it's complex.

jww: I don't think we have the plumbing in place for this.

john: I don't see the breakage.
... You build an app, it has new storage.

jww: Could do this as an opt-in super-high-privilege mode.
... Not a hash of the CSP or something. Just a binary set of checklists.

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.
... Specialized use case to put onus on the user.
... Building the ability to do that at scale while maintaining an open platform is difficult.
... Who pulls the revocation lever.

wseltzer: We could expose the data that allows folks to make the decision, as opposed to defining who makes the decision.

jww: I'm concerned that we're talking about things that need high privilege without asking whether we should give those privileges.
... Are we talking about things today that browsers have implemented? Or new things?

john: Both. \
... Future proofing. We're going to keep doing new things, right?

deian: If filesystem is one of those, it's not clear how these four things help?

john: Containerized!

deian: Installation process, app store, etc. They run analysis on these binaries.

john: Not opposed to having an audit requirement.

deian: What's a reasonable policy? Is `script-src https:` enough?

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.
... currently we have "secure contexts" which only means HTTPS.
... It's the padlock from 20 years ago.

deian: Would Google/Facebook be ok with a third-party auditing their code?

john: Maybe we need X of these for Service Workers.

jww: before HTTPS, a user agent can't tell the user anything about who they're talking to. it's a baseline.

dev: But without pinning, that doesn't mean anything.

jww: Sure, this is why we're trying to make HTTPS better.
... There's a goal which is to tell the user agent who they're talking to.
... Well-defined, if imperfect goal.
... Would love to know what specifically we're trying to get at.
... Shutting down openness to some degree.
... Feel ok about HTTPS because of a well-defined goa

john: Security, privacy, performance.
... Reducing the risk of injected code that uses powerful APIs in some malicious way.

jww: Attribution of the executing code?

john: Partially. Also, people make mistakes and write vulnerable apps.

estark: Isn't that what feature policy is about?

<JeffH> mkwst: u want scribe help?

john: that's the top-level saying "I don't want X", not the UA saying "You can't have X."

bhill2: Analogy to default CSP for chrome extensions?

raymes: People generally agree that these are good things?
... Perhaps we restrict a feature if there's a reason. Website X gets Y if it does A, B, and C.

crispin: It's possible to be totally secure and malicious at the same time.

john: These are about reducing the risk of compromise. Necessary but not sufficient.
... Also:
... * no mixed trust.
... * synchronized security state

deian: Seems like a new definition of a secure context.

aaj: If you're worried about XSS protection, and that's sufficient for powerful features...

john: Also reducing the dynamism: I'm deploying X, Y, and Z, and only those.

aaj: Most of these criterion don't actually help you.
... An app with an XSS bug will be able to meet these criteria.

mkwst: I think the suggestion is that the whole blob of everything is signed.
... <missed some things>

dev: The filesystem example is worrying you too much.
... The question is whether HTTPS is enough, or whether we can add more criteria to the secure contexts spec.

crispin: Web apps in a store solve this problem neatly.
... signed, authenticated, embedded web control, etc.
... Giving that powerful capabilities seems reasonable.

deian: Would rather give a website a permission than downloading an app the permission.

crispin: I'd rather give a packaged app from a store the permission to do whatever.
... <discussion of XSS in apps>

john: It would be nice if we could enable powerful apis when developers do X, Y, and Z.

jww: So let's do that, and not go to a store.
... Let's not rely on stores as the end result.

rbarnes: John is asserting that if we want web to have more permissions, we need to make them more like native apps.

JeffH: Web app vs web site?

<rbarnes> (note: i do not necessarily agree with that position)

crispin: Packaged app. Manifest. Know the principles.

jww: Would rather have a set of goals than a list of features to look for.
... Attribution? Seems useful.
... Reduce XSS?
... Maybe a few other things.
... 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.

john: We're already at the point where different vendors have different opinions about what's fine on the open web.
... Let's define a set of levers that can be pulled.
... And let Edge, Chrome, etc. define different restrictions based on those levers.

crispin: We have apps stores. If you want apps, write a Windows app or an Apple app.

danielb: Just proposing new mechanisms for the purposes of attribution, etc. Not claiming that they are requirements.

john: Right. Requirements can be per-browser.

danielb: You still need discussions around permission requirements, delegation, etc.

jww: To be clear, I don't think this is a wrong thing to do, I'm just trying to find the goals.

bhill2: I liked Elisabeth Morant's talk at trustycon:
... Not a question of access or not, but how much you get.
... If you go here every day, maybe you get a lot.
... Reputation, scoring, etc.

palmer: Choosers mitigate many of these risks.

crispin: I love choosers until Dropbox asks for root access.

palmer: I want Drobox to read `/Users/palmer/noodle`, but not `/Users`

dev: If it's long-lived, john is proposing doing something beyond HTTPS.

jww: The green lock doesn't convey enough information right now.

bhill2: There are ways to deprecate legacy features, make the platform more secure by default.
... Misfeatures like `document.domain`, etc.
... We probably need to move on.

Survey of current WebAppSec Portfolio

<dveditz> scribenick: dveditz

<JeffH> bhill2:

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)
... or star is "lack of outstanding issues"

<JeffH> ...items in blue have lack of outstanding issues

bhill2: there is a lot going on!

<JeffH> ...things in black with blue stars have strong proposals

<scribe> scribenick: JeffH

UNKNOWN_SPEAKER: how do we prioritize this list in order to deliver a platform that's relatively in sync?
... notes that many items lack more than one impl

<dveditz> devd: as a web author I'd love to know what has a full implementation

<dveditz> ... as a baseline. CSP 1, maybe 2, and SRI I think

dev: have a baseline of things that do have 2 or more impls (eg a double dot)
... < bhill adds count of impls to various items >
... ok, what is not impl'd and what's the priority of those things?

mkwst: what's the key things for browsers to restrict in order to reduce ambient authority
... so CSP is pretty impt -- eg unsafe-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
... things like suborigins take longer to impl, but they're impt

dev: another factor is how many webapps are using a particular feature...

mkwst: another top item is removinig barriers to migration to HTTPS -- rbarnes 2nds

rbarnes: e.g. upgrade insecure... <others>
... twitter wants to migrate t.co and needs Referrer Policy

mkwst: if you impl the 'origin for referrer policy' then you're a ways down the road (which road?)

bhill: mixed content in geeneral, then there's the "block-all-mixed-content" directive (?)

<wseltzer> [2 half ticks on mixed content are the lack of block-all-mixed-content]

rbarnes: wrt HSTS priming would fix ~ 1.5% of mixed content

?: is there a discussion to have wrt prioritizing ?

bhill: crispin: if u were going to impl one feature in next yr what would it be?

crispin: 'localhost'

<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 :)

bhill: present top two are https migration and CSP2 -- what's next two

<devd> hahaha yeah rbarnes

<devd> but I think the biggest enabler of https has been letsencrypt not w3c

bhill: if u want to have a captcha and a map etc -- unsafe-cynamic (in csp3) is a key feature

<rbarnes> devd: did you not listen to zack's comments? getting a cert is not the barrier for big sites

mkwst: SRI is also getting some traction -- have 2 solid impls, more would be good, see it as valuable

tanvi: what about the cookie specs

<devd> lets chat after the meeting .. I actually don't think what I am saying is at odds with what zack said

bhill: wrt cookies: there's 'csp cookie controls" and then several in ietf

joel: secure atrtribte cookie stuff is impl'd, landing in dev channel soon

bhill: adds CSP Priming to list

mkwst: getup has adopted same-site cookies

<devd> *github

mkwst: doesn't think entrypoint reg is very impt -- same site cookies addresses largely
... csp embedded enforcement -- ad folks don't like it -- thinks something is there regardless
... csp cookie controls is "small" and ought to be progressed....

<wseltzer> Feature Policy draft

mkwst: it iterates on 'content performance policy' (?)
... so it might make sense to move the csp cookie policy to the feature-policy spec
... .... 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...

bhill adds "origin defaults/pins for CSP / CORS" to list on board

mkwst/dveditz: wondering about fixing behaviors in CORS but it is all server-side and tough to figure out what the issues are

bhill: one issue is not being able to propogate creds (ambient authn cookies?) cross-origin via CORS-authz'd requests (?)

<wseltzer> [^ through redirects]

bhilll: UI Security is something to not forget

johnw: that spec is tough to understand....

<wseltzer> [the ED is very different from the published WD]

bhill: editors' draft is very different, imperative & declaritive APIs, presents frame-raising approach....

<scribe> ...new spec tries to fix the gpu-bottleneck issue

<rbarnes> tbh, this seems like it could be a separate wg

UNKNOWN_SPEAKER: only tell the querier whether they are obscured or not

<rbarnes> not really sure the right expertise is in this room

<rbarnes> (this == UI sec)

<dveditz> it's explicitly in our charter though

palmer: there's an 'intersection observer' API

bhill: ed's copy of ui sec is similar to 'intersection observer'
... but has a slightly diff characteristic that gives stronger assertions
... diff impl strategy

johnw: will it work in a webview context?

dveditz: webview won't know the app is 'on top'

bhill: you aren't really in web context when in web view
... if webview is in malicioius app, u have bigger issues

dev: priority is jsut to get more browsers to impl CSP2
... csp2 helped us to migrate to HTTPS

bhill: seems top choices for impl are CSP2 and upgrade-insecure

mkwst: referrer policy is close impl-wise

bhill: what here is a get-off-out-plate ?

mkwst: has heard that from Moz wrt Cred Mgmt ?

rbarnes: we going to talk internally about that....
... wrt UI Sec -- is related to rendering and such that we don't know about here....
... it fulfills a sec purpose but relies on things we aren't familiar with

bhill: doesn't think it make sense in diff grp due to the sec component -- moving may cost more than leaving it here
... IPR issues on moving it

mkwst: chrome prob not impl csp pining as-written
... thinks it needs to be more generic
... defining a more general pining mech would be more interesting...

dveditz: somilar to EPR....

mkwst: maybe bundle into manifest spec ?
... csp pining hasn't gone far enuff to have worked out all the issues

johnw: some of these things under consideration -- see the webkit page
... 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
... webkit blog is getting more active
... note that CSP2 is in Safari Tech Preview

<wseltzer> john: strong user story helps. We didn't really hear that for CSP1, but do for CSP2

<wseltzer> devd: SRI

bhill: hsts priming

mkwst: will impl when chrome impls --

is hsts specific to browsers

mkwst: that spec reverses the order of hstas upgrade and mixed contexnt checking -- that's likely bwsr specific

<wseltzer> [conversation about HSTS work in IETF, coordination]

<wseltzer> john: HSTS supercookies discussion?

<wseltzer> JeffH: whenever you set state on client, there's some tracking potential

<wseltzer> john: private browsing?

<wseltzer> mkwst: mnot is drafting a doc on considerations for private browsing

<wseltzer> devd: request for cookie prefixes

rbarnes: ponders way to perhaps not do hsts priming in webappsec ?

<wseltzer> ... privilege reduction is valuable; we want to subdomain isolate without 3d-pty cookie blocking

<wseltzer> ... so cookie prefixes.

<wseltzer> ... document.cookie session fixation

<wseltzer> ... "cookies lack integrity" paper at Usenix Sec

<wseltzer> ... host cookie prefixes

<wseltzer> ... it's not just trying to avoid 3d pty cookie blocking, because it's our own domain, just less trusted content

<wseltzer> ... dropbox uses it since chrome supported

<wseltzer> ... protect user authentication

<wseltzer> ... host cookie is impossible without browser support

<wseltzer> ... If you're not HSTS + include subdomains, someone can interfere

<wseltzer> dveditz: cookie prefixes require secure

<wseltzer> mkwst: require secure attribute on the cookie

<wseltzer> john: secure and insecure cookies share jar

<wseltzer> mkwst: cookie prefixes require secure attribute

<wseltzer> jww: secure attribute can be set only by secure origins

<wseltzer> mkwst: but we broke the web, and then unbroke it

<wseltzer> jww: cookie priorities in chrome

<wseltzer> mkwst: not breaking the web, breaking internal-to-google sites

<wseltzer> john: any problems with existing cookie jar?

<wseltzer> jww, rbarnes, dev: prefixes are easy, small number of sites setting secure cookies from insecure origins

<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

<wseltzer> [adjourned]

- DRAFT -

Web Application Security Working Group F2F

16 May 2016

Attendees

Contents