User.js: MOAR stuff to look at

[Thorin-Oakenpants]

From @bogachenko 's PR ( #532 )

• NAH: Promotional links need to be removed?
  
  
  
  • https://hg.mozilla.org/integration/mozilla-inbound/rev/1a5fd94651fb
  
  
  • user_pref("identity.mobilepromo.android", "");
  
  
  • user_pref("identity.mobilepromo.ios", "");
  
  
• NAH: Device Storage API
  
  
  
  • user_pref("device.storage.enabled", false);
  
  
• NAH: File Handle API
  
  
  
  • https://developer.mozilla.org/en-US/docs/Web/API/File_Handle_API
  
  
  • user_pref("dom.fileHandle.enabled", false);
  
  
• NAH: disabled warning about:networking
  
  
  
  • user_pref("network.warnOnAboutNetworking", false);
  
  
• NAH: new hardware acceleration settings (disabled by default) added
  
  
  
  • user_pref("webgl.force-enabled", false); // default false
  
  
  • user_pref("webgl.msaa-force", false); // default false
  
  
  • user_pref("layers.acceleration.force-enabled", false); // default false
  
  

From the Big E (revisit these)

• [x] security.tls.version.min - https://github.com/ghacksuserjs/ghacks-user.js/commit/0cc4007eda10a92dadbe8d3548a06a16c21a1d7b
• [x] full-screen-api.enabled - https://github.com/ghacksuserjs/ghacks-user.js/commit/b85e748b532086a28fc69524223bde1e1e6e8c76
• [x] permissions.default.geo - https://github.com/ghacksuserjs/ghacks-user.js/commit/4e42bad6a13ba8a840a61e5807ea0d3ddd162690

From :jeans: (revisit these)

• media.autoplay.default: make inactive and move to 5000s
  
  
  
  • not just yet. In 64 or 65 the default will be a prompt, move it then so there is no disruption to current users
  
  
• [x] permissions api & FP'ing - https://github.com/ghacksuserjs/ghacks-user.js/commit/c12eb0fdc6ccd898298ee7094aca5a05fc4d3b42
• [x] browser.eme.ui.enabled - https://github.com/ghacksuserjs/ghacks-user.js/commit/36b90cd5e6bc71a2c214da81060c4d8e2673f69d
• [x] browser.crashReports.unsubmittedCheck.autoSubmit - https://github.com/ghacksuserjs/ghacks-user.js/commit/299a03663fb70673d017f82058e4ba97910f6d54

[bogachenko]

Device Storage API
https://wiki.mozilla.org/WebAPI/DeviceStorageAPI
https://bugzilla.mozilla.org/show_bug.cgi?id=1046258
https://bugzilla.mozilla.org/show_bug.cgi?id=886627

[Thorin-Oakenpants]

and from earthlng

ps: other things off the top of my head that make us pretty unique for no good reason IMHO ...

• security.tls.version.min = 3
• full-screen-api.enabled = false

