Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider requirement for cross-origin isolation #41

Closed
sethbrenith opened this issue Apr 2, 2021 · 6 comments
Closed

Reconsider requirement for cross-origin isolation #41

sethbrenith opened this issue Apr 2, 2021 · 6 comments

Comments

@sethbrenith
Copy link

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:

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
Copy link

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
Copy link

shhnjk commented Jun 9, 2021

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
Copy link

shhnjk commented Jun 16, 2021

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
Copy link

annevk commented Jun 16, 2021

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

@shhnjk
Copy link

shhnjk commented Jun 16, 2021

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 added a commit that referenced this issue Jun 16, 2021
As per the results of the WebAppSec WG discussion, remove the dependency
on cross-origin isolation. Update the Privacy and Security section of
the spec accordingly to illustrate the security considerations made.
acomminos added a commit that referenced this issue Jun 16, 2021
As per the results of the WebAppSec WG discussion, remove the dependency
on cross-origin isolation. Update the Privacy and Security section of
the spec accordingly to illustrate the security considerations made.
acomminos added a commit that referenced this issue Jun 18, 2021
As per the results of the WebAppSec WG discussion, remove the dependency
on cross-origin isolation. Update the Privacy and Security section of
the spec accordingly to illustrate the security considerations made.
acomminos added a commit that referenced this issue Jun 20, 2021
As per the results of the WebAppSec WG discussion, remove the dependency
on cross-origin isolation. Update the Privacy and Security section of
the spec accordingly to illustrate the security considerations made.
acomminos added a commit that referenced this issue Jun 20, 2021
As per the results of the WebAppSec WG discussion, remove the dependency
on cross-origin isolation. Update the Privacy and Security section of
the spec accordingly to illustrate the security considerations made.
@acomminos
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants