 |
 |
On 06/18/2014 12:36 PM, Brent E Hanner wrote: > Stuart Yeates wrote: > >> Compared to other contributors to this thread, I appear to be (a) less >> worried about state actors than our commercial partners and (b) keener >> to see relatively straight forward technical fixes that just work 'for >> free' across large classes of library systems. Things like: >> >> * An ILS module that pulls the HTTPS Everywhere ruleset from >> https://gitweb.torproject.org/https-everywhere.git/tree/HEAD:/src/chrome/content/rules >> and applies those rules as a standard data-cleanup step on all >> imported data (MARC, etc). >> >> * A plugin to the CMS that drives the library's websites / blogs / >> whatever and uses the same rulesets to default all links to HTTPS. >> >> * An EzProxy plugin (or howto) on silently redirectly users to HTTPS >> over HTTP sites. > > So let me see if I understand this. Your concern is that commercial > partners are putting HTTP links in their systems rather than HTTPS. > Because HTTPS only protects from a third party so the partner will still > have access to all the information about what the user read. IP6 will > improve the HTTPS issue but something like HTTPS Everywhere ( > https://www.eff.org/https-everywhere ) is actually the simplest > solution, especially as you can't be sure every link will have HTTPS. My concern is that by referring users to resources and services via HTTP rather than HTTPS, we are encouraging users to leak more personal information (reading habits, location, language settings, etc) to third parties. These third parties include our networking providers, our hosting providers, our content providers, the next person who uses the users' public computer, etc., etc. HTTPS protects in multiple ways. Firstly it protects the data 'on the wire' (but that is rarely a problem in practice). Secondly HTTPS protects from web caching attacks. Thirdly the fact that a connection is HTTPS causes almost all tools and applications to use a more secure set of options and preferences, covering everything from cookie handling, to not remembering passwords, not storing local caches, using shorter timeouts, etc. This last category is where the real protection is. There are lots of privacy breaches that HTTPS won't deter (a thorough compromise of the users' machine, a thorough compromise of the content provider's machine, etc.), but it raises the bar and protects against a significant number of breaches that become impossible or much, much harder / less likely. My understanding is that that HTTPS and EzProxy can potentially protect readers identity very effectively (assuming the library systems are secure and no one turns up with a warrant). > And having just read the Freedom to Read Statement, this issue has no > bearing on it. Freedom to Read is about accessibility to materials, not > privacy. While no doubt there is some statement somewhere about that, > Freedom to Read is a statement about diversity of materials and not the > ability to read them without anyone knowing about it. If materials are only available at the cost of personal privacy, are they really available? In repressive regimes all across the world people are actively discriminated against (or worse) for read the wrong book, being in the wrong place or communicating in the wrong language. How many of us live in countries where currently (or in living memory) people are been derided for speaking a non-English language? cheers stuart