Open cooperq opened 10 years ago
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:
Alice 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.
OnBeforeRequest() do
if requestDomain in exceptionDomains
and request domain would be blocked or cookieblocked do
displayPopup('the action you are taking would need to allow this domain to track you. Do you want that to happen?')
if yes then move domain to user whitelist
if no then do nothing
done
done
/* This is a dictionary containing all of the domains that user may want to make an exception for. The key is the domain that will need to be allowed and the value is an array of the acceptable 1st party domains to show this popup on. If the array is empty then we show the popup for any request to the domain */
exceptionDomains = {
'login.disqus.com': [],
'apis.google.com': ['youtube.com'],
}
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.
exceptionDomains = [
'https://apis.google.com/u/0/wm/4/_/diagnostics/',
'https://disqus.com/next/login/',
]
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 unblock .kinja.com unblock stats.g.doubleclick.net
The last one surprises me, but without it also being deactivated login fails entirely.
Instapaper is still broken :cry:
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:
[...] disables logging in with google, facebook and other IDs on some websites. [...] For example, it is not possible to use draw.io services if this addon is enabled - integrations with google are not working and privacy badger closes all windows that attempt to authenticate with google services. Similar with Shazam - not possible to login with FB.
We've been getting a number of related complaints lately regarding not being able to authenticate through your cable provider to watch the Olympics. I think they all have to do with Privacy Badger "cookieblocking" auth.adobe.com
(1fda4d93fbc4d0ce4b60f8be48fac22e1a7679f7), which breaks the authentication flow.
To be clear, auth.adobe.com
being on the yellowlist is not the problem (blocking it would also break the flow); it's just that the yellowlist is not the right tool to work around site breakages where sites require third-party cookies/localStorage to function.
Looks like auth.adobe.com
subdomains are part of Adobe Primetime's SAML SSO authentication, which may be a distinct problem from OAuth authentication.
Initial solution ideas:
auth.adobe.com
everywhere, we may then keep a MDFP-like list of site and required-for-functionality third-party domain mappings. For example, auth.adobe.com
could be allowed on stream.nbcolympics.com
and espn.com
pages. It would be good to limit the privacy exposure further by only allowing the required third-party domains when the user's intent is clear. Can replacement widgets help?This needs more technical investigation.
This happens on SoundCloud, for example:
fqdn: soundcloud.com
block: secure.quantserve.com,dpm.demdex.net,5352434.fls.doubleclick.net,5485101.fls.doubleclick.net
cookieblock: www.facebook.com,apis.google.com,staticxx.facebook.com
noaction: style.sndcdn.com,a-v2.sndcdn.com,www.gstatic.com,www.googletagmanager.com,ssl.google-analytics.com,connect.facebook.net,vt.myvisualiq.net,tapestry.tapad.com,t.myvisualiq.net,sb.scorecardresearch.com,idsync.rlcdn.com,bcp.crwdcntrl.net,ssl.gstatic.com
version: 2018.4.23
message: Login modal dialog buttons don't work.
fqdn: soundcloud.com
block: 5352434.fls.doubleclick.net,5485101.fls.doubleclick.net,googleads.g.doubleclick.net,securepubads.g.doubleclick.net,www.google.ca,sb.scorecardresearch.com,ad.doubleclick.net,cm.g.doubleclick.net,ads.yahoo.com
cookieblock: platform.twitter.com,www.google.com,www.facebook.com,analytics.twitter.com
noaction: c1.rfihub.net,connect.facebook.net,at.amgdgt.com,static.ads-twitter.com,va.sndcdn.com,i1.sndcdn.com,style.sndcdn.com,a-v2.sndcdn.com,www.gstatic.com,www.googletagmanager.com,ssl.google-analytics.com,rules.quantcount.com,bcp.crwdcntrl.net,loadus.exelator.com,idsync.rlcdn.com,cf-hls-media.sndcdn.com,wis.sndcdn.com
version: 2018.4.10
message: When I try to sign in with Google, nothing happens and I don't get logged in.
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:
We currently have multiple different heuristics for allowing third-party cookies in limited cases: ... Redirect-based. When domain a issues a first-party redirect to domain b, we trust b as a third-party to domain a pages for a short time. This handles single sign-on portals which rely on third-party cookies instead of oauth-based methods. OAuth detection. Practical implementations of oauth sometimes require some third-party cookies to be allowed in order to function correctly (Google is the main case). This heuristic detects the OAuth flow in the browser and allows cookies for these cases.
-- https://github.com/cliqz-oss/browser-core/issues/58#issuecomment-394285634
Edit: Here is their onBeforeRequest
"pipeline". We are interested in redirectTagger
and oauthDetector
.
Brave seems to allow accounts.google.com
by default.
When ["Allow Google Login in extensions and third party sites"] is enabled:
- It adds a third-party cookie exception for accounts.google.com so sites using Login with Google can work correctly.
- It enables chrome.identity for extensions so extensions like Google Keep and Google Calendar can retrieve an OAuth token from google to authenticate users. The OAuth token can be used to retrieve personal information like email id, profile. You can read more about chrome.identity here: https://developer.chrome.com/apps/identity
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? :)
In addition, Total Cookie Protection makes a limited exception for cross-site cookies when they are needed for non-tracking purposes, such as those used by popular third-party login providers. Only when Total Cookie Protection detects that you intend to use a provider, will it give that provider permission to use a cross-site cookie specifically for the site you’re currently visiting. Such momentary exceptions allow for strong privacy protection without affecting your browsing experience.
-- 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