Hype runtime blocked by AdWords?

(Nathan) #1

So I’m finally getting an accurate report of the actual error the ad service is getting:

Refused to load the script ‘http://tumult.com/hype/runtime/HYPE-578.thin.min.js’ because it violates the following Content Security Policy directive: “script-src https://tpc.googlesyndication.com https://pagead2.googlesyndication.com ‘unsafe-eval’ ‘unsafe-inline’ https://ajax.googleapis.com/ajax/ https://s0.2mdn.net/ads/studio/cached_libs/ https://www.gstatic.com/ads/ci/ https://www.gstatic.com/swiffy/”.

Does that mean they are blocking all external links to prevent potential cross-site scripting attacks? Or is there a different way I should be doing this?

Adwords banners rejected for 4th party call
(Jonathan Deutsch) #2

This doesn’t look specific to the Hype runtime - the content policy is probably blocking it because it is not served over HTTPS, though might also be because it is not coming from the same origin as the rest of the ad.

Regardless, do not use the runtime files on our server. The URL for this is not a CDN and we make no guarantees about uptime, hosting, or performance, and may change the URL in the future. We make this available so it can be copied in an automated way to other CDNs.

These runtime URLs are unpublished, undocumented, and unsupported for any use other than what we have communicated to partners we share with.

Instead, you should either copy the runtime files to your own CDN or have the files alongside the ad in the .hyperesources folder as a normal export would do.

(Nathan) #3

Well, shoot. I found that URL from a Google search and figured that would be the best, most official source for the library.

We’re not set up to run our own CDN, but desperately trying to make files as skinny as possible and take advantage of caching. But it sounds like AdWords doesn’t play nice with external runtimes anyway, so I guess I just have to deal.

I remember there was some discussion of eventually offering an official CDN, is that still on the board of options down the line?


This page might help: Google Adwords Best Practices

You might want to try these settings in ‘Advanced Export’:

Is Adwords giving you a file size warning when you include the Hype runtime in your export?

(Nathan) #5

On this particular one the package size isn’t bad because I’m running everything through ImageOptim after and not including the 2x retina assets. But on other ads that have a lot of images, that extra 25k can make the difference between being accepted or being over the weight limit. Doing a test right now using the Sizmek CDN since they seem to be on the Google whitelist.

What exactly does the inline data file option do? Does that create a smaller file size somehow?

(Nathan) #6

Just received word back that the Sizmek CDN link is still being blocked by AdWords. So I’m guessing that it’s only Doubleclick that allows this. Oh well.

(Hans-Gerd Claßen) #7

just a hint:
if you use ‘optimize image’ on export and afterwards delete the @x2-files those images won’t show up on retina-devices …

so if you want to optimize images yourself: uncheck optimizing in hype!

(Nathan) #8

Yeah, I’m familiar with how that works. The thing is, the Optimize option creates files at the optimal pixel size for that particular layout. So you can drop a 1200px image into a 300px ad and on export it generates 300px image for you. But it also makes a 600px version also, which puts the package over the size limits. But just deleting it leaves a broken link. On Mac it falls back gracefully to the normal size asset, but our testing reveals that it doesn’t do this on Windows and you just get a blank ad.

And just to clarify, it’s not efficient for our designers to go manually creating multiple sizes of each image for all 30+ versions of an add before doing a layout…

(Jonathan Deutsch) #9

I do have an item on our bug tracker to only export a single variant of the image (while still optimizing) for cases like this.