 |
 |
On Jun 17, 2014, at 17:09, Stuart Yeates <[log in to unmask]> wrote: > On 06/17/2014 08:49 AM, Galen Charlton wrote: >> On Sun, Jun 15, 2014 at 4:03 PM, Stuart Yeates <[log in to unmask]> wrote: >>> As I read it, 'Freedom to Read' means that we have to take active steps to >>> protect that rights of our readers to read what they want and in private. >> [snip] >>> * building HTTPS Everywhere-like functionality into LMSs (such functionality >>> may already exist, I'm not sure) >> >> Many ILSs can be configured to require SSL to access their public >> interfaces, and I think it would be worthwhile to encourage that as a >> default expectation for discovery interfaces. >> >> However, I think that's only part of the picture for ILSs. Other >> parts would include: >> >> * staff training on handling patron and circulation data >> * ensuring that the ILS has the ability to control (and let users >> control) how much circulation and search history data gets retained >> * ensuring that the ILS backup policy strikes the correct balance >> between having enough for disaster recovery while not keeping >> individually identifiable circ history forever >> * ensuring that contracts with ILS hosting providers and services that >> access patron data from the ILS have appropriate language concerning >> data retention and notification of subpoenas. > > 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. > > cheers > stuart This is something that I have been interested in as well, and I have been asking our content providers when they will make their content available via HTTPS, but so far with very little uptake. Perhaps if enough customers start asking, it will get enough exposure internally to drive adoption of HTTPS for the content side. I looked into what EZproxy offers for the user side, and that product does not currently have the ability to do HTTPS to HTTP proxying, even though there is no technical reason why it could not be done (look at how many HTTPS sites run Apache in a reverse proxy to HTTP servers internally for load balancing, etc.) EZproxy makes the assumption that a HTTP resource will always be accessed over HTTP, and you cannot configure a HTTPS entry point to HTTP services to at least secure the side of the communication channel that is going to contain more identifiable information about the user, before it becomes aggregated into the general proxy stream. -- 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