To anyone now panicing about user generated content and non-SSL images, and thinking "What I need is some kind of SSL proxy for user generated images"...
And I whipped one up in PHP for some old PHP site that I worked on if anyone wants to see that. I shoved that behind Nginx so that I also get a file cache for the most requested files.
For my project I purchased an extra SSL domain name ( https://sslcache.se ), as I had some concern about serving user generated content on my primary domain. Concerns which are valid, as github.com recently acknowledged by moving their UGC pages to github.io .
As far as I can tell, this change doesn't apply to images, and probably shouldn't apply to user-generated content (i.e., you shouldn't be letting users write/embed arbitrary CSS, JS, plugins, fonts, frames, etc...)
I had read the link, and whilst it doesn't mention images as being included in the change it also doesn't mention images as being excluded, and does imply that all mixed content is blocked. It was my assumption given those conditions that it included images.
And there are many scenarios in which you do want to allow user generated content to include JS, off the top of my head Google Maps does so to allow user maps to be extensible. The issue is how such content is managed safely, and enabling SSL and putting the content on another domain is a good thing. Google do the right thing and serve such content over SSL and via an iframe on a totally different domain ( http://whois.domaintools.com/googleusercontent.com ).
FWIW I too wrote a camo clone, but in Go[1]. Decently sized project for learning a new language. At $dayjob we have a python version too (considering replacing it with the Go version at some point)...
According to the link, the block only applies to certain types of resources, notably excluding images (presumably because malicious images cannot really take over the page).
If by hotlinking you mean that terrible act of theft of bandwidth, then yes! Down with that✝.
If by hotlinking you mean inline images that are an essential part of hypertext documents, then no! It's a great thing to support.
But the basic thing is that by not hosting, and by being just a proxy, we haven't expressed any ownership or liability over the content that passes through the SSL proxy.
And as a side benefit, we don't have to build out storage for this.
✝ for those who like to externalise their responsibility to determine whether their servers serve a request by just stomping around claiming people 'steal' bandwidth.
Node based SSL proxy: https://github.com/atmos/camo
And I whipped one up in PHP for some old PHP site that I worked on if anyone wants to see that. I shoved that behind Nginx so that I also get a file cache for the most requested files.
For my project I purchased an extra SSL domain name ( https://sslcache.se ), as I had some concern about serving user generated content on my primary domain. Concerns which are valid, as github.com recently acknowledged by moving their UGC pages to github.io .