Adobe Security Chief Defends JavaScript Support

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.'"

Comments

Easy but far too simple solution

[richdun]

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

[sopssa]

Well you can always use alternate PDF readers, like Foxit Reader (and no bloat either)

Re:Easy but far too simple solution

[kestasjk]

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

[fuzzyfuzzyfungus]

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

[Anonymous Coward]

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

[noidentity]

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

[pmontra]

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

[Anonymous Coward]

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

[morgan_greywolf]

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

[nametaken]

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.

Re:Easy but far too simple solution

[reub2000]

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

[morgan_greywolf]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[clone53421]

Dreamweaver?

Re:Easy but far too simple solution

[ristonj]

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

Re:Easy but far too simple solution

[Ephemeriis]

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.

Re:Easy but far too simple solution

[Anonymous Coward]

My Eyes! It Burns! It Burns!

Re:Easy but far too simple solution

[interval1066]

"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

[GIL_Dude]

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

[Anonymous Coward]

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

Re:Easy but far too simple solution

[toleraen]

L O L

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

[toleraen]

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

[nitroscen]

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

[Anonymous Coward]

"Well you can always use alternate PDF readers"

ok - question.
Is there an alternate reader (for windows and/or linux) that is
1. F/OSS?
2. supports filling out/saving forms and commenting?

I've been reluctant to try Foxit, because they seem to be using their software to push the use of TrialPay (which smells like a scam). Maybe they're legitimate, but if they knowingly associate with a scam artist, it doesn't add to my confidence.

Re:Easy but far too simple solution

[BitZtream]

Or, just do away with PDF in favor of a portable document format, like HTML which is supported on far more platforms than PDF, and far better than PDF in every conceivable way.

As for PDF forms, has anyone ever seen them used properly. By that I mean made, actually will allow you to input data on them and allow it to be submitted to where it needs to go or printed or something useful?

I've never seen a PDF form that worked.

Re:Easy but far too simple solution

[Grishnakh]

IRS forms also have fillable fields.

Re:Easy but far too simple solution

[morgan_greywolf]

Many enterprises use alternative tools for generating PDFs such as PDF Creator to minimize the number of Acrobat Pro licenses required -- or even to eliminate the cost associated with the tool at all.

Re:Easy but far too simple solution

[Rayonic]

PDF forms are used when the form needs to be printed in a very specific format, or at least needs to exactly emulate their paper counterparts. e.g., tax forms, standardized contracts, employee waivers, etc. Even with stylesheets set up properly, printing out HTML is always an adventure.

So if an employee needs to, say, update their tax information, they can fill out the form online and submit it (securely) back to the employer. Then the employer can print it out themselves, file it, or whatever. Beats mailing around paper or having someone come into the main office.

Re:Easy but far too simple solution

[Monkeedude1212]

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

You are faced with the problem of having to host a file which requires a server and an afternoon setting that all up. Then you have to provide a link to someone, which means they have to open it in a web browser. Which means you'll have to let that server through the firewall/dns, since you've got it all blacklisted to keep employees in line.

Instead of being able to open it by whatever email client you want, as an attachment, that works across all platforms.

I don't like them any more than the next guy, but they fill a spot that webforms haven't quite done yet.

Re:Easy but far too simple solution

[BitZtream]

Much like Linux exploits, the installed base is so small no one notices when the product gets exploited.

Its no better, its just different exploits that happen to fewer total people. The percentage of installed users effected is likely identical, assuming the same ratio of exploits directed at Foxit versus Adobe Reader.

You gain security through obscurity. No one cares about exploiting foxit really, the install base is too small compared to adobe reader, so the bad guys target the one that they get the most effect on. Spend an hour exploiting foxit and get to exploit 10 machines. Spend a hour exploiting adobe and exploit 1 million machines. Only an idiot would bother writing Foxit exploits. The result, while code quality could be identical, Foxit is still SAFER to use at the moment.

Re:Easy but far too simple solution

[FooAtWFU]

In the wild? Tax form PDFs. That's about it.

Re:Easy but far too simple solution

[Bill, Shooter of Bul]

Yeah. That's the use case for it allright. Large enough company to not mind paying for all the adobe software required to send a one off pdf form.

Re:Easy but far too simple solution

[uniquename72]

Wow, three idiotic posts by morgan greywolf already, and I'm not even a tenth of the way through this page!

Many enterprises use alternative tools for generating PDFs

While you're correct that Adobe makes more from other tools, to say that free software is cutting into sales of Acrobat is just plain dumb. It's akin to saying, "Microsoft doesn't make that much off of Office because many enterprises use OpenOffice." Yes, there are free alternatives, but Adobe Acrobat is the standard bearer and will remain so for the foreseeable future.

As a smart company, don't you think there's a REASON that Adobe continues product development on Acrobat? Or do you think they're just throwing away their money without any profit expectation?

Re:Easy but far too simple solution

[Anonymous Coward]

Chosen security model and the software installation procedure will naturally affect the security of a system. Only an idiot would claim otherwise based on a single data point.

Re:Easy but far too simple solution

[Quarters]

Displaying documents on screen in a device independent way isn't the original intended goal of PDF. PDF was designed to get around the issue of offset press operators not having the correct fonts, introducing errors into printed page layouts due to slight differences in page rendering of *.ps files between different seperation software packages, etc... PDF was designed to make digital prepress operations work in a device independent manner. The idea that such standardization would help for on screen rendering (especially in early 90's, pre-CSS days of HTML) came later.

Re:Easy but far too simple solution

[erroneus]

Adobe is trying really hard to be like Microsoft with their embrace and extend mentality. Just as Microsoft decided it was a good idea to put executable code and objects inside of office documents, Adobe thinks it's a good idea that "portable documents" get hindered by using any PDF software other than Adobe's. They can't pull out the functionality without crippling their [monopoly] software.

Re:Easy but far too simple solution

[Mister Whirly]

You are not crazy. I can say that the University where I work, Acrobat Pro is installed on about 20% of the machines here. And we have a staff of over 60,000 employees, so that right there is a big chunk of dough to Adobe. Granted, we get an educational discount and a license is only about $60, but the numbers add up quick with the volume of users who have it installed.

Re:Easy but far too simple solution

[Red Flayer]

Easy there, fella.

While you're correct that Adobe makes more from other tools, to say that free software is cutting into sales of Acrobat is just plain dumb.

No. That is not dumb. At my current employer, we are phasing out Acrobat (not necessarily Reader, as it is required for some of the third-party SAAS products we use). But my department alone has dropped from 6 Acrobat Pro licenses to 1 within the last year.

