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 mixing HTTP/HTTPS resources, but rather wholesale > converting to SSL and taking advantage of the fact that vendors don’t seem to > care about privacy issues and do not support SSL today. Thus when leaving > the secure site, the referring header will not be sent, thanks to RFC 2616 > behavior. > > Of course, SPDY^WHTTP/2.0 will make this moot, but perhaps someone can > convince the standards group that referring URLs are not a good idea to carry > forward in general. > > -- > 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 18:23, Eric Hellman <e...@hellman.net> wrote: > >> 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 <and...@lirn.net> 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 <conal.tu...@gmail.com> 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) < >>>> frumk...@email.arizona.edu> 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 >>>>> j...@arizona.edu >>>>> —————————————————————————————— >>>>> "A person who never made a mistake never tried anything new." - Albert >>>>> Einstein >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 6/11/15, 8:25 AM, "Eric Hellman" <e...@hellman.net> 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 >>>>>
