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

RESOLVED WONTFIX

Status

enhancement
RESOLVED WONTFIX
20 years ago
3 years ago

People

(Reporter: netdragon, Unassigned)

Tracking

({helpwanted})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

20 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

20 years ago
Severity: normal → enhancement

Updated

20 years ago
Assignee: leger → slamm
Component: Browser-General → Bookmarks

Comment 1

20 years ago
bookmarks

Updated

20 years ago
Assignee: slamm → don
Summary: Password Protect Bookmark Folders → [RFE] Password Protect Bookmark Folders
Whiteboard: HELP WANTED
Target Milestone: M20

Comment 2

20 years ago
Re-assign to me for M20.

Updated

20 years ago
Keywords: helpwanted
Whiteboard: HELP WANTED

Comment 3

20 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 4

20 years ago
I agree. 
Reporter

Comment 5

19 years ago
*** Bug 32645 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 jgmyers@netscape.com's statement
Summary: [RFE] Password Protect Bookmark Folders → [RFE] Encrypt Bookmark Folders, Cache, etc. Inside A Profile

Comment 8

19 years ago
Move to "Future" milestone.
Target Milestone: M20 → Future
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.)

Comment 10

19 years ago
Updating QA Contact.
QA Contact: leger → claudius
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

19 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!!!
Reporter

Comment 13

19 years ago
I am Meta-izing this bug. Marking it a dependant of another bug.
Reporter

Updated

19 years ago
Depends on: 60466
updating dependency.
Depends on: profile-password
No longer depends on: 60466

Comment 15

19 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 ;-)
Assignee: don → vishy
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 17

19 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 - 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.
Reporter

Comment 18

19 years ago
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

Comment 21

19 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

19 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

19 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.
Reporter

Comment 24

19 years ago
Peter, check the depends and blocks bugs.

Updated

18 years ago
No longer blocks: 59120

Comment 25

18 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

18 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

18 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

17 years ago
Summary: [RFE] Encrypt Bookmark Folders, Cache, etc. Inside A Profile → Encrypt Bookmark Folders, Cache, etc. Inside A Profile

Comment 28

17 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

17 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 (bug 35308).
Reporter

Comment 30

15 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

15 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 (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.
Reporter

Comment 32

15 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.
Duplicate of this bug: 460617
Assignee: ccarlen → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: cmaximus → profile-manager-backend

Updated

10 years ago
Duplicate of this bug: 521740
Duplicate of this bug: 560131

Updated

9 years ago
Duplicate of this bug: 496306

Comment 37

9 years ago
Bug 588704 is related to this bug.  Especially see #27 and #28 comments for that bug.
Duplicate of this bug: 588704

Comment 39

7 years ago
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
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
Duplicate of this bug: 1281566
You need to log in before you can comment on or make changes to this bug.