[guardian-dev] Hi, i' new

[Hans-Christoph Steiner]

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