43
Encrypt Bookmark Folders, Cache, etc. inside a profile for privacy
source link: https://www.tuicool.com/articles/hit/EJVFZvz
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
(Reporter)
Description
19 years ago
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.
Updated
19 years ago
Assignee: slamm → don
Summary: Password Protect Bookmark Folders → [RFE] Password Protect Bookmark Folders
Whiteboard: HELP WANTED
Target Milestone: M20
Comment 3
19 years ago
One wouldn't want to do just bookmarks; history, cookies, cache, and just about everything else in a profile should be encrypted.
(Reporter)
Comment 5
19 years ago
*** <a title="VERIFIED DUPLICATE - Cache Dir - Profile Manager" href="/show_bug.cgi?id=32645">Bug 32645</a> has been marked as a duplicate of this bug. ***
(Reporter)
Comment 6
19 years ago
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?
(Reporter)
Comment 7
19 years ago
Updating Summary to reflect <a href="mailto:[email protected]">[email protected]</a>'s statement
Summary: [RFE] Password Protect Bookmark Folders → [RFE] Encrypt Bookmark Folders, Cache, etc. Inside A Profile
(Reporter)
Comment 9
19 years ago
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.)
(Reporter)
Comment 11
19 years ago
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.
(Reporter)
Comment 12
18 years ago
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!!!
sairuh (rarely reading bugmail)
Comment 14
18 years ago
updating dependency.
Depends on:16489
No longer depends on:60466
Comment 15
18 years ago
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 ;-)
Comment 16
18 years ago
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Comment 17
18 years ago
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 - <a title="RESOLVED WONTFIX - Password Protection of Profiles" href="/show_bug.cgi?id=16489">bug 16489</a> - 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.
(Reporter)
Comment 18
18 years ago
For now, packing all the files into a jar file as was said in <a title="RESOLVED WONTFIX - Password Protection of Profiles" href="/show_bug.cgi?id=16489">bug 16489</a> 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.
Marcia Knous [:marcia - needinfo? me]
Comment 19
18 years ago
Netscape Nav Triage team: changing component to profile manager. reassigning to ccarlen
Assignee: vishy → ccarlen
Component: Bookmarks → Profile Manager BackEnd
Conrad Carlen (not reading bugmail)
Comment 20
18 years ago
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
Comment 21
18 years ago
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.
(Reporter)
Comment 22
18 years ago
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.
Comment 23
18 years ago
OK, wouldn't this then be most useful in conjunction with a profile manager password. Without one, you're already INSIDE another#s profile.
Comment 25
17 years ago
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.
Comment 26
17 years ago
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.
(Reporter)
Comment 27
17 years ago
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.
Updated
16 years ago
Summary: [RFE] Encrypt Bookmark Folders, Cache, etc. Inside A Profile → Encrypt Bookmark Folders, Cache, etc. Inside A Profile
Comment 28
16 years ago
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).
Comment 29
16 years ago
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 (<a title="NEW - password and encrypting protecting for mail folders" href="/show_bug.cgi?id=35308">bug 35308</a>).
(Reporter)
Comment 30
14 years ago
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
Comment 31
14 years ago
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 (<a rel="nofollow" href="http://truecrypt.sourceforge.net/">http://truecrypt.sourceforge.net/</a>) 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.
(Reporter)
Comment 32
14 years ago
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.
Reed Loden [:reed] (use needinfo?)
Updated
10 years ago
Assignee: ccarlen → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: cmaximus → profile-manager-backend
Comment 37
8 years ago
<a title="RESOLVED DUPLICATE - Lack of cookie encryption security hole" href="/show_bug.cgi?id=588704">Bug 588704</a> is related to this bug. Especially see #27 and #28 comments for that bug.
Comment 39
6 years ago
Would it be worth considering something like SQLChiper (<a rel="nofollow" href="http://sqlcipher.net/">http://sqlcipher.net/</a>)? 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?
Comment 40
6 years ago
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
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK