Re: [w3ctag/design-reviews] Review request for Fenced Frames (Issue #735)

> Also of note.
> 
> Do you plan to disable some [input events](https://vmonaco.com/papers/Device%20Fingerprinting%20with%20Peripheral%20Timestamps.pdf) that may aid in fingerprinting? That would be a matter of getting rid of access to a clock.
> 
> If the plan is to make the thing tight and leak-resistant, perhaps going as far as possible would be a sensible approach.

Agree that there is the issue of network timing side channel (described in the explainer [here](https://github.com/WICG/fenced-frame/blob/master/explainer/network_side_channel.md)) and we are considering what a long-term solution for this would look like in fenced frames. The solution will likely also be different for the different modes of fenced frames (e.g. [read-only mode](https://github.com/WICG/fenced-frame/blob/master/explainer/modes.md#read-only) completely blocks off network access when it gets read-only cookies access). For the [opaque-ads mode](https://github.com/WICG/fenced-frame/blob/master/explainer/modes.md#opaque-ads), the considerations are either 1) denying any network access (e.g., loaded via navigable web bundles)  or 2) network access only allowed to some trusted caching service that promises to only log aggregate data. 

Re Removing the clock : This was considered, but this is an approach that would require needing to block many APIs and as a result can lead to a lot of content not working inside fenced frames. Additionally as long as the FF has network, the timing can be retrieved from the server at any point.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/735#issuecomment-1187523219
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/735/1187523219@github.com>