Another idea off the top of my head. How about another Removable Media
option that sets it to "Secure Mode"? Then, if in secure mode and
something is removed/ejected, Nautilus prompts the user if they want to
shred or erase all traces of the data. A simple yes/no, and only if in
secure mode. The default is not secure mode. Then we don't care where the thumbs are stored (much) because we keep track of the thumbs created during an inserted session. We purge that info when it is ejected of course. I'm not a programmer so I don't know if this is feasible, but it seems to me that we have two different use cases here, or at least two different goals. So perhaps we need to allow both rather than ignore one or the other? Kirk Jason Hoover wrote: On Wed, 2008-03-26 at 16:23 -0400, Yuval Levy wrote:nice try, but does not work. will only simulate the intended behavior and will give a false sense of security. the only true security is an option not to write thumbnails to disk in the first place.Then why not simply disable thumbnails in the first place? There appears to be some discrepancy and two clear camps. The first position is: "I like cached thumbnails and dislike having to thumbnail the same things every time." These people seem to understand how the thumbnail system works, and despite it's inherent risk of recording things you may have looked at, use it anyway. I am of this opinion. The second, yours: "I like cached thumbnails and want them to be kept on the individual media." However, this carries some usability issues on it's own. Firstly, storing thumbnails on network drives or removal media can be a serious issue if permissions ever come into play (and they will). For instance, a user might create a .thumbnail directory in a drive with the permissions 700, and then prevent any other users from making thumbnails in your proposed design. The existing spec avoids this. Scenario number two; even under your system, the potential exists for there to be thumbnails of images which /have been deleted/. So for instance, say you make some sensitive image on a removable volume, look at it, then delete it. The thumbnail of that image will still continue to exist on that removable (or networked) volume, perhaps even with your name on it. The existing spec avoids this as well by providing a /central point/ where the concerned user's thumbnails can be easily cleared. This is not possible on removable volumes without combing through all of the individual media in question. >From a network administrator's point of view, your proposed idea makes an administrative nightmare. Thousands of tiny thumbnail files which are stored in awkward locations on volumes, possibly with usernames that no longer exist, perhaps requiring world-writable permissions on network volumes for them to even function properly, in addition to excessive numbers of read/write operations and traffic over a LAN or long-distance WAN (or even to a write-count sensitive volume, like packet re-writable or flash memory) per thumbnailed directory. This really only leaves two options: 1) Disable thumbnails. 2) Make the thumbnails more easily removed. Perhaps the 'clear document history' option should be expanded to this function? This provides a compromise; people who don't like their information recorded can remove it at will, and people who don't care or trust their own systems can keep it while still maintaining the full functionality and benefits of the thumbnail system. _______________________________________________ Usability mailing list Usability gnome org http://mail.gnome.org/mailman/listinfo/usability |