Apple adds a tracker blocker to desktop Safari • Hacker News Board

Re: Apple adds a tracker blocker to desktop Safari

#81

Post by gruez » Mon, Jun 05, 2017, 7:49 PM UTC

_xgw wrote: post #24

gruez wrote: post #11

Earlier quoted context omitted.

Source? Because the only information contained in user-agent strings in modern browsers are browser version (realistically limited to vendor since browsers auto-update) and operating system version. So basically all you're going to get is (Chrome/Firefox/Edge/Internet Explorer/Safari on Windows/Linux/Mac), which isn't much.

It's more than just the browser, it's the exact, EXACT version of the browser which can be very revealing if you're not updating your browser (almost) every day. For example: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/537.36

>It's more than just the browser, it's the exact, EXACT version of the browser which can be very revealing if you're not updating your browser (almost) every day

Is there a reason why you don't have auto-update enabled in your browser?

Also, auto-updaters don't apply updates right away, so as long as you're not a few versions behind the latest, you will blend into the crowd.

Re: Apple adds a tracker blocker to desktop Safari

#82

Post by olivierlacan » Mon, Jun 05, 2017, 7:49 PM UTC

throwaway2048 wrote: post #14

bauerd wrote: post #5

Earlier quoted context omitted.

Probably most (if not all) fingerprinting sources are showcased by fingerprint.js: https://github.com/Valve/fingerprintjs2

It is essentially impossible to enumerate all the ways browsers leak fingerprintable information.

I'd go with !Tor.

Re: Apple adds a tracker blocker to desktop Safari

#83

Post by derefr » Mon, Jun 05, 2017, 7:50 PM UTC

gsnedders wrote: post #71

derefr wrote: post #57

Earlier quoted context omitted.

Simple way would be tainting any JS/DOM data that interacts with the font metrics API (or one of a number of other similar APIs) and then not allowing tainted data to be used as parameters in network requests.

You don't even need the font metrics API. Draw a span containing the character "m", measure the width of the span using Element.clientWidth. Unless you taint (almost literally) the entire CSSOM, you can pull off similar things.

Is there a reason to not taint the entire CSSOM?

Alternately: why not anonymize CSSOM return values? Your browser might have access to OS fonts A+B+C, but if your JS asked the CSSOM about the size of characters on the page, the answer it would give would come from an "alternate world" where the browser only has access to the web-safe fonts, and so is using one of them.

Re: Apple adds a tracker blocker to desktop Safari

#84

Post by dsp1234 » Mon, Jun 05, 2017, 7:51 PM UTC

gsnedders wrote: post #55

pmiller2 wrote: post #30

Earlier quoted context omitted.

I don't think that's even theoretically possible. How do you block JS font enumeration without crippling the browser font API?

You can't block font enumeration without crippling the entire CSSOM. But that doesn't affect iOS, because you can't install fonts on iOS.

you can't install fonts on iOS.

Custom fonts can be installed via custom configuration profiles[0], which is what some font applications do[1]

I'm not sure if this is exposed via Safari or not, so it could still be a moot point.

[0] - https://developer.apple.com/library/content/featuredarticles...

[1] - https://itunes.apple.com/us/app/anyfont/id821560738

Re: Apple adds a tracker blocker to desktop Safari

#85

Post by tinus_hn » Mon, Jun 05, 2017, 7:51 PM UTC

dkonofalski wrote: post #67

jacobolus wrote: post #62

Earlier quoted context omitted.

I think he’s referring to aggregated anonymized usage data, which people can opt in or out of with no effect on function. (This is different than messages, etc., which are stored on Apple’s servers but end-to-end encrypted.)

I know he is, but that's not the same thing as what he's implying and, even then, Apple's solution is opt-in while Microsoft's was on by default.

If Apples solution is opt-in, Microsofts is in. For many things there just is no opting out.

Re: Apple adds a tracker blocker to desktop Safari

#86

Post by om2 » Mon, Jun 05, 2017, 7:52 PM UTC

hellofunk wrote: post #3

It's unclear to me how these "trackers" work? How do they track you, is it cookies, or what?

Most trackers use cookies or other client-side state to track you across the web. There's also various fingerprinting techniques but they are less reliable.

Re: Apple adds a tracker blocker to desktop Safari

#87

Post by gruez » Mon, Jun 05, 2017, 7:52 PM UTC

abc_lisper wrote: post #28

gruez wrote: post #11

Earlier quoted context omitted.

Source? Because the only information contained in user-agent strings in modern browsers are browser version (realistically limited to vendor since browsers auto-update) and operating system version. So basically all you're going to get is (Chrome/Firefox/Edge/Internet Explorer/Safari on Windows/Linux/Mac), which isn't much.

Check https://panopticlick.eff.org/

Due to how the site takes into account ALL user-agent strings ever collected, it overestimates how unique an user-agent string is. Realistically in a given point in time, there are only a few dozen user-agent strings in widespread use (due to how few bits of information actually gets put into it). Unless you're using a special snowflake browser/operating system you should be fine.

Re: Apple adds a tracker blocker to desktop Safari

#88

Post by jaegerpicker » Mon, Jun 05, 2017, 7:52 PM UTC

tyingq wrote: post #74

tinus_hn wrote: post #51

Earlier quoted context omitted.

You don't need to block Google Analytics to make it more private. You just need to make the user appear to a new user to every site. So Google may lose data because then they can't track you all over the web, but the websites don't because they still see you as one user.

Maybe I'm overly paranoid, but I assume Google does all sorts of fingerprinting (documented and not) via GA. Why else would it be free if it didn't provide a big upside for Google?

Only a limited subset is free. More advanced types of tracking requires the pro subscription.

Re: Apple adds a tracker blocker to desktop Safari

#89

Post by moogleii » Mon, Jun 05, 2017, 7:54 PM UTC

tptacek wrote: post #46

cylo wrote: post #41

Earlier quoted context omitted.

I am curious to know why you say this considering Safari is just as sandboxed as Chrome?

No, it isn't.

http://news.softpedia.com/news/Safari-5-1-Protects-Users-wit...

Re: Apple adds a tracker blocker to desktop Safari

#90

Post by jcranmer » Mon, Jun 05, 2017, 7:56 PM UTC

_xgw wrote: post #24

gruez wrote: post #11

Earlier quoted context omitted.

Source? Because the only information contained in user-agent strings in modern browsers are browser version (realistically limited to vendor since browsers auto-update) and operating system version. So basically all you're going to get is (Chrome/Firefox/Edge/Internet Explorer/Safari on Windows/Linux/Mac), which isn't much.

It's more than just the browser, it's the exact, EXACT version of the browser which can be very revealing if you're not updating your browser (almost) every day. For example: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/537.36

I can't speak for Chrome or Safari, but Firefox's UA is pretty sparse:

Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

This a totally custom, self-compiled build--and there is absolutely no reflection of that in the UA. Also note that the Mozilla/5.0 and Gecko/20100101 fields are frozen and are only there because sites break if they're not there.