[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library
#27609: TBA: Evaluate Tor Onion Proxy Library
-------------------------------------------------+-------------------------
Reporter: sysrqb | Owner: tbb-
| team
Type: defect | Status: new
Priority: Very High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: tbb-mobile, TorBrowserTeam201812, | Actual Points:
TBA-a3 |
Parent ID: | Points:
Reviewer: | Sponsor:
| Sponsor8
-------------------------------------------------+-------------------------
Comment (by sisbell):
Replying to [comment:18 sysrqb]:
> Replying to [comment:15 sisbell]:
>
>
>
> > Evaluation:
> >
> > 1. Tor Installation: Tor Onion Proxy library is using tor-android-
binary - Who is going to install the tor binary? Orbot or Tor Onion Proxy
Libray. If orbot installs, we will need to configure the onion proxy to
use those locations for tor files/libraries.
> >
> >
> >
>
> We'd use this instead of Orbot. This library would completely replace
our Orbot implementation.
>
>
>
>
> > 1. Settings Screen: there is no settings screen: configure ports,
delete/add onion addresses [these features need to be defined]
> >
> >
> >
>
> Right. We'll need to create our own UI for Orbot and TOPL, so I don't
consider this a blocker.
>
>
>
>
> > 1. Starting Proxy: This is a simple operation to start but we need to
display the startup logs to the user. We also need to define UI to handle
things like restart or shutdown.
> > 1. Stability: Its workable for an alpha, but we should cleanup up the
threading and socket connections
> >
> >
> >
> >
>
> This is what I'm primarily worried about. Is the code quality where we
need it. Is it tested? Is the code safe (for some value of safe)? With
Orbot, we weren't exposing our users to new code (because Orbot was
previously a dependency). If we use TOPL then we should be confident this
won't be worse.
I tested it back in February of this year and it works. While working on
the code, I didn't see anything jumping out as unsafe. It's straight-
forward.
>
>
>
>
> > In summary: this is not a simply a drop-in. It will need a UI defined
and built but core functionality is all there. Suggest cleanup of
threading before a production release.
> >
> >
> >
>
> Can you estimate how much time this will require? Would we need to re-
write much of the code and redesign it?
Its no more than one week to cleanup threading and the other async
handling. So not much of the code would need to be re-written. I'm seeing
TOPL library as more of a replacement for orbotservice.
So far I see we need to bring in Orbot app features (not complete list)
1. Build our pluggable transports (this is currently handled as part of
orbot dependency)
1. Transport lifecycle (start/stop)
1. Onboarding flow
1. Cookie management
1. Hidden services management
1. Additional permissions handling
1. UI for bootstrap
1. Tor, transports and other binary installations (some of this is
already included in TOPL)
1. Tor lifecycle/bootstrap (already there but needs some modification)
We can break this into service components and front-end UI components.
its hard to give exact estimate without going through full list of
features first. Here is an initial estimate
* Bring TOPL inline with orbotservice - 1 week
* Pluggable transport build - ??? needs more investigation
* Re-write of Orbot UI and providers - 3 weeks
So best case would be about one-man-month. If we wanted to be keep Orbot
but just integrate TOPL and remove orbotservice, we would be looking at
more like 2 weeks.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27609#comment:19>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs