Using HTTP to Avoid Mixed Content Warnings From Ads
MyFitnessPal (via Matt Birchler):
Although our home page at http://www.myfitnesspal.com may not indicate the presence of https in your browser’s interface, the actual login “lightbox” or pop-over window on the home page does send your login credentials via https.
Once logged in, however, most data interactions on the site are not sent via https. This is a concession we have made in order to be able to offer our health and fitness tools for free. Our revenue model is mostly comprised of presenting advertising on the site. We work with a number of ad aggregation companies, and these partners serve their ads to us via http. As a result, we cannot serve most pages of the site via https without badly reducing the usability of the site. As but one example, many browsers and internet security programs are prompted to present warnings to users because of “mixed content” on pages of our site, when some content on a given page is sent via SSL and some is not.
Is there an advantage to the ad companies in not offering HTTPS?
6 Comments RSS · Twitter
So it’s trivial to mess with the webpage and add JavaScript that submits the login credentials to another website via Ajax on entry.
I thought that https doesn’t pass referrers; I don’t know if that’s really true or not, but I remember reading that at some point (maybe back when Google switched to https? There was definitely something about that switch years ago that irritated analytics/tracking people).
@Smokey I did blog about that, but I wouldn’t expect it to be an issue for ads since they can add tracking parameters to the destination URL.
Isn't it the case that rules around cookies are different when presented on HTTP vs HTTPS?
Not 100% sure but something like HTTP cookies are available from HTTPS, but not vice versa.
I'm also curious what the real story is here.
https://stackoverflow.com/questions/2163828/reading-cookies-via-https-that-were-set-using-http
For ads that are ISP-affiliated, they need plaintext HTTP pages for the ISP's ad injection to work.
Access of an iframe's content via javascript is restricted when using https and (&or) different hosts. I guess the tracking code doesn't run as smooth with https.