FP'ing is overrated (but a growing threat). When looking at FP'ing we always take a worst case scenario, but in reality (I'd have to dredge up some reports, but the gist in my head is:) there is so much low hanging fruit that the small percentage of sites that do attempt to FP, use more conventional means, and controlling 3rd party and JS mitigates the vast bulk of it. But it is an arms race. That said, I'm surprised more metrics/bits aren't grabbed (if they really wanted to, we'd ALL be unique - think client rects, fonts (eg that browserspy font/glyphs test), more res metrics (inner / outer / screen / available screen / viewport+scrollbar), feature detection and more.

TLS configs (just like cipher suits) can be gotten without JS, and yes, it would raise entropy from defaults. Given that only approx 2% (from memory) of sites use TLS1.0 or 1.1, and that it's not inherently a security risk (right? TLS1.0 and 1.1 are still secure), and that all this setting does (by enforcing a minimum of 1.2) is break sites for users who would then simply open it in a secondary browser, and that FF & Chrome will deprecate it in time, I'm inclined to agree that the default is actually fine, and that we could just make the pref inactive

Full screen api is governed by JS, and can leak your real screen res. It's not the fact that you lied (they can already get that info if they wanted), it's leaking the actual real screen res. IIRC if requires user interaction (and thus not part of any real FP suite, but youtube would grab that shit for sure) and I doubt it's used anywhere except the likes of video navigator bars - eg netflix, youtube - in which case the end-user want his/her damn video in full screen for a reason. So we could relax it - but I think it's better to do this in a relaxed version. Debatable.

It would be nice for a per site permission to allow FS - maybe that's what they could do to resolve https://bugzilla.mozilla.org/show_bug.cgi?id=1450401

Edit: also when https://bugzilla.mozilla.org/show_bug.cgi?id=1407366 lands and they dynamically control the viewport, then this could certainly go under RFP alts

[bogachenko]

https://bugzilla.mozilla.org/show_bug.cgi?id=1450401

Posted by 8 months ago

maybe that's what they could do to resolve

maybe

---

security.tls.version.min = 3

https://blog.torproject.org/new-sslv3-attack-found-disable-sslv3-torbrowser
https://blog.torproject.org/comment/271978#comment-271978

In TOR version 1

full-screen-api.enabled = false

https://trac.torproject.org/projects/tor/ticket/12609

still included in TOR

[Thorin-Oakenpants]

I appreciate what TBB do, but TBH, TBB & FF are different tools. If your threat model is that serious, then you should be using TBB.

https://blog.torproject.org/new-sslv3-attack-found-disable-sslv3-torbrowser - the default value in FF60+ is already 1, so this 4 year old article is moot. SSL3 is not used.

[Thorin-Oakenpants]

network.warnOnAboutNetworking was brought up in #442 (expand part5 of the ~~first~ second post) . It's a one off checkbox for those who visit about:networking, just uncheck and hit OK. Nothing to do with privacy or security

[bogachenko]

aa okey

[Thorin-Oakenpants]

identity.mobilepromo.* was brought up in the same issue (in part4). No need to blank these either.

[bogachenko]

yes now I see. just thought - advertisement

[bogachenko]

this is also webgl.force-enabled part 3

https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers

at the very end of the page

[Thorin-Oakenpants]

yes now I see. just thought - advertisement

I'm not entirely sure what it does but it's not a security or privacy risk. It won't be for advertising, except inhouse - and if Mozilla need to tell mobile users of something, I don't see that as a bad thing

---

device.storage.enabled is default false (brought up Part 3 of the same issue). Pretty sure we've covered this as well, and it's been at false for a very long time. No need to clutter up the user.js (we've been trying to remove extraneous items for ages).

edit: that first bug shows it was false at least 4 years ago on desktop. The second bug (also 4 years old) shows they patched it for android. You're already fukked on a smart phone :) and I suspect it would break things

[bogachenko]

Mozilla need to tell mobile users of something, I don't see that as a bad thing

I would argue

---

OK, and the rest?

[Thorin-Oakenpants]

If you look here: https://hg.mozilla.org/mozilla-central/rev/c55670d2c8a7 you can see that the "promo" is just helpful stuff about devices and is linked to signed in users. That's about as far as I need to dig to know this is not an issue

[Thorin-Oakenpants]

The three prefs webgl + layers.acceleration are at default. Again, no need to clutter the user.js, and they're covered under master prefs. We've most likely covered them somewhere already (webgl.force.enabled is in Part3 of that issue)

[bogachenko]

My English is running out.
I am against any display of updates, banners, notifications. I do not want that my browser (at start, and especially at work) was connected on the third party or to shit NOT a direct task.
this is who I am.

Whatever the outcome, you're right, this is your repository = your rules. My (no one unnecessary opinion) I will keep to myself

[Thorin-Oakenpants]

dom.fileHandle.enabled is default true (on Windows desktop at least), but I don't like the association of this with IDB. Needs more investigations. Seems like a very old unsupported API

[Thorin-Oakenpants]

@bogachenko No problems here buddy: suggestions are always welcome :) If you want to block those, then go ahead. But they're not a privacy or security issue IMO.

[bogachenko]

Well, with the "Pull requests" I hurried. hahha

[Thorin-Oakenpants]

this is also webgl.force-enabled part 3

https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers

at the very end of the page

thanks for the link, and I quote:

If you would like to forcibly enable a graphics feature that is blocked on your system, follow these instructions. Warning: do this at your own risk. There usually are good reasons why features are blocked.

• To force-enable WebGL, go to about:config and set webgl.force-enabled=true.
• To force-enable WebGL anti-aliasing, go to about:config and set webgl.msaa-force=true.
• To force-enable Layers Acceleration, go to about:config and set layers.acceleration.force-enabled=true.

So, these are default false, which is what we want. We don't want to fill the user.js up with every single pref (there's 3.5K of them currently still used). I guess we could enforce them at false, but its just more work, more prefs to read thru for users, and more (irrelevant?) troubleshooting for end-users to deal with if they have some sort of problem.

