Detailing the Security Risks In PDF Standard 136
crabel writes with this quote from the H Online:
"At the 27th Chaos Communication Congress in Berlin security researcher Julia Wolf pointed out numerous, previously hardly known security problems in connection with Adobe's PDF standard. For instance, a PDF can reportedly contain a database scanner that becomes active and scans a network when the document is printed on a network printer. Wolf said that the document format is also full of other surprises. For example, it is reportedly possible to write PDFs which display different content in different operating systems, browsers or PDF readers — or even depending on a computer's language settings."
Abomination (Score:4, Funny)
"Wolf said that the document format is also full of other surprises. For example, it is reportedly possible to write PDFs which display different content in different operating systems, browsers or PDF readers -- or even depending on a computer's language settings."
Amazing -- totally unbelievable!! This should be wholly forbidden. Who would want to read documentation that knew what system you were running, or what language you could read, and tailored the display to make it more relevant to you? Text files don't let you do these things! Adobe is clearly going too far.
Re:Abomination (Score:4, Funny)
i18n is the work of the [devil|diablo|Teufel], clearly.
Rgds
Damon
Re:Abomination (Score:5, Insightful)
It's not that internationalization is the work of the devil, but rather that it should happen at a higher level than an individual PDF. Allowing different content to be displayed in different language environments raises serious questions about document integrity: imagine a international contract PDF that displayed one payment for German users and another for French ones.
PDF-the-document-format is a good thing in that it allows perfect reproduction of a printed document anywhere. PDF-the-generic-container, on the other hand, is both frightening and of dubious utility, but I can see why Adobe might have a business case for trying to drive this approach anyway. This is why we can't have nice things.
Re: (Score:2, Informative)
So this higher level is going to have fully automated language translation to guarantee the precise meaning of the contract is the same in every language? I think anyone expecting a computer solution to that with current technology is going to be disappointed. If I send 20 text files, one in English, one in French, one in German etc. believe it or not I can still put different stuff in each.
The real problem I suspect here is that the reporting of what was said is not reflecting the actual problems perceived
Re: (Score:2, Informative)
A recording of the presentation will soon appear here [ftp.ccc.de] and should answer your request for more details.
Re: (Score:2)
No, the higher level is going to be an archive file with multiple PDFs and a manifest giving you the details of what is for whom. But then, you purposely misunderstand, I suspect.
Re: (Score:2)
I don't see how that's better. If I always open the English documentation anyway, what's wrong with my computer picking it automatically?
Re: (Score:2)
For example, it is reportedly possible to write PDFs which display different content in different operating systems, browsers or PDF readers -- or even depending on a computer's language settings.
Notice that if this was automatic, it would be well-known already. What it sounds like is that you can write a document in several languages (or for different PDF readers if you want) and have the reader's computer decide the correct one to show.
So, there might be multiple versions, but the author would be aware of all of them.
Re: (Score:2)
In fact, assuming that differences existed, being able to examine a single, signed file and determine that they were placed in there is probably more convenient than having to examine multiple files. Of course, you could distribute those multiple files in a signed archive, but that's basically what the PDF has become at this point.
Re: (Score:2)
You might imagine valid uses for flexible documents that adapt to the environment they're read on, but if you don't realize that these documents have these flexible/adaptive features, then there is indeed some potential for nasty surprises.
There are already a lot of weird myths about pdfs (e.g. I've heard they're better for contracts than docs because "pdfs can't be edited"). This is, at the very least, pointing out yet another misconception.
Re:Abomination (Score:5, Funny)
What a great feature!
Everyone will get invited to the our next office party, but the Windows users will read that they are to come in clown costumes.
Re:Abomination (Score:4, Funny)
What a great feature!
Everyone will get invited to the our next office party, but the Windows users will read that they are to come in clown costumes.
It's hard to know whether this should be modded Funny or Insightful, because it's both. And that is precisely what makes these PDF "features" so disturbing.
Re: (Score:3, Insightful)
Excuse me, but a document format used for storing printed documents on a system should represent the document as if it was printed when viewed again, _not_ suddenly switch the language or layout or whatever.
If it were to display _different content_, as alleged, that would disqualify it from being able to be used for archival of government documents.
Re:Abomination (Score:5, Informative)
> Excuse me, but a document format used for storing printed documents on a system should represent the document as if it was printed when viewed again, _not_ suddenly switch the language or layout or whatever.
It sounds like what you want is PDF/A ( http://en.wikipedia.org/wiki/PDF/A [wikipedia.org] ), which restricts the PDF to a simple non-scripted document. The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format. DjVu ( http://djvu.org/ [djvu.org] ) I believe would also be a good fit.
For example, we're looking at taking in student essays in PDF, attaching a form to the front that marks can be entered into, and the whole document returned to the submission system that then pulls the mark out (as opposed to having to track the mark independently of the material it applies to). I've seen presentations run from a PDF before. It would be a pity to lose these possibilities.
Re: (Score:3)
The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format.
That was its sole intent when it was created, and for several years afterward. Rudimentary javascript support wasn't added until 1996. Audio / video embedding is a much more recent addition (2008 or so). See here [wikipedia.org].
Re: (Score:2)
Ehm, can you please point out where on the page you link to does it say that the sole intent of pdf format was originally to produce printed documents? I don't seem to be able to find that.
Re: (Score:2)
You can always go read the PDF 1.0 specification, which is what I did, in 1993 or so. Of course no one was promoting the idea that you had to reduce the documents to hard copy. Acrobat Reader would be pretty useless if that was the case.
Re: (Score:2)
I cannot find pdf 1.0 specification online, but I did find pdf 1.2 from 1996, and it describes the purpose of the format as "to enable users to easily and reliably exchange and view electronic documents independent of the environment in which they were created." It says nothing about hardcopy, and it specifically talks about "electronic documents", without further specifying what these are. It also says that "PDF also includes objects, such as annotations and hypertext links, that are not part of the page
Re: (Score:2)
I misspoke when I said "printed documents". I should have said something like "print-ready page oriented documents". Form support was bolted on three years later, and the sort of forms that PDF was good at were "print ready page oriented documents", like IRS tax forms, for example.
It is not a mistake that audio, video, and Flash support didn't come to PDF for twelve years after that. That is not what the creators had in mind, or at least not what they expended any actual effort implementing. What they
Re: (Score:2)
I agree with you on the difference between pdf and html. Thus the need for a format that is page oriented, allows us to deliver document in a typographical quality, but allows interactive content. Pdf tries to do that.
Javascript came to pdf in 2000, the same year as prepress support. Does it mean that pdf document were never meant to be seriously printed in high quality, since it took 7 years to introduce prepress support?
Re: (Score:2)
No, for two reasons. (1) For most common applications PDF was high quality (2) PDF was based on a technology designed for typesetting from the very beginning. Adding the tweaks necessary for pre-press is a minor change.
Javascript support and interactivity was not, evidenced in part by the fact that dynamic PDF documents are incredibly rare. The whole tool chain used to produce most PDFs has no support whatsoever for automating them.
For the record, I think embedding audio and video clips is a worthwhile ex
Re: (Score:2)
Yeah, I went away and read the 1.2 spec. Hadn't realised how much stuff they added later to PDF. I suspect a lot of the problems are that it's been substantially over-expanded since original design.
Re: (Score:3)
For example, we're looking at taking in student essays in PDF, attaching a form to the front that marks can be entered into, and the whole document returned to the submission system that then pulls the mark out (as opposed to having to track the mark independently of the material it applies to).
That's ripe for a hack. A smart kid will come up with code he can add to his PDF at submission that will identify the form and change the mark to a higher grade and then, if he's really clever, rewrite the PDF to delete any sign of the grade changing code.
Re:Abomination (Score:4, Interesting)
> Excuse me, but a document format used for storing printed documents on a system should represent the document as if it was printed when viewed again, _not_ suddenly switch the language or layout or whatever.
It sounds like what you want is PDF/A ( http://en.wikipedia.org/wiki/PDF/A [wikipedia.org] ), which restricts the PDF to a simple non-scripted document. The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format. DjVu ( http://djvu.org/ [djvu.org] ) I believe would also be a good fit.
For example, we're looking at taking in student essays in PDF, attaching a form to the front that marks can be entered into, and the whole document returned to the submission system that then pulls the mark out (as opposed to having to track the mark independently of the material it applies to). I've seen presentations run from a PDF before. It would be a pity to lose these possibilities.
Everything in your post makes sense, but now let's get back to the security issues.
If the security issue is that unsophisticated users get their computers owned because they click on a PDF link, then PDF/A isn't a solution. It isn't a solution for at least three reasons: (1) PDF/A is not an appropriate format for general use on the web, because it requires embedding all fonts. This makes the PDF much bigger, and that means the user's experience is slower. People already get bent out of shape about how long it takes for a PDF to load. They don't want a solution that makes it worse. (2) Advocating that people distribute their documents in PDF/A doesn't help, because bad guys will not follow that advice. (3) Telling users to restrict themselves to software that only accepts PDF/A will not work, because virtually no PDF's they encounter on the web are in PDF/A.
In typical case where the user simply wants to view or print a document, there is an incredibly simple solution. Tell the user to switch to something other than Adobe Reader, e.g., Foxit on Windows, Preview on MacOS X, or Evince on Linux. (For Windows users who get annoyed by how long it takes to open a PDF in a web browser, this has the added selling point of fixing that problem.) For users who can't switch (either because they need features of AR or are in a corporate environment where they can't install software), the next best option is disable JavaScript: go to Edit, Preferences, JavaScript, and uncheck "Enable Acrobat JavaScript."
The cases where I don't know of any good, general solution are cases like the one you're describing, where you want to put students' grades on their papers. The problem here is that you need a feature that goes beyond simply printing and viewing a document. Presumably you've thought about the security issues, and you have a PDF application that has the particular feature you want without exposing you to security issues. The trouble here is that the message now becomes much too complex for the average web user. It's easy to tell them "Use Foxit," and then their problem is solved. But what if they say, "I need features x, y, and z that aren't in Foxit, and I need JavaScript enabled, but I don't want to spend several hours researching how to do this without a security risk?" The only answer I have for such a person is, "Don't do that, because Adobe is clueless about security."
One particularly ugly issue is that if you're in the print advertising or publishing business, you really can't get away with not testing your PDFs in Adobe Reader, but AR is poorly engineered and a security risk. The best you can do is to disable JavaScript.
Re: (Score:2)
PDF/A is not an appropriate format for general use on the web, because it requires embedding all fonts. This makes the PDF much bigger, and that means the user's experience is slower.
Clearly we need a 'PDF/R' then, much like PDF/A except without mandatory font embedding.
Re: (Score:3)
In typical case where the user simply wants to view or print a document, there is an incredibly simple solution. Tell the user to switch to something other than Adobe Reader, e.g., Foxit on Windows, Preview on MacOS X, or Evince on Linux. (For Windows users who get annoyed by how long it takes to open a PDF in a web browser, this has the added selling point of fixing that problem.) For users who can't switch (either because they need features of AR or are in a corporate environment where they can't install software), the next best option is disable JavaScript: go to Edit, Preferences, JavaScript, and uncheck "Enable Acrobat JavaScript."
Just to point out that on Windows, it is actually more secure to use reader x. The sandbox and exploit mitigation techniques are much better than the negligible gain in security by obscurity in using foxit or sumatra.
Re: (Score:3)
In typical case where the user simply wants to view or print a document, there is an incredibly simple solution. Tell the user to switch to something other than Adobe Reader, e.g., Foxit on Windows, Preview on MacOS X, or Evince on Linux. (For Windows users who get annoyed by how long it takes to open a PDF in a web browser, this has the added selling point of fixing that problem.) For users who can't switch (either because they need features of AR or are in a corporate environment where they can't install software), the next best option is disable JavaScript: go to Edit, Preferences, JavaScript, and uncheck "Enable Acrobat JavaScript."
Just to point out that on Windows, it is actually more secure to use reader x. The sandbox and exploit mitigation techniques are much better than the negligible gain in security by obscurity in using foxit or sumatra.
It took me a while to figure out what you meant. Foxit didn't used to support javascript at all, and that meant that its added security was more than just security through obscurity. It was actually more secure, because all the exploits for AR were based on javascript, which foxit didn't implement. I hadn't realized that foxit later added javascript support. At this point it looks like foxit is roughly equivalent to AR in terms of security: both have js turned on by default, and both allow you to turn it of
Re: (Score:2)
Re: (Score:2)
> Presumably you've thought about the security issues, and you have a PDF application that has the particular feature you want without exposing you to security issues.
It's actually simpler and safer than you'd imagine. The plan would be to have the server pre-check the PDF, and outright refuse to put the field in if there's anything troubling (e.g. scripts). The grade field will be a normal text form field, and the whole PDF will have to be re-uploaded to the server to extract the value.
> But what if
Re: (Score:2)
The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format.
Right, but world domination is hard to fit on the printed page. :-)
Re: (Score:2)
There's a few contexts we use PDFs in, with varying advantages:
1. For archival purposes, we produce signed PDFs (and are working on producing PDF/A compliant documents, but the library we're using is being a bit of a pest). These can't then be changed without breaking the cryptographic signature.
2. For coursework submission... HTML could work for essays (although conversion from Word has always been "interesting"), but presentations wouldn't work. We're idly looking at adding .docx to HTML convertors as a s
Re: (Score:2)
1) Any file can be signed, it's just a matter of hashing and encrypting such hash with a private key. PGP and such have "sign file" buttons.
2) http://meyerweb.com/eric/tools/s5/s5-intro.html [meyerweb.com]
3) Why is text layout important in a letter?
Re: (Score:2)
1. Yeah, suppose we could. What's the advantage?
2. That's really cool, and prints a lot better than I would have expected, but... this is for coursework submission. That means training 9,000 students to produce HTML presentations. I don't see that going well for us...
3. Appearance of professionalism, and not being quietly killed in our sleep by the corporate identity peeps. We'll get rid of paper letters before we get rid of the demand that letter layouts aren't done to an extremely strict set of requiremen
Re: (Score:3)
One of the big differences between html and PDF is data storage. When using a pdf form someone opens the form inputs the data and that data is saved inside that form; everything is in one place. Html requires three separate pieces; The form to enter the information, the scripts to save the information and the data store (database or file system) to save the data. PDFs are much simpler for handling small quantities of forms.
Re: (Score:2)
Re: (Score:3)
PDF is in essence a PostScript-document (with restrictions of the use of external fonts and in a compressed form).
PostScript is a complete programming-language which implies that one could write PostScript that would react to the environment in which it runs. The problem with that has always been that one would have to know on what make and model printer it would run. But, thanks to Adobe, most people will run their PostScript in a 'virtual' printer inside an Adbode-product, and that makes usefull programmi
Re:Abomination (Score:5, Interesting)
PDF is in essence a PostScript-document (with restrictions of the use of external fonts and in a compressed form).
PostScript is a complete programming-language which implies that one could write PostScript that would react to the environment in which it runs.
A real programming language cannot "react to the environment" unless it has the needed I/O facilities. It seems to me that PostScript (as implemented by ghostscript) has been locked down more and more in this area.
PDF in Adobe's hands on the other hand has acquired more and more dynamic features *not* found in Postscript.
Re: (Score:2)
PDF is in essence a PostScript-document (with restrictions of the use of external fonts and in a compressed form). PostScript is a complete programming-language which implies that one could write PostScript that would react to the environment in which it runs
PDF is not anything like PostScript. It shares the same rendering model, that is about it. Postscript _is_ a Forth-like, stack oriented programming language. PDF isn't a programming language at all, but rather a generally vector oriented graphics form
Re:Abomination (Score:5, Informative)
Re: (Score:3)
A subset of PDF is almost identical to a subset of PostScript.
One should say rather that a subset of Postscript, when executed/interpreted produces output that is equivalent to a subset of PDF. PDF isn't based around an interpreter. Javascript/Flash appendages aside, a PDF document won't overflow the stack, does not have infinite loops, won't crash your photo-typesetter or take hours to run, because it is not a scripting language, but rather a vector oriented graphics format.
If Adobe did it over again, it
Re: (Score:2)
PDF isn't based around an interpreter
As I said, the top-level structure is a dictionary, but the drawing command set is definitely run in an interpreter. It provides a set of stateful drawing commands which are identical to the same commands in PostScript. It is not a Turing-complete language, because it doesn't have loops, but it is interpreted and its syntax is identical to PostScript. In the first version of the PDF spec, it was a subset of PostScript, just with the flow control removed. In newer versions, it has gained some things that
Re: (Score:2)
It provides a set of stateful drawing commands which are identical to the same commands in PostScript. It is not a Turing-complete language, because it doesn't have loops, but it is interpreted and its syntax is identical to PostScript.
A syntax identical to a highly restricted subset of PostScript - not so much as a user defined macro - everything pre-defined for you. You can't even come anywhere close to converting the most average, run of the mill Postscript file (such as the output of a typical Postscri
Re: (Score:2)
Not me, certainly. When I view a document I want to see exactly what everyone else viewing the document sees unless I take explicit action to change it.
Re: (Score:2)
Lowest common denominator. So you don't care that some systems are more compliant that others and can display things better than others. That would require the format to only support formatting that available on all computers.
Re: (Score:2)
"Wolf said that the document format is also full of other surprises. For example, it is reportedly possible to write PDFs which display different content in different operating systems, browsers or PDF readers -- or even depending on a computer's language settings."
Amazing -- totally unbelievable!! This should be wholly forbidden. Who would want to read documentation that knew what system you were running, or what language you could read, and tailored the display to make it more relevant to you? Text files don't let you do these things! Adobe is clearly going too far.
Look, the security problem isn't that the features exist. The security problem is that people are just plain ordinary mortals, and plain ordinary mortals screw things up. Every new option adds another route to failure.
Apple doesn't like to ship too huge manuals. My sister wanted a nice printed GarageBand manual. She sent the PDF manual to my father, who opened it on a computer with an older Windows version of Acrobat Reader that didn't know damn about the language switch thingy. So he ended up getting bound
Re: (Score:2)
I suppose they could put a big page in the front that only appears on older reader version that says "This document contains the documentation to GarageBand in X languages", ... etc etc, but then again, who uses brains in this area.
Or prevent printing if the reader doesn't have "multi-language" capabilities... yay, frustrate the user even more!
Re: (Score:3)
Re: (Score:2)
Try opening a Word 2010 in Office 3.1. It won't work. The fact that the PDF was even able to be opened in older software is astounding. One would have to be clairvoyant to be able to make software compatible with all possible future extensions.
To me this sparks a hubris; I want the computer to do what I want when I want no matter what version of software I use. The fact that someone opens a new version document in an old version of the software and there is an issue is not the problem of the software but a
Re: (Score:1)
Re: (Score:2)
There is a place for adapting to the user (though IMO there should always be overrides). But there is also a place for a standard "electronic paper" that reliablly displays the same way everywhere. Many people assume PDF is like electronic paper but as the article shows it isn't in key ways.
Consider what happens if someone reads a document, decides they agree then takes it to another system to print and sign. There is no gaurantee that what they read matches what they printed and signed.
Re: (Score:2)
Unfortunately, those features also make it a lot harder to secure and a lot easier to use for malicious purposes. Word documents had a similar problem. Macro viruses didn't come on to the scene until MS decided that a document should be more than just text and mark up.
Adobe Reader (Score:2)
Agreed. This is an Adobe Reader problem (Score:4, Informative)
Of course, we all know the vast majority of the world (especially corporate users) uses Windows, and thus, Adobe Reader, so the security problems mentioned in the article are a valid cause for general concern... But not a concern for the PDF format in general.
Re: (Score:2)
At the end of the article, it is revealed that the exploits are Adobe Reader problems that are going to be addressed starting with Adobe Reader 10.
From TFA: "Adobe plans to remedy the situation in version 10 of its Reader product by introducing a sandbox". In other words, they aren't going to actually fix any of the problems, they're just going to try to hide them behind a wall.
Re: (Score:2)
Re: (Score:2)
Actually, there are many more powerful alternative pdf readers on windows than on linux. On linux, if you want anything besides just a document rendered to print (such as annotations, animations, forms, 3D content, ...), you have to use adobe reader. I don't know what the situation is on osx, but state of linux pdf readers is abysmal. Linux is perfect environment for producing pdfs, but linux viewers are really quite primitive.
Re: (Score:2)
That's a very popular excuse for the sorry state of linux pdf viewers. If all you need is just display text and images in the right font and on the correct place on the page, you are right, linux pdf viewers are fine. AFAIK there is nothing available for windows that can beat let's say zathura for that purpose. But contrary to the popular belief, pdf is much more than just static text and images on a page. Just because you have never needed certain features does not mean that these features are useless a
Thank jebus that Apple invented Preview (Score:3)
Re: (Score:2)
Evince on Linux is the same way.
Adobe's own offering is slow and eats up memory.
Evince loads large PDF files in less than 3 seconds and uses a comparatively small amount of memory. Scrolling is smooth, as well.
Re: (Score:1)
Even evince is starting to suffer from bloat. I've recently gone back to using xpdf [foolabs.com] on my desktop box, and put ePDFView [fsf.org] on my netbook.
Re: (Score:2)
Is ePDFview in the Debian repos?
Re: (Score:3)
> Is ePDFview in the Debian repos?
Yes.
Re: (Score:2)
Re: (Score:2)
Preview has a nasty habit of not displaying the PDF correctly, though. I'd rather slow-and-correct than fast-but-graphic-elements-get-randomly-shifted-on-the-page-or-dropped-entirely.
The couple of times I've had issues with Preview not displaying a PDF file, I have noticed that even in the full (OS X) version of Acrobat, the file is pretty wonky. I'm not sure that Adobe even knows what Adobe is doing.
Re: (Score:2)
Re: (Score:2)
I have never seen this with a well-formed PDF. In fact, Preview is the reference PDF renderer for several graphic artists I know precisely because Acrobat seems to produce funny output with a significant minority of files.
Re: (Score:2)
Re: (Score:3)
Indeed. You know what the easiest way to fuck with OS X is?
Treat it like Windows and install all the extras you'd want on Windows - even where equivalent functionality is already built in on OS X.
A couple of years ago I saw a MacBook Air that my US colleagues had purchased and done exactly that with. Even removing Adobe Reader sped it up no end.
Re: (Score:2)
Foxit works better on Windows than Adobe Reader.
Re: (Score:2)
People use Adobe Reader?
All right (Score:1)
"previously hardly known"
And that's where I stopped reading. Yet another publicity-seeking person recycling previously known vulnerabilities and trying to tell us they were "hardly" known.
Re:All right (Score:5, Insightful)
I happen to know Julia Wolf personally and I know she's not seeking publicity. In talks I've had with her in the past, she has described how open PDF is to attack and how bad Adobe's reader is at security. She designs and writes these attacks as part of her job in order to detect and block them. She's one of the white hats. I'm sure that the issues she's discussed were probably discussed previously with Adobe and a handful of other security researchers, hence "previously hardly known". The article is poorly written IMO.
Trying to say that she's a publicity-seeking person would be highly inaccurate. She does give talks at various security conferences around the world since that is her expertise and she knows what she's talking about.
The problem is that Adobe made PDF so flexible with so many features that it's impossible to block all the various exploits, not to mention that Adobe themselves don't have a very good track record with security, i.e. look at Flash. The fact that PDF can incorporate Javascript, Flash, multimedia and even execute arbitrary external programs makes it a nightmare to secure.
Re: (Score:1)
Ban manuals distributed in pdf. (Score:2)
Re: (Score:3)
HTML manuals suck for a number of things. They don't print very well and are limited to a certain set of fonts. While there's SVG, it's not widely used at this time in the web browser because some browsers only recently started to support it (i.e. I.E.).
Re: (Score:2)
Re: (Score:1)
HTML is a display format, not a printing format. It will print, but often poorly formatted - the reason for using PDF over txt/html is that they want it to look pretty/have a fixed display format relative to images, etc. HTML is nice for linkability, but a printed out HTML manual is utter crap to flip through.
Re: (Score:2)
I never have a problem finding information in PDFs, nor do I always have to pan and zoom. I'm always dealing with datasheets for various chips and whatnot. These are ALWAYS in PDF format without exception from every vendor I've seen. They usually contain scalable vector drawings where they can't really do that in HTML because a certain company's web browser didn't support SVG until very recently. These PDFs also usually have have the table of contents as well to help navigation.
In my case I usually use Okul
Re: (Score:2)
HTML manuals can do all the things accused of PDFs, and you won't even know about half of them! Your browser automatically sends your operating system and locale preferences on every request. The hosting site doesn't even need Javascript to access them. But if you did have Javascript enabled, your HTML documentation could also read and write to Flash and HTML5 offline storage databases, often without your consent or direct knowledge! The horrors!
Re: (Score:2)
Further all the hard to remove cookie shenanigans could be fixed, but wait Flash? That's ADOBE's fault again! DOH.
HTML5 offline storage should be cleared from the same privacy clearing settings that cookies are cleared from etc.. etc..
Re: (Score:2)
You actually can do that with javascript, but it makes for a very large and clunky file.
Re: (Score:2)
You really shouldn't. Better to keep images in separate files. Noting stops you from having a simple web1.0 style webpage with hyperlinks to different parts of the same web page, or you can even break it into separate different files. You just need to link to it from the start menu or something. Name the main file help.html
Re: (Score:2)
Re: (Score:3)
It would be good to have HTML standard for manuals - and have a standard to embed images and fonts and whatever in ONE SINGLE file (the same .html), then it will replace PDF to some degree.
You mean like MHTML [wikipedia.org]? Based on MIME, standardised [ietf.org]. Unfortunately Firefox doesn't support it out of the box, perhaps because it's a Microsoft invention (AFAIK).
PDF as a standard vs a Standard for Documents (Score:2)
Many years ago there was a standard in development called Open Document Architecture (ODA - ISO 8613) which defined a compound document standard which never became mainstream. Adobe's PDF was a proprietary product which became a mainstream standard encompassing content and presentation. The features described for a PDF are things some users will find a benefit. Good. What is upsetting is that these features are opaque. I don't know if everything dreamed of for ODA is in PDF, but PDF has solved many exchange
Re: (Score:2)
A good set of SGML like tools should accomplish all of what is buried in a PDF but with transparency
SGML is two full levels of abstraction higher than PDF. PDF isn't really intended to be a user editable document format at all. PDF is a page description language with a few extra features glued on. It was never intended to be editable, let alone provide any sort of document structure (aside from a table of contents), but rather to provide an accurate representation of printed pages.
SGML and HTML cannot do
PDF is hacker-friendly way of making leaks (Score:5, Insightful)
Perfect example: when the TSA's army of contractors "redacted" a document for public release, they simply drew (in PDF) black rectangles above the redacted text. Yet the original text was still there and intact.
Some here seem to view content that's below the surface (not visible with standard settings on standard Adobe tools) as a problem. Yet it is the perfect route to security leaks, a treasure-trove to anyone who knows how to look below the surface. And we hackers are the ones who know how to do that.
Re: (Score:2)
The ability to press Ctl-A, Ctl-C, switch to a text editor, and press Ctl-V does not qualify you as a "hacker".
Re: (Score:2)
The knowledge that there is something actually informational there below the surface of glitz, is hacking in a way.
At one point I was sure that hacking - knowing what was going on below the surface - was by definition the ability to wire a flip-flop together and later to code in machine code and then Fortran. And using this to, say, put something up on the Rose Bowl scoreboard.
Today I am willing to enlarge that to typing Unix shell commands, and extracting hidden text from PDF's. Yes, both are relaxing the
Re: (Score:2)
Neither does the ability to program qualify a person as a hacker. A hacker is somebody who thinks outside the box, with playfulness and creativity.
Re: (Score:2)
Similarly, many non-hackers have the knowledge to open a file in a text editor. There can be some interesting stuff there, quite apparent.
Re: (Score:2)
A real hacker doesn't call himself a hacker, you tool.
Re: (Score:3)
This is in the same vein as someone running "rm -rf" on a hard rive full of sensitive information and then selling it. Anyone with a little tech experience knows that the data is still there. Ignorance of how a system works is not a problem wit the system; it is a problem with the user.
Re: (Score:2)
Perfect example: when the TSA's army of contractors "redacted" a document for public release, they simply drew (in PDF) black rectangles above the redacted text. Yet the original text was still there and intact.
Yep, the difference between vector and bitmapped graphics.
Let's abandon this outdated standard (Score:1)
And start using something more modern and much more secure: XPS.
PDF/A, PDF/X (Score:3)
There are two standards which are made for archiving/printing, where all the funny things are disabled and all the necessary thing are mandatory on board. How about not using the PDF standard when creating legal documents or other 100% perfect reproductions but PDF/A or PDF/X.
Everybody knows that PDF, as all formats which contain active (and nearly arbitrary) content are insecure.
Re: (Score:2)
Good question. I always think acroread displaying a document as pdf/a should be enough.
PDF == EXE (Score:1)
And woe unto those who do not treat it as such in their security model.
If you consider the social aspect of it, its even worse...many users will not run random programs sent even from well spoofed messages, but a "document" is as close to a thoughtless decision as you can find.
It all depends on the Reader (Score:3)
Or a truly effective sandbox environment since this has proven itself very harmful.
Or a new Safe PDF format that eschews all of the cuteness. Take you pick.
Re: (Score:2, Funny)
Samsung cell phone (SCH-W830) spontaneously combusted in my home ... might use Samsung products, which are selling like hot cakes
No kidding!