InteractiveAdvertisingBureau/SIMID

Allow SIMID to come from html text in VAST

ryanthompson591 opened this issue · 4 comments

ryanthompson591 commented

Currently the simid spec only allows a url resource that points to html.

A suggestion would be to allow the VAST to contain html code. This code could be injected into an iframe that renders as the SIMID ad.

Some reasons to do this:
Assets could be selected server side to match the resolution and needs of the requester device.

Some issues:
What if the VAST is too big?
What if there is more latency because caching doesn't work?
Since the html is injected does the allow XSS attacks to happen?

wgrose commented

The convention in the spec seems to be to add HTMLResource sub node for inline HTML, IFrameResource for a URL to html, and StaticResource for a url to an image/swf.

It would be nice to continue to use that, adding HtmlResource/IframeResource/StaticResource as a child node to <InteractiveCreativeFile>.

richardrapp commented

Responding to +1 this basically; would be useful in cases where we want to avoid an extra http request.

ryanthompson591 commented

Just to leave a comment. This has come up in committee a few times and I think we were open to the idea.

The thoughts on it were.
Negatives: 

  • it would add some more complexity to an already complex standard.  
  • it is already possible to inject code into vast, via using the parameters and having your simid ad inject that js dynamically. 
  • This could cause large unwieldy vast ads 
  • this might actually be a net negative since the vast cannot be cached by the browser but a js ad  can be cached
  • publishers not getting iframe sandboxing correct would cause security vulnerabilities

The pros were: 

  • It could make things simpler for advertisers as they wouldn't need to host their dynamic ads anywhere. 
  • This could save some latency, because the ad could be instantly injected instead of waiting on a network request.
andmig commented

In short, I strongly oppose allowing HTML or any potentially functional elements injections into VAST. Doing so would defy three critical objectives:

  • Making in-stream interactive ads secure.
  • Bringing VAST back to its original mission to be a lean data transport mechanism only. Neither VAST is an application, nor is it a presentation layer.
  • Absolute externalization of executables.

I agree with the cons while disagreeing with the pros Ryan described.

  1. I don't see how it would make life easier.
  2. I do not see an association of HTML injection with dynamic ads hosting.
  3. Ads dynamism has nothing to do with HTML markup. The best, most efficient dynamic ads have nothing but <html><head><script/></head><body/></html> markup. All magic happens on the server and application levels.
  4. The latencies hogs are not HTML markups but assets, scripts, and synchronization logic.
  5. Security troubles aside, HTML injection opens the floodgates of the VAST response payload to become prohibitively big.

To save on requests, can I inject bytecode along with bitmap data into my HTML, please? 😉