What I see is exactly false promises, lack of documentation and much innocence at the struggling users. Users try to establish privacy, use good 'ol Truecrypt. The average joe then trusts the promises, sees the "no history" checkbox, thinks he has a choice, but he does not - it's leaking and he doesn't know. And some user indeed find out that there is a leak. You can look in forums to see demand for solutions - and the many efforts to give advice. Often also false promises. Which is worst.
Truecrypt claims to offer features (no history), and officially worries about plausible deniability. And then you see practically it's all a huge mess. And I really blame them for giving false promises.
And yes: we could keep on to pass the buck, but TrueCrypt fails epically ignoring this issue. As I state, there would be true solutions possible to circumvent this leaking nightmare. If they wished, they (TrueCrypt) could fix it themselves (e.g. using another way of file selector).
If that were my project, I would do something against this and not ignore (for years).
And doing nothing will not help anybody. So I tried to give a practicable workaround until someone fixes the mess.
Well, you shouldn't be running it as root anyway (I'm not sure why you would) -- I just installed it on this laptop (Arch Linux) to test and it works just fine as a normal user.
In addition, this would still not be an issue if 1) you were running it as a normal user and/or 2) DACs were properly set.
Isn't the issue because Truecrypt is using the native open dialog which basically leaks the information in the first place to the desktop environment?
If they wanted to prevent this, they could implement a custom open dialog. While not TrueCrypt's issue, it is something that can be worked around. It's certainly not the issue of the desktop environment.
I suppose... but if he weren't running TrueCrypt as root, there would be no way for another user to discover his recently used documents/files anyways.
7 comments
[ 3.0 ms ] story [ 20.6 ms ] threadIt is an issue with his desktop environment maintaining a list of "recent documents".
What I see is exactly false promises, lack of documentation and much innocence at the struggling users. Users try to establish privacy, use good 'ol Truecrypt. The average joe then trusts the promises, sees the "no history" checkbox, thinks he has a choice, but he does not - it's leaking and he doesn't know. And some user indeed find out that there is a leak. You can look in forums to see demand for solutions - and the many efforts to give advice. Often also false promises. Which is worst.
Truecrypt claims to offer features (no history), and officially worries about plausible deniability. And then you see practically it's all a huge mess. And I really blame them for giving false promises.
And yes: we could keep on to pass the buck, but TrueCrypt fails epically ignoring this issue. As I state, there would be true solutions possible to circumvent this leaking nightmare. If they wished, they (TrueCrypt) could fix it themselves (e.g. using another way of file selector). If that were my project, I would do something against this and not ignore (for years).
And doing nothing will not help anybody. So I tried to give a practicable workaround until someone fixes the mess.
In addition, this would still not be an issue if 1) you were running it as a normal user and/or 2) DACs were properly set.
If they wanted to prevent this, they could implement a custom open dialog. While not TrueCrypt's issue, it is something that can be worked around. It's certainly not the issue of the desktop environment.