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 <[log in to unmask]> 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 <[log in to unmask]> 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 <[log in to unmask]> 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 <[log in to unmask]> 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) <
>>>> [log in to unmask]> 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
>>>>> [log in to unmask]
>>>>> ——————————————————————————————
>>>>> "A person who never made a mistake never tried anything new." - Albert
>>>>> Einstein
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 6/11/15, 8:25 AM, "Eric Hellman" <[log in to unmask]> 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
>>>>>