[crssi]

About promo links and even telemetry... lets say we trust mozilla and anonymizing those data, then I do not see any reason to block those, since mozilla also needs feedback to make things better... whatever you decide is just fine.

File Handle API looks quite dangerous. I do not see any reason that some 3rd party stuff can make/modify files, even if its sandboxed or limited only to firefox profile. It smells like hell to new supercookie and other abusements.

I would disable security.tls.version.min and the same with full-screen-api.enabled.
What you have wrote about those make total sense and I have full screen relaxed for a long time and was always in doubt about TLS min.

[bogachenko]

@crssi
1 telemetry is good, but not for everyone. mozilla Has a bugreport, github issues, there is (in the end of it all) Firefox Nightly.
but for ordinary (mortals) there is no.

2 ye

3 full-screen-api.enabled disable uncomfortable. YouTube / twitch is crying. but still need, especially with the included protection from fingerprints browser. it is strange that it is included in TOR. apparently patches issued for circumvent this anal umbrella over. I hope and believe (and most importantly prepare) perhaps mozilla will release

[crssi]

@bogachenko

1. also mortals IMHO, mozilla need to know what is used and what is not to make the used things better and to drop things not used. I am not calling for a change here and the current ghacks prefs are good, I was just saying, no need to go further here. ;)

1. You haven't understood me ;)... disable is not setting it to false. In ghacks user.js it means to comment that pref out. So it stays at default (whatever it is) or user does the change to whatever he/her wish.
   I am using this as True.

Cheers

[bogachenko]

@crssi

1.can argue about that fooooooooooorever.

1. english english english

Cheers

[Thorin-Oakenpants]

disable is not setting it to false

Actually, we prefer to use the term "inactive". Edit as in we comment it out. Also, just saying enable/disable a pref is ambiguous, as prefs can have negative words: eg:

• extensions.screenshots.disabled
• extensions.pocket.enabled

setting false on both "enables" one and "disables" the other

[crssi]

Doh... stupid me. :smile:

Thx Thorin

[Thorin-Oakenpants]

https://bugzilla.mozilla.org/show_bug.cgi?id=859704#c4

However FileHandle is not enabled on B2G by default, one needs to toggle "dom.fileHandle.enabled" pref.

https://bugzilla.mozilla.org/show_bug.cgi?id=771288 - so it looks like this was added in FF43+ (the API might be old, but the pref looks to be have been added in this ticket? and for a different purpose)

I would have to have a bit of a look at DXR when it's back up (seems to be down for me), but as I said before, this is too closely tied to IDB and storage. I think it would break things internally.

Edit: So I managed to finally get into DXR and on central it's in two places (besides tests and all/grep prefs)

