Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Adobe Security Chief Defends JavaScript Support

timothy posted more than 4 years ago | from the oh-it's-gotta-have-javascript dept.

Security 216

Trailrunner7 writes "Despite the fact that the majority of [PDF-related] malware exploits use JavaScript to trigger an attack in Adobe's PDF Reader product, the company says it's impossible to completely remove JavaScript support without causing major compatibility problems. In a Q&A on Threatpost, Adobe security chief Brad Arkin says the removal of JavaScript support is a non-starter because it's an integral part of how users do form submissions. '"Anytime you're working with a PDF where you're entering information, JavaScript is used to do things like verify that the date you entered is the right format. If you're entering a phone number for a certain country it'll verify that you've got the right number of digits. When you click 'submit' on the form it'll go to the right place. All of this stuff has JavaScript behind the scenes making it work and it's difficult to remove without causing problems," Arkin explained.'"

cancel ×

216 comments

Sorry! There are no comments related to the filter you selected.

Easy but far too simple solution (5, Insightful)

richdun (672214) | more than 4 years ago | (#30656790)

Why not let PDFs only display documents, and rely on web forms for submitting information? No? Too simple?

I personally have hated PDF forms for some - as a Mac user, having an OS with great PDF support built-in, but still having to use Adobe's products to use their non-standard (or newly made standard) forms implementation is a headache.

Re:Easy but far too simple solution (2, Informative)

sopssa (1498795) | more than 4 years ago | (#30656834)

Well you can always use alternate PDF readers, like Foxit Reader [foxitsoftware.com] (and no bloat either)

Re:Easy but far too simple solution (3, Interesting)

pmontra (738736) | more than 4 years ago | (#30657124)

Simply switching one user to another safer reader won't solve this security problem because most people use the Adobe's one. Disabling JavaScript by default in Adobe Reader would. People that for some reason have to use PDF forms will enable it or will be told how to by their IT department. By the way, I'm using evince on Linux to read PDF. I discovered now that it supports forms but apparently it doesn't have javascript. I'm probably safe.

Re:Easy but far too simple solution (1)

morgan_greywolf (835522) | more than 4 years ago | (#30657306)

Right. Because switching users to a safer browser (Firefox) has had no impact on security because most people were using Microsoft's (Internet Explorer)? People switching to Linux and OS X has also had no impact on security either, I suppose?

Re:Easy but far too simple solution (1, Funny)

Anonymous Coward | more than 4 years ago | (#30657490)

People switching to Linux and OS X has also had no impact on security either, I suppose?

Pretty much. Those malware-ridden deb packages for Ubuntu pretty much showed the falsity of such a claim.

Re:Easy but far too simple solution (2, Insightful)

nitroscen (811508) | more than 4 years ago | (#30657960)

You should really read the posts you are replying to before bashing them. The guy was just saying it won't solve the problem. He didn't say it 'has had no impact'. He was simply stating that the solution to this problem requires some action on Adobe's part... just like how the solution to most security problems you bring up require some action on Microsoft's part.

Re:Easy but far too simple solution (0)

Anonymous Coward | more than 4 years ago | (#30657238)

Problem is that Foxit Reader has vulnerabilities associated with it as well. Sadly when it comes to PDF files in general you have to rely on various security measures. The final and sadly most used is "User Awareness". If the file is able to get through all your defensive barriers, it still has to get opened by the user (through either web browser or seperate PDF viewer) and this is where "User Awareness" comes in to play.

Re:Easy but far too simple solution (4, Informative)

toleraen (831634) | more than 4 years ago | (#30657888)

L [nist.gov] O [nist.gov] L [nist.gov]

All NIST tracked vulnerabilities for Foxit in the last two years have been of the "open a bad PDF and get infected" variety. How is Foxit any better, other than executing infected PDFs faster?

Re:Easy but far too simple solution (2, Funny)

kestasjk (933987) | more than 4 years ago | (#30656884)

I'm also surprised the Adobe Security Chief didn't consider the option of ditching PDF for HTML in this interview

Re:Easy but far too simple solution (0)

Anonymous Coward | more than 4 years ago | (#30657002)

I'm also surprised the Adobe Security Chief didn't consider the option of ditching PDF for HTML in this interview

How exactly is Adobe going to make money off of that?

Re:Easy but far too simple solution (1)

morgan_greywolf (835522) | more than 4 years ago | (#30657432)

It's not as if they're making much money on PDF now. Adobe's largest revenue stream comes from their design applications like Photoshop, InDesign, Illustrator, Flash, etc. Acrobat is a side business, if anything.

Re:Easy but far too simple solution (1)

toleraen (831634) | more than 4 years ago | (#30657938)

Maybe I'm crazy but I'd bet there's a lot more corporate use of Acrobat Pro than just as a "side business".

Re:Easy but far too simple solution (3, Funny)

clone53421 (1310749) | more than 4 years ago | (#30657560)

Dreamweaver?

Re:Easy but far too simple solution (5, Insightful)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#30656960)

Your "solution" is only a solution if your business isn't peddling PDF software(not to mention the really expensive backendware that you have to buy from Adobe if you want to "enable your enterprise PDF form workflow" or whatever).

There are well behaved, and standardized, subsets of PDF that are just fine. They know their place, they are a perfectly competent and pretty well supported way of slinging around documents that have to look a certain way. Outside of that, though, is the nightmare realm where Adobe just keeps cramming use cases into PDF, because PDF is what they own. Javascript, embedded Flash video, it's just a matter of time before they announce an alliance with VMware, to "Enable users to deploy entire Rich Enterprise Solution Stacks" just by emailing PDFs full of x86 virtual machines, complete with embedded video documentation, to one another...

Re:Easy but far too simple solution (1, Insightful)

Anonymous Coward | more than 4 years ago | (#30657474)

Javascript, embedded Flash video, it's just a matter of time before they announce an alliance with VMware, to "Enable users to deploy entire Rich Enterprise Solution Stacks" just by emailing PDFs full of x86 virtual machines, complete with embedded video documentation, to one another...

where is the mod for +1 "Run Screaming Into The Night"?

Re:Easy but far too simple solution (2, Funny)

ristonj (1195983) | more than 4 years ago | (#30657570)

Shhhh....you'll give them ideas!

Re:Easy but far too simple solution (0)

Anonymous Coward | more than 4 years ago | (#30657648)

My Eyes! It Burns! It Burns!

Re:Easy but far too simple solution (1)

interval1066 (668936) | more than 4 years ago | (#30657682)

"PDFs full of x86 virtual machines, complete with embedded video documentation, to one another..."

Can you imagine the chaos that would bring? "Here's your presentation on the XYZ effort", let'er rip and a Pandora's box of digital mayhem starts to eat away at your corp's lan...

Re:Easy but far too simple solution (1)

noidentity (188756) | more than 4 years ago | (#30657020)

Why not let PDFs only display documents, and rely on web forms for submitting information? No? Too simple?

I propose we make a new read-only document format that's portable between machines. We could call it PRODF. We could also require that any format updates are backwards compatible with previous readers, so that the user doesn't have to update his &%(*% reader every month just to be able to read a document (hence the name "portable").

Re:Easy but far too simple solution (1)

reub2000 (705806) | more than 4 years ago | (#30657366)

No. We need forwards compatibility to ensure that documents created today can be read by readers in the future.

Re:Easy but far too simple solution (0)

Anonymous Coward | more than 4 years ago | (#30657862)

I want sideways-compatibility. My business use cases require them to facilitate horizontal asset transmogrification. My consultant said so.

JavaScript: the biggest computing fuckup ever. (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30657186)

Your proposal doesn't change the fact that JavaScript may still be involved in some way, even when using web forms.

JavaScript is indisputably the biggest fuckup to ever hit computing. Yes, it's even worse than Microsoft Windows. At least you can choose to avoid Windows, and software from Microsoft. That's just not possible with JavaScript.

JavaScript has embedded its tentacles into every major web browser, and most minor ones, too. Then just to fuck everyone over one more time, it's the basis for ActionScript, used in Flash. And in this case, it has even lodged itself in a goddamn PDF viewer!

JavaScript needs to go. It's a pathetic excuse for a scripting language, let alone a full programming language (like many stupid fools seem to use it as today).

JavaScript has brought performance problems, security holes and shitty programming wherever it has been used. It's a disease that has severely infected the current generation of software developers and software.

Re:JavaScript: the biggest computing fuckup ever. (0)

Anonymous Coward | more than 4 years ago | (#30657390)

Obvious troll is obvious.

JavaScript isn't to blame; the protocols and formats implementing JavaScript, such as Adobe's rendition of PDF, are. You can avoid JavaScript if you want: Use Opera, Firefox or another mature, well-intending web browser that allows you to use whitelist policy against JavaScript online. Use a PDF-reader that isn't Adobe's. Etc. etc.

You're and idiot and don't know what you are... (0, Troll)

gbutler69 (910166) | more than 4 years ago | (#30657672)

...talking about.

It's a pathetic excuse for a scripting language, let alone a full programming language

This proves it. If you don't understand that Javascript, you'd think that. But, you probably don't think LISP/SCHEME are REAL programming languages either. You probably don't even know WTF "Lambda Calculus" is? Shut the Fuck Up!

Re:Easy but far too simple solution (2, Insightful)

nametaken (610866) | more than 4 years ago | (#30657320)

Correct. This whole problem stems from this awful idea that PDF should be more than what made it popular. Its purpose is to make sure a document looks the same for everyone, regardless of a person's installed fonts or default margins, etc.

In a struggle to monetize the PDF format and maintain relevance Adobe keeps adding all kinds of bullshit feature bloat that doesn't catch on, BECAUSE WE DON'T WANT IT. Take form submission. How many PDF forms have you seen in the wild? I haven't seen more than two in the last ten years. Adobe isn't about to give this up though. They've committed to these BS features, they're not going away now regardless of how irrelevant or dangerous they are.

Look into a good alternative reader. Adobe is not a customer-centric company. It never has been.

Huh? (1)

gbutler69 (910166) | more than 4 years ago | (#30657756)

Adobe is not a customer-centric company.

Unless you are buying software from the (i.e. Adobe Development Tools and Document Management Solutions) YOU AIN'T THEIR CUSTOMER. People who just use Adobe Reader and Flash Viewer ARE NOT Adobe's customers. The people who produce the content, using Adobe tools and work-flow management stuff are their customers.

I am not Adobe's Customer.

Re:Easy but far too simple solution (1)

GIL_Dude (850471) | more than 4 years ago | (#30657760)

I've seen lots of them. One per month at work for SOX compliance (unfortunately the crazy system our company bought uses them). One more just the other day from my kids school district for a form to apply to be in the school's "pathways" program (engineering program in this case). This form didn't even work right. The form field checking worked, but the submit button failed to do its email thing - so we had to print it and carry it in because you can't SAVE it. Another to apply to be a coach for the soccer league (background check info). All of these things use the forms feature with ActionScript/JavaScript. Just because one person isn't required to use them doesn't mean all of us don't have to use them.

BTW, I agree that adobe reader is terrible software - but I can't get the school district, the soccer league, or my work to switch...

Re:Easy but far too simple solution (1)

Ephemeriis (315124) | more than 4 years ago | (#30657574)

Why not let PDFs only display documents, and rely on web forms for submitting information? No? Too simple?

Yeah, that was my thought as well.

The reason I use a PDF is because I want somebody on the other end to see my document the way it is supposed to look. I don't want to worry about what font they have installed or which version of Word they're running or whatever. It's the digital equivalent of a printed page.

I like that you can specify editable areas on a PDF... So that you can send somebody a form, that they can type on, and then print out or send back to you. That's nice.

But that's about the extent of it.

If I really need to collect live data from a form, I'm not going to use a PDF - I'll just use a web page.

Simple solution (3, Interesting)

loganljb (1424009) | more than 4 years ago | (#30656794)

Well, gee -- how about creating the equivalent of noscript for Adobe, then? That way, the user can decide for themselves if they want to run scripts in what they THOUGHT was just a formatted text document.

Re:Simple solution (1)

Reason58 (775044) | more than 4 years ago | (#30656886)

Well, gee -- how about creating the equivalent of noscript for Adobe, then? That way, the user can decide for themselves if they want to run scripts in what they THOUGHT was just a formatted text document.

I don't have it installed on this machine, but I am pretty sure there is a setting to disable script support in all versions of Acrobat.

Re:Simple solution (1)

loganljb (1424009) | more than 4 years ago | (#30656926)

Yes, but it should be the default, with an option to ENABLE script support for specific documents, not a system-wide setting. Like noscript lets you mark specific pages as trusted.

Re:Simple solution (1)

natehoy (1608657) | more than 4 years ago | (#30657036)

Agreed. The current JavaScript setting is "on" or "off", with no "Allow it, but ask me each time a document wants to use it".

Since I've never received a document with JavaScript, and I'm not seeing that trend change anytime soon, I turn it "off". Sadly, the default setting is "on", so I probably represent some single-digit percentage at best of Adobe users.

And, yes, I could use an alternative, but at work they load Adobe Reader on the default install. I pretty much have to use the tool my employer wants me to, so I take the steps necessary to make it as secure as possible.

At home, I run Linux with an open-sourced reader.

Re:Simple solution (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#30656894)

Well, gee -- how about creating the equivalent of noscript for Adobe, then?

Noscript was (I don't care if it is now, once is enough) malware and adware. I don't want that again.

Re:Simple solution (2, Insightful)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#30656994)

You can turn off javascript in Acrobat Reader.

Every time you load a document with Javascript, you'll be warned that it may not display properly, and asked if you'd like to turn javascript back on.

If you agree, the "on" setting sticks for subsequent documents, until you go into the menu and turn it off again.

Can't you just taste adobe's eagerness to have you turn off javascript?

Re:Simple solution (1)

Dragee (881700) | more than 4 years ago | (#30657976)

Exactly. I'm not saying Adobe should strip out javascript, just fucking disable it by default. And *if* I need it, *if* I turn it on, at least give me the option to only leave it on for that session. There aren't enough adjectives for my opinion of what Adobe has done to Acrobat Reader.

How difficult is it to remove Adobe Reader? (1)

plover (150551) | more than 4 years ago | (#30656836)

Seriously, how damaged would the world be without form-based PDFs? I removed almost every plug-in from my copy of Adobe Reader. I don't need their "rights management" or their "braille reader" or their "web submission plugin" or any of that other cruft.

And somehow my life is not incomplete as a result.

Re:How difficult is it to remove Adobe Reader? (1)

PIBM (588930) | more than 4 years ago | (#30657050)

Just remove the pdf viewer altogether...

The web is so much nicer without those ugly, slow loading, web browser crashing pdf junk...

Re:How difficult is it to remove Adobe Reader? (0)

Anonymous Coward | more than 4 years ago | (#30657126)

Adobe Reader is not nearly as bad if you neuter all the plugins (physically remove them from the plugins folder). The only plugin I have enabled is the one required for search functionality. The newest version is still fugly, but functionally it is just fine.

Re:How difficult is it to remove Adobe Reader? (1)

plover (150551) | more than 4 years ago | (#30657242)

Well, I am stuck because some stuff that I actually do want is provided only in PDF format. But the stuff I need is "information", not "function". I don't need yet another piece of software acting as a browser, or a mail client, or a media player, or a download accelerator, or a Swiss-army-knife.

It's one thing to make a spec sheet available in PDF format. But don't expect me to order spare parts from it -- it's all I can do to make one browser trustworthy, let alone every other damn application on the box.

Tea and pramwiches (5, Insightful)

daeley (126313) | more than 4 years ago | (#30656858)

"Anytime you're working with a baby pram where you're, say, also carrying diapers, our chainsaw is used to do things like verify that the Pampers fit on that little shelf underneath. If you're carrying some groceries as well, the chainsaw verifies that you don't try to fit too much on there. When you push the pram, the chainsaw makes sure you push it to the right place. All of this stuff has the chainsaw behind the scenes making it work and it's difficult to remove without causing problems," Arkin explained.

Re:Tea and pramwiches (0)

Frosty Piss (770223) | more than 4 years ago | (#30657184)

Not funnt, not relevent, basically worthless post. I'm sure you'll be modded "interesting" or "funny". Sad, very sad...

Re:Tea and pramwiches (1, Informative)

Anonymous Coward | more than 4 years ago | (#30657336)

Missed the analogy, hmm?

Chainsaw == Javascript
Pram == Document

Get it? He's saying that Javascript is the wrong tool for the job.

Asshole.

Re:Tea and pramwiches (1)

ben0207 (845105) | more than 4 years ago | (#30657352)

Ha! That's where you're wrong! He got modded Insightful!

In your face!

Re:Tea and pramwiches (1)

Nerdfest (867930) | more than 4 years ago | (#30657380)

I think it's quite insightful. Check the number of exploits over the last couple of years. I'm at the point where I keep Adobe software on systems to an absolute minimum, as these days they seem to be the number one target for exploits. Reducing their attack surface (and improving their software quality) would go a long way to reducing the number of exploits.

I thought it was funny too, but maybe that's just me.

PDF forms? DIE! (1)

FrostedWheat (172733) | more than 4 years ago | (#30656862)

The only thing I learned when we used PDF forms a few years ago was ... don't do it. Just no. Really, don't .

Re:PDF forms? DIE! (3, Interesting)

Qzukk (229616) | more than 4 years ago | (#30657068)

The only thing I learned when we used PDF forms a few years ago was ... don't do it. Just no. Really, don't.

PDF forms with javascript for web submission? I agree.

In reality though, a lot of crap (especially government crap) still has to be done on paper, and until HTML+CSS gets to the point where I can reliably reproduce a form on paper, PDF is the best option, ahead of Word documents with 50,000 underscores that wordwrap when someone tries to write in them.

That, or find someone with a typewriter.

Re:PDF forms? DIE! (1)

Mornedhel (961946) | more than 4 years ago | (#30657188)

Or, y'know, a PDF could be generated by the server when the form is submitted, if a paper trail is really important.

Re:PDF forms? DIE! (2, Informative)

Volante3192 (953645) | more than 4 years ago | (#30657506)

He's referring to submitting a form by hand or by snail mail, not electronically.

If you're going to the DMV, you're giving them a piece of paper. That is where PDF forms excel. You get the benefits of PDF (exact document reproduction) with the additional benefit of legible typed in data.

Re:PDF forms? DIE! (1)

clone53421 (1310749) | more than 4 years ago | (#30657830)

I maintained such a system for a while.

People were supposed to fill in the HTML form, submit it, print the PDF from the next page, sign it, and mail it.

The problem?

Some people printed the HTML form, filled it in by hand, signed it, and mailed it.
Some people filled in the HTML form, printed it, signed it, and mailed it.

Not a lot – just enough to be irritating.

(This despite a notice on the top of the HTML form telling you not to print it, and despite blank versions of the PDF form being available for people who needed to print a blank form.)

I finally added an @media print section to put the legal statement and a signature blank at the end of the HTML form if they printed it so their signature would actually mean something. (Not visible in the screen copy, obviously, because it still said not to print it and I didn’t want to suggest that it was okay to do so.)

Re:PDF forms? DIE! (1)

clone53421 (1310749) | more than 4 years ago | (#30657642)

Word documents with 50,000 underscores that wordwrap when someone tries to write in them

The correct way to create those is with an underlined tab character.

Simple answer (3, Insightful)

just_another_sean (919159) | more than 4 years ago | (#30656874)

White listed docs/publishers are the only ones allowed to run JavaScript. White listing
should be as easy as pushing a "Trust this document" or "Trust this publisher" button.

Will it/can it be abused? Sure, but it's better then running script by default without
user consent.

What Wasn't Said (0)

Anonymous Coward | more than 4 years ago | (#30656878)

Translation: "We don't want to expend the time, effort, resources and money- especially the money- it would take to replace quick and dirty Javascript code with something more secure and robust."

PDF with a form? (1)

ickleberry (864871) | more than 4 years ago | (#30656888)

Anytime you're working with a PDF where you're entering information, JavaScript is used to do things like verify that the date you entered is the right format

I really can't remember the last time I saw a PDF that had a form in it that you could submit. Was it 2001? possibly 2003 at the very latest. The idea never caught on, and why would it? you get some minimal HTTP POST support in a proprietary format. To me it would seem more important that you have an up-to-date version of the form you are submitting, rather than having the form's formatting look *exactly* right without loss in formatting which is the whole point of PDF.

JavaShit, forms, DRM in PDF files should all be removed - all they do is make the reading software more bloated

Re:PDF with a form? (1)

Volante3192 (953645) | more than 4 years ago | (#30657108)

I had to deal with a PDF form recently, from the DMV. Basically you filled it out and then printed it out.

That's the only reason I could see for using a PDF form.
(I'd rather type in than write in details...it'd take thrice as long to write legibly than it would to type it and print it.)

Re:PDF with a form? (1)

plover (150551) | more than 4 years ago | (#30657318)

I had to deal with a PDF form recently, from the DMV. Basically you filled it out and then printed it out.

Screw the DMV. If they're going to make me wait in line for an hour, they can spend an extra 10 minutes trying to figure out my hand writing.

No, not a good idea at all (2, Insightful)

Nomen Publicus (1150725) | more than 4 years ago | (#30656896)

Why does a product called "Reader" have to process user input?

i discovered a new concept today (2, Funny)

circletimessquare (444983) | more than 4 years ago | (#30656928)

the bloatware partisan

Maybe it's just me (1)

mandark1967 (630856) | more than 4 years ago | (#30656958)

I read it as saying, "It's cheaper to patch vulnerabilities than it is to re-write the code properly in the first place"

Re:Maybe it's just me (1)

jellomizer (103300) | more than 4 years ago | (#30657368)

You make it sound like a bad thing...

Trying to make an app perfect can take an exponentially more amount of time to create a product. So in the mean time you are trying to get perfection there is time that people cannot take value from your product.

Like Duke Nukem Forever. They tried to make it the perfect game at a cost that they couldn't complete so no-one could pay the game nor could they get enjoyment from it.

Sure Slashdot geeks like to bust on PDF as it isn't their choice of a document format, for some good reasons and some bad ones. However PDF is a heck of a lot better then using Microsoft Doc files. But there is a value in a document format that displays equally well on different systems. So if Adobe were to take an extra 10/15 years to make it perfect they will be out competed, and no one will be able to use the software. Vs. an imperfect program that will give people value even with the glitches.

Now before the crazy rants that will follow the post about how good code can save the company money in the future. There is a balance between the Value of releasing early vs the Value of having a good product which needs to be carefully considered writting bad code just to get it done fast won't work either... However in real life if you want to make money for a living you need to get it done and working good enough for people to get value from your product.

Re:Maybe it's just me (2, Insightful)

mandark1967 (630856) | more than 4 years ago | (#30657700)

I think you read a little too much into my post. The application is called Adobe Acrobat Reader, but the quotes from the Adobe rep talk about all sorts of crap that 90% of the users at home do not need, or likely even want. As has been suggested in another post above, they need to make Acrobat Reader do one thing. Read PDFs.

I, personally, do not need the capability of filling out forms nor do I need to submit and route forms. I just need to read a motherboard manual to see some jumper pin-outs and the like. In order to accomplish these types of tasks, I use Sumatra PDF reader.

Removing that java scripting functionality from Reader and putting it into something else, like Adobe's Forms Manager makes sense from a security standpoint as well as a marketing standpoint. If they want to charge a premium for the capability of filling out forms and the like, let them. There are companies/people willing to pay extra for that set of features. It also allows them to make Reader more secure by removing the major attack vector from Reader that is exploited today, seemingly by any script kiddie.

CS4 Scripting too (5, Informative)

0100010001010011 (652467) | more than 4 years ago | (#30656962)

I didn't know this until recently, but you script most of Adobe's CS products (Photoshop, etc) with JavaScript.

It's cross platform. The same scripts work on my Mac as they do on a Windows machine.

I already know it, syntax isn't something foreign and there is a ton websites out there for JavaScript support.

It makes stuff like making panoramas and HDR panoramas awesome.

Why not html forms? (1)

jack2000 (1178961) | more than 4 years ago | (#30656964)

Can anyone tell me WHY people want to fill forms inside PDFs? What am i missing here? We already have the technology to fill forms, what do adobe want to achieve with this? To me it smells like another CEO type of decision and desire for everything to be centralized.

Re:Why not html forms? (2, Insightful)

jbolden (176878) | more than 4 years ago | (#30657134)

PDF is a ubiquitous format for which allows for paper like documents which requires only free software. What other format comes close.

HTML = not remotely paper like
forms -> typeset: not ubiquitous

etc...

Re:Why not html forms? (1)

jack2000 (1178961) | more than 4 years ago | (#30657398)

you are forgetting that well structured and styled html is just as effective as paper print. Besides you have doc files for printing forms, you can even use an open precessing software if you'd like.

Re:Why not html forms? (3, Insightful)

Volante3192 (953645) | more than 4 years ago | (#30657638)

Except HTML is dependent on margin size, available fonts, interpretation by the browser, too many tiny variables that could cause problems. Most code monkeys can't even check if their stuff works in the browser they use. Binary files like doc can be interpreted wrong if opened in a different program or even version of the same program.

The one thing PDF does well, extremely well, is keep the document the same across platforms. (Better than other options at least.) Use the right tool for the right job: if you need a form to look the same regardless of where it ends up, your best bet is a PDF.

Re:Why not html forms? (1)

LOLLinux (1682094) | more than 4 years ago | (#30657688)

Except you can't guarantee that your well-structured and styled HTML or doc files will look exactly the same between all possible systems. With PDF you can.

Re:Why not html forms? (1)

Volante3192 (953645) | more than 4 years ago | (#30657170)

The one case I can see for using a PDF form is to have a hard copy print out with the fields filled properly. I've used one for the DMV like that.

Anything you're submitting electronically, no.

Re:Why not html forms? (1)

diskofish (1037768) | more than 4 years ago | (#30657290)

Sometimes small organizations don't have the infrastructure to put every single form online, it takes a developer and costs money. I recently had to fill out a bunch of forms, and there was no way to do it online. For these cases, it's a godsend to be able to type right into the PDF, save it, and print it out.

Re:Why not html forms? (1)

Volante3192 (953645) | more than 4 years ago | (#30657388)

I recently had to fill out a bunch of forms, and there was no way to do it online. For these cases, it's a godsend to be able to type right into the PDF, save it, and print it out.

That's the kicker. You're not submitting a PDF form, you're printing it out and making it simply a legible paper form.

If they have the infrastructure to accept PDF-submitted forms, they have the infrastructure to make and accept HTML-submitted forms.

Re:Why not html forms? (1)

castironpigeon (1056188) | more than 4 years ago | (#30657350)

Adobe has made PDFs more accessible while WC3 has made HTML and other web programming less accessible. As a result web programmers get to keep their jobs, which I'm guessing was the point of obfuscating web programming to the point that most non-geeks don't want to deal with it, and non-geeks that need to make forms will go with an Adobe product because it "just works."

Re:Why not html forms? (1)

geminidomino (614729) | more than 4 years ago | (#30657546)

Adobe has made PDFs more accessible while WC3 has made HTML and other web programming less accessible. As a result web programmers get to keep their jobs, which I'm guessing was the point of obfuscating web programming to the point that most non-geeks don't want to deal with it, and non-geeks that need to make forms will go with an Adobe product because it "just works."

This may be harsh, but it needs to be said: by referring to HTML as "web programming", it's pretty clear that you're not really in a position to be explaining the logic of the decision.

Huh? (1)

jack2000 (1178961) | more than 4 years ago | (#30657598)

Excuse me HOW has WC3 made html so hard to understand?
All things considered it's made it more legible! Consolidating style and content into different parts of the document makes things Very easy.

Re:Why not html forms? (1)

TheRaven64 (641858) | more than 4 years ago | (#30657394)

Offline use. You can email someone a PDF form or put it on a memory stick, they can then fill it in (or out if they are American) and then use the JavaScript to validate their entries before sending them back. They don't need Internet access while they are entering the data and they can save a local copy easily. It's marginally useful, but in 99% of cases an HTML form would be better.

Re:Why not html forms? (1)

Jaysyn (203771) | more than 4 years ago | (#30657742)

I'll bite. The "blanks" on most of the paper forms we have to turn into various city & state governments for permitting & such are so small that if you are successful in filling them out, they probably won't be legible. It's much easier for me to scan them to a PDF, & make some "blanks" that you can fill in. Took me about 30 minutes total the last time I had to make one. It would take me a lot longer to do this in HTML & they still wouldn't look like the forms that the DOT expects us to be using.

Re:Why not html forms? (1)

VGR (467274) | more than 4 years ago | (#30657962)

I'm guessing people who choose to create PDF forms are WYSIWYG-obsessed, and Adobe is catering to them. Remember all those web pages in the 90s that contained 1x1 blank GIFs for spacing? The people who made those things are still around, somewhere. Perhaps they are Adobe's target market.

I've actually seen an entire web page replaced with an Acrobat document containing hyperlinks.

bummer dude (1)

varmint jerky (810306) | more than 4 years ago | (#30657000)

Oh no, it's difficult to do the right thing! In many organizations, they would respond by saying "You're fired!" Good thing this guy works for Adobe.

Stupidity repeats itself (0)

Anonymous Coward | more than 4 years ago | (#30657052)

Funny, I always turn off Javascript in every new PDF viewer installation and not having it never causes me any problems. This guy is making excuses for something that should never have existed in the first place. Those who don't learn the history of the MS Office macro virus debacle of the 1990s are doomed to repeat it.

Security Not the *Only* Consideration (1)

Alphanos (596595) | more than 4 years ago | (#30657072)

Amazing that in the face of one known problem, someone knowledgeable about the issues can remain aware of another problem. This silly guy would be much better off to ignore all other issues when examining a problem, regardless of whether proposed solutions would have other undesired consequences.

Re:Security Not the *Only* Consideration (2, Insightful)

plover (150551) | more than 4 years ago | (#30657466)

It's obvious from this discussion that his *only* consideration is shareholder value.

His job is to make sure that PDFs remain relevant. Adding plugins, or anything that makes people depend on PDFs, is their primary goal. Turning off features (such as disabling JavaScript) would reduce that primary goal.

Security is valued only as long as it keeps people from complaining. He'll talk about security for hours, but in the end he has to justify whatever decisions the board told him to justify. He'd be much more effective as a security chief if he were truly autonomous, as a CxO is supposed to be.

Fine, but... (1)

MobyDisk (75490) | more than 4 years ago | (#30657146)

His point is sound, but it dodges the real issue:

1) Most of the time people aren't doing forms submissions. It's somewhat of an obsolete concept. We use HTML for that. We use PDF when we want to print something. (Which we do a lot less often than we used to)

2) You can have Javascript that can do form validations without giving it commands like "open this file, write to it, then execute it" Adobe's Javascript security is stuck in 1998, back in the days of ActiveX controls that could trivially to break out of the sandbox.

Re:Fine, but... (1)

clone53421 (1310749) | more than 4 years ago | (#30657472)

2) You can have Javascript that can do form validations without giving it commands like "open this file, write to it, then execute it"

You think you can have it without that... and then somebody designs a buffer overflow that usurps your security level and does exactly that.

Envy (1)

psbrogna (611644) | more than 4 years ago | (#30657176)

I wish I was in a position where I didn't have to fix my strategic mistakes. It sure would be a nice a nice world if we didn't have to make mistakes and could call anything difficult a "non-starter."

Keep your JS but... (1)

gad_zuki! (70830) | more than 4 years ago | (#30657194)

Dont run it automatically. Have the default be JS off and a nice scary warning box about JS and how you should only enable it if you are certain this is a safe PDF. Sure, its not a perfect solution but its better than just having it on by default and running vulnerabilities at double-click.

Not to mention, when I shut it off under Preferences - KEEP IT OFF. If its off in preferences, it helpfully reminds the user than its off and offers to re-enable it via the prompt. What the hell is Adobe thinking?

While I'm at it how about updates to the reader that arent 40-150 megabytes big or an updater that actually works. Right now, sane people should be considering Reader are very serious security vulnerability and migrating off the platform. Adobe has shown nothing but contempt for even basic security.

PDF has forms before Javascript (1)

wiredlogic (135348) | more than 4 years ago | (#30657200)

Funny. The PDF format had forms before Javascript was tacked on. If they needed something to do validation they should have looked in house and used a language they already had like, oh I dunno... Postscript.

Re:PDF has forms before Javascript (0)

Anonymous Coward | more than 4 years ago | (#30657878)

You're kidding, right? Postscript was intended to be machine-generated, not hand-written, so it is much harder to code in. Not only that, but it doesn't have any meaningful facilities for doing the things you would want to do in JS, like form validation or submission.

Of course the reason they chose JS was because they already had a JS engine written and just plug it into all of their products whenever they need some scripting ability. In other words, it was easy.

dom

Market grab turned ugly (1)

bl8n8r (649187) | more than 4 years ago | (#30657246)

What's happened is Adobe has tried to retrofit Acrobat with tubes. They did it with much haste so as to get a foothold in the 'cloud' computing craze. What we now have is a hastily coded bloated application that's somewhere between IE5 and MS Word 95 in terms of security. Adobe needs to start over, they f#cked up and need to fix it.

B-A-L-O-N-E-Y (0, Flamebait)

Stumbles (602007) | more than 4 years ago | (#30657260)

Yep Java is such a powerful language... it is the only one that can verify the correct number of digits for a phone number, the right date, etc. So there all you purist language tards; things like C++, C, perl, python, etal are utter crap compared to the almighty Java and its scripts. Who cares if there are a few security issues introduced, Adobe could not give a shit about it.

Are you drunk? (1)

spun (1352) | more than 4 years ago | (#30657396)

Yep Java is such a powerful language... it is the only one that can verify the correct number of digits for a phone number, the right date, etc. So there all you purist language tards; things like C++, C, perl, python, etal are utter crap compared to the almighty Java and its scripts. Who cares if there are a few security issues introduced, Adobe could not give a shit about it.

No, seriously, are you? Because I don't even know where to start here, I mean, come on! Are you trolling? This whole post is meaningless jibber-jabber. Java isn't java-script. In fact, they aren't even related. ANY general purpose language included in a document mark-up language can introduce vulnerabilities. This isn't about one language versus another. The question is, why does a document format need scripting at all? Sheesh.

Re:B-A-L-O-N-E-Y (1)

Mongoose Disciple (722373) | more than 4 years ago | (#30657406)

... you do know that Java and JavaScript are completely different and essentially unrelated things, right?

Re:B-A-L-O-N-E-Y (0)

Anonymous Coward | more than 4 years ago | (#30657522)

wha? You do realise that Java and JavaScript are two very distinctly different languages, right?

Hello? ...off topic rage post...

Stop right there. (0, Flamebait)

geminidomino (614729) | more than 4 years ago | (#30657404)

Anytime you're working with a PDF where you're entering information, you've already failed

Fixed that for you, dipshit.

You can't defend a stupid idea by saying that without it, another stupid idea would be impossible.

Well, I guess you CAN, since this knob just DID. He just didn't do a very good job of it.

Except... (1)

oglueck (235089) | more than 4 years ago | (#30657420)

...that nobody uses these "I am an electronic form" features anyway. All we want is view and print documents. But then, PostScript did exactly that. Oh wait, PDF is based on PostScript. I never understood why it had to be Adobe and PDF that the world uses today. It could have been (a nice version of) Ghostview and PostScript. Hm, but then nobody could have sold PDF-Creation Add-Ons to MS Word, because you could have used a PS printer driver.

PDF Javascript vs WWW Javascript (2, Insightful)

gehrehmee (16338) | more than 4 years ago | (#30657434)

We have Javascript in web browsers, and it's rare to see vulnerabilities this rare.

What's the difference? Is Adobe just not sandboxing Javascript code properly? I've never really used Adobe's products for this... but what's to stop them from just using an established javascript implementation like that used in Firefox or Webkit?

Why JavaScript? (1)

Kleiba (929721) | more than 4 years ago | (#30657530)

...or any other programming language for that matter? If the functionality is indeed only needed for checking that form input adheres to a specific format, should not a regular expression mechanism be enough in 99% of the cases? As in: if you design a form, you'll get the ability to specify a regex for each field and the PDF renderer will check new input against each field's regex. Less powerful, but also less likely to be exploitable, I would assume.

Re:Why JavaScript? (1)

Locke2005 (849178) | more than 4 years ago | (#30657782)

Regex's might work for verifying individual fields in isolation, but I believe verifying that multiple fields have information consistent with each other requires scripting. (How do you write a regex to verify that the input string converts to a floating point number x such that 1.5 x 2.5?) Shouldn't widespread adoption of HTML5 render this whole argument moot anyway?

Smells like.. (1)

SuperCharlie (1068072) | more than 4 years ago | (#30657550)

It smells like they painted themselves into a backward compatibility nightmare using a lightweight solution to what now needs to be a heavyweight security application because of its widespread usage. Anyone standing behind javascript as a security boundary on a compiled app is pretty much insane imho..

API? (1)

eigenstates (1364441) | more than 4 years ago | (#30657562)

Why not just invent a new language exactly like javascript for Reader to use and then only expose the public API, which is similar to javascript. Make sure that main code base is securely sealed though so that when developer is trying to debug their script for some mystical, incomplete error message from the base classes it will be impossible. Call it something like actionPDFscript.

I am sure it will be a big hit.

Oh, I do get it. (1)

rickb928 (945187) | more than 4 years ago | (#30657708)

JavaScript is a feature that Adobe believes is useful enough to tolerate the security compromises.

Or to rephrase it, Adobe Reader is so good, security doesn't matter as much as features.

Yup. That's how they see it.

declarative standards-based form validation (2, Informative)

leighklotz (192300) | more than 4 years ago | (#30657940)

Adobe should move away from JavaScript and move to declarative form definition and validation, which carries no risk of code attacks from errant JavaScript. In fact, there is a standard for validating forms declaratively, called XForms. It lets you write validation expressions for saying when data is valid, required, readonly, or calculated from other data (i.e. totals), and also lets you assign data types using the widely-deployed XSD type names (integer, URL, string, regexp string, etc).

XForms is modular enough that it's been incorporated into ODF, and there's no reason other that it can't be used in PDF to define and validate forms, other than that Adobe has a vested interest in maintaining its proprietary technology forms instead. There are a number of folks who would be quite ready to help Adobe incorporate XForms into PDF.

There are in-browser JavaScript implementations of XForms (here [agencexml.com] , here [google.com] , and here [formfaces.com] ), server side implementations a la GWT (here [orbeon.com] and here [sourceforge.net] ), and mobile implementations (here [picoforms.com] ).

I've been working with XForms for many years, and find it an excellent solution for deploying rich internet applications; we've switched implementations a few times, and have had to do only minor changes to our applications, so using a standard preserves our investment in stuff already written.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>