The referer-linked privacy leakage that I'm mostly concerned with is associated
with embedded resources, not resources that a user clicks on to access. But I
agree moving to SSL has many benefits.
On Jun 12, 2015, at 11:38 PM, Andrew Anderson and...@lirn.net wrote:
I was not suggesting
Or just SSL enable your library web site. Few vendors support SSL today, so
crossing the HTTP/HTTPS barrier is supposed to automatically disable referring
URL passing.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3
15.1.3 Encoding Sensitive Information in URI's
Because the
While going to SSL is a good thing to do, it's not a good idea to be loading
non-secure resources into a secure web page, because then your page is no
longer secure.
So for example, if you load the google analytics script via http from an https
page, and MITM attacker could just insert evil
I'd not heard of this.
But on reading it closely, I don't think it regulates the referer header,
rather it prevent restricts the origins of resources that a page can load.So it
doesn't work with referrer policies. but I could be wrong
Eric
On Jun 12, 2015, at 12:24 AM, Conal Tuohy
Eric -
Many thanks for raising awareness of this. It does feel like encouraging good
practice re: referrer meta tag would be a good thing, but I would not know
where to start to make something like this required practice. Did you have some
thoughts on that?
— jaf
Assuming your library web server has a front-end proxy (I guess this is
pretty common) or at least runs inside Apache httpd or something, then
rather than use the HTML meta tag, it might be easier to set the referer
policy via the Content-Security-Policy HTTP header field.
http://go-to-hellman.blogspot.com/2015/06/protect-reader-privacy-with-referrer.html
http://go-to-hellman.blogspot.com/2015/06/protect-reader-privacy-with-referrer.html
I hope this is easy to deploy on library websites, because the privacy
enhancement is significant.
I'd be very interested to