Sure, it's anecdotal. But I can't be the only one who has observed the same thing... and even if I were the only one, it would be *exactly* correct to say that free software alternatives to Acrobat are cutting into Acrobat sales.

As a smart company, don't you think there's a REASON that Adobe continues product development on Acrobat? Or do you think they're just throwing away their money without any profit expectation?

That's a neat gimmick you've used there, the old false dichotomy trick. Did you learn how to have intelligent discussion by watching Jerry Springer, or are you naturally an idiot? (How's that for a false dichotomy in return?)

Re:Easy but far too simple solution

[LordLimecat]

Lets see, the first one linked is for an addon, the second one is for version 2.3 which was old when that was released, and the third was for a non-current version. None appear to have been 0-day exploits (except MAYBE the last one), which Adobe Reader has had plenty of.

So given that its faster, and has a better (though not perfect) track record, id say yes, it is better.

Re:Easy but far too simple solution

[CodeBuster]

This is a problem with closed-source software in general, especially for closed-source software sold on the "fee per license or upgrade" model, and not just Adobe; although, many Adobe products are classic examples of this problem. In the Free Software world the software tends to reach a stable state in which most users are completely (or almost completely) satisfied and the rest is remanded to plugins or addons; especially for niche features that might interest only 1% of the users and not the rest. In Free Software, once a problem is "well solved" there is less incentive to add "bloatware" features in order to generate additional licensing or upgrade fees and so these features are not added, or at least they are not added to the core product, and users can choose additional features, if they want them, from the plugin or addon developers.

Re:Easy but far too simple solution

[morgan_greywolf]

But I can't be the only one who has observed the same thing...

No, you're not. I've seen the exact same behavior at several different clients over the past several years.

Re:Easy but far too simple solution

[toleraen]

Fine, go dig through them yourself. My implied point that you seem to have missed was that just by switching to a different PDF reader isn't going to solve the issue of getting exploited when people open any random PDF.

Re:Easy but far too simple solution

[morgan_greywolf]

As a smart company, don't you think there's a REASON that Adobe continues product development on Acrobat? Or do you think they're just throwing away their money without any profit expectation?

Of course they have profit expectation. But Acrobat is more of a sideline business for Adobe and it always has been. Acrobat will likely continue being a standard bearer, to be sure, but I have personally witnessed at least 5 different enterprises in the past few years cut their number of Acrobat licenses. IT management has realized that Acrobat simply isn't necessary for every employee that must generate PDFs and that there are plenty of alternative tools with either a zero cost or very cheap licensing -- there's at least one shareware tool I can think of in use at Ford Motor Co. and Xerox has a tool included with their DocuCenter workgroup/enterprise-class multifunction devices (printer/fax/scan/email) for generating PDFs as well. Tools like this are deemed "good enough" for most purposes.

Why don't you try working in an actual corporate IT environment before you go spouting off.

Re:Easy but far too simple solution

[dave562]

The TSA uses PDF forms for customs and shipping. The IRS uses them for tax forms.

Re:Easy but far too simple solution

[mad.frog]

...and that's how Emacs stayed its original, trim self.

Re:Easy but far too simple solution

[jonom]

Sorry but you are completely wrong on your PDF history.

PDF was developed as a document exchange format. It had absolutely nothing to do with prepress, that didn't come about until version 3.

http://www.adobe.com/pdf/about/history/

Re:Easy but far too simple solution

[Anonymous Coward]

PDF has been obsolete since the introduction of CSS 1.0.

Re:Easy but far too simple solution

[Anonymous Coward]

I have too. I was a document scanner for a large HUD-funded entity in Portland, OR and pretty exclusively I had a site license for Acrobat. Everyone else had Reader and PDF Creator.

Re:Easy but far too simple solution

[kestasjk]

As a smart company, don't you think there's a REASON that Adobe continues product development on Acrobat? Or do you think they're just throwing away their money without any profit expectation?

That's a neat gimmick you've used there, the old false dichotomy trick. Did you learn how to have intelligent discussion by watching Jerry Springer, or are you naturally an idiot? (How's that for a false dichotomy in return?)

I don't get it. Is there a reason they'd be developing Acrobat that doesn't involve making money that I haven't thought of? How is it a false dichotomy?

Re:Easy but far too simple solution

[the_womble]

Emacs is fairly lightweight - for an OS.

Re:Easy but far too simple solution

[the_womble]

The people creating web forms etc. are paying customers.

Those of us just reading a lot of PDFs, or generating them using free (as in unpaid, as opposed to speech) software, are not doing anything for Adobe, apart from increasing acceptance of the format, so what we want counts for little.

Re:Easy but far too simple solution

[Red Flayer]

It's a false dichotomy because of the substitution you performed on the first part of your argument...

You argued that Adobe's market share in pdf-writers is not dropping. Then you argue that if this is not the case, then they must be "throwing away their money without any profit expectation".

Adobe losing market share to free alternatives is not mutually exclusive with Adobe spending money on product development. This is what makes your dichotomy incorrect.

Simple solution

[loganljb]

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

[Reason58]

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

[loganljb]

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

[fuzzyfuzzyfungus]

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

[natehoy]

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

[maxume]

Off is actually equivalent to block but ask. There are some (probably safe) scripted pdfs here if you want to clicky-clicky:

http://www.planetpdf.com/developer/article.asp?ContentID=6828

Re:Simple solution

[Dragee]

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.

Re:Simple solution

[natehoy]

I stand corrected. Thanks very much for clarifying that.

Re:Simple solution

[thsths]

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

And I think each update also turns it on again automatically. I wonder when they will start a more frequent update cycle...

Re:Simple solution

[antic]

I recently disabled JavaScript in Acrobat.

A day before that, I visited Pirate Bay for a fraction of a second before noticing something odd (in the statusbar) and shutting my browser. I use Firefox (up to date) on XP (up to date). I didn't click to approve anything during the process of visiting PB and getting infected. There was a rootkit, malware, etc. Took me a few attempts to get rid of it and it wasted a lot of time. Obviously venturing out into the dodgier regions of the net has its risks, but the last time this happened to me, I'd visited the site of an NBA team. Each time, I believe the cause was a rogue PDF or Flash piece possibly pushed through an ad network.

Very frustrating.

Re:Simple solution

[slater86]

You could even go as far as the "I trust this author button" (IT Dept can prefill this in registry or something)
various other apps use this method where security is imperative like the noscript addon for firefox or Internet Explorer's trusted sites feature.

How difficult is it to remove Adobe Reader?

[plover]

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?

[PIBM]

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?

[Anonymous Coward]

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?

[plover]

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.

Re:How difficult is it to remove Adobe Reader?

[Grishnakh]

What are you talking about? PDF is an excellent format for printed media; I look up data sheets online all the time, which are in PDF format.

The problem is Adobe's crappy reader software. Don't use it; there's far better ones out there like Okular and Evince.

Re:How difficult is it to remove Adobe Reader?

[Skuld-Chan]

(speaking as someone who has worked quite a great deal with implementing Acrobat forms...)

End users don't need this stuff (it would be cool if IRS Tax forms were intelligent, but that would cut into the profits of a lot of tax prep companies). A lot of enterprises however use this stuff. I would agree its not the best solution in every case, but one thing it was used for frequently was a front end for some other system where they previously printed out, faxed in a paper form and then transcribed it by hand into some mainframe CRM app - well with Acrobat forms you can cut out a lot of that steps - keep the familiar forms, and keep training costs down to boot.

Livecycle forms is just a development environment like anything else (SAP/Datatel etc) - and if you are used to it - great, if not - use something else.

I do know - for end users being able to type into a form they previous wrote on was helpful because they knew where everything was and how the form worked. That certainly cut down training time, and calls to help desks.

And no - no other pdf viewer (even foxit) is compliant enough to actually work within this workflow - its either Reader 8/9 or nothing.

Re:How difficult is it to remove Adobe Reader?

[plover]

I kept Search*.api, and I also kept reflow.api in the plug_ins folder, as it seems to speed up rendering. As a bonus for getting rid of that extra crapware, Acroread seems to load up twice as fast.

Re:How difficult is it to remove Adobe Reader?

[hey!]

This is pretty much what Lotus Notes did better in the early 1990s -- and did with pretty darn good crypto built in too. It even got stuff like key revocation right.

The problem was you needed at least a few people who had above room temperature IQ to administer. I remember sitting in class with guys who just couldn't wrap their brains around the idea around signing keys. They treated it as a cargo cult ritual they had to do in order to get the system to work, but they'd much rather have had plain old account names and passwords. By the time we got to delegating signing authority, most of the class had mentally checked out.

Oh, that and the fact it was ugly a sin.

And marketed by a company that couldn't explain what the product *did*, so they mis-positioned it as an email system.

But for the kinds of asynchronous and distributed form entry / review / approval kinds of applications it did an amazing job for a piece of early 90s software.

Re:How difficult is it to remove Adobe Reader?

[gtall]

DoD factotums would lose their mind without pdf forms. The alternative is some microsoft crap, them are worse. Anyhow, they are handy except for one thing, some forms are set up in such a way that you cannot save them; you can print them though...sort of defeats the purpose. I suspect the rest of the fed. gov. is similarly encased in this stupid behavior.

Re:How difficult is it to remove Adobe Reader?

[Sheik Yerbouti]

Lotus Notes is a self corrupting database posing as an email system ;-)

Seriously though why not just web forms keep java script in the browser so we only have to worry about the browser as a javascript threat vector. PDF forms seem like a complete duplication and a poor one at that since it's more efficient to send someone a URL to a website that can take the data and then pass it on to the back end system automatically. Only reason I see people doing the adobe forms is because they are too lazy, dumb, or ignorant to either build a simple forms based web app or hire a coder to do it for them.

Adobe gives them a simple tool they can do it themselves without knowing any code. Wait I just had a product idea everyone stop reading this and forget what I have said. I will reinvent Lotus Notes only this time it will work!

Re:How difficult is it to remove Adobe Reader?

[plover]

And marketed by a company that couldn't explain what the product *did*, so they mis-positioned it as an email system.

Reminds me of an old Christmas carol parody:
"We don't know what Lotus Notes is,
We don't know what Lotus Notes is,
We don't know what Lotus Notes is,
But we use it each day."

Re:How difficult is it to remove Adobe Reader?

[Ben Newman]

God I wish we would just implement all of the CSS print features in the spec so I could do exactly that. The only reason I've incorporated any type of PDF functionality into any web app I've written recently is that you still can't hit print from your browser and get a well formatted document out of it. Unfortunately I need this in IE because of my user base, and it'll be a cold day in hell before Microsoft does this as it moves Office one step closer to obsolescence.

Re:How difficult is it to remove Adobe Reader?

[hey!]

Why not just do things in web forms and live with the consequences?

Because the consequences are not acceptable. I agree it's *better* than living with the consequences of living with Acrobat, but that's not saying much.

It gets worse if you can't run your system off a single web server that you can secure with TLS then watch like a hawk. In many of these forms applications, one of the key requirements is to be able to fill in forms without having Internet access. Maybe in a few years ubiquitous wireless Internet access with VPN will make that requirement negligible, but we aren't there yet. Until then, you've got to deal with users having copies of sensitive data.

There's still a lot to be said for a special purpose tool just for this purpose with two factor security and local data encryption. Notes showed that this was quite feasible with early 1990s technology. It should be possible to do an even better job today, but from a crypto standpoint I haven't seen that happen yet.

And as for the the admin who might have told you the Notes dog ate your homework -- I have my doubts about him.

Re:How difficult is it to remove Adobe Reader?

[jonom]

I too develop interactive PDF forms using LiveCycle and I'd like to add a few things.

Why PDF vs HTML forms? You don't have to be connected to the internet. Forms can be saved partially completed and be finished later (with Reader Extensions which allow saving, among other things, with Reader).

Do you need a signature with that form? HTML fails. With PDF you can print the form out, sign it and send it in - with 2d barcode technology that form can be scanned in on the receiving end and all data retrieved electronically.

Why Javascript or any other scripting ability (there's also FormCalc in PDF)? Besides error checking, math and other obvious things - interactivity. I can have the form adapt as it is filled in. Clicked a checkbox that says you're not married and don't have kids? You won't see those kinds of questions later on in the form.

This only scratches the surface - with the full suite of LiveCycle server technology you can do some pretty amazing stuff.

Re:How difficult is it to remove Adobe Reader?

[bored]

Seriously though why not just web forms keep java script in the browser so we only have to worry about the browser as a javascript threat vector. PDF forms seem like a complete duplication and a poor one at that since it's more efficient to send someone a URL to a website that can take the data and then pass it on to the back end system automatically. Only reason I see people doing the adobe forms is because they are too lazy, dumb, or ignorant to either build a simple forms based web app or hire a coder to do it for them.

But adobe can't sell that.. What they can sell is print accurate display. But that market is only so big, so they make up excuses like we need javascript to do form validation. Which everyone knows is BS, form validation can be done with simple rule or regex based engines. The truth is, they want to sell big expensive customized "work flow management" packages that lock their customers into a proprietary technology they can milk for decades. Which any idiot can see, and hence the reason you don't see lots of PDF forms. The fundamental problem is, PDF is the defacto standard for display independent layout and printing. Nothing else really comes close (except maybe ps, DVI needs font encapsulation), so everyone is jerked around by the needs of a company to make money.

Re:How difficult is it to remove Adobe Reader?

[PIBM]

That's what I was referring to on the first line, notice he removed every plugin that he had on adobe reader, so I was saying to go the full way and remove the viewer altogether :)

Re:How difficult is it to remove Adobe Reader?

[mftb]

It's only Adobe's own pdf viewers that are broken in that way. Bizarrely (or not), everybody else's pdf readers boot in seconds, if that, and are stable once up.

Tea and pramwiches

[daeley]

"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

[Frosty Piss]

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

Re:Tea and pramwiches

[Anonymous Coward]

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

[ben0207]

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

In your face!

Re:Tea and pramwiches

[Nerdfest]

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!

[FrostedWheat]

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!

[Qzukk]

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!

[Mornedhel]

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!

[Volante3192]

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!

[clone53421]

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.

Re:PDF forms? DIE!

[clone53421]

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!

[TooMuchToDo]

Or you have the user submit the data online and print out a barcode (1/2D) they can bring in and have scanned by someone at the DMV or where ever to lookup the record. Or the barcode is sent to their mobile device to be shown and scanned.

Re:PDF forms? DIE!

[Mornedhel]

That was my point, actually. You fill an HTML form, press Submit, the server generates a nice PDF from your data, serves it to you, and you print it.

Re:PDF forms? DIE!

[cbhacking]

MS Word fully supports editable fields. You can even include "default" text (such as "XXX-YYY-YYYY" for a phone number) that is erased if somebody clicks on the field. The "Use a crap-ton of underscores" idea is from people who don't know how to use the software, not from a limitation of the format.

I'm not sure whether or not you can do verification of the fields without macros though, and I'm quite sure you can't submit them online. Not that writing macros is hard, or even terribly uncommon, but they raise security concerns of their own.

On the other hand, unlike Acrobat Reader, the default behavior in Word is *NOT* to execute macros. Hell, recent versions even have their own file extensions for macro-enabled documents (which you will still, by default, receive a warning about). Good luck trying to figure out whether a PDF has some JS in it before opening it...

Re:PDF forms? DIE!

[defaria]

Government crap need only be done on paper because the government insists that it's done on paper. The government could tomorrow pass a law saying that paper is no longer required. They did pass laws saying that digital signatures are valid. The government should get out of the business of issuing Social Security Cards and into the business of issuing digital IDs. HTML+CSS can do just about everything that is required and I say anything it can't do really is necessary! It really, really doesn't matter if a document flows exactly this way or that way - just that it's readable, comprehensible and usable. The rest is pure fluff and not required.

Simple answer

[just_another_sean]

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.

Re:Simple answer

[OzPeter]

And Joe Sixpack will say to him/herself

"the only way I can see my embedded VMware virtual machine with full video documentation [1] is to click on the whitelist button for the producer. and I really want to see this .. so here goes".

[1] Shamelessly stolen from a previous comment VMware embedded documents

What Wasn't Said

[Anonymous Coward]

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?

[ickleberry]

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?

[Volante3192]

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?

[plover]

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.

Re:PDF with a form?

[Skater]

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.

You don't want to do that. I had a situation a couple years ago where the DMV misread what I'd written (and I have reasonably good handwriting) and put incorrect information for the lienholder on the title. Well, my credit union wanted me to fix it, of course, because they were afraid they wouldn't get paid if the vehicle was totaled. Long story short, it took three trips to the DMV (with hour-long waits each time) to fix the problem. I don't remember all the details, but I do remember one problem they had was that the letter from my credit union wasn't on letterhead that had their address, or something crazy like that.

Eventually I got it all straightened out and was glad I was done with the DMV for a while. Then I discovered that when I was registering that vehicle, the DMV incorrectly canceled the registration on another vehicle I owned. Back to the DMV again...

Re:PDF with a form?

[Anonymous Coward]

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.

I recently used a PDF form that submitted through the web to file Texas Franchise Tax forms for my business. I filled out the form in Adobe Reader 9 in Ubuntu. I don't see why the same form couldn't be implemented in HTML/JavaScript.

No, not a good idea at all

[Nomen Publicus]

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

Re:No, not a good idea at all

[Anonymous Coward]

Why does a product called "GIMP" not involve fucking a man in a leather suit?

Re:No, not a good idea at all

[Anonymous Coward]

If you want a dumb reader, my I suggest Sumatra PDF.
It's the best one I've found yet.

Or check out the Alternativeto.net page for Acrobat and find your own.

Re:No, not a good idea at all

[idji]

so you can fill in the fields on screen, print out the document, sign it and fax it back to the goverment department or insurance company that you downloaded it from! And so their OCR software can read it without requiring human intervention. That way they don't have to change any internal work processes that they have been using for years - but you the customer downloaded, printed and made it machine readable -saving them work.

Re:No, not a good idea at all

[Chester K]

For the same reason your "web browser" can submit forms.

i discovered a new concept today

[circletimessquare]

the bloatware partisan

Maybe it's just me

[mandark1967]

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

[jellomizer]

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

[mandark1967]

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.

Re:Maybe it's just me

[Jeng]

To summarize. Perfection is the enemy of the good.

CS4 Scripting too

[0100010001010011]

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.

Re:CS4 Scripting too

[FlyingBishop]

That's cool. But I really don't need a document extension language. It's a document, not a graphics editor.

Re:CS4 Scripting too

[nine-times]

I don't think anyone has a problem with scripting in the applications. It's putting scripts into the documents that concerns people.

Part of the problem, as I see it, is that computers have an conceptual division between documents and applications. Applications actively do things when they're run, and so you never want to run an application from an untrusted source. Documents, on the other hand, are supposed to be passive and not do things on their own. Opening a document from an unknown source shouldn't be too dangerous, since it shouldn't be able to do anything on its own. If the viewer installed on your system isn't designed to do anything malicious, then the document shouldn't be able to do anything malicious just by viewing it.

Now that distinction isn't entirely clear or necessary, but that's the way all of our desktop/document metaphors were designed. However, when you allow scripting and macros to be embedded in the document itself, the documents sort of straddle the line between "document" and "application". Even if it requires some kind of viewer in order to run, a PDF still becomes an executable file, and therefore cannot be trusted.

Re:CS4 Scripting too

[Anonymous Coward]

That is an entirely different issue. A PDF reader doesn't NEED support for ANY scripting language.

Why not html forms?

[jack2000]

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?

[jbolden]

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?

[Volante3192]

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?

[diskofish]

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?

[castironpigeon]

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?

[Volante3192]

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?

[TheRaven64]

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?

[jack2000]

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?

[geminidomino]

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.

Re:Why not html forms?

[Volante3192]

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?

[LOLLinux]

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?

[Jaysyn]

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?

[VGR]

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.

Re:Why not html forms?

[Monkeedude1212]

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.

No, its not harsh at all. People need to distinguish the difference between "Web Programming" and "Web Design". HTML/CSS is the latter. Javascript is a sort of in the middle - in that anyone with a decent IDE can design a web page to use basic Javascript functions. Web Programmers, the guys who do the nitty gritty stuff, know that you can't fire off an email using Javascript. You either link a Mailto: or you use something else backend, usually something .NET . I say .NET in that its standard across all Windows PC now, or close enough to be negligable.

Thats why PDF Forms have a small Niche - they work on Windows, Mac, anything that can run the latest versions of Adobe.

And for the "WC3 has made HTML and other web programming less accessible" - In what way? You can still do the same HTML Design the old way (minus a few deprecated tags) as much as you want. The only problem is that your web page will look like something from the early 90's. Or you will be spending ALOT of time on a now trivial task, that takes less than a day to learn.

Re:Why not html forms?

[Grishnakh]

Not necessarily. The government is a big user of PDF forms. The IRS, for example, has all the tax forms available as fillable PDFs.

Yes, it might make more sense to just have HTML-submitted forms, but again, this is the government we're talking about. They're not exactly known for being extremely technology-savvy, or having well-functioning IT departments (necessary for any web-based systems). Fillable PDF forms allow you to download the forms, type all your information into them, and then print them out on paper and send them in the mail. You can't do that very well with any other solution. Sure, it'd be nice to submit your taxes online, but again, this is the government. They wouldn't be able to keep their systems running properly on April 15th, and it'd be a disaster.

Re:Why not html forms?

[Volante3192]

So...you're agreeing with me? Heh.

You don't submit the PDF form electronically, you just fill it out and print it out.

GP was saying there was no online way to submit their data. I was figuring if they could accept PDF forms electronically, they could make and accept HTML ones without much extra effort.

Re:Why not html forms?

[Grishnakh]

Sorry, I don't always read the entire chain of posts.

But yes, it seems to me the most useful purpose for fillable PDFs is for forms you can download, fill out on your computer, and print out. It should be very obvious how this is useful for the government, which loves paperwork but definitely isn't up-to-date with web-based infrastructure.

Re:Why not html forms?

[geminidomino]

Thats why PDF Forms have a small Niche - they work on Windows, Mac, anything that can run the latest versions of Adobe.

No, they have that niche becaues whoever is setting up those sites is ignorant or incompetent. The same thing can be accomplished trivially without adding all sorts of useless (read: "input") functions in what was intended to be a display format. A simple,standard html form, plus a form handler in $server_backend_of_choice can create PDFs just fine (and you can do it without paying adobe a dime).

The PDF forms crap is just yet another lock-in/cash grab that we should all be used to by now.

Re:Why not html forms?

[jbolden]

HTML renders based on the browser and printer The forms are not remotely similar from computer to computer. Same thing with word processing programs.

Re:Why not html forms?

[Anonymous Coward]

back end mail scripts are usually php or perl.

Re:Why not html forms?

[Sleepy]

>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.

But what does this have to do with form -submission-.

Seriously... this is a task which does not belong in a presentation format.
The job can be delegated to a background server process (webserver, proprietary email server, I don't care), or it
can offer to fire off a browser (which would need to support this task) and let the browser do the submit.. and I don't mean automatically. You get to proof what the browser is sending, then press submit.

I can't tell you how many PDFs I get which ask me to "fill out this PDF" and NO instructions how to do that. My PDF viewer is on Linux, and it doesn't run Javascript (nor do I want it to).

It's funny... you can design a Javascript application on the web which DEGRADES nicely to plain HTML if the browser does not support Javascript. No problem whatsoever, if your web developer knows what "non-intrusive Javascript" means.

For Adobe to not work out a no-JS solution makes them as bad as Microsoft, willfully flouting standards for control and refusing to fix core vulnerabilities for years and years. Eventually, Adobe is going to be forced to address these issues... but in the meantime they're content to let the bodies pile up in the street.

Re:Why not html forms?

[Monkeedude1212]

You want to set up a server_backend_of_your_choice? I know the average user doesn't. I do know the average user (at least in my business category) does use PDF forms.

Re:Why not html forms?

[Anonymous Coward]

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.

Why? The entry form rarely has to be a strict visual representation; it's usually the output of that form that must look correct. The target document should be a PDF, but if you're filling out a form, it makes more sense to use a website to conduct an interview and generate a completed PDF for download.

However, if the company is already able to do this, in most cases it makes much more sense to have a "submit" button and have the form submitted directly to the company's database instead of saving to a local PDF which then has to be saved, printed, mailed, received, processed, and finally scanned and/or manually entered back into that same system.

There are some situations where generating a PDF makes sense, but I can't think of a single case these days where a forms-enabled PDF brings anything to the table that couldn't be better handled through some other data entry method and a PDF generation script.

Re:Why not html forms?

[Volante3192]

But what does this have to do with form -submission-.

Nothing, not electronically. The niche for PDF forms is when the end result is printed and delivered by hand/mail/courier/pigeon/et cetera.

To quote the GP:
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.

This all started off on printing hard copies, not electronic submission.

My argument is HTML is not as effective as a PDF for printing. (Heavily tested HTML, maybe, but in the time it takes to make it, you could have a form based PDF in a fraction of the time.)

Furthermore, it's an odds on favorite that a user will have a pdf viewer handy. Even if you have javascript off you can still print out the form blank and write in the details.

So, in a perfect world, PDF forms are limited solely to occassions when a hard copy is required by the receiving party.

Re:Why not html forms?

[Ansoni-San]

You sound like a back-end programmer that is bitter his crappy HTML table-generator doesn't cut it anymore.

1. It's W3C not WC3.
2. Why should a non-geek care about W3C standards? They can still code in any broken HTML they feel like if the browser displays it properly. The only reason they'd care is if they're trying to pass it off as professional or paid work. In which case they should work to the quality their client requires or stop lying about their skills

All UI programming is complicated and tricky, this is well known. As languages become more and more abstracted from the nitty-gritty details of interacting with the OS, they become more and more focused on abstract concepts such as objects and their interactions. HTML defines objects (nodes, their attributes, types), CSS and JS define how they interact. If you are so narrow-minded in regards to the tools you use to define or implement your solution then I'm afraid you don't have a very bright future in this field.

Try your hand at some real UI programming for local applications for a while and you'll realise that HTML/CSS/JS is really the UI toolkit you wish you always had. See how long it takes you to write a UI engine to achieve custom behaviour it would have taken an hour or two to achieve using HTML/CSS/JS.

Re:Why not html forms?

[Anonymous Coward]

the most useful purpose for fillable PDFs is for forms you can download, fill out on your computer, and print out.

And that doesn't (read: shouldn't but given the other braindead things Adobe has done probably does) require JS.

Even validation should be done with simple regexes or something. There is absolutely no excuse to run JS in a PDF.

Re:Why not html forms?

[geminidomino]

The average user shouldn't be the one setting up the websites then. I don't see how anyone, even an average user who is ignorant of the stupidity of PDF forms as a concept, can think the "download this form, enter the information, then email it back to us" workflow isn't horrible on its face.

If you want something done right, you get someone who knows how to do it.

Re:Why not html forms?

[Grishnakh]

No argument here. I was just pointing out why fillable PDFs are useful. To most people here on /., they probably seem pretty silly, but when you consider the government and their love of paperwork, it makes sense.

bummer dude

[varmint jerky]

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

[Anonymous Coward]

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

[Alphanos]

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

[plover]

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.

Re:Security Not the *Only* Consideration

[myowntrueself]

Whenever people like this talk about 'security' what they really mean is 'financial security'.

There is simply no other form of 'security' on their radar.

Fine, but...

[MobyDisk]

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...

[clone53421]

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.

Re:Fine, but...

[Spliffster]

If I had mod points, i would mod you up.

Paper is really getting less important to People. PDF is best used for generating print ready documents or archiving old and newly created documents. It's a print media used read-only. When we need to submit data there are various better suited ways, today html/http is preferred (specially when cross-platform compatibility is of concern).

Integrating form functionality and scriptability is a desperate try to transform a static print media into an interactive online media. Too many other technologies do it already, so there is no need for replacement (and wasn't early this decade when forms were added to PDF).

What I never understood is, why adobe hasn't added a simple data store in their document format. Then extend the "Reader" to be able to store data in the document in a standardised way. A filled out form would stay filled out. it could be archived, mailed and automatically processed by software which imports this data back into other storage system(s).

Cheers,
-S

Re:Fine, but...

[MobyDisk]

If it was in a proper sandbox, the buffer overflow still couldn't do anything that that sandbox can't do.

Re:Fine, but...

[clone53421]

But how do you know you’ve built an improper sandbox until someone breaks out of it?

It’s possible, in theory. In practice, it’s difficult.

Re:Fine, but...

[jonom]

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.

It's not an obsolete concept - HTML fails if you don't have online access or if you need a wet signature. Sure you can print out the HTML form but it's going to look like crap.

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.

Adobe's security specifically doesn't allow you to do those kinds of operations unless you have access to the user's hard drive beforehand for installing trusted functions. Only really useable in a networked office/enterprise.

Envy

[psbrogna]

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...

[gad_zuki!]

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.

Re:Keep your JS but...

[Grishnakh]

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.

I'll tell you what Adobe is thinking: if they trimmed down their PDF reader to only do what it needs to, and stopped trying to bloat it up with all kinds of crap that almost no one wants, then they would have a product that no one would want to pay for, because there's plenty of free/cheap alternatives that are better for doing the things that most people do with PDFs. Adobe is a big, public corporation with shareholders to please, and that means that they need higher and higher quarterly profits. Part of achieving that is adding everything including the kitchen sink into Acrobat/PDF to get other dumb corporations to buy their overpriced tools and use them.

Remember, you, some guy on the internet that only uses Adobe's reader and not their content-production tools, are NOT their customer. They don't care if you don't like that their reader is 150MB, because you're not their target market. Their target is some dumb company, or better yet the government, that wants to use their expensive tools to make fancy PDFs, which then require you to download their 150MB reader to use these PDFs in order to file your taxes or work with the DMV.

This is a case study in how Free software many times works much better than corporate-produced for-profit software: for many applications, there comes a time when it's pretty much "done", and no one really wants any more features added. For Free/OSS software, this isn't a problem: the application is mature, and just goes into maintenance mode, and the authors move on to something else unless a bug comes up, or maybe they want to update the UI a little, or whatever. For corporations, this is unbearable: a mature application means no steady stream of new customers, so they need to keep adding crap ("bloat") into it to get people to "upgrade" to the latest version, which they can charge more for. They need to do this so they can have continuously increasing revenues.

Re:Keep your JS but...

[teridon]

You can use the Adobe Javascript Blacklist Framework to block the vulnerable function completely, so that no matter what the (non-admin) user does, they cannot execute the Javascript. They still get prompted about the Javascript, but it won't execute.

More information about mitigating the vulnerability using this method is
here:

http://kb2.adobe.com/cps/532/cpsid_53237.html

More general information about the framework is here:

http://kb2.adobe.com/cps/504/cpsid_50431.html

PDF has forms before Javascript

[wiredlogic]

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

[Anonymous Coward]

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

Re:PDF has forms before Javascript

[pclminion]

A PDF "form" is just a macro of content stream commands. It has nothing to do with a "Form" in the sense of a document with fields that are filled in. And if you're thinking of FDF, that's a different issue entirely. FDF represents form data which will be composed by software on top of a form -- what we're talking about here are user-filled forms, submitted from the reader. THAT functionality is almost entirely implemented in JavaScript.

PostScript has nothing to do with PDF either. The content stream format of PDF was designed to map onto PostScript, but the reverse is not true. PDF readers have no PostScript processing abilities, and Adobe actively discourages the use of PostScript-specific features of PDF (which, sadly, still exist in limited form).

Re:PDF has forms before Javascript

[wiredlogic]

Postscript can definitely be hand coded. Using it to produce a complete document is not for the faint of heart but it's no worse than writing Lisp. Once you have a library of layout routines set up it is pretty easy to do. There is a gentleman, Don Lancaster, who has been putting out newsletters for years using handwritten code. Here are some examples.

And to the other responder. PDF may carry over the Postscript concept of a "form" as a macro but I was referring to "form entry" which has long been a part of PDF and it predates the inclusion of Javascript. There's nothing precluding the use of a limited subset of Postscript as a validation language. You wouldn't need to have support for any of the graphical operators or file I/O. The core Postscript interpreter is far simpler and hence easier to secure than Javascript.

Re:PDF has forms before Javascript

[Anonymous Coward]

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.

JavaScript doesn't have those things either. They're plugged into the interpreter by the host application, and that could be done just as easily with a Postscript interpreter.

Market grab turned ugly

[bl8n8r]

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

[Stumbles]

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.

Re:B-A-L-O-N-E-Y

[Mongoose Disciple]

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

Re:B-A-L-O-N-E-Y

[Anonymous Coward]

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

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

Re:JavaScript: the biggest computing fuckup ever.

[Anonymous Coward]

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.

Are you drunk?

[spun]

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.

Stop right there.

[geminidomino]

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...

[oglueck]

...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

[gehrehmee]

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?

Re:PDF Javascript vs WWW Javascript

[BitZtream]

Browsers are used FAR FAR more than PDF. Browsers user FAR FAR more likely to have already experienced these exploits and had them fixed.

It isn't that Adobe isn't as good as it so much as that Adobe is just a new player in the JavaScript world.

And for reference, Firefox and Adobe are sharing some implementation details.

http://www.mozilla.org/projects/tamarin/

How the script interacts with the rest of the software is a problem. The exploits (without actually looking at these specific details) are generally not with the JS engine, but are with the integration between the engine and the application. What generally happens is that someone connects JS to some component of the C code that does things that shouldn't be allowed in a document, but the guy who wired up the connection between JS and the C code doesn't know about the danger or doesn't realize that it allows someone to create a chain of objects that can do something nasty and otherwise normally not allowed.

Security in complex systems such as a browser or pdf viewer is insanely complex. Not only do you have to protect against the user doing potentially bad things, you also have to make sure that the document the user is opening doesn't do something the user doesn't expect, while still allowing all the other stuff the user wants to do to work.

Re:PDF Javascript vs WWW Javascript

[kriston]

The only trojan horse software infection I ever got was vectored through Adobe Acrobat Reader JavaScript.
It was a form of the Vundo trojan horse http://en.wikipedia.org/wiki/Vundo.
It came in through Adobe Acrobar Reader 8, attached itself to winlogon.exe, and is impossible to remove unless you boot the computer off a book disc like BartPE and remotely manipulate the system's registry to remove it, Heisenberg-style.

Re:PDF Javascript vs WWW Javascript

[Sleepy]

>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?

Peer review.

Shine a light (or point enough eyeballs) on a bug, and it becomes transparent. Someone will send a patch in for review, or public debate will force an architecture change to safer methods. This is how open source applications like FireFox work. When ICANN said it was OK to start selling domains in non-latin characters which LOOK like latin, phishers drolled at the prospect of owning something that looks like "paypal.com" in hundreds of different forms (Cyrillic's latin looking characters, etc). Firefox developers voted to revolt, and not display non-latin domain names in a exploitable fashion.

Adobe's security experts (and the community) can give their input to Adobe, but Adobe marketing gets to say what is and what is not "a non-starter". There's a valid concern of repeat vulnerabilities here, and Marketing (correctly so) knows convenience over security means MORE SALES.

Adobe is accountable ONLY to their shareholders, who can legally sue them for not moving the upgrade-treadmill fast enough (shareholder value).

Re:PDF Javascript vs WWW Javascript

[rwade]

Just to tag on to your comment, in the 10 years I have been using PDFs I have used exactly zero online submitable PDF forms. Zero. Not for taxes, not for the DMV, not for college applications, not for anything. Why would I use it? I have HTTP for that.

However, I have picked up a trojan horse virus infection from a PDF.

Re:PDF Javascript vs WWW Javascript

[Anonymous Coward]

Either that, or if they're using their own, why not just remove anything that involves external data streams (files, network connectivity, etc)? It sounds like all they really need it for is input validation and as glue for embedded Flash elements.

Of course, they probably also use it to manage all their UI elements, write form data back to another PDF, link elements in an "intelligent" manner, enforce DRM, format the hard drive, drop botnet engines....

Re:PDF Javascript vs WWW Javascript

[Blakey Rat]

Just FYI for next time, there is a way to remove Vundo without a boot disk:

http://blakeyrat.com/2008/10/how-to-really-get-rid-of-the-vundo-aka-virtumonde-virtumondo-ms-juan/

Once you've identified the offending DLLs, you can set their file permissions to "Everybody - Deny". When you next boot, they won't be allowed to execute and you can simply delete them. (You do, however, have to power-off your computer without shutting it down, which carries a tiny risk.)

Re:PDF Javascript vs WWW Javascript

[kriston]

Thanks but the offline registry edits were much more effective for me. I don't want the registry blottoed by an unclean shutdown after I tried to change permissions on a half-dozen randomly-named files.

Oh, and yes, I have yet to ever fill out a PDF form. The government's various paperwork reduction acts were supposed to phase them in and even today you still rarely see any.

Why JavaScript?

[Kleiba]

...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?

[Locke2005]

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?

Re:Why JavaScript?

[Kleiba]

Oh, right, good point - even simple things as "start date, end date" where you wanna make sure that the end date is _after_ the start date wouldn't be possible with regular expressions alone.

Smells like..

[SuperCharlie]

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?

[eigenstates]

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.

Huh?

[jack2000]

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.

You're and idiot and don't know what you are...

[gbutler69]

...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:You're and idiot and don't know what you are...

[Anonymous Coward]

Oh, geeze. Here come the JavaScript faggots, err, fanatics.

I understand JavaScript perfectly. I worked with JavaScript before your father deposited his filthy sperm in your mother's smelly twat.

I've had the misfortune of writing hundreds of thousands of lines of JavaScript code, since it's the "trendy" thing to do (according to all the crap that my manager reads). I know JavaScript inside and out.

Lisp and Scheme (note that their names are not fully capitalized, unless you're a fucking retard) put JavaScript to shame.

And congratulations for throwing out terms you heard in the Introduction to Computer Science course that you flunked out of. When I was in graduate school, I wrote several papers on Hindley-Milner type inference and nondeterministic evaluation strategies (based on the work of Church-Rosser) of lambda expressions. Unlike you, I actually do know what I'm talking about.

So, in closing, fuck off you pathetic little turdworm. Go back to Digg, where you can wait 45 s for each page load, due to the mountains of shitty JavaScript they throw at your browser.

Re:You're and idiot and don't know what you are...

[ColdWetDog]

Sorry Gramps. Looks like somebody forgot to give you your medication this morning. Here, take this.

You'll feel better in a little while.

Some shuffleboard for you maybe?

Re:You're and idiot and don't know what you are...

[riegel]

Wow you are really smart. Thanks for letting us know. But what is this "Anonymous Coward" bit?

Re:You're and idiot and don't know what you are...

[mister_playboy]

Go back to Digg, where you can wait 45 s for each page load, due to the mountains of shitty JavaScript they throw at your browser.

Posting that on Slashdot is delicious irony.

Re:You're and idiot and don't know what you are...

[jedidiah]

Only one use case was brought up for excusing the idea of bringing in an entire
scripting language into what could otherwise be an inert document format. Even
that singular justification is pretty weak and hardly requires anything approaching
Javascript.

It's simply not necessary.

Either that or the relevant Javascript pusher isn't making his case very well.

Re:You're and idiot and don't know what you are...

[Toonol]

First off: Everybody browsing this thinks you're an idiot, due to both your opinion (it's wrong) and your presentation (emotional, irrational, vulgar, and immature).

Secondly, the biggest problem with Javascript (really, the only significant one) isn't a problem with Javascript at all; it's a problem with browsers. The model they adopted of autoloading and autorunning scripts and/or applets is completely wrong. Web sites should always have been 100% static as a default, with scripts and embedded applets running only when actively triggered by the user. If any other scripting language had been used instead of Javascript, such as Python, everybody would hate IT instead.

Oh, I do get it.

[rickb928]

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.

Huh?

[gbutler69]

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.

declarative standards-based form validation

[leighklotz]

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, here, and here), server side implementations a la GWT (here and here), and mobile implementations (here).

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.

Re:declarative standards-based form validation

[CodeBuster]

Another salient point, IMHO, is that Adobe is interested in more than simple form validation with JavaScript. As others have mentioned in this discussion, Adobe wants to compete with web forms implementations of the type often found in CMS and other web based document management and collaboration tools. Adobe is desperately trying to avoid becoming pigeon holed into the "dumb document" viewing niche by nimble web-based competitors and this is another reason why Adobe, even if they eventually choose to support XForms, will be extremely reluctant to give up the sort of JavaScript support that allows them to "compete" (at least in their minds) with the web-based CMS and document management systems.

Re:declarative standards-based form validation

[leighklotz]

Enterprise customers are often those who are the most interested in security and in forms deployment. If Adobe offered a safe, secure, standards-compliant forms processing mode for PDF, enterprise would be the first market.

Because the alternative is impossible?

[Anonymous Coward]

Javascript default = OFF

"This PDF file uses JavaScript, which can sometimes be a security risk. Do you want to enable JavaScript support for this document in order to view it?" <YES> <NO>

Or the more sophisticated:

"This PDF file is a form that uses JavaScript for some of its function. Do you want to enable JavaScript support for this document?"

Sure, this guy is correct to defend support for JavaScript. But I can't think of any legitimate reason for a person interested in security to defend the decision to have it on by default.

Devil's advocate for Javascript

[RevWaldo]

I actually used Javascript in Adobe Acrobat a few years back. As part of a workflow process we were regularly bundling sets of PDFs together into one large PDF. This included a title page and a table of contents (talking about a printable one, not bookmarks.) So I futzed around with the Javascript and came up with a way to have the person creating the one big PDF to:

- open a blank Title/TOC PDF
- click a checkbox to unhide the form elements.
- enter a title into a field, which appeared on both the title page and the page headers
- check off which documents were being included in the PDF, which then showed those lines in the TOC. The chapter numbering e.g. 1), 2), 3) etc. also changed to match.
- click the checkbox again to hide the form elements, leaving just the printable title and TOC portions.
- save as a new copy, then bundle it with the other documents.

