See also: IRC log
<wseltzer> Meeting: WebAppSec F2F
<wseltzer> agenda: https://docs.google.com/document/d/1KQ_TWHBc1QBn4Xf2yJ7AYDQumuJioaGDfxbzwIJjxOI/edit#heading=h.vvzbltm8twb9
<inserted> scribenick: wseltzer
bhill2: reviewing agenda
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]
<estark> related thread: https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0421.html
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?
<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
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
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
<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.
<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.
<dveditz> scribenick: dveditz
<JeffH> bhill2:
<JeffH> ...<attempts to present taxonomy of webappsec work on proverbial table>
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]
