unhush

Tracking bug for this (in Firefox): https://github.com/EFForg/privacybadgerfirefox/issues/11

FYI, upgrading to 0.1.1 (released Friday) fixes the bug I mentioned. Subdomains of whitelisted sites are also whitelisted now. https://github.com/EFForg/privacybadgerfirefox/pull/63/files

Unfortunately not, if you use Incognito by default (other than being able to see who's tracking you and toggle the settings manually). We could add a feature to optionally save data in Privacy Badger between incognito sessions (or use data from the non-incognito sessions to determine which sites to block in incognito sessions).

In Firefox, PBadger Alpha doesn't have permission to operate in Incognito mode yet, so it will just be off.

There is code in Privacy Badger that checks whether a site has publicly posted a statement of compliance with DNT before blocking it. If they do and then violate that commitment, we have a record of it and can call them out on it.

Do you have other extensions installed that are already blocking trackers? (NoScript, for instance.) If so, Privacy Badger shows only the ones that they've missed.

To clarify, those cases where we block cookies but not requests entirely are the sites on this whitelist: https://www.eff.org/files/cookieblocklist.txt

This pull request will also apply the whitelisting to subdomains of the domains on the whitelist: https://github.com/EFForg/privacybadgerfirefox/pull/63.

Unfortunately blocking all those sites and making users whitelist them manually is a lot of work for most users. So we ship a whitelist.

UGH, you're right. Ok, let me explain this. We whitelisted google.com but it was not anticipated that, in the general case, we should really whitelist all subdomains in order not to break sites.

Luckily this was a one-line patch: https://github.com/EFForg/privacybadgerfirefox/pull/63 (though in the future, it is better for the whitelist to have wildcards in the cases where it's necessary).

Thanks for testing. Really helps a lot.

The reasons for not using a blacklist in Privacy Badger were philosophical, not technical. I agree it would be more convenient to ship with a blacklist but hopefully the learning algorithm works well enough to be almost-equivalent.

Btw. what is the point of Privacy Badger without the Do Not Track header?

Not sure I understand. Privacy Badger Alpha currently sets the Do Not Track header on all requests.

Perhaps now is a good time to mention that if you want to work on projects like Privacy Badger with EFF, we're hiring for a Staff Technologist: https://www.eff.org/opportunities/jobs/staff-technologist. The role is a mix of software engineering, doing security/privacy research, pressuring large internet companies and standards groups to not be evil, and teaching lawyers/reporters about technology issues.

It's overall a fun job. I wrote most of Privacy Badger Firefox with help from Mozilla folks in the last two months, and it's very satisfying to see people using and reporting bugs in the software that I made almost immediately after launch. :)

Yes, the alpha version (what we just launched) only works on third-party cookies, so the heuristic blocking algorithm doesn't do anything if you block 3rd party cookies entirely. We plan to add detection of other tracking methods (Flash cookies, local storage, fingerprinting, etc.) as time goes on. More info in the Firefox version's README: https://github.com/EFForg/privacybadgerfirefox/blob/eb1055c4...

We do have a preloaded list of third-party sites to not block because they would cause too much breakage. Note that because PBadger is in alpha, this list is very short right now: https://www.eff.org/files/cookieblocklist.txt

It's maintained by EFF, and more things will get added as time goes on.

Note that Privacy Badger uses a browser history-dependent algorithm for blocking - when you first install it, it doesn't block anything because it assumes that third-party trackers are innocent until proven guilty. When it sees you being tracked on 3+ first-party domains by a third party, it either blocks or cookieblocks the third party. I wrote up a basic description of the algorithm here: https://github.com/EFForg/privacybadgerfirefox/blob/master/R...

So if you're testing Privacy Badger on a profile with no browsing history, it is bound to do worse than other extensions. You have to "prime" it with some browsing data before it's really effective.

Hi, I'm an EFF staff technologist and wrote most of Privacy Badger Firefox (though I didn't come up with the idea). It's often hard for us to find projects like yours, so we appreciate developers contacting us and telling us about them directly. It's possible we can find a way to work together, if you'd like. Email me: yan at eff dot org.

Disclosure: I didn't work on Privacy Badger Chrome but at least I can fwd you on to the right people. :)

