Ensure we work along PrivacyBadger
bushidocodes opened this issue · 27 comments
I've been building a demo app using @solid/react in preparation for a talk I'm giving on Solid to NationJS, a big JavaScript conference in Washington, DC. The app is functionally similar to some of the profile viewers out there, but takes close design inspiration from a certain well known social network.
My MVP is functionally complete and up at https://5bfb1fc2b13fb10671d78e6e--competent-babbage-885c43.netlify.com/. Unfortunately, I can't seem to login using my Community pod using Chrome. Clicking on "Solid Community" in popup.html triggers a request that Chrome seems to block. All other OIDC providers work in Chrome as expected, and Solid Community works in Firefox. It appears that Chrome is blocking the request for safety reasons.
Any ideas?
-Sean
Could not reproduce on Chrome 70.0.3538.102 on macOS.
What version are you using?
I have a similar issue on my work computer, not my personal one. When the popup opens and I click on "Login with solid community", nothing happens.
If I then start the application in a private browser session it works. I think it is most likely due to a plugin like AddBlocker or Privacy Badger blocking the request, but I haven't found a way to verify it.
The console first outputs GET https://solid.community/.well-known/openid-configuration net::ERR_BLOCKED_BY_CLIENT and then it seems like the solid-auth-client repeats it with Error logging in with WebID-OIDC.
I think the solid auth client should be better at reporting this error. For instance by detecting net::ERR_BLOCKED_BY_CLIENT and then inform the user "It was not possible to login - the request was blocked by your browser. Please disable any add blockers for the domain XXX and try again."
Just tried to disable privacy badger - and now it works even in normal browser mode. Fun thing is that it continued to work after I enabled Privacy Badger again. Duh?
This might be related to nodeSolidServer/node-solid-server#921
"It was not possible to login - the request was blocked by your browser.
Probably an't do that, because net::ERR_BLOCKED_BY_CLIENT does not bubble up to JavaScript. The request fails silently from our perspective; same with cross-origin issues.
We can set a timeout, but we do not know the reason.
Note to self: ask people (in issue template?) to list their browser extensions
Yeah, interesting it is not just me... I suppose we should reach out to the Privacy Badger team.
I just check the privacy badger's FAQ. This is what it says:
At a more technical level, Privacy Badger keeps note of the "third party" domains that embed images, scripts and advertising in the pages you visit. Privacy Badger looks for tracking techniques like uniquely identifying cookies, local storage "supercookies," and canvas fingerprinting. If it observes a single third-party host tracking you on three separate sites, Privacy Badger will automatically disallow content from that third-party tracker. In some cases a third-party domain provides some important aspect of a page's functionality, such as embedded maps, images, or stylesheets. In those cases Privacy Badger will allow connections to the third party but will screen out its tracking cookies and referrers (these hosts have their sliders set to the middle, "cookie block" position).
Could it be that the popup.html reaches out to some website(s) (solid) when you load it? - and once you have used the same popup.html on three different sites, Privacy Badger kicks in and blocks the requests.
If popup.html embed images and javascript etc. from external services then I guess Privacy Badger does it job as it is supposed to and how I want it to. In that case popup.html is nothing better than embedded Facebook trackers - you allow a central actor to be notified of each and every Solid login attempt from all over the web by all Solid users - even if they choose to login with their own private Solid/webId provider.
Glad you fixed it - it really is a relevant privacy issue.
And now we are bashing privacy issues, then I believe your recommended usage is just as bad. The code example starts with this line:
<script src="https://solid.github.io/solid-auth-client/dist/solid-auth-client.bundle.js"></script>
And that is needed on ALL pages that uses Solid since it contains the session tracking code.
This means github.io now tracks all Solid websites that uses your recommended usage.
Please promote a downloadable local version to be installed on the individual websites AND favor that over github.io.
Yeah, there we have to trade DevX for privacy too 👍
Unfortunately, the screenshot above is already the latest version that does not include any external resources, so Privacy Badger must be triggered by something else.
I was looking into this, since I still have this issue on NSS 5.0.0 beta.2. In the current version, there are no external dependencies, so we have concluded that the cause for this is unknown, right?
I was thinking that we might file an issue with Privacy Badger, but simply saying "Privacy Badger doesn't work with Solid" isn't a terribly good report. Are we able narrow down what the issue might be?
I would suggest to have a public demo somewhere, and already get the discussion going over at Privacy Badger. They might be able to say what we should look for (for instance, switch on certain debug flags).
Right!
I'll create a test account on dev.inrupt.net and include a password in the report.
Arrggh! So, it works for me on https://dev.inrupt.net/ ... @JornWildt , @bushidocodes , can I ask you to create an account there and see if you are able to reproduce?
I could(!) reproduce it somewhat consistently on for instance https://solidrc.azurewebsites.net/home/login# which is running an older version of "login.html". But it is not easy - you have to use the old login.html from at least four different websites before it triggers Privacy Badger.
So I have https://elfisk.solid.community/, https://solidrc.azurewebsites.net/home/login#, https://localhost:5001/home/login, https://solidrc.jorn:5001/home/login, https://solidrc.other.dk:5001/home/login# where the last three all refers to my test project on localhost (using the "hosts" file on Windows to direct trafic).
Then, at some point, I see solid.community blocked by PB and unblock it, whereafter stuff works again. Unfortuantely, when I block solid.community again, things still work. Then I add a new name for locahost - and then that one is blocked and unable to login. So PB is a bit tricky to figure out.
Anyway - the blocked request is always https://solid.community/.well-known/openid-configuration which makes sense, because why should solidrc.azurewebsites.net reach with "fetch" to solid.community? Except that it happens when I click on a button (the "Login with Solid Community" button), so I initiate the request myself - but apparently PB is unable to detect that.
If it "works for you" then try running the new server version on localhost and add a couple of entries for 127.0.0.1 in the "hosts" file, such that you can use the same local server on different hostnames. Then, after logging in via solid.community from a couple of hostnames (4 times works for me), PB should start blocking it - it last it does for me on the old server.
I just tried a few logins on dev.inrupt.net (for instance https://aviana.dev.inrupt.net/common/popup.html) and PB blocks https://solid.community/.well-known/openid-configuration when I click "Login" and "Solid community". So the new server has the same issue with PB.
OK, I managed to reproduce it now, I think. At least I saw the problem I saw in nodeSolidServer/node-solid-server#883 . I saw it when I logged into my own site https://solid.kjernsmo.net/ with the test identity https://testpb.dev.inrupt.net/profile/card#me identity. Not a particularly spectacular fail, but a fail nonetheless ;-)
OK; great! I think I have enough to submit to PB. :-)
Oh, they have some stuff in https://github.com/EFForg/privacybadger/wiki/Find-out-why-Privacy-Badger-is-blocking-a-domain if you want to help out submitting it, @JornWildt . If you do, I can follow up with posting an account and password to help them look into it.
Tried it and got:
**** ACTION_MAP for solid.community
elfisk.solid.community {
"dnt": false,
"heuristicAction": "block",
"nextUpdateTime": 1543923490370,
"userAction": "user_allow"
}
solid.community {
"dnt": false,
"heuristicAction": "block",
"nextUpdateTime": 1544823052811,
"userAction": ""
}
**** SNITCH_MAP for solid.community
solid.community [
"localhost",
"elfisk.dk",
"solidrc.azurewebsites.net"
]
Don't know how much it helps ...
We still need to know why PB ends up with "heuristicAction": "block". My best guess is the "fetch" request to solid.community/.well-known/...
OK, yeah, don't know how much it helps, but I'll submit to see if they can figure out something.