No to mention that users may get that annoying and paranoia-inducing
browser warning: "These resources can be viewed by others while in
transit, and can be modified by an attacker to change the look of the
page.²

Its enough to scare me off even though its usually harmless.
-Dan

********
Daniel Suchy
Assistant Director
Academic Computing & Media Services
UC San Diego
858.534.9556
[log in to unmask] | acms.ucsd.edu



On 6/12/15, 3:23 PM, "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-s
>>>ecurity-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-r
>>>>eferrer.html
>>>> <
>>>> 
>>>>http://go-to-hellman.blogspot.com/2015/06/protect-reader-privacy-with-r
>>>>eferrer.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
>>>>