Brainstorm

Palm OS had a feature where individual items of content (e.g. notes, to-do items, contacts, appointments) could be marked as private. An app could be run to hide all private content, unhiding it only when the user types in a PIN.

Pros:

• The guest would have a more interesting experience, being able to see the main owner's desktop and at least some of his or her content, such as pictures.

Cons:

• The main owner would have to spend time marking items as private.
• Almost all apps would need to be rewritten to allow private tags (the image viewer already supports tags which could be used for this)
• The guest would still have read/write access to non-private content, so could accidentally change things

 

This solution is like the Guest Session idea, but without the /home/guest folder being wiped at the end of the session. The main owner could populate this with content that would be persistent.

Pros:

• The guest could have a better user experience with better content
• A proper persistent multi-user system could have other use cases, such as multiple family members sharing a device

Cons:

• Would involve quite a lot of work for the main owner
• As with Guest Session, apps would probably need to be recoded to not use /home/user
• Data left lying around in the other profile will continue to take up space, which the main owner may forget is there

Note that I think that discussion of a proper multi-user system probably should lie in a different Brainstorm idea, but I put this in as a solution so that it could be voted for here.

If all the to-be-protected data is in a folder, then my proposed solution might work? The idea is not only to protect the folder but also the files in it from being viewed from the apps installed on the device. This might be possible to achieve in a simple manner. For ex, lets take a simple photo viewer app! Assuming the photo viewer app only views files ending with an extension jpg/jpeg/bmp/png/raw/etc. To avoid protected data from being viewable in the photo viewer app, the extensions of those picture files in the to-be-protected folder can be changed to something other what the photo viewer app would understand (say, xyz). And the protector app will remember all these temporary mappings. The folder and also the app should be protected from being run by a secure password.

Port something like www.truecrypt.org to fremantle.  Their was a version for Diablo, so we might be able to port that version or might be able to port a newer version.

This would make any files in its "container" encrypted and unreadable without a password.   This would not be a method to protect calendar or contacts; but any sensitive information would be protected.

 

Solution #3 from here (multi-user) and Solution #1 from there http://maemo.org/community/brainstorm/view/get_encryption_average_joe_ready/ would merge just fine in my opinion.

A proper multi-user environment and a ~/[$config,$private] like symlinking setup of user-data would make the system fully useable for someone else (if user-access) but would protect all private data to the user.

This would include a startup-screen to switch users, rebuilding the user-file-environment based on symlinking all user-data to a crypted place not mountable via USB (having an exportable fs should be still an option! but not for those things normaly not exportable via USB). A crypt-management tool like EasyCrypt and so on.

A phone could have a Private and a Public profile that can be switched on the run.

 

This does nothing more than set a global flag, and allow each application to implement its own security model. For example, Images could have its own system, based on "Private" tag. Video archive could have a .videos/private folder that isn't listed if in Public mode. Calendar could hide private calendars, Email could have private and work accounts, and so on. This is similar to profiles in many implementations, where each app/game is responsible for obeying the set limits.

 

This has several advantages over complex user-based implementations:

• Virtually no increased usage on root
• Flexible implementation that is future-proof and developer-safe
• Gradual implementation (there is no need for everyone to support immediately)
• Could cover all cases, including 3rd party
• Easy implementation (minimal UI, a duplication of the profile code minus the actual setting changes)
• All apps and settings available (desktop, background, general experience - what's what we are showing off, right?)
• Instant activation, no logoff-logon cycle, stop widgets, etc. A power button plugin could do this with one click and one touch.

 

It also has several disadvantages

• No enforced security (which is out of the scope for this proposal)
• Requires developer support to work (but only for sensitive data applications)
• Already-running apps could be slow to switch