Closed earthlng closed 7 years ago
432 diffs!! man this is gonna suck!! I think I'm gonna be MIA until you and hopefully an army of contributors are done with this. idea: changelog for 55alpha => "ignored 432 pref-changes for FF55" - there, done, easy peacy :)
pref("app.releaseNotesURL", "https://www.mozilla.org/%LOCALE%/firefox/%VERSION%/releasenotes/?utm_source=firefox-browser&utm_medium=firefox-browser&utm_campaign=whatsnew");
All the crap after ?
is Urchin Google tracking, totally unneeded: https://www.mozilla.org/en-US/firefox/55.0beta/releasenotes/
toolkit.cosmeticAnimations.enabled
- https://bugzilla.mozilla.org/show_bug.cgi?id=1352069
Introduce a pref that allows for disabling animations
This rolls
browser.tabs.animate
,browser.fullscreen.animate
, andalerts.disableSlidingEffect
into a single pref; if any of these are disabled, we'll disable the new pref too (toolkit.cosmeticAnimations.enabled
). Most future animations will also be subject to this pref.
and credited to Mozilla
... money, money, money. They realized they miss out on "credits" for "follow-on" searches. If what they say is true then disabling telemetry will also never send out this kind of stuff. As long as it remains a system-addon that gets downloaded and installed, the fact that we have auto-install disabled will prevent this addon from ever seeing our harddiscs.
We are ready to roll out to release as soon as blog is public
at least they are transparent about it
/* 12xx: disable TLS1.3 0-RTT (round-trip time)
[1] https://github.com/tlswg/tls13-spec/issues/1001
[2] https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/ ***/
user_pref("security.tls.enable_0rtt_data", false); // false in FF51+, true in FF55+
from new ...
pref("plugins.http_https_only", true);
pref("plugins.remember_infobar_dismissal", true);
pref("plugins.show_infobar", true);
pref("urlclassifier.flashInfobarTable", "except-flashinfobar-digest256");
IMO can all be ignored because it's Flash stuff
extensions.legacy.exceptions
- looks like this could be used to prevent certain mozilla addons from being loaded, not that I think we should do that, it's more of an FYI
security.data_uri.unique_opaque_origin
- is the renamed pref for security.data_uri.inherit_security_context
- see https://github.com/ghacksuserjs/ghacks-user.js/issues/87#issuecomment-306183087 - no progress made in https://bugzilla.mozilla.org/show_bug.cgi?id=1324406 so this is still not ready to try IMO
browser.onboarding.enabled
https://dxr.mozilla.org/mozilla-central/source/browser/extensions/onboarding/README.md
great reviews: https://addons.mozilla.org/en-US/firefox/addon/firefox-onboarding-tour/reviews/
https://github.com/mozilla/onboard
edit: WTF! this shit even includes google-analytics! [ :hankey: :hankey: :hankey: :hankey: :hankey: - edit, Thorin, 5-turd award] https://github.com/mozilla/onboard/commit/db4d6c8726c89a5d6a241c1b1065827b525c5baf
IMO...
extensions.startupScanScopes
- is fine as is. It's done for faster startup and I don't see a problem with keeping FF's default value. Not even worth adding to the user.jssecurity.sandbox.gpu.level
- we shouldn't mess with this. Can add to the list of "donotuse" prefs.security.insecure_field_warning.ignore_local_ip_address
- safe to ignorepdfium.enabled;false
- we can ignore this for now and look into it when they change it to true
When I installed nightly 56 I also created a quick diff and this pref showed up under removed, renamed or hidden in v56.0nightly
. And it's "force enable", which will very likely never be set to true by mozilla anyway. IMO we can move it to the ignored list.
are the two prefs for
privacy.window.maxInner*
hidden?
DXR nightly - they are not in any of the default preferences files = hidden prefs for sure.
In 56nightly: 551x751 = 400x700, 549x749 = 400x700
https://dxr.mozilla.org/mozilla-central/source/dom/base/nsContentUtils.cpp#2447
400 = 551 - (551 % 200) = 551 - 151 700 = 751 - (751 % 100) = 751 - 51
width needs to be a multiple of 200 (1x200,2x200,etc), height can be any round hundred. It just can't be higher than your real screen resolutions width/height. fe with a 1920x1080 screen resolution you can use width: 200,400,600,800,1000,1200,1400,1600,1800 together with any round hundred height between and including 100 to 1000. No 2:1 ratio at all as long as what you set fits on your screen
What's up with dom.enable_user_timing
being removed ?
Do you know how Tor Browser reacted to this ? It wouldn't make sense that nothing else happened because both Firefox and Tor teams are in sync for such things.
Like, is privacy.resistFingerprinting
taking care of it now or something ?
Well the User Timing API now can't be disabled. The Tor team already added time wobble in their patches, and at the same time they disabled the API, so I'm not sure that this kind of imprecision reaching Firefox as opposed to just being a Tor patch is compensating anything regarding the loss of dom.enable_user_timing
...
I'm kind of mixed on this, I'd be more open if not for Tor team's decision which I trust. I'm a little surprised that this sounds like a non event to you though :)
I'm sold for the time. But is it the name + scope thing mentioned here covered too ? Damn API provides more information than neat timestamps unfortunately.
I trust your pinky, it's actually the reason I'm asking this to you. For some reason you and earthlng appear to be better at searching Bugzilla and Firefox innards than I am, when things get obscure, which drives me crazy.
browser.tabs.remote.allowLinkedWebInFileUriProcess
- we can set this to false IMO. Most users will never load a file:// anyway. If we want to add this, I'd say as a xxxxB for whatever item browser.tabs.remote.separateFileUriProcess
is. They want to remove "read" access for normal content processes, maybe other things as well. Having this pref set to true could allow web content to run under a less restrictive sandbox policy, But I think it's probably not that critical. We can also ignore it and wait for them to set it to false by default, or we add it as inactive with value false. IDC, I'm on ESR now xD
dom.w3c_pointer_events.dispatch_by_pointer_messages
- whatever this is, it doesn't matter because dom.w3c_pointer_events.enabled
is default falsedom.storageManager.enabled
+ browser.storageManager.enabled
are both still defaulting to false, right? the 2 dom.storageManager.prompt.*
prefs can be ignored IMOnetwork.dns.forceResolve
- 1361099 - moved to ignorenetwork.auth.subresource-img-cross-origin-http-auth-allow
- 1357835Sub-resources HTTP-authentication for cross-origin images: true - it is allowed to present http auth. dialog for cross-origin images. false - it is not allowed. If network.auth.subresource-http-auth-allow has values 0 or 1 this pref does not have any effect.
there shouldn't be the capability whereas someone in control of "img src" can make a dialogue that sends credentials
but
Cross origin errors also have the following text: "WARNING: Your password will not be sent to the web site you are currently visiting!" making this attack far less likely.
we can add it as false
and it shouldn't cause too much breakage IMO. Depending on what their new telemetry data will show, I expect they will change the pref to false (or even hardcode it to false and remove the pref again) but there's also talk of WONTFIX so IDK.
ESR doesn't have this pref yet and the only alternative there is to change network.auth.subresource-http-auth-allow
to 1 (or 0 but I wouldn't recommend that, see comment 13) which restricts all cross-origin subresources from presenting that dialog and not just images.
[Edit: Agreed, besides it totally looks like a spec/web-compat thing and has no privacy/tracking implications IMO - Thorin ]
Security and Privacy Considerations section for WebVTT: https://lists.w3.org/Archives/Public/public-texttracks/2016Nov/0005.html
Thanks for your help here @2glops
👍 or nits
👎 - media.webvtt.pseudo.enabled
only disables WebVTT pseudo element and class support. What good does disabling the styling of subtitles really do?
https://developer.mozilla.org/en-US/docs/Web/API/WebVTT_API#CSS_pseudo-classes
there's media.track.enabled
as well which should eventually allow for multiple "tracks" but it's still disabled, so atm I guess FF always just uses the first track and therefore the "giving away your language or if you're hard of hearing" part probably doesn't apply.
IMO it's useless to include this pref. If you want to "disable"/block WebVTT there are other ways, fe with uBO: /\.vtt$/$media
. [1] also mentions media.webvtt.enabled
but that pref no longer exists.
Thanks for the invitation !
Edit: Yup, that seems pretty harmless - Thorin
pref("security.allow_chrome_frames_inside_content", false); https://hg.mozilla.org/mozilla-central/rev/09ee763947c3 We should enforce that pref to false, security risk here. "If set to true, in some limited circumstances it may be possible to load privileged content in frames inside unprivileged content."
security.allow_chrome_frames_inside_content
from https://bugzilla.mozilla.org/show_bug.cgi?id=1145470#c18
The pref wasn't originally planned, and the only reason it was added was so we could react if a lot of add-ons broke. But during beta I haven't heard or seen any complaints, and so we shipped with the pref turned off.
false is what we want but it's a temporary pref and there's no need to enforce it IMO
pref("network.auth.subresource-img-cross-origin-http-auth-allow", true); IMO, we can ignore : https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
https://dxr.mozilla.org/mozilla-release/source/modules/libpref/init/all.js#2074
// Sub-resources HTTP-authentication:
// 0 - don't allow sub-resources to open HTTP authentication credentials
// dialogs
// 1 - allow sub-resources to open HTTP authentication credentials dialogs,
// but don't allow it for cross-origin sub-resources
// 2 - allow the cross-origin authentication as well.
pref("network.auth.subresource-http-auth-allow", 2);
// Sub-resources HTTP-authentication for cross-origin images:
// true - it is allowed to present http auth. dialog for cross-origin images.
// false - it is not allowed.
// If network.auth.subresource-http-auth-allow has values 0 or 1 this pref does not
// have any effect.
pref("network.auth.subresource-img-cross-origin-http-auth-allow", true);
/* CHANGED: why do we need to disable this exactly? ***/ pref("security.tls.enable_0rtt_data", true); // (FF51+, turned on in 55+)
Because it's the one major flaw in TLS1.3
https://github.com/ghacksuserjs/ghacks-user.js/issues/144#issuecomment-311426070
https://github.com/tlswg/tls13-spec/issues/1001
... security review of the TLS 1.3 0-RTT section ...
The review focused on two known-issues: the absence of forward secrecy for all data, and the replayability of 0-RTT data. As it turns out, these issues can be worked around, and it is possible to to provide 0RTT, Forward Secrecy and anti-replayability (save for the Gilmor downgrade attack case) at the same time.
However TLS1.3 0-RTT is insecure by default, and based on the current draft, it is likely that TLS implementations not using work arounds will create real-world vulnerabilities. I believe that the attacks enabled by these vulnerabilities are more practical, and more serious, than is generally appreciated.
Conclusion
TLS 1.3 0-RTT is not secure by default ...
They've since implemented some anti-replay mechanisms @ https://bugzilla.mozilla.org/show_bug.cgi?id=1295163 - no idea how effective that is though or when that landed. IDK if they even tried to do something about the forward-secrecy problem. IMHO the TLS1.3 guys should have just removed 0-rtt from the spec.
We can ignore this pref if we disable TLS1.3 again instead. Or not give a shit, idc tbh, I know what I will do.
Edit: Thorin - Yup, see my comment a few posts up with exploit link and bugzilla link. Was wondering what effect adding it and ramping up to 2 would have, but yeah, ignore for now. It is a good security fix though, so at least its documented and can be easily found in the repo
Add a passive (detection only) mode for Tracking Protection https://bugzilla.mozilla.org/show_bug.cgi?id=1170190
I'm planning to make the privacy.trackingprotection.annotate_channels pref only control whether channels are annotated as tracking or non-tracking, and add an API to nsIChannel to query that information. I'm going to create another pref (privacy.trackingprotection.lower_network_priority) to control the behavior in bug 1141814.
Lower priority of HTTP requests for resources on the Tracking Protection list https://bugzilla.mozilla.org/show_bug.cgi?id=1141814
When Tracking Protection is disabled, we could still use the Tracking Protection list to lower the priority of those HTTP requests to nsISupportsPriority::PRIORITY_LOWEST. Patrick says: to the extent that TP resources are separate origins than other resources it wouldn't actually turn into much of a practical difference. Different origins are basically run in parallel right now and the prioritizations apply within the origin. There are some exceptions to this when different origins are carried on the same connection - and we will see more of that in the H2/CDN world. And generally doing more with priority information is an evolving area of interest, so marking TP channels as low priority at least creates the meta information to do the right thing when the rest of the stack has more creative things to do.
The network tab should flag resources on the tracking protection list https://bugzilla.mozilla.org/show_bug.cgi?id=1333994
Now that bug 1170190 has landed (currently behind the privacy.trackingprotection.annotate_channels pref), we will start annotating channels with whether or not they are from a URL on the tracking protection list. We should flag these trackers in the network tab of the devtools to help developers know which resources might be blocked and avoid having their sites break when these resources are missing.
I still have no idea WTF this is. Might help if I knew what annotate meant (attributing sources? idk) and why this is even required and why we should list it (inactive to be sure).
The annotations themselves are a purely internal thing. It means every time we're about to load a URL, we check it against the TP list. If it's on the TP list, we mark that URL as a tracker. It's just a mark though: by itself, it doesn't do anything. Therefore, there's not really any point in disabling that.
The other pref, privacy.trackingprotection.lower_network_priority
, will look at whether or not URLs are marked (or "annotated") as trackers and if they are (because annotations are turned on AND the URL is on the TP list) then they get a lower priority.
There's also another pref, I think it's dom.timeout.tracking_throttling_delay
, that looks at URLs marked as trackers and limits the amount of time they can fire timeouts when they are in the background. If you disable annotations, then you don't get the timeout throttling or the lower network priorities.
Maybe one day u can explain this - just internals again?
That's adding an API to let extensions (e.g. Lightbeam) toggle TP on and off.
Even more reason to leave alone. And they have no privacy/security etc issues AFAIK.
Well, the existence of the annotation feature and its intended uses implies that turning TP off may not completely disable all tracking protection related mechanisms. So I quickly searched, and found this from a Francois Marier (@fmarier ?):
https://bugzilla.mozilla.org/show_bug.cgi?id=1345158#c7
> 2. Maybe this is a question for francois, does disabling tracking protection
> stop us from downloading ths list of trackers? If so, I think this really
> belongs in privacy.services
We also download the list of trackers if privacy.trackingprotection.annotate_channels is
enabled. If both are disabled, then the list is not downloaded.
If enabling the annotation feature will cause TP list related client<->server communications, we then have to determine what the risks of those are. Is it a pure download which never involves passing hashes, urls, identifiers, or other significant info to the server? Is the list a list and form that multiple people can download and easily compare to verify they are getting the same exact version? Or are we talking about a Safe Browsing protocol that isn't as clean as that?
Plus, there is another potential issue. Which is Firefox messing around with the priority of things which are on Mozilla's list. A list that may contain entries that users do NOT want deprioritized or whatever. Maybe not a problem unless someone does the "it has be enabled for awhile, time to remove the prefs" thing.
Well, the existence of the annotation feature and its intended uses implies that turning TP off may not completely disable all tracking protection related mechanisms.
Exactly. That's why I suggested to include it in the user.js. IMO we should include the 2 "passive TP" prefs, active and both set to false. They are ignored anyway if "active" TP is enabled.
But 0420 .. privacy.trackingprotection.enabled is OFF by default and the user.js does not change it.
Oh yeah, I didn't think about that. So I guess that means that once both of the passive TP prefs default to true then TP blocks requests in PB windows, and in normal windows the passive TP kicks in and lowers priority.
network.auth.subresource-img-cross-origin-http-auth-allow
- we can ignore this. One would have to be pretty stupid to fall for this attack...
Attempting to demonstrate a 401 prompt on "bugzilla.mozilla.org"
https://bug1357835.bmoattachments.org/attachment.cgi?id=8859667
Honestly, would any of you have entered your bugzilla account credentials into that prompt? 🤦♂️ xD
^^ Hmmm... my parents would fall to trickery. ;)
Apple doesn't fall far from tree. So you know now from where your beer-jar is filling up. :) At least from that point of view the anonymity is a shit. Otherwise I would be happy to bank transfer you guys for a beer.
^^ Hmmm... my parents would fall to trickery. ;)
Lol, yeah I guess that's a valid concern. Let's include it then. Where do we put it? 0900 Passwords? or 2600?
/* xxxx: prevent cross-origin images from triggering an HTTP-Authentication prompt (FF55+)
* [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1357835 ***/
user_pref("network.auth.subresource-img-cross-origin-http-auth-allow", false);
IMO the bugzilla link is enough info
network.auth.subresource-img-cross-origin-http-auth-allow
- https://github.com/ghacksuserjs/ghacks-user.js/commit/31b1f6624e0a289b37e51a4520a8dee5dcef3598
How about this for the passive TP?
/* 04xx: disable passive Tracking Protection
* Passive TP annotates channels to lower the priority of network loads for resources on the tracking protection list
* [NOTE] It has no effect if TP is enabled, but keep in mind that by default TP is only enabled in Private Windows
* This is included for people who want to completely disable Tracking Protection.
* [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1170190
* [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1141814 ***/
// user_pref("privacy.trackingprotection.annotate_channels", false);
// user_pref("privacy.trackingprotection.lower_network_priority", false);
Is it a pure download which never involves passing hashes, urls, identifiers, or other significant info to the server? Is the list a list and form that multiple people can download and easily compare to verify they are getting the same exact version?
Yes to both of these. More details can be found here: https://feeding.cloud.geek.nz/posts/how-tracking-protection-works-in-firefox/
Which is Firefox messing around with the priority of things which are on Mozilla's list. A list that may contain entries that users do NOT want deprioritized or whatever.
s/Mozilla's/Disconnect's/
Not sure why a user would want to avoid de-prioritizing trackers given that this feature doesn't break anything (otherwise it's considered a bug). This is purely a performance improvement.
How about this for the passive TP? ... // user_pref("privacy.trackingprotection.lower_network_priority", false);
You don't need to disable that second one. If annotations are disabled, the network prioritization code will not do anything.
You don't need to disable that second one.
I put it in for informational purposes so that people know there's a 2nd pref that can be toggled independently. Later on the annotations will be used for other things as well and maybe someone wants those other things but not the network throttling for example. Or someone on FF55 wants to use the prioritization and doesn't realize that the 2nd pref is still defaulting to false.
Can you comment on this:
once both of the passive TP prefs default to true then TP blocks requests in PB windows, and in normal windows the passive TP kicks in and lowers priority.
is that the desired effect and how it will work for the foreseeable future? Are you putting that into the release-notes or something because how else are "normal" people gonna know about this stuff otherwise?
is that the desired effect and how it will work for the foreseeable future? Are you putting that into the release-notes or something because how else are "normal" people gonna know about this stuff otherwise?
I think it's scheduled to ship in 57, so I'd look for those release notes when it comes out.
Given the issue closure I'll keep this to a minimum. @fmarier:
How to stop Firefox from making automatic connections suggests that disabling tracking protection will stop the tracking protection list update connections. Will that page be updated to inform people that they also have to disable privacy.trackingprotection.annotate_channels?
@Atavic: I asked because of https://bugzilla.mozilla.org/show_bug.cgi?id=1345158#c7 and there is code in https://dxr.mozilla.org/mozilla-release/source/toolkit/components/url-classifier/SafeBrowsing.jsm which appears consistent with that (superficially):
// From lines 202 and 204
this.trackingEnabled = Services.prefs.getBoolPref("privacy.trackingprotection.enabled") || Services.prefs.getBoolPref("privacy.trackingprotection.pbmode.enabled");
this.trackingAnnotations = Services.prefs.getBoolPref("privacy.trackingprotection.annotate_channels");
// Beginning at line 351
for (let i = 0; i < this.trackingProtectionLists.length; ++i) {
if (this.trackingEnabled || this.trackingAnnotations) {
listManager.enableUpdate(this.trackingProtectionLists[i]);
} else {
listManager.disableUpdate(this.trackingProtectionLists[i]);
}
}
for (let i = 0; i < this.trackingProtectionWhitelists.length; ++i) {
if (this.trackingEnabled || this.trackingAnnotations) {
listManager.enableUpdate(this.trackingProtectionWhitelists[i]);
} else {
listManager.disableUpdate(this.trackingProtectionWhitelists[i]);
}
}
mozilla-central has the same.
We also download the list of trackers if privacy.trackingprotection.annotate_channels is enabled.
After a glance, I see you are right.
How to stop Firefox from making automatic connections suggests that disabling tracking protection will stop the tracking protection list update connections. Will that page be updated to inform people that they also have to disable privacy.trackingprotection.annotate_channels?
Yes, that needs to be updated. Feel free to submit a change there. It's a wiki that anybody can edit, though changes are reviewed to prevent spam.
v54.0 vs v55.0
432 diffs ( 207 new, 66 gone, 159 different )
new in v55.0:
2699
- no longer hidden - 1345322, https://github.com/ghacksuserjs/ghacks-user.js/commit/6ef86fbde60b5349cab07d55181500a25973704dremoved, renamed or hidden in v55.0:
All DONE - see https://github.com/ghacksuserjs/ghacks-user.js/commit/48511d1f9b58d85f5781737e4849f7d929822551
13643341361220135206912413901361578browser.selfsupport.enabled
1352069134466913529491072859changed in v55.0:
1104
0201
0304
0413
0850e
0808
2426
2415b
2504
2629
0608
ignore
==NEW
53 font.name* prefs
```js pref("font.name.cursive.ja", ""); pref("font.name.cursive.x-armn", ""); pref("font.name.cursive.x-beng", ""); pref("font.name.cursive.x-cans", ""); pref("font.name.cursive.x-devanagari", ""); pref("font.name.cursive.x-geor", ""); pref("font.name.cursive.x-gujr", ""); pref("font.name.cursive.x-guru", ""); pref("font.name.cursive.x-khmr", ""); pref("font.name.cursive.x-knda", ""); pref("font.name.cursive.x-mlym", ""); pref("font.name.cursive.x-orya", ""); pref("font.name.cursive.x-sinh", ""); pref("font.name.cursive.x-tamil", ""); pref("font.name.cursive.x-telu", ""); pref("font.name.cursive.x-tibt", ""); pref("font.name-list.cursive.ar", "Comic Sans MS"); pref("font.name-list.cursive.el", "Comic Sans MS"); pref("font.name-list.cursive.th", "Tahoma"); pref("font.name-list.cursive.x-cyrillic", "Comic Sans MS"); pref("font.name-list.cursive.x-ethi", "Visual Geez Unicode Title"); pref("font.name-list.cursive.x-math", "Comic Sans MS"); pref("font.name-list.cursive.x-unicode", "Comic Sans MS"); pref("font.name-list.cursive.x-western", "Comic Sans MS"); pref("font.name-list.cursive.zh-HK", "DFKai-SB"); pref("font.name-list.cursive.zh-TW", "DFKai-SB"); pref("font.name-list.monospace.ar", "Courier New"); pref("font.name-list.monospace.el", "Courier New"); pref("font.name-list.monospace.th", "Tahoma"); pref("font.name-list.monospace.x-cyrillic", "Courier New"); pref("font.name-list.monospace.x-math", "Courier New"); pref("font.name-list.monospace.x-unicode", "Courier New"); pref("font.name-list.monospace.x-western", "Courier New"); pref("font.name-list.sans-serif.el", "Arial"); pref("font.name-list.sans-serif.he", "Arial"); pref("font.name-list.sans-serif.th", "Tahoma"); pref("font.name-list.sans-serif.x-armn", "Arial AMU"); pref("font.name-list.sans-serif.x-cans", "Aboriginal Sans"); pref("font.name-list.sans-serif.x-cyrillic", "Arial"); pref("font.name-list.sans-serif.x-ethi", "GF Zemen Unicode"); pref("font.name-list.sans-serif.x-geor", "BPG Classic 99U"); pref("font.name-list.sans-serif.x-gujr", "Shruti"); pref("font.name-list.sans-serif.x-guru", ""); pref("font.name-list.sans-serif.x-khmr", "Khmer OS"); pref("font.name-list.sans-serif.x-math", "Arial"); pref("font.name-list.sans-serif.x-unicode", "Arial"); pref("font.name-list.sans-serif.x-western", "Arial"); pref("font.name-list.serif.ar", "Times New Roman"); pref("font.name-list.serif.el", "Times New Roman"); pref("font.name-list.serif.th", "Tahoma"); pref("font.name-list.serif.x-cyrillic", "Times New Roman"); pref("font.name-list.serif.x-unicode", "Times New Roman"); pref("font.name-list.serif.x-western", "Times New Roman"); ```
==REMOVED or HIDDEN
==CHANGED
114 font.name* prefs
```js pref("font.name.cursive.ar", ""); // prev: "Comic Sans MS" pref("font.name.cursive.el", ""); // prev: "Comic Sans MS" pref("font.name.cursive.he", ""); // prev: "Guttman Yad" pref("font.name.cursive.ko", ""); // prev: "Gungsuh" pref("font.name.cursive.th", ""); // prev: "Tahoma" pref("font.name.cursive.x-cyrillic", ""); // prev: "Comic Sans MS" pref("font.name.cursive.x-ethi", ""); // prev: "Visual Geez Unicode Title" pref("font.name.cursive.x-math", ""); // prev: "Comic Sans MS" pref("font.name.cursive.x-unicode", ""); // prev: "Comic Sans MS" pref("font.name.cursive.x-western", ""); // prev: "Comic Sans MS" pref("font.name.cursive.zh-CN", ""); // prev: "KaiTi" pref("font.name.cursive.zh-HK", ""); // prev: "DFKai-SB" pref("font.name.cursive.zh-TW", ""); // prev: "DFKai-SB" pref("font.name.monospace.ar", ""); // prev: "Courier New" pref("font.name.monospace.el", ""); // prev: "Courier New" pref("font.name.monospace.he", ""); // prev: "Fixed Miriam Transparent" pref("font.name.monospace.ja", ""); // prev: "MS Gothic" pref("font.name.monospace.ko", ""); // prev: "GulimChe" pref("font.name.monospace.th", ""); // prev: "Tahoma" pref("font.name.monospace.x-armn", ""); // prev: "Arial AMU" pref("font.name.monospace.x-beng", ""); // prev: "Mitra Mono" pref("font.name.monospace.x-cans", ""); // prev: "Aboriginal Sans" pref("font.name.monospace.x-cyrillic", ""); // prev: "Courier New" pref("font.name.monospace.x-devanagari", ""); // prev: "Mangal" pref("font.name.monospace.x-ethi", ""); // prev: "Ethiopia Jiret" pref("font.name.monospace.x-geor", ""); // prev: "BPG Classic 99U" pref("font.name.monospace.x-gujr", ""); // prev: "Shruti" pref("font.name.monospace.x-guru", ""); // prev: "Raavi" pref("font.name.monospace.x-khmr", ""); // prev: "Khmer OS" pref("font.name.monospace.x-knda", ""); // prev: "Tunga" pref("font.name.monospace.x-math", ""); // prev: "Courier New" pref("font.name.monospace.x-mlym", ""); // prev: "Rachana_w01" pref("font.name.monospace.x-orya", ""); // prev: "ori1Uni" pref("font.name.monospace.x-sinh", ""); // prev: "Iskoola Pota" pref("font.name.monospace.x-tamil", ""); // prev: "Latha" pref("font.name.monospace.x-telu", ""); // prev: "Gautami" pref("font.name.monospace.x-tibt", ""); // prev: "Tibetan Machine Uni" pref("font.name.monospace.x-unicode", ""); // prev: "Courier New" pref("font.name.monospace.x-western", ""); // prev: "Courier New" pref("font.name.monospace.zh-CN", ""); // prev: "SimSun" pref("font.name.monospace.zh-HK", ""); // prev: "MingLiu_HKSCS" pref("font.name.monospace.zh-TW", ""); // prev: "MingLiU" pref("font.name.sans-serif.ar", ""); // prev: "Segoe UI" pref("font.name.sans-serif.el", ""); // prev: "Arial" pref("font.name.sans-serif.he", ""); // prev: "Arial" pref("font.name.sans-serif.ja", ""); // prev: "MS PGothic" pref("font.name.sans-serif.ko", ""); // prev: "Gulim" pref("font.name.sans-serif.th", ""); // prev: "Tahoma" pref("font.name.sans-serif.x-armn", ""); // prev: "Arial AMU" pref("font.name.sans-serif.x-beng", ""); // prev: "Vrinda" pref("font.name.sans-serif.x-cans", ""); // prev: "Aboriginal Sans" pref("font.name.sans-serif.x-cyrillic", ""); // prev: "Arial" pref("font.name.sans-serif.x-devanagari", ""); // prev: "Nirmala UI" pref("font.name.sans-serif.x-ethi", ""); // prev: "GF Zemen Unicode" pref("font.name.sans-serif.x-geor", ""); // prev: "BPG Classic 99U" pref("font.name.sans-serif.x-gujr", ""); // prev: "Shruti" pref("font.name.sans-serif.x-khmr", ""); // prev: "Khmer OS" pref("font.name.sans-serif.x-knda", ""); // prev: "Tunga" pref("font.name.sans-serif.x-math", ""); // prev: "Arial" pref("font.name.sans-serif.x-mlym", ""); // prev: "Rachana_w01" pref("font.name.sans-serif.x-orya", ""); // prev: "ori1Uni" pref("font.name.sans-serif.x-sinh", ""); // prev: "Iskoola Pota" pref("font.name.sans-serif.x-telu", ""); // prev: "Gautami" pref("font.name.sans-serif.x-tibt", ""); // prev: "Tibetan Machine Uni" pref("font.name.sans-serif.x-unicode", ""); // prev: "Arial" pref("font.name.sans-serif.x-western", ""); // prev: "Arial" pref("font.name.sans-serif.zh-CN", ""); // prev: "Microsoft YaHei" pref("font.name.sans-serif.zh-HK", ""); // prev: "Arial" pref("font.name.sans-serif.zh-TW", ""); // prev: "Arial" pref("font.name.serif.ar", ""); // prev: "Times New Roman" pref("font.name.serif.el", ""); // prev: "Times New Roman" pref("font.name.serif.he", ""); // prev: "Narkisim" pref("font.name.serif.ja", ""); // prev: "MS PMincho" pref("font.name.serif.ko", ""); // prev: "Batang" pref("font.name.serif.th", ""); // prev: "Tahoma" pref("font.name.serif.x-armn", ""); // prev: "Sylfaen" pref("font.name.serif.x-beng", ""); // prev: "Vrinda" pref("font.name.serif.x-cans", ""); // prev: "Aboriginal Serif" pref("font.name.serif.x-cyrillic", ""); // prev: "Times New Roman" pref("font.name.serif.x-devanagari", ""); // prev: "Kokila" pref("font.name.serif.x-ethi", ""); // prev: "Visual Geez Unicode" pref("font.name.serif.x-geor", ""); // prev: "Sylfaen" pref("font.name.serif.x-gujr", ""); // prev: "Shruti" pref("font.name.serif.x-guru", ""); // prev: "Raavi" pref("font.name.serif.x-khmr", ""); // prev: "PhnomPenh OT" pref("font.name.serif.x-knda", ""); // prev: "Tunga" pref("font.name.serif.x-math", ""); // prev: "Latin Modern Math" pref("font.name.serif.x-mlym", ""); // prev: "Rachana_w01" pref("font.name.serif.x-orya", ""); // prev: "ori1Uni" pref("font.name.serif.x-sinh", ""); // prev: "Iskoola Pota" pref("font.name.serif.x-tamil", ""); // prev: "Latha" pref("font.name.serif.x-telu", ""); // prev: "Gautami" pref("font.name.serif.x-tibt", ""); // prev: "Tibetan Machine Uni" pref("font.name.serif.x-unicode", ""); // prev: "Times New Roman" pref("font.name.serif.x-western", ""); // prev: "Times New Roman" pref("font.name.serif.zh-CN", ""); // prev: "SimSun" pref("font.name.serif.zh-HK", ""); // prev: "Times New Roman" pref("font.name.serif.zh-TW", ""); // prev: "Times New Roman" pref("font.name-list.monospace.x-beng", "Mitra Mono, Likhan, Mukti Narrow"); // prev: "Likhan, Mukti Narrow" pref("font.name-list.monospace.x-mlym", "Rachana_w01, AnjaliOldLipi, Kartika, ThoolikaUnicode"); // prev: "AnjaliOldLipi, Kartika, ThoolikaUnicode" pref("font.name-list.monospace.x-orya", "ori1Uni, Kalinga"); // prev: "Kalinga, ori1Uni" pref("font.name-list.monospace.zh-CN", "SimSun, MS Song, SimSun-ExtB"); // prev: "MS Song, SimSun, SimSun-ExtB" pref("font.name-list.sans-serif.x-mlym", "Rachana_w01, AnjaliOldLipi, Kartika, ThoolikaUnicode"); // prev: "AnjaliOldLipi, Kartika, ThoolikaUnicode" pref("font.name-list.sans-serif.x-orya", "ori1Uni, Kalinga"); // prev: "Kalinga, ori1Uni" pref("font.name-list.sans-serif.zh-HK", "Arial, MingLiU_HKSCS, Ming(for ISO10646), MingLiU, MingLiU_HKSCS-ExtB"); // prev: "MingLiU_HKSCS, Ming(for ISO10646), MingLiU, MingLiU_HKSCS-ExtB" pref("font.name-list.sans-serif.zh-TW", "Arial, PMingLiU, MingLiU, MingLiU-ExtB"); // prev: "PMingLiU, MingLiU, MingLiU-ExtB" pref("font.name-list.serif.x-mlym", "Rachana_w01, AnjaliOldLipi, Kartika, ThoolikaUnicode"); // prev: "AnjaliOldLipi, Kartika, ThoolikaUnicode" pref("font.name-list.serif.x-orya", "ori1Uni, Kalinga"); // prev: "Kalinga, ori1Uni" pref("font.name-list.serif.zh-CN", "SimSun, MS Song, SimSun-ExtB"); // prev: "MS Song, SimSun, SimSun-ExtB" pref("font.name-list.serif.zh-HK", "Times New Roman, MingLiu_HKSCS, Ming(for ISO10646), MingLiU, MingLiU_HKSCS-ExtB"); // prev: "MingLiu_HKSCS, Ming(for ISO10646), MingLiU, MingLiU_HKSCS-ExtB" pref("font.name-list.serif.zh-TW", "Times New Roman, PMingLiu, MingLiU, MingLiU-ExtB"); // prev: "PMingLiu, MingLiU, MingLiU-ExtB" ```