Path: utzoo!attcan!uunet!samsung!usc!rutgers!umn-d-ub!cs.umn.edu!kanefsky
From: kanefsky@umn-cs.cs.umn.edu (Steve Kanefsky)
Newsgroups: comp.sys.mac
Subject: Re: On Location is BAD NEWS!
Message-ID: <1990Feb18.194815.5121@umn-cs.cs.umn.edu>
Date: 18 Feb 90 19:48:15 GMT
References: <17721.635313273@ics.uci.edu> <8514@wpi.wpi.edu>
Organization: University of Minnesota, Minneapolis - CSCI Dept.
Lines: 48

In article <8514@wpi.wpi.edu> tbutler@wpi.wpi.edu (Tim Butler) writes:
>In article <17721.635313273@ics.uci.edu> truesdel@ICS.UCI.EDU (Scott Truesdell) writes:
>
>   Mitch Kapor's new venture sounded like a neat hack.
>>   Then I read something in MacWorld, March, 1990, MacWorld News, page
>>   119, right under Mitch's picture that chilled my blood. I quote:
>>
>>	   "AppleShare volumes also present a curious problem:
>>	   [On Location] indexes don't respect AppleShare's
>>	   security features, so you can't prevent users from
>>	   finding text in folders they are not authorized to
>>	   read. On Technology plans a fix for a later version."
>
> [remainder deleted]
>
>Isn't it interesting that an application must RESPECT Appleshare's security
>features? I think perhaps that instead of On Technology planning a fix, Apple
>should be planning a fix. If On Location drops this *feature* then many
>people may forget about it and therefore place themselves in a vulnerable
>position. Anyone who then had the older version would still be able to  
>access protected volumes.

I don't believe that Appleshare's security has this terrible hole that 
everyone is claiming.  Security which must be "respected" is no security
at all.  After having gone back and read the ad for On Location and the
review in MacWorld, I think that the "curious problem" refers to the way
On Location builds its index.  

Remember that On Location is constantly updating an index that takes
up to 2% of the volume being indexed.  My guess is that it is possible
that On Location can store sensitive information in its index while
someone is logged on to an AppleShare volume, which is then available
to someone else logged on to the same volume with different access
priviledges.  If this is the case, then all one would have to do
to maintain security would be not to use On Location while working on
secure documents.  That way, the contents of the document would never
be indexed.  Anyone using On Location later would not have access to
that information.  AppleShare volumes which haven't been indexed by
On Location at all would have nothing to fear.

Of course, everyone must be responsible for what INITs they are running.
I don't suppose it would be hard to do On Location one better by writing
an INIT that trapped save commands and always saved an extra copy of
every document in a publicly accessible folder.

-- 
Steve Kanefsky             
kanefsky@umn-cs.cs.umn.edu