Copyright c 1995 by Don Lancaster and Synergetics, Box 809, Thatcher AZ, 85552 (520) 428-4073
Web support: www.tinaja.com    Email: don@tinaja.com   All commercial rights and all electronic
media rights fully reserved. Linking welcome. Reposting expressly forbidden..

Consulting services available on the concepts shown.

Adobe Acrobat versions 2.0 and higher offer a number of "security" features. It turns that these "features" are seriously -- and possibly fatally -- flawed.

Details on available security appear in ATN5154.PDFavailable at www.adobe.com.

If a "owner" security level is selected, the "user" security can be modified.

Several levels of "user" security are offered. These include a password, defeating the ability to print, the ability to change the document, the ability to select text or graphics, and the ability to add or change notes.

Security levels are normally selected when an Exchange file is saved to disk.

If the least little deviation from a totally transparent comm channel is present, Acrobat will conclude the file has been modified and will DEMAND a password. Thus denying certain legitimate users from access.

For instance, even bring a protected .PDF file up in Word and resaving it might lock a user out of access. Blindly uploading the same file to a BBS or other uncontrolled environment essentially GUARANTEES that some end users will be prohibited from access.

Most importantly, the XMODEM comm protocol sometimes adds padding NULL characters. These can cause major lockout problems.

In the case of a recent GEnie PSRT file, approximately ONE-THIRD of the potential users were unrightfully denied access.

The best workaround seems to be to CAREFULLY watch your file length counts on upload and download. XMODEM should be avoided! If the upload and download counts do not **EXACTLY** match, at least some users might expect problems.

Apparently a file length change of **one** count can sometimes be tolerated.

With "non-secure" Acrobat files, it is best to use ASCII-85 encoding that can operate over a seven bit "dirty" channel. This increases the file size by twenty percent. In general, it is **not** a good idea to use binary format in any uncontrolled or unknown envorinment. Especially for online distribution.

Sadly, the Acrobat security mode **FORCES** binary output. Even when given seven bit clean input. 

If the user is allowed to print his file, he is allowed to print to disk as a PostScript level I program. This, of course, can simply be shoved back through the Distiller to create a new and totally unprotected file.

Even if the print-to-disk feature were stupidly defeated, a PostScript data stream recorder (such as those on GEnie PSRT) can simply intercept the actual data going to the printer. From here, a new and unlocked .PDF file is easily redistilled.

Thus, giving a user the ability to print a file gives him the ability to circumvent **all** higher Acrobat security levels.

The only current workarounds seem to be Draconian ones. Demand a user password from **every** reader, and prohibit **all** hard copy printing.

Or consider Acrobat security to create far more problems than it solves. And **NEVER** use it. 

Copyright c 1995 by Don Lancaster and Syenrgetics, Box 809, Thatcher AZ, 85552 (520) 428-4073. SYNERGETICS@TINAJA.COM. All commercial rights and all electronic media rights **fully** reserved.

Consulting services avaiable on concepts shown.
Web support: www.tinaja.com    Email: don@tinaja.com