RFC: amendment to Thumbnail Managing Standard

Yuval Levy create07 at sfina.com
Wed Mar 26 07:31:55 PDT 2008

Hi all.

reposting this since being made aware by Cyrille Berger that this is the 
right place. It's my first post here.

Since I started to use a free desktop more intensively, I came across 
behaviors that are radically different from what I am used to. Some 
behaviors are superior and I learn and enjoy them. Workspaces? Saved 
Sessions? great. Other behaviors I find to be less useful.

One in particular is a deal killer for me: Thumbnails management the way 
it is currently specified in what I assume is the standard 
opens the door to leaks of confidential information and makes the 
application relying on this standard inadequate for professional use.

I found an earlier attempt to discuss this on the base of encrypted volumes.


digital cameras storage is not encrypted, but requires the same level of 
confidentiality if photographers are to trust free desktop applications.

The latest revision of the document known to me is still Version 0.7.0 
and is almost four years old. I herewith request for comments on these 
suggested modifications, hoping that we can take the specs to the next 
level and improve their adequacy to real world situations.

My comments are page by page, with the page referred first. I apologize 
and I am embarrassed to admit that I would not know where to find the 
DocBook source nor how to use/edit it, and would appreciate help.



Four years later
* the standard seems to be widely accepted.
* different volume types like network mounts and removable storage that 
were only marginally addressed in the last revision have become 
increasingly important.

Removable media, particularly the flash memory used in digital cameras, 
is promiscuous between systems and users. users will easily plug their 
card into the next available system without being aware that thumbnails 
of potentially sensitive images could be leaked.

Groups of users share the same set of images over network mounts - the 
current specs yield duplicate thumbs.

This revision takes the approach that the software is responsible for 
the files it creates for its own use. It is not the responsibility of 
the user to know or understand the details of the creation and 
accessibility of the thumbs beyond managing his preferences for thumbs 
on media he controls.


Issues to Solve:
* give the owner of the images a simple mechanism to express preferences 
for thumbnail creation and distribution across the system
* enable different behavior for different kind of media
* simplify the 0.7.0 version of September 2004


change: "the .thumbnails directory located in the users home" into "the 
.thumbnails directory located inside the directory containing the images".


"the .thumbs file, located in each file system's root directory, 
specifies how thumbnails should be handled on the file system.

in its simplest incarnation, it can be just an empty file. Its absence 
means: don't create thumbnails for files on this file system.

If present, thumbnails are created. It could be further specified to 
indicate what actions to take if images with existing thumbnails are 
copied into the file system, but this is not seen as necessary at this time.


add on top:

thumbnails are created only if permission for such creation is 
explicitly set for the file system in .thumbs

when files with thumbnails are copied from one file system into another, 
the thumbnails are not copied unless the .thumbs file is present on the 
target file system.

maybe the copying of thumbnails deserve a separate page, like the 
deleting thumbnails page.


Change the Permissions section to

~./thumbnails directory must have set their permissions to the same 
permissions as the directory containing the images.

the thumbnails themselves must have set their permissions to the same 
permissions as the original image.

the .thumbs file must have its permission set so that everybody can read 
it and only the owner of the volume can edit it.

this way we assure that the real owner of the files - and not the user 
of the system, as specified in the previous revision - controls who can 
have a glance.

add to Advantages of This Approach:

5. avoids leaking thumbnails of the images
6. avoids duplicate thumbnails
7. gives the *real* user (as opposed to the *system* user) finer grained 
  access control


becomes redundant and is superseded


The next step is to adapt the specs to the changed circumstances in the 
real world; finalize them into a 1.0; adopt them and update existing 
implementations to reach a higher level of usability.

I hope my initiative will help make free desktop more palatable to 
converts from proprietary desktops like me.


More information about the xdg mailing list