Opened 3 years ago
Closed 2 years ago
#19048 closed task (fixed)
Review Firefox Developer Docs and Undocumented bugs since FF45esr
| Reported by: | gk | Owned by: | tbb-team |
|---|---|---|---|
| Priority: | Very High | Milestone: | |
| Component: | Applications/Tor Browser | Version: | |
| Severity: | Normal | Keywords: | ff52-esr, TorBrowserTeam201704, tbb-7.0-must-alpha, GeorgKoppen201704 |
| Cc: | brade, mcs, arthuredelstein | Actual Points: | |
| Parent ID: | Points: | ||
| Reviewer: | Sponsor: | Sponsor4 |
Description
This ticket is for the review of new features and (undocumented) bugs between Firefox 46 and 52 inclusive.
Child Tickets
Change History (38)
comment:1 Changed 3 years ago by
comment:2 Changed 3 years ago by
| Cc: | brade mcs added |
|---|
comment:3 Changed 3 years ago by
| Keywords: | TorBrowserTeam201701 added |
|---|
comment:4 Changed 3 years ago by
While experimenting with an ESR52 Tor Browser, Kathy and I noticed a fetch of http://detectportal.firefox.com/success.txt at startup. Captive portal detection is enabled in Firefox 52; we will need to decide whether we should disable it in Tor Browser.
See https://bugzilla.mozilla.org/show_bug.cgi?id=989193#c54
comment:5 follow-up: 8 Changed 3 years ago by
We will want to set browser.selfsupport.enabled to false to disable Normandy aka Shield aka Self Support aka Self Repair. To be safe we can also redirect browser.selfsupport.url
We probably want to disable stuff under browser.uitour.
I'm not sure how to get to it in 52, but in 53, the WebIDE auto-installs some extensions it downloads from Mozilla. Probably best to disable it via devtools.webide.enabled
The Telemetry experiments features should be disabled (experiments.*)
There is something called "Extensions Discovery" governed by extensions.getAddons.showPane
Probably want to disable security.ssl.errorReporting
There's something called 'Social' under social.* including the scary one social.remote-install.enabled
comment:6 Changed 3 years ago by
| Keywords: | TorBrowserTeam201702 added; TorBrowserTeam201701 removed |
|---|
Moving our tickets to Feb 2017.
comment:8 Changed 3 years ago by
Replying to tom:
We will want to set browser.selfsupport.enabled to false to disable Normandy aka Shield aka Self Support aka Self Repair. To be safe we can also redirect browser.selfsupport.url
This is already done; see #18738.
We probably want to disable stuff under browser.uitour.
We already have browser.uitour.enabled = false but to be even safer maybe we should modify the browser.uitour prefs that contain URLs?
I'm not sure how to get to it in 52, but in 53, the WebIDE auto-installs some extensions it downloads from Mozilla. Probably best to disable it via devtools.webide.enabled
We already have the following in browser/app/profile/000-tor-browser.js:
pref("devtools.webide.autoinstallADBHelper", false);
pref("devtools.webide.autoinstallFxdtAdapters", false);
pref("devtools.webide.enabled", false);
pref("devtools.appmanager.enabled", false);
The Telemetry experiments features should be disabled (experiments.*)
Agreed.
There is something called "Extensions Discovery" governed by extensions.getAddons.showPane
Setting that pref to false removes the "Get Add-ons" panel from about:addons. I don't think we have to remove it, but doing so would discourage use of add-ons in Tor Browser (and we don't have any control over what add-ons Mozilla might show on that panel).
Probably want to disable security.ssl.errorReporting
Agreed.
There's something called 'Social' under social.* including the scary one social.remote-install.enabled
It looks like we have #13612 for this. We should look at it for ESR52.
comment:9 follow-up: 15 Changed 3 years ago by
Kathy and I reviewed the Firefox 46 and 47 changes (by looking at the "Firefox ## for Developers" web pages, the target_milestone=mozilla## bugs, and the target_milestone=Firefox%20## bugs). Before we move on to 48-52, we wanted to note here what we found so far:
a) DateTimeFormat.formatToParts. We should verify that timezone and/or locale not leaked to web content by new API.
https://bugzilla.mozilla.org/show_bug.cgi?id=1289340
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts
b) Some changes were made to device orientation events. We should ensure that orientation is not leaked to web content.
https://bugzilla.mozilla.org/show_bug.cgi?id=1205649
c) The Permissions API is now enabled. Kathy and I think we should turn it off to prevent fingerprinting based on choices that users make. Unfortunately, the dom.permissions.enabled pref was removed.
https://lists.mozilla.org/pipermail/dev-platform/2015-August/011466.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1233702
d) TouchEvents are now enabled on Windows and Linux. I already poked #10286.
e) window.showModalDialog() is not available when e10s is enabled. Should we always make it unavailable (even when e10s is disabled)? Or maybe we don't care because we will probably enable e10s for all Tor Browser users or none.
https://bugzilla.mozilla.org/show_bug.cgi?id=1234700
f) Looking through the bug lists reminded us about Web Animations possibly providing a high resolution timing source. But we do have #18273 for that issue.
g) Similarly, we were reminded about WebAudio. See #13017.
h) We will need to set network.dns.blockDotOnion = false.
i) Should we disable about:profiles? Some of the functionality will confused our users, e.g., "Create New Profile" which may not work correctly on Linux and Windows and "Restart with Add-ons Disabled."
https://bugzilla.mozilla.org/show_bug.cgi?id=1235402
j) A DNS lookup feature was added to about:networking DNS. We should verify that it respects the browser proxy settings.
https://bugzilla.mozilla.org/show_bug.cgi?id=907050
k) Is the Fetch API safe? It includes fetch events with mode=navigate, and Kathy and I are not sure if there are any linkability concerns with that API.
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
comment:10 Changed 3 years ago by
| Cc: | arthuredelstein added |
|---|
comment:11 follow-up: 21 Changed 3 years ago by
Here are some things Kathy and I found while reviewing Firefox 48 changes (we will need to file separate tickets for some of these, but as a first pass I am posting our notes in this ticket):
a) We should probably make sure screen sharing is disabled. Maybe this is covered by our removal of WebRTC, but we could also set these pref values to be sure:
media.getusermedia.screensharing.enabled = false
media.getusermedia.screensharing.allowed_domains = ""
b) Some safe browsing prefs have been renamed and other functionality has been added. We should disable all of it via the following pref values:
browser.safebrowsing.downloads.enabled = false
browser.safebrowsing.downloads.remote.enabled = false
browser.safebrowsing.malware.enabled = false
browser.safebrowsing.phishing.enabled = false
browser.safebrowsing.blockedURIs.enabled = false
c) We should return a constant value for window.navigator.hardwareConcurrency.
https://developer.mozilla.org/en-US/docs/Web/API/NavigatorConcurrentHardware/hardwareConcurrency
d) From a fingerprinting perspective, the following bug is a little scary (consult Firefox prefs from CSS) but use seems to be limited to internal style sheets:
e) Mozilla sites can check whether an add-on is installed and retrieve some metadata. Do we want to disable this?
f) APIs to allow access to some internal Firefox services from remote New Tab pages (hosted on mozilla.org servers) have been added. We should figure out how to disable them.
PreviewProvider Messaging API
NewTabPrefsProvider Messaging API
PlacesProvider Messaging API
g) We may want to skip importing a certificate on Windows to support Microsoft Family Safety by setting:
security.family_safety.mode = 0
https://bugzilla.mozilla.org/show_bug.cgi?id=1239166
h) We may want to document for our Linux users that add-ons installed in the following directory do not have to be signed by Mozilla:
/usr/{lib,share}/mozilla/extensions
i) If we enable e10s/multiprocess mode, we should document for our users that it will be disabled if accessibility tools are used.
comment:12 follow-up: 23 Changed 3 years ago by
And here are our notes for Firefox 49:
a) Graphite font rendering has been re-enabled. We need to decide if we want to disable it again or not.
b) Mozilla switched to compiling with Intel SSE2. We could do the same, although it would mean that Tor Browser would not run on some really old CPUs. Mozilla modified their Windows installer to notify and refuse to install if the CPU does not support SSE2.
c) Kathy and I cannot think of any fingerprinting or linkability risks associated with the Web Speech API, but it is a big new thing:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_API
https://bugzilla.mozilla.org/show_bug.cgi?id=1268633
d) We should verify that the "Network ID" is not even computed when Telemetry is disabled. At least I would feel better if it was not.
e) The Bookmarks Toolbar is automatically shown when the user adds a bookmark to it. This will change the window size, but maybe this is used rarely enough that we do not care?
f) The window.isSecureContext API is interesting but may not add any fingerprinting or linkability risks. We should think about whether features that are being made "HTTPS only" should also be available on .onion sites.
https://developer.mozilla.org/en-US/docs/Web/API/Window/isSecureContext
g) As part of our release procedures, do we double-check the HPKP expiration? Mozilla seems to have bugs for each release, e.g.,
comment:13 follow-up: 24 Changed 3 years ago by
Here are a few items for Firefox 50:
a) We need to determine if the File and Directory Entries API adds any fingerprinting or linkability risk.
https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API
b) When reviewing bugs, Kathy and I noticed that there seem to be a lot of crasher bugs associated with DOM Animation, e.g., UAF bugs. I think this is disabled by default via:
dom.animations-api.core.enabled = false
or maybe we also need to add the following if we want to turn it off completely?
dom.animations-api.element-animate.enabled
This might be something for the security slider eventually.
c) As part of our release procedures, do we double-check the HPKP expiration? We do not want to have a repeat of the problem where the pins expired. Mozilla seems to have bugs for each release, e.g.,
comment:14 follow-up: 28 Changed 3 years ago by
Finally, here our our notes for Firefox 51 (we did not look at the Firefox 52 changes yet):
a) We should verify that TypedArray.toLocaleString() does not leak locale information.
b) We should verify that the new <input> types do not leak locale information, e.g., <input type="time">, type="date", type="week", etc.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
c) WebGL2 is enabled by default which may enable new fingerprinting opportunities:
d) HTTP Opportunistic Security may add some linkability risks, although it seems okay at a glance.
http://httpwg.org/http-extensions/opsec.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1301117
e) Do we want to disable Web Audio due to fingerprinting risks? Mozilla keeps adding more functionality. Maybe this is already covered by #13017.
f) There are some new Storage APIs that we should look at, e.g.,
https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/estimate
https://bugzilla.mozilla.org/show_bug.cgi?id=1267941
comment:15 follow-up: 17 Changed 3 years ago by
Replying to mcs:
Kathy and I reviewed the Firefox 46 and 47 changes (by looking at the "Firefox ## for Developers" web pages, the target_milestone=mozilla## bugs, and the target_milestone=Firefox%20## bugs). Before we move on to 48-52, we wanted to note here what we found so far:
a)
DateTimeFormat.formatToParts. We should verify that timezone and/or locale not leaked to web content by new API.
https://bugzilla.mozilla.org/show_bug.cgi?id=1289340
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts
That's in mozill52, right? But, yes, we should double-check that. I opened #21608.
b) Some changes were made to device orientation events. We should ensure that orientation is not leaked to web content.
https://bugzilla.mozilla.org/show_bug.cgi?id=1205649
c) The Permissions API is now enabled. Kathy and I think we should turn it off to prevent fingerprinting based on choices that users make. Unfortunately, the
dom.permissions.enabledpref was removed.
https://lists.mozilla.org/pipermail/dev-platform/2015-August/011466.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1233702
d) TouchEvents are now enabled on Windows and Linux. I already poked #10286.
e) window.showModalDialog() is not available when e10s is enabled. Should we always make it unavailable (even when e10s is disabled)? Or maybe we don't care because we will probably enable e10s for all Tor Browser users or none.
https://bugzilla.mozilla.org/show_bug.cgi?id=1234700
I think we should not care. Besides that it seems that non of our code is using showModalDialog() anyway.
f) Looking through the bug lists reminded us about Web Animations possibly providing a high resolution timing source. But we do have #18273 for that issue.
I guess you mean #16337?
g) Similarly, we were reminded about WebAudio. See #13017.
h) We will need to set
network.dns.blockDotOnion = false.
Hm. You mean for the transparent proxying option?
i) Should we disable about:profiles? Some of the functionality will confused our users, e.g., "Create New Profile" which may not work correctly on Linux and Windows and "Restart with Add-ons Disabled."
https://bugzilla.mozilla.org/show_bug.cgi?id=1235402
Yes. I opened #21610.
j) A DNS lookup feature was added to about:networking DNS. We should verify that it respects the browser proxy settings.
https://bugzilla.mozilla.org/show_bug.cgi?id=907050
k) Is the Fetch API safe? It includes fetch events with mode=navigate, and Kathy and I are not sure if there are any linkability concerns with that API.
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
This is already #16326. Or did you find something new we should look at?
Additional things I found:
l) Remaining things for offscreen canvas got implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=1172796. We should make sure that they are disabled as well (I updated #18599).
m) windows are maximized on first run on small screens: https://bugzilla.mozilla.org/show_bug.cgi?id=384336 I'll have that in mind while reviewing the rebased patches in #20680.
n) There is a "What's new" item on the about dialog pointing to Mozilla resources: https://bugzilla.mozilla.org/show_bug.cgi?id=1047395 I guess we should point to our blog post instead. We have #21484 for that.
comment:16 Changed 3 years ago by
| Keywords: | tbb-7.0-must added |
|---|
comment:17 follow-up: 20 Changed 3 years ago by
Replying to gk:
Replying to mcs:
a)
DateTimeFormat.formatToParts. We should verify that timezone and/or locale not leaked to web content by new API.
https://bugzilla.mozilla.org/show_bug.cgi?id=1289340
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts
That's in mozill52, right? But, yes, we should double-check that. I opened #21608.
Thanks. That bug and the docs say it is in mozilla51, but in any case we should take a look.
...
e) window.showModalDialog() is not available when e10s is enabled. Should we always make it unavailable (even when e10s is disabled)? Or maybe we don't care because we will probably enable e10s for all Tor Browser users or none.
https://bugzilla.mozilla.org/show_bug.cgi?id=1234700
I think we should not care. Besides that it seems that non of our code is using
showModalDialog()anyway.
Okay. Kathy and I were thinking about regular web pages using that API and/or detecting that it is not available. But there are probably other ways to detect that e10s is enabled.
f) Looking through the bug lists reminded us about Web Animations possibly providing a high resolution timing source. But we do have #18273 for that issue.
I guess you mean #16337?
Yes; thanks.
h) We will need to set
network.dns.blockDotOnion = false.
Hm. You mean for the transparent proxying option?
I was thinking that the Firefox code would block .onion requests even when they go through the SOCKS proxy. But you may be correct.
k) Is the Fetch API safe? It includes fetch events with mode=navigate, and Kathy and I are not sure if there are any linkability concerns with that API.
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
This is already #16326. Or did you find something new we should look at?
No, I don't think we found anything new. Kathy and I forgot that we had looked at this API before. There were some small changes since Firefox 45, but if I remember correctly they are not significant.
Thanks for making another pass at this and filing tickets!
comment:18 Changed 3 years ago by
| Keywords: | TorBrowserTeam201703 added; TorBrowserTeam201702 removed |
|---|
Moving tickets to March
comment:20 Changed 3 years ago by
Replying to mcs:
Replying to gk:
Replying to mcs:
e) window.showModalDialog() is not available when e10s is enabled. Should we always make it unavailable (even when e10s is disabled)? Or maybe we don't care because we will probably enable e10s for all Tor Browser users or none.
https://bugzilla.mozilla.org/show_bug.cgi?id=1234700
I think we should not care. Besides that it seems that non of our code is using
showModalDialog()anyway.
Okay. Kathy and I were thinking about regular web pages using that API and/or detecting that it is not available. But there are probably other ways to detect that e10s is enabled.
I made a note in #21432. Maybe we find some good solution to the "e10s and fingerprinting" issue.
h) We will need to set
network.dns.blockDotOnion = false.
Hm. You mean for the transparent proxying option?
I was thinking that the Firefox code would block .onion requests even when they go through the SOCKS proxy. But you may be correct.
I opened #21674 for investigating this.
comment:21 Changed 3 years ago by
Replying to mcs:
Here are some things Kathy and I found while reviewing Firefox 48 changes (we will need to file separate tickets for some of these, but as a first pass I am posting our notes in this ticket):
a) We should probably make sure screen sharing is disabled. Maybe this is covered by our removal of WebRTC, but we could also set these pref values to be sure:
media.getusermedia.screensharing.enabled = false
media.getusermedia.screensharing.allowed_domains = ""
That seems to be nothing new or did something related to those prefs change between ESR 45 and ESR 52?
b) Some safe browsing prefs have been renamed and other functionality has been added. We should disable all of it via the following pref values:
browser.safebrowsing.downloads.enabled = false
browser.safebrowsing.downloads.remote.enabled = false
browser.safebrowsing.malware.enabled = false
browser.safebrowsing.phishing.enabled = false
browser.safebrowsing.blockedURIs.enabled = false
This is #21683.
c) We should return a constant value for window.navigator.hardwareConcurrency.
https://developer.mozilla.org/en-US/docs/Web/API/NavigatorConcurrentHardware/hardwareConcurrency
This is #21675. Note the related one, #18559.
d) From a fingerprinting perspective, the following bug is a little scary (consult Firefox prefs from CSS) but use seems to be limited to internal style sheets:
Yes. Looking over it it seems to be okay having even a test showing this is a non-issue for non-priv contexts.
e) Mozilla sites can check whether an add-on is installed and retrieve some metadata. Do we want to disable this?
Yes. This is bug #21684.
f) APIs to allow access to some internal Firefox services from remote New Tab pages (hosted on mozilla.org servers) have been added. We should figure out how to disable them.
PreviewProvider Messaging API
NewTabPrefsProvider Messaging API
PlacesProvider Messaging API
This is #21685.
g) We may want to skip importing a certificate on Windows to support Microsoft Family Safety by setting:
security.family_safety.mode = 0
https://bugzilla.mozilla.org/show_bug.cgi?id=1239166
Yes, in #21686.
h) We may want to document for our Linux users that add-ons installed in the following directory do not have to be signed by Mozilla:
/usr/{lib,share}/mozilla/extensions
Maybe, although I still think we should not propagate things that deviate from the Tor Browser as we ship it.
i) If we enable e10s/multiprocess mode, we should document for our users that it will be disabled if accessibility tools are used.
There are a bunch more conditions where this holds. I made a note in #21432.
Other items I have
j) prefetch in the network predictor is implemented (https://bugzilla.mozilla.org/show_bug.cgi?id=1016628). I opened #21687.
k) There is a search service update feature available we ignored up to now (I stumbled over it while readin https://bugzilla.mozilla.org/show_bug.cgi?id=1259510). We should investigate whether that is an issue for us. This is done in #21688.
l) Element.animate() got shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=1245000) that part of the Animations API seems to be available right now. I moved #16337 for that back onto our ESR 52 radar.
m) Fetch RequestCache got implemented (https://bugzilla.mozilla.org/show_bug.cgi?id=1120715). Not sure if that is a thing we should care about. But if so, it has to respect our design guidelines. This is #21689.
comment:22 Changed 3 years ago by
sec-review of appcache: https://bugzilla.mozilla.org/show_bug.cgi?id=1237782#c34
Honza Bambas (firefox47: fixed):
I've recently landed a patch that allows disabling appcache by turning a pref (actually few prefs) - bug 1237783.
Backport?
comment:23 follow-up: 27 Changed 3 years ago by
Replying to mcs:
And here are our notes for Firefox 49:
a) Graphite font rendering has been re-enabled. We need to decide if we want to disable it again or not.
I opened #21726.
b) Mozilla switched to compiling with Intel SSE2. We could do the same, although it would mean that Tor Browser would not run on some really old CPUs. Mozilla modified their Windows installer to notify and refuse to install if the CPU does not support SSE2.
The updater part is #19316 and the installer #21704.
c) Kathy and I cannot think of any fingerprinting or linkability risks associated with the Web Speech API, but it is a big new thing:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_API
https://bugzilla.mozilla.org/show_bug.cgi?id=1268633
Yeah, I think this is fine. Both synthesis and recognition seem to be off anyway. pref("media.webspeech.synth.enabled", false); pref("media.webspeech.recognition.enable", false);
d) We should verify that the "Network ID" is not even computed when Telemetry is disabled. At least I would feel better if it was not.
#21727. Might have sandboxing implications as well as it needs /proc/net/arp access on Linux e.g.
e) The Bookmarks Toolbar is automatically shown when the user adds a bookmark to it. This will change the window size, but maybe this is used rarely enough that we do not care?
Hm. I think that falls under #16456
f) The window.isSecureContext API is interesting but may not add any fingerprinting or linkability risks. We should think about whether features that are being made "HTTPS only" should also be available on .onion sites.
https://developer.mozilla.org/en-US/docs/Web/API/Window/isSecureContext
Yes, this is a nice thing to look at, I opened #21728.
g) As part of our release procedures, do we double-check the HPKP expiration? Mozilla seems to have bugs for each release, e.g.,
No, we don't right now. Mozilla has HPKP enabled for addons.mozilla.org and other measures implemented (https://bugzilla.mozilla.org/show_bug.cgi?id=1303127#c13). I think that's okay until we solve this properly.
Other things I have:
h) Flyweb landed which seems crazy (https://wiki.mozilla.org/FlyWeb and https://hacks.mozilla.org/2016/09/flyweb-pure-web-cross-device-interaction) but it is disabled in ESR 52 (dom.flyweb.enabled is false).
i) Canvas CSS/SVG filters are enabled by default (https://bugzilla.mozilla.org/show_bug.cgi?id=1173545). We have #16341 for that.
comment:24 follow-up: 25 Changed 3 years ago by
Replying to mcs:
Here are a few items for Firefox 50:
a) We need to determine if the File and Directory Entries API adds any fingerprinting or linkability risk.
https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API
That is #21742.
b) When reviewing bugs, Kathy and I noticed that there seem to be a lot of crasher bugs associated with DOM Animation, e.g., UAF bugs. I think this is disabled by default via:
dom.animations-api.core.enabled = false
or maybe we also need to add the following if we want to turn it off completely?
dom.animations-api.element-animate.enabled
This might be something for the security slider eventually.
Have you checked whether those crasher bugs made it ever into releases? The current metric for the slider was looking at sec-high and sec-critical bugs that got fixed on the release channel. Just looking at mozilla50 might spoil our metrics.
c) As part of our release procedures, do we double-check the HPKP expiration? We do not want to have a repeat of the problem where the pins expired. Mozilla seems to have bugs for each release, e.g.,
Hey, that got mentioned in the mozilla49 notes already (see my reply in the previous comment). :)
Additional things I have:
d) The HTML Drag and Drop API is new and enabled by default allowing multiple items to being dragged and dropped (see: https://bugzilla.mozilla.org/show_bug.cgi?id=906420, https://bugzilla.mozilla.org/show_bug.cgi?id=1289255, and https://bugzilla.mozilla.org/show_bug.cgi?id=1298243). I opened #21741.
e) Mozilla ships an own emoji font on Windows/Linux, we should make sure that does not interfere with our font fingerprinting defense (see: https://bugzilla.mozilla.org/show_bug.cgi?id=1231701). That's #21740.
f) SPDY 3.1 is disabled, we can get rid of our pref we set (https://bugzilla.mozilla.org/show_bug.cgi?id=1287132). That is actually ripped out in Firefox 51. I opened #21739.
comment:25 Changed 3 years ago by
Replying to gk:
b) When reviewing bugs, Kathy and I noticed that there seem to be a lot of crasher bugs associated with DOM Animation, e.g., UAF bugs. I think this is disabled by default via:
dom.animations-api.core.enabled = false
or maybe we also need to add the following if we want to turn it off completely?
dom.animations-api.element-animate.enabled
This might be something for the security slider eventually.
Have you checked whether those crasher bugs made it ever into releases? The current metric for the slider was looking at sec-high and sec-critical bugs that got fixed on the release channel. Just looking at mozilla50 might spoil our metrics.
You make a good point. It is difficult to tell if a bug made it into an actual release (at least I am not sure how to tell). If it did, it should be included in the Mozilla Security Advisory list, and I did find a couple of items there:
https://www.mozilla.org/en-US/security/advisories/mfsa2016-85/#CVE-2016-5277
https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5379
But there is always a collection of memory safety bugs for which little detail is available, and I cannot see all of the bugs. I did find one bug that way:
c) As part of our release procedures, do we double-check the HPKP expiration? We do not want to have a repeat of the problem where the pins expired. Mozilla seems to have bugs for each release, e.g.,
Hey, that got mentioned in the mozilla49 notes already (see my reply in the previous comment). :)
Oops. I think I am repeating myself. I think I am repeating myself.
comment:26 follow-up: 29 Changed 3 years ago by
Here are the items that Kathy and I found for Firefox 52:
a) As I mentioned in comment:4, captive portal detection is enabled in FF52. It won't be useful over Tor, so we should disable it via network.captive-portal-service.enabled = false. I thought we already had a ticket for this, but I cannot find it.
b) MediaError has gained a message property that may include system diagnostic
information. We should make sure it does not provide fingerprintable information
about the user's computer.
https://developer.mozilla.org/en-US/docs/Web/API/MediaError
https://bugzilla.mozilla.org/show_bug.cgi?id=1322606
c) Kathy and I don't fully understand what was done in the following bug and
how it affects our use of the --disable-eme configure flag:
Maybe the difference is that now the framework that supports EME is always
built and --disable-eme only skips building the bundled providers?
d) The CustomElementRegistry.get() method of the Web Components API has been implemented. It looks like all of the custom element features are disabled via dom.webcomponents.customelements.enabled = false, but eventually we should make sure that these APIs do not introduce any linkability problems
e) A note related to e10s: use of accessibility tools is no longer a reason to disable e10s (it was for Firefox 48-51, as I noted in comment:11):
https://bugzilla.mozilla.org/show_bug.cgi?id=1312100
https://bugzilla.mozilla.org/show_bug.cgi?id=1310788
https://bugzilla.mozilla.org/show_bug.cgi?id=1322606
comment:27 Changed 3 years ago by
Replying to gk:
Replying to mcs:
c) Kathy and I cannot think of any fingerprinting or linkability risks associated with the Web Speech API, but it is a big new thing:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_API
https://bugzilla.mozilla.org/show_bug.cgi?id=1268633
Yeah, I think this is fine. Both synthesis and recognition seem to be off anyway. pref("media.webspeech.synth.enabled", false); pref("media.webspeech.recognition.enable", false);
Actually, I misspoke here. media.webspeech.synth.enabled is set to true. It turns out we have a ticket for that already, #10283, and getVoices() might indeed be interesting.
comment:28 follow-up: 30 Changed 3 years ago by
Replying to mcs:
Finally, here our our notes for Firefox 51 (we did not look at the Firefox 52 changes yet):
a) We should verify that
TypedArray.toLocaleString()does not leak locale information.
There are other objects that have toLocaleString() as well, like Array (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toLocaleString) or Number (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toLocaleString). I have a ticket for all of them: #21784.
b) We should verify that the new
<input>types do not leak locale information, e.g.,<input type="time">,type="date",type="week", etc.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
Hm. The docs say these are not implemented yet and the linked bug (https://bugzilla.mozilla.org/show_bug.cgi?id=888320) seems to second that. What made you believe they are wrong?
c) WebGL2 is enabled by default which may enable new fingerprinting opportunities:
This is #16404.
d) HTTP Opportunistic Security may add some linkability risks, although it seems okay at a glance.
http://httpwg.org/http-extensions/opsec.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1301117
It seems that needs HTTP2/Alternative Services being enabled which is both not the case for us?
e) Do we want to disable Web Audio due to fingerprinting risks? Mozilla keeps adding more functionality. Maybe this is already covered by #13017.
I think having this covered by #13017 seems okay for me. We should keep a close eye on that one, though. FWIW: We got a pref to disable that in https://bugzilla.mozilla.org/show_bug.cgi?id=1288359 (+ there is some discussion on that bugs) we might want to use. I updated #13017 accordingly and flag it for closer ff52-esr scrutiny.
f) There are some new Storage APIs that we should look at, e.g.,
https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/estimate
https://bugzilla.mozilla.org/show_bug.cgi?id=1267941
I have #21785 for that.
Additionally, I have
g) Check whether the Ambient Light Sensor event.value is properly rounded off: #21786.
h) Make sure exposing the calendar information does not leak the locale: #21787.
comment:29 Changed 3 years ago by
Replying to mcs:
Here are the items that Kathy and I found for Firefox 52:
a) As I mentioned in comment:4, captive portal detection is enabled in FF52. It won't be useful over Tor, so we should disable it via
network.captive-portal-service.enabled = false. I thought we already had a ticket for this, but I cannot find it.
b) MediaError has gained a message property that may include system diagnostic
information. We should make sure it does not provide fingerprintable information
about the user's computer.
https://developer.mozilla.org/en-US/docs/Web/API/MediaError
https://bugzilla.mozilla.org/show_bug.cgi?id=1322606
This is #21792.
c) Kathy and I don't fully understand what was done in the following bug and
how it affects our use of the --disable-eme configure flag:
Maybe the difference is that now the framework that supports EME is always
built and --disable-eme only skips building the bundled providers?
Yeah, I had a similar impression. I'll make a note in #16285.
d) The CustomElementRegistry.get() method of the Web Components API has been implemented. It looks like all of the custom element features are disabled via
dom.webcomponents.customelements.enabled = false, but eventually we should make sure that these APIs do not introduce any linkability problems
I opened #21793.
e) A note related to e10s: use of accessibility tools is no longer a reason to disable e10s (it was for Firefox 48-51, as I noted in comment:11):
https://bugzilla.mozilla.org/show_bug.cgi?id=1312100
https://bugzilla.mozilla.org/show_bug.cgi?id=1310788
https://bugzilla.mozilla.org/show_bug.cgi?id=1322606
The last link is probably a copy-and-paste error? In any case, it seems the a11y+e10s support got at least backed out for Windows again: https://bugzilla.mozilla.org/show_bug.cgi?id=1325690
Additionally, I have
f) We want to clear preloaded state (dynamic pins) in SiteSecurityService as well on New Identity (https://bugzilla.mozilla.org/show_bug.cgi?id=1306471) which is #21794.
comment:30 Changed 3 years ago by
Replying to gk:
b) We should verify that the new
<input>types do not leak locale information, e.g.,<input type="time">,type="date",type="week", etc.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
Hm. The docs say these are not implemented yet and the linked bug (https://bugzilla.mozilla.org/show_bug.cgi?id=888320) seems to second that. What made you believe they are wrong?
I don't remember what we saw, but you are correct: the implementation seems to be a work in progress and the new input types are disabled via a dom.forms.datetime pref.
d) HTTP Opportunistic Security may add some linkability risks, although it seems okay at a glance.
http://httpwg.org/http-extensions/opsec.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1301117
It seems that needs HTTP2/Alternative Services being enabled which is both not the case for us?
Yes, I think #16673 took care of disabling it.
comment:31 Changed 2 years ago by
| Keywords: | tbb-7.0-must-nightly added |
|---|
We want those tickets for our first ESR52 nightlies.
comment:32 Changed 2 years ago by
| Keywords: | TorBrowserTeam201704 added; TorBrowserTeam201703 removed |
|---|
Moving tickets over to April
comment:33 Changed 2 years ago by
| Keywords: | tbb-7.0-must removed |
|---|
No need to use somewhat duplicated keywords.
comment:34 Changed 2 years ago by
| Keywords: | tbb-7.0-must-alpha added; tbb-7.0-must-nightly removed |
|---|
Things to tag for the alphas (as the remaining tasks in the tickets are no nightly bloclers).
comment:35 Changed 2 years ago by
Getting this on our radar for alpha release in less than two weeks.
comment:36 Changed 2 years ago by
| Keywords: | GeorgKoppen201704 added; GeorgKoppen201703 removed |
|---|
Moving my tickets to April
comment:37 Changed 2 years ago by
| Priority: | Medium → Very High |
|---|
comment:38 Changed 2 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I finished my review of the differences of firefox.js and all.js between esr45 and esr52. I used the following git commands to produce them: git diff mozilla/esr45 mozilla/esr52 browser/app/profile/firefox.js and git diff mozilla/esr45 mozilla/esr52 modules/libpref/init/all.js. I filed follow-up tickets (mainly #22070 and #22071) and addressed the remaining concerns tjr had with #22072 and #22073. We are done here then.
Here are some useful search quereies:
1) Firefox bugs
https://bugzilla.mozilla.org/buglist.cgi?list_id=12910125&product=Firefox&query_format=advanced&resolution=FIXED&target_milestone=Firefox%2046&target_milestone=Firefox%2047&target_milestone=Firefox%2048&target_milestone=Firefox%2049&target_milestone=Firefox%2050&target_milestone=Firefox%2051&target_milestone=Firefox%2052&order=priority%2Cbug_severity&limit=0
2) Core bugs per target milestone
https://bugzilla.mozilla.org/buglist.cgi?product=Core&query_format=advanced&resolution=FIXED&target_milestone=mozilla46&order=priority%2Cbug_severity&limit=0
https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&product=Core&target_milestone=mozilla46