[Bug 38655] New: e-books (PDF) to be readable only to authenticated users, Stop download and Print
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 Bug ID: 38655 Summary: e-books (PDF) to be readable only to authenticated users, Stop download and Print Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard@myacpl.org Reporter: ujkhatry@gmail.com QA Contact: testopia@bugs.koha-community.org 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 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 Ujwal <ujkhatry@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ujkhatry@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 Ujwal <ujkhatry@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion --- Comment #1 from Ujwal <ujkhatry@gmail.com> --- 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 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #3 from Ujwal <ujkhatry@gmail.com> --- 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 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #4 from David Nind <david@davidnind.com> --- Mattermost chat thread about this topic https://chat.koha-community.org/koha-community/pl/86nugh1eyfg3fnapmj5o3i6uqr -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #5 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #6 from Ujwal <ujkhatry@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|In Discussion |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #7 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz --- Comment #9 from Chris Cormack <chris@bigballofwax.co.nz> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #10 from Ujwal <ujkhatry@gmail.com> --- (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 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #11 from Ujwal <ujkhatry@gmail.com> ---
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... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #13 from David Cook <dcook@prosentient.com.au> --- 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... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |koha@trust-box.at --- Comment #14 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Adding Mark, since IIIF sounds vaguely familiar. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #15 from Mark Hofstetter <koha@trust-box.at> --- 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 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #16 from Ujwal <ujkhatry@gmail.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #17 from David Cook <dcook@prosentient.com.au> --- (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.) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #18 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=21412 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #20 from Ujwal <ujkhatry@gmail.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |--- Status|CLOSED |REOPENED --- Comment #21 from David Cook <dcook@prosentient.com.au> --- I was chatting with a colleague over at PHAIDRA and he mentioned PDF.js. I remember looking at PDF.js a long time ago, but disregarded it for this use case, but it seems that it has advanced quite a bit, especially in the last couple of years. It seems to me that you could provide a protected API endpoint that lets PDF.js request and render small chunks of the PDF from the backend. -- I'm going to re-open this one as I think there's some experimenting that could be done... It wouldn't be high on my priorities by any means, but it could be interesting for someone to explore... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 --- Comment #22 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #21)
I was chatting with a colleague over at PHAIDRA and he mentioned PDF.js.
It seems also that Universal Viewer does use PDF.js itself by default in newer versions I think. Or it can be configured to use it at least which is quite interesting as well. When using PDF.js, you don't have to pre-process the PDF by splitting it up into individual pages. Instead, it requests the PDF structure (usually stored at the end of the PDF but I think it can sometimes be stored at the front), and then does a HTTP range request for just the bytes that it needs based on the structure of the PDF. Very clever. I don't know how it renders it. Whether it's on a <canvas> or something else. But yeah... interesting for sure. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard@myacpl.org |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org