There are certain aspects of EPUB 3 that are underspecified by default.
The navigation document I detailed in the last post is one example. While the rules for structuring the markup are delineated in the specification, the specification itself is not out to mandate the presentation.
Here’s the exact clause that provides the flexibility I’m talking about:
[A reading system] may place additional limitations on the capabilities provided to scripts during execution (e.g., limiting networking).
It’s the final clarification, in particular, that’s proving to be the real pain point: that reading systems can disable network access.
What do you do if you’re trying to create content that can work across devices and you need network access, but not every reading system with scripting gives you that access… well, that’s the $64k question.
But first, why does the restriction exist…
At the top of the reasons for limiting access is malicious content.
I’m firmly in the camp that enabling or disabling network access should be up to the user, but whether you get what you deserve for downloading content from pirate sites is not the sole concern.
Having to worry about network access and what scripts might be doing complicates validation and distribution of content for everyone, whether legitimate content distributors or not. Exploits can appear very benign in nature (e.g., ad network exploits), so anyone wanting to verify content before putting it in their bookstore is going to have a monumentally more difficult task if they have to consider what can happen outside the book.
No one wants a legitimate-seeming ebook in their store that tricks users into giving sensitive information to a third party.
Epubcheck is simply of no use when it comes to verifying what a script is going to do, either, as its focus is compliance to the standards, not trying to virus check runtime code.
While malicious intent is a concern, there are also complications in network access that reach to the very heart of the format.
The law of EPUB 3.0, for example, was that only audio and video files can live outside the container. (EPUB 3.0.1 saw one new addition — descriptions referenced from the
aria-describedat attribute — but it’s still a restrictive list.)
All other content has to be in the container, as predictability of rendering is at the heart of EPUB. You don’t want the user to have to rely on … network access … to access the book each time they want to read.
Network access for scripts blows a hole through the heart of this restriction, since with XmlHttpRequest you can grab most anything you want and inject it into a document (using CORS to get around the same origin policy, of course). You could literally change the text of the book each time it loads, if you were so inclined.
Adding to this particular complexity is that there are legitimate reasons for dynamically updating content.
For example, while I might revile advertisements, buy a magazine and you expect to be bombarded with them. They offset costs. They promote other content you might be interested in.
There’s no reason why they should have to be static, since they’re entirely peripheral to the content. Whether they dynamically rotate or not is unimportant. (Perennially relevant ads is actually kind of a cool idea, at least on the marketing side.)
It’s also not illegal to update content, provided consumption of the ebook is not dependent on script. But the day I believe people will follow that requirement of their own volition is the day I start believing in the Easter Bunny again.
The problem is that you simply can’t open the door only a crack without opening it the whole way, so you have to take the good with the bad.
Forms are another vector of attack, especially for social engineering, if the user thinks they’re a legitimate part of a legitimate ebook. While you can support them independently of scripts, the two generally go hand-in-hand.
As above, they provide a means for information to be extracted and for content to be injected into an ebook, and restrictions on submitting them typically parallels whether you have access to the internet by script.
But forms are also critical for education, so again it’s another case of damned if you do, damned if you don’t.
(There are other technical issues the spec is silent on that would be good to clarify, like what happens after you submit a form. You might infer that the current document should be unloaded and the response loaded as though it follows the document in the spine, but nothing in the specification requires any behaviour. But I’m straying off topic.)
In terms of script access to the network, you’re stuck at the mercy of reading system support for the foreseeable future. There are no workarounds when functionality like this isn’t available.
For forms, there’s always the fallback of hosting them on the web and linking out from the ebook to complete them. It’s a reliable fallback option, at least, and you can potentially reuse the same form both inside the ebook and on the web. But it’s a solution lacking in elegance that creates a divide like CDs at the back of the print book.
Longer term, one idea I’ve heard floated is to require network access only in container-constrained contexts, or, in English, when a script is embedded within an
Since scripts running in this context cannot access the parent, it limits any damage they can do to the publication. They’re effectively sandboxed within the
Assistive technologies should also announce that the user is entering an
iframe, giving context for non-visual readers that they are outside the ordinary.
iframe approach would solve dynamic additions like live ads, but would be a handcuff on content manipulation. But no one’s been asking for network access to manipulate the content of books, so I’m not convinced it’s a real need.
Dynamic widgets that need to pull content from the web (like a twitter feed for a book or author) can easily live within an
The use of
iframes for forms would also solve the question of what to do with the response, since it will be contained within the
iframe and have no impact on the currently loaded document or spine navigation.
But, of course,
iframes aren’t a panacea. It wouldn’t be hard to have a wrapper XHTML document that only embeds an
iframe referencing the actual content document to effectively circumvent the controls.
That’s why I think whatever the support solution is, it also has to involve improving interaction between the reading system and the reader.
Reading systems should alert a reader whenever an attempt is made to access the network. And I don’t mean a little blinking network light in a corner somewhere, but a prompt asking the user to allow the activity, indicating what site the script is attempting to access (and, like browsers, showing the specific domain to avoid phishing).
The user can be given the option to allow all traffic to a given site, or all traffic within an ebook, but putting the access attempts in the user’s face will help mitigate the malicious aspects.
Network activity should also be very apparent. Flash a message at the top or bottom of the page that includes the site the ebook is interacting with.
While, in theory, these measure might be annoying and interfere with the reading experience, you’d have to question why activity would be going on when you aren’t interacting with some widget where you expect it, in which case most people will just mentally filter the information out. My tablet tells me when it’s downloading and installing updates, so why shouldn’t my ebook make clear what is happening behind the scenes?
There’s no reason why these reader-focused measure couldn’t be implemented now, at least in reading systems that support network access.
But that’s enough for today.
While I can yammer on forever, the only takeaway I have is that your hands are bound for now.
How the network access issue evolves is sitting on the radar for the next revision, so it’s not like anyone is actively avoiding it.