Bug 310226

Thanks for the report, but to be honest, I don't think that this should be considered a bug. The .kde directory contains lots of information about how you use your computer - if you want to keep it private, make sure that this directory can't be read by other people.

Moreover, you can prevent the generation of those files if you enable "Use common view properties for all folders" in the settings.

(In reply to comment #0)
> Shouldn't
> such information better be stored in some sort of database or at least using
> a flat directory layout and a hashed file name to not make this history all
> too obvious?

This would not prevent that a malicious person can get that information. So you suggest to put a lot of effort into something that would not fix the issue at all?

I would not consider this way to get information about when you browsed directories on a USB stick "obvious". I don't think that anyone will read the contents of your .kde folder accidentally.

(In reply to comment #1)
> Thanks for the report, but to be honest, I don't think that this should be
> considered a bug. 

Agreed. Reopening this on "wishlist" priority as this seems more appropriate.


> The .kde directory contains lots of information about how
> you use your computer - if you want to keep it private, make sure that this
> directory can't be read by other people.

While I generally tend to agree, this IMO seems a bit too easy here. Yes, the .kde folder, much alike every piece of configuration, reveals a lot about how I use my machine.

I'm not generally complaining about that, it seems a matter of fact, yet in this situation at least to me it seems (a) accessing these information is way easier than accessing other configuration data in there (one doesn't even need to open some file in an editor, just ls -l'ing the folder, using find, ... practically does it), and (b) talking about the timestamps of these folders, there's more information collected than actually required for what happens here. 


> This would not prevent that a malicious person can get that information. So
> you suggest to put a lot of effort into something that would not fix the
> issue at all?

No. Definitely not. Yet I think KDE in many respects offers more sophisticated means of storing configuration and metadata. And, well, I'm just a Java EE backend developer lacking much experience in doing Qt/C++ coding, but from my point of view, even a pretty bare-bone approach of hammering a few lines of SQL into an sqlite store wouldn't be much more effort than storing things somewhere in the file system, and this at least partly would fix this "issue" as it would not record timestamps all along with the configuration. ;)

> I would not consider this way to get information about when you browsed
> directories on a USB stick "obvious". I don't think that anyone will read
> the contents of your .kde folder accidentally.

I am not sure. I actually did. And it came bit of a surprise, the way it was/is. Anyway, no offense intended. Leaving this as an enhancement request, maybe some day there'll be a way to easily address this. :)

> > The .kde directory contains lots of information about how
> > you use your computer - if you want to keep it private, make sure that this
> > directory can't be read by other people.
> 
> While I generally tend to agree, this IMO seems a bit too easy here. Yes,
> the .kde folder, much alike every piece of configuration, reveals a lot
> about how I use my machine.
> 
> I'm not generally complaining about that, it seems a matter of fact, yet in
> this situation at least to me it seems (a) accessing these information is
> way easier than accessing other configuration data in there (one doesn't
> even need to open some file in an editor, just ls -l'ing the folder, using
> find, ... practically does it)

'ls -l'ing subfolders of your home directory or running find there is something that nobody whom you're not willing to share all your information with should ever do. And if you are afraid that people do it anyway, you have to protect your system better.

>, and (b) talking about the timestamps of
> these folders, there's more information collected than actually required for
> what happens here. 

The same is true for *every* .directory file in your home folder. And maybe the timestamp is more useful for some people than you actually think (think of backups).

> > This would not prevent that a malicious person can get that information. So
> > you suggest to put a lot of effort into something that would not fix the
> > issue at all?
> 
> No. Definitely not. Yet I think KDE in many respects offers more
> sophisticated means of storing configuration and metadata. And, well, I'm
> just a Java EE backend developer lacking much experience in doing Qt/C++
> coding, but from my point of view, even a pretty bare-bone approach of
> hammering a few lines of SQL into an sqlite store wouldn't be much more
> effort than storing things somewhere in the file system, and this at least
> partly would fix this "issue" as it would not record timestamps all along
> with the configuration. ;)

"hammering a few lines of SQL into an sqlite store" is a lot less trivial than it may look at first sight (even if you disregard the fact that "hammering" is a very inadequate description for the development of code that many users rely on). Please note:

a) We don't use any kind of database in Dolphin at the moment.

b) We would have to add a new way to store the view properties and maintain two different ways (database + .directory file) in the future. You might argue that one could just store the view properties for all folders in the database, but then I already see bug reports coming like "I moved a folder inside my home directory, but the view properties got lost" -> still a lot more work to do until it works as expected. Note that people might move folders while Dolphin is not running at all - how can we know this the next time the folder is opened?

