Create 2019-03-20.minutes.md

meetings/2019/2019-03-20.minutes.md

@@ -0,0 +1,147 @@
+# WebAppSec WG - 2019-03-20
+
+Present: mkwst, dveditz, johnwilander, wseltzer,
+estark, weiler, gmaone, pranjal, dveditz, jeffh, jyasskin, koto, ArturJanc ...
+
+Agenda: https://github.com/w3c/webappsec/blob/master/meetings/2019/2019-03-20.agenda.md
+
+## Minutes
+
+MikeWest: borrowing from TAG methods, suggest collaborative note-taking here. Then we copy the minutes to github repo. 
+
+dveditz: For next time, we can play with some video mechanisms. The TAG has something that might work well for us, which also has a queueing mechainsm.
+
+estark: Is this the final time or still in flux?
+
+mkwst: not final. works for Cal folks, doesn't for Asia. could move around
+
+estark: I and maybe other Chrome people have conflict with this time on Wednesdays, other days at this time work
+
+mkwst: if you have time/day preferences please tell me!
+
+### CfC to publish Feature Policy
+
+dveditz: We talked about publishing this previously. We adopted the spec into the WG previously. Any objections to publishing as a FPWD?
+
+jyasskin: does that include echidna auto-pub?
+
+mkwst: Yes. But I'll need some support from folks who know how that works. :)
+
+wseltzer: W3C team will help with that once the FPWD is published.
+
+RESOLVED: Publish FPWD of Feature Policy 
+
+### [Trusted Types](https://github.com/WICG/trusted-types)
+
+koto: We started an origin trial in Chrome ~last month. Working on revisions of the API. Some things have changed since TPAC. There's a [draft specification](https://wicg.github.io/trusted-types/dist/spec/). Starting to adopt it at Google as a pilot. Assessing feasibility of the API, migrating a few frameworks onto the API, seems feasible for now. 
+
+Artur: https://wicg.github.io/trusted-types/dist/spec/
+
+koto: Seems like a useful approach in combination with CSP for those sites. Any questions from folks here?
+
+mkwst: talked with some Mozilla folks about this and they've started a reponse on their standards positions page. Any one else with feedback?
+
+wilander: Queued up for review, no feedback yet.
+
+mkwst: koto's team is very excited to experiment with it. A "developer trial" means developers can sign up for a token and experiment with the API in the wild on Chrome.
+
+### [Origin Policy](https://github.com/WICG/origin-policy)
+
+mkwst: More interest in OP in past couple of weeks and months. Someone on my team has implemented the core support for it, want to extend to the CORS Opt-out part of the spec and then it should be in a good Minimum Viable Product shape.
+... heard some concerns from folks at Mozilla about its cookie-like nature. I think we can address this by advertising from the server rather than the client. A few changes like this to get to a "baked" state, but we're close to a state where it could be adopted into this group.
+... Now would be a good time to look this over and see if you agree. I have an action to rip out the obsolete parts of the spec, but it would still be useful to go over the spec and see if the mechanisms would be workable for you.
+... This could be a good distribution mechanism for Spectre-like mitigation settings, for example. Please have opinions!
+... Any feedback now? [crickets]
+
+### [Fetch Metadata](https://github.com/mikewest/sec-metadata)
+
+mkwst: (used to be called "sec-metadata".) Artur's team has experimented with this feature. We split the single header into four separate headers (rather than a structured header) for better compression, and some feedback this is easier to use.
+
+Mark Nottingham on [Designing Headers for HTTP Compression](https://www.mnot.net/blog/2018/11/27/header_compression)
+
+mkwst: We added a [CORS-mode](https://mikewest.github.io/sec-metadata/#sec-fetch-mode-header) indication to the headers. We added another item to the site-enum, 'none'. Means user-intervention (top-level load from bookmark or typing in URL bar, for example).
+... good discussion on what's 'none' vs cross-site in issue 20, worth reading through!
+
+https://github.com/mikewest/sec-metadata/issues/20
+https://mikewest.github.io/sec-metadata/#directly-user-initiated
+
+mkwst: unfortunately these won't be easy to test in WPT because it requires interaction with browser chrome. We'll have to add some manual tests to WPT. Would be great if browsers could align on behavior.
+... rest of the document has gone through TAG review and should be relatively solid. What's next? Could move this into the Fetch spec through a series of PRs. Or we could adopt it whole in this WG referencing Fetch. What would people like to do?
+
+johnwilander: regarding WPT -- we have the ability to trigger "user interaction" in our own tests. WPT doesn't ahve this?
+
+mkwst: we have specified some common WebDriver APIs that we can do something things, like gestures and clicks in the page. It's possible we could specify APIs to click/enter into browser UI but a common API doesn't  exist in browsers today. A faster route forward would be to specify manual tests for now.
+... Feedback please!  1) do we want to adopt this in WASWG, or 2) push into the Fetch spec.
+
+Artur: from a dev POV it's nice to have security functionality like this be gathered together than buried in the Fetch spec.
+
+mkwst: my opinion mirrors that. easier to digest as a single document. At the same time it's good to have Fetch things live in fetch so they get updated when Fetch gets updated.
+... Currently when we publish a spec it's done. Monolith version 1, version 2, etc. W3C is considering an "evergreen" model. (See https://github.com/w3c/w3process/issues/79#issuecomment-472092730 )
+
+dveditz: Also like it as a separate spec, for similar reasons. Easier to digest.
+
+jyasskin: I always have trouble tracking how Referrer Policy works, which is a separate spec. I don't have as much trouble tracking CSP. They should be easy to read. I'm not sure why there's this distinction between the two, but for me, there is a difference.
+
+wseltzer: Evergreen model is an [active conversation](https://github.com/w3c/w3process/issues/79#issuecomment-472092730). Not an immediate change we can make, but noted that WebAppSec is a candidate user of this potential process. Importantly, it'll give us patent commitments along the way.
+
+mkwst: WG is good for IP-related things. Maybe not important for this spec particularly, but generally important.
+
+### [CORS-only/credentialless mode](https://github.com/whatwg/html/issues/4175) for Spectre mitigation/isolation
+
+mkwst: link to HTML issue worth skimming, plus the following links:
+
+[Long-Term Web Browser Mitigations for Spectre](https://docs.google.com/document/d/1dnUjxfGWnvhQEIyCZb0F2LmCZ9gio6ogu2rhMGqi6gY/edit?usp=sharing)
+[CORS-RFC1918](https://github.com/WICG/cors-rfc1918)
+
+mkwst: clear docs describing the problems and potential solutions. Requiring CORS for every request is a good way to ensure data from various sites only go where those sites want it to go. Alternately, if we go to a credential-less mode sites will get public data and we'll have less worry about Spectre attacks.
+
+wilander: Charlie's document is a good read. Under the "Site Isolation Status" subheading, it mentions the challenge of mobile devices. We might want to "Isolate a subset of sites, including those that users log into". It would be helpful to know which sites a user is actually signed into. That's useful for a number of reasons. It means that the user has interesting data on this site. Also useful for SSO providers. Signal that "I hold knowledge about logins, and would like the ability to log people into sites." Also for authenticated embeds where we use the Storage Access API whether the context has a logged in user in that context. Would be great if we could take that on.
+
+mkwst: Totally interesting. Do y'all have ideas about the shape of that API?
+
+wilander: We do! Emerged in the discussion around Storage Access API. Login providers are willing to jump through hoops in order to do this work. Could tie into Credential Management API or WebAuthN. Might need to use one of these APIs to set the bits, claim the user.
+
+mkwst: It would be great to write things down! I'll try to write something down as well.
+
+wilander: Looking forward to a crisp discussion, at the latest at TPAC.
+
+=jeffh: QQ for John. Is the comment on GitHub that you're referring to the one on whatwg/html?
+
+wilander: https://github.com/whatwg/html/issues/3338
+
+artur: The work that Anne has been doing on CORS-only/credentialless (link above in section title) is really exciting. Feels like the last missing piece of the work we've been doing on cross-origin information leaks in the platform generally. It's somewhat self-contained and elegant. Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, Fetch Metadata all fit together as a bundle, and I'd encourage folks to think about them together. Developers will need to adopt several of these features. Will need COOP as well as something else that will prevent your resource from showing up in an attacker's context (CORP, Fetch Metadata rules, etc). So. I'm happy that it turns out to be pretty sane.
+
+Because these features are a bundle, we should all implement all of them right away. We'll otherwise miss some things that developers will need.
+
+
+### Update on [Mixed Content autoupgrade experiment in Chrome](https://github.com/mikewest/webappsec-mixed-content/blob/master/proposed-level-2-roadmap.md)
+
+estark: We talked a while ago about autoupgrading mixed content in Chrome. We're running an experiment in Chrome. We haven't rolled it back yet, so that's good. Somewhere around 60% of mixed requests have been autoupgraded, 40% failed. Still digging into the data to understand root causes. Extensions? User visible breakage, or just random subresources/ads? Planning on rolling out to a small % of beta channel sometime soon. Looking forward to getting more data on that. Only one bug report, and that was from a person who didn't seem too upset about it.
+
+Perhaps dveditz or other Mozilla folks could comment on whether they have their autoupgrade code around, perhaps reenabling it for a bit would be interesting to gather more data from more vendors?
+
+dveditz: I don't know. Jonathan or Tanvi would be the right folks to talk to.
+
+estark: Safari? Still interested?
+
+wilander: Certainly still interested. Thanks for the numbers! We wanted to work out more of the details on fallback. I think I asked on Twitter what the current fallback strategy is. I'd love to hear more there. Also interested in the kinds of sites where you see failures. Also also interested in the image case, as that even hits Google Image search. Bing said the same thing.
+
+estark: Fallback: No fallback in the experiment. May return to that if we need to, but we hope we can get away without it. My understanding is that other folks would find it similarly difficult to implement. So if we don't need it, let's avoid it.
+
+For the kinds of sites, I'm not sure we can extrapolate too much from Canary/Dev. Big divergence from stable population. We do, however, see that podcasts are a problem. Early data points to podcast streaming sites as a point of failure. Maybe we could carveout `<audio>`: perhaps special-casing a public podcast stream, with some form of streaming SRI. Would be unsatisfying, but could possibly be a reasonable resolution.
+
+For search, it looks like a large percentage of what Google serves in Image Search could be autoupgraded. I suppose that might apply to Bing as well. I'm personally more worried about podcasts than image search.
+
+### [PR](https://github.com/whatwg/url/pull/434) against URL for display in security sensitive surfaces, based on [Chromium guidelines](https://chromium.googlesource.com/chromium/src/+/master/docs/security/url_display_guidelines/url_display_guidelines.md)
+
+estark: We have this doc outlining how Chromium displays URLs in security-sensitive contexts. It would be lovely for folks here to take a look at that document, and the PR against URL. Feedback on both is more than welcome.
+
+### WebAuthN cross-origin usage explicit permissions?
+
+=jeffh: mkwst and I have talked about this in the past. Been ongoing discussions around using WebAuthN in an `<iframe>` where the framing entity is different to the framed entity. mkwst notes that we can do that in the WebAuthN spec, but need to provide guidance to developers to avoid the concerns outlined in [origin confusion](https://w3c.github.io/webappsec-credential-management/#security-origin-confusion).
+
+Doing this might be reasonably tied to some sort of delegation. jcjones suggeted using Permissions API.
+
+mkwst: Send a message to the list, cc jyasskin and iclelland
+
+_Out of time! Oh noes!_