-
-
Notifications
You must be signed in to change notification settings - Fork 381
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
Privacy Badger breaks some deliberate third party interactions such as oAuth with facebook youtube disqus etc. #137
Comments
This is a similar enough problem to #147 and #142 that I think they can all be solved the same way. Here is the solution as I see it: User StoryAlice visits youtube.com and clicks on the text box below a video to comment. If the necesary domain (in this case apis.google.com) is not already allowed then Alice gets a popup telling her that she needs to allow this domain to take this action, but by doing that she could be letting the domain track her browsing. If Alice clicks 'OK' then the domain is put into Alices white list and Alice makes a comment on youtube. If Alice clicks 'Cancel' then the domain stays as it is and Alice continues on with her day. If Alice trys to comment on youtube again and it is still blocked, then she will once again get the popup. Pseudo Code
|
One argument against any of this is that the user could already do this by just whitelisting the appropriate sites, or the sites could whitelist themselves by posting dnt-policy.txt and that having this feature rewards bigger content providers by making it easier for the user to unblock them. It also puts us in the position of maintaining two whitelists. An alternate proposal is that we just do this for every site on the cookie block list and then we only have to maintain one list of domains. |
Now that I think about this more I don't think that there is any need to have a list of referrers that we care about for each domain. The exception domains could just be an array then, which has the added bonus of giving us a performance boost.
|
Additionally we should only bring up this dialog if privacy badger has automatically blocked these domains. If the user has manually blocked these domains then we should trust their judgement and not bring up this dialog IMO. |
It also breaks Facebook login on the the Kinja-based sits over at Gawker. Workaround is to: unblock *.facebook.com The last one surprises me, but without it also being deactivated login fails entirely. |
Instapaper is still broken 😢 The PB dialog pops up asking whether and when to allow instapaper.com, but the browser is redirected to the instapaper.com website too fast to let you click a dialog button. How about a nice, simple text box in the settings where I can add any domains I'd like to whitelist? |
It is annoying that instapaper does that redirect, I wonder if there is some way to prevent that. I agree that there should be a way to whitelist domains, but text boxes aren't super user friendly. I think that the better way to fix this is to have an options page for privacy badger that shows you all of the domains that it knows about and lets you override the settings for each of them. |
The Instapaper bookmarklet does the redirect because PB is blocking it. The alternative is not working at all. If PB prevented the redirect, it would completely break the bookmarklet. A "proper" interface would be better than a text box, that is certainly true. |
Reopening as #219 has since been removed from Privacy Badger (as part of #951, I think). From a recent AMO user review:
|
This happens on SoundCloud, for example:
|
I'm just writing to letting you know that we had at least one user who wasn't able to login to our web app because of EFF privacy badger. This time it was the combination Spotify OAuth + Spotify-Account-which-was-created-through-facebook. |
We should look into Ghostery's workarounds:
-- cliqz-oss/browser-core#58 (comment) Edit: Here is their |
Brave seems to allow
|
We are also noticing this false blockage issue with google basic auth on our app hosted at abstractops.com. Let me know where we can help to make more progress on this issue? :) |
-- https://blog.mozilla.org/security/2021/02/23/total-cookie-protection/ |
Sometimes when a user tries to use oAuth to log into a site with facebook or google or tries to use disqus to comment on a site or makes some other deliberate interaction with a third party resource it gets blocked. This presents a bad experience to the user who is prevented from using a website in the way they intended. We need to find a generalizable solution to this
Current Workarounds
facebook oauth and comments:
unblock www.facebook.com
unblock connect.facebook.com
unblock static.ak.facebook.com
unblock s-static.ak.facebook.com
you tube comments:
unblock apis.google.com
disqus comments:
unblock disqus.com
google oauth:
unblock oauth.googleusercontent.com
unblock apis.google.com
The text was updated successfully, but these errors were encountered: