-
-
Notifications
You must be signed in to change notification settings - Fork 387
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
Spotify Widget Still Rings Home #2746
Comments
Hello! Is this before or after clicking to allow the widget to load? Just checking. |
This is before allowing the widget. It loads before even asking. |
Could you help me reproduce this problem? Do I need to share a Spotify song in Discord somehow? |
Yeah, please follow these steps and it should be reproduced.
In my network logs I see that the 3 Spotify domains are called before even the widget is allowed or even if it is on the screen. I noticed that even if the widget is not rendered yet and is in another chat window, it still rings the Spotify servers. I hope this has been enough. |
Apologies for the delay. This was helpful, but I haven't been able to reproduce the problem. I see a single blocked request to |
Trying this on my own system using Brave: Version 1.22.70 Chromium: 89.0.4389.105 (Official Build) (64-bit) and Windows 10 Version 20H2 and OS build 19042.867. I have turned off brave shields as well in order to keep it simple. Curiously enough maybe it's some sort of caching or something but even after completely relaunching the browser Privacy badger still allows the Spotify widget to load and only seems to replace it after a few seconds. Privacy badger does seem to allow the various scdn domains you talked about @ghostwords even with Privacy badger on. As well as |
As well when and if Privacy Badger correctly blocks the widget from loading seems to be completely random for both. |
Thank you for confirming it. I was suspecting it only occurs on my machine. |
With brave shields on the difference seems to be by allowing third party cookies that changes the results with both fingerprinting and ad block both set to off. Essentially allowing third party cookies seems to be the factor whether privacy badger allows it to load parts of it first or block it correctly. |
Changing |
If you see this happen when you restart the browser in a profile configured to reopen previously open tabs, you're probably running into #1845. Privacy Badger takes a little time to initialize itself. Since the browser doesn't wait for Privacy Badger when restoring tabs, it's possible for requests to go through before Privacy Badger is ready to deal with them. If this happens outside of browser restarts, if you can reproduce just by opening a new window/tab and visiting Discord in an already-open browser, could you see if you can reproduce this in a new browser profile with a fresh installation of Privacy Badger (and no other extensions/all browser settings left to default values)? Also, is this behaviour Discord-specific, or can you reproduce on other sites with embedded Spotify widgets? Let me know if you'd like me to find and post some examples. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I tried it on a fresh installation of Firefox (Version 87.0) on a fresh VM and yes it seems that you are right. It did not contact those domains until I manually allowed it and it was working as intended. So now that the issue has become evident is there a way to force Firefox to wait for the page load or are there any fixes for it? |
So to be clear, is this the same issue as #1845? When you wrote |
Yep, the steps are identical. I also tried reloading the page and opening discord in new tabs or via different links but it seems that the Spotify widget is successfully getting blocked and only contacts their domains when I actually allow the widget. |
Sorry, I'm still confused. If you can reproduce in an already-open Firefox browser, then this isn't the same as #1845. Could you clarify? What is different between the new Firefox installation where you can't reproduce this problem, and your current Firefox where you can? |
This happens outside of browser restarts for me and restoring brave settings to default corrects the problem, because third party cookies are blocked. Turning off brave shields to imitate what a chrome user might experience yields the same issue. If you could provide some examples of Spotify widgets I can check. |
I can still reproduce the error in an already open Firefox. Sorry for not making it clear. In my current Firefox, I have some addons and the config is a bit modified. In the fresh Firefox, there are no extra addons installed (minus Privacy Badger) and there is the default config. I have no idea which configuration variable or addon is messing up with Privacy Badger's operations. |
Weird, curiously I can't reproduce what had happened earlier, it seems to have fixed itself. |
Browser: Firefox 86.0
Issue: The Spotify widget makes a connection to their servers even though Privacy Badger says that it has 'replaced' the Spotify widget.
Discovered on https://discord.com/app/
The Spotify widget contacts the following domains:
dealer.spotify.com
i.scdn.co
open.spotify.com
The text was updated successfully, but these errors were encountered: