jkarlin
commented
1 year ago Hi anisenoff, thanks for the report! You're absolutely right that timing conveys extra information. The issue here is that Shared Storage requires private rendering. It's not enough to select the ad privately, it must also be rendered privately. We can accompish that one in of a few ways. We could require that all of the urls are prefetched as web bundles, we could require that the documents are fetched from some CDN that has a trusted policy that it won't leak its logs, we could utilize some sort of private information retrieval service, we could require that the server exists in a trusted execution environment running trusted code, or some mix of the above.
Right now, we're allowing selectURL() responses to be rendered in regular iframes. In time, we will require that they are rendered in fenced frames, and the fenced frames will require some sort of network/timing protection as well.
anisenoff
You can delay when the selectURL gate makes a request by delaying when the run function registered in the worklet returns. By doing this you can pass information to a server based on how quickly it receives the request relative to an earlier request, and use those delays to learn what value was stored with the API.
If you make a call to selectURL and only pass in a single URL it will not decrease the privacy budget as it is currently described since the request can only go to that one URL and log_2(1)=0, but delaying the request, based on a stored value, can still allow you to leak data that is not accounted for in the privacy budget. While the obfuscated URL or fenced frame config is returned almost immediately, the actual request can’t be made until the function returns. The simplest case involves either including a hardcoded delay or no delay before returning, although conceptually there is no reason you couldn’t use different lengths of delays to pass more information to the server (e.g., no delay, short delay, long delay) or tailor the delays to the current network conditions.
Below are links to two different websites that include the same third-party HTML in an iframe (light blue) which creates a persistent identifier that is transmitted as delays (hardcoded to be 2 seconds for this example) between requests for each of the fenced frames. The screenshots of the network waterfalls for the two sites are included below.
Website 1: https://anisenoff.github.io/sharedstorage/request.html?q=delay_header Website 2: https://www.andrew.cmu.edu/user/anisenof/sharedstorage/request.html?q=delay_header
Note: The links above were tested in Chrome version 114.0.5735.90
Furthermore, by allowing the resources to be loaded into iframes it appears to open up the possibility of using caching attacks, to learn what resource was loaded by a call to selectURL on subsequent visits to a site without decrementing the privacy budget, and possibly other side-channel attacks.