Breaks cross-origin requests when logged in on SoundCloud.com

[BinToss]

Disabled

Enabled

Networking Errors

[BinToss]

This seems to be due to a modification of the requests' Referrer Policy. Manually resent requests use the "unsafe-url" policy while blocked requests use the "origin" Referrer Policy.

[da2x]

The extension doesn’t touch any of these headers.

Here’s all the header modifications it does: https://github.com/da2x/save-data/blob/d02ccfbfb1ff311c97b9a3d88f0d768bf1b6ee22/background.js#L27-L30

The server in question may modify what it sends back based on the presence of the header. (Which is kind of the point.) Does the problem reproduce with Chrome on Android set in data saver mode? It sends the same header as the extension.

[BinToss]

So, I can't actually test that with the latest Chrome for Android. It seems Data Saver was replaced with the Lite mode setting which essentially uses a Google-hosted proxy server to compress data.

[da2x]

Lite Mode also adds the Save-Data: on header.

[BinToss]

Chrome for Android with Lite mode did not experience the issue on either the desktop website or mobile website. I also tried Opera for Android with same/similar settings. No issues.

[da2x]

Does it also reproduce after disabling all other extensions and reloading the page?

[BinToss]

Yup.

I discovered now that the initial GET requests don't have headers when I'm not logged in, but they do when I am logged in. When logged in, GET requests' headers use the Origin referrer policy with an origin of https://soundcloud.com/ to request a resource from "a-v2.sndcdn.com". image

Right-clicking the failed GET request in the event log and selecting "Resend Request" changes the header to use the "unsafe-uri" referrer policy, which allows this CORS to succeed.

My findings were irrelevant. This, however, seems more relevant:

There's still very little information to go on by inspecting the request header...

[da2x]

Duplicate of #6.