See also: IRC log
<bhill2_> anyone want to scribe today?
<bhill2_> thanks
<jochen___> yes :)
mkwst: If time allows, it would be nice to chat about https://github.com/whatwg/html/pull/2373.
bhill2_: Nothing else so...
<bhill2_> https://www.w3.org/2011/webappsec/draft-minutes/2017-04-19-webappsec-minutes.html
bhill2_: Objections?
<crickets>
scribe: No objections, yay.
<bhill2_> Blink will now check the full ancestor stack for X-Frame-Options: SAMEORIGIN
<bhill2_> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/fsDaKFqvU20/6swtcHVrAQAJ
scribe: `X-Frame-Options: SAMEORIGIN` changing in Blink to check the whole ancestor chain.
... Yay.
<bhill2_> https://wicg.github.io/isolation/index.html
estark: Summarize proposal, and discussion on list.
... Proposal currently in WICG.
... Allows sites to protect themselves from malicious web content.
... Use-case is most likely security-critical, high-value applications.
... Not targeting at wide audience.
... Won't be broadly-applicable. Useful instead for sites that would trade off functionality and effort for isolation.
... A few ways we're thinking of isolation:
... 1. Best practices: automatic X-Frame-Options, SameSite cookies, etc.
... 2. Navigation restrictions: currently defined as a ServiceWorker event, must explicitly allow navigations, closed by default.
... 3. Hint to turn on process isolation in browsers that support it.
... 4. Separate storage: cookies wouldn't be present if origin loaded outside the isolated context.
... Two threads on the list:
... https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0054.html
... https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0071.html
... In the first thread, the two main issues were:
... 1. Can isolated sites be framed?
... Rough consensus that it might be useful, but would complicate the implementation a lot.
... 2. Possibility of one tab with `a.com` in isolated mode, another with `a.com` in non-isolated mode.
... Force-refresh? Kinda messy, but maybe a solution.
... Other thread, neutering `WindowProxy`
... Perhaps something we can expose independently from isolate-me.
<estark> mkwst: seems like a separable portion of Isolate-Me
<bhill2_> mkwst: it seems like a separable portion of isolate-me and could be another primitive that it builds on top of
<bhill2_> ... Artur believes in at least half of it; a.com opens b.com, b.com should have a means to remove that reference held by a.com
<bhill2_> ... postMessage is something we may want to separate from other window properties
<bhill2_> ... b.com opened by someone is something we want strong controls over, but if b.com opens something, might not want to restrict it in the same way
<bhill2_> ... so restricting who may get/keep references to you seems like low hanging fruit, valuable and would be wanted by many sites
devd: Where are we talking about these things?
<bhill2_> dev: are we discussing those future paths here, or should they be github issues?
devd: GitHub? List?
estark: No strong opinions.
devd: GitHub sounds good to me.
dveditz: Don't really have time to debate things here.
bhill2_: I read through the cookies bit of the spec.
... Issue #9.
... Double-keying doesn't prevent subdomain or pre-isolation interaction from leaking in.
... Session fixation, etc.
... Seems important to address.
... Without HSTS `includeSubdomains`, even insecure cookies could leak in.
... Is there a GitHub issue to talk about this on?
estark: Don't think so. I'll file one.
... I agree that's a problem.
... Limiting isolated sites to `__Host-`-prefixed cookies would address part of that. But it's a big restriction.
<dveditz> (part of the quote of me above should have said that this is a great place to raise concerns and add to the list of things to be discussed later)
bhill2_: Can you talk about `allow-isolated-navigation`
estark: The navigation restriction idea is that any navigation request would fail unless a Service Worker explicitly allows the request.
... The developer can still get that wrong. Still relying on them to validate navigations.
... Might prevent navigations from external sites, except to a list of paths.
... Intention is to help with that, but relying on the developer to do so.
bhill2_: Thoughts about doing other things to sanitize things like `window.name`?
<dveditz> ooh, would like that to be a separate feature/restriction/discussion.
bhill2_: Data leaking in might be a problem. Might create a new window, give it a name, then navigate it to an isolated origin.
... If it reads/sinks `window.name`, it might open a hole.
... Might be worth sanitizing them by default.
estark: Anything tat could have been set by another origin should be cleared when navigating in?
<bhill2_> https://docs.google.com/spreadsheets/d/1Mnuqkbs9L-s3QpQtUrOkPx6t5dR3QyQo24kCVYQy7YY/edit#gid=0
bhill2_: Yeah. https://docs.google.com/spreadsheets/d/1Mnuqkbs9L-s3QpQtUrOkPx6t5dR3QyQo24kCVYQy7YY/edit#gid=0 is a good list of things to look at.
estark: Great. I'll file an issue.
dveditz: If the navigation restrictions are enforced by a Service Worker, is a SW required to have an isolated origin?
estark: If you didn't have a Service Worker, we'd fail navigations closed.
mkwst: Also, having a Service Worker doesn't force isolation. You can use one or the other.
<bhill2_> just for the record, +1 to splitting out window.opener control as its own mechanism
dveditz: Sure, just wondering if it would be reasonable to define navigation restrictions without SW, for origins that don't have SW.
ArturJanc: I remember Mozilla folks (Tanvi?) being involved in the spec, discussions.
... Still cooperation between estark and Mozilla?
estark: Yeah. I've talked with Tanvi before she went on leave, still talking with dveditz and ???.
dveditz: We're interested! And busy! Probably won't do anything here until Tanvi is back.
<ArturJanc> great, thanks Dan :)
dveditz: We have a feature called Containers, and we think we can probably build this on top of that feature.
<estark> github issues: https://github.com/WICG/isolation/issues/14, https://github.com/WICG/isolation/issues/13
dveditz: Not starting from scratch.
bhill2_: One random thought: I wonder if some of the restrictions on RFC1918 hosts might be addressed by forcing them into this.
<bhill2_> https://w3c.github.io/webappsec-suborigins/
jochen___: Met with devd to talk about the spec, got internal feedback from folks at Google.
... Trying to go through open issues, and reconcile them with Chrome's implementation.
... There seems to be not super-positive feedback from HTML/Fetch integration questions.
... Trying to figure out what we can carve out as a v1 that adds value, isolates web content that has lower security properties than other content on a domain, but also gets other spec authors on board.
... We end up needing to monkey-patch HTML, change the origin model.
<estark> Changing the security model of HTML might be something that isolate-me needs to do too :(
bhill2_: Can you provide a pointer to the more contentious issues there?
jochen___: One feedback both internally and for Chrome is that the serialization of the origin is somewhat unexpected.
... The idea was originally to make it simpler to debug, but it's confusing.
... Looking into ways of changing that.
... Sketched out a change to `postMessage` https://github.com/w3c/webappsec-suborigins/pull/67
... Anne noted that we should talk about this in a broader way in HTML as opposed to a separate spec.
... https://github.com/w3c/webappsec-suborigins/issues/34, similar questions around the origin model.
devd: I'm more positive!
... We've focused on the spec, trying to make it usable for ArturJanc or Dropbox.
... I think we're most of the way there.
... Emails on the list show Google finds it useful as well.
... Pointing out use-cases that we might want to address in v2.
... It's just a lot of work.
jochen___: My main concern is how we can get to a state where we can ship this.
... Impression is that we'll have a hard time in Blink as long as it requires patching HTML without HTML's buy-in.
ArturJanc: Chance we'll run into similar concerns for isolation/Containers?
... They also somewhat redefine what an origin is.
... Were the concerns specific to suborigins, or higher-level?
devd: I'm wondering whether Isolation can use some version of suborigins.
... Might make integration simpler.
... dveditz mentioned that Containers are implemented.
... How are they merged into specs?
dveditz: "Origin Attributes"
... Not exposed to the web.
... Containers is user-facing, not web-facing.
... But we would likely reuse the internal functionality.
devd: One option is to generalize the notion of origin attributes.
... Each attribute can define its equality function?
... Or we can use suborigins. I prefer suborigins.
jochen___: I like the idea of a more general concept so that we don't patch the security model for everything we try to do.
... Might be worthwhile to try to float this attributes idea with the HTML spec authors.
devd: The current spec talks about "extended origin"
... Might be the right primitive.
jochen___: It would be worthwhile to write down how Isolate-Me might make use of this concept.
dveditz: I don't think it is, for Isolate-Me.
... Internally (in Gecko), the Containers isolation looks at the attribute, but then does a ton of extra work.
... The attribute alone isn't enough.
... They trigger internal behaviors unique to the feature.
... Not just "a different origin".
jochen___: Attributes could define that behavior.
devd: Suborigins kinda do that. Fetch and HTML could thread this "extended origin" check throughout.
... Suborigins will still say what to do when these attributes exist.
estark: The "extended origin" concept seems quite useful for Isolate-Me.
... Otherwise I'd need to monkey-patch each spec that uses "Origin".
... Need to integrate it into the notion of "origin" in one place.
... Much cleaner.
bhill2_: Concrete action?
devd: jochen___ and I will focus on integrating with HTML and Fetch.
... AI for others is to look at the spec to see if it's reasonable.
... I want it to be internally consistent before pushing out to HTML/Fetch.
... So, please review the spec.
jochen___: Right. Continue working on suborigin spec, and get buy-in from other folks.
<bhill2_> https://w3c.github.io/webappsec-clear-site-data/
<bhill2_> welcome, Martin!
msramek: Hi! I'm Martin, working on Chromium implementation with mkwst.
... Clear Site Data implementation is almost ready.
... Just need to polish details.
... Header, origin can instruct the user agent to delete data that belongs to the origin.
... Split into several data types.
... Use-cases involve privacy on the one hand (logout -> clear data) and security on the other (recover from malicious service worker).
... Not sure whether the split between storage types makes sense. Right level of granularity?
... Is the header cachable via Service Worker, and so on.
<bhill2_> mkwst: we've poked the TAG twice to get feedback from them
<bhill2_> ... summary is "looks pretty good, some questions about the naming"
<bhill2_> ... split up into broad buckets: cookies, cache, storage
<bhill2_> ... execution contexts on the fourth hand
<devd> zakim queue +
<devd> zakim queue+
<bhill2_> mkwst: execution contexts is the wrong name, that's chromium specific
<bhill2_> ... browsing contexts maybe
<bhill2_> ... cache and storage is not a good delineation given that we have a cache that is cleared by the storage flag in some browsers
<bhill2_> ... need naming assistance in how to clear things website already has direct control over vs. stuff in networking layers that are not currently clearable by website
<bhill2_> ... currently we wipe all cookies in eTLD+1 (registerable domain) regardless of where you are when calling clear cookies
<bhill2_> ... do that b/c cookies are weird and don't follow SOP
<bhill2_> ... accounts.google.com has the canonical version of whether you are logged in or not, docs.google.com or maps.google.com caches that state
<bhill2_> ... would be weird to clear state on one but not the other that might lead to inconsistencies between subdomains
<bhill2_> mkwst: feedback sooner rather than later would be awesome, please look at it
<bhill2_> devd: what is the user interest of application authors looking at this; we struggled with this - clearing all cookies is hard
<bhill2_> ... protecting against anti-automation often uses cookies, so clearing all of them is rare
<bhill2_> mkwst: google is not going to do this for reasons including anti-fraud
<bhill2_> ... google will use cache and potentially storage clearing
<bhill2_> ... e.g. google+ should delete stuff locally when you logout, not leave sensitive data on disk to extent we can
<bhill2_> ... github has same use case
<bhill2_> devd: knowing that these are issues with clearing cookies, should we address in the spec?
<bhill2_> ... namespace for cookies not to be cleared, b/c otherwise this is useful
<bhill2_> mkwst: we haven't done that yet for complexity reasons
<bhill2_> ... but if you have a concrete proposal, would love to see it
<bhill2_> ... maybe we can work something out
<bhill2_> ... if you know the cookies you want to clear you can already do that via set cookie
<bhill2_> devd: only if you know what you want to clear
<bhill2_> can foo.facebook.com clear cookies set for bar.facebook.com without lots of domain/iframe juggling, even knowing the names?
<bhill2_> JohnWilander: assume appcache is included? also question about HSTS cache
<bhill2_> mkwst: appcache is site data, cleared with that, HSTS cache is treated more like network data
<bhill2_> ... file a bug if you think we've done the wrong thing
<bhill2_> martin: we do delete all network configuration and I would expect HSTS to be part of that but need to check
<bhill2_> martin: appcache is cleared with storage
<bhill2_> mkwst: spec does explicitly mention appcache, take the oppty to skim through and see if categories make sense
<bhill2_> martin: categorization must be somewhat generic due to differences between browsers
<bhill2_> mkwst: different browsers store different things, some of those things aren't spec'ed
<bhill2_> mkwst: please look at spec and file bugs!
<bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0038.html
JohnWilander: I've brought this up internally, but folks are busy with WWDC.
... Not ready to look at it internally yet.
... Need to look more at the Android version of this, then will get back with y'all.
jochen___: Thanks! Just to note, we don't need to bind ourselves to the Android version.
... Maybe use Origin Policy, Manifest, whatever to avoid extra network round-trip.