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 code into the script. Or verizon could insert x-uidh headers into non-SSL cover image requests. Eric > On Jun 12, 2015, at 2:37 AM, Andrew Anderson <[email protected]> wrote: > > 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 source of a link might be private information or might reveal an > otherwise private information source, it is strongly recommended that the > user be able to select whether or not the Referer field is sent. For example, > a browser client could have a toggle switch for browsing openly/anonymously, > which would respectively enable/disable the sending of Referer and From > information. > > Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP > request if the referring page was transferred with a secure protocol. > > Authors of services which use the HTTP protocol SHOULD NOT use GET based > forms for the submission of sensitive data, because this will cause this data > to be encoded in the Request-URI. Many existing servers, proxies, and user > agents will log the request URI in some place where it might be visible to > third parties. Servers can use POST-based form submission instead > > -- > Andrew Anderson, Director of Development, Library and Information Resources > Network, Inc. > http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | > http://www.facebook.com/LIRNnotes > > On Jun 12, 2015, at 0:24, Conal Tuohy <[email protected]> wrote: > >> 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. >> >> https://w3c.github.io/webappsec/specs/content-security-policy/#content-security-policy-header-field >> >> e.g. in Apache httpd with mod_headers: >> >> Header set Content-Security-Policy referrer 'no-referrer' >> >> >> >> On 12 June 2015 at 13:55, Frumkin, Jeremy A - (frumkinj) < >> [email protected]> wrote: >> >>> 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 >>> >>> ----------------------------------------------------------- >>> Jeremy Frumkin >>> Associate Dean / Chief Technology Strategist >>> University of Arizona Libraries >>> >>> +1 520.626.7296 >>> [email protected] >>> —————————————————————————————— >>> "A person who never made a mistake never tried anything new." - Albert >>> Einstein >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 6/11/15, 8:25 AM, "Eric Hellman" <[email protected]> wrote: >>> >>>> >>> 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 know of sites that are using it; I know Thomas >>> Dowling implemented a referrer policy on http://oatd.org/ < >>> http://oatd.org/> >>>> >>>> Would it be a good idea to make it a required practice for libraries? >>>> >>>> >>>> Eric Hellman >>>> President, Gluejar.Inc. >>>> Founder, Unglue.it https://unglue.it/ >>>> http://go-to-hellman.blogspot.com/ >>>> twitter: @gluejar >>>
