Possibly treating http and https as separate origins

[MarcusJT]

PBC breaks the Hootsuite Hootlet and Save to Pocket extensions - after much fiddling (thanks to no hints in Chrome console that PBC was doing the blocking) I found that disabling PBC makes them work again.

The Hootsuite extension can also be made to work by manually setting the hootsuite.com domain back to green in PBC settings but oddly there is no equivalent domain listed for the getpocket.com requests which are being blocked, and in any case it surely shouldn't be necessary to manually unblock these popular extensions.

[cooperq]

I think that this is the same issue that @bperrier was having in #211 using instapaper. The problem is that all of these extensions work by creating an iframe on the site which you want to save. Privacy badger has no way of knowing that the iframe was created by an extension so to privacy badger it just looks like another tracking element. I have added hootlet.com getpocket.com and instapaper.com to the cookie block list for now. You can get these extensions working again by whitelisting the above listed sites in privacy badger.
It is possible that when we implement the feature being discussed in #137 it will create a sufficient work around for this problem.

[MarcusJT]

Yes, that sounds like the likely root cause (and solution). Thanks!

[artlogic]

I'm sorry to re-open this. I just started using privacy badger, and my instapaper bookmarklet is broken, presumably because of this issue. I would like whitelist instapaper's 3rd party cookie, but the problem is I can't seem to find a way to whitelist it. When I click "Read Later", it takes me directly to the instapaper site telling me 3rd party cookies are blocked, however, since I'm at instapaper.com, the cookie at that point is not 3rd party. Is there some simple way to whitelist a domain that doesn't appear in privacy badger?

[tsibley]

@artlogic I just came across this issue trying to figure out the same thing as you. I realized I could provoke the Badger artifically and then change the blocking settings, so I made a little tool to do so: https://tsibley.net/provoke-the-privacy-badger/. I hope it helps!

[artlogic]

@tsibley very nice! Works like a charm. I had been doing something similar to this, but using the browser's dev tools. Your solution is much more pleasant.

[MarcusJT]

Excellent, thanks @tsibley!

I hope that in the long run PB will implement this (or something similar) itself... @cooperq ?

[tsibley]

Yeah, I do hope PB will implement a way to change privacy settings without being on the page were they were triggered.

[cooperq]

There is a pull request in the works right now to have an options page where you can change settings for all of the domains privacy badger knows about. It should be released soon.

[tsibley]

@cooperq Yay!

[timmib]

As of today I am still having instapaper.com bookmarklet interrupted even though the slider is green.

[tsibley]

@timmib It looks like Privacy Badger may have started distinguishing between http:// and https:// schemes in its whitelist. Until that pull request that @cooperq was talking about lands, try using https://tsibley.net/provoke-the-privacy-badger/ with instapaper.com (again, it's updated). Doing so just solved the problem (again!) for me.

[cooperq]

@tsibley privacy badger should not be distinguishing between http and https in the cookie block list. The pull request has landed and will be in the next release.
If privacy badger is treating http and https as separate domains that is a bug, what leads you to believe it is?

[tsibley]

@cooperq I'd successfully whitelisted a domain using a triggered HTTP request and it was working great. Then when I last updated Privacy Badger (in Firefox, on 1 April), that whitelisting stopped working. As far as I could tell, the domain was still considered whitelisted under HTTP, but not HTTPS. Once I toggled the slider to green after triggering an HTTPS request to the domain, the whitelisting was restored.

This wasn't a controlled test case, just what I seemed to be observing. It could, of course, be for another reason entirely.

[cooperq]

looking into this, I don't think that https and http are treated differently. I think this might have been unrelated. Closing for now.