Bug 38655 - e-books (PDF) to be readable only to authenticated users, Stop download and Print
Summary: e-books (PDF) to be readable only to authenticated users, Stop download and P...
Status: RESOLVED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low new feature
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-09 13:14 UTC by Ujwal
Modified: 2025-04-18 12:52 UTC (History)
5 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ujwal 2024-12-09 13:14:08 UTC
Dear Koha friends,

I have a request from a small library. They would like their e-books to be readable only to authenticated users….  
The user should not be able to download, print or save the PDF locally. This is to stop the one authenticated users
from distributing a e-book among friends.

I have searched and searched in Koha and it seems we don’t have such controls. It would be wonderful if the
Koha community could guide me on this.

Thanks,

Ujwal
Comment 1 Ujwal 2024-12-11 13:05:17 UTC
Dear Owen,

Any news on this...  Would be keen to know your views. 

Also keen to know how we can make this feature a priority if it doesn't exist. 

Thanks,

Ujwal
Comment 2 Katrin Fischer 2024-12-12 15:10:35 UTC
Hi Ujwal, 

Owen is the default Assignee for anything marked for "OPAC", but it won't guarantee that he will pick up something.

In this case, I think Koha can't help you. 

If you want to avoid students to share files with one another, you need to implement DRM and this is not a task Koha can help you with. Even if the link is only visible for registered users, once the file is downloaded or the link known you'd face the same issue again.

Usually this type of limitations is solved by the ebook providers/publishers themselves.
Comment 3 Ujwal 2024-12-19 13:25:48 UTC
Dear Katrin,

This is a bit frustrating as Koha is great with everything else...

It seems Authors are willing to donate their on-line books to the library, but they want to stop the Download and print options....

Koha does great as only logged in users can access the on-line book....  It just doesn't go the extra mile.

I would be willing to pay for this feature  as it would be a pain to have to look at another software.

I hope someone from Koha reads this.

Thanks,

Ujwal
Comment 4 David Nind 2024-12-19 17:53:41 UTC
Mattermost chat thread about this topic https://chat.koha-community.org/koha-community/pl/86nugh1eyfg3fnapmj5o3i6uqr
Comment 5 Katrin Fischer 2024-12-19 21:19:09 UTC
To put this into perspective: I know quite some library systems, but I am not aware of one implementing this feature. As said in chat: this is a complex issue and usually implemented outside of the ILS.
Comment 6 Ujwal 2024-12-23 18:10:07 UTC
Dear Katrin,

Thanks for responding. It appears that our requirement is pretty unique and that surprises me...

Anyway thanks for your help...


Just for your information, the library is below :
 
https://atenlibrary.org/    [ you should be able to navigate to the Koha link ]

I guess a lot of physical libraries are struggling to stay relevant in the age of social media and youtube...  Reading books in our part of the world is taxing :-)
Small libraries have to attract committed members and protect it's asset and the wishes of the authors...

