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