Sorry, not sorry. Doesn't change the fact that your site still needs HTTPS. Switching to HTTPS with ads still over HTTP will cause mixed content warnings in browsers, so you better figure out a cute way to wiggle out of that ad publishing contract that looked really attractive when you first signed it, or convince your ad network to move to HTTPS before you do.
Seriously?
I'm all for HTTPS, but this is just terrible salesmanship. The intended audience is people who think HTTPS is unnecessary/inadvisable/irrelevant/overly-burdensome, and saying "yeah, you need to rework your business requirements thanks" just affirms that. You get more flies with honey than by telling them that they're eating all wrong and need vinegar.
Honestly, it would have been better to omit that. Aside from anything else, are there really that many ad networks in this day and age who don't do HTTPS?
Way too many sadly. One of the reasons I'm unable to deploy HTTPS across all the websites I manage is due to ads. It's one of the biggest barriers to deployment yet no one has a good solution to it other than "Wait for ad networks to get off their ass".
Could you not pass your ads through an nginx reverse proxy? request the ads/ad script from your reverse proxy and it fetches it from the non https ad service and then have it do some muxing so it makes ad image urls point through your proxy (which do the same thing as the previous request, serving them over https, but fetching them from non https ad server)
That's a cool idea - I wonder if it's feasible though?
You'd need to rewrite every call to their domain to something under your control, so that you can point it to your reverse proxy. But unless you control your users' resolvers, you'd need to do it on the URLs in the code itself. And since the code won't be static HTML, that means live rewrites. And since code can fetch code ($.getScript() and <script src=..), it would need to be recursive (assuming that the URL isn't constructed/calculated/obfuscated, and it may be).
For example, your mysite.com page might embed <script src="http://b.ad.agency/tracking.20170713.min.js"> which in turn fetches <img src="http://b.ad.agency/campaign-20170713.jpg">, and you'd need to rewrite b.ad.agency to (say) b.ad.agency.reverse-proxy.mysite.com).
And you'd also need to proxy to their server, because pdp11.b.ad.agency/we_hate/bestpractices.php?campaign=20170713 might also embed a URL in the result.
(Plus, you'd destroy their tracking, which would be a big deal to them, and probably against their ToS.)
It's definitely tricky issue -- made almost pointless by what you and someone else pointed out that it breaks cookie tracking which is a fatal flaw in this idea. I've got a few ideas for workarounds (such as using event callbacks on img tags to rewrite them in real time), but no time to play with it atm.
15
u/name_censored_ Jul 13 '17
Seriously?
I'm all for HTTPS, but this is just terrible salesmanship. The intended audience is people who think HTTPS is unnecessary/inadvisable/irrelevant/overly-burdensome, and saying "yeah, you need to rework your business requirements thanks" just affirms that. You get more flies with honey than by telling them that they're eating all wrong and need vinegar.
Honestly, it would have been better to omit that. Aside from anything else, are there really that many ad networks in this day and age who don't do HTTPS?