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
