Hacker News Reader

Comment by bri3d | Hacker News Reader

It sounds like the requests were a bug:

https://github.com/EFForg/privacybadgerchrome/issues/431#iss...

This looks like it's trying to exercise every dark corner of the user's browser in order to ensure that the browser is a real, eyeball-facing browser and not just a URL fetcher, PhantomJS/SlimerJS, or a clickjacking plugin being used to fraudulently click ads.

I think it's easy to see both sides here: tools like this are a powerful way to detect and combat botnets and click fraud, but if/when weaponized they're also a form of browser fingerprinting which is a nasty way to ruin anonymity across the web.

IMO there are a lot of bigger targets on the Taxonomy of Bad Internet Things: malware-serving bottom-tier ad networks, "wrapped download" sites, clickjacking, and especially cross-site correlative "analytics" companies come to mind as being more sinister to privacy than Dan Kaminsky going botnet hunting.

View on HN

Their motives might be good, but if their actions are indistinguishable from the bad guys, then there's still a problem.

I'd argue that collecting unique information from your browser does not necessarily make you "the bad guys". Lots of legitimate anti-fraud products used on bank/investment websites collect that information and detect/prevent account takeovers before fraudsters can steal money and identities, for example.

What can make it bad is:

1. What you do with that information.

2. Who or what you share it with.

3. How far your reach extends.

An ad network which can place that code on multiple websites can put itself in a position of power and track devices, and thus browsing habits, of individuals.

However, if you have fingerprinting code only on your own website, and don't share that information with any other people/companies/websites, and use it solely to detect malicious bots, users, and behaviors, then I don't really think it's bad. It's like the difference between a gas station owner pointing a closed circuit camera at the door and someone flying a surveillance drone over a whole state. Both are surveillance, but one kind is much less ethical.

If it's possible to collect enough information from your browser to uniquely identify you, your browser needs fixing.

I would agree, but there are very few browsers out there to which that doesn't apply.

Yeah, I ran into a site a while back that was clever enough to spot that I wasn't using a browser.

So I did, Selenium allows you to automate a real browser and capture the responses, hell if need be you can create a fake profile with Chrome and make it completely indistinguishable.

EDIT: explanation, it was a video tutorial site for one of the technologies I use, each video had a download link but it had no way to batch downloads for offline use, scraping it with normal tools didn't work since it was doing UA and other sniffing so I whipped up a python script to control chrome to authenticate, sign in get the cookie and then pulled the unique to that session download link for each video, since I'm not a dirtbag I set the time between downloads to 30 minutes (average video is 15 minutes) and left it running for 24 hours to get the ones I wanted.

    Selenium allows you to automate a real browser and capture the
    responses, hell if need be you can create a fake profile with Chrome
    and make it completely indistinguishable.

Are there no headless browsers that let you accomplish the same thing? Honest question...

I've used Selenium, but I just assumed that headless browsers were exactly: real browsers minus the UI.

Quite possibly but I use selenium extensively during dev to automate boring tasks (filling in forms over and over is boring) as well as for integration and functional testing.

So I had a hammer and the problem looked like a nail. ;)

headless browsers are easy to identify.

The best you have to not be ID'd and "kinda headless" is slimer or selenium to XVFB, which aren't really headless but sort of

[edit] slimer [AND] selenium to [OR]

It sounds like it would be quite easy to circumvent just by running a real browser... especially with lightweight VMs.

which it also attempts to enumerate common files such as virtualbox or vmware drivers via <link> and <img> off file://

Shouldn't it be impossible for a website to determine what files exist or do not exist on a local machine? That sounds like a serious security problem. It seems that no non-file:// site should ever be allowed to load a file:// resource, much less query the element for its size or error state afterward.

You're completely correct.

Those kinds of security issues are the low-hanging fruit that's largely been fixed by now.

Reply on news.ycombinator.com