Hacker News Reader

Comment by bigiain | Hacker News Reader

I wonder haw many pages on a typical website you'd need to browse to let Tencent de-anonymise that k-anonymous hash-prefix scheme?

If Tencent added ihatetheccp.com and ihatetheccp.com/about and ihatetheccp.com/news and ihatetheccp.com/blog and ihatetheccp.com/donate to their "unsafe page" list - I suspect the pattern of fetching of the full list of urls for some of those specific hash prefixes in a short time would allow Tencent (or Google) to make reasonably accurate assumptions about which site you're actually visiting.

View on HN

If I recall correctly hashes are based only on the domain though, not the full path.

If they're using the same method that they use with Google, then this is not the case: https://developers.google.com/safe-browsing/v4/urls-hashing

The URLs are canonicalized first and then the full URL is hashed.

That's true, but if you scroll down further it mentions that they try several permutations of the url, up to 30. So while grabbing 1 of the 2^32 buckets won't say much, grabbing 5 buckets (once for each permutation) in a specific order may very well indicate that you browsed a specific url.

That’s on the client, not on the server. The server would just provide the responses for the specific hash prefix. While I agree that, in time, it would eventually get good enough to categorize people, all it would take is a change in the hash and most of the old model would be trash.

>That’s on the client, not on the server.

But that required by the system to work. Otherwise you have to choose between having really poor granularity (if you only check the domain), or really large black lists (if you only check the whole url). Point is, there's no way for this system to work effectively and be anonymous.

>all it would take is a change in the hash and most of the old model would be trash

Why would the hash change?

One?

Pretty sure browsing _one_ url won't give too much useful away.

Without digging into details myself, I'm under the impression from recent reporting that Safari is sending 32 bytes of a SHA256 hash of the (canonicalised somehow) url. So there's 2^24 possible hashes that you might be wanting to check in the returned list. Presumably some small percentage of those will actually be on the list, what I'm not sure about is how many of them are plausible and completely innocent urls.

Reply on news.ycombinator.com