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