Because I had posted early in this thread, I wanted to close the loop: we
are not moving forward with Lean Library at the moment. We have had several
rounds of correspondence with LL that were, at best, evasive and confusing.
One of these occurred before the code4lib thread but it continued after
they became aware of ASU's audit and our specific interest in the
implementation details. We wanted to see much more definitive information
confirming how the data is transmitted or stored; our concerns increased
rather than being allayed.

We'd really like to be able to offer an extension that has this
functionality, which would mitigate a significant pain point for users, and
hope to continue a conversation about it with Lean Library and other
libraries.

Emily
Penn Libraries

On Wed, Sep 5, 2018 at 12:32 PM Tammy Wolf <[log in to unmask]> wrote:

> I just met with Johan Tilstra, CEO of Lean Library this morning. According
> to Johan, the fact that browser activity was being sent to Lean Library was
> an architectural oversight. He has committed to a change the way they
> collect data, specifically storing browsing activity locally, rather than
> sending it to Lean Library. They current have a new architecture in Beta
> and should have something to show next week.
>
> I feel encouraged that the company really does seem committed to
> transparency and user privacy. We will see how things go testing-wise when
> the new plugin is released.
>
> Thanks so much for this great and lively discussion.
>
>
> Tammy Allgood Wolf
> Director of Discovery Services
> ASU Library
> Arizona State University
> 480-965-1797
>
>
>
>
> -----Original Message-----
> From: Code for Libraries <[log in to unmask]> On Behalf Of Eric
> Hellman
> Sent: Friday, August 31, 2018 10:15 AM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] Lean Library Security Concerns
>
> Wow. Lean Library seems to be sloppily implemented, has a privacy policy
> that says that big dutch companies that acquire them receive ALL the user
> data, and the word "collect" doesn't mean what they think it means. The
> icing on the cake is that their T&C forbid us from reverse engineering
> their code to see what it really does.
>
> From their "privacy policy":
> We may disclose the information we obtain:
> If Lean Library is involved in a merger, acquisition or sale of all or a
> portion of its Please note that you will be notified by either email or a
> prominent notice on our website of any changes in ownership or uses of this
> information.
> from their T&C
> No Reverse Engineering and the like.User nor Licensee may, or may cause or
> permit any of its employees or any third party to, modify, adapt,
> translate, reverse engineer, decompile, disassemble, translate or create
> derivative works based on the Service without the prior written consent of
> Licensor, which Licensor may withhold in its sole discretion.
>
> Any librarian that pays to hand users over to LL as it presents itself
> today needs to reflect on their life choices.
>
> Having said that, (and having been involved in browser extension projects)
> I think LL would be super valuable if done right, with all the i's dotted
> and t's crossed.
>
> That would mean building independent code review and privacy and data
> audits of ops into LL's contracts. Remember that giving a company
> phone-back access to a browser extension gives that company (and anyone
> with the power or craft to compel that company) to see everything a user
> does online, credit card numbers, browsing behavior, passwords, EVERYTHING!
> Libraries need to examine their potential legal liability for their
> patron's catastrophic security loss if they recommend installation of this
> product (as presented today.)
>
> If anyone needs technical backup on this, please don't hesitate to contact
> me.
>
> Eric Hellman
> President, Free Ebook Foundation
> Founder, Unglue.it https://unglue.it/
> https://go-to-hellman.blogspot.com/
> twitter: @gluejar
>
> > On Aug 21, 2018, at 6:04 PM, Tammy Wolf <[log in to unmask]> wrote:
> >
> > I just wondered if anyone else on this list reviewed Lean Library<mailto:
> https://www.leanlibrary.com/> and had any security and/or privacy
> concerns.
> >
> > Here is what our Director of Security had to say,
> >
> > "I can confirm that browsing activity is sent to lean library. Attached
> is an example screenshot showing the POST when visiting a URL on
> reddit.com. And if you visit
> https://app.leanlibrary.com/?r=api/api/institutes it's trivial to see
> info about all subscribers of lean library.
> >
> > Also, there are Repeated Pings to capture user IP Address. This was also
> verified during the session capture. This occurs via
> https://app.leanlibrary.com/?r=api/api/getIp."
> >
> > Our Security Director goes on to say the following:
> >
> > "Of course this is also a question of consent. Any users of the plugin
> should first have to consent to the privacy policy:
> https://www.leanlibrary.com/privacy-policy/item181 - which would be in
> conflict with deploying this automatically to lab computers. I have some
> issues with the privacy policy itself as well. It states:
> >
> > What information does Lean Library and The Extension NOT obtain?
> > Your security and privacy is our biggest priority. We are only
> interested in information or data that can help us deliver the best
> experience possible in saving you time while and optimizing your academic
> research. Therefore, The Extension does not store any information for other
> browsing activity such as activity on non-database webpage urls.
> > Maybe they aren't technically "storing" the fact that I visited a URL on
> reddit.com, but that visit still went to their server and was captured /
> analyzed *somehow*. It would be more accurate for them to say that they
> analyze all sites you visit to determine whether they are academic in
> nature, or something. But that would be a red flag."
> >
> > Thoughts?
> >
> > Tammy Allgood Wolf
> > Director of Discovery Services
> > ASU Library
> > Arizona State University
> > 480-965-1797
> > <leanlibrary-postrequest.jpg>
>