[unisog] MacIntosh Safari Scripts - Hype or Hack?

John Rowan Littell littejo at earlham.edu
Thu Feb 23 18:51:46 GMT 2006


-----BEGIN PGP SIGNED MESSAGE-----

Lo, Stasiniewicz, Adam and the teakettle whistled in unison:

> Here is a crazy idea.  Why doesn't Mac simply use the following logic:
> -If fork and extension match, proceed normally.
> -If either fork or extension is present, go with what it's got.
> -If for and extension don't match, don't allow any program to open file
> until user changes extension.

The basic idea there is good, but it won't follow through in practice.
There are any number of programs that a resource fork could specify to
open a file, and trying to second guess those is tricky, at best.  And
hey, I may *want* to specify Terminal.app as the program that handles
a particular .jpg file for my own insane reasons.

The problem really is one of assumptions and different actions
making different assumptions.  We've got Safari (or StuffIt or
Mail.app) looking in one place (the file extension) to determine
whether to attempt to open the file and the operating system looking
in another place (the resource fork) to actually open the file.
The problem isn't that these two don't match but that we're using
one in one place and the other in the another place.  Instead, the
program that thinks it ought to be opening "safe" files ought to
be looking at the same thing that the operating system is to determine
the "safety" of those files:

- - If the resource fork is there, and it references a "safe"
application, send it to the OS to open it (which will also use the
resource fork).
- - If there is no resource fork, base your safety decision on the file
extension.  If it's safe, send it to the OS (which will use the
extension and the default program for that extension).

I suppose if you wanted you could have another check for common
extension to resource fork mappings -- look at the system default
for files of type foo, and if this file's resource fork doesn't
match it issue a warning.  Couldn't hurt, although I could see some
people wanting to turn that check off.

What Apple needs to do is provide a way to verify that your assumption
about the file's safety and what action the OS is going to take with
it actually match the action once you tell the OS to do it.  Leaving
aside discussions of actual picture files that contain code that
Preview will execute, or the like...

   --rowan

- -- 
John "Rowan" Littell
Systems Administrator
Earlham College Computing Services
http://www.earlham.edu/~littejo/
2006-02-23 13:33
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: http://www.earlham.edu/~littejo/littejo.asc

iQCVAwUBQ/4ER5dUNSJ2nf/5AQGOiAP/X68j0Bwkbr/ttMQE0BBiZQsByZbr/fXI
mLdnxZbDC+UZZClGRz0jS5Gx45fOHStppz21GMCs74ySQ0bMsuICmWSvv3va4uiZ
e3W/vNjDTTxIh7juWxo4uiuyajCDDzPIDoTomavXkLevGA1nLIpZ2eeMRuc0CoD6
8b0Ase3fTdE=
=73UW
-----END PGP SIGNATURE-----


More information about the unisog mailing list