c) We would have to add some backwards-compatibility code to check if view properties for a folder on a removable drive are stored in .kde if not found in the database. People don't like it if their data created with earlier KDE versions get lost.

d) We would give up control about the view properties storage, and thus open the door for new kinds of bugs. The other day, an application on my system refused to work properly after the distro upgraded the packages for the database that the app uses. Now just imagine that something like that happened to us. We get a bug report like "Dolphin fails to show a folder with the correct view properties". Can you imagine what a debugging nightmare that would be?

To sum up: it would be a lot of work, make the code more complex and probably increase the maintenance burden. And the only benefit is that a single user believes that it would help him to keep his data private, even though I've pointed out that there are easier and more effective ways to do that.

Now consider that I work on Dolphin an hour a day on average, that there are ~280 bug reports, even more wishes, and that people file new reports every day. I can only work on a very small number of the things that users request and have to think carefully about what is worth spending time on.

Just to prevent that anyone else wastes time on this: I'm very unlikely to accept patches implementing this feature. The bug reports will end up in *my* inbox. And yes, every non-trivial code change causes bugs, I've seen that happen too often already.

>> I would not consider this way to get information about when you browsed
>> directories on a USB stick "obvious". I don't think that anyone will read
>> the contents of your .kde folder accidentally.
> I am not sure. I actually did. 

But it was *your own* data that you found. It's not like anyone else found out information about you by accident.

> Leaving this as an enhancement request,
> maybe some day there'll be a way to easily address this. :)

Maybe some other Dolphin maintainer will see your point in the future ;-) So I'm not closing this as WONTFIX yet.

(In reply to comment #3)
> > I'm not generally complaining about that, it seems a matter of fact, yet in
> > this situation at least to me it seems (a) accessing these information is
> > way easier than accessing other configuration data in there (one doesn't
> > even need to open some file in an editor, just ls -l'ing the folder, using
> > find, ... practically does it)
> 
> 'ls -l'ing subfolders of your home directory or running find there is
> something that nobody whom you're not willing to share all your information
> with should ever do. And if you are afraid that people do it anyway, you
> have to protect your system better.

Well I won't dispute on that. The fact that I see your points won't keep me from disagreeing with that, for the reasons I pointed out. ;)  Nevertheless, just a few thoughts however:


> b) We would have to add a new way to store the view properties and maintain
> two different ways (database + .directory file) in the future. You might
> argue that one could just store the view properties for all folders in the
> database, but then I already see bug reports coming like "I moved a folder
> inside my home directory, but the view properties got lost" -> still a lot
> more work to do until it works as expected. Note that people might move
> folders while Dolphin is not running at all - how can we know this the next
> time the folder is opened?

But at the moment you already _have_ to keep track of two different ways of storing view properties - one for storing them inside the directory itself, and one for storing them somewhere below view_properties/local/. Not talking about the fact that this "moved folder -> lost view configuration" issue already is given now for every folder having its view properties stored outside the folder itself. 


> c) We would have to add some backwards-compatibility code to check if view
> properties for a folder on a removable drive are stored in .kde if not found
> in the database. People don't like it if their data created with earlier KDE
> versions get lost.

Maybe, yes. Not sure about the complexity of that, though, assuming the SQL persistency layer possibly would suffice just being a dumb store (thus also the wording "hammering" as this doesn't involve many too complex RDBMS / database related things but should be rather straightforward in terms of table structure, data model et al). 


> d) We would give up control about the view properties storage, and thus open
> the door for new kinds of bugs. The other day, an application on my system
> refused to work properly after the distro upgraded the packages for the
> database that the app uses. Now just imagine that something like that
> happened to us. We get a bug report like "Dolphin fails to show a folder
> with the correct view properties". Can you imagine what a debugging
> nightmare that would be?

Yes, it possibly would.  Yet: How do other applications in the KDE universe handle this? I see i.e. akonadi (mysql, postgresql) or nepomuk depending upon databases, too?



> Now consider that I work on Dolphin an hour a day on average, that there are
> ~280 bug reports, even more wishes, and that people file new reports every
> day. I can only work on a very small number of the things that users request
> and have to think carefully about what is worth spending time on.

I'm not complaining, and given this kind of time budget, I think the result of this work is rather good, as dolphin itself seems a mature and stable piece of software I heavily rely upon nowadays. I wasn't expecting this wish to be implemented anytime soon, yet I was hoping that filing an enhancement request wouldn't hurt.

