Reconsider requirement for cross-origin isolation

[sethbrenith]

During Edge's extended origin trial of this API, we received feedback from a site owner that the requirements for COOP and COEP make the feature useless to that site. This is the case for any website which includes third-party content and can't force that third-party content into compliance with COOP and COEP. We know that requiring "cross-origin isolated" is sufficient for preventing additional information leakage from timing attacks, but is it necessary? What other strategies would work? A few ideas:

• Limit the maximum sampling frequency if the page isn't cross-origin isolated
• Don't expose timestamps in the report, like requested in Support for collecting profiles without timestamps #15, if the page isn't cross-origin isolated
• Keep the timestamps but add noise so that they're no better than repeated calls to Performance.now
• Add some randomness to the sampling interval, which is a good idea anyway for data quality as explained in Fair sampling with very low sample rates #4

As mentioned in the discussion on #1, "FB is amongst a very small set of sites on the web that is effectively exclusively powered by 1P content, which makes exposing traces simple to reason about." I'm concerned that the requirement for COOP and COEP over-fits this feature to Facebook's use-case rather than providing a general-purpose tool for the rest of the web.

If ideas like these were already discussed and discarded prior to adding the cross-origin isolation requirement, could you please point me toward meeting notes or other documentation supporting that decision? I didn't find anything in GitHub issues, but I know that discussion takes place across various sites and in-person meetings so I may have not looked in the right place.

Thanks!

[magenish]

Excel Online team also believes COI requirement is not needed for this API.
After deep discussions on that decision we came to understanding that the API does not expose any new vulnerability to time channel attack as the timings from the API output is the same as perfromance.now(after the clamping obviously).

Further more the sampling interval of the profiler is in millisecond resolution as well, so again nothing new is exposed here.
@acomminos, if you agree on the timing concern, can we update this part(https://wicg.github.io/js-self-profiling/#privacy-security) in the spec to reflect our agreement on this understanding.

Another aspect when requiring COI is avoiding leaking information form cross-origin scripts.
However this is already being handled inside the API by avoiding function names introspection if the script is from different origin and did not provided CORS header, just as in error.callstack AFAIU.
Therefore we are clear here as well.

Taking those points into account we strongly believe that the COI in this case is redundant.

Thanks.

[shhnjk]

I have done a security review of JS Self-Profiling API, and I think that this API is safe without COI requirement, as long as we have same-origin or CORS check.

CC: @arturjanc

[shhnjk]

This has been discussed in W3C WebAppSec meeting (minutes). We had consensus among folks who are familiar with the API (i.e. Microsoft and Google) that COI requirement is not necessary.

Next steps for this issue would be to add more detailed security consideration section, and then remove COI requirement from the spec.

CC: @acomminos and @annevk

[annevk]

I don't understand what a same-origin or CORS check means in the context of this API. Could you elaborate?

[shhnjk]

This API will only do sampling of functions defined in same-origin script or CORS satisfied cross-origin scripts. Which means, while cross-origin no-cors scripts can still execute in the document, functions defined in those script won't appear in trace.

This is the similar concept as what we have today in script error event, where you can only get detailed information about line and column number, only if the script is same-origin or CORS satisfied cross-origin scripts.

[acomminos]

As per the discussion in the WebAppSec WG and @shhnjk's analysis, the API is no longer requiring cross-origin isolation. Closing.