Ubuntu QA:
BlogBrainstormPackage status
Log in
Ubuntu QA
Nautilus
Idea sandbox Idea sandbox
Popular ideas Popular ideas
Ideas in development Ideas in development
Implemented ideas Implemented ideas

Popular ideas Here are the latest commented ideas about Nautilus.

So we dont have to use encryption or mess with permissions   forum
Written by mwillams73 the 2 Aug 09 at 23:01. New
I really have no need for encryption, and although i have some experience with Ubuntu I feel that average users would feel more comfortable with right clicking on a file or folder and having the option in the context menu to " Add Password Lock" or something similar and then proceeds to open a dialogue box or window that you type your pass into and from that point on the file is password protected until you right click on the file again and select " Remove Password Lock" and again enter the pass. Thereby unlocking it for anyone to see.

I know that you can alter the permissions of a file or folder but many " new" users dont know how , and a search of Ubuntu forums brings up mods and posters alike suggesting encryption when all the poster really wants is to keep prying eyes out.

I honestly feel that if you dont want your girlfriend , kids or friends seeing something that may be personal or possibly offensive, that encryption is over kill and messing with permisions is unelegant. I know this does not really protect anyone from a serious threat, But I feel that its merely a road block, Used primarily for people you know or people you have logged on to your session. Thereby knowing you could walk away for a minute or two and not worry about that file or folder.

Also this could be useful for file sharing on networks . So tell me what you guys think.
-16
votes
up equal down
Solution #1: Intergrate Something like Truecrypt(without encryption) Into Nautilus
Written by mwillams73 the 2 Aug 09 at 23:01.
I am no developer, but it seems to me that if you can alter true crypt or something like it into nautilus ( with options to encrypt or not to encrypt) that would be rather simple, But as i said I'm not a developer.

I guess it could be like an add on and you can invoke whether you want to use it inside edit preferences. And from there you could also decide whether it uses encryption or just a password. But any way that ist used it should be a default add on to nautilus, if im not mistaken true crypt isnt a very large file and with it being open source and all I dont see why it couldnt be remixed and intergrated into nautilus.
27
votes
up equal down
Solution #2: Keep the normal file permissions
Written by aliam13_2 the 4 Aug 09 at 15:29.
You simply want to protect the files from other "trusted" users on the computer. Encryption is over the top and you are aware the files are not really secure - unless the physical computer is secure. Useful for a home environment where you want to stop family from looking at your photos easily (easily is the key part).

The permissions on files and folders are simple enough and the GUI is also simple. The user does however need to know what the terms User, Group and Other mean. This is simple to pick up and if in doubt just restrict access to only the user.

See the 7 comments or propose a solution (latest comment the 4 Aug 09 at 11:35) >>

Some otherwise good apps aren't terribly secure/privacy aware.  
Written by r0g the 19 May 09 at 23:49. New
In short, can we provide extra security/privacy for our data despite wanting/needing to use insecure apps?

Linux permissions do a good job of automatically protecting core system files from change but data privacy/security seems to be predicated on an assumption of userspace security which is generally unrealistic. At the same time for many people losing the privacy of their data can be far worse than losing their OS install or hardware. For example in my case...

I have some applications which I love but which aren't written with security in mind. The main one I'm thinking of here is FileZilla which stores all usernames and passwords as plain text but many other apps simply assume their environment will always remain private. One of the MAIN REASONS I switched to a linux based system was to get a bit more security as since I became a web developer a few years back I have stared to accumulate LOTS of other peoples web hosting credentials. This is valuable booty to some miscreants and I guess it has been standard hacker practice to scan for unencrypted ftp/ssh credentials for time immemorial but I am troubled to hear many worms and trojans now do the same as a matter of course and I would like an extra line of defense against this.

There are lots of encryption solutions, some of which I already use such as truecrypt but these don't really hit the spot as once a volume is mounted it can be read by any user/process. This means that any intrusion into my user space (say from a browser bug) while I have a truecrypt volume mounted might trivially compromise all my most private data. I'm sure we have the technology to protect against this.