• dom/indexedDB/ActorsParent.cpp (this page made my CPU spike to 100% and wouldn't fully load, but I did see a little of it)
• dom/indexedDB/IndexedDatabaseManager.cpp

I'm just not sure what calls these files and if its used internally. I'd need the Big E to have a look

[Thorin-Oakenpants]

full-screen-api.enabled. I see two factors here

• can availability of the FullScreen API be detected without user interaction (its been available since FF9 and Chrome 15)?
• can it be triggered without user interaction (additional screen res measurements can't be grabbed unless it goes FS)?

If FS API can be detected purely from JS, then hell yeah, disabling it would stick out (but who the heck would check for that as part of FP'ing?). But then if FS can't be triggered without user interaction then at least that is some fallback. Note though that just a simple mouse click can be used to do just that - steal your real screen res ( see big e's clickjacking here: https://github.com/earthlng/testpages/blob/master/docs/fullscreen_leak.htm )

Note: users can still use F11 etc to manually go full screen, but that's the browser, not the video window. So I can see an annoyance factor here.

I can't really make any decision until I know the answers to the 2 points above

[Thorin-Oakenpants]

OK, I think I know the answer to 1

hdr.innerText = (document.mozFullScreenEnabled) ? "enabled" : "You're not using Firefox or you've disabled the Fullscreen API"

Looking at https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API, this is/will be controllable under Feature Policy

[claustromaniac]

Element.requestFullscreen()

Note: This method must be called while responding to a user interaction or a device orientation change; otherwise it will fail.

[Thorin-Oakenpants]

OK, that's what I thought (device orientation, oh, that I didn't know). So I think Big E makes a valid point

Disabling the API makes you stick out (if anyone wanted to use that for entropy), assuming you allowed JS. And it still requires the user to interact to actually go FS.

I think it's highly unlikely anyone uses the FS API state for FP'ng (maybe youtube?), I also think it's highly unlikely anyone uses sneaky mouse clicks or movements to steal your full screen res (you would notice you screen flicker or go to and stay in full screen). So it's one of those things where making the pref inactive (or active) probably doesn't really achieve anything. Except when inactive it doesn't piss off end-users who want this feature.

So yeah, I think we can do that

[Thorin-Oakenpants]

just waiting in the Big E to tell me all about File Handle API

[crssi]

OT or maybe not (due to FS)... does user_pref("media.autoplay.default", 1); really need to be active?

[Thorin-Oakenpants]

Not OT at all. TBH, I don't think autoplaying media is a really a security or FP'ing issue (back in the flash days it was for sure), but seriously ... who ever wants auto-playing media .. it's the scum of the internet. IDK, maybe 2030+2031 should in the personal section? Although it makes sense where it is for convenience sake

[bogachenko]

@crssi I was having trouble playing the video. watched, or rather wanted to see the (pirated) movies to different sites. player refused to work. Thought that broke that that in the adblock list = no. then I thought that because of blocking third-party cookies (Firefox 63) = nope.Disable this setting (by process of elimination, trial and error) = works

_upd_ Actually, I turned off this pref. (although it was on youtube and twitch ooooh, how useful)

_upd_ in fact, in OLDER versions of firefox was a very good expansion block (ungodly) flash player and html5.

[crssi]

@bogachenko obviously we are in the same club about expressions in english, I am also not good at that.
I didnt understand what is your verdict in your last post.

The player refused to work when user_pref("media.autoplay.default", 1);?

I know I had numerous problems in the past with upper set, but did tried yesterday all kind of video providers I could remember and there were not problems. It looks like mozilla has sorted out those in the last year or two.

FF now does not start to play until tab focus anymore.
In addition... lately (last year) I haven't seen any site to auto play, except there where I wanted and expected so.
That said, , I kind don't hate it anymore and default is OK with me.

Cheers

[bogachenko]

@crssi

obviously we are in the same club about expressions in english, I am also not good at that

like this? You're all English speaking here. British / Canadians / Americans and Australians. Not? hm
_my English is ~bed~ bad. And (drunk) google translate is even worse_

---

The player refused to work when user_pref("media.autoplay.default", 1);

at 1 it did not work, at 0 all is well
The player STARTED working when user_pref("media.autoplay.default", 0); yeah

I'm just saying that some sites break down. Perhaps that is the fault of the company that makes the player (not the Mozilla Foundation), who then use sites with pirated videos.
just as a fact. this pref _SOMETIMES_ breaks reproduction

I put 0. Now there are no problems with playback. or I did not find

from Russia with love

[Thorin-Oakenpants]

Just for kicks ..

• here's the original ticket, FF15+ 726593: Implement FileHandle
• Updated in FF33

[Thorin-Oakenpants]

I'm convinced there is no issue with FileHandle API. If anyone wants to dig deeper then by all means, go ahead

Edit: for the record, the value in TBB7.x and 8.x are both default true

[earthlng]

does user_pref("media.autoplay.default", 1); really need to be active?

they're working on making it default-prompt which should land soonish. see meta bug - only 4 open tickets left atm
Until then you can use site permissions to allow autoplay on sites that break with 1.

If you want to test the new prompt-based autoplay even though it might not be fully polished yet, you can do so by setting the prefs like this:

// Switch block autoplay logic to v2, and enable UI.
pref("media.autoplay.enabled.user-gestures-needed", true);
// Allow asking for permission to autoplay to appear in UI.
pref("media.autoplay.ask-permission", true);
// Set Firefox to block autoplay, asking for permission by default.
pref("media.autoplay.default", 2); // 0=Allowed, 1=Blocked, 2=Prompt

[earthlng]

found another one that makes us stand out more than necessary for no good reason:

0201b: user_pref("permissions.default.geo", 2);

permissions can be read by sites and AFAIK RFP always rejects geolocation requests with "denied" anyway. I'm not sure if RFP geolocation can be overruled with site permissions but either way I think we should enforce the default permission which is prompt.

test: press ctrl+shift+k and run this

navigator.permissions.query({name:'geolocation'}).then(e => console.log("permission for geolocation:", e.state, "(default is prompt)"));

[Thorin-Oakenpants]

So, to summarize

• geo is not a threat in any way, because it is always behind a prompt (by default), so 0201 is not required
• by changing geo to always block, it can be detected
• RFP overrides all geo, and acts as if the user blocked it (as per the associated ticket)

So what I want to test is what the fuck am I looking for with this

• RFP off + permissions.default.geo=0
• RFP off + permissions.default.geo=2
• RFP on + permissions.default.geo=0
• RFP on + permissions.default.geo=2

Are there meant to be different results?

[Thorin-Oakenpants]

On all four combinations I get the same result. I tested this in a nilla FF64 and even restarted FF between changes to values

-- Promise { <state>: "pending" }
permission for geolocation: granted (default is prompt)

[Thorin-Oakenpants]

AFAIK the permissions.default.geo is just the state to return. RFP returns denied and overrides everything else, 2=block (which is just another word to say you denied it). There's no difference.

geo.enabled=false would be detectable, as that kills the API, but we don't do that because when the default prefs came out I added em all and flipped geo.enabled top inactive for this reason

[Thorin-Oakenpants]

please 'splain!

[earthlng]

No idea why you always get "granted". Did you test it on a site where you set a site permission for geolocation?
RFP doesn't affect the outcome of querying the permissions with that command.
permissions.default.geo=0 -> should return "prompt"
1 = "granted"
2 = "denied"
that's also what I see in my beta and I don't think anything related to this changed since FF63.

[earthlng]

There also seems to be a bug with the implementation in that it always reports the default permission instead of the actual permission set in Page Info->Permissions, fe
permissions.default.geo=0 -> test: reports "prompt"
set site permission to block for that domain, refresh or load the same page in another tab, ctrl+shift+k again and test still reports "prompt".
Makes the whole permission api kind of useless

[Thorin-Oakenpants]

RFP is not a factor) in FF63+ (or shouldn't be)

Did you test it on a site where you set a site permission for geolocation

Why do I need to test it on a site? I was setting the global pref and not using site permissions. The script you gave is doing the asking? Also, if I gave it permission I'm defeating the purpose of the test to detect the state of the pref.

Makes the whole permission api kind of useless

So it doesn't matter then what we set (ask or block)?

edit: I don't have GPS capabilities on my desktop machine. Would that make a difference?

[earthlng]

Why do I need to test it on a site?

ctrl+shift+k allows you to run code in the context of that site (where you clicked ctrl+shift+k).
I guess you always see "granted" because you ran it on about:config, right?
You need to test it on a real site, not a privileged page like about:config.
Sorry I should've mentioned that, I forgot that you're totally clueless when it comes to these things :trollface: ;)

if I gave it permission I'm defeating the purpose of the test to detect the state of the pref.

not really. I assumed the whole purpose of the permissions API is to allow sites to query if they have a certain permission but it apparently doesn't take site permissions into consideration.

So it doesn't matter then what we set (ask or block)?

it matters what we set as default

I don't have GPS capabilities on my desktop machine. Would that make a difference?

no

[Thorin-Oakenpants]

I guess you always see "granted" because you ran it on about:config, right? You need to test it on a real site, not a privileged page like about:config.

No. I actually ran it on a web site (which didn't want or ask for geo), but that shouldn't matter IMO. The script is doing the asking (in the context of the unprivileged page).

I assumed the whole purpose of the permissions API is to allow sites to query if they have a certain permission

I assume the permissions is not for websites to query, but for FF internally to decide if it want s to grant geo, prompt, or auto-block it. Maybe auto-block is the same as prompt without the prompt showing, i.e no difference to state, because the user never gets to click deny etc (if that makes sense)

[Thorin-Oakenpants]

Anyway, doesn't matter. The pref is there for users who get prompt fatigue. The more prefs we have at default the better anyway.

[Thorin-Oakenpants]

Of course a site permissions override will also make you stick out (on that site). But looking at defaults (ignore my cookies which I block by default, and the image is opened on github where I override with allow)

A default new profile and the user.js match except for Automatically Play Media with Sound. I'm not sure why a nilla profile shows nothing checked in Set Cookies as the default. But we already know that cookies (true/false) is already a metric that is used in Panopticlick (and other FP'ng tests).

But what about Automatically Play Media with Sound - which is the only one we differ on. I actually think we should make this inactive, and even move to 5000s - its not a security or privacy risk per se (you've already connected to it). If a site gets particularly annoying, users can use a site permission override

Also, for the four or five default settings (camera/mic/geo/etc), do they all leak the default setting? Can we test them. Should we add a warning that changing from default prompt can be FP'ed?

[earthlng]

as of FF64 the permissions API itself only supports geolocation, notifications/push and persistent-storage.

1-liner for the Permissions API to query all permissions currently listed at https://developer.mozilla.org/en-US/docs/Web/API/Permissions/query:

for (const a of [ 'accelerometer', 'accessibility-events', 'ambient-light-sensor', 'background-sync', 'camera', 'clipboard-read', 'clipboard-write', 'geolocation', 'gyroscope', 'magnetometer', 'microphone', 'midi', 'notifications', 'payment-handler', 'persistent-storage', 'push' ]) navigator.permissions.query({name:a}).then(e => console.log("permission for", a, ":", e.state)).catch(console.log);

Don't run it on a privileged page ;)

camera and mic permissions are probably queryable but would need certain prefs enabled like media.navigator.enabled

Should we add a warning that changing from default prompt can be FP'ed?

:+1:

[Thorin-Oakenpants]

:+1:

Which ones?

[Thorin-Oakenpants]

Don't run it on a privileged page ;)

Nice.

[earthlng]

"prompt" all of a sudden eh? ;)
you did run it on a privileged page when you got all "granted", didn't you, little liar? liar liar :jeans: on :fire:

[earthlng]

Which ones?

0201b + 2305

[Thorin-Oakenpants]

you did run it on a privileged page

Well fuck. Now I'm not sure. I had the console open in a new window, on my secondary monitor, and I had about:config open to check flip prefs in the tests. I could almost pinky swear I used the right tab. The tests were done on a new 64 profile. The above was done in my main pimped FF63

[Thorin-Oakenpants]

lets remove browser.eme.ui.enabled 1830. It's not relevant. PS am going thru checking all the [SETTING] info

Also, bump ... media.autoplay.default: make inactive and move to 5000s

[bogachenko]

@Thorin-Oakenpants

media.autoplay.default make inactive

what for? your buddy @earthlng wrote good settings.

// Switch block autoplay logic to v2, and enable UI.
pref("media.autoplay.enabled.user-gestures-needed", true);
// Allow asking for permission to autoplay to appear in UI.
pref("media.autoplay.ask-permission", true);
// Set Firefox to block autoplay, asking for permission by default.
pref("media.autoplay.default", 2); // 0=Allowed, 1=Blocked, 2=Prompt

which "it seems" helped me. not sure. but so far there are no problems. maybe I'm search bad?

---

lets remove browser.eme.ui.enabled 1830. It's not relevant. PS am going thru checking all the [SETTING] info

https://bugzilla.mozilla.org/show_bug.cgi?id=1127784
https://support.mozilla.org/en-US/questions/1164682

when TRUE (and rebooting the browser) nothing has changed
no plug-in, no tick in settings
hm

[Thorin-Oakenpants]

@bogachenko - because autoplaying media has nothing to do with security (it is assuming you want the video, so it has nothing to do with DRM etc) or privacy (you have already loaded/connected to it etc)

The user.js is about security, privacy, anti-FP'ing, tracking etc. Anything that does not fit that, should go in 5000s as inactive. It's a personal choice.

[bogachenko]

@Thorin-Oakenpants hell, I constantly forget about it ... my fool

[Thorin-Oakenpants]

lets remove browser.eme.ui.enabled 1830. It's not relevant.

Again, it has nothing to do with the user.js. It is only a pref to show/hide the UI. The real pref that matters is media.eme.enabled. By hiding the UI it just complicates matters for end users.

[bogachenko]

@Thorin-Oakenpants oke

[Thorin-Oakenpants]

I constantly forget about it ... my fool

No problems here buddy. If you have a question, by all means ask. Always challenge something if you think it's wrong, or can be done better :+1:

[Thorin-Oakenpants]

538 @earthlng - just squash and merge it if you think it's all good

[bogachenko]

@Thorin-Oakenpants

If you have a question, by all means ask.

taking an opportunity, do you understand in the shell? I created a question here ... #537
this does not apply to security and privacy

[Thorin-Oakenpants]

^^ Nope, I'll leave that to claustromaniac overdodactyl earthlng et al

[bogachenko]

@claustromaniac @earthlng @overdodactyl

[Atavic]

Been there, done that.

[Woofy-Wolf]

Hi, and thank you for your never-ending work on ghacks.

mozilla also needs feedback to make things better

telemetry is good, but not for everyone.

I'd like to enable a minimum level of telemetry, to contribute data that supports privacy-centric efforts at Mozilla, but I don't want to over-share. I _think_ the least possible level of sharing is achieved with:

user_pref("toolkit.telemetry.unified", true); // 330
//user_pref("toolkit.telemetry.server", "data:,"); // 330 (comment out and reset in about:config)
user_pref("datareporting.healthreport.uploadEnabled", true); // 333

Can you tell me if this is right? Or, can the "health report" be sent with toolkit.telemetry.unified = false?

[bogachenko]

user_pref("security.OCSP.require", true);

This option breaks some sites. sucks

if you do not turn it off .. you have to clean it every time - cert9.db

[bogachenko]

What do you say about this?

The "screenshot --imgur" command, with the help of which it was possible to publish screenshots on Imgur.com
user_pref("devtools.gcli.imgurClientID", "");
user_pref("devtools.gcli.imgurUploadURL", "");

[Thorin-Oakenpants]

security.OCSP.require

I know. I override it myself back to default false. Wat's that blue button in English? I might flip mine back to true, but only if I can temporarily bypass it when I get errors. At least I would get an idea of how much breakage

screenshot & imgur

I don't say anything about it. Clearly the user wants to use Imgur, nothing I can do to protect them

[Thorin-Oakenpants]

@Woofy-Wolf I'm not sure at all. datareporting.policy.dataSubmissionEnabled (0334) might be needed. And if you read 0330, then for minimum telemetry you would want .united as false but .enabled as true.

[bogachenko]

@Thorin-Oakenpants blue button - "Try again."
Is this setting generally necessary?
As I said the problem it disappears for a while if you remove cert9.db and then again.

It's unpleasant, but if it's very IMPORTANT... you probably don't need to remove this setting

[earthlng]

devtools.gcli.* all got removed in FF64

@Woofy-Wolf extended telemetry is force-disabled in Release versions anyway so if you want to enable basic telemetry I think you'll probably have to comment-out and reset all of 0330, 0333 and 0334.
But don't force-enable anything because fe 0380 is nightly-only and if you send them data from release versions you'll stand out and possibly confuse them with errors that they can't replicate in nightly.

[Thorin-Oakenpants]

@bogachenko The default in FF is false, it's obviously not ready for prime time. I override it myself. I don't think the threat is major, but it depends on your threat model. 99.99999% of the world is ok with it being disabled (I doubt the other major browsers have this enabled because breakage is akin to losing users - I believe the threshhold for flipping or removing features is 0.3%, maybe lower for chrome)

[bogachenko]

@Thorin-Oakenpants well disable, so disable.
ps: in the tor browser is also disabled

[Thorin-Oakenpants]

Tor browser has a different threat model, but not surprised - TBBv8.* is such a mess, they still have a lot of changes to check on, not just new features/APIs, but even just prefs. The change from 52=>60 is massive.

Just in case, I'll clarify what I meant .. using disable/enable with prefs can be fraught with danger, especially if the pref name has a negative in it, reversing the meaning of the boolean word.

• security.OCSP.require = false = disabled (this is the FF default, and this is what I use in my overrides)

[bogachenko]

@Thorin-Oakenpants I understood you

[Thorin-Oakenpants]

@earthlng Maybe start a new ticket, but we have 36 [WARNING] labels in the user.js - that seems excessive. We don't have one on security.OCSP.require (maybe we should). Now some of these are on prefs that are inactive, but I think we could re-assess all the warning and setup tags - yes/no?

[Thorin-Oakenpants]

bump: media.autoplay.default, make inactive and move to 5000s

last chance for comments on this people, or I'll just do it and then close the ticket

[bogachenko]

@Thorin-Oakenpants Question (translation difficulties): what does it mean to move to 5000s

5000s what's this?

[bogachenko]

strings? or what?

[Thorin-Oakenpants]

To move it to the numbered section 5000 in our user.js

/*** 5000: PERSONAL [SETUP]
     Non-project related but useful. If any of these interest you, add them to your overrides ***/

[bogachenko]

Understood

[bogachenko]

@Thorin-Oakenpants like this #544 ? :blush:

[earthlng]

I'd prefer to wait with changing autoplay until they land default-prompt in 64 or 65

[bogachenko]

damn

[earthlng]

re-assess all the warning and setup tags

:+1:

[Thorin-Oakenpants]

I'd prefer to wait with changing autoplay until they land default-prompt in 64 or 65

Why would that make a difference. Is the default going to be "ask" and than means no-one really needs to add an override? If so, then yeah, we can wait

edit: I need to learn how to comprehend shit ... land default-prompt .. default-promt .. the answer was there all along