2

As more and more browsers adopt stringent checks around preventing insecure content served up on secure sites, there is impact on the use of ad networks which in many cases don't support the secure content.

What are some options that exist to continue to leverage the HTTP based ads in a secure site? Note that I am aware of HTTPS ad network providers, but would still like to explore workarounds allowing the use of HTTP (insecure) ad providers.

I see through this question that proxying the requests through an SSL landing page could be an option. Does anyone have experience doing that or more information on this technique?

What other things have people been doing in this context?

Regards.

2 Answers 2

1

I would think that using information served over HTTP on a HTTPS page would defeat some of the purpose of using HTTPS in the first place. HTTPS is meant to be more secure than HTTP, but once you start using HTTP on an HTTPS page you are only as secure as your weakest link, HTTP.

You said you were aware of HTTPS advertising networks, that is probably your safest bet.

If you do try a proxy solution you should make sure you read the Terms of Service, some advertising networks are strict about how you use their code/service.

4
  • To clarify, the idea behind the proxy would be that ad payloads / calls would be proxied through an SSL bridge and all requests would be marshalled through it. I.e. you'd get a HTTP ad network payload, replace all URLs to point to your local SSL tunnel and then route the requests. That's basically kind of a crazy idea, just brainstorming here.
    – Episcopus
    Commented May 23, 2012 at 17:07
  • What about for contextual advertising, where the ads are based on the content of the page, like AdSense. Google will crawl the pages that ads are placed on in order to determine which ads should be shown. If the pages are HTTPS when Google tries to crawl them it will notice that the page is not an HTTP page. Another thing, most advertising networks would not allow the kind of modifications to the URL's you mentioned. For Google, you can really only take the code they give you and put in on your page the way it is. Anything that modifies their code, or the ad behaviour, would not be allowed. Commented May 23, 2012 at 22:32
  • It seems like a lot of work when there may be some ad networks that work over SSL anyways. I usually don't try to create more work for myself, haha. Commented May 23, 2012 at 22:36
  • Thanks for the feedback guys! The legal issues around rewriting urls and script are definitely there. The one thing about using the SSL networks is that they usually don't monetize very well next to their non SSL brethren. I assume that at some point if supply migrates to SSL networks demand will follow but for right now it's a revenue impact for web properties.
    – Episcopus
    Commented May 25, 2012 at 23:41
1

You could do what Slashdot used to do:

  • Require HTTPS for pages directly related to user authentication, such as sign-up, login, password change, OpenID management, and subscription payment. Offer HTTP for all other pages.
  • Offer HTTPS to subscribers who have paid for ad-free access.
  • Redirect non-authentication, non-subscriber HTTPS page views back to HTTP so that ads can be displayed. This may hurt your SEO now that Google is ranking HTTPS sites slightly higher. It is also vulnerable to cookie copying attacks such as Firesheep, so be sure to warn users of this when they log in.
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.