As soon as you mentioned it, I remembered that too. You’re right, late 2004. It was specific to Microsoft software and due to a poorly written GDI+ routine that allowed its program data space to be overwritten. I recall Microsoft being criticized at the time for not cleanly separating code from data.
Good memory.
Ooooh, howdy, Philip M. Parker, nice to see you on teh Boing!
There are however a great many text in which such dynamic controls will hardy be necessary. I think they should just make it a separate format entirely – call it “sliced bound scrolls” or somthing – and let people who have no interest in such frippery keep it far away.
After all this time, after the whole mess with Alexandria viruses and self-scraping vellum attachments and drive-by Illuminations, have people learned nothing?
Then answer is to control the reader app itself. Not a great answer, but just as any decent browser app will offer the option to disable javascript, the readers will need to do so as well. And yes, that will potentially kill off some of the fancier features mentioned - but it would protect the owner from having the script execute.
Media people may be spending on pimping this HTML5 standard - but they’re also going to have to spend on protection efforts to reassure their customers. I would predict this will go into high gear, and make some existing companies very happy right about the time the first ebook virus goes (ahem) viral and the public gets scared.
On the whole, a lousy deal, when you consider that we already have good models of what happens to novice users and what those novice users deliver to virtually everyone who knows them because they either A) collect viruses like they collect stray cats (by feeding them as if they were click-thru ads); or B) drive customer service reps nuts and costs higher because they cannot operate their own property without problems.
Um. Gonna be ugly, any way you slice it.
Really, how many people surf with javascript disabled?
Real people, not card-flashing members of the FSF?
(Member#8082 BTW and I surf with the devil-spawned javascript turned ON baby, 'cause I’m dumbbad like that.)
Zactly!
It seems like major ebook sellers can point to this potential problem and say “See!! It is dangerous to buy ebooks directly from authors … you should only buy them from us!”
Reading this reminded me of seeing people complain that Barnes and Noble was downloading sample chapters onto their ereaders without notification or first asking permission.
Well, jeez. Don’t jinx it!
And more recently, ‘JailBreakMe’ exploited a series of iOS bugs (a TIFF rendering bug, then a PDF rendering bug, then some subtler PDF bug, I think) to jailbreak iOS devices with a single website visit.
I don’t know what percentage of attacks, overall, they make up; but specially crafted inputs that turn renderers into zombie slaves are certainly neither novel nor theoretical. Simpler file formats probably get improved security over time, some of the more complex ones are probably on the ‘yeah, and why don’t I solve the halting problem while I’m at it?’ level of difficulty to open with full safety.
I do, mostly, assuming you count using NoScript selectively as doing so. I mean, I let it run for a few trusted sites, and temporarily allow other sites on a case by case basis, but by default it’s off.
I just find it quieter, I don’t get a lot of annoying features, and I can sometimes make a game of trying to enable the least subdomains possible in order to render the site functional. And if nothing else, it’s a safeguard against accidentally clicking a malicious link. If I go to their site, nothing runs.
This topic was automatically closed after 5 days. New replies are no longer allowed.
