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
