[tor-dev] introduce some customization on the tbb
Richard Pospesel
richard at torproject.org
Thu Nov 14 19:38:49 UTC 2019
> and about windows,
> it is a requirement for my situation , but i just saw some build scripts
> regarding windows in the tbb repo you mentioned; i would be happy to
> hear from you about tips and tricks regarding windows!
So tor-browser-build lets us make all our build targets (windows, mac,
android, etc) on a Linux host (I'm 99% sure those of us using it are all
using Debian or Debian derivatives).
If you are stuck using windows for whatever reason there may be a few
options (though none of them are particularly good):
It *may* be possible to get tor-browser-build working in the new Windows
Subsystem for Linux in Windows 10, but to my knowledge no has tried it.
Maybe you can just clone the repo, apt-get the dependencies and go.
Another option for you would be running a Debian VM in
HyperV/VirtualBox/etc and running tor-browser-build there, but that
first build will definitely take awhile.
Yet another option would be to acquire the tor-browser-build build
artifacts necessary to build Windows firefox, and setup a Debian build
environment (via your preferred virtualization method) and replicate the
firefox project's build process.
> 1) padding is the time period which i send random packets to random
> destinations for generating fake browsing pattern.
I'm not sure what this is supposed to accomplish, and my first instinct
is that this is a very bad idea. See
https://2019.www.torproject.org/projects/torbrowser/design/#idm660 for
discussion around why we don't use randomization as a strategy to avoid
fingerprinting. I highly doubt we would want anything like this in Tor
Browser
> 2) rotation is a fancy name for MaxCircuitDirtiness
I feel like this is a sort of knob that only 'advanced' users
should/would use, an as such keeping it in the torrc and not exposing it
in the user-facing preferences page is probably best. We generally want
to avoid leaving foot-guns laying around.
> 3) idle timeout is a custom clock which will close the tbb automatically
> in case of no interaction from the user
Could be a neat off-by-default option to have in the 'Privacy &
Security' page (as it is not tor-specific). I'm not sure if we'd accept
this feature but I think a case could be made.
> 4) use proxy & use bridge is already available inside tbb
Indeed
> 5) entry, middle and exit countries will fill the torrc with user
> selected options
This one actually intrigues me a little bit. There are certainly
situations where on a per-site basis controlling which country your exit
is can be useful (for avoiding IP-based censorship, 'this video not
available in your country' nonsense). As it is the current 'hit new
circuit until it works' workflow is not the best.
I don't see any particular benefit exposing this level of control over
guard and middle relays, nor do I think the exits should be a global
setting. The level of control exposed as you have in these screenshots
seems like another foot-gun.
best,
-Richard
On 11/14/19 1:55 AM, sarpedon montecarlo wrote:
> Hi Richard, this is great!
> I appreciate all the insights you gave me.
> about the build setup i would definitely go with your suggestion. maybe
> it would be possible to also use these build scripts inside a docker
> composer for a reload on demand during development. and about windows,
> it is a requirement for my situation , but i just saw some build scripts
> regarding windows in the tbb repo you mentioned; i would be happy to
> hear from you about tips and tricks regarding windows!
>
> basically what i am about to implement are as below:
>
> image.png
>
> image.png
>
> image.png
>
> above screen shots are from the browser extension that i have already
> implemented and want to integrate with the tbb.
>
> 1) padding is the time period which i send random packets to random
> destinations for generating fake browsing pattern.
>
> 2) rotation is a fancy name for MaxCircuitDirtiness
>
> 3) idle timeout is a custom clock which will close the tbb automatically
> in case of no interaction from the user
>
> 4) use proxy & use bridge is already available inside tbb
>
> 5) entry, middle and exit countries will fill the torrc with user
> selected options
>
> based on the commit you mentioned for "about:preferences#tor pane", i
> believe that commit is the right place i should start coding.
>
> Best Regards,
> Sarpedon
>
> On Wed, Nov 13, 2019 at 9:33 PM Richard Pospesel <richard at torproject.org
> <mailto:richard at torproject.org>> wrote:
>
> Hey Sarpedon,
>
> The tor-browser-build project (
> https://gitweb.torproject.org/builders/tor-browser-build.git/ ) can be
> used to build tor-browser for all the various environments, and you can
> updated the /projects/firefox/config file to point to your own git repo
> and commit for development. Unfortunately this is not particularly fast,
> but it's really the only way to go if you need builds for platforms
> other than Linux.
>
> Alternatively, you can just build tor-browser (
> https://gitweb.torproject.org/tor-browser.git/ ), and copy the relevant
> bits over an existing tor-browser install. This is the workflow I use
> during development on Linux and is generally pretty straight forward to
> use once you have scripts setup to do the deploying.
>
> It's theoretically possible to get this sort of incremental build setup
> working for other platforms (ie building windows bins in a linux dev
> environment), but it's a pain and would require delving into the
> tor-browser-build firefox build and config scripts. I've done it before
> for our older windows build target (before we switched to clang and
> friends) and can give you some tips on how to do that if necessary.
>
> The Tor Browser Hacking Guide should be a good resource as well, though
> it is a living document so might be out of date:
>
> https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking
>
> If you're interested in updating/improving/adding to the
> about:preferences#tor pane, than you can start by looking at this commit
> which added the page:
>
> https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-68.2.0esr-9.5-1&id=bea7e61c120f207e7e1a65041b44dc1998e3656a
>
> In general, the relevant things there are in:
>
> /browser/components/torpreferences/*
> /browser/modules/TorProtocolService.jsm
> /browser/modules/TorStrings.jsm
>
> What sort of improvements are you looking to add? If you're interested
> in submitting a patch, you should open a ticket that tracks whatever
> feature you're looking to add. There we can give you early code and
> design/UX feedback to improve the odds of us accepting your patch :)
>
> best,
> -Richard
>
>
> On 11/9/19 4:04 PM, sarpedon montecarlo wrote:
> > Hello to the community!
> > my first question is that is there a solution for rapid development of
> > tbb? i was wondering that each time a contributor wants to change
> > something in the tbb or add extra functionality, they have to go
> through
> > the build process which i just guess would be very time consuming.
> i was
> > wondering that is there any containerized environment for this? any
> > docker ecosystem available or other solutions that might help?
> > my second question is about the changes that i want to implement. i am
> > interested into the graphical settings page about bridges and tor
> > process that currently tbb is exposing to the end users. if we want to
> > add more functionality into this settings page, where should we
> start to
> > change? and is there any possibility that we may have some control
> over
> > the underlying tor process as well, for instance controlling it's
> > launching or it's torrc configuration; because as i see, there
> must be a
> > link between the graphical interface of tbb and the underlying tor
> > process so that is the way we can control bridges for instance.
> similar
> > to this i was planning to add more graphical options to the interface
> > for controlling other configuration aspects of the tor process through
> > it's torrc or other workarounds.
> > in the past i have achieved this by writing a browser extension that
> > benefits from native messaging for communication to the tor
> process; but
> > this is not really performance friendly and an intuitive
> experience for
> > the end users.i am not satisfied with the result. so i was
> interested on
> > mirroring these functionalities inside tbb.
> > i really appreciate your insights and thoughts on the matter,
> > have a great day,
> > Sarpedon.
> >
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at lists.torproject.org <mailto:tor-dev at lists.torproject.org>
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> >
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org <mailto:tor-dev at lists.torproject.org>
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20191114/4b19b9e8/attachment.sig>
More information about the tor-dev
mailing list