Skip to content

Latest commit

 

History

History
107 lines (63 loc) · 8.34 KB

2022-11-16-minutes.md

File metadata and controls

107 lines (63 loc) · 8.34 KB

Web Application Security WG

Wednesday, November 16th: 17:00 UTC (09:00 California, 12:00 Boston, 17:00 London, 18:00 Berlin)

Attendees

  • You?
  • Arthur Sonzogni (Google)
  • Dan Veditz (Mozilla, Co-chair)
  • Mike West (Google, Co-chair)
  • Daniel Huigens (Proton)
  • Camille Lamy (Google)
  • Artur Janc (Google)
  • Wendy Seltzer (W3C)
  • Sam Weiler (W3C)
  • Balazs Engedy (Google)
  • Ian Clelland
  • Jun Kokatsu

Agenda

Minutes

Credentialless IFrames (mozilla/standards-positions#628, @ArthurSonzogni & @smaug----)

Arthur S: Previously known as "anonymous iframes"; renamed to "credentialless iframes". Follows COOP, COEP: credentialless. Things started because of side-channels like spectre. Site isolation was an answer. Main problem was that it wasn't always enabled, and wasn't enabled in all browsers.

...: As a consequence, we all shipped COEP and COOP: creating an environment in which it was safe to use SharedArrayBuffer. But, folks complained that COEP was too difficult to deploy: each resource must be allowed by the server to be embedded cross-origin. Third-parties blocked first-parties from opting into isolation.

...: COEP: credentialless now ships in Chrome and Firefox. Most of the resources are "public" resources, but we don't know which ones. COEP: credentialless changes no-cors requests to be sent without cookies, which means that the server has a harder time personalizing the resource, so it leaks less data. We used this to enable isolation even without third-party opt-in.

...: <iframe credentialless> tries to do something similar. Allows us to relax COEP checks on iframes because we load the "public" version of the iframe. Dropping cookies isn't enough, as frames have access to personal data (localStorage, IDB, etc)

...: We'd like to implement a "fresh" context for the frame being loaded in this mode. Fortunately, most of the work for this is already being done by various partitioning efforts creating storage keys in different ways than they were before.

...: Key created from document origin and top-level site is more or less exactly what we need for credentialless iframes. We use a nonce for the document's origin, which means that the storage will never be reused, and we can simply drop it.

...: Two additional requirements: no-opener for popups (to prevent oauth), and disable autofill (to prevent leaking credentials into this context).

...: Implemented with a new credentialless attribute to <iframe>. This is the main point of contention. What kind of attribute to use, how it should work, etc.

dveditz: (mozilla/standards-positions#628) Mozilla is interested in this feature, sees the need for it. Disabling autofill is maybe a strong suggestion, but shouldn't be required. Users should be able to force filling, maybe not a complete block. But big-picture, we agree with the story.

...: Naming: "credentialless" is better than "anonymous".

...: Main concern is that this is a bundle of individual switches that might be useful on their own. Should be part of general flags on a frame like sandbox. There's some tension here, as sandbox without any options provides an opaque origin, but credentials on all of the outgoing requests. <iframe credentialess> is kinda the opposite: you want the origin, but don't want credentials. Also sympathetic to the idea that there's a clear "This is what you use with COOP/COEP." flag for developers. Not entire agreement within Mozilla.

...: Unclear to me whether this mode would be allowed in a page that wasn't cross-origin isolated? Might be an attractive bundle of things that could be used in ways we don't expect.

ArthurS: Intention was to make it available all the time. No use case outside cross-origin isolation. Since this happens only in an iframe, users don't have any way to differentiate the real website in a credentialless mode from a fake version of that site. You don't need anonymous iframes to phish the user.

Camille: If you want the user to log in again in an iframe, it's equivalant to having a phishing page with the exception of autofill. Disabling autofill pushes users away from signing into this context just like it would for a phishing page.

...: Would it help if we had a Sec-Fetch-* header that broadcast whether or not the context was credentialless?

dveditz: Probably? We already have Sec-Fetch-Dest: iframe with mode. We could add credentialess, I suppose.

aaj: I don't mind us adding something in Fetch Metadata for this, but it's not clear to me what developers would do with it. You could prevent your document from being loaded this way, but why would you want to? Most applications that care prevent emvedding outright via X-Frame-Options, etc.

...: Low-risk environment, insofar as no state is available in this context.

dveditz: We expose no-cors mode already.

Camille: We do think that it's helpful to have one keyword for developers that are trying to deploy cross-origin isolation. But we could certainly add popup-with-noopener to a sandbox flag in the future.

dveditz: Other things would be partitioning (less relevant as browsers shift in this direction already), and ephemerality.

Camille: That's a little complicated for the main request; details.

Mike: Anything in sandbox will be exposed via CSP: sandbox, also for main-frame requests. Granular disabling of autofill for those contexts might be user-harmful.

dveditz: We should give browsers the ability to override in cases where it's harmful to users. Shipping as a bundle might be a good thing to do apart from the other stuff.

ArthurS: [Problem with partition and sandbox that I didn't quite catch.] Described here: https://github.com/WICG/anonymous-iframe/blob/main/mozilla-sandbox-proposal.md#supporting-sandboxed-iframe-inside-anonymous-iframe https://github.com/WICG/anonymous-iframe/blob/main/mozilla-sandbox-proposal.md#disallow-xxx-syntax

Camille: Even a fully-sandboxed iframe makes a credentialled navigation, whereas credentialless does not. Also slightly strange from a modeling perspective. Document cannot use the flag on itself: when we receive the CSP header, we've already made the request, so we can't treat it as credentialless.

Mike: Dan, I heard you personally don't object to shipping this set of capabilities in bundle; there might be some additional work we should do to take the primitives in this bundle to rep them individually to devs, enabling them to decide what precise set of capabilities or lack they want each individual frame to have. Is that accurate?

Dan: beyond me personally, agreement that shipping as a bundle is a good thing. I personally feel this is the opposite of sandboxing. What Camille just said about credentialless and sandbox. I'm not wedded to CSP / embedded headers being 1 for 1. Credentiallessness distinct from partitioning, ephemerality. If you start from base of sandboxing and have to turn on what you need, it can be a long list.

Dan: I was wondering, is there any existing attribute we could reuse? only one I could think of was cross-origin on images, not really the right fit.

Mike: remaining topics: CSP, permissions workshop. Does anyone here want to talk about CSP, or keep it on github?

Ian: fine to keep on github for now.

Permissions Workshop

Balasz: Working on next installment of workshop on Permissions. 5-6 December in Munich and remote. Agenda

Plan is for themed discussion sessions on the first day. Open slots on the second day, dedicated to breakouts and unconference sessions, to be determined at the end of the first day. Day1, user needs and high-level topics; Day2, more technical digging into details. There will be in-person and remote participation options. Registration is officially closed, but we welcome further expressions of interest.

Mike: Thanks for pointer, important conversations.