Quote:
Originally Posted by tomsem
The whole push behind JavaScript use in ebooks (for purposes of 'communicating' directly with publishers, advertising, etc.) is troubling, and the potential for mischief non-trivial. I'm all for using it to create a pleasant, more interactive reading experience (pop up references etc) but there has to be transparency about what information is being shared and who owns it. And what safeguards are in place to protect privacy, and security.
|
Right.
But that's exactly what they are announcing they intend to do: gather user data via the ebook phoning home.
In the internet age, user data is a product, a form of currency, just as user attention/"eyeballs" is a product.
Google makes its money off our eyeballs and our usage patterns which is how they fund their "free products" by selling our attention to advertisers. Ultimately, Google is an advertising agency masquerading as a tech company. (Which is why their non-search products tend to be second-rate; its not their core business.
)
Given that the ebook is a paid-for product, unlike the majority of web-content, who wants to "pay" again by gifting the publisher with our personal data?
Even if only a few publishers do it, once the word gets out that epub3 ebooks can spy on you, the subtlety that only *some* do it will get lost. The meme is going to be epub3=spyware.
And that is before we get to the other obnoxious use of script-driven ebooks: internal DRM. How is the market going to take to the idea of ebooks with their own shrink-wrap User Agreements? That you need to register and/or activate before you can read it? It's doable.
Even before the spec was finalized, Javascript was a bone of contention because of the can of worms of reader-hostile possibilities it opened up. Don't expect the issue to go away soon; it is part of the spec so somebody *will* use it.