[cap-talk] Drag & "Attenuated" Drop?
Karp, Alan H
alan.karp at hp.com
Tue Dec 9 11:55:18 EST 2008
Rob Meijer wrote:
>
> There seem to be 3 alternatives possible, all seem sub optimal:
>
> 1) Show an attenuation dialog box on each drop.
> 2) By default let drag+drop be a deep read only attenuation, use
> something
> like CTRL drag-drop to show an attenuation dialog box on drop.
> 3) By default let drag and drop be unatenuated, use something like CTRL
> drag+drop to show an attenuation dialog box.
Since people often drop on the wrong target, option 3 is too dangerous. You'll minimize any damage of an inadvertent drop by using option 1, but that's too annoying. I guess that leaves you with option 2.
>
> Am I missing a better alternative, and if not, what of these 3 would be
> the preferable one.
>
One option would be to somehow tag applications at install time with how to handle drops. The problem is that your trust often depends on the application and the data it has processed, e.g., macro viruses. Perhaps you can somehow tag the data so that files with compatible tags, whatever that means, can default to unattenuated and all others to attenuated. Color or icon choice can be used to denote which default is in effect, and CTL can be used to override.
________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp
> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org [mailto:cap-talk-
> bounces at mail.eros-os.org] On Behalf Of Rob Meijer
> Sent: Monday, December 08, 2008 11:18 PM
> To: General discussions concerning capability systems.
> Subject: [cap-talk] Drag & "Attenuated" Drop?
>
> In explaining how in theory MinorFs could work with a MinorFs aware
> GUI,
> I've been saying that drag and drop could implicitly use MinorFs
> decomposition.
> That is, if some file or directory /mnt/minorfs/cap/$BASECAP_A/foo/bar
> whould get drag dropped, the GUI could implicitly request the "cap"
> extended attribute, that would point to /mnt/minorfs/cap/$BASECAP_B .
>
> With an additional file system I am adding to MinorFs that next to
> decomposition of the directory treegraph can do attenuation, the drag
> and drop concept however seems to get a bit more complex, and extended
> user interaction appears to be needed.
>
> There seem to be 3 alternatives possible, all seem sub optimal:
>
> 1) Show an attenuation dialog box on each drop.
> 2) By default let drag+drop be a deep read only attenuation, use
> something
> like CTRL drag-drop to show an attenuation dialog box on drop.
> 3) By default let drag and drop be unatenuated, use something like CTRL
> drag+drop to show an attenuation dialog box.
>
> Am I missing a better alternative, and if not, what of these 3 would be
> the preferable one.
>
>
> Rob
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
More information about the cap-talk
mailing list