(In reply to comment #4)
> But at the moment you already _have_ to keep track of two different ways of
> storing view properties - one for storing them inside the directory itself,
> and one for storing them somewhere below view_properties/local/. Not talking
> about the fact that this "moved folder -> lost view configuration" issue
> already is given now for every folder having its view properties stored
> outside the folder itself. 

If you are really trying to tell me that the two options "storing info in a .directory file inside the folder itself" and "storing it in a file in a subfolder of .kde" create a similar maintenance burden as the first option plus "storing the info in a database", then we should end the discussion here.

> > d) We would give up control about the view properties storage, and thus open
> > the door for new kinds of bugs. The other day, an application on my system
> > refused to work properly after the distro upgraded the packages for the
> > database that the app uses. Now just imagine that something like that
> > happened to us. We get a bug report like "Dolphin fails to show a folder
> > with the correct view properties". Can you imagine what a debugging
> > nightmare that would be?
> 
> Yes, it possibly would.  Yet: How do other applications in the KDE universe
> handle this? I see i.e. akonadi (mysql, postgresql) or nepomuk depending
> upon databases, too?

Just look through the bug reports for those projects (both open and resolved) to see what kind of trouble working with a database can cause, in particular if you have no control over the version that is installed on a user's machine and any distro-specific patches that are applied there.

First off: Frank, this issue report wasn't meant to be an offense or to point out anything dolphin does by now is bad or wrong. I think you're doing a good work maintaining this thing and I don't want to bash this. I posted this issue because stumbling across these plain text folder names in there felt both pretty much surprising and somewhat unfamiliar _to me_. YMMV, and indeed does, as far as I learnt by now. That's perfectly fine with me and not something I'll tr arguing away.


(In reply to comment #5)
> If you are really trying to tell me that the two options "storing info in a
> .directory file inside the folder itself" and "storing it in a file in a
> subfolder of .kde" create a similar maintenance burden as the first option
> plus "storing the info in a database", then we should end the discussion
> here.

I am not sure how much of the burden of storing things in a database could actually be "abstracted away" by either using something such as unixODBC or by making use of something "embedded" such as sqlite so to keep the amount of complicated external dependencies limited? 


> Just look through the bug reports for those projects (both open and
> resolved) to see what kind of trouble working with a database can cause, in
> particular if you have no control over the version that is installed on a
> user's machine and any distro-specific patches that are applied there.

I was somehow assuming KDE provides sort of a shared infrastructure for handling configuration entries such as that inside an RDBMS rather than leaving each and every application to keep track of this on its own.

(In reply to comment #6)
> First off: Frank, this issue report wasn't meant to be an offense or to
> point out anything dolphin does by now is bad or wrong. I think you're doing
> a good work maintaining this thing and I don't want to bash this. I posted
> this issue because stumbling across these plain text folder names in there
> felt both pretty much surprising and somewhat unfamiliar _to me_. YMMV, and
> indeed does, as far as I learnt by now. That's perfectly fine with me and
> not something I'll tr arguing away.

All right, but considering that you initially filed this as a bug, rather than a wish, I thought I had to explain why I'm not going to implement this.

> I am not sure how much of the burden of storing things in a database could
> actually be "abstracted away" by either using something such as unixODBC or
> by making use of something "embedded" such as sqlite so to keep the amount
> of complicated external dependencies limited? 

I don't know much about these things, but I don't see how this could prevent the possible problems that I pointed out (increased code complexity for no real benefit at all, risk of new bugs due to issues in the database which we have no control over, ...)

> I was somehow assuming KDE provides sort of a shared infrastructure for
> handling configuration entries such as that inside an RDBMS

I'm not aware of any such thing.

This is not really implementable in just Dolphin, as already discussed.

Since KDE has a privacy goal (https://community.kde.org/Goals/Privacy_Software), this sort of thing should be implemented at a higher level so that all KDE apps have their configuration data stored in an opaque, encrypted database, not just Dolphin. This should probably be implemented as an optional "high security mode" thing since it would make reading and debugging configuration files impossible, and opens up various database corruption risks. See Bug 402728.

As for creating .desktop files when using per-directory view settings, I believe this is part of a FreeDesktop spec and we can't just break the spec. Perhaps what we could do is add a warning to Dolphin when "High Security Mode" is enabled that informs the user of possible data leakage when using the per-directory view option.

*** This bug has been marked as a duplicate of bug 402728 ***