[guardian-dev] how to do clean tor integration in Orfox

[Amogh Pradeep]

> On Sep 18, 2015, at 10:45 PM, Nathan of Guardian <nathan at guardianproject.info> wrote:
> 
> 
> 
> On Fri, Sep 18, 2015, at 01:06 PM, Amogh Pradeep wrote:
>> 
>>> On Sep 17, 2015, at 6:52 PM, Hans-Christoph Steiner <hans at guardianproject.info <mailto:hans at guardianproject.info>> wrote:
>>> 
>>> 
>>> Orfox was working pretty well in general as a browser.  Amogh added NetCipher
>>> to get the automatic Tor starting.  That started Orbot fine, but Orfox errored
>>> out on any websites that it tried to load while waiting for Orbot to start
>>> Tor.  So I implemented an approach that makes the orbot starting stuff
>>> transparent, and tries to make Orfox transparently hold loading any pages
>>> until Tor is ready.  This used the internal Fennec event "Tab:Load".  The
>>> problem with that approach is that the Fennec UI blocks and waits for the
>>> Gecko engine to respond to any "Tab:Load" messages that have been sent.
>> I agree that we need to make major UI changes to integrate the two
>> applications properly.
>> I’d be able to implement it if someone gave me a clear idea on what
>> exactly to do, UI wise.
> 
> I strongly disagree that we need to make major UI changes, because once
> we do that, it becomes a much bigger problem to maintain and update
> Orfox.
That is a valid point. Maintenance
> 
> The problem you are trying to deal with is one that happens rarely for
> the typical Orbot user. Most people keep Orbot running all of the time
> in the background on their phone. This is how a typical VPN is used as
> well. They don't selectively start and stop it, and if they did, that
> would create a pretty poor user experience based on the time it takes to
> boostrap into the Tor network.
> 
>>> 
>>> I also tried queuing incoming Intents that cause a web page to be loaded, but
>>> that only works for new URLs coming in.  If Orfox is not running, then it is
>>> started and wants to load a few tabs from the previous session, those will all
>>> show the failure to connect page since they are not being started by Intents,
>>> but rather the internal Tab:Load messages.
>>> 
>>> I also thought about just going back to the old Orbot start Intent that
>>> launched Orbot itself, but upon thinking about that, I think it would really
>>> handle error conditions badly, like when Orbot fails to start properly,
>>> because going to Orfox would always just redirect to Orbot.
>>> 
>>> Now, I'm thinking the best approach includes two key pieces:
>>> 
>>> * remove the Tab:Load queuing that is there now, and switch back to the Intent
>>> queuing method I had going before.
>>> 
>>> * update the "proxy connection failed" page so that it shows the Tor status
>>> (OFF/STARTING/ON/STOPPING)  That page will also include the "Try Again" button
>>> that is there.  Also, when STATUS_ON is received from Orbot, that page can
>>> automatically try again.  We should probably also add a button that brings up
>>> the Orbot main screen so that users can easily troubleshoot the Tor connection
>>> in Orbot.
>> I think this would be awesome. If we could redirect to a help page in
>> case the proxy connection isn’t fine (Orbot isn’t fine) and we help the
>> user troubleshoot on that page, it would be a nice UX.
> 
> This sounds like a good small change that we could manage.

I guess managing this one page would be the best solution then, that shouldn’t be too hard to maintain either.

> 
> 
> --
>  Nathan of Guardian
>  nathan at guardianproject.info
> _______________________________________________
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org


PS: Sorry for the triple reply for the earlier mail, I had email client problems!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20150918/eda94879/attachment.sig>