Note: Please do not reply Ubuntu is secure enough already or vote this down because 'Ubuntu does not get viruses'. *nix is only that way because developers were sensible enough to take precautions before there were widespread problems. Nothing is infallible and the one thing worse than a total lack of security is a false sense of security!
46
votes
up equal down
Solution #1: Encrypted Applications.
Written by r0g the 19 May 09 at 23:49.
What I would like is a way of installing/launching an app in it's own little encrpyted file system bubble so all its settings are always encrypted and ONLY THAT SPECIFIC PROCESS can read and write to it. In essence this would be like a small truecrypt volume tied to a specific PID. Obviously it would require a key to be input from somewhere so maybe this could be kept on a keyring protected by your admin password or simply based of a very hefty hash of your admin password.

I'm pretty sure all the tricky technicals are already in place (loopback, encrypted and union file systems, access control lists, keyring) it would just needs munging together and integrating into the desktop/file browser with a nice simple interface suitable for mere humans like myself :-)
27
votes
up equal down
Solution #2: Make possibility to encrypt file by wallet.
Written by Lachu the 20 May 09 at 06:24.
Wallet should have API to generate key for configuration file/documents encryption. Application should use wallet API to operate on this files. It allows us for example to import settings from one application to another. It may only requires to open keyring and accept another application to have access into specific key. User can also disagree to encrypt some files.
14
votes
up equal down
Solution #3: Integrate gnome-keyring/kwallet with more applications
Written by Zanko the 2 Jun 09 at 21:40.
The job of storing credentials belongs to gnome-keyring (or kwallet in KDE), but many applications don't use it (Pidgin, Firefox...). Using gnome-keyring mean having credentials stored in one single place and encrypted.

Firefox for example have its own way of storing credentials, with it's own master password system, however an addon (which probably needs to be improved as it seems buggy) is available (https://addons.mozilla.org/en-US/firefox/addon/8737) and could be provided by default.

Other applications should be patched to use it.

Applications that don't want to be tied to Gnome-keyring or kwallet (like Pidgin which store passwords in plain text because it want to be portable on OS X and Windows) can use PPassKeeper, a library which provide an abstraction layer for this tools and store passwords in plain text only if they're not available.
2
votes
up equal down
Solution #4: Use selinux
Written by Lachu the 15 Sep 09 at 10:11.
Use selinux to achieve this.

See the 7 comments or propose a solution (latest comment the 29 May 09 at 01:04) >>

Allow user to Authenticate when an operation fails because of permissions  
Written by braaivleis the 22 Nov 08 at 21:32. New
If the user performs an operation and it fails because of a lack of permissions, the error dialog should not only inform the user of this but also allow the user to Authenticate himself and retry the operation.

"Pre" authentication is already in use in ubuntu in the form of the "Unlock" button in admin dialogs.

Allowing the user to retry with more permissions will make life easier.

A scenario of how this could be used:
A user tries to delete a file(s) created by root (using nautilus), the user is then told that the operation failed on a particular file because of a lack of permissions.

The error dialog will then present the options to either "skip", "skip all", "cancel", "Authenticate" and "Authenticate All". When the authenticate options are selected, the operation could be retried with the user rights entered (can even reuse the Authenticate dialog).

"Authenticate All" option will allow the user to make use of the permissions for the rest of the files.

This will save the user time because he no longer needs to go and change the permissions manually after it failed.
42
votes
up equal down
Solution #1: Auto-generated solution of idea #15877
Written by braaivleis the 22 Nov 08 at 21:32.
Ubuntu Brainstorm was updated in January 2009. Since the idea #15877 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

See the 7 comments or propose a solution (latest comment the 25 Nov 08 at 06:59) >>

Don't make Private Directory show up on Desktop  
Written by tharkban the 26 Oct 08 at 03:21. New
Don't make the Private directory show up as an icon on my desktop (or make it an option to not display it). This just advertises the fact that I have hidden data. Also add the ability to create a private directory(ies) that are password protected instead of automatically decrypted on login. This is already possible using ecryptfs it just needs a GUI interface.
30
votes
up equal down
Solution #1: Auto-generated solution of idea #14816
Written by tharkban the 26 Oct 08 at 03:21.
Ubuntu Brainstorm was updated in January 2009. Since the idea #14816 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

Add a comment or propose a solution >>