Closed Bug 19184 Opened 25 years ago Closed 12 years ago

Encrypt Bookmark Folders, Cache, etc. Inside A Profile for privacy

Categories

(Core Graveyard :: Profile: BackEnd, enhancement)

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
x86
Other
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: netdragon, Unassigned)

References

Details

(Keywords: helpwanted) 

Just in case I do not get a chance to edit the code myself ( and I could only do
it for windows), could mozilla have password protection for bookmark folders by
encrypting the content of the bookmark folder if it is protected and using some
thing like:
<PPROTECT><!--
Name:My BSites
SecretName:Budget Sites
EncryptedData:djfkdsafadjs...etc.
>
It would have to use key encryption. The data could be prefaced with an
encrypted "DTA", or something like that so Mozilla would know if it was
decrypted correctly. You could then change password, unlock and lock a
folder,and remove password protection in the edit bookmarks window. You wouldn't
have to enter the password info to lock a folder. Also, folders would be
automatically locked each time Netscape stops.
Also, when a folder is unlocked, you can choose to open a temporary copy of
bookmarks.html with the unlocked bookmarks in it.
Severity: normal → enhancement
Assignee: leger → slamm
Component: Browser-General → Bookmarks
bookmarks
Assignee: slamm → don
Summary: Password Protect Bookmark Folders → [RFE] Password Protect Bookmark Folders
Whiteboard: HELP WANTED
Target Milestone: M20
Re-assign to me for M20.
Keywords: helpwanted
Whiteboard: HELP WANTED
One wouldn't want to do just bookmarks; history, cookies, cache, and just about 
everything else in a profile should be encrypted.

I agree. 
*** Bug 32645 has been marked as a duplicate of this bug. ***
If it is encrypted and opened when the profile is opened (when the program 
starts) and placed in a directory and then deleted when the program quits or 
user changes to a different profile, what happens if the program crashes? There 
needs to be a way around that. My idea is that there will be a crashproof 
background task that isn't linked to the Mozilla task that detects when Mozilla 
crashes or closes and deletes temp files. Either that or if the files can be 
encrypted and decrypted very quickly then there is no reason not to do so 
dynamically. Since cache is rarely used and the history can be loaded into 
memory, I don't think speed will be a problem. What do you think?
Updating Summary to reflect jgmyers@netscape.com's statement
Summary: [RFE] Password Protect Bookmark Folders → [RFE] Encrypt Bookmark Folders, Cache, etc. Inside A Profile
Move to "Future" milestone.
Target Milestone: M20 → Future
Also, a password-protected profile should require you to enter a password to use 
it. It therefore shouldn't store the password unless someone tells it to. That 
way, if someone forgets to change the profile before quitting, no one will have 
access to their info (this keeps people out of others's email, etc.)
Updating QA Contact.
QA Contact: leger → claudius
Also, Mozilla should have an option on whether to always go to the 
main (passwordless) setting or go to some specific personal setting or use the 
last used personal setting. Before loading anyone's setting (which can be loaded 
from the file menu) a password must be entered, and on 3 wrong entries, the 
main (not passwordable) user setting would be loaded.
This is great for if you don't want people getting into the cache of the porn 
site you just browsed (like your wife, siblings, etc). Think about the 
POSSIBILITIES!!!
I am Meta-izing this bug. Marking it a dependant of another bug.
Depends on: 60466
updating dependency.
Depends on: profile-password
No longer depends on: 60466
There is no need to encrypt the actual files in the profile's directory. 
That would be overkill. All we need is to be able to deter someone from 
accidentally entering our profile by hitting ENTER in the profile manager. It 
will also deter 99% of people (wives, children, colleague, etc.) who want to 
take a "peek" at our mail and 
bookmarks. It would be the same feature as in NC 4.x - a simple password that 
allows entry into ones profile.

Those who are willing to read through hundreds of pages of difficult to read 
text files to read our mail will likely not be able to be deterred by encryption 
either. Please create a simple password protection for profiles for the 99% of 
us "casual" users.

