> According to Apple, before visiting a website, Safari may send hashed prefixes of the URL (Apple terms it “information calculated from the website address”) to Google Safe Browsing to check if there’s a match.
Does anyone have links to algorithms for such "hashed prefixes of an URL"?
I assume it's the same as when it was mentioned in 2019
"A 32-bit hash prefix like "ba7816bf" would represent the first eight characters of a 256-bit, 64-character SHA256 digest of a full URL.
Before it loads a requested website, Safari, like other browsers that implement a safe browsing lookup system, will hash the URL of the website to be visited and compare its hash prefix to the received hash segments of malicious sites."
"A 32-bit hash prefix like "ba7816bf" would represent the first eight characters of a 256-bit, 64-character SHA256 digest of a full URL."
Is this done for 'privacy'?
Pretty thinly veiled attempt, because they could easily create hashes for every url their crawlers come across, and do some statistical wizardry to try to find out which of the 1000 urls with that prefix you visited. Right?
Of course it's done for privacy. If Google created hashes for every single URL it crawled, the hash prefixes that are downloaded by clients would be enormously large, wasting multi gigabytes for on-device storage of these hash prefixes.
> Since Apple uses a hashed prefix, Google cannot learn which website the user is trying to visit.
Can anyone explain how this works? It isn't making sense to me. If the hash is unique enough to match in a database identifying malicious websites (without false positives), isn't it also unique enough to identify the website the user is trying to visit? At least to anyone with the hashing algorithm? Doesn't it have to be, in order to work at it's intended effect, to match a list of malicious websites?
Occasionally, you download a list of hash prefixes. This local database is used to do a probabilistic match as to whether it might be a malicious website.
If it might be, you send that hash prefix to Google, who respond with a list of full hashes with that prefix, and then you can go through that list (locally) and determine whether the computed hash is in the malicious set or not (without false positives).
The important point is that the full hash is never sent over the wire from the end user: only a prefix (typically four ASCII-encoded hex bytes) is ever transmitted.
It's not about hiding the website you visit but about hiding the ip it was visited from. If Google can't tie your ip to the website request they can't use it to market to you. I'm not sure why the hash is made a big deal but hiding your ip is the real value here.
No it's the combination of the two. If they tie the ip to the domain and then tie that ip to non-safe browsing websites that were visted by that same ip and they can easily start to identify the "safe" sites you visited. If you stop that IP from being identified (also stopping most if not all browser fingerprinting techniques) than it's MUCH harder to identify you as the person that visited those sites. It's the relationship that really matters. Apples proxy breaks that relationship. So does a good VPN setup.
> According to Apple, before visiting a website, Safari may send hashed prefixes of the URL (Apple terms it “information calculated from the website address”) to Google Safe Browsing to check if there’s a match.
Does anyone have links to algorithms for such "hashed prefixes of an URL"?