Moving Baloo forward
kloecker at kde.org
Tue Jan 28 23:06:11 GMT 2014
On Tuesday 28 January 2014 22:06:45 Rolf Eike Beer wrote:
> Am Dienstag, 28. Januar 2014, 20:10:13 schrieb Ivan Čukić:
> > > To move a file to another machine and have the metadata be copied
> > > and re- indexed on that new machine as well. The copy process
> > > just needs to take care of transfering the xattr. This can even
> > > work when using a USB stick or so as interim medium.
> > I'm all for xattrs, but this thread really raises a nice question of
> > which annotations/tags/whatever should be public and which should
> > not.
> IMHO the default should be "privacy first". Probably everyone of us
> has laughed about someone who accidentially published either metadata
> or deleted text (remember MS Word document history or something)? I'm
> absolutely fine if you want this that you do this. But most people
> will not be aware of it, even less of the implications. So it should
> be deactivated by default and only activated explicitely.
I don't think it makes sense to work around a social problem (uneducated
users) by using an inferior and much more complex technical solution
(some database instead of xattrs). IMHO the advantages of using xattrs
(e.g. we get easy synchronization and backup of metadata for free)
outweigh the possibility that some people might inadvertently publish
private metadata. People need to be educated that they have to use their
brains when they share stuff. And we need to make sharing stuff (with
built-in privacy protection) as easy as possible.
Moreover, the risk for privacy is significantly lower than with metadata
that is stored in the file itself (as in your MS Word document example).
In contrast to metadata stored in MS Word documents, metadata stored in
xattrs will not be leaked if you share the file via mail or by uploading
it to Facebook or by copying it on a (FAT32-formatted) USB-stick.
Apparently, Dropbox supports xattrs, but IMHO it's Dropbox's
responsibility to provide a setting to disable synchronization of file
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel