Hello Bosko,

You're quite right: it's hard to work streaming video into the TURTLEDOVE approach of resisting timing attacks by rendering ads without letting them touch the network.

It's possible that we could mitigate the timing attack in some other way, with the goal of somehow enforcing that the streaming video URL is "non-personalized" and "sufficiently popular". But it's not immediately obvious how to accomplish those.

I'd welcome other suggestions.

Still thinking about this but...

For all IG targeted ads, even standard display ads with web bundles, they could sometimes contain larger video files that would make sense to progressively download, or they may want to connect to web services serving e.g., a product DB dynamically, or stream video, etc.

In TURTLEDOVE, given this:

Aside from communication with the publisher page, we may need to worry about network communication with the outside world, since a timing attack could attempt to join the contextual ad request with the subsequent interest-group ad render. This could be solved by requiring the interest-group ad (or both ads) to be a Web Bundle that renders entirely locally, without any additional network activity (until the ad is clicked).

Let's assume that this is a hard requirement and that we want to close the door to timing attacks in the proposed manner. If that's the case, then simply restricting the types of ads that could be IG targeted to the bare minimum, not too costly to cache, would be one possibility. I don't see how that's realistic if we want to include the ability to IG target richer ads including video.

Another solution could be a "trusted" remote service, maybe not too dissimilar to what SPARROW proposes, or similar to what IP Blindness suggests. For the specific issue discussed here, such a service would pre-fetch and pre-cache web bundles, parse VAST/VPAID and cache non-stream (progressively downloaded) video files, companion banners, etc. Winning bids could reference server-pre-cached bundles from authorized hosts only, requiring the browser sandbox to only cache a "loader web bundle". In the case of video, VAST payloads could probably be rewritten to reference server-pre-cached files from authorized hosts. I think this would close the door to the type of timing attacks quoted above, while enabling advertisers to serve richer IG targeted ads and video. Noting that the timing attack discussed in this SPARROW issue is a different problem.

For video and VAST specifically, I think there is also the concern of information leakage via the video URLs in the VAST payload that could be handed to an e.g., videojs. So for assets served from "authorized hosts"/gatekeepers, it could be a requirement that URLs are obfuscated/random and do not leak information that an advertiser may want to pass to the publisher to enable later correlation in the publisher+advertiser collusion scenario.

I'm also working under the assumption that for the majority of the web in-stream video ads that are "client side ad inserted" (CSAI) by VAST-supporting video players, video assets tend to be of the progressive download (vs streaming) variety, so perhaps it wouldn't be too dramatic if sandboxed video ads just didn't allow real time streaming but only downloading of pre-cached assets from the "authorized hosts"/gatekeepers.

Closing this issue as it represents past design discussion that predates more recent proposals. I believe some of this feedback was incorporated into the Protected Audience (formerly known as FLEDGE) proposal. If you feel further discussion is needed, please feel free to reopen this issue or file a new issue.