Mitchell Stoltz wrote:
> Any installed application imposes some constraints on directory
> structure, and Mozilla is no exception. Maybe I don't like the fact
> thet the Mozilla binary has to be in the same directory as its
> associated files (like the chrome directory). Tough turkey - it won't
> run otherwise. I don't see how salting is any different.
Exactly. After all, the user can specify, where the profile (incl.
salting dir) should go.
> That said, in light of all the complaints, what I would like to do is
> get rid of the salt directory and do the following: Assume that if a
> profile name is something other than "default," then it's reasonably
> unpredicatble and doesn't need salting.
Personally, I would prefer more unpredictability. My profile could be
named "Ben", and if somebody starts an attack targetted at my
personally, it would not be hard to guess.
I don't want to use Ben_abcd1234 as profile name, because that will
appear in the ProfileSelector.
But we could skip the salting dir whenever the user explicitly specifies
a profile dir. I would consider it "natural" that we don't use a salting
dir in that case. The user has an intuitive way to avoid the salting
dir, and we didn't even had to add any pref :).
This would also solve the problem: If I want to reuse an old profile,
should I target the dir of the newly created one at the dir with the
profile name "<somepath>/Ben/" or at the salting dir
"<somepath>/Ben/a1b2c3d4" of the old profile?