Sorry, that does sound frustrating. I joined EFF partly because it was a good way to make software that people would actually use.

(One constraint that most people may not realize is that EFF has very strict privacy policies for our tech projects. There's lots of projects I'd like to do, but the lawyers probably wouldn't approve. So there's plenty of room for other developers to do projects that step over lines we wouldn't cross.)

Hi, I'm the main author of Privacy Badger's Firefox version. You are 100% right; I'll point this out to the text authors.

On the other hand, EFF's fanbase is generally very technical compared to the average person and I'm sometimes afraid of coming off as imprecise or belittling to them. Striking the balance is hard.

maybe the hackpad creators will open-source and/or release upstream patches to etherpad! cough

I'm aware that there's modules you can add to do those things. Are there public instances that have those installed? It's been a while since I used Piratepad et al.

Hackpad is an Etherpad fork, so you might conclude that someone has already done the work of wrangling Etherpade code and making those patches. ;)

It is often like that in Firefox.

They don't do a great job of advertising why they're better, but semi-sensible keybindings (similar to Github markdown) and code syntax highlighting sold it for me. Also doesn't require a Google account to use.

Also auto-embeds photos/videos/soundcloud when you paste in links and has prettier UI. Not sure if Google does the former.

My favorite parts of Hackpad were the features that weren't intended to have mass-market appeal (ex: code syntax highlighting, markdown-inspired keybindings, ability to easily create/delete accounts). These will likely be gone in whatever notes product that Dropbox makes with the help of the (wonderful) Hackpad team.

So for me, this acquisition seems like a loss. I realize that Hackpad has said that they'll keep the site alive, but I expect it to be less functional if everyone maintaining it is a full-time Dropbox employee now. Fingers crossed that there will someday exist a good collaborative doc editor for hackers that doesn't fall over when >10 people connect or require a Google account!

Full disclosure: I have written code and done security auditing for Hackpad. I tried to get them to add vim mode. :)

Agreed 110%, but I would back up my Hackpad documents now. Claims of being able to sustain a business after acquihire when the parent company has no stated interest in keeping it alive seem extremely fragile.

Thanks for the feedback!

The tech team at EFF is pretty overloaded all of the time; we've hired outside contractors before but this is a project where it seems more efficient (and potentially more fun per person) to crowdsource. The same goes for HTTPS Everywhere (https://www.eff.org/https-everywhere), a browser extension that I maintain where almost all of the 10,000+ XML (ugh!) http-to-https upgrade rules are contributed by volunteers.

I think EFF is in a rare position to experiment with crowdsourced programming tasks, because (most of) our contributors don't have any incentive to game the system and deliberately submit low-quality work, which decreases the usefulness of results you get from money-driven crowdsourcing platforms like Amazon Mechanical Turk. This particular experiment was far more successful than I predicted, which brings up the question of whether there is a systematic way to make crowdsourced web development effective.

In the case of the sample described in the post, there was a TLS handshake that was immediately terminated, followed by a client hello and the heartbeats. The client hello and heartbeats were sent in the clear.

I conjecture that the TLS handshake was used to fingerprint the server, since not all 3 versions of the payload will succeed on all TLS versions.

For anyone following along at home, we looked into this and it seems to be caused by the fact that you're using an older operating system that doesn't ship with the StartCom CA cert that eff.org uses. So probably not an attack. :)

Emailing me works. yan at eff dot org.

Are you joking? If not please report what error you're getting in Chrome.

I helped write this post. Note that we're very interested in anyone who has been keeping raw packet logs from before the Heartbleed vuln. was public. If you find 18 03 (01 | 02 | 03) 00 03 01 in them, please let me know or post pcap files. Contact info: https://www.eff.org/about/staff/yan-zhu

Is it possible for you to allocate those funds to (specifically) funding a security audit and code refactor of OpenSSL? Cryptography researcher Matthew Green has stated interest in starting a campaign: https://twitter.com/matthew_d_green/status/45386223750218547...

EFF blog post: https://www.eff.org/deeplinks/2013/11/aaron-swartz-hackathon...

Freedom of the Press Foundation blog post: https://pressfreedomfoundation.org/blog/2013/11/help-us-make...

Yeah, I'll be MC'ing and telling people how to be scared of things they didn't even know about. Come!