[guardian-dev] Hi, i' new

[Hans-Christoph Steiner]

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 <hans at guardianproject.info
>> :
> 
>>
>>
>> arrase:
>>> 2016-11-15 13:23 GMT+01:00 Michael Rogers <michael at briarproject.org>:
>>>
>>>> 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:  guardian-dev-unsubscribe at lists.mayfirst.org
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556