Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow SIMID to come from html text in VAST #316

Open
ryanthompson591 opened this issue Jan 30, 2020 · 4 comments
Open

Allow SIMID to come from html text in VAST #316

ryanthompson591 opened this issue Jan 30, 2020 · 4 comments
Labels
SIMID 1.2 potential future update

Comments

@ryanthompson591
Copy link
Collaborator

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?
@mimidden mimidden added SIMID 1.2 potential future update and removed SIMID 1.1 labels Aug 20, 2020
@wgrose
Copy link
Collaborator

wgrose commented Jan 26, 2021

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
Copy link

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

@ryanthompson591
Copy link
Collaborator Author

ryanthompson591 commented Feb 26, 2021 •
edited
Loading

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
Copy link
Collaborator

andmig commented Mar 17, 2021

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? 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
SIMID 1.2 potential future update
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@wgrose @ryanthompson591 @andmig @richardrapp @mimidden