Unexpected features in Acrobat 7
| LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing |
Linux users may have been pleased to find that Adobe has finally made available a new version of its Acrobat Reader, with accessibility features, a much slicker interface than Acrobat 5.x and new and other spiffy features. However, there are a few other features that Linux users should be aware of.
A company called Remote Approach is promising to alert PDF publishers as to the "reach and use of their materials." We were curious to find out how Remote Approach was going to make good on its promise, given that PDF has largely been seen as a one-way medium. To find out, we created a test account and uploaded a PDF to be "tagged" by Remote Approach, and then downloaded the modified document to see whether Remote Approach could log our use of the document.
Remote Approach's reporting did not work when we viewed the document with Kpdf, Xpdf and Adobe Reader 5.0.10. It also failed using Apple's "Preview" application on Mac OS X. The document was still viewable with no apparent glitch in other PDF readers, but the reporting function did not work. However, when we opened the file using Adobe Acrobat Reader 7, Remote Approach started logging views from our IP address. After doing a little research, we found that Adobe's Reader was connecting to http://www.remoteapproach.com/remoteapproach/logging.asp each time we opened the document. The information is submitted over port 80 using HTTP, so it is unlikely that a home or office firewall would, in a normal configuration, block the activity, unless the firewall administrator is attempting to block Web browsing.
Apparently, Remote Approach's "tag" to our document included the addition of JavaScript code causing Acrobat to report back to their server; the information reported includes the fact that the document had been read, our IP address, and which viewer it had been read in. (Interestingly, Remote Approach does not seem to recognize the Linux version of Acrobat Reader, as it left the "User Agent" field blank in its reports.)
What many Linux users may not have realized, since Adobe did not release an Acrobat Reader 6.x for Linux, is that Adobe has added JavaScript support to PDF and the official Acrobat readers since Acrobat 6.x. For those interested in the JavaScript support and its abilities in Acrobat, see Adobe's scripting reference or scripting guide. (Both are PDFs, of course.)
By default, Adobe Reader 7 turns on JavaScript, so the "tagged" document is able to "phone home" without the user's awareness. Turning off JavaScript disables the document's code, and prevents Remote Approach (or any other entity) from tracking views of the document. No doubt, Remote Approach is using features that would normally be used to submit information from a PDF form.
The inclusion of JavaScript in Adobe Reader 7 for Linux no doubt provides a number of welcome features for users, but it also raises some privacy issues. The reader does not inform the user that information is being submitted, so users are likely to be oblivious to the fact that another party is aware of their PDF reading habits. While a user may not find it objectionable to notify the publisher, there are those of us who don't care to allow publishers to snoop on activities taking place on our personal computers.
Lucky for us, there are plenty of
alternatives to Adobe's Reader. Free PDF readers are unlikely to adopt
features allowing the reader to silently phone home in response to code
stored within the document itself. If you must use Acrobat, however, you
may want to have a look at the JavaScript settings first.
| Index entries for this article | |
|---|---|
| GuestArticles | Brockmeier, Joe |
(Log in to post comments)
Thanks for the heads up
Posted Mar 30, 2005 19:53 UTC (Wed) by b7j0c (subscriber, #27559) [Link]
One more reason why open software is so important, little tricks like this come out earlier and easier, no need for forensic analysis (thankfully the author to the time to do the work).
If in fact future open pdf readers want to support JS, it would be nice to be able to disable this feature...I can think of no circumstances in which I feel I need to alert an author to the fact that I have opened their document.
Thanks for the heads up
Posted Mar 30, 2005 21:13 UTC (Wed) by fjf33 (guest, #5768) [Link]
In gentoo it will probably be USE=-javapdf and it won't be compiled in. :)
Thanks for the heads up
Posted Mar 31, 2005 18:54 UTC (Thu) by dberkholz (guest, #23346) [Link]
Acroread is distributed as a precompiled binary.
Thanks for the heads up
Posted Mar 30, 2005 21:53 UTC (Wed) by iabervon (subscriber, #722) [Link]
Ideally, they would support JavaScript, but allow the user to put limits on what it is allowed to do. I could see a use to having a tax form PDF run the calculations as you fill it out, while you wouldn't want to let it make network connections.
Thanks for the heads up
Posted Mar 31, 2005 15:05 UTC (Thu) by gnb (subscriber, #5132) [Link]
I'm not that convinced about the need for Javascript, myself:1) Take a procedural page layout language (PostScript)
2) Hack out the procedural bits so you're just left with the display bits
you need to draw documents and call the result PDF
3) Add in support for a completely unrelated procedural language so
you can have interactive documents
Yes, I know more people can write Javascript than PS, but the whole
thing still seems... icky.
Thanks for the heads up
Posted Mar 31, 2005 17:49 UTC (Thu) by iabervon (subscriber, #722) [Link]
Postscript, even without the procedural bits hacked out, doesn't really have an interaction model. So it would have to be substantially replaced anyway in order to be useful, and then there's still the fact that it's a stack language, which is an obscure class of language.
I suspect that xhtml, xforms, and a spreadsheet-style expression language would apply better to the actual useful applications, but people persist in going for Turing-complete solutions instead of more targetted ones.
Thanks for the heads up
Posted Mar 31, 2005 23:16 UTC (Thu) by gnb (subscriber, #5132) [Link]
>Postscript, even without the procedural bits hacked out, doesn't really> have an interaction model.
There's Display PostScript, which addressed this long before Javascript.
But yes, the point about not really needing a Turing-complete language
in the first place is a good one.
Thanks for the heads up
Posted Mar 31, 2005 23:20 UTC (Thu) by dvdeug (subscriber, #10998) [Link]
A spreadsheet is Turing complete. Most useful forms of computation are Turing-complete; it really doesn't take that much to be, and if you aren't Turing-complete, you very quickly run into problems you want to solve that you can't. Even most Unix "regexs" aren't really computer science regular expressions; they're Turing-complete.
Thanks for the heads up
Posted Mar 31, 2005 23:30 UTC (Thu) by gnb (subscriber, #5132) [Link]
I'm not sure "useful" quite captures it. "Accessible" may be closer:I've had explanations from computer scientists about how to solve a
problem in a language that's more limited, and yes the answer works,
but it usually requires far more cleverness than coming up with a
solution to the same problem in a Turing-complete language. That is, yes
Turing-completeness is often overkill, but it's overkill that makes
solving the problem so much _easier_.
Thanks for the heads up
Posted Apr 1, 2005 14:19 UTC (Fri) by iabervon (subscriber, #722) [Link]
If you require cell references to be acyclic, don't have document-defined functions or don't let them be recursive, and don't have unbounded looping constructs, it's obviously not Turing-complete, because every calculation has to halt. I think this is still sufficient for the applications people will expect to use a form for, assuming the library is satisfactory. I believe that the expectation would be that you have a form such that you could fill it out completely yourself (if you printed it out, for example), but some of the fields depend on other fields, and the software will fill in these fields for you if you fill in the necessary other fields.
Complicated as it is, the US tax code (for example) is written with constraints which make the language of potential tax codes not Turing-complete (not counting things you do to acquire the inputs to the tax code; the process of getting a 1099 from a bank may not terminate, but doing your taxes once you have all the necessary documents will). This is the sort of thing that people would like to automate: forward-only calculations with a finite number of steps and an acyclic inclusion of worksheets.
Thanks for the heads up
Posted Apr 1, 2005 7:02 UTC (Fri) by khim (subscriber, #9252) [Link]
:roll: It's not so easy to develop non-turing-complete system without artificial limits. DVD-Video is not turing-complete, for example. The reason is not obscurity of format but trivial fact that it only has limited number of registers (20 plus some special ones with user-visible effects).
This is turing-complete "langauge"!
Unexpected features in Acrobat 7
Posted Mar 30, 2005 19:55 UTC (Wed) by jbh (guest, #494) [Link]
I tried turning off javascript. But now it pops up a dialog every time I close a window, asking me if I want to turn it back on (and defaulting to "yes"). Very annoying.
(question is, is it more annoying than v5 not responding to keyboard shortcuts when numlock is on? hard to tell)
Unexpected features in Acrobat 7
Posted Mar 30, 2005 20:11 UTC (Wed) by alan (guest, #4018) [Link]
No need to disable javascript completely, just all outgoing traffic to any domain controlled by remoteapproach.
Unexpected features in Acrobat 7
Posted Mar 30, 2005 20:21 UTC (Wed) by mattdm (subscriber, #18) [Link]
Well, except, any given document that wants to track you could use its own site to do so.
Unexpected features in Acrobat 7
Posted Mar 31, 2005 22:29 UTC (Thu) by proski (subscriber, #104) [Link]
Do you have a complete list of domains controlled by remoteapproach?
Unexpected features in Acrobat 7
Posted Apr 1, 2005 17:44 UTC (Fri) by allesfresser (guest, #216) [Link]
Does anyone know if there's a way to control packet flow based on the attributes of the process trying to transmit the packet (i.e., "don't allow Acrobat Reader to send any network packets anywhere?")
Unexpected features in Acrobat 7
Posted Apr 1, 2005 17:45 UTC (Fri) by corbet (editor, #1) [Link]
SELinux can do that sort of thing quite easily. Well, as easily as SELinux does anything, I guess...
Unexpected features in Acrobat 7
Posted Apr 7, 2005 21:07 UTC (Thu) by ekg (guest, #27035) [Link]
iptables -A OUTPUT -m owner --cmd-owner acroread -j DROP
Unexpected features in Acrobat 7
Posted Oct 21, 2005 16:02 UTC (Fri) by toxik (guest, #33244) [Link]
That tid not quite work, perhaps it works for other or you need some extension - I'm not an expert.
Anyhow, the idea is to send all output from the command "acroread" to the DROP chain, which would cause you timeouts, I'd rather just send it to REJECT (-j REJECT) or if you're wondering, why not use a logged chain of your own? :)
Unexpected features in Acrobat 7
Posted Apr 7, 2005 18:30 UTC (Thu) by RelentlessWeevilHowl (guest, #5682) [Link]
Go to $HOME/.adobe/Acrobat/7.0/JavaScripts and remove "glob.settings.js". Create a symbolic link with that name to "/dev/null". That should stop the dialog box.
Unexpected features in Acrobat 7
Posted Mar 30, 2005 21:52 UTC (Wed) by bert.kenward (subscriber, #28573) [Link]
Despite the negative issue here, you might actually consider theusefullness of Javascript in PDFs for things like form filling,
calculations etc. The free PDF viewers have a decent way to go before
supporting the advanced features of PDF like this and presentation modes
and full transparencies, layer support etc.
Unexpected features in Acrobat 7
Posted Mar 31, 2005 4:32 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
I want a PDF viewer. I want to know that the PDF document I view will not try to do anything funny.
See also the discussions regarding the "safe mode" of gs and xdvi.
Who needs Acrobat 7?
Posted Mar 30, 2005 22:03 UTC (Wed) by danielthaler (guest, #24764) [Link]
Now that Kpdf 0.4 which supports multi-page view and selecting text is out (as part of Kde 3.4) I have no reason to want to install Acrobat 7.
Who needs Acrobat 7?
Posted Mar 30, 2005 22:13 UTC (Wed) by bkw1a (subscriber, #4101) [Link]
Now that Kpdf 0.4 which supports multi-page view and selecting text is out (as part of Kde 3.4) I have no reason to want to install Acrobat 7.Will kpdf let you fill in PDF forms? That's the main reason I've been using acroread.
Who needs Acrobat 7?
Posted Mar 30, 2005 22:20 UTC (Wed) by danielthaler (guest, #24764) [Link]
Dont't know, sorry. I don't have any such documents.
Who needs Acrobat 7?
Posted Mar 31, 2005 6:10 UTC (Thu) by coolian (guest, #14818) [Link]
Well, a lot of people do, so keep that in mind.
Who needs Acrobat 7?
Posted Mar 31, 2005 13:43 UTC (Thu) by cpm (guest, #3554) [Link]
Does PDF mean portable document format? Or does it mean Proprietary Deliverable Forms?
If it means the former, then I don' WANT TO FILL OUT FROMS in a
document. I want pdfs to act like pdfs. If it means the latter,
I don't want to play.
pdf, which is an adobe creation, is a cool thing, been around a
long while, and is very useful, as a pdf.
All these "features" speak to me of proprietary vendor lock-in.
I see this as a step in the wrong direction.
If a business vendor requires proprietary software on my behalf,
I find another vendor. If a customer requires proprietary
software on my behalf, that's the beauty of an open market. They
can shop elsewhere. No harm, no foul.
Open business is about open standards.
I don't have much use for the proprietary stuff. I wish folks
wouldn't encourage it.
Word count, proprietary 5
open 3
=============
Who needs Acrobat 7?
Posted Mar 31, 2005 19:03 UTC (Thu) by dw (guest, #12017) [Link]
The PDF specification is an open, backwards compatible standard. It is built upon other open standards, ECMAScript being only one of them. It would take Adobe to turn seriously evil and counter to the existing way PDF has been developed over the years, before they could create lock-in.
Also don't forget that at least one other major PDF renderer exists in the wild that is not controlled by Adobe (AFAIK) - that built into Mac OSX as part of its display/printing subsystem. (Note: I have never used OSX, I'm going from what I read).
If you can stomach the hundreds of pages of specification, the PDF spec is quite an enthralling read. The format is very well designed and specified. +1 to Adobe.
Who needs Acrobat 7?
Posted Mar 31, 2005 22:25 UTC (Thu) by grouch (guest, #27289) [Link]
>It would take Adobe to turn seriously evil [ . . . ]
As in Dmitri Sklyarov being arrested and kept from his family?
HTML supports forms. I have no use for another method of spyware.
Who needs Acrobat 7?
Posted Apr 1, 2005 14:10 UTC (Fri) by ohanssen (guest, #2761) [Link]
My government gives me three alternatives for filling in agiven form, which I regularily need to do.
1) Using a windows only program.
2) Using a pdf form.
3) Filling in a paper form by hand.
BTW, are there internationalised versions of acroread 5 and 7
for linux available? No?
Unexpected features in Acrobat 7
Posted Mar 30, 2005 22:25 UTC (Wed) by dmarti (subscriber, #11625) [Link]
Since this company seems to be using one domain name for all its tracking, the old nameserver trick should work.
Unexpected features in Acrobat 7
Posted Apr 1, 2005 1:10 UTC (Fri) by rickmoen (subscriber, #6943) [Link]
dmarti wrote:Since this company seems to be using one domain name for all its tracking, the old nameserver trick should work.
As chance would have it, Don, I decided my nameserver would be authoritative for remoteapproach.com right about the time you were writing that. ;-)
Rick Moen
rick@linuxmafia.com
Unexpected features in Acrobat 7
Posted Mar 30, 2005 23:09 UTC (Wed) by alangley (guest, #23266) [Link]
Could the author check if this still happens with plugins disabled (see below). acroread 7 has the best text rendering of anything that I've tried and it makes screen reading much nicer. It would be nice if `features' like this could be removed with throwing the baby out too.
Disabling plugins:
% cd acroread7/Reader/intellinux
% mv plug_ins plug_ins_disabled
(Acroread loads much faster without them and there's one called `EScript.api', ECMAScript maybe?)
AGL
Unexpected features in Acrobat 7
Posted Mar 31, 2005 0:03 UTC (Thu) by deatrich (guest, #25) [Link]
I'm betting that your hack does the trick. Without the plug_ins directory the javascript option is no longer visible in the preferences panel, and the application stops asking if you want to re-enable javascript when you exit..
Unexpected features in Acrobat 7
Posted Mar 31, 2005 0:35 UTC (Thu) by lakeland (guest, #1157) [Link]
I find the text rendering in the latest kpdf (0.4) to be equal to that inacrobat. I understand that rendering has now been shifted to a library so
the current CVS version for gnome should function the same. There are
still missing features in kpdf for which I must load acrobat
(rotation being the most obvious), but they're pretty minor. I load
acroread about once a week, kpdf I never even quit.
Unexpected features in Acrobat 7
Posted Mar 31, 2005 10:44 UTC (Thu) by nedrichards (subscriber, #23295) [Link]
Yep, it's called Poppler, these sort of cross DE libraries are an unequivocal good.
Unexpected features in Acrobat 7
Posted Mar 31, 2005 15:48 UTC (Thu) by eru (subscriber, #2753) [Link]
But an unfortunate name choice: soon the Futurama makers will sue for some kind of IP infringement... (just kidding - I hope they remember their own "Simpsons" episode that nicely parodied that kind of lawyering)
Unexpected features in Acrobat 7
Posted Apr 12, 2005 15:43 UTC (Tue) by mudd1 (guest, #29227) [Link]
You don't have to move all plug-ins aside. A list follows for those Plug-ins that are necessary to make Acrobat Reader start up without complaining about unmatched dependencies:
Accessibility.acroplugin
AcroForm.acroplugin
Checkers.acroplugin
Comments.acroplugin
DigSig.acroplugin
EScript.acroplugin
ImageViewer.acroplugin
LegalPDF.acroplugin
Multimedia.acroplugin
PPKLite.acroplugin
SOAP.acroplugin
Spelling.acroplugin
Updater.acroplugin
WebLink.acroplugin
Dunno what they do but we'll see. JavaScript is off after renaming these directories. I did this on Mac OS X BTW, the names may differ for Linux. In Mac OS you'll find these directories in Contents/Plug-ins/ in the .app directory. Good Luck,
Christian
Unexpected features in Acrobat 7
Posted Jun 16, 2005 10:47 UTC (Thu) by mudd1 (guest, #29227) [Link]
> A list follows for those Plug-ins that are necessary to make Acrobat Reader start up without complaining
Well, that is capable of being misunderstood. It's the list of those plug-ins that must be *removed* to disable the scripting capabilities while keeping Acrobat silent. You can remove more but you can't remove less without making Acrobat really annoying.
Unexpected features in Acrobat 7
Posted Mar 30, 2005 23:17 UTC (Wed) by mwalls (guest, #6268) [Link]
As far as tracking document usage, why not just set the proxy settingsin Acroreader to a totally bogus proxy server, so it can't connect to the
net.
Unexpected features in Acrobat 7
Posted Apr 12, 2005 9:38 UTC (Tue) by norbusan (guest, #10100) [Link]
I like this option, great. THis way I can activate HTML access if necessary very fast, and stupid Acroread don't ask me. I checked that with bogus proxy settings (in fact localhost:1080) and the iptables rules I see a connect which immediate terminats. Good.
Thanks for the suggestion!
Unexpected features in Acrobat 7
Posted Mar 30, 2005 23:39 UTC (Wed) by yodermk (guest, #3803) [Link]
Ok, how is this different in principle from, say, web server logs?
/me feels a sudden urge to get rid of his Internet connection for fear that web site authors could realize he is viewing their content....
Differences from server logs
Posted Mar 30, 2005 23:47 UTC (Wed) by corbet (editor, #1) [Link]
How about this: web server logs don't track when you read a file that somebody emailed to you?
Differences from server logs
Posted Mar 31, 2005 4:07 UTC (Thu) by yodermk (guest, #3803) [Link]
But they would track it if a web page link were emailed to a friend and he clicked it.
Sure, this behavior might be unexpected, but I don't see any reason to panic. There are much more interesting things to worry about. Plus, is it really wrong for a content author to know a bit about how far their content has spread? In nearly all cases, an IP address doesn't tell much about you.
Then, maybe I just don't understand some of the privacy advocates. The fact of our economy is such that unless you decide to be a hermit, some aggregate information is going to be collected about you. In reality, why does that matter? I don't feel like I have any reason to care that my credit card company knows I've recently ordered from Newegg and Reasons to Believe, and flown LanPeru. Are they going to hunt me down to do Bad Things to me? Worst case scenario, I might get more ads of some sort as a result, but they just might be targetted and are easy to ignore.
Now, when someone installs a videocamera in my house, there's reason to be concerned....
Differences from server logs
Posted Mar 31, 2005 4:35 UTC (Thu) by ronaldcole (guest, #1462) [Link]
How long until all these "I read your docs" acks displace bittorrent as the Internet Bandwidth Hog (tm)?
Sometimes you really don't want the author to know...
Posted Mar 31, 2005 8:50 UTC (Thu) by eru (subscriber, #2753) [Link]
Plus, is it really wrong for a content author to know a bit about how far their content has spread? In nearly all cases, an IP address doesn't tell much about you.Try this skenario: Whistleblower at a Big Corrupt Corporation mails law enforcement officials an internal PDF document exposing illegal activities by the top management. Unfortunately the PDF was tracked and the Law Enforcer just naively opens it with Acrobat, thus alerting the corrupt management to the investigation, and giving them a head start with the paper shredders...
For a long time I thought of PDFs as just a kind of digital paper. Too bad they have now endowed it with capabilities to perform surprising activities when the document is merely read. We really need an electronic docment format that is guaranteed to be "inert". I guess plain ASCII is left, but something with richer formatting capabilities would also be nice.
Sometimes you really don't want the author to know...
Posted Mar 31, 2005 14:52 UTC (Thu) by cpm (guest, #3554) [Link]
If I want the author to know, I can email, call, write, them andtell them.
If I don't, or more to the point, don't care, then I don't. It shouldn't
be a mandatory, or opt-out (why is this in contemporary parlance, is
it the spam issues and the spam laws? yes!) issue.
A PDF *should* be an electronic document. Nothing more.
It can be copied, messed with, forged, and all that rot. To add all these
bells and whistles to it, to fend off these old-as-the-written-word
issues with "documents" (What is a document anyway?*) is to create
yet-still-another legal morass of so-called "Intellectual Property"
disputes.
It's a PDF. Once it has been printed, it's as good as the paper it's
printed on. Want to have some assurance that its "real" ? wrap it
in gpg/pgp before you send it.
Oh, yes, many will say that using decent crypto/signature is too much
bother, and they are right. But everything else is often simple
to break/ignore/circumvent etcetera.
Sometimes you really don't want the author to know...
Posted Mar 31, 2005 17:28 UTC (Thu) by juha (subscriber, #5866) [Link]
> A PDF *should* be an electronic document. Nothing more.
Is it possible to create a filter program to remove these extra features from the .pdf file?
Javascript page bugs
Posted Mar 31, 2005 9:13 UTC (Thu) by rwmj (subscriber, #5474) [Link]
Actually, it's no different from Javascript page bugs, which areroutinely embedded in HTML files. Dozens of web analytics companies
(Web Trends, Urchin and Nedstat are the "big three") do this sort
of monitoring, precisely so that web page views can be tracked when
the HTML is sent by email or saved to disk.
While there are undesirable possibilities to this, in probably 99.9999%
of cases the stats are simply used for aggregate tracking for
building up marketing stats which few people in marketing even
read, let alone understand.
Rich.
Javascript page bugs
Posted Mar 31, 2005 16:51 UTC (Thu) by martinfick (subscriber, #4455) [Link]
"Actually, it's no different from Javascript page bugs"You are correct, that doesn't mean that they don't suck.
Html is bad for email:
http://www.avernus.com/~gadams/essays/20020418-html-mail....
Javascript page bugs
Posted Mar 31, 2005 16:58 UTC (Thu) by rwmj (subscriber, #5474) [Link]
Sure, HTML is bad for email.
_I_ know that, and _you_ know that, but the huge majority
of the unwashed LookOut-using users send each other top-posted
HTML-encoded web pages all the time.
Marketing people want to track this. They perceive (correctly)
that their statistics will contain a systematic bias if they
are not able to track when their web pages are emailed, read
offline, saved to disk, and so on. They are probably not clueful
enough to deduce useful information from the aggregate data,
but that doesn't mean there is some conspiracy going on here.
Rich.
Javascript page bugs
Posted Apr 3, 2005 23:00 UTC (Sun) by error27 (subscriber, #8346) [Link]
Say a website has a bug in it. That's fine. They already have that info but the web bug is an easier way to sort it. It's their computer so they can do what they want.
If there is a bug in your email or PDF that's a different story. Most email clients are good and don't allow spying. I use Yahoo, Gmail and pine and all three are secure.
My computer is my property and it should only serve me. It's like Adobe is run by some kind of hippies who don't believe in property. "We'll just waltz into the house that you paid for and raid the fridge and leave flowers strewn on the carpet."
Perhaps I sound like a Republican but people like this should be thrown in jail.
Javascript page bugs
Posted Apr 12, 2005 15:35 UTC (Tue) by gvy (guest, #11981) [Link]
Pine's buggy, not secure. It could lead to even worse consequences.
As our security officer has put it, "one specially crafted message was enough reason for me to drop Pine". He's using Mutt now, me too (for being programmable, but that's another matter).
Telling they're insecure doesn't make us more secure per se... even if it's not exactly technical security.
Why a Linux 7.x release now?
Posted Mar 31, 2005 7:35 UTC (Thu) by mepr (guest, #4819) [Link]
I think it is that oss pdf reader development is starting to make big time headway, and they want to get back in the market before they're left behind. This is the year of the desktop :-P.The main thing is copy/paste for text, but evince's rendering, search interface, and etc., are beautiful. It, for the first time ever, makes reading PDFs a pleasure. It probably uses some of the same backend as Kpdf, I guess. What if Kpdf and Evince are ported to windows and Scribus effectively catches up with or surpasses the pay-for acrobat version? Hmmmm
Unexpected features in Acrobat 7
Posted Mar 31, 2005 8:43 UTC (Thu) by tousavelo (guest, #27022) [Link]
Looking forward to check the visual quality of these new tools. Among the tools shipped with this fall series of distro, I couldn't find one but Adobe's that had decent rendering in my eyes.
Unexpected features in Acrobat 7
Posted Apr 1, 2005 4:05 UTC (Fri) by rro (guest, #5155) [Link]
I'm running privoxy, an Internet proxy filtering application. It is lighter-weight than squid, since all I wanted to do is block advertisements in web pages. However, I believe it may have the capability for telling my Linux system not to communicate with remoteapproach.com. Wouldn't that accomplish the feedback blocking from Acrobat Reader 7 without disabling JavaScript (repeatedly)? Privoxy runs on Linux, OS X and Windows, so it may be a fine solution for all these platforms, and maybe I could rein in Acrobat Reader 7 on my OS X systems too.
Anyone know the privoxy configuration change to put this into place?
General problem needs a general solution
Posted Apr 1, 2005 14:39 UTC (Fri) by kevinbsmith (guest, #4778) [Link]
Even if your proxy does block RemoteApproach itself, it won't block other similar "attacks". RemoteApproach could register a new domain every month. Competitors may spring up. Someone may create a tool that allows PDF authors to embed tracking that goes to an arbitrary site of the author's choosing.
Since the javascript plugin is a general tool, it is best blocked with a general approach.
I don't use acroread myself, but I will recommend to my friends that they disable acroread plugins entirely (as described in posts above), at least as a starting point. I wonder what other privacy and/or security vulnerabilities lurk within those (closed source) plugins.
Unexpected features in Acrobat 7
Posted Apr 1, 2005 15:57 UTC (Fri) by dps (guest, #5725) [Link]
Given the limited avialabilkity of IP space I would expect that remote approach, and most of the rest of the world, have very limited room of manover their box's IP address. An IP tables output rule, or equivalent controls on a separate firewall, would suffice to stop documents calling home.
In my office it would be sufficient not to mention the (squid) web proxy to acroread, so it tries to send the HTTP request directly. This will not work because the firewall's default is deny and only the proxy has permission to get out to port 80 (and 443). Port 25 and 53 are limited to professional name and mail servers.
I suspect that some other spyware might not work on my office's network too. Nobody has asked me to "fix" that yet :-)
Unexpected features in Acrobat 7
Posted Apr 2, 2005 19:33 UTC (Sat) by dale (subscriber, #4068) [Link]
Perhaps something akin to the following for iptables filtering?iptables -A OUTPUT -o eth0 -p tcp -m owner --cmd-owner acroread -j REJECT --reject-with tcp-reset
Since I don't have a PDF document with Javascript "web bug" in it, I tested the above with wget instead of acroread and it seems to work OK. Rejection with tcp-reset seems to avoid a several second delay that occurs with the default rejection method of ICMP port-unreachable.
Javascript *is* supported in Acroread 5 for Linux
Posted Apr 7, 2005 23:22 UTC (Thu) by CJF (guest, #16403) [Link]
This article is misleading; Javascript has been supported by Linux versions of acroread/acrobat for some time, including version 5 of acroread for Linux (in fact, on all platforms). I understand there was even some support for Javascript in version 4 (although I stand to be corrected on that). The support in version 5 includes passing information to a web server, e.g. posting the contents of a completed PDF form/questionnaire. [Perhaps the only difference in version 7 is whether or not some user action is required to invoke a transaction?]
I have developed interactive multiple choice quizzes in a LaTeX-based system that are rendered as PDFs with embedded Javascript. The users answers are marked, and model solutions can be given. This works fine with version 5 of acroread under Linux.
Given the poor support for portable, high-quality mathematical notation in HTML/MathML, this is unfortunately one of the least-bad ways of producing reasonably platform-neutral distance learning material involving mathematical notation, using free tools. It would be much nicer if there was a free viewer that supported Javascript in PDFs, and better still if there was good platform-neutral support for mathematical notation and interactive quizzezs etc in HTML documents (or some other open standard that supported appropriate sandboxing). This would have the potential of being more accessible for sight-impaired users than is mathemtics in PDF.
I did try to hack latex2html to support interactive quizzes, but it was too painful, and I was continually fighting Microsoft's poor and inconsistent interpretation of CSS, and Mozilla/Firefox's buggy handling of vertical alignment specifications (it seems they copied a bug from earlier versions of Microsoft IE, presumably to mimic IE's misbehaviour, despite the fact that this fault is corrected in more recent versions of IE). Acrotex isn't perfect, but I refuse to use MM Flash and platform-specific font-encoding hacks.
How to turn off AllowOpenFile?
Posted May 11, 2005 23:25 UTC (Wed) by psz (guest, #29877) [Link]
I can turn JS off (Edit Preferences JavaScript), and see the setting infile $HOME/.adobe/Acrobat/7.0/Preferences/reader_prefs . However (on
Debian sarge) the page where I think I could turn off AllowOpenFile
(Edit Preferences TrustManager) is curiously blank.
Does anyone know how to control AllowOpenFile (and multimedia stuff)?
(Would prefer instructions on how to set/seed reader_prefs or whatever
file, rather than getting the GUI to work...)
Unexpected features in Acrobat 7
Posted Jan 28, 2006 17:45 UTC (Sat) by untrammelled (guest, #35548) [Link]
Debian users may be OK if they install the unofficial packages at ftp://ftp.nerim.net/debian-marillat/. The acroread package installs acroread itself, while acroread-plugins installs the javascript functionality. You can enable/disable the javascript feature just by installing/uninstalling the acroread-plugin.
Unexpected features in Acrobat 7
Posted May 8, 2008 2:49 UTC (Thu) by Blazer (guest, #51948) [Link]
"Ok, how is this different in principle from, say, web server logs?" Consider if you put a resume online in PDF format that contained code to phone home to you...now your malicious javascript is potentially executing on the machines of people who view your resume. Consider some javascript code that reads or creates files on your hard drive, and optionally sends results to some other server. Without any notice to the user. I think its obvious that it has the potential to be a lot more invasive than a web server logging a hit that you specifically requested. I don't care if google logs that I went to a gmail URL. I do care however, if I open a document and it runs unknown code and sends information to a third party without permission or notice.