Revision history [back]

The current design for SD card mounting keeps a history of every SD card you have ever inserted. This is a serious privacy issue (for example, allowing authorities to find out who has read a Samizdat sdcard).

If the UUID-directory design is to be kept, the device must ensure that the information is not retained after the sdcard is removed. At least the following actions must be taken:

1. mount-sd.sh must rmdir the directory after unmounting an sdcard. This is easy to do but is not guaranteed to work (for example, files may still be open on the device).
2. On boot, the /media/sdcard/ directory must be emptied. Obviously this has to happen before any mounts could happen (before udev is started?).
3. Tracker database must forget (securely) all information about cards which are no longer mounted. This is probably harder to do (and also, harder to decide when to do) but it is essential.

All this means that the card would be forgotten about if another card is inserted, but that is not a problem. Swapping cards is relatively rare, and having to re-index for tracker after swapping cards is not a big problem.

Alternatively, change the design so that the mount point is not named from the UUID but is chosen randomly. Of course, it would be useful for it to remain stable across boots, as long as the card has not been swapped, as that is the most common use case. This could be done by keeping a record (in a file, in the user's home directory so they can delete it when they choose) of the UUID of the last card seen and the mount point being used for it. If, on the next mount, the same UUID is seen, then the same mount point is used. If the UUID has changed, the file is deleted, a new random mount point created, and a new record created.

Even with this alternative design, it is important that tracker forget about the files it saw on the earlier sdcard. If that doesn't happen automatically, then there needs to be an option (probably in media player) to "clear private data", just like in the browser.

The current design for SD card mounting keeps a history of every SD card you have ever inserted. This is a serious privacy issue (for example, allowing authorities to find out who has read a Samizdat sdcard).

If the UUID-directory design is to be kept, the device must ensure that the information is not retained after the sdcard is removed. At least the following actions must be taken:

1. mount-sd.sh must rmdir the directory after unmounting an sdcard. This is easy to do but is not guaranteed to work (for example, files may still be open on the device).
2. On boot, the /media/sdcard/ directory must be emptied. Obviously this has to happen before any mounts could happen (before udev is started?).
3. Tracker database must forget (securely) all information about cards which are no longer mounted. This is probably harder to do (and also, harder to decide when to do) but it is essential.

All this means that the card would be forgotten about if another card is inserted, but that is not a problem. Swapping cards is relatively rare, and having to re-index for tracker after swapping cards is not a big problem.

Alternatively, change the design so that the mount point is not named from the UUID but is chosen randomly. Of course, it would be useful for it to remain stable across boots, as long as the card has not been swapped, as that is the most common use case. This could be done by keeping a record (in a file, in the user's home directory so they can delete it when they choose) of the UUID of the last card seen and the mount point being used for it. If, on the next mount, the same UUID is seen, then the same mount point is used. If the UUID has changed, the file is deleted, a new random mount point created, and a new record created.

Even with this alternative design, it is important that tracker forget about the files it saw on the earlier sdcard. If that doesn't happen automatically, then there needs to be an option (probably in media player) to "clear private data", just like in the browser.

The current design for SD card mounting keeps a history of every SD card you have ever inserted. This is a serious privacy issue (for example, allowing authorities to find out who has read a Samizdat sdcard).

If the UUID-directory design is to be kept, the device must ensure that the information is not retained after the sdcard is removed. At least the following actions must be taken:

1. mount-sd.sh must rmdir the directory after unmounting an sdcard. This is easy to do but is not guaranteed to work (for example, files may still be open on the device).
2. On boot, the /media/sdcard/ directory must be emptied. Obviously this has to happen before any mounts could happen (before udev is started?).started?). Better: make it a tmpfs -- there is no need to retain the information across boots.
3. Tracker database must forget (securely) all information about cards which are no longer mounted. This is probably harder to do (and also, harder to decide when to do) but it is essential.

All this means that the card would be forgotten about if another card is inserted, but that is not a problem. Swapping cards is relatively rare, and having to re-index for tracker after swapping cards is not a big problem.

Alternatively, change the design so that the mount point is not named from the UUID but is chosen randomly. Of course, it would be useful for it to remain stable across boots, as long as the card has not been swapped, as that is the most common use case. This could be done by keeping a record (in a file, in the user's home directory so they can delete it when they choose) of the UUID of the last card seen and the mount point being used for it. If, on the next mount, the same UUID is seen, then the same mount point is used. If the UUID has changed, the file is deleted, a new random mount point created, and a new record created.

Even with this alternative design, it is important that tracker forget about the files it saw on the earlier sdcard. If that doesn't happen automatically, then there needs to be an option (probably in media player) to "clear private data", just like in the browser.