Revert aarch64 fixup for ESR 60-based bundles with Tor Browser 9
We solved #31616 (moved) and #31140 (moved) by making sure the JIT prefs are not enabled via our security slider on aarch64.
We need to revert that for Tor Browser 9 and make sure that the security level is actually reset to low for those users whose level got set to custom due to the workaround we deployed. (Doing the latter might actually not be trivial).
Activity
For review: https://github.com/acatarineu/torbutton/commit/31730.
Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201910 deleted, TorBrowserTeam201910R addedActually, I think https://github.com/acatarineu/torbutton/commit/31730+1 is a bit more precise. This will preserve the user custom state if they did not change any of the
javascript.options.*prefs (but some of the others).If I was smart, I would've saved the current prefs somehow before we overwrote them, but I didn't think about that. Unfortunately, I'm worried about changing these. On the one hand, custom prefs aren't recommended but they are allowed. If we change this without notifying the user then we could be putting them at risk. We should probably include a warning about this in the release announcement, at a minimum.
I think we should set
kCustomPrefasfalseif all the prefs are set as level 4. What do you think? Can you add a functionisSecurityLevel(index)that takes an index and iterates throughkSecuritySettings, returns true if they match the expected value and false otherwise? Or something like this?Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam201910R, tbb-9.0-must deleted, TorBrowserTeam201910R tbb-9.0-must addedIn the first version which I didn't push I was doing a similar thing, reusing the function
read_setting_from_prefs. I think I switched to just checking the security level because I thought in any case it would be possible to set these prefs totruewithout user wanting, and that it would not be very likely that a user which did not change the security level slider would have setion,baselinejitandnative_regexpmanually tofalse.But I think the one you suggest is probably better here, it's on the safer side. It's true that there could be the case that a user kept level 4 and just flipped some of
media.webaudio.enabled,mathml.disabled,gfx.font_rendering.opentype_svg.enabledorsvg.disabled, in which case with the this fix we would wrongly keepion,baselinejitornative_regexptofalse(with an unnecessary performance hit). But given that no solution is perfect, I think it's better to prioritize security over performance.For both fixes, there's always the case that for a user who kept security level to 4 and disabled
ion,baselinejitornative_regexpwe will be wrongly enabling these. So I think in any case having some warning it's good, not sure where. Probably somewhere in release notes and/or blog post is enough.So here is the revised fix: https://github.com/acatarineu/torbutton/commit/31730+2
I'm also checking that the slider value is 4, to rule out cases where user moved the security slider to < 3 but flipped some prefs in a way that those have the same value as level 4 (very unlikely, but...).
