Implementation differences with "Strip URL for use in reports"

[evilpie]

At least Chrome and Firefox don't match the current specification of 5.4. Strip URL for use in reports. I haven't tested Safari.

Both browser treat ws(s): scheme like http(s): and return the whole URL (without fragment etc. of course). I guess I can see how both of these types of scheme are pretty similar, so this doesn't seem all that controversial to me.

The bigger difference is in regards to URLs used for reports generated by blocking frame-src and object-src navigations. To avoid leaking the whole URL when blocking (or reporting!) cross-origin navigations inside a frame, both browsers restrict the URLs to just the origin.

https://issues.chromium.org/issues/40084987
https://bugzilla.mozilla.org/show_bug.cgi?id=1790345

[annevk]

Browsers should never be able to report ws or wss though. By the time CSP is reached those have long been normalized to http and https. So if they do end up in a report that would be a bug.

[evilpie]

Browsers should never be able to report ws or wss though. By the time CSP is reached those have long been normalized to http and https. So if they do end up in a report that would be a bug.

All browsers use wss: in my testing: https://tomschuster.name/testing/csp-websocket-url.html

[annevk]

Given that the request we create for Fetch (which then asks CSP) isn't created after those are normalized that doesn't match any specification: https://websockets.spec.whatwg.org/#concept-websocket-establish

[mikewest]

• @yoavweiss, who's been poking at this algorithm in other contexts.

[yoavweiss]

I mostly worked on moving the algorithm to Reporting and fixing it up. I don't have strong opinions RE what it should do with ws and wss schemes.

Given @annevk's comment above, it sounds like the right thing to do would be to align the implementations on what the spec says, rather than the other way around.

[evilpie]

Given @annevk's #735 (comment), it sounds like the right thing to do would be to align the implementations on what the spec says, rather than the other way around.

This might apply to the WebSocket scheme.

However, I think we should instead focus more on the frame-src/object-src behavior. Here the current behavior in browsers is required to prevent leaking (more) sensitive cross-origin information. It would actually be best if we could come up with something to stop leaking even just the origin.