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