Apple accepts Javascript in EPUB ebooks in iBookstore | Hacker News Reader

Apple accepts Javascript in EPUB ebooks in iBookstore

pigsgourdsandwikis.com

38 pointsjoshuacc30 comments

I had no idea epub allowed js in the spec. My reactionary opinion on this is negative. Why do we need this? What reason is there to have js in epub when we already have js in html? What distinction will there be between html and epub if they are both just document formats that can also execute js?

So the good thing about ePub was that it was less capable than HTML, and now they've made ePub worse by making it better?

Possibly, like I said it was my reactionary opinion. However being limited by design can be a good thing.

JavaScript isn't in the current ePub 2.0 spec. Though it is suggested in the 3.0 draft. Like Apple extended ePub 2.0 with audio/video support, they seem to either support it or not prevent it.

Does the standard even really matter, since the content is wrapped in DRM anyways and can only be played in the eBooks app?

It does to producers, who often target multiple ebook platforms.

As a web developer who specializes in JavaScript, I'm really thrilled -- but as a person who reads books, I'm a little worried. What does the iTunes approval process for iBooks look like? Will any kind of HIG be enforced on the books? Do book publishers have good taste in interactivity? If I wanted interactivity, I would go to the internet.

This brings a lot of interesting possibilities to technical books. End-of-chapter review questions that are automatically graded being the most obvious.

Or background/animated images in children' books. Or dynamic content adjusting to what you already know / had already read. I.e. I know what a prototype is, automatically, all the chapters/paragraphs explaining it could be hidden.

There are plenty of books with webkit animations already in the bookstore.

Hm... interesting security implications depending on how the code executes, what external info/code it can call

So my ebooks can now contain executable root kits.

Cool.

Javascript is pretty well jailed up, you can't communicate with local and remote files in the same javascript file.

That sort of protection has nothing to do with js, but rather the browser, which isn't in play here.

Edit: It's implemented via Mobile Safari, as pointed out by justincormack -- this comment is invalid.

iBooks is implemented using mobile Safari, so the security model is the same.

It uses CSS3 columns to make the pages going across.

Ah hah, I was mistaken. Thanks!

I find it rather silly to be worried about security given that Apple's one of the largest browser vendors in the world, directly or indirectly via WebKit.

More accurately: all increasing of capabilities in non-immediately-apparent sources IS cause for concern. But that has to be weighted against the exhibited competence of the vendor. I find it unlikely that we-vet-everything our-brand-name-is-safe-computing-experiences Apple wouldn't have considered security in this move.

Presumably they have. But given the number of times Safari has been remotely exploitable in the past, that's not necessarily reassuring.

How is this different than Adobe Reader, where the ability to execute code within a document reading application has resulted in world wide exploits of operating systems?

If my document reader can execute any code in any language, then any document that I read has the potential to execute malicious code on my computer, and I now have an exploit vector that I need to consider when downloading documents & opening e-mail attachments.

I understand that the code can be sandboxed, but before I implicitly trust the sandboxing technology, I'd have to see an example of an unexploitable sandbox. I don't know of any - but that doesn't mean they don't exist.

Chrome one has stood up the best thus far

Right, but "the best" being a very misleading term for anyone not in the know. It too has failed to do the job.. But, of course, no code is perfect. Just keep that in mind.

http://www.informationweek.com/news/security/attacks/2295000...

Adobe gives the same access it has to save to any folder on the drive, to the scripts in the PDF. Apple doesn't make those kind of mistakes.

I agree. Logical follow-up questions would be:

- is this using the fast JavaScript JIT (http://news.ycombinator.com/item?id=2666763)?

- what API is available to eBook JavaScript? Can one make Ajax calls? How much of the book's content can one replace? Make permanent changes to book content?

- Depending on e answers, what differences remain between eBook reader and web browser?

I was worried about the direction of iBooks and the growing interest in making app-based books instead of using the native iBooks store. This makes me more optimistic about the future of iBooks.

Previously, in a kind of reverse thing, any booklike app that didn't have interactivity was refused as a normal app and had to go in the iBook store. But interactivity ie Javascript in iBooks did not seem to be allowed.

The ePub committee spent a lot of time trying to decide if ePub was just a browser and what an eBook was, but maybe Apple have decided.

Not sure they would accept an HTML5 game as an iBook though. A kids book with puzzles in might work though and still sell as a book not an app.

An Young Girl Illustrated Primer, or, Diamong Age here we go!

This is fantastic. I'm glad to see Apple doing what they do best... enabling content developers to be creative. Adobe has a long way to go.

"Photoshop CS4 supports scripts written in AppleScript, JavaScript or VBScript. ..."

etc.. :)

What would you like to see from Adobe to change your mind?

Not rendering magazines as 500MB packs of PNGs would be a start.

Bingo. Their magazine viewer is bloated. RMSDK is garbage. Start by bringing their expertise in layout and fonts to things that people are actually using. Namely, WebKit and JS.

Reply on news.ycombinator.com