Closed ghost closed 2 years ago
Thanks for the feedback! We'll definitely keep these in mind.
Once we have experimental results, we will be in a better place to come up with a design that mitigates these concerns. For example, N could include visited sites, and prefetches could happen in parallel.
Thanks, that makes a lot of sense. As I mentioned in my comment above, knowledge of N
is not critical in this attack, but the two of your suggestions combined together should help.
Are there any updates to share here? Wondering if it's now safe to turn on the Preload setting in Chrome or not.
See https://github.com/buettner/private-prefetch-proxy/issues/7 for more details on how we've addressed the issue.
Note that this feature is still in the experiment phase. Currently, it is still only enabled for a small fraction of user sessions.
(Closing this bug as a dupe of the other.)
Hi, can you explain how the attacks described above are handled by mitigations listed in #7? My understanding is that #7 mentions mitigations for threat models where the referrer is either colluding with the network operator OR the referrer is colluding with the proxy.
In the threat model described above, the referrer does not need either of them. Instead the referrer introduces speculation rule to prefetch a URL that it has control over. Does the difference make sense?
Can you explain your threat model again, and highlight how the mitigation in #7 does not mitigate them?
The key mitigation is that Chrome now makes the prefetch request even if the user has visited the site before. Note that that is a behavior change from when this comment was initially posted.
The initial post on this thread mentions, "would see a fetch .. iff only if the user has visited" and "or if the browser skipped fetching of foo.com and directly went from prefetching first hint to the third." -- neither of those happen now.
Similar to https://github.com/buettner/private-prefetch-proxy/issues/7, with Private Prefetch Proxy and Speculation Rules, any website on the Internet can determine the set of websites a specific user has visited in the past. These attacks do not require any collusion between the proxy and the referrer.
There are 2 possible attacks, and I had alluded to them in https://github.com/buettner/private-prefetch-proxy/issues/7#issuecomment-812184839, but I realized later that I commented on the wrong issue. That issue is about the proxy learning user history and not the referrer. Attacks mentioned in that issue also require the referrer to control the network unlike the 2 attacks below:
N
hints for sites that are unvisited, and it wants to determine if a specific user has visitedfoo.com
in the past. To do so, the referrer insertsN-1
prefetches for some randomly generated origins that the user is guaranteed to have not visited, followed by a prefetch for foo.com and followed by a prefetch forreferrer.com/unique_decorated_url
.Now the referrer would see a fetch for
referrer.com/unique_decorated_url
in its logs iff only if the user has visitedfoo.com
in the past. If the user has visitedfoo.com
in the past, the browser would skip that hint and only then prefetchreferrer.com/unique_decorated_url
.N
. Again, lets say that the referrer wants to determine if a specific user has visited foo.com in the past. To do so, the referrer inserts prefetches forreferrer2.com/unique_decorated_url_1
, followed byfoo.com
, followed byreferrer2.com/unique_decorated_url_2
. Here,referrer2.com
is an origin controlled byreferrer.com
.Now the referrer matches the timestamp for when fetch of
unique_decorated_url_1
completed to when the fetch forunique_decorated_url_2
started. This time gap can be used to determine if the browser spent any time in prefetchingfoo.com
, or if the browser skipped fetching offoo.com
and directly went from prefetching first hint to the third.The timestamps would be close iff the user has not visited
foo.com
in the past. Determining closeness is not that hard since the referrer would know the current RTT from the user to the proxy based on the prefetches made by user to thereferrer2.com
links.Note that unlike the attacks mentioned in https://github.com/buettner/private-prefetch-proxy/issues/7#issue-810339403, these two attacks can be carried out by Google websites solely with no way for the browser or the proxy to detect them. So, these attacks are not subject to the Chrome's whitepaper and privacy policy mentioned in https://github.com/buettner/private-prefetch-proxy/issues/7#issuecomment-854843083.