Great , is all i need to start, many thanks. 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <[email protected] >:
> > I think it would work like the start/status intents that are currently > in Orbot. The app sends an Intent to Orbot to request a Hidden Service > to be created, then Orbot sends reply status Intents to the app that > made the request with all relevant info, including a FileProvider URI > with GRANT URI permissions so that the requesting app can get the > private key. That'd be the whole API, unless you also want to make a > "stop hidden service" Intent. > > No need to change anything about the control, the whole API would be > based on those Intents, and we can use the TrustedIntents library to > enforce that the reply only goes to the exact app that requested it. As > a start, it would be fine to send the reply based on packageName. > > .hc > > arrase: > > Are you suggesting something? XD > > > > I can take a look at the problem and propose a solution, it will not be > > fast but I can do it. > > > > Tonight I will try to compile Orbot from sources and try to familiarize > > myself with the code. (Is there a wiki with info??) > > > > How do you want to focus the change? What should be possible by a third > > party? > > > > In my opinion: > > > > - Be able to register a hidden service for your ports without sharing it > > with other applications. > > - Be able to backup the configuration files in order to migrate the > service. > > - Everything should be possible without root > > > > It would be nice if all this was possible without giving access to the > Tor > > configuration port, but right now I can not think of how to do it. > > > > I keep thinking ..... after working, I'll dedicate some time to the > problem > > > > > > 2016-11-15 14:19 GMT+01:00 Hans-Christoph Steiner < > [email protected] > >> : > > > >> > >> > >> arrase: > >>> 2016-11-15 13:23 GMT+01:00 Michael Rogers <[email protected]>: > >>> > >>>> Hi arrase, > >>>> > >>>> Thanks for discovering this bug. Can you describe how Briar's Tor > daemon > >>>> conflicts with Orbot? What problems does it cause? Our goal is for > Briar > >>>> to be able to operate on the same device as Orbot without problems. > >>>> > >>>> > >>> I do not think it could be called a bug, and definitely not a Briar bug > >> at > >>> all. I find it hard to argue in English, I'm sorry. > >>> > >>> But if it is true that is a problem if more applications follow the > same > >>> path as Briar implementing a Tor daemon within the application. > >>> > >>> Briar opens those ports for Tor: > >>> > >>> Tcp 0 0 127.0.0.1:59050 0.0.0.0:* LISTEN 10019 214952 18753 > >>> Tcp 0 0 127.0.0.1:59051 0.0.0.0:* LISTEN 10019 213387 18753 > >>> > >>> If Orbot starts first, nothing prevents it from taking ports 59050 and > >>> 59051 as control ports. It is a remote but real possibility and would > be > >>> more real when more applications opt for the same solution. > >>> > >>> It's just an argument about changing the hidden service API for Orbot. > >>> > >>> I think there are more strong arguments like that each application can > >>> manage the configuration files of the hidden service to be able to > >> migrate > >>> between devices. > >>> > >>> It does not look very good to make an application that uses the hidden > >>> service as a user identifier and if we lose the device we lose our > entire > >>> network of contacts. > >>> > >>> I think they are good arguments for bringing about an improvement in > >> Orbot > >>> APi as proposed by Nathan. > >> > >> I think we all want to have a nice Intent-based API in Orbot for apps to > >> work with Hidden Services, the real question is: who is going to do the > >> work. That would be a great place for you to start to get involved. > >> > >> .hc > >> > >> > >> -- > >> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 > >> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 > >> _______________________________________________ > >> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > >> To unsubscribe, email: [email protected] > >> > > > > -- > PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 > https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 >
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