Anyway we will look around for an ideal system.
Comment 7 David Cook 2024-12-24 00:41:10 UTC
(In reply to Ujwal from comment #3)
> This is a bit frustrating as Koha is great with everything else...

Everything in Koha comes from someone's time, effort, and ultimately money.
 
> It seems Authors are willing to donate their on-line books to the library,
> but they want to stop the Download and print options....

That's quite interesting to know. You have authors in mind for this already?

> Koha does great as only logged in users can access the on-line book....  It
> just doesn't go the extra mile.
> 
> I would be willing to pay for this feature  as it would be a pain to have to
> look at another software.

It's an interesting topic, and you're not alone in wanting this feature. It's an increasingly common request I've heard amongst my Koha users.

On Mattermost, I thought that you were wanting to implement DRM with downloadable ebooks, and that is quite complicated.

But here it sounds like you're more interested in a web-based ereader available only to authenticated users. That is different, and I have had a number of libraries desire this same feature in recent years.

I'd have to do some more thinking, but I think it might be doable with a Koha plugin. You'd need to pay a developer (like myself or someone else from the Paid Support vendors https://koha-community.org/support/paid-support/), but it might be doable.
Comment 8 David Cook 2024-12-24 00:53:59 UTC
(In reply to Katrin Fischer from comment #5)
> To put this into perspective: I know quite some library systems, but I am
> not aware of one implementing this feature. As said in chat: this is a
> complex issue and usually implemented outside of the ILS.

I believe that Queens Public Library and New York Public Library have both integrated with Adobe Content Server according to an Australian-based ACS reseller.

Baobab ebooks provider in the UK also have a 9 year old modified Koha that allows for DRM protected ebook downloads for authenticated users.

As for ereaders, I think there have been some Koha vendors that have local customisations that hide links from unauthenticated users, but not quite full ereaders. I do know an archive that is implementing a custom ereader for authorized authenticated users.

I get requests for all the above a few times a year. The most recent one just a week or two ago.

Integrating with ACS or Readium have licensing costs attached, and a number of unknowns, so tough to work out pricing for this.

An ereader that just shows 1 page of a publication at a time to an authenticated user... that would be cheaper. I believe that's how a number of commercial app-based systems work. 

--

I think for many libraries they're going to get their licensed DRM-protected ebooks from third-party systems like EBSCO, Overdrive, etc. 

I do have libraries in organisations that produce content that only want their members to view it. I think that's a good use case.

I suppose there might be libraries where authors are willing to provide ebooks so long as they have restrictions. I'm not so sure about that one. But it could be interesting to explore. 

Licensing certainly comes with implications... so I think perhaps a Koha plugin is better than core Koha for exploring this sort of functionality.
Comment 9 Chris Cormack 2024-12-26 21:30:41 UTC
I agree that a plugin is the only way to go.
It should not be built into Koha for multiple reasons. If people want to use Adobe DRM and all the evil that entails that's their choice. But keeping it out of the core is vital for living up to the ideals we speak about.
Comment 10 Ujwal 2025-01-02 11:31:08 UTC
(In reply to David Cook from comment #7)
> (In reply to Ujwal from comment #3)
> > This is a bit frustrating as Koha is great with everything else...
> 
> Everything in Koha comes from someone's time, effort, and ultimately money.
>  
> > It seems Authors are willing to donate their on-line books to the library,
> > but they want to stop the Download and print options....
> 
> That's quite interesting to know. You have authors in mind for this already?
> 
> > Koha does great as only logged in users can access the on-line book....  It
> > just doesn't go the extra mile.
> > 
> > I would be willing to pay for this feature  as it would be a pain to have to
> > look at another software.
> 
> It's an interesting topic, and you're not alone in wanting this feature.
> It's an increasingly common request I've heard amongst my Koha users.
> 
> On Mattermost, I thought that you were wanting to implement DRM with
> downloadable ebooks, and that is quite complicated.
> 
> But here it sounds like you're more interested in a web-based ereader
> available only to authenticated users. That is different, and I have had a
> number of libraries desire this same feature in recent years.
> 
> I'd have to do some more thinking, but I think it might be doable with a
> Koha plugin. You'd need to pay a developer (like myself or someone else from
> the Paid Support vendors https://koha-community.org/support/paid-support/),
> but it might be doable.


Dear David,

Yes it is the e-reader feature we are after.
I am keen to look at the Koha plugin and cost. If you could come up with a price , I would be keen to consider. 

If a bunch of us could share the cost of development that would be great and the plugin could be available for everyone... 

Yes i/we would be keen to look at the paid Koha plugin options.

Thanks,

Ujwal
Comment 11 Ujwal 2025-01-02 11:38:16 UTC
> That's quite interesting to know. You have authors in mind for this already?
> 

Yes the authors are local ones... small ones...



> > Koha does great as only logged in users can access the on-line book....  It
> > just doesn't go the extra mile.
> > 
> > I would be willing to pay for this feature  as it would be a pain to have to
> > look at another software.
> 
> It's an interesting topic, and you're not alone in wanting this feature.
> It's an increasingly common request I've heard amongst my Koha users.
> 
> On Mattermost, I thought that you were wanting to implement DRM with
> downloadable ebooks, and that is quite complicated.
> 
> But here it sounds like you're more interested in a web-based ereader
> available only to authenticated users. That is different, and I have had a
> number of libraries desire this same feature in recent years.

Cool :  if we could hare the cost of development ... that would be perfect....  But I guess this is hard to coordinate....


> 
> I'd have to do some more thinking, but I think it might be doable with a
> Koha plugin. You'd need to pay a developer (like myself or someone else from
> the Paid Support vendors https://koha-community.org/support/paid-support/),
> but it might be doable.

Looking forward to getting some idea of the cost... If the cost can be shared .... that would be amazing...
Comment 12 David Cook 2025-01-06 06:02:43 UTC
I'd have to think about this one some more...

For a web reader, I'd say you'd need to pre-process your PDFs ahead of time. Splitting them into individual pages and converted into images, which could then be served one by one (for performance and security).

(But then... there is the question of where this data is stored and served from. Depending on the amount of data and views you're planning, you'd need to consider the operational costs involved.)

I suppose a simple version could be done where the content is stored on the Koha server and served from it. Having Koha serving the content would slow down your Koha overall, but that might be acceptable for you. 

--

Actually, as I write this, I'm reminded that this topic is already handled by the IIIF (International Image Interoperability Framework). 

Most of my experience with IIIF is with publicly accessible content, but IIIF does come with authorization APIs too. 

--

Typically, with IIIF you have an "Image Server" (like the Java-based Cantaloupe) and an "Image Viewer" (like the Javascript-based Universal Viewer). The IIIF-enabled web app has the "Image Viewer" and the app gives the Image Viewer a URL to a IIIF Manifest which is a JSON file, which contains links to the Image Server.

Technically, I think you don't have to use an Image Server. I think that you can just use static images as well.
Comment 13 David Cook 2025-01-06 06:19:52 UTC
Locally, we have a custom Koha endpoint which generates IIIF manifests on-the-fly.

We run a Cantaloupe IIIF image server, which fetches images from a S3-compatible object storage service, which makes the storage cheap. 

We actually use an iframe in Koha to point to a Universal Viewer that we host on a non-Koha system, but there's other ways that could be implemented.

--

As I said, I'd have to think more, but perhaps a IIIF plugin could be created, which could only serve image content to authenticated users.

Converting the PDFs into images is harder/more complicated, but not impossible. It could actually be its own plugin as well. A plugin which ingests PDFs and turns them into images with a particular layout or a IIIF friendly layout. 

A IIIF plugin could actually be useful for many libraries in different contexts. Perhaps we could replace our local customization with a IIIF plugin. Hmm...
Comment 14 Katrin Fischer 2025-01-07 08:32:12 UTC
Adding Mark, since IIIF sounds vaguely familiar.
Comment 15 Mark Hofstetter 2025-01-07 10:15:16 UTC
I am currently working on a IIIF plugin for koha

slides in german here: https://www.db-thueringen.de/receive/dbt_mods_00064224

to display the pdfs properly they have to be/are separated in pages already

I expect a release in Q1/2025

displaying only to authenticated user is/would be easy, the mechanism of IIIF maybe also may serve as some sort of poor mans DRM because it make it harder to download the whole pdf - although I don't have DRM on my mind and would like to avoid it
Comment 16 Ujwal 2025-01-13 11:27:56 UTC
(In reply to Mark Hofstetter from comment #15)
> I am currently working on a IIIF plugin for koha
> 
> slides in german here: https://www.db-thueringen.de/receive/dbt_mods_00064224
> 
> to display the pdfs properly they have to be/are separated in pages already
> 
> I expect a release in Q1/2025
> 
> displaying only to authenticated user is/would be easy, the mechanism of
> IIIF maybe also may serve as some sort of poor mans DRM because it make it
> harder to download the whole pdf - although I don't have DRM on my mind and
> would like to avoid it

I read the german presentation. Thanks...

So a PDF doc will have to be spilt into images per page and stored in a IIIF server ?

Yes I think a poor mans DRM would be OK .... If the images cannot be downloaded that would be great. The library we are talking about is basically a charity and the annual membership fee is USD 10 per year. So the value of the work/authors that we are aiming to protect is peanuts.
Comment 17 David Cook 2025-01-13 22:33:06 UTC
(In reply to Mark Hofstetter from comment #15)

Thanks, Mark. I'll have to set aside some time to go through your comment in depth.

(In reply to Ujwal from comment #16)
> So a PDF doc will have to be spilt into images per page and stored in a IIIF
> server ?

PDF doc split into pages - yes.

Stored in a IIIF server - probably/potentially. There are ways of avoiding a IIIF server if it adds too much complication, although that adds complications of its own ;).

> Yes I think a poor mans DRM would be OK .... If the images cannot be
> downloaded that would be great. The library we are talking about is
> basically a charity and the annual membership fee is USD 10 per year.

From a technical standpoint, it is very difficult if not impossible to prevent images from being downloaded, because the image needs to be rendered on the user's screen. Once it's been rendered on the screen, it's possible for it to be captured in some way by that user. 

However, what we can do is add layers of security on top to make it more difficult to download those images. The same concept is used in all forms of security. 

For example, you put a lock on door handle to your house to prevent someone from just opening the door and walking in. But a determined thief will just break the lock or break a window and enter. So then maybe you add bars to the window and get a deadbolt for the door which is not so easy to break. That prevents that determined thief, but an even more determined thief will break a hole in the wall and enter that way.

Ultimately, it's about measuring risk and implementing proportionate counter-measures. 

In this case, I think you have 3 key elements. First, only allowing authenticated users to view the ebook content (although you/we should keep in mind self-registrations and whether they should be able to view). Second, splitting the PDF into images, so that you're not transmitting the entire ebook to the user's computer at once. Third, using a web viewer like the IIIF Universal Viewer, typically prevents people from right clicking to save the full sized image (it's always possible to add some additional UI-based security on top of the viewer as well). 

Even if someone did a screenshot for the page, they'd have to manually do it for every page to try to reconstruct the entire ebook. While it is possible, it is not very likely. (There are also methods for automating it, but that would require a determined and experienced person looking to abuse the system and steal the ebooks.)
Comment 18 David Cook 2025-01-13 22:42:05 UTC
(In reply to Ujwal from comment #16)
> Yes I think a poor mans DRM would be OK .... If the images cannot be
> downloaded that would be great. 

For what it's worth, more expensive DRM like Adobe's is already broken. An knowledgeable user can easily use third-party software to strip DRM from files protected by Adobe. The most secure part of the Adobe model is in delivering content only to authorized users. 

In that way, the expensive DRM works in a similar way to the method proposed above. These protections can prevent inexperienced/everyday users from downloading the full content, but an experienced/knowledgeable user can work around most security if they have enough time and energy.

But remember in both cases if the user has to be an authenticated authorized user... that really mitigates a lot of the risk, especially if you record which user is accessing which content. 

By having that audit log, you can then do some analysis to see if someone is likely abusing the system. In theory, that audit log could have some privacy concerns, but it's not dissimilar to the circulation tracking anyway, although I'll note that can be anonymized. 

Anyway, hopefully that provides some insight into electronic document security.

At the end of the day, there are no absolute guarantees, but you can try to limit the risk as much as possible by adding layers of security.
Comment 19 David Cook 2025-01-15 05:29:27 UTC
(In reply to Mark Hofstetter from comment #15)
> I am currently working on a IIIF plugin for koha
> 
> slides in german here: https://www.db-thueringen.de/receive/dbt_mods_00064224

My German is super basic so I wasn't able to follow much of that, but I've used Cantaloupe and Mirador. I find Mirador a bit overwhelming visually and like how light Universal Viewer is, but *shrug*. 
 
I don't really like the 856$2 since "IIIF-Manifest" isn't a valid code from the "Electronic Access Methods Code List", but it can be difficult to find a hook, so I can understand the idea.

For our local customization, we use a special item type as our hook, which I don't love either.
Comment 20 Ujwal 2025-04-18 12:52:09 UTC
(In reply to Mark Hofstetter from comment #15)
> I am currently working on a IIIF plugin for koha
> 
> slides in german here: https://www.db-thueringen.de/receive/dbt_mods_00064224
> 
> to display the pdfs properly they have to be/are separated in pages already
> 
> I expect a release in Q1/2025
> 
> displaying only to authenticated user is/would be easy, the mechanism of
> IIIF maybe also may serve as some sort of poor mans DRM because it make it
> harder to download the whole pdf - although I don't have DRM on my mind and
> would like to avoid it

@Mark Hofstetter :  I am keen to follow up on your work.... Do you have a release yet as it is past `Q1/2025`. I am fairly new to Koha so I am not sure how I can review the plugin or Koha version that you have worked on.