Remove HTTPS-Everywhere extension from esr102-based Tor Browser Android

added Next label

assigned to @ma1

added Android Sponsor 131 FF102-esr labels

changed milestone to %Sponsor 131 - Phase 3 - Major ESR 102 Migration

added Q3 label

added Doing label and removed Next label

Facing a dilemma.

The patch I've made uninstalls HTTPS Everywhere if it's not been uninstalled yet, but only if HTTPS-Only is still enabled, on the assumption that alpha2 users who turned HTTPS-Only back off did that because for any reason (bugs?) they opted to rather keep relying on the extension.

Now I'm questioning if this is actually a valid concern, even though I'd feel uncomfortable leaving such a user without any HTTPS-enforcing mechanism (by skipping the "HTTPS-Only still enabled" check).

If it is a valid concern (at least for alpha3), though, I should suspend the work I'm doing

1. on tor-browser-build to prevent HTTPSE from being bundled in the builds,
2. on GeckoView to remove the HTTPSE references (OnionAliasStore.jsm & HttpsEverywhereControl),

and submit just the fenix patch for now.

@richard, @pierov , what do you think?

I think leaving this logic in is fine for alpha, once we transition to stable in November we can rip this logic out entirely (assuming we don't run into any catastrophic bugs) and just always remove the extension since it's no longer being maintained.

It's a good question and good concerns.

I think on desktop we did not have to address this because HTTPS-E was a system addon and IIRC we already had a logic to uninstall it if the user installed it from AMO.

On Android we installed it, but we don't have any way to tell when we did it and if the user did it. So, I hope this does not transform in a battle between users that absolutely want HTTPS-E (even if deprecated) with our logic.

What about removing the extension once, and then not doing it anymore?

who turned HTTPS-Only back off did that because for any reason (bugs?) they opted to rather keep relying on the extension.

I fear some users could disable it because they're annoyed by error messages.

Should we show a confirmation dialog to warn users that disabling HTTPS-Only is a dangerous choice?

We wanted to hide HTTPS-Only preferences, but we haven't done it yet because we want also to leave the exception dialog available, for now (well, it does not work very well even with Firefox/PBM, in my experience).

on GeckoView to remove the HTTPSE references (OnionAliasStore.jsm & HttpsEverywhereControl),

Alpha 3 for Android was intended to be on the same branch as desktop.

Things are going long, and after what we said yesterday, this will happen with alpha 4, maybe.

Still, I would not bother to patch GV, unless removing HTTPS-E results in errors. IIRC, these features are already not used in Android, because they were never implemented properly. At most, I'd revert the commits.

What about removing the extension once, and then not doing it anymore?

FWIW my patch already check this by setting a permanent httpsEverywhereRemoved boolean (in the same vein of noscriptInstalled), so that users can choose of reinstalling the extension in future and not be bothered again by automatic removal.

Additionally in next alpha iteration (and in 12 stable), when we won't check anymore for HTTPS-Only enablement, I'd suggest to forcibly flip it On contextually to the HTTPS Everywhere one-time removal and, again, stop doing further automated changes.

FWIW my patch already check this by setting a permanent httpsEverywhereRemoved boolean (in the same vein of noscriptInstalled), so that users can choose of reinstalling the extension in future and not be bothered again by automatic removal.

Great, that's what I meant, I just haven't seen the patch, yet .

Additionally in next alpha iteration (and in 12 stable), when we won't check anymore for HTTPS-Only enablement, I'd suggest to forcibly flip it On contextually to the HTTPS Everywhere one-time removal and, again, stop doing further automated changes.

Makes sense. We need to do further testing if updating works as expected (i.e., if HTTPS Only is enabled when updating a fresh 11.5aX to 12.0aX).

mentioned in merge request fenix!152 (merged)

mentioned in commit fenix@a8b8273e

mentioned in commit fenix@81f03fff

mentioned in issue #41160 (closed)

Fixed by fenix!152 (merged). Follow up in #41160 (closed). /remove Doing

closed

removed Doing label

marked this issue as related to tor-browser-build#40609 (closed)

marked this issue as related to tor-browser-build#40609 (closed)