Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Aren't most use-cases covered already ?
I've been using Evince for years now. Haven't had a PDF it couldn't read in the last 3 years or so.
The last couple of months I've even had pdf.js in Firefox handle all the PDF's I view when surfing the web. For such a new project, I've had very little which it couldn't handle almost perfectly.
So the only use case that remains is PDF-forms. Where you get a PDF which has a enbedded form.
Something which I've not encountered on my home-desktop machine ever so I don't have Adobe Reader installed.
So how many users of Adobe Reader on Linux could there be ?
So which/how many users use Adobe Reader on Linux ?
Posted Aug 16, 2012 20:07 UTC (Thu) by tnoo (subscriber, #20427)
Posted Aug 16, 2012 20:11 UTC (Thu) by Lennie (subscriber, #49641)
Do you encounter them on a regular basis ?
Posted Aug 16, 2012 20:32 UTC (Thu) by sfeam (subscriber, #2841)
Posted Aug 16, 2012 20:55 UTC (Thu) by Lennie (subscriber, #49641)
I didn't know they did that in the US. I knew my government was probably pretty unique anyway.
My government has a program people can download from their website so people can do their taxes.
I haven't done my own taxes the last couple of years, but this program used to be based on some open source components (there was at least a license file which made that very clear) and it was thus available for Windows, Mac and Linux (I wouldn't be surprised if you could run the Linux program on BSD with Linux emulation as well).
You could print the result or submit it over the Internet.
I just downloaded the one for 2011 and it seems to be mostly a bunch of HTML-files with a program around it (it also has a license file which says it used LGPL software) and it is still available for Windows, Mac and Linux.
Posted Aug 17, 2012 13:24 UTC (Fri) by drag (subscriber, #31333)
> My government has a program people can download from their website so people can do their taxes.
How it works for USA federal government is that if your filing 1040 EZ, which means that you are probably renting your house and have relatively low income. If you do that then there is a number of tax prep software you can download or use online free of charge that are from corporations.
If your a using itemized deductions and/or have investments and higher income to support then you have to use the 1040 form, which means that you can use the same applications as 1040ez, but you have to pay for them.
Probably about half the people I know use accountants. Certified public accountants and their assistants helping average people prepare taxes is a very large business.
There were a couple open source software written for it. I used one of those one year actually and it worked quite well.
Nowadays I just use online version from one of the tax software companies.
Posted Aug 17, 2012 20:04 UTC (Fri) by Per_Bothner (subscriber, #7375)
Actually, taxact.com provides free Federal online fill-in, printing, and e-file. I've been using it the last few years, partly because I can use it without booting into Windows! Fairly full set of forms. You do have to pay for state (but if you're a cheap-skate doing state forms by hand isn't as painful as Federal).
On a related topic: California Tax Franchise Board offers forms you can fill-in and print - but not save because the forms don't have the correct "permisisons". Of course that only applies to Acrobat - Evince will happily save the forms for you. Another win for Free Software!
Posted Aug 16, 2012 21:41 UTC (Thu) by pjtait (subscriber, #17475)
Posted Aug 16, 2012 23:32 UTC (Thu) by shmerl (guest, #65921)
Posted Aug 16, 2012 23:39 UTC (Thu) by sfeam (subscriber, #2841)
Posted Aug 17, 2012 0:07 UTC (Fri) by shmerl (guest, #65921)
Posted Aug 17, 2012 3:33 UTC (Fri) by wagner17 (subscriber, #5580)
Posted Aug 20, 2012 8:53 UTC (Mon) by fb (subscriber, #53265)
Perhaps some KDE file managers are smart enough to move the metadata, but a normal shell "cp here/doc.pdf there" will certainly not.
Really a great thing to discover when you are emaling your PDFs back to your lawyer close to the tax submission deadlines.
Posted Aug 20, 2012 11:44 UTC (Mon) by hummassa (subscriber, #307)
Posted Aug 17, 2012 2:22 UTC (Fri) by pabs (subscriber, #43278)
Posted Aug 17, 2012 19:59 UTC (Fri) by daniel (subscriber, #3181)
Posted Aug 22, 2012 9:07 UTC (Wed) by tnoo (subscriber, #20427)
Posted Aug 17, 2012 11:40 UTC (Fri) by RobSeace (subscriber, #4435)
Do people still buy the boxed retail TurboTax software and run it anymore? I've been using the all-online TurboTax web interface every year since 1998, and always from a Linux-based web browser... For a while, they were checking User-Agent, and not letting you in unless you changed it to lie to them about what OS you were on... But, everything worked fine once you actually get in! But, they thankfully stopped that stupid practice some years ago, and now merely put up a scary warning at the start that you appear to be on an unsupported system, but give you the option of continuing on anyway...
Posted Aug 17, 2012 21:36 UTC (Fri) by jreiser (subscriber, #11027)
Yes, and I file by printing paper, then physical post.
I've been using the all-online TurboTax web interface ...
You've been feeding the targeted marketing trolls, or at least Intuit's captive ones. All your tax data is kept forever by Intuit, and used to make money by sending you advertisements based on that data: age, gender, filing status, number and age of dependents, filing (residence) address, amount and kind of income, specific employers, specific dividend payers, amount and kind of deductions, amount and kind of tax credits, amount of refund, history of any category over multiple years, etc. Advertisers deliver the content and desired profile to Intuit. Intuit matches you against the profile, prints and applies the address label (or logical equivalent) to the content, and sends the ads. Your tax data never leaves Intuit [except of course when Intuit forwards it to the IRS or sends it back to you over SSL], but it is used for a lot more than just being forwarded to the IRS (or being held for your "convenience" in filing an amended return, defending an audit, etc.)
Posted Aug 17, 2012 22:12 UTC (Fri) by RobSeace (subscriber, #4435)
Ads? I've been running AdBlock Plus for ages...
Google also revolves around ads, but that doesn't stop me from using their products... If people want to send me ads I'll never see because they're blocked, let them... If it makes Google/Intuit money, and loses the advertisers money, so much the better!
Posted Aug 18, 2012 1:25 UTC (Sat) by hummassa (subscriber, #307)
Posted Aug 16, 2012 21:02 UTC (Thu) by dmitrij.ledkov (subscriber, #63320)
Posted Aug 16, 2012 21:05 UTC (Thu) by josh (subscriber, #17465)
Posted Aug 17, 2012 10:54 UTC (Fri) by Lennie (subscriber, #49641)
Posted Aug 19, 2012 19:32 UTC (Sun) by mathstuf (subscriber, #69389)
Posted Aug 17, 2012 12:25 UTC (Fri) by Wol (guest, #4433)
But I run gentoo, so I'm always up-to-date, except when there's a dependency screw-up with poppler :-)
That's really the only downside - anything goes wrong with poppler, and pdf support is completely screwed until I fix the mess.
Posted Aug 20, 2012 4:13 UTC (Mon) by tnoo (subscriber, #20427)
Posted Aug 16, 2012 23:08 UTC (Thu) by JoeBuck (subscriber, #2330)
The evince developers should use the IRS tax forms as test data and for regressions; they are freely redistributable (not subject to copyright if I understand correctly as a US government work).
Posted Aug 16, 2012 23:38 UTC (Thu) by josh (subscriber, #17465)
DRM'd/locked forms don't save
Posted Aug 16, 2012 23:39 UTC (Thu) by jjs (guest, #10315)
Posted Aug 17, 2012 0:08 UTC (Fri) by shmerl (guest, #65921)
not subject to copyright as a US Government work
Posted Aug 17, 2012 12:29 UTC (Fri) by Wol (guest, #4433)
As per, however, the US law implementing copyright, the US government cannot ENFORCE that copyright, within the US at least.
So, if you're an American, it's a distinction without a difference :-)
Posted Aug 16, 2012 21:39 UTC (Thu) by ay (guest, #79347)
Posted Aug 17, 2012 8:18 UTC (Fri) by epa (subscriber, #39769)
Posted Aug 17, 2012 9:06 UTC (Fri) by zdzichu (subscriber, #17118)
Posted Aug 17, 2012 17:13 UTC (Fri) by thedevil (subscriber, #32913)
But the UI is terrible.
Posted Aug 17, 2012 20:51 UTC (Fri) by khim (subscriber, #9252)
So how many users of Adobe Reader on Linux could there be ?
Good point. If you'll recall that security-wise evince is worse then Adobe Reader and there are more users of evince in general... it's not clear what the hoopla is all about.
Posted Aug 19, 2012 7:29 UTC (Sun) by gmatht (guest, #58961)
Or perhaps Softbound.
Posted Aug 19, 2012 13:16 UTC (Sun) by gmatht (guest, #58961)
Posted Aug 19, 2012 21:23 UTC (Sun) by cmccabe (guest, #60281)
I still think that a seccomp-based solution would be the way to go. Similar to what Google did with Webkit in Chrome. That would not require SELinux to be enabled (it's not available on my current distribution) and would be a true upstream solution.
Posted Aug 27, 2012 21:07 UTC (Mon) by idupree (subscriber, #71169)
Posted Sep 1, 2012 3:49 UTC (Sat) by cmccabe (guest, #60281)
Um, displaying content is not an exploit. Or if it is, the only secure PDF decoder is /dev/null.
I don't need to be a hacker to give you a PDF that displays a silly doodle. I can just create a pdf that embeds a silly doodle.
Posted Sep 1, 2012 15:06 UTC (Sat) by bronson (subscriber, #4806)
Just because an exploit is a silly doodle, that doesn't mean we can just ignore the exploit vector.
Posted Sep 1, 2012 18:21 UTC (Sat) by cmccabe (guest, #60281)
If we did something similar for PDF readers, all a bug in the PDF rendering code could do is change the way the PDF looks-- which is not an exploit.
Posted Sep 3, 2012 10:36 UTC (Mon) by ekj (guest, #1524)
HTML-injection-attacks can become interesting if a bug in the rendering means that you can affect the looks of a part of the page which you're not supposed to be able to affect.
Let's say you're allowed to enter plain-text but that <strong>-tags are allowed and preserved. If a bug in the rendering means that the user is able to affect not only how his comment is rendered, but also some other arbitrary part of the page, then that is a potential security-problem.
The assumption that the entire html-string being rendered is from *one* source, and thus that it's always a noninteresting bug that one part of that string can affect other parts of that string, isn't valid. It's *incredibly* common for websites today to output HTML where parts of the HTML are strings entered by users. (sanitized to varying degrees)
Posted Sep 5, 2012 3:10 UTC (Wed) by cmccabe (guest, #60281)
However, taking this to its logical conclusion leads to a kind of reductio ad absurdum: any bad behavior could be exploited by someone, therefore all bad behaviors are security bugs. Therefore the only way to get secure software is to run only bug-free software-- i.e., no software.
In the real world, we accept that deleting your files and p0wning your home directory is a heck of a lot more interesting than changing the bold tag on something outside your IFRAME. The former could be used for industrial espionage. The latter will just lead to someone navigating away from your site, because it "looks weird."
Posted Sep 5, 2012 8:36 UTC (Wed) by ekj (guest, #1524)
HTML-rendering-engines live in a world where a common use for them, is to render a string of HTML where different parts of the string comes from different entities which you trust to differing degrees. LWN itself is an example of this, the text you're reading right now is a string entered by me, while the layout and rest of the window is markup and text made by LWN.
This is the reality of the situation. The same isn't true for (say) an image-viewer. It's not, infact, common to be viewing a jpg-image where the pixels in a certain part of the picture are created by one entity, and the pixels elsewhere by another entity. If it was, then yes, the situation would be parallell.
Often it doesn't matter. But sometimes it matters very much indeed. If I pay a bill by net-bank, I can enter a string that is displayed (in the net-bank) to the person receiving the payment. If it was possible for me to enter a string that would, for example, change what the recipient sees in the "amount" field, not merely the "comment"-field, that'd be a major problem.
Yes, they sanitize the strings (allow only [a-zA-Z 0-9]). This reduces the attack-surface, and makes sense. But the basic principle of the attack remains: bugs in the rendering-engine may make one part of the string able to affect other parts which it shouldn't by the standard, such bugs are security-bugs.
Yes that means many bugs in rendering untrusted content are security-bugs. A bug in OpenOffice that somehow causes what is displayed on screen (for a specially crafted document) to differ from what is printed, is a security-bug. (imagine what would happen if someone read a contract on-screen, then printed and signed the paper-copy without validating that the paper-contract match the on-screen contract)
Posted Sep 6, 2012 0:24 UTC (Thu) by cmccabe (guest, #60281)
As far as HTML goes, sandboxing the HTML rendering thread is an important step towards shutting down browser-based attacks. At the end of the day, perfect security is impossible-- yes, even in Java. However, additional layers of security can add to your confidence level. BTW, if you haven't read "reflections on trusting trust," you should check that out.
Posted Aug 18, 2012 12:29 UTC (Sat) by spaetz (subscriber, #32870)
I know, one can blame the original pdf creator apps, but often that is out of your control....
Posted Aug 29, 2012 8:17 UTC (Wed) by Tet (subscriber, #5433)
Me. There are no alternatives. For daily use, xpdf works fine. But when I need to send a book to a printer, I have to proof it with Acroread first. It's what the printer uses, and it's no use turning round after it's printed incorrectly and saying "well it looked fine to me in xpdf/evince/whatever". The fact is that none of them are pixel for pixel identical to Acroread (usually gradient fills are wrong, for example). If I want to see what my final printed output will look like, Acroread is the only option. Ideally, I'd be able to check it through a Fiery RIP too, but that's not an option.
Posted Aug 29, 2012 10:28 UTC (Wed) by ssam (subscriber, #46587)
I'd say I hit a couple per year. of course they are not evince bugs, so the evince devs just bounce them off to the poppler bug tracker.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds