[RFC] misc. prefs

[atomGit]

hello again :)

i have some comments/questions regarding various prefs...

sec. 2701 (ETP) is currently missing from user.js, however it seems there are several prefs that are set as if ETP were present

network.cookie.cookieBehavior - should this be uncomented and set to '2'? do other prefs in section 7016 need to be revisited also?

privacy.firstparty.isolate - same as above - shouldn't this be true until ETP arrives?

calendar.timezone.local - given the calendar is now integrated and essentially useless without a correct time, and guessing that a lot of people do/will use it, i think this should be set to default

"mail.biff.alert.* - is there a reason (privacy-wise) to override user choice with these prefs?

"privacy.resistFingerprinting", true - this messes up dates/times and a few other things - given that TB is primarily a mail client, and ought to be used only for mail, and given calendar integration, i think this should be set to false

[HorlogeSkynet]

hello again :)

Hello @atomGit !

sec. 2701 (ETP) is currently missing from user.js, however it seems there are several prefs that are set as if ETP were present

network.cookie.cookieBehavior - should this be uncomented and set to '2'? do other prefs in section 7016 need to be revisited also?

privacy.firstparty.isolate - same as above - shouldn't this be true until ETP arrives?

You're absolutely right, this is a big oversight on my behalf.... I actually didn't notice the "links" between these preferences when I purged the unimplemented ones.
I'll try very soon to partially revert changes of #24, for preferences still required without ETP.

calendar.timezone.local - given the calendar is now integrated and essentially useless without a correct time, and guessing that a lot of people do/will use it, i think this should be set to default

I agree, if we assume that calendar timezone cannot "leak" through email client/Web usages.
From source, it does not seem to be used outside of calendar.

"mail.biff.alert.* - is there a reason (privacy-wise) to override user choice with these prefs?

From a privacy PoV, preventing preview/subject/sender from appearing in notifications may be required on setups where you have eyes behind your screen (e.g. at work if you are showing another window, or in case of an intimate relationship threat).

"privacy.resistFingerprinting", true - this messes up dates/times and a few other things - given that TB is primarily a mail client, and ought to be used only for mail, and given calendar integration, i think this should be set to false

I agree that RFP can be boring, but I'm not keen about disabling it. If a Web remote content is loaded from an email and/or a Web page ends up loaded in TB built-in browser, RFP helps mitigate many (most of ?) fingerprinting techniques widely used.
I think the template should enable it and that it should be up to users to explicitly accept risks by disabling it.
Maybe as a trade-off, what about documenting RFP side-effects related to TB, next to preference enabling it (with a SETUP-FEATURE tag) ?

---

Thanks again, bye 👋

[atomGit]

i would vote for dumping the mail.biff.alert.* prefs i think

as for RFP, i understand

[HorlogeSkynet]

Hey back @atomGit

After some diggings, see below my points :

• For ETP, I've opened Workaround ETP Strict Mode lack of support in 102 #28 I'd like your review before merging it.
  Note : the CardBook wiki page has been updated according to network.cookie.cookieBehavior revert ;

• For calendar.timezone.local, it appears this preference had been to set to UTC to prevent the guessSystemTimezone function to be called, as it "rumag[es] through the user's actual file-system, to figure out the time-zone they're in"...
  As the preference already got a SETUP-INSTALL tag, I'd vote against touching it at the moment.
  The template also notes that users may even set it to their current TZ.

• I've reset mail.biff.alert.* preferences in 08713b3 ;

• As for RFP, I actually noticed that timezone spoofing actually does not affect calendar integration (TB v102.3.1 here) : once the correct timezone has been set with the other preference, the current time was OK.

Are we all good here ? Thanks again ! Bye 👋

[atomGit]

it all seems good to me

... noticed that timezone spoofing actually does not affect calendar ...

yes, sorry, i messed up - i meant email timestamps - and just to reaffirm, i agree that RFP should be left enabled

[HorlogeSkynet]

Released as v102.1 🎉
Thanks again @atomGit, see you 👋