Google can track surfing habits without need for HTTP cookies • Hacker News Board

Re: Google can track surfing habits without need for HTTP cookies

#21

Post by yjftsjthsd-h » Fri, Sep 07, 2018, 1:46 AM UTC

aawc wrote: post #11

Did you turn on that 'Block dangerous and deceptive content' feature in Firefox' security tab? It works by consulting Google each time you visit a new website. You can imagine the rest. Patently wrong. Here's how the API works: The Update API lets your client applications download hashed versions of the Safe Browsing lists for storage in a local database. URLs can then be checked locally. Only if a match is found in…

So then it semi-randomly sends Google URLs you visit? That's better, but I wouldn't say patently wrong. Statistically usually wrong?

Re: Google can track surfing habits without need for HTTP cookies

#22

Post by yborg » Fri, Sep 07, 2018, 1:48 AM UTC

gruez wrote: post #20

yborg wrote: post #19

Earlier quoted context omitted.

This doesn't seem to be present on 63b2.

it's hidden by default. see: https://bugzilla.mozilla.org/show_bug.cgi?id=967977#c17

Is there a major performance impact for having not using the session tickets? It seems odd that it's buried this deeply.

Re: Google can track surfing habits without need for HTTP cookies

#23

Post by gruez » Fri, Sep 07, 2018, 2:11 AM UTC

yborg wrote: post #22

gruez wrote: post #20

Earlier quoted context omitted.

it's hidden by default. see: https://bugzilla.mozilla.org/show_bug.cgi?id=967977#c17

Is there a major performance impact for having not using the session tickets? It seems odd that it's buried this deeply.

AFAIK most servers use keep-alive, so it's not like a new tls connection is made for each resource.

Re: Google can track surfing habits without need for HTTP cookies

#24

Post by judge2020 » Fri, Sep 07, 2018, 2:12 AM UTC

marichards wrote: post #4

So DNS over HTTPS sounds great.

I don't see ISPs starting DOH servers up within the next 5 years, so either way, you'll be performing dns lookups to a central server.

Re: Google can track surfing habits without need for HTTP cookies

#25

Post by Avshalom » Fri, Sep 07, 2018, 2:15 AM UTC

aawc wrote: post #11

Did you turn on that 'Block dangerous and deceptive content' feature in Firefox' security tab? It works by consulting Google each time you visit a new website. You can imagine the rest. Patently wrong. Here's how the API works: The Update API lets your client applications download hashed versions of the Safe Browsing lists for storage in a local database. URLs can then be checked locally. Only if a match is found in…

any evidence that it doesn't match with the top ~1M websites? because that page says "hashed versions" which kind of implies "not inspect-able".

also why does it collect client ID at all and also "should uniquely identify a client implementation, not an individual user" doesn't sound a lot like "can't identify an individual user" ... especially in a home user context.

Re: Google can track surfing habits without need for HTTP cookies

#26

Post by auslander » Fri, Sep 07, 2018, 2:30 AM UTC

kawsper wrote: post #10

Nerada wrote: post #5

Mitigated by uMatrix and other Firewall tools, no? I don't find myself ever needing to allow Google Fonts/Analytics to view a page.

https://www.easyjet.com had a hilarious bug where their menu bar wouldn't work if you were blocking Analytics. But yes, it is often not a problem at all to block Google Fonts/Analytics - almost everything works as expected.

> not a problem at all to block Google Fonts

Just checked my uBlock Origin on smh.com.au: fonts.gstatic.com are loaded ...

Re: Google can track surfing habits without need for HTTP cookies

#27

Post by tlarkworthy » Fri, Sep 07, 2018, 2:34 AM UTC

lwansbrough wrote: post #17

gruez wrote: post #16

security.ssl.disable_session_identifiers = true on firefox mitigates this.

Any reason for Mozilla to not have this disabled by default?

Those session resumption tokens save you redownloading 1- 10kb of certificates every fresh connection and the multiple round trips for the TLS handshake. Its a bandwidth and latency optimization.

Re: Google can track surfing habits without need for HTTP cookies

#28

Post by lixtra » Fri, Sep 07, 2018, 2:37 AM UTC

yjftsjthsd-h wrote: post #21

aawc wrote: post #11

Did you turn on that 'Block dangerous and deceptive content' feature in Firefox' security tab? It works by consulting Google each time you visit a new website. You can imagine the rest. Patently wrong. Here's how the API works: The Update API lets your client applications download hashed versions of the Safe Browsing lists for storage in a local database. URLs can then be checked locally. Only if a match is found in…

So then it semi-randomly sends Google URLs you visit? That's better , but I wouldn't say patently wrong. Statistically usually wrong?

> So then it semi-randomly sends Google URLs you visit?

No, it computes a 4 byte hash of the URL (domain?) and if this matches a local DB entry then it asks google for all malicious URLs with that hash (explained in the link of parent).

Depending how many entries there are your browser contacts google fairly frequently and then google using techniques mentioned in the article can link your TLS-Cookie to your IP.

Re: Google can track surfing habits without need for HTTP cookies

#29

Post by corv » Fri, Sep 07, 2018, 2:42 AM UTC

aawc wrote: post #11

Did you turn on that 'Block dangerous and deceptive content' feature in Firefox' security tab? It works by consulting Google each time you visit a new website. You can imagine the rest. Patently wrong. Here's how the API works: The Update API lets your client applications download hashed versions of the Safe Browsing lists for storage in a local database. URLs can then be checked locally. Only if a match is found in…

You’re right, it doesn’t contact Google every time but it does contact Google periodically, something which many users might not be aware of.

Ideally Firefox wouldn’t rely on contacting any third parties in their default browser configuration.

Re: Google can track surfing habits without need for HTTP cookies

#30

Post by toast0 » Fri, Sep 07, 2018, 2:55 AM UTC

bogomipz wrote: post #6

The author states: >"Eight years later, everyone in the business seems keen to point out that TLS version 1.3 will finally address this issue by encrypting session data, although it isn't obvious if the measures taken by IETF actually work." Can someone say why it not yet if the measure taken by the IETF in TLS 1.3 work? Is it simply that this part of the spec hasn't been finalized yet? Or does the author mean someth…

So, TLS 1.2 servers offer session identifiers in cleartext and client resumption sends them in cleartext also. Which probably means someone watching lots of traffic to Google can correlate users even as they move across ips.

TLS 1.3 servers send the session identifiers encrypted to the client, and then the client sends it back in cleartext, but each successful handshake will generate a new identifier; a passive observer will not be able to correlate sessions -- except for retries, but the service owner still could. In TLS 1.3, the server can establish a session ticket any time after the handshake is complete, so conceivably, the server could wait until it had some idea of who you are, and establish a token then which contains your userid. (Anyway, it could always associate a random session id with your userid later)