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 >>>>