RE: Document Centricity in GNOME [LONG]

I do not agree with the method, however I do agree that something must be
done to avoid such problems.

The problem is that code is included with documents, and runs automatically.
You cannot expect every single piece of software to make the difference
between running the code and not running it. IMHO the best solution is to
dissociate at file level the code from the document. It will allow documents
to be sent with their code attached as a separate document. Mail software
will be able to filter the document from its code, and forbids any script or
code to go through, providing users the possibility to view the document
without the danger of running unknown code.

I'm looking for an mail add-on to postfix that will filter attachments from
mails to my system. I want to have a list of authorised attachments that can
be received. For obvious reasons word documents and excel spreadsheets
should be forbidden, html also because of embeded scripts... While jpeg,
tiff, bmp, pdf documents will be authorised. I think the whole process will
be at mime level where certain mime types will be declared dangerous and
some others not.

Let me know what you think of this approach....

Franck Martin
Network and Database Development Officer
SOPAC South Pacific Applied Geoscience Commission
E-mail: <> 
Web site: <> 

		-----Original Message-----
		From:	Moshe Zadka []
		Sent:	Wednesday, May 10, 2000 3:53 AM
		Subject:	Document Centricity in GNOME [LONG]

		First of all, let me apologize for cross-posting: I'm not
really sure
		where this belongs. Please direct followups to the
appropriate list.

		Next, I'm not subscribed to either of the lists, so please
keep me in the

		I've wrote a brain-dump on how GNOME can stay
document-centric, while not
		falling prey to ILOVEYOU-type bugs.

		              How to Stop ILOVEYOU While Staying Document
		   Document-centricity is a good thing. It allows users to
be more
		   productive, because it reduces the cognitive load - a
user needn't be
		   aware of which application opens the file, and can
concentrate on his
		   work. However, as seen in the ILOVEYOU virus,
document-centricity can
		   be a dangerous thing too. Because the user is unaware of
		   application opens the document, and because the
application is unaware
		   of the document (possibly) dangerous origins, a situation
in which it
		   executes malicious code might occur. The way to stop this
problem is:
		   Do not use file-association -- make the user aware which
		   is used. The user should consult with the application
documentation to
		   check whether it is safe to open documents of unknown
origins with it.
		   Of course, the solution is much less user-friendly then
		   alternative. Here is a different way to solve it, while
		   document-centric, with a low (but nevertheless existant)
price for
		   usability, but with much increased security.
		   In addition to the file-association for the "Open"
action, have a
		   file-association for the "Open Safely" action. For many
programs, it
		   can be the association for both (Electric Eyes, MP3
players, etc.).
		   For other types, there will be no "Open Safely" (Perl
		   executables). A third category will be those with a
different "Open
		   Safely" action (Tcl's Safe Tcl, Java's sandbox, etc.).
When an
		   application installs (for example, via an RPM file), it
should install
		   itself to the "Open" and "Open Safely" as appropriate. Of
course, it
		   could consult a security setting to see if it should be
installed in
		   "Open Safely" (e.g., Safe Tcl might be all right if the
security is
		   low - high security sites may doubt if Safe Tcl really is
safe). A
		   system administer can change association system-wide, and
a user can
		   further override associations, just like other
		   Thus, the user is in control, but he is given a sensible
default so
		   the naive user will find it slightly harder to shoot
himself in the

		Moshe Zadka <> -- we put the penguin in .com

		gnome-devel-list mailing list

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]