Allow trusted books to load contents from the internet

[ShayonRoy]

Hello,
Even though foliate is very good epub reader in almost every regard, except this one thing where no epub3 book can use contents and embed iframes from external sources because of the content security policy in the reader.html file of foliate-js. I understand that allowing any book to load contents from the internet might be a security risk, but there are often legitimate reasons for some ebooks, for example textbooks, to be able to embed and load contents from elsewhere.

Now, one solution to this would be to add an option to "Trust the book" and using a separate reader.html containing lax csp policy for trusted books. And optionally add fine grained controls(e.g. images, videos, scripts) for "Trust this book" providing users the option to only allow those that they absolutely need, although I do think that this use case(fine grained...) would be very limited

I should mention that, I have tried almost all epub readers out there but not a single one had been comparable to foliate in terms of UI, performace, usability, simplicity and everything except, as i mentioned before, this one thing. And that's the only reason I am forced to use Thorium reader for interactive books even though I hate it. So, adding this simple feature would be much appreciated

[johnfactotum]

It should be noted that, if I'm reading it correctly, remote images and iframes are actually disallowed by the spec:

EPUB creators MAY host the following types of publication resources outside the EPUB container:

• Audio resources.
• Video resources.
• Resources retrieved via scripting APIs (e.g., XmlHttpRequest [xhr] and Fetch [fetch]).
• Font resources.

EPUB creators MUST store all other resources within the EPUB container.

Allowing remote resources would much easier than allowing scripting, especially if iframes are not allowed. The most problematic issue for scripting is that

It MUST assign a unique origin [html], shared by all spine-level scripts of the EPUB publication. That origin [html] MUST be unique for each user-specific instance of an EPUB publication in a reading system.

(From https://www.w3.org/TR/epub-rs/#sec-scripted-content)

This can probably be solved by registering a custom URI scheme, though (1) I'm not sure how origins are handled in WebKit for custom URI schemes, and (2) there's still the issue of how to determine the identity of a book.

One option would be to keep using the unique identifier, but apart from being problematic in itself, it would make it too easy for malicious books to impersonate books that you've trusted. This can be solved by hashing the files, but either you must do this every time when you open a book, or you must store a full copy of the book (which I believe is what Thorium does), both of which are bad for performance.

There are perhaps only two ways around this:

1. There would be no trusting on the book level; either you have to confirm when loading unsafe content every time (which still would leave the user somewhat vulnerable to "phishing" attacks), or you have a global toggle that trusts all books.
2. Require that trusted books be copied or moved to Foliate's internal storage. Or, if that's too confusing, require that all books are copied.

---

Somewhat related is that Foliate doesn't currently support manifest fallback chains, which I think is required when scripting is not supported:

If a reading system does not support scripting, it MUST process fallbacks for scripted content as defined in Fallbacks for scripted content documents [epub-33].

[ShayonRoy]

As I understand it, Foliate does seem to allow scripting, so supporting fallback chains or something is kinda moot(no?).

Now, I am not an expert, but I think I can use the fetch api to just download whatever outside document I want to embed inside iframe and convert it to data: or blob: url, both of which are allowed by CSP in reader.html, and just use that as the source of an iframe element. So, doesn't it kind of circumvent any potential security benefit. All I can see is that disallowing directly using a foreign url only just complicates embedding, doesn't really prevent it altogether.

Another thing to note is that audio and video resources DIRECTLY from outside the container is also disabled by the csp in reader.html and thus making Foliate deviate from the epub spec you mentioned.

Which means, if compliance with the spec is wanted, then the csp values have to be changed to allow outside sources which someone might(or might not. I am not sure) argue would be a security risk too.

All this is to say that some kind of trust system has to be implemented if both compliance with the spec and minimizing the potential attack vector is needed. But then, Foliate might as well expose a toggle for iframes as well and thus giving the user a choice to still be able to read non-compliant interactive books as well

And I understand your concern that implementing a proper trust system would be difficult and would involve compromise on some front. I propose that that compromise should be OS support by using extended file system attributes to store unique identifier(randomly generated mixed with perhaps hash or something the first time a book is opened) directly on the file to solve the trust system issue. And I don't think it's a compromise per se, because (1) Foliate currently only supports linux and (2) AFAIK, there are analogues of extended file system attributes on windows and mac

I should note that, as far as I can imagine, for any malicious book to impersonate a trusted book it has to infect the whole system to be able to scan, read and copy the extended attribute but by which point It's nothing of Foliate's responsibility

I can end here, but just to be comprehensive, the index mapping the trusted identifiers to file path could be encrypted, encryption key of which can be stored on the gnome/kde login keyring, if we are really worried

Edit: previously I missed that allowing outside audio and video resources is only optional according to the spec. But my main point still stands. If a proper trust system(e.g. like the one I proposed) can be implemented, then these optional behaviors as well as non-compliant, but almost no worse in terms of security, behaviors may be enabled depending on the user's choice

[johnfactotum]

As I understand it, Foliate does seem to allow scripting

No, it does not allow scripting. If you are able to use scripting in the current version of Foliate, that would be a bug.

using extended file system attributes

Yes, that sounds like a good way to solve the issue. Though frankly I would personally rather take the first option above ("There would be no trusting on the book level") as it would be much simpler.