Wanted to share some feedback and thoughts on the 2 proposals for instream video (https://github.com/google/ads-privacy/tree/master/proposals/protected-audience-video, and https://github.com/google/ads-privacy/blob/master/proposals/protected-audience-video/component-seller.md)

1. The Protected Audience VAST Player (PAVP) component adds additional complexity and complications:

   1. Introducing player interactions between publisher player, 3p SDK (if applicable) and PAVP via postMessage could introduce latency into the user experience (i.e. pause, play interactions etc).
   2. The implementation of this component would reside with either the publisher or the video player if the publisher is not using GAM as the primary ad server which would be a significant lift to be implemented by the publisher and or video player.

2. The construction of the renderUrl presents a few challenges:

   1. Multiple sellers using macro expansion - builds a chain of dependencies of 3rd parties to execute properly, introduces extra latency, would be difficult to debug and conceptually is complex.
   2. Using renderUrl for video/native seems like a bit of a misfit/hack. Instead - there is a proposal for "first class citizen rendering" for Native/Video (Support for native advertising WICG/turtledove#265 (comment)) that seems like it could solve some of the challenges of the “renderUrl” problem.

3. Reporting VAST events through reportResult would require changes to all the VAST payloads (in the form of a VAST extension) from the DSP as well as the seller or SSP and might take a long time for adoption.

4. Long term, I'm unclear how VAST redirects would be supported if the fence frame doesn't allow additional HTTPS requests. What would be the mechanism for supporting such scenarios (which are very common)?