[tor-bugs] #10760 [Applications/Tor Browser]: Integrate TorButton to TorBrowser core to prevent users from disabling it
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed May 8 14:35:27 UTC 2019
#10760: Integrate TorButton to TorBrowser core to prevent users from disabling it
-------------------------------------------------+-------------------------
Reporter: Rezonansowy | Owner: tbb-
| team
Type: defect | Status: new
Priority: High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: AffectsTails, tbb-parity, | Actual Points:
TorBrowserTeam201904, GeorgKoppen201904 |
Parent ID: #24855 | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Changes (by gk):
* status: needs_information => new
Comment:
Replying to [comment:29 acat]:
> Are there any issues of using in desktop the same
`toolkit/torproject/torbutton` used already in Android (#25013)?
Not really issues, see below.
> Here https://github.com/acatarineu/tor-browser/commit/10760 I took the
patch from #28044 (https://gitweb.torproject.org/user/brade/tor-
browser.git/commit/?h=bug28044-01&id=79f8ea9c98c69eb594e7d2aace9199b3bceb22cb)
and did the same for torbutton, seems to work fine too. Note that `tor-
launcher` patch uses the path `browser/extensions/tor-launcher`, while
current Android and also this one uses `toolkit/torproject/torbutton`. I
realized that in this case the final code goes to `/chrome/torbutton`
inside `omni.ja` instead of `browser/omni.ja` as tor-launcher. Is one path
preferred to the other?
I think the reason Tor Launcher is in the `browser` dir is that we don't
have a Tor Launcher on Android (and won't have one), thus it is desktop-
specific. While that's not the case for Torbutton (even though we don't
use the tor-browser version for desktop yet).
> There is this `GetOverrideStringBundle` function in
https://gitweb.torproject.org/tor-
browser.git/tree/toolkit/xre/nsAppRunner.cpp?h=tor-
browser-60.6.1esr-8.5-1&id=178fcbbe24f543a15b165bdc680a5083247e87a3#n1823
that would need to be fixed, since the XPI would not be there. But I
wonder if this code is still needed since `general.useragent.locale` pref
is not there anymore (was moved to `intl.locale.requested`).
Good question and I don't know the answer to it right now...
> If this ticket is in the context of ESR68, then of course there is more
work to do. But if it's just `Integrate TorButton to TorBrowser core to
prevent users from disabling it` I think this patch might be good enough
(together with a change in `tor-browser-build`, will do if this approach
is fine). Perhaps we could track porting to ESR68, refactoring common
parts with tor-launcher, etc. in separate tickets. Or make this ticket
include all those, and keep working on this one.
>
> Also, not sure if the idea is to abandon the `torbutton` git repository
in favour of continuing development in `tor-browser` repo. According to
https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/102
-integrate-tor-launcher-into-tor-browser.txt the plan for `tor-launcher`
is to keep the repo, would this also be fine for `torbutton`?
This is a thing we wanted to do for a while now. So, it has not been
really ESR68-related. However, I felt we could start integrating the
remaining Torbutton pieces directly into the browser while we are at it
and while we need to make substantial changes to our UI anyway (given that
there are no overlays anymore in esr68). In that sense it *is* an esr69
item and we should make progress as much as we can now so we have less to
fix later on.
Ideally we would not even have Torbutton as an extension and separate repo
anymore at the end of the process, probably "just" some JS modules
somewhere in `toolkit` and the UI in the respective files per platform.
(Hence the proposal idea as this is not just making a git submodule
anymore).
We should get rid of the onion button in the toolbar, for instance, and
expose the new identity feature as a button instead directly (the update
check in the menu can go, I think, and the other item is a tor launcher
overlay which we need to think about what to do in the still open tor
launcher bug).
I am happy to take a step-wise approach here obviously. The obvious choice
would be 1) get it into tor-browser ala #28044, 2) make the things
compatible with esr68 3) get rid of it as an own extension, however, I
hoped we can avoid doing the full 2) and then 3) by doing part (or the
whole!) 3) while doing minimal 2). :)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10760#comment:30>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list