Nathan of Guardian: > > > On Fri, Sep 18, 2015, at 01:06 PM, Amogh Pradeep wrote: >> >>> On Sep 17, 2015, at 6:52 PM, Hans-Christoph Steiner >>> <[email protected] <mailto:[email protected]>> 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. > > 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 don't think we need major UI work. Really just changing that proxy page I think could cover what we need. That said, I disagree that proxy failure is a rare situation. It happens to me a lot on my devices. I think that Orbot frequently fails after sleep then wakeup. And I have to manually restart Orbot to get it working again. But of course, it would be better to get Orbot solidly reliable. There is another case that I've seen that I'm guessing at. Orfox sometimes shows the regular "failure to connect" page when the internet is working. My guess is that the SOCKS port is open before tor is ready to deliver circuits, so connecting to the SOCKS proxy is working, but a connection to the internet cannot be made. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