Pretty slick IMHO. It saved the users from having to waste time opening Word to create a new Title/TOC page every time.
But that being said, what happened in the PDF stayed in the PDF. It didn't have to connect to the web, etc.
This is of course the classic reason for bloatware. The feature that's unbelievably-useful-couldn't-do-my-work-without-it for 2% of the users is completely worthless to the other 98%, and we all belong to at least one group of 2%.
Adobe also has the problem of full Adobe Acrobat Pro vs. Acrobat Reader. Any changes made to a PDF in Acrobat Pro have to be compatible within Acrobat Reader e.g. if I highlight text in Pro and save the PDF I expect everyone who opens the PDF later on to see it too. Otherwise they could simply make all the additional features (including Javascript support) plug-ins and be done with it.

Yeah, right

[Locke2005]

All of this stuff has JavaScript behind the scenes making it work and it's difficult to remove without causing problems," Arkin explained. Translation: "We designed the products with a flawed security model to begin with and fixing that now would cause applications built on them that depend on defects in the security model in order to operate to no longer work."

So what I'm hearing is...

[myddrn]

Security is hard! Lets go shopping!

Problem solved

[BlueBoxSW.com]

Here's the solution:

Use .PDF for documents WITHOUT javascript, and use a new extension for docs WITH javascript.

Users/admins can handle what app opens what format on their end, or disallow one format all together.

Done.

PDF doesn't have Postscript?

[Anonymous Coward]

Why does it have to be Javascript. I thought PDF was built on top of Postscript, a language in it's own right. Why not use that?

Re: vulnerabilities when running Windows

[butlerm]

The only trojan horse infection I have had in the past decade was due to visting a "security" web site that exploited a Java vulnerability. I use XP for work, and never run as an administrator anymore, unless I need to install software. In XP it is fundamentally unsafe.

I imagine running as limited user all the time seriously reduces the impact of Adobe Reader vulnerabilities like this, among others.

Please let me...

[hesaigo999ca]

Please, let me hit him in the head with a bat, I promise I wont let him suffer, please, let me make him see the light.
What a mofo, sounds way too much like a clueless idiot, that got his job handed to him by being a family or friend.

Regexen?

[Anonymous Coward]

Why do you need Javascript to verify that fields in a form match certain formats? Wouldn't, say, regexen be able to do the same thing?

So he's telling the world to stop using PDF ...

[zuperduperman]

Seems like he's just done a mea culpa and asked the world to stop using PDFs as a document format.

He's basically said: "Our document format is out of control. We no longer have the ability to keep it secure. Run for the hills. Save your women and children if you can. Treat our product the same way you treat malicious .exe's when your browser encounters them. Whatever you do, don't use it for encoding simple read only documents, it's not meant for that."

Re:So he's telling the world to stop using PDF ...

[owlstead]

Exactly. They are trying to host forms on an application most people just use to view formatted pages of text. Fine by me, just call it .fpdf, create a new MIME extension and be done with it. It could still be nicely compatible with Acrobat Reader, and you could disable JS for normal .pdf files.

Currently I am just using another viewer without any JS and 10 pages of settings just to be able to view .pdfs without getting a headache. They are trying to accomplish multiple things on a popular platform and are falling in their own trap.

Aha, and how comes I do not miss it in XPDF?

[gweihir]

Maybe I do not need it at all? This explanation sounds like complete BS to me. PDF is a display format and active content has no business at all in it. At the same time it is rather obvious that having JavaScript in there is a huge, hige risk and the JavaScript should be implemented with great care and not fall over because of a simple, amateur-level buffer overflow...

JS SUX

[Anonymous Coward]

Javascript is EVIL! All of this validation can be done on the server side in a much more secure manner. Come to the server side, we have cookies.