This should be simple enough to implement in a near nightly build ;-)
Assignee: don → vishy
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
My comment to this bug is this should be, and is labelled as a future 
enhancement.  A nice touch,  but in a proper networked environment with roaming 
profiles, permissions, etc, not needed.  A focus on simple non-stong encryption 
of entry to a profile - bug 16489 - should be undertaken and delt with first. 
As Peter Lairo suggests, it will deter the 99% of people who are just looking 
for a quick snoop of who we're talking to and what we're looking.  This is a  
non-secure real world we live in where we're not always around to guard our 
desks/rooms from the nosey people around us.
For now, packing all the files into a jar file as was said in bug 16489 would 
be good as long as the average to somewhat advanced user couldn't decompress 
it. Maybe in the future, that jar could be encrypted in a way that no one could 
not get into the files no matter how smart they are. For now I would be happy 
if someone opens a sensitive site with a certain password using 
user:password@site form, that the cache, bookmarks, and history wouldn't be 
accessable to any nosey user. Possible other protection is for children 
visiting their Uncle's house, let's say, who has viewed porn sites lately. So 
for now, password protection of cache, history, and bookmarks from snoops would 
be fine. Maybe in the future, that can be expanded to include encryption.
Netscape Nav Triage team: changing component to profile manager. reassigning to 
ccarlen
Assignee: vishy → ccarlen
Component: Bookmarks → Profile Manager BackEnd
I think that using filtered streams (with the filter being an encryption filter)
would be the way to go. As a stream filter, no data is ever decrypted to disk so
its safe for the case of decrypt and crash. Also, it has minimal effect on the
consumers of this data. If they are consuming the data with a stream, they would
just slap a filter on this stream and read/write as if it were a normal stream.
Also, the data would be decrypted lazily. There's no need to encrypt/decrypt
until the data is needed. Problem is, we don't have an implementation of
filtered streams, much less an encryption filter. Leaving this futured.
Status: NEW → ASSIGNED
This is definetely something that should be left to the OS. Do we really want to
be crypting and decrypting files? Most OS's will hide profifes of different
users from one anther. This bug is only asking for trouble in form of crashes
and permanently lost profile information. Wait until you see users leaving
mozilla in LARGE numbers once a few cases of lost profiles start popping up on
the net....

Suggest WONTFIX.
Hiding profiles from other users is not the issue. The issue is for hiding 
profiles from people who share user names within the OS - like families. Win98 
and WinME doesn't offer any user protection either.
OK, wouldn't this then be most useful in conjunction with a profile manager
password. Without one, you're already INSIDE another#s profile.
Peter, check the depends and blocks bugs.
No longer blocks: 59120
This bug has become obsolete. Now that WindozeXP is out, all major OS's support
OS level protection of user data. All user data is not visible/accessible by
other users. The cost-benefit of introducing encrypted profiles is just not
there: Most people in the next 1-3 years will have secure profile data because
they will have switched to WinXP or (hopefully) to Linux. OTOH, encrypting data
in mozilla causes dataloss issues, increases the complexity, prevents simple
copying and editing of files (user.js, prefs.js, bookmarks, addressbook.mab, etc.)

Suggest WONTFIX.
I would very much like to see it all encrypted. I don't trust any sort of
filepermissions or user accounts, they can always be hacked. I only trust strong
standard encryption with the key in my brain. I don't see why multiple layers of
security is a *bad* thing. 
I agree - and would like to add that administrator accounts in Windows and root
accounts in Unix would have access to their users' accounts. For instance, a
network guy at a University would have access to all their users' stuff on
Roaming accounts. Now if the network guy had a vandetta against someone, it
would give them access to their information.

Also, any Administrator on Windows would also have access to any other
Administrator.
Summary: [RFE] Encrypt Bookmark Folders, Cache, etc. Inside A Profile → Encrypt Bookmark Folders, Cache, etc. Inside A Profile
Some good points (admins currently have access to users' profile data), but
these are now less severe cases, because usually admins *should* have access to
users' accounts (e.g., employee leaves comanpy and replacement employee needs
access to former employee's project e-mails). Therefore, the risk-benefit of
this bug has steeply declined. 

I do see *some* usefulness in this bug, though. Therefore, I suggest the
following two conditions:

1. This feature should be *off* by default.

2. The feature should be independant of Password Protected Profiles (i.e., users
should be able to set a profile password *without* also encrypting the profile).
I agree with 1. and 2. above, and

3. It should be possible to convert encrypted profile back to unencrypted (we 
do not like point-of-no-return situations ;-)

4. Mail folder encryption should be per folder (bug 35308).

We could offer two forms of encryption: and munging of data for privacy, and
strong encryption.

1) The munging for privacy would just mix up the cache data, etc, so you can't
view it directly if you know the file type. It should be done in a way that can
be quickly reconstructed (method such xoring with a mask the first 500 bytes of
the file and every successive 1,000th byte). This would be reversable.

2) Strong encryption would encrypt every file of the entire profile, require a
password every time you run Mozilla, and never store unencrypted data anywhere
but in memory. This would not be reversable, and if you forget your key, you are
done.
Summary: Encrypt Bookmark Folders, Cache, etc. Inside A Profile → Encrypt Bookmark Folders, Cache, etc. Inside A Profile for privacy
If you wanted to have it OS handled or handled by a third party, you could have
an option for the user to set the directories/drive/etc. for the
profile/cache/bookmarks/etc.  That way they can be directed at a encrypted
container.  For instance, I would set up a "Firefox" (or obfuscated name)
container using TrueCrypt (http://truecrypt.sourceforge.net/) or using cryptloop
in Linux.  If the user has not opened that container, then it would default to
Firefox's default profile/no history/default bookmarks, etc.  This would also
create an extra layer of security in that the snoop would be unaware that a
encrypted profile existed b/c Firefox would not be prompting them for a password
or have the profile in its list.  Security is important for a great many users
who are not simply trying to hide p0rn/games/etc.  It's valuable for users in
oppressive governments who would persecute you if you visited sites that didn't
jive with the gov't -e.g. religious sites in Saudi Arabia (religious police
behead converts from Islam), anti-gov't communications in China, and coffee and
alcohol related sites in Utah (ok, maybe that last one was a little toungue in
cheek ;-)).  Personally I think that all programs should permit users to change
the location of temp files/etc. for just these security reasons.  If the
container is not available then all settings are to default directories, etc.

If on the other hand, you want to simply encrypt the data but not obfuscate that
the data is still there and are primarily concerned about "bulking up" Firefox
too much with encrypt/decrypt code, may I suggest the Tiny Encryption Algorithm
(TEA).  It's, as the name implies, tiny - only a few lines of code to implement,
and it's very fast so it could be done seamlessly.  That's it.  My .02.  I
really hope that some kind of encryption or encryption option gets included in
Firefox soon.  Thx for all your hardwork on the project.
If XPCOM extensions could be made to modify how profiles are written, then this
could probably be implemented through a third-party extension and not add any
bloat to Mozilla proper.
Assignee: ccarlen → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: cmaximus → profile-manager-backend
Bug 588704 is related to this bug.  Especially see #27 and #28 comments for that bug.
Would it be worth considering something like SQLChiper (http://sqlcipher.net/)? It could protect things such as cookies, history + anything else contained within an SQLite file deemed worth protecting. From the reading I've done, it looks like it's fairly transparent. It wouldn't cover things not stored in SQLite files (such as bookmarks/cache), but it could be a start?
As filed, we're not going to fix this for all profile files. It may make sense to have encryption for some specific files such as the places DBs, but in terms of threat model I think OS-level file encryption saves you just about as much.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
See Also: → 1562324
You need to log in before you can comment on or make changes to this bug.