Adobe Security Chief Defends JavaScript Support 216
Trailrunner7 writes "Despite the fact that the majority of [PDF-related] malware exploits use JavaScript to trigger an attack in Adobe's PDF Reader product, the company says it's impossible to completely remove JavaScript support without causing major compatibility problems. In a Q&A on Threatpost, Adobe security chief Brad Arkin says the removal of JavaScript support is a non-starter because it's an integral part of how users do form submissions. '"Anytime you're working with a PDF where you're entering information, JavaScript is used to do things like verify that the date you entered is the right format. If you're entering a phone number for a certain country it'll verify that you've got the right number of digits. When you click 'submit' on the form it'll go to the right place. All of this stuff has JavaScript behind the scenes making it work and it's difficult to remove without causing problems," Arkin explained.'"
Easy but far too simple solution (Score:5, Insightful)
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: (Score:3, Informative)
Well you can always use alternate PDF readers, like Foxit Reader [foxitsoftware.com] (and no bloat either)
Re:Easy but far too simple solution (Score:4, Interesting)
Re: (Score:2, Insightful)
Re:Easy but far too simple solution (Score:5, Informative)
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: (Score:2)
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
Re: (Score:3, Informative)
So given that its faster, and has a better (though not perfect) track record, id say yes, it is better.
Re: (Score:3, Funny)
Re:Easy but far too simple solution (Score:4, Funny)
Dreamweaver?
Re: (Score:2)
Re:Easy but far too simple solution (Score:5, Insightful)
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: (Score:2, Funny)
Re: (Score:2)
"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 (Score:4, Funny)
...and that's how Emacs stayed its original, trim self.
Re: (Score:2)
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: (Score:2)
Re: (Score:3, Insightful)
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
Re: (Score:2)
Re: (Score:2)
IRS forms also have fillable fields.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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: (Score:3, Interesting)
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 ma
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2, Funny)
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
Simple solution (Score:3, Interesting)
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2, Informative)
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 [planetpdf.com]
Re: (Score:2)
I stand corrected. Thanks very much for clarifying that.
Re: (Score:3, Insightful)
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?
How difficult is it to remove Adobe Reader? (Score:2)
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: (Score:2)
Just remove the pdf viewer altogether...
The web is so much nicer without those ugly, slow loading, web browser crashing pdf junk...
Re: (Score:2)
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 bo
Re: (Score:3, Interesting)
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: (Score:2)
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? (Score:4, Informative)
(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: (Score:3, Interesting)
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 ele
Tea and pramwiches (Score:5, Insightful)
"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: (Score:2)
Ha! That's where you're wrong! He got modded Insightful!
In your face!
Re: (Score:2)
I thought it was funny too, but maybe that's just me.
PDF forms? DIE! (Score:2)
Re:PDF forms? DIE! (Score:4, Interesting)
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: (Score:2)
Re: (Score:3, Informative)
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: (Score:2)
Re: (Score:2)
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 pe
Re: (Score:2)
Word documents with 50,000 underscores that wordwrap when someone tries to write in them
The correct way to create those is with an underlined tab character.
Simple answer (Score:4, Insightful)
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: (Score:3, Funny)
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 [slashdot.org]
PDF with a form? (Score:2)
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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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
No, not a good idea at all (Score:3, Insightful)
i discovered a new concept today (Score:3, Funny)
the bloatware partisan
CS4 Scripting too (Score:5, Informative)
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.
Security Not the *Only* Consideration (Score:2)
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: (Score:3, Insightful)
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 mo
Fine, but... (Score:2)
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 o
Re: (Score:2)
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: (Score:2)
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 med
Envy (Score:2)
Keep your JS but... (Score:2)
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
Re: (Score:3, Interesting)
Not to mention, when I shut it off under Preferences - KEEP IT OFF. If its off in preferences, it helpfully reminds the user than its off and offers to re-enable it via the prompt. What the hell is Adobe thinking?
While I'm at it how about updates to the reader that arent 40-150 megabytes big or an updater that actually works. Right now, sane people should be considering Reader are very serious security vulnerability and migrating off the platform. Adobe has shown nothing but contempt for even basic security
PDF has forms before Javascript (Score:2)
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: (Score:3, Informative)
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
Re: (Score:2)
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 [tinaja.com] examples [tinaja.com].
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
Market grab turned ugly (Score:2)
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.
Except... (Score:2)
...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 (Score:3, Insightful)
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: (Score:2)
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/ [mozilla.org]
How the script interacts with the rest of the software is a problem. The exploits (without actually looking at these specific details) are generally
Smells like.. (Score:2)
Oh, I do get it. (Score:2)
JavaScript is a feature that Adobe believes is useful enough to tolerate the security compromises.
Or to rephrase it, Adobe Reader is so good, security doesn't matter as much as features.
Yup. That's how they see it.
declarative standards-based form validation (Score:3, Informative)
Adobe should move away from JavaScript and move to declarative form definition and validation, which carries no risk of code attacks from errant JavaScript. In fact, there is a standard for validating forms declaratively, called XForms. It lets you write validation expressions for saying when data is valid, required, readonly, or calculated from other data (i.e. totals), and also lets you assign data types using the widely-deployed XSD type names (integer, URL, string, regexp string, etc).
XForms is modular enough that it's been incorporated into ODF, and there's no reason other that it can't be used in PDF to define and validate forms, other than that Adobe has a vested interest in maintaining its proprietary technology forms instead. There are a number of folks who would be quite ready to help Adobe incorporate XForms into PDF.
There are in-browser JavaScript implementations of XForms (here [agencexml.com], here [google.com], and here [formfaces.com]), server side implementations a la GWT (here [orbeon.com] and here [sourceforge.net]), and mobile implementations (here [picoforms.com]).
I've been working with XForms for many years, and find it an excellent solution for deploying rich internet applications; we've switched implementations a few times, and have had to do only minor changes to our applications, so using a standard preserves our investment in stuff already written.
Devil's advocate for Javascript (Score:3)
- 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 (Score:3, Insightful)
Re: (Score:3, Insightful)
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? (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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 Wind
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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 so
Re: (Score:2, Insightful)
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.
Re:Maybe it's just me (Score:4, Interesting)
To summarize. Perfection is the enemy of the good.
Are you drunk? (Score:2)
Yep Java is such a powerful language... it is the only one that can verify the correct number of digits for a phone number, the right date, etc. So there all you purist language tards; things like C++, C, perl, python, etal are utter crap compared to the almighty Java and its scripts. Who cares if there are a few security issues introduced, Adobe could not give a shit about it.
No, seriously, are you? Because I don't even know where to start here, I mean, come on! Are you trolling? This whole post is meaningless jibber-jabber. Java isn't java-script. In fact, they aren't even related. ANY general purpose language included in a document mark-up language can introduce vulnerabilities. This isn't about one language versus another. The question is, why does a document format need scripting at all? Sheesh.
Re: (Score:2)
... you do know that Java and JavaScript are completely different and essentially unrelated things, right?
Re: (Score:2)