Re: [Usability] time stamps and privacy



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
  


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