Consider adding a [CrossOriginIsolated] extended attribute.

[mikewest]

We have a [SecureContext] extended attribute that governs whether or not a given construct is exposed within a given context. I'd suggest that something similar would be helpful as we begin restricting access to APIs based on whether or not a given context is cross-origin isolated.

The Securer Contexts proposal talks about this attribute in terms of [SecureContext=Isolated], but I now think it's probably a better idea to create a new attribute ([CrossOriginIsolated]) for this purpose, as it would give us the opportunity to reformulate [SecureContext] in the future to something more specifically related to the aspect of security it actually governs.

That is, for upcoming APIs like performance.measureMemory(), I'd like them to be able to define the API as limited to isolated and secure contexts in a standardized way. Perhaps along the lines of:

partial interface Performance {
  [SecureContext, CrossOriginIsolated] Promise<MemoryMeasurements> measureMemory();
}

That would have the effect of exposing the method only when the context is cross-origin isolated via COOP and COEP (as defined in whatwg/html#4732 (comment)).

WDYT?

@annevk @camillelamy @domenic

[annevk]

Is whatwg/html#5435 still something that is being pursued by Google? (It would be doable in Firefox, but I'm not sure we want to lead with shipping that as well.)

Note that if you have [CrossOriginIsolated] there should be no need to list [SecureContext]. It's effectively a subset.

[mikewest]

Is whatwg/html#5435 still something that is being pursued by Google?

I think so? Either @arturjanc or @ulan pinged me about it earlier this week, and it seems like a reasonable thing to do that this would layer on top of.

Note that if you have [CrossOriginIsolated] there should be no need to list [SecureContext]. It's effectively a subset.

If we keep [SecureContext], I think I'd suggest that folks list both for clarity.

(As part of Securer Contexts, I'd secretly like to deprecate [SecureContext] by making it the default, and annotating all unrestricted APIs with [UnsafelyExposedToNetworkAttackers] or something similar... but that's a bit off topic for this particular issue).

[ExE-Boss]

Make sure to include the Legacy prefix, eg.: [LegacyUnsafelyExposedToNetworkAttackers] or [LegacyInsecureContext], if the former is deemed too long for something that would be listed on many, many¹ APIs.

---

1. I don’t have an exact figure, but I’d expect that at least ⅔ of all Web APIs don’t currently have [SecureContext].

[mikewest]

My hope is that we'd mostly be putting the attribute on interfaces rather than literally every attribute or method. I filed #876, which is probably a better place for that conversation. :)