Re: [guardian-dev] Hi, i' new

[arrase]

2016-12-06 19:51 GMT+01:00 arrase :

>
>
> On Mon, Nov 21, 2016, at 10:35 AM, Mihkel Raba wrote:
>>> > There are other tor settings also entered manually. For example access
>>> > to hidden service that requires cookie auth.
>>> > HidServAuth site.onion mycookie
>>> >
>>> > Currently i use this feature to access my servers.
>>>
>>> This is a good point, but more about being a client for a hidden
>>> service, and not hosting one.
>>>
>>> That said, I have been thinking about supporting a URI format (as we do
>>> for bridges currently), so we can open links and scan QR codes for
>>> HidServAuth features.
>>>
>>
> I'm working on this, is almost done
>

New feature added: HidServAuth manager and QR share

https://github.com/n8fr8/orbot/pull/62
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[arrase]

thank you :)

2016-11-23 2:00 GMT+01:00 Mark Murphy :

> On Tue, Nov 22, 2016, at 19:57, arrase wrote:
> > Ouch! the app builds but:
> >
> > AndroidRuntime: java.lang.RuntimeException: Unable to get provider
> > com.commonsware.cwac.provider.StreamProvider:
> > java.lang.IllegalArgumentException: Failed to parse
> > com.commonsware.cwac.provider.STREAM_PROVIDER_PATHS meta-data
>
> You did not replace android:name with the fully-qualified class name of
> your StreamProvider subclass. StreamProvider does not know about your
> custom tag.
>
> For further help with StreamProvider, please use:
>
> https://github.com/commonsguy/cwac-provider#questions
>
> --
> Mark Murphy (a Commons Guy)
> https://commonsware.com | https://github.com/commonsguy
> https://commonsware.com/blog | https://twitter.com/commonsguy
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[Mark Murphy]

On Tue, Nov 22, 2016, at 19:57, arrase wrote:
> Ouch! the app builds but:
> 
> AndroidRuntime: java.lang.RuntimeException: Unable to get provider
> com.commonsware.cwac.provider.StreamProvider:
> java.lang.IllegalArgumentException: Failed to parse
> com.commonsware.cwac.provider.STREAM_PROVIDER_PATHS meta-data

You did not replace android:name with the fully-qualified class name of
your StreamProvider subclass. StreamProvider does not know about your
custom tag.

For further help with StreamProvider, please use:

https://github.com/commonsguy/cwac-provider#questions

-- 
Mark Murphy (a Commons Guy)
https://commonsware.com | https://github.com/commonsguy
https://commonsware.com/blog | https://twitter.com/commonsguy
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[Mihkel Raba]

Hello


There are other tor settings also entered manually. For example access
to hidden service that requires cookie auth.
HidServAuth site.onion mycookie

Currently i use this feature to access my servers.

On 21.11.2016 15:04, arrase wrote:
>
> And the services that a user configure manually? Why do you have to
> lose them?
>
>
> El 21 nov. 2016 2:00 p. m., "Hans-Christoph Steiner"
> > escribió:
>
>
> About the hidden service backups, that certainly would be a useful
> feature, but it should not be implemented in Orbot.  The
> requesting apps
> need to be entirely responsible for saving, managing and backing
> up that
> key.  Orbot will never be able to provide all of the various levels of
> security needed by different apps using Hidden Services.  For example,
> something like OnionShare might only have one-time-use Hidden Services
> that are thrown away after use.  Another app might have a long-lived
> hidden service that is too sensitive to be backed up via Google or
> other
> cloud services.
>
> .hc
>
> arrase:
> > 2016-11-21 0:25 GMT+01:00 Nathan of Guardian
> >:
> >
> >>
> >> We only need Internet permission, so haven't had to deal with
> the new
> >> permission request framework.
> >>
> >> Why do we need a backup feature? I thought the approach was for
> apps to
> >> manage their keys themselves, at least advanced apps?
> >>
> >
> > By example, if you have ssh running at your device and you want
> to maintain
> > the same .onion in a device migration.
> >
> > You can manually create and restore an .onion backup from one
> device to
> > another.
> >
> >> Even so, couldn't we offer backup without needing external storage
> >> permissions?
> >>
> >
> >  With the ability to be exported to another device writing a zip
> in the
> > external store is the simplest I think.
> >
> >
> >> I bring this up because I know our users are very sensitive to
> this, and
> >> the external storage permission is one that often sets off
> concern since
> >> you are giving access to full media.
> >>
> >
> > Well, is true but with runtime permissions the user is asked
> only when is
> > going to perform an action who actually needs them, so you can
> assume than
> > there is no panic if the app ask for those permissions.
> >
> > Also, the permissions were already there before I started to
> make changes,
> > so we understand that all those users who have an older version
> of android
> > have to accept them when installing the application from the
> store and does
> > not seem to have been a Problem for Orbot to date.
> >
> > On the other hand, it seems that they are not used in the
> application, if
> > they are not used, why are they there? And if they are used, the
> parts of
> > the code that use them are not working in the latest versions of
> android
> > since there is no code that manages them.
> >
> > That needs a review.
> >
> >
> >> Thanks for the hard work on this, and I will definitely take a
> look at
> >> the UI issues.
> >>
> >
> > To you.
> >
>
> --
> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
> 
>
>
>
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[arrase]

2016-11-21 16:47 GMT+01:00 Hans-Christoph Steiner :

>
>
> Nathan of Guardian:
> >
> >
> > On Mon, Nov 21, 2016, at 05:21 AM, Hans-Christoph Steiner wrote:
> >> What use case are you thinking for manually setting up a hidden service
> >> in Orbot?
> >>
> >> Orbot doesn't provide any actual services beyond Tor and internet
> >> proxying, so it seems that its not really the place for setting up and
> >> managing hidden services.
> >
> > I do see value here for medium to advanced users, that want to use Orbot
> > with apps that do not support setting up hidden servers directly. This
> > is mostly remote access to on device HTTP servers, SSH servers and so
> > on. Today, we have many users who do this through the existing Orbot
> > settings, where you can manually enter a port, and the onion service is
> > generated. Arrase is just extending that behavior with a better user
> > interface. I think it is a valid use of Orbot.
>
> That's going to add a fair amount of complexity to Orbot, as well as the
> requirement to save valuable state info (i.e. beyond the regular setup).
>  Seems like we should have a strong use case for this before taking it
> on.  People who want to run servers on their phone can always use
> linuxdeploy, Lil' Debi, etc.
>
>

But the feature is currently there, why we have to lose it?
Maintain backwards compatibility as much as possible is a good idea.

Currently the only documented use of orbot for run hidden services is open
the settings a manually add a port.

And i use that feature, i don't like to code for loose it.

On the point of saving more information, I do not see the problem, I have
solved it with a content provider that consults a database with a single
table, simple and easy to maintain.

Most of the work is done, we just need to improve the acquisition of
permissions and improve layouts.

I suggest to take a look at the work already done.

https://github.com/arrase/orbot/tree/hidden_services

There is not more complexity, just a simple list with a button to add, but
the added features have been many and without breaking compatibility back.


.hc
>
> >
> >
> >
> >>
> >> .hc
> >>
> >> arrase:
> >>> And the services that a user configure manually? Why do you have to
> lose
> >>> them?
> >>>
> >>> El 21 nov. 2016 2:00 p. m., "Hans-Christoph Steiner" <
> >>> h...@guardianproject.info> escribió:
> >>>
> 
>  About the hidden service backups, that certainly would be a useful
>  feature, but it should not be implemented in Orbot.  The requesting
> apps
>  need to be entirely responsible for saving, managing and backing up
> that
>  key.  Orbot will never be able to provide all of the various levels of
>  security needed by different apps using Hidden Services.  For example,
>  something like OnionShare might only have one-time-use Hidden Services
>  that are thrown away after use.  Another app might have a long-lived
>  hidden service that is too sensitive to be backed up via Google or
> other
>  cloud services.
> 
>  .hc
> 
>  arrase:
> > 2016-11-21 0:25 GMT+01:00 Nathan of Guardian <
>  nat...@guardianproject.info>:
> >
> >>
> >> We only need Internet permission, so haven't had to deal with the
> new
> >> permission request framework.
> >>
> >> Why do we need a backup feature? I thought the approach was for
> apps to
> >> manage their keys themselves, at least advanced apps?
> >>
> >
> > By example, if you have ssh running at your device and you want to
>  maintain
> > the same .onion in a device migration.
> >
> > You can manually create and restore an .onion backup from one device
> to
> > another.
> >
> >> Even so, couldn't we offer backup without needing external storage
> >> permissions?
> >>
> >
> >  With the ability to be exported to another device writing a zip in
> the
> > external store is the simplest I think.
> >
> >
> >> I bring this up because I know our users are very sensitive to
> this, and
> >> the external storage permission is one that often sets off concern
> since
> >> you are giving access to full media.
> >>
> >
> > Well, is true but with runtime permissions the user is asked only
> when is
> > going to perform an action who actually needs them, so you can assume
>  than
> > there is no panic if the app ask for those permissions.
> >
> > Also, the permissions were already there before I started to make
>  changes,
> > so we understand that all those users who have an older version of
>  android
> > have to accept them when installing the application from the store
> and
>  does
> > not seem to have been a Problem for Orbot to date.
> >
> > On the other hand, it seems that they are not used in the
> application, if
> > they are not used, why are they there? And if they are used, the
> parts of
> 

Re: [guardian-dev] Hi, i' new

[Nathan of Guardian]

On Mon, Nov 21, 2016, at 05:21 AM, Hans-Christoph Steiner wrote: 
> What use case are you thinking for manually setting up a hidden service
> in Orbot?
> 
> Orbot doesn't provide any actual services beyond Tor and internet
> proxying, so it seems that its not really the place for setting up and
> managing hidden services.

I do see value here for medium to advanced users, that want to use Orbot
with apps that do not support setting up hidden servers directly. This
is mostly remote access to on device HTTP servers, SSH servers and so
on. Today, we have many users who do this through the existing Orbot
settings, where you can manually enter a port, and the onion service is
generated. Arrase is just extending that behavior with a better user
interface. I think it is a valid use of Orbot.



> 
> .hc
> 
> arrase:
> > And the services that a user configure manually? Why do you have to lose
> > them?
> > 
> > El 21 nov. 2016 2:00 p. m., "Hans-Christoph Steiner" <
> > h...@guardianproject.info> escribió:
> > 
> >>
> >> About the hidden service backups, that certainly would be a useful
> >> feature, but it should not be implemented in Orbot.  The requesting apps
> >> need to be entirely responsible for saving, managing and backing up that
> >> key.  Orbot will never be able to provide all of the various levels of
> >> security needed by different apps using Hidden Services.  For example,
> >> something like OnionShare might only have one-time-use Hidden Services
> >> that are thrown away after use.  Another app might have a long-lived
> >> hidden service that is too sensitive to be backed up via Google or other
> >> cloud services.
> >>
> >> .hc
> >>
> >> arrase:
> >>> 2016-11-21 0:25 GMT+01:00 Nathan of Guardian <
> >> nat...@guardianproject.info>:
> >>>
> 
>  We only need Internet permission, so haven't had to deal with the new
>  permission request framework.
> 
>  Why do we need a backup feature? I thought the approach was for apps to
>  manage their keys themselves, at least advanced apps?
> 
> >>>
> >>> By example, if you have ssh running at your device and you want to
> >> maintain
> >>> the same .onion in a device migration.
> >>>
> >>> You can manually create and restore an .onion backup from one device to
> >>> another.
> >>>
>  Even so, couldn't we offer backup without needing external storage
>  permissions?
> 
> >>>
> >>>  With the ability to be exported to another device writing a zip in the
> >>> external store is the simplest I think.
> >>>
> >>>
>  I bring this up because I know our users are very sensitive to this, and
>  the external storage permission is one that often sets off concern since
>  you are giving access to full media.
> 
> >>>
> >>> Well, is true but with runtime permissions the user is asked only when is
> >>> going to perform an action who actually needs them, so you can assume
> >> than
> >>> there is no panic if the app ask for those permissions.
> >>>
> >>> Also, the permissions were already there before I started to make
> >> changes,
> >>> so we understand that all those users who have an older version of
> >> android
> >>> have to accept them when installing the application from the store and
> >> does
> >>> not seem to have been a Problem for Orbot to date.
> >>>
> >>> On the other hand, it seems that they are not used in the application, if
> >>> they are not used, why are they there? And if they are used, the parts of
> >>> the code that use them are not working in the latest versions of android
> >>> since there is no code that manages them.
> >>>
> >>> That needs a review.
> >>>
> >>>
>  Thanks for the hard work on this, and I will definitely take a look at
>  the UI issues.
> 
> >>>
> >>> To you.
> >>>
> >>
> >> --
> >> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
> >> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
> >>
> > 
> 
> -- 
> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556


-- 
  Nathan of Guardian
  nat...@guardianproject.info
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[arrase]

And the services that a user configure manually? Why do you have to lose
them?

El 21 nov. 2016 2:00 p. m., "Hans-Christoph Steiner" <
h...@guardianproject.info> escribió:

>
> About the hidden service backups, that certainly would be a useful
> feature, but it should not be implemented in Orbot.  The requesting apps
> need to be entirely responsible for saving, managing and backing up that
> key.  Orbot will never be able to provide all of the various levels of
> security needed by different apps using Hidden Services.  For example,
> something like OnionShare might only have one-time-use Hidden Services
> that are thrown away after use.  Another app might have a long-lived
> hidden service that is too sensitive to be backed up via Google or other
> cloud services.
>
> .hc
>
> arrase:
> > 2016-11-21 0:25 GMT+01:00 Nathan of Guardian <
> nat...@guardianproject.info>:
> >
> >>
> >> We only need Internet permission, so haven't had to deal with the new
> >> permission request framework.
> >>
> >> Why do we need a backup feature? I thought the approach was for apps to
> >> manage their keys themselves, at least advanced apps?
> >>
> >
> > By example, if you have ssh running at your device and you want to
> maintain
> > the same .onion in a device migration.
> >
> > You can manually create and restore an .onion backup from one device to
> > another.
> >
> >> Even so, couldn't we offer backup without needing external storage
> >> permissions?
> >>
> >
> >  With the ability to be exported to another device writing a zip in the
> > external store is the simplest I think.
> >
> >
> >> I bring this up because I know our users are very sensitive to this, and
> >> the external storage permission is one that often sets off concern since
> >> you are giving access to full media.
> >>
> >
> > Well, is true but with runtime permissions the user is asked only when is
> > going to perform an action who actually needs them, so you can assume
> than
> > there is no panic if the app ask for those permissions.
> >
> > Also, the permissions were already there before I started to make
> changes,
> > so we understand that all those users who have an older version of
> android
> > have to accept them when installing the application from the store and
> does
> > not seem to have been a Problem for Orbot to date.
> >
> > On the other hand, it seems that they are not used in the application, if
> > they are not used, why are they there? And if they are used, the parts of
> > the code that use them are not working in the latest versions of android
> > since there is no code that manages them.
> >
> > That needs a review.
> >
> >
> >> Thanks for the hard work on this, and I will definitely take a look at
> >> the UI issues.
> >>
> >
> > To you.
> >
>
> --
> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[arrase]

2016-11-21 0:25 GMT+01:00 Nathan of Guardian :

>
> We only need Internet permission, so haven't had to deal with the new
> permission request framework.
>
> Why do we need a backup feature? I thought the approach was for apps to
> manage their keys themselves, at least advanced apps?
>

By example, if you have ssh running at your device and you want to maintain
the same .onion in a device migration.

You can manually create and restore an .onion backup from one device to
another.

Even so, couldn't we offer backup without needing external storage
> permissions?
>

 With the ability to be exported to another device writing a zip in the
external store is the simplest I think.


> I bring this up because I know our users are very sensitive to this, and
> the external storage permission is one that often sets off concern since
> you are giving access to full media.
>

Well, is true but with runtime permissions the user is asked only when is
going to perform an action who actually needs them, so you can assume than
there is no panic if the app ask for those permissions.

Also, the permissions were already there before I started to make changes,
so we understand that all those users who have an older version of android
have to accept them when installing the application from the store and does
not seem to have been a Problem for Orbot to date.

On the other hand, it seems that they are not used in the application, if
they are not used, why are they there? And if they are used, the parts of
the code that use them are not working in the latest versions of android
since there is no code that manages them.

That needs a review.


> Thanks for the hard work on this, and I will definitely take a look at
> the UI issues.
>

To you.
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[arrase]

Ok, permissions are working, and the backup creation feature works nice.

There is only one thing to do, a way for a restore the backup.

But there is a problem, i'm very bad building layotus, i mean, my layouts
are always ugly as hell.

So, if someone can build Orbot from the new brach and take a look to the
job for suggest a better look for the layouts the help will be appreciated.

Here is the branch at github:

https://github.com/arrase/orbot/tree/hidden_services

The list item is ugly as hell, the icon and color of the fab is ugly and i
don't know where to put the button for load a backup zip, maybe
longclicking the fabbad idea i think.

2016-11-20 16:17 GMT+01:00 arrase :

> I'm confused about Orbot permission management.
>
> Orbot needs several permission like WRITE_EXTERNAL_STORAGE but there is no
> code related to the new runtime permissions api.
>
> When i try to do a backup to the external storage it fails because i need
> to request permissions but...
>
> How have permissions worked until today? i have to implement the request
> to the new api in OrbotMainActivity if Build.VERSION.SDK_INT>Build.
> VERSION_CODES.LOLLIPOP_MR1???
>
>
>
>
> 2016-11-17 23:36 GMT+01:00 arrase :
>
>> Then you can implement TOFU in a simpler way and with backwards
>> compatibility, nice, I will implement it
>>
>> El 17 nov. 2016 11:31 p. m., "Hans-Christoph Steiner" <
>> h...@guardianproject.info> escribió:
>>
>>>
>>> The idea is to do Trust-On-First-Use (TOFU) with TrustedIntents, not to
>>> use the pin.  Basically, use the same technique to verify the
>>> packagename and signing key are trusted, but store the values on the
>>> first use, rather than have it built into the app.  I forget off the top
>>> of my head whether that is fully implemented in TrustedIntents, but if
>>> not, it shouldn't be hard to do.
>>>
>>> .hc
>>>
>>> arrase:
>>> > I have read about TrustedIntents, as a concept is good but if as
>>> > Hans-Christoph said to make the user have to do too many interactions
>>> is
>>> > not good, and implementing TrustedIntents in its current state
>>> requires the
>>> > user to use an application (Checkey) To get the pin.
>>> >
>>> > Too much work for the user.
>>> >
>>> > I will do something that is simpler, provide sufficient security and
>>> > backwards compatible.
>>> >
>>> > thinking in progress.
>>> >
>>> > 2016-11-17 22:06 GMT+01:00 Hans-Christoph Steiner <
>>> h...@guardianproject.info
>>> >> :
>>> >
>>> >>
>>> >> Updating to the new style makes sense.  I don't know the current
>>> hidden
>>> >> API though.
>>> >>
>>> >> .hc
>>> >>
>>> >> arrase:
>>> >>> Ummm  when you update an application from the store, you delete a
>>> >>> preference  although the value is not going to be accessed has
>>> not
>>> >> been
>>> >>> erased, right?
>>> >>>
>>> >>> Can we do a routine that after updating look for the configuration
>>> of the
>>> >>> old preferences and convert them to the new ones?
>>> >>>
>>> >>> makes sense?
>>> >>>
>>> >>> 2016-11-17 21:23 GMT+01:00 arrase :
>>> >>>
>>>  No, old ones do not runmust be requested again from the app, i
>>>  complete rewrite the settings , i can't find a way to maintain the
>>> old
>>> >> one
>>>  preference setup and the new one screen, has no sense if is put all
>>>  together.
>>> 
>>>  A cursor content provider has more sense for store a big amount of
>>> >> domains
>>>  and with a view adapter is more easy to manage for the user.
>>> 
>>>  El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" <
>>>  nat...@guardianproject.info> escribió:
>>> 
>>> > Hmm, I may be okay with breaking backward compatibility. I don't
>>> think
>>> > there are that many apps using the existing intent, and it would
>>> only
>>> >> be
>>> > a problem from them to request a new intent (i.e. existing
>>> configured
>>> > onion services would still work, right?)
>>> >
>>> > On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:
>>> >> I have only done a quick read but ... this breaks backward
>>> > compatibility,
>>> >> is it correct? I have no problem with that, but if we break the
>>> >> compatibility I'm going to change the Intent to accept a list of
>>> ports
>>> >> instead of just one
>>> >>
>>> >> El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
>>> >> h...@guardianproject.info> escribió:
>>> >>>
>>> >>>
>>> >>> Yes.  Check out our TrustedIntents library for some methods.
>>> Also,
>>> > this
>>> >>> project has some other methods for validating Intents received
>>> by a
>>> >> Service:
>>> >>>
>>> >>> https://gitlab.com/fdroid/privileged-extension/
>>> >>>
>>> >>> .hc
>>> >>>
>>> >>> arrase:
>>>  Is it possible to know which app has sent an Intent service?
>>> I'll
>>>  investigate
>>> 
>>>  It seems to me a good method if it is possible 

Re: [guardian-dev] Hi, i' new

[arrase]

I'm confused about Orbot permission management.

Orbot needs several permission like WRITE_EXTERNAL_STORAGE but there is no
code related to the new runtime permissions api.

When i try to do a backup to the external storage it fails because i need
to request permissions but...

How have permissions worked until today? i have to implement the request to
the new api in OrbotMainActivity if
Build.VERSION.SDK_INT>Build.VERSION_CODES.LOLLIPOP_MR1???




2016-11-17 23:36 GMT+01:00 arrase :

> Then you can implement TOFU in a simpler way and with backwards
> compatibility, nice, I will implement it
>
> El 17 nov. 2016 11:31 p. m., "Hans-Christoph Steiner" <
> h...@guardianproject.info> escribió:
>
>>
>> The idea is to do Trust-On-First-Use (TOFU) with TrustedIntents, not to
>> use the pin.  Basically, use the same technique to verify the
>> packagename and signing key are trusted, but store the values on the
>> first use, rather than have it built into the app.  I forget off the top
>> of my head whether that is fully implemented in TrustedIntents, but if
>> not, it shouldn't be hard to do.
>>
>> .hc
>>
>> arrase:
>> > I have read about TrustedIntents, as a concept is good but if as
>> > Hans-Christoph said to make the user have to do too many interactions is
>> > not good, and implementing TrustedIntents in its current state requires
>> the
>> > user to use an application (Checkey) To get the pin.
>> >
>> > Too much work for the user.
>> >
>> > I will do something that is simpler, provide sufficient security and
>> > backwards compatible.
>> >
>> > thinking in progress.
>> >
>> > 2016-11-17 22:06 GMT+01:00 Hans-Christoph Steiner <
>> h...@guardianproject.info
>> >> :
>> >
>> >>
>> >> Updating to the new style makes sense.  I don't know the current hidden
>> >> API though.
>> >>
>> >> .hc
>> >>
>> >> arrase:
>> >>> Ummm  when you update an application from the store, you delete a
>> >>> preference  although the value is not going to be accessed has not
>> >> been
>> >>> erased, right?
>> >>>
>> >>> Can we do a routine that after updating look for the configuration of
>> the
>> >>> old preferences and convert them to the new ones?
>> >>>
>> >>> makes sense?
>> >>>
>> >>> 2016-11-17 21:23 GMT+01:00 arrase :
>> >>>
>>  No, old ones do not runmust be requested again from the app, i
>>  complete rewrite the settings , i can't find a way to maintain the
>> old
>> >> one
>>  preference setup and the new one screen, has no sense if is put all
>>  together.
>> 
>>  A cursor content provider has more sense for store a big amount of
>> >> domains
>>  and with a view adapter is more easy to manage for the user.
>> 
>>  El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" <
>>  nat...@guardianproject.info> escribió:
>> 
>> > Hmm, I may be okay with breaking backward compatibility. I don't
>> think
>> > there are that many apps using the existing intent, and it would
>> only
>> >> be
>> > a problem from them to request a new intent (i.e. existing
>> configured
>> > onion services would still work, right?)
>> >
>> > On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:
>> >> I have only done a quick read but ... this breaks backward
>> > compatibility,
>> >> is it correct? I have no problem with that, but if we break the
>> >> compatibility I'm going to change the Intent to accept a list of
>> ports
>> >> instead of just one
>> >>
>> >> El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
>> >> h...@guardianproject.info> escribió:
>> >>>
>> >>>
>> >>> Yes.  Check out our TrustedIntents library for some methods.
>> Also,
>> > this
>> >>> project has some other methods for validating Intents received by
>> a
>> >> Service:
>> >>>
>> >>> https://gitlab.com/fdroid/privileged-extension/
>> >>>
>> >>> .hc
>> >>>
>> >>> arrase:
>>  Is it possible to know which app has sent an Intent service? I'll
>>  investigate
>> 
>>  It seems to me a good method if it is possible to implement it
>> > without
>>  having to ask the app to identify itself.
>> 
>>  2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <
>> >> h...@guardianproject.info
>> > :
>> 
>> >
>> > I think adding any kind of user interaction is too much
>> complexity.
>> > This needs to be entirely transparent to the user, at least to
>> > start
>> > with.  Orbot has no saved state beyond the basic config stuff
>> (e.g.
>> > using VPN mode, allowing background starts, etc).  So its
>> entirely
>> > up
>> >> to
>> > the app to save the Hidden Service key.
>> >
>> > If an app sends Orbot a private key, it will remember which app
>> > sent
>> >> it,
>> > and only allow that exact app to do anything with it.  An app
>> can

Re: [guardian-dev] Hi, i' new

[arrase]

Then you can implement TOFU in a simpler way and with backwards
compatibility, nice, I will implement it

El 17 nov. 2016 11:31 p. m., "Hans-Christoph Steiner" <
h...@guardianproject.info> escribió:

>
> The idea is to do Trust-On-First-Use (TOFU) with TrustedIntents, not to
> use the pin.  Basically, use the same technique to verify the
> packagename and signing key are trusted, but store the values on the
> first use, rather than have it built into the app.  I forget off the top
> of my head whether that is fully implemented in TrustedIntents, but if
> not, it shouldn't be hard to do.
>
> .hc
>
> arrase:
> > I have read about TrustedIntents, as a concept is good but if as
> > Hans-Christoph said to make the user have to do too many interactions is
> > not good, and implementing TrustedIntents in its current state requires
> the
> > user to use an application (Checkey) To get the pin.
> >
> > Too much work for the user.
> >
> > I will do something that is simpler, provide sufficient security and
> > backwards compatible.
> >
> > thinking in progress.
> >
> > 2016-11-17 22:06 GMT+01:00 Hans-Christoph Steiner <
> h...@guardianproject.info
> >> :
> >
> >>
> >> Updating to the new style makes sense.  I don't know the current hidden
> >> API though.
> >>
> >> .hc
> >>
> >> arrase:
> >>> Ummm  when you update an application from the store, you delete a
> >>> preference  although the value is not going to be accessed has not
> >> been
> >>> erased, right?
> >>>
> >>> Can we do a routine that after updating look for the configuration of
> the
> >>> old preferences and convert them to the new ones?
> >>>
> >>> makes sense?
> >>>
> >>> 2016-11-17 21:23 GMT+01:00 arrase :
> >>>
>  No, old ones do not runmust be requested again from the app, i
>  complete rewrite the settings , i can't find a way to maintain the old
> >> one
>  preference setup and the new one screen, has no sense if is put all
>  together.
> 
>  A cursor content provider has more sense for store a big amount of
> >> domains
>  and with a view adapter is more easy to manage for the user.
> 
>  El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" <
>  nat...@guardianproject.info> escribió:
> 
> > Hmm, I may be okay with breaking backward compatibility. I don't
> think
> > there are that many apps using the existing intent, and it would only
> >> be
> > a problem from them to request a new intent (i.e. existing configured
> > onion services would still work, right?)
> >
> > On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:
> >> I have only done a quick read but ... this breaks backward
> > compatibility,
> >> is it correct? I have no problem with that, but if we break the
> >> compatibility I'm going to change the Intent to accept a list of
> ports
> >> instead of just one
> >>
> >> El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
> >> h...@guardianproject.info> escribió:
> >>>
> >>>
> >>> Yes.  Check out our TrustedIntents library for some methods.  Also,
> > this
> >>> project has some other methods for validating Intents received by a
> >> Service:
> >>>
> >>> https://gitlab.com/fdroid/privileged-extension/
> >>>
> >>> .hc
> >>>
> >>> arrase:
>  Is it possible to know which app has sent an Intent service? I'll
>  investigate
> 
>  It seems to me a good method if it is possible to implement it
> > without
>  having to ask the app to identify itself.
> 
>  2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <
> >> h...@guardianproject.info
> > :
> 
> >
> > I think adding any kind of user interaction is too much
> complexity.
> > This needs to be entirely transparent to the user, at least to
> > start
> > with.  Orbot has no saved state beyond the basic config stuff
> (e.g.
> > using VPN mode, allowing background starts, etc).  So its
> entirely
> > up
> >> to
> > the app to save the Hidden Service key.
> >
> > If an app sends Orbot a private key, it will remember which app
> > sent
> >> it,
> > and only allow that exact app to do anything with it.  An app can
> > pass
> > around that private key as it wants to.
> >
> > If Orbot generates the private key, then Orbot will send that
> back
> > to
> > the requesting app, and allow only that app to access it.
> >
> > .hc
> >
> > arrase:
> >> Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_
> > SERVICE),
> >> I've
> >> extended it to maintain backward compatibility.
> >>
> >> I'm going to add another Intent to manage the small security
> layer
> >> that
> > I'm
> >> adding when exporting the key of a service for its 

Re: [guardian-dev] Hi, i' new

[arrase]

I have read about TrustedIntents, as a concept is good but if as
Hans-Christoph said to make the user have to do too many interactions is
not good, and implementing TrustedIntents in its current state requires the
user to use an application (Checkey) To get the pin.

Too much work for the user.

I will do something that is simpler, provide sufficient security and
backwards compatible.

thinking in progress.

2016-11-17 22:06 GMT+01:00 Hans-Christoph Steiner :

>
> Updating to the new style makes sense.  I don't know the current hidden
> API though.
>
> .hc
>
> arrase:
> > Ummm  when you update an application from the store, you delete a
> > preference  although the value is not going to be accessed has not
> been
> > erased, right?
> >
> > Can we do a routine that after updating look for the configuration of the
> > old preferences and convert them to the new ones?
> >
> > makes sense?
> >
> > 2016-11-17 21:23 GMT+01:00 arrase :
> >
> >> No, old ones do not runmust be requested again from the app, i
> >> complete rewrite the settings , i can't find a way to maintain the old
> one
> >> preference setup and the new one screen, has no sense if is put all
> >> together.
> >>
> >> A cursor content provider has more sense for store a big amount of
> domains
> >> and with a view adapter is more easy to manage for the user.
> >>
> >> El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" <
> >> nat...@guardianproject.info> escribió:
> >>
> >>> Hmm, I may be okay with breaking backward compatibility. I don't think
> >>> there are that many apps using the existing intent, and it would only
> be
> >>> a problem from them to request a new intent (i.e. existing configured
> >>> onion services would still work, right?)
> >>>
> >>> On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:
>  I have only done a quick read but ... this breaks backward
> >>> compatibility,
>  is it correct? I have no problem with that, but if we break the
>  compatibility I'm going to change the Intent to accept a list of ports
>  instead of just one
> 
>  El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
>  h...@guardianproject.info> escribió:
> >
> >
> > Yes.  Check out our TrustedIntents library for some methods.  Also,
> >>> this
> > project has some other methods for validating Intents received by a
>  Service:
> >
> > https://gitlab.com/fdroid/privileged-extension/
> >
> > .hc
> >
> > arrase:
> >> Is it possible to know which app has sent an Intent service? I'll
> >> investigate
> >>
> >> It seems to me a good method if it is possible to implement it
> >>> without
> >> having to ask the app to identify itself.
> >>
> >> 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <
>  h...@guardianproject.info
> >>> :
> >>
> >>>
> >>> I think adding any kind of user interaction is too much complexity.
> >>> This needs to be entirely transparent to the user, at least to
> >>> start
> >>> with.  Orbot has no saved state beyond the basic config stuff (e.g.
> >>> using VPN mode, allowing background starts, etc).  So its entirely
> >>> up
>  to
> >>> the app to save the Hidden Service key.
> >>>
> >>> If an app sends Orbot a private key, it will remember which app
> >>> sent
>  it,
> >>> and only allow that exact app to do anything with it.  An app can
> >>> pass
> >>> around that private key as it wants to.
> >>>
> >>> If Orbot generates the private key, then Orbot will send that back
> >>> to
> >>> the requesting app, and allow only that app to access it.
> >>>
> >>> .hc
> >>>
> >>> arrase:
>  Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_
> >>> SERVICE),
>  I've
>  extended it to maintain backward compatibility.
> 
>  I'm going to add another Intent to manage the small security layer
>  that
> >>> I'm
>  adding when exporting the key of a service for its backup.
>  Once the permission for export the key is denied, only the user
> >>> can
>  re-grant it from the main application.
> 
>  The major picture is done, now i'm adding:
> 
>  - A way for import/export the configuration of a hidden service
> >>> in zip
>  fromat (UI and Intent service versions)
>  - A way for delete a hidden service (UI and Intent service
> >>> versions)
>  - Intent for disallowing backup of the service.
> 
>  2016-11-17 15:47 GMT+01:00 Nathan of Guardian <
> >>> nat...@guardianproject.info>:
> 
> > As Arrase point out though, there is an undocumented intent.
> >>> This is
> > what we use for CameraV currently. I think making it official,
>  expanding
> > it, and adding it into NetCipher makes a great deal of sense.
> >
> > On 

Re: [guardian-dev] Hi, i' new

[arrase]

this should fix the issue

private void migratePreferences(){
   String hsPortString = mPrefs.getString("pref_hs_ports", "");
   if(hsPortString.length() > 0)
   {
  StringTokenizer st = new StringTokenizer (hsPortString,",");
  ContentResolver cr = getContentResolver();
  while (st.hasMoreTokens())
  {
 int hsPort = Integer.parseInt(st.nextToken().split(" ")[0]);
 ContentValues fields = new ContentValues();
 fields.put("name", hsPort);
 fields.put("port", hsPort);
 fields.put("onion_port", hsPort);
 cr.insert(HSContentProvider.CONTENT_URI, fields);
  }

  Editor pEdit = mPrefs.edit();
  pEdit.remove("pref_hs_ports");
  pEdit.commit();
   }
}



2016-11-17 21:28 GMT+01:00 arrase :

> Ummm  when you update an application from the store, you delete a
> preference  although the value is not going to be accessed has not been
> erased, right?
>
> Can we do a routine that after updating look for the configuration of the
> old preferences and convert them to the new ones?
>
> makes sense?
>
> 2016-11-17 21:23 GMT+01:00 arrase :
>
>> No, old ones do not runmust be requested again from the app, i
>> complete rewrite the settings , i can't find a way to maintain the old one
>> preference setup and the new one screen, has no sense if is put all
>> together.
>>
>> A cursor content provider has more sense for store a big amount of
>> domains and with a view adapter is more easy to manage for the user.
>>
>> El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" <
>> nat...@guardianproject.info> escribió:
>>
>>> Hmm, I may be okay with breaking backward compatibility. I don't think
>>> there are that many apps using the existing intent, and it would only be
>>> a problem from them to request a new intent (i.e. existing configured
>>> onion services would still work, right?)
>>>
>>> On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:
>>> > I have only done a quick read but ... this breaks backward
>>> compatibility,
>>> > is it correct? I have no problem with that, but if we break the
>>> > compatibility I'm going to change the Intent to accept a list of ports
>>> > instead of just one
>>> >
>>> > El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
>>> > h...@guardianproject.info> escribió:
>>> > >
>>> > >
>>> > > Yes.  Check out our TrustedIntents library for some methods.  Also,
>>> this
>>> > > project has some other methods for validating Intents received by a
>>> > Service:
>>> > >
>>> > > https://gitlab.com/fdroid/privileged-extension/
>>> > >
>>> > > .hc
>>> > >
>>> > > arrase:
>>> > > > Is it possible to know which app has sent an Intent service? I'll
>>> > > > investigate
>>> > > >
>>> > > > It seems to me a good method if it is possible to implement it
>>> without
>>> > > > having to ask the app to identify itself.
>>> > > >
>>> > > > 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <
>>> > h...@guardianproject.info
>>> > > >> :
>>> > > >
>>> > > >>
>>> > > >> I think adding any kind of user interaction is too much
>>> complexity.
>>> > > >> This needs to be entirely transparent to the user, at least to
>>> start
>>> > > >> with.  Orbot has no saved state beyond the basic config stuff
>>> (e.g.
>>> > > >> using VPN mode, allowing background starts, etc).  So its
>>> entirely up
>>> > to
>>> > > >> the app to save the Hidden Service key.
>>> > > >>
>>> > > >> If an app sends Orbot a private key, it will remember which app
>>> sent
>>> > it,
>>> > > >> and only allow that exact app to do anything with it.  An app can
>>> pass
>>> > > >> around that private key as it wants to.
>>> > > >>
>>> > > >> If Orbot generates the private key, then Orbot will send that
>>> back to
>>> > > >> the requesting app, and allow only that app to access it.
>>> > > >>
>>> > > >> .hc
>>> > > >>
>>> > > >> arrase:
>>> > > >>> Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_
>>> SERVICE),
>>> > I've
>>> > > >>> extended it to maintain backward compatibility.
>>> > > >>>
>>> > > >>> I'm going to add another Intent to manage the small security
>>> layer
>>> > that
>>> > > >> I'm
>>> > > >>> adding when exporting the key of a service for its backup.
>>> > > >>> Once the permission for export the key is denied, only the user
>>> can
>>> > > >>> re-grant it from the main application.
>>> > > >>>
>>> > > >>> The major picture is done, now i'm adding:
>>> > > >>>
>>> > > >>> - A way for import/export the configuration of a hidden service
>>> in zip
>>> > > >>> fromat (UI and Intent service versions)
>>> > > >>> - A way for delete a hidden service (UI and Intent service
>>> versions)
>>> > > >>> - Intent for disallowing backup of the service.
>>> > > >>>
>>> > > >>> 2016-11-17 15:47 GMT+01:00 Nathan of Guardian <
>>> > > >> nat...@guardianproject.info>:
>>> > > >>>
>>> > >  As Arrase point out though, there is an undocumented intent.
>>> This is
>>> > >  what we use for CameraV currently. I think making 

Re: [guardian-dev] Hi, i' new

[Hans-Christoph Steiner]

Updating to the new style makes sense.  I don't know the current hidden
API though.

.hc

arrase:
> Ummm  when you update an application from the store, you delete a
> preference  although the value is not going to be accessed has not been
> erased, right?
> 
> Can we do a routine that after updating look for the configuration of the
> old preferences and convert them to the new ones?
> 
> makes sense?
> 
> 2016-11-17 21:23 GMT+01:00 arrase :
> 
>> No, old ones do not runmust be requested again from the app, i
>> complete rewrite the settings , i can't find a way to maintain the old one
>> preference setup and the new one screen, has no sense if is put all
>> together.
>>
>> A cursor content provider has more sense for store a big amount of domains
>> and with a view adapter is more easy to manage for the user.
>>
>> El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" <
>> nat...@guardianproject.info> escribió:
>>
>>> Hmm, I may be okay with breaking backward compatibility. I don't think
>>> there are that many apps using the existing intent, and it would only be
>>> a problem from them to request a new intent (i.e. existing configured
>>> onion services would still work, right?)
>>>
>>> On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:
 I have only done a quick read but ... this breaks backward
>>> compatibility,
 is it correct? I have no problem with that, but if we break the
 compatibility I'm going to change the Intent to accept a list of ports
 instead of just one

 El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
 h...@guardianproject.info> escribió:
>
>
> Yes.  Check out our TrustedIntents library for some methods.  Also,
>>> this
> project has some other methods for validating Intents received by a
 Service:
>
> https://gitlab.com/fdroid/privileged-extension/
>
> .hc
>
> arrase:
>> Is it possible to know which app has sent an Intent service? I'll
>> investigate
>>
>> It seems to me a good method if it is possible to implement it
>>> without
>> having to ask the app to identify itself.
>>
>> 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <
 h...@guardianproject.info
>>> :
>>
>>>
>>> I think adding any kind of user interaction is too much complexity.
>>> This needs to be entirely transparent to the user, at least to
>>> start
>>> with.  Orbot has no saved state beyond the basic config stuff (e.g.
>>> using VPN mode, allowing background starts, etc).  So its entirely
>>> up
 to
>>> the app to save the Hidden Service key.
>>>
>>> If an app sends Orbot a private key, it will remember which app
>>> sent
 it,
>>> and only allow that exact app to do anything with it.  An app can
>>> pass
>>> around that private key as it wants to.
>>>
>>> If Orbot generates the private key, then Orbot will send that back
>>> to
>>> the requesting app, and allow only that app to access it.
>>>
>>> .hc
>>>
>>> arrase:
 Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_
>>> SERVICE),
 I've
 extended it to maintain backward compatibility.

 I'm going to add another Intent to manage the small security layer
 that
>>> I'm
 adding when exporting the key of a service for its backup.
 Once the permission for export the key is denied, only the user
>>> can
 re-grant it from the main application.

 The major picture is done, now i'm adding:

 - A way for import/export the configuration of a hidden service
>>> in zip
 fromat (UI and Intent service versions)
 - A way for delete a hidden service (UI and Intent service
>>> versions)
 - Intent for disallowing backup of the service.

 2016-11-17 15:47 GMT+01:00 Nathan of Guardian <
>>> nat...@guardianproject.info>:

> As Arrase point out though, there is an undocumented intent.
>>> This is
> what we use for CameraV currently. I think making it official,
 expanding
> it, and adding it into NetCipher makes a great deal of sense.
>
> On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote:
>>
>> The documentation is mostly in the form of javadoc strings in
>>> the
>> NetCipher library, since that's the usual developer interface to
 this
>> stuff.  Otherwise, there is a little bit here:
>>
>> https://guardianproject.info/code
>>
>> There isn't yet any official way to request a Hidden Service as
>>> of
 now.
>>
>> .hc
>>
>> arrase:
>>> After reviewing the code and learned how to make the changes I
 think
> I'll
>>> take this a little further.
>>>
>>> Keeping the backwards compatibility I will rewrite the
 

Re: [guardian-dev] Hi, i' new

[arrase]

Ummm  when you update an application from the store, you delete a
preference  although the value is not going to be accessed has not been
erased, right?

Can we do a routine that after updating look for the configuration of the
old preferences and convert them to the new ones?

makes sense?

2016-11-17 21:23 GMT+01:00 arrase :

> No, old ones do not runmust be requested again from the app, i
> complete rewrite the settings , i can't find a way to maintain the old one
> preference setup and the new one screen, has no sense if is put all
> together.
>
> A cursor content provider has more sense for store a big amount of domains
> and with a view adapter is more easy to manage for the user.
>
> El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" <
> nat...@guardianproject.info> escribió:
>
>> Hmm, I may be okay with breaking backward compatibility. I don't think
>> there are that many apps using the existing intent, and it would only be
>> a problem from them to request a new intent (i.e. existing configured
>> onion services would still work, right?)
>>
>> On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:
>> > I have only done a quick read but ... this breaks backward
>> compatibility,
>> > is it correct? I have no problem with that, but if we break the
>> > compatibility I'm going to change the Intent to accept a list of ports
>> > instead of just one
>> >
>> > El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
>> > h...@guardianproject.info> escribió:
>> > >
>> > >
>> > > Yes.  Check out our TrustedIntents library for some methods.  Also,
>> this
>> > > project has some other methods for validating Intents received by a
>> > Service:
>> > >
>> > > https://gitlab.com/fdroid/privileged-extension/
>> > >
>> > > .hc
>> > >
>> > > arrase:
>> > > > Is it possible to know which app has sent an Intent service? I'll
>> > > > investigate
>> > > >
>> > > > It seems to me a good method if it is possible to implement it
>> without
>> > > > having to ask the app to identify itself.
>> > > >
>> > > > 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <
>> > h...@guardianproject.info
>> > > >> :
>> > > >
>> > > >>
>> > > >> I think adding any kind of user interaction is too much complexity.
>> > > >> This needs to be entirely transparent to the user, at least to
>> start
>> > > >> with.  Orbot has no saved state beyond the basic config stuff (e.g.
>> > > >> using VPN mode, allowing background starts, etc).  So its entirely
>> up
>> > to
>> > > >> the app to save the Hidden Service key.
>> > > >>
>> > > >> If an app sends Orbot a private key, it will remember which app
>> sent
>> > it,
>> > > >> and only allow that exact app to do anything with it.  An app can
>> pass
>> > > >> around that private key as it wants to.
>> > > >>
>> > > >> If Orbot generates the private key, then Orbot will send that back
>> to
>> > > >> the requesting app, and allow only that app to access it.
>> > > >>
>> > > >> .hc
>> > > >>
>> > > >> arrase:
>> > > >>> Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_
>> SERVICE),
>> > I've
>> > > >>> extended it to maintain backward compatibility.
>> > > >>>
>> > > >>> I'm going to add another Intent to manage the small security layer
>> > that
>> > > >> I'm
>> > > >>> adding when exporting the key of a service for its backup.
>> > > >>> Once the permission for export the key is denied, only the user
>> can
>> > > >>> re-grant it from the main application.
>> > > >>>
>> > > >>> The major picture is done, now i'm adding:
>> > > >>>
>> > > >>> - A way for import/export the configuration of a hidden service
>> in zip
>> > > >>> fromat (UI and Intent service versions)
>> > > >>> - A way for delete a hidden service (UI and Intent service
>> versions)
>> > > >>> - Intent for disallowing backup of the service.
>> > > >>>
>> > > >>> 2016-11-17 15:47 GMT+01:00 Nathan of Guardian <
>> > > >> nat...@guardianproject.info>:
>> > > >>>
>> > >  As Arrase point out though, there is an undocumented intent.
>> This is
>> > >  what we use for CameraV currently. I think making it official,
>> > expanding
>> > >  it, and adding it into NetCipher makes a great deal of sense.
>> > > 
>> > >  On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote:
>> > > >
>> > > > The documentation is mostly in the form of javadoc strings in
>> the
>> > > > NetCipher library, since that's the usual developer interface to
>> > this
>> > > > stuff.  Otherwise, there is a little bit here:
>> > > >
>> > > > https://guardianproject.info/code
>> > > >
>> > > > There isn't yet any official way to request a Hidden Service as
>> of
>> > now.
>> > > >
>> > > > .hc
>> > > >
>> > > > arrase:
>> > > >> After reviewing the code and learned how to make the changes I
>> > think
>> > >  I'll
>> > > >> take this a little further.
>> > > >>
>> > > >> Keeping the backwards compatibility I will rewrite the
>> > configuration
>> > > 

Re: [guardian-dev] Hi, i' new

[arrase]

No, old ones do not runmust be requested again from the app, i complete
rewrite the settings , i can't find a way to maintain the old one
preference setup and the new one screen, has no sense if is put all
together.

A cursor content provider has more sense for store a big amount of domains
and with a view adapter is more easy to manage for the user.

El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" <
nat...@guardianproject.info> escribió:

> Hmm, I may be okay with breaking backward compatibility. I don't think
> there are that many apps using the existing intent, and it would only be
> a problem from them to request a new intent (i.e. existing configured
> onion services would still work, right?)
>
> On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:
> > I have only done a quick read but ... this breaks backward compatibility,
> > is it correct? I have no problem with that, but if we break the
> > compatibility I'm going to change the Intent to accept a list of ports
> > instead of just one
> >
> > El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
> > h...@guardianproject.info> escribió:
> > >
> > >
> > > Yes.  Check out our TrustedIntents library for some methods.  Also,
> this
> > > project has some other methods for validating Intents received by a
> > Service:
> > >
> > > https://gitlab.com/fdroid/privileged-extension/
> > >
> > > .hc
> > >
> > > arrase:
> > > > Is it possible to know which app has sent an Intent service? I'll
> > > > investigate
> > > >
> > > > It seems to me a good method if it is possible to implement it
> without
> > > > having to ask the app to identify itself.
> > > >
> > > > 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <
> > h...@guardianproject.info
> > > >> :
> > > >
> > > >>
> > > >> I think adding any kind of user interaction is too much complexity.
> > > >> This needs to be entirely transparent to the user, at least to start
> > > >> with.  Orbot has no saved state beyond the basic config stuff (e.g.
> > > >> using VPN mode, allowing background starts, etc).  So its entirely
> up
> > to
> > > >> the app to save the Hidden Service key.
> > > >>
> > > >> If an app sends Orbot a private key, it will remember which app sent
> > it,
> > > >> and only allow that exact app to do anything with it.  An app can
> pass
> > > >> around that private key as it wants to.
> > > >>
> > > >> If Orbot generates the private key, then Orbot will send that back
> to
> > > >> the requesting app, and allow only that app to access it.
> > > >>
> > > >> .hc
> > > >>
> > > >> arrase:
> > > >>> Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_
> SERVICE),
> > I've
> > > >>> extended it to maintain backward compatibility.
> > > >>>
> > > >>> I'm going to add another Intent to manage the small security layer
> > that
> > > >> I'm
> > > >>> adding when exporting the key of a service for its backup.
> > > >>> Once the permission for export the key is denied, only the user can
> > > >>> re-grant it from the main application.
> > > >>>
> > > >>> The major picture is done, now i'm adding:
> > > >>>
> > > >>> - A way for import/export the configuration of a hidden service in
> zip
> > > >>> fromat (UI and Intent service versions)
> > > >>> - A way for delete a hidden service (UI and Intent service
> versions)
> > > >>> - Intent for disallowing backup of the service.
> > > >>>
> > > >>> 2016-11-17 15:47 GMT+01:00 Nathan of Guardian <
> > > >> nat...@guardianproject.info>:
> > > >>>
> > >  As Arrase point out though, there is an undocumented intent. This
> is
> > >  what we use for CameraV currently. I think making it official,
> > expanding
> > >  it, and adding it into NetCipher makes a great deal of sense.
> > > 
> > >  On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote:
> > > >
> > > > The documentation is mostly in the form of javadoc strings in the
> > > > NetCipher library, since that's the usual developer interface to
> > this
> > > > stuff.  Otherwise, there is a little bit here:
> > > >
> > > > https://guardianproject.info/code
> > > >
> > > > There isn't yet any official way to request a Hidden Service as
> of
> > now.
> > > >
> > > > .hc
> > > >
> > > > arrase:
> > > >> After reviewing the code and learned how to make the changes I
> > think
> > >  I'll
> > > >> take this a little further.
> > > >>
> > > >> Keeping the backwards compatibility I will rewrite the
> > configuration
> > > >> preferences of the hidden services and an extension of the
> existing
> > >  Intent
> > > >> services.
> > > >>
> > > >> It's a big change that will take me a few days but I think it's
> the
> > >  right
> > > >> thing to do.
> > > >>
> > > >> Additionally I have not found a site where are documented the
> > >  integration
> > > >> options offered by Orbot, for example there is already the
> option
> > that
> > >  an
> > > >> application can 

Re: [guardian-dev] Hi, i' new

[Nathan of Guardian]

Hmm, I may be okay with breaking backward compatibility. I don't think
there are that many apps using the existing intent, and it would only be
a problem from them to request a new intent (i.e. existing configured
onion services would still work, right?)

On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:
> I have only done a quick read but ... this breaks backward compatibility,
> is it correct? I have no problem with that, but if we break the
> compatibility I'm going to change the Intent to accept a list of ports
> instead of just one
> 
> El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
> h...@guardianproject.info> escribió:
> >
> >
> > Yes.  Check out our TrustedIntents library for some methods.  Also, this
> > project has some other methods for validating Intents received by a
> Service:
> >
> > https://gitlab.com/fdroid/privileged-extension/
> >
> > .hc
> >
> > arrase:
> > > Is it possible to know which app has sent an Intent service? I'll
> > > investigate
> > >
> > > It seems to me a good method if it is possible to implement it without
> > > having to ask the app to identify itself.
> > >
> > > 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <
> h...@guardianproject.info
> > >> :
> > >
> > >>
> > >> I think adding any kind of user interaction is too much complexity.
> > >> This needs to be entirely transparent to the user, at least to start
> > >> with.  Orbot has no saved state beyond the basic config stuff (e.g.
> > >> using VPN mode, allowing background starts, etc).  So its entirely up
> to
> > >> the app to save the Hidden Service key.
> > >>
> > >> If an app sends Orbot a private key, it will remember which app sent
> it,
> > >> and only allow that exact app to do anything with it.  An app can pass
> > >> around that private key as it wants to.
> > >>
> > >> If Orbot generates the private key, then Orbot will send that back to
> > >> the requesting app, and allow only that app to access it.
> > >>
> > >> .hc
> > >>
> > >> arrase:
> > >>> Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_SERVICE),
> I've
> > >>> extended it to maintain backward compatibility.
> > >>>
> > >>> I'm going to add another Intent to manage the small security layer
> that
> > >> I'm
> > >>> adding when exporting the key of a service for its backup.
> > >>> Once the permission for export the key is denied, only the user can
> > >>> re-grant it from the main application.
> > >>>
> > >>> The major picture is done, now i'm adding:
> > >>>
> > >>> - A way for import/export the configuration of a hidden service in zip
> > >>> fromat (UI and Intent service versions)
> > >>> - A way for delete a hidden service (UI and Intent service versions)
> > >>> - Intent for disallowing backup of the service.
> > >>>
> > >>> 2016-11-17 15:47 GMT+01:00 Nathan of Guardian <
> > >> nat...@guardianproject.info>:
> > >>>
> >  As Arrase point out though, there is an undocumented intent. This is
> >  what we use for CameraV currently. I think making it official,
> expanding
> >  it, and adding it into NetCipher makes a great deal of sense.
> > 
> >  On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote:
> > >
> > > The documentation is mostly in the form of javadoc strings in the
> > > NetCipher library, since that's the usual developer interface to
> this
> > > stuff.  Otherwise, there is a little bit here:
> > >
> > > https://guardianproject.info/code
> > >
> > > There isn't yet any official way to request a Hidden Service as of
> now.
> > >
> > > .hc
> > >
> > > arrase:
> > >> After reviewing the code and learned how to make the changes I
> think
> >  I'll
> > >> take this a little further.
> > >>
> > >> Keeping the backwards compatibility I will rewrite the
> configuration
> > >> preferences of the hidden services and an extension of the existing
> >  Intent
> > >> services.
> > >>
> > >> It's a big change that will take me a few days but I think it's the
> >  right
> > >> thing to do.
> > >>
> > >> Additionally I have not found a site where are documented the
> >  integration
> > >> options offered by Orbot, for example there is already the option
> that
> >  an
> > >> application can register a new port hidden by an Intent but I have
> not
> > >> known until reading the code despite having searched Information on
> >  google.
> > >>
> > >> 2016-11-15 23:26 GMT+01:00 Nathan of Guardian <
> >  nat...@guardianproject.info>:
> > >>
> > >>> As I mentioned in the ticket, you need to run > ndk-build in the
> > >>> /orbotservice directory to create those native assets first.
> > >>>
> > >>> We are working on extracting the native binary build components
> into
> > >> a
> > >>> separate gradle dependency, to make working on the app itself,
> > >> easier.
> > >>> For now though, yes, you must build!
> > >>>
> > >>> On Tue, Nov 

Re: [guardian-dev] Hi, i' new

[arrase]

I have only done a quick read but ... this breaks backward compatibility,
is it correct? I have no problem with that, but if we break the
compatibility I'm going to change the Intent to accept a list of ports
instead of just one

El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
h...@guardianproject.info> escribió:
>
>
> Yes.  Check out our TrustedIntents library for some methods.  Also, this
> project has some other methods for validating Intents received by a
Service:
>
> https://gitlab.com/fdroid/privileged-extension/
>
> .hc
>
> arrase:
> > Is it possible to know which app has sent an Intent service? I'll
> > investigate
> >
> > It seems to me a good method if it is possible to implement it without
> > having to ask the app to identify itself.
> >
> > 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <
h...@guardianproject.info
> >> :
> >
> >>
> >> I think adding any kind of user interaction is too much complexity.
> >> This needs to be entirely transparent to the user, at least to start
> >> with.  Orbot has no saved state beyond the basic config stuff (e.g.
> >> using VPN mode, allowing background starts, etc).  So its entirely up
to
> >> the app to save the Hidden Service key.
> >>
> >> If an app sends Orbot a private key, it will remember which app sent
it,
> >> and only allow that exact app to do anything with it.  An app can pass
> >> around that private key as it wants to.
> >>
> >> If Orbot generates the private key, then Orbot will send that back to
> >> the requesting app, and allow only that app to access it.
> >>
> >> .hc
> >>
> >> arrase:
> >>> Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_SERVICE),
I've
> >>> extended it to maintain backward compatibility.
> >>>
> >>> I'm going to add another Intent to manage the small security layer
that
> >> I'm
> >>> adding when exporting the key of a service for its backup.
> >>> Once the permission for export the key is denied, only the user can
> >>> re-grant it from the main application.
> >>>
> >>> The major picture is done, now i'm adding:
> >>>
> >>> - A way for import/export the configuration of a hidden service in zip
> >>> fromat (UI and Intent service versions)
> >>> - A way for delete a hidden service (UI and Intent service versions)
> >>> - Intent for disallowing backup of the service.
> >>>
> >>> 2016-11-17 15:47 GMT+01:00 Nathan of Guardian <
> >> nat...@guardianproject.info>:
> >>>
>  As Arrase point out though, there is an undocumented intent. This is
>  what we use for CameraV currently. I think making it official,
expanding
>  it, and adding it into NetCipher makes a great deal of sense.
> 
>  On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote:
> >
> > The documentation is mostly in the form of javadoc strings in the
> > NetCipher library, since that's the usual developer interface to
this
> > stuff.  Otherwise, there is a little bit here:
> >
> > https://guardianproject.info/code
> >
> > There isn't yet any official way to request a Hidden Service as of
now.
> >
> > .hc
> >
> > arrase:
> >> After reviewing the code and learned how to make the changes I
think
>  I'll
> >> take this a little further.
> >>
> >> Keeping the backwards compatibility I will rewrite the
configuration
> >> preferences of the hidden services and an extension of the existing
>  Intent
> >> services.
> >>
> >> It's a big change that will take me a few days but I think it's the
>  right
> >> thing to do.
> >>
> >> Additionally I have not found a site where are documented the
>  integration
> >> options offered by Orbot, for example there is already the option
that
>  an
> >> application can register a new port hidden by an Intent but I have
not
> >> known until reading the code despite having searched Information on
>  google.
> >>
> >> 2016-11-15 23:26 GMT+01:00 Nathan of Guardian <
>  nat...@guardianproject.info>:
> >>
> >>> As I mentioned in the ticket, you need to run > ndk-build in the
> >>> /orbotservice directory to create those native assets first.
> >>>
> >>> We are working on extracting the native binary build components
into
> >> a
> >>> separate gradle dependency, to make working on the app itself,
> >> easier.
> >>> For now though, yes, you must build!
> >>>
> >>> On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote:
>  It's hard to build Orbot, I solved several problems with the
>  toolchain
>  but
>  now I'm stuck here building Tor binary:
> 
>  zip ../orbotservice/src/main/assets/armeabi/pdnsd.mp3
>  ../orbotservice/src/main/libs/armeabi/pdnsd
>  zip warning: name not matched:
>  ../orbotservice/src/main/libs/armeabi/pdnsd
> 
>  zip error: Nothing to do!
>  (../orbotservice/src/main/assets/armeabi/pdnsd.mp3)
> 
>  Is 

Re: [guardian-dev] Hi, i' new

[Hans-Christoph Steiner]

Yes.  Check out our TrustedIntents library for some methods.  Also, this
project has some other methods for validating Intents received by a Service:

https://gitlab.com/fdroid/privileged-extension/

.hc

arrase:
> Is it possible to know which app has sent an Intent service? I'll
> investigate
> 
> It seems to me a good method if it is possible to implement it without
> having to ask the app to identify itself.
> 
> 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner > :
> 
>>
>> I think adding any kind of user interaction is too much complexity.
>> This needs to be entirely transparent to the user, at least to start
>> with.  Orbot has no saved state beyond the basic config stuff (e.g.
>> using VPN mode, allowing background starts, etc).  So its entirely up to
>> the app to save the Hidden Service key.
>>
>> If an app sends Orbot a private key, it will remember which app sent it,
>> and only allow that exact app to do anything with it.  An app can pass
>> around that private key as it wants to.
>>
>> If Orbot generates the private key, then Orbot will send that back to
>> the requesting app, and allow only that app to access it.
>>
>> .hc
>>
>> arrase:
>>> Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_SERVICE), I've
>>> extended it to maintain backward compatibility.
>>>
>>> I'm going to add another Intent to manage the small security layer that
>> I'm
>>> adding when exporting the key of a service for its backup.
>>> Once the permission for export the key is denied, only the user can
>>> re-grant it from the main application.
>>>
>>> The major picture is done, now i'm adding:
>>>
>>> - A way for import/export the configuration of a hidden service in zip
>>> fromat (UI and Intent service versions)
>>> - A way for delete a hidden service (UI and Intent service versions)
>>> - Intent for disallowing backup of the service.
>>>
>>> 2016-11-17 15:47 GMT+01:00 Nathan of Guardian <
>> nat...@guardianproject.info>:
>>>
 As Arrase point out though, there is an undocumented intent. This is
 what we use for CameraV currently. I think making it official, expanding
 it, and adding it into NetCipher makes a great deal of sense.

 On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote:
>
> The documentation is mostly in the form of javadoc strings in the
> NetCipher library, since that's the usual developer interface to this
> stuff.  Otherwise, there is a little bit here:
>
> https://guardianproject.info/code
>
> There isn't yet any official way to request a Hidden Service as of now.
>
> .hc
>
> arrase:
>> After reviewing the code and learned how to make the changes I think
 I'll
>> take this a little further.
>>
>> Keeping the backwards compatibility I will rewrite the configuration
>> preferences of the hidden services and an extension of the existing
 Intent
>> services.
>>
>> It's a big change that will take me a few days but I think it's the
 right
>> thing to do.
>>
>> Additionally I have not found a site where are documented the
 integration
>> options offered by Orbot, for example there is already the option that
 an
>> application can register a new port hidden by an Intent but I have not
>> known until reading the code despite having searched Information on
 google.
>>
>> 2016-11-15 23:26 GMT+01:00 Nathan of Guardian <
 nat...@guardianproject.info>:
>>
>>> As I mentioned in the ticket, you need to run > ndk-build in the
>>> /orbotservice directory to create those native assets first.
>>>
>>> We are working on extracting the native binary build components into
>> a
>>> separate gradle dependency, to make working on the app itself,
>> easier.
>>> For now though, yes, you must build!
>>>
>>> On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote:
 It's hard to build Orbot, I solved several problems with the
 toolchain
 but
 now I'm stuck here building Tor binary:

 zip ../orbotservice/src/main/assets/armeabi/pdnsd.mp3
 ../orbotservice/src/main/libs/armeabi/pdnsd
 zip warning: name not matched:
 ../orbotservice/src/main/libs/armeabi/pdnsd

 zip error: Nothing to do!
 (../orbotservice/src/main/assets/armeabi/pdnsd.mp3)

 Is it a known error?

 For this case I have not found references in google


 2016-11-15 20:14 GMT+01:00 arrase :

> Great , is all i need to start, many thanks.
>
> 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <
> h...@guardianproject.info>:
>
>>
>> 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 

Re: [guardian-dev] Hi, i' new

[arrase]

Is it possible to know which app has sent an Intent service? I'll
investigate

It seems to me a good method if it is possible to implement it without
having to ask the app to identify itself.

2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner :

>
> I think adding any kind of user interaction is too much complexity.
> This needs to be entirely transparent to the user, at least to start
> with.  Orbot has no saved state beyond the basic config stuff (e.g.
> using VPN mode, allowing background starts, etc).  So its entirely up to
> the app to save the Hidden Service key.
>
> If an app sends Orbot a private key, it will remember which app sent it,
> and only allow that exact app to do anything with it.  An app can pass
> around that private key as it wants to.
>
> If Orbot generates the private key, then Orbot will send that back to
> the requesting app, and allow only that app to access it.
>
> .hc
>
> arrase:
> > Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_SERVICE), I've
> > extended it to maintain backward compatibility.
> >
> > I'm going to add another Intent to manage the small security layer that
> I'm
> > adding when exporting the key of a service for its backup.
> > Once the permission for export the key is denied, only the user can
> > re-grant it from the main application.
> >
> > The major picture is done, now i'm adding:
> >
> > - A way for import/export the configuration of a hidden service in zip
> > fromat (UI and Intent service versions)
> > - A way for delete a hidden service (UI and Intent service versions)
> > - Intent for disallowing backup of the service.
> >
> > 2016-11-17 15:47 GMT+01:00 Nathan of Guardian <
> nat...@guardianproject.info>:
> >
> >> As Arrase point out though, there is an undocumented intent. This is
> >> what we use for CameraV currently. I think making it official, expanding
> >> it, and adding it into NetCipher makes a great deal of sense.
> >>
> >> On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote:
> >>>
> >>> The documentation is mostly in the form of javadoc strings in the
> >>> NetCipher library, since that's the usual developer interface to this
> >>> stuff.  Otherwise, there is a little bit here:
> >>>
> >>> https://guardianproject.info/code
> >>>
> >>> There isn't yet any official way to request a Hidden Service as of now.
> >>>
> >>> .hc
> >>>
> >>> arrase:
>  After reviewing the code and learned how to make the changes I think
> >> I'll
>  take this a little further.
> 
>  Keeping the backwards compatibility I will rewrite the configuration
>  preferences of the hidden services and an extension of the existing
> >> Intent
>  services.
> 
>  It's a big change that will take me a few days but I think it's the
> >> right
>  thing to do.
> 
>  Additionally I have not found a site where are documented the
> >> integration
>  options offered by Orbot, for example there is already the option that
> >> an
>  application can register a new port hidden by an Intent but I have not
>  known until reading the code despite having searched Information on
> >> google.
> 
>  2016-11-15 23:26 GMT+01:00 Nathan of Guardian <
> >> nat...@guardianproject.info>:
> 
> > As I mentioned in the ticket, you need to run > ndk-build in the
> > /orbotservice directory to create those native assets first.
> >
> > We are working on extracting the native binary build components into
> a
> > separate gradle dependency, to make working on the app itself,
> easier.
> > For now though, yes, you must build!
> >
> > On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote:
> >> It's hard to build Orbot, I solved several problems with the
> >> toolchain
> >> but
> >> now I'm stuck here building Tor binary:
> >>
> >> zip ../orbotservice/src/main/assets/armeabi/pdnsd.mp3
> >> ../orbotservice/src/main/libs/armeabi/pdnsd
> >> zip warning: name not matched:
> >> ../orbotservice/src/main/libs/armeabi/pdnsd
> >>
> >> zip error: Nothing to do!
> >> (../orbotservice/src/main/assets/armeabi/pdnsd.mp3)
> >>
> >> Is it a known error?
> >>
> >> For this case I have not found references in google
> >>
> >>
> >> 2016-11-15 20:14 GMT+01:00 arrase :
> >>
> >>> Great , is all i need to start, many thanks.
> >>>
> >>> 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <
> >>> h...@guardianproject.info>:
> >>>
> 
>  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.  

Re: [guardian-dev] Hi, i' new

[Hans-Christoph Steiner]

I think adding any kind of user interaction is too much complexity.
This needs to be entirely transparent to the user, at least to start
with.  Orbot has no saved state beyond the basic config stuff (e.g.
using VPN mode, allowing background starts, etc).  So its entirely up to
the app to save the Hidden Service key.

If an app sends Orbot a private key, it will remember which app sent it,
and only allow that exact app to do anything with it.  An app can pass
around that private key as it wants to.

If Orbot generates the private key, then Orbot will send that back to
the requesting app, and allow only that app to access it.

.hc

arrase:
> Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_SERVICE), I've
> extended it to maintain backward compatibility.
> 
> I'm going to add another Intent to manage the small security layer that I'm
> adding when exporting the key of a service for its backup.
> Once the permission for export the key is denied, only the user can
> re-grant it from the main application.
> 
> The major picture is done, now i'm adding:
> 
> - A way for import/export the configuration of a hidden service in zip
> fromat (UI and Intent service versions)
> - A way for delete a hidden service (UI and Intent service versions)
> - Intent for disallowing backup of the service.
> 
> 2016-11-17 15:47 GMT+01:00 Nathan of Guardian :
> 
>> As Arrase point out though, there is an undocumented intent. This is
>> what we use for CameraV currently. I think making it official, expanding
>> it, and adding it into NetCipher makes a great deal of sense.
>>
>> On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote:
>>>
>>> The documentation is mostly in the form of javadoc strings in the
>>> NetCipher library, since that's the usual developer interface to this
>>> stuff.  Otherwise, there is a little bit here:
>>>
>>> https://guardianproject.info/code
>>>
>>> There isn't yet any official way to request a Hidden Service as of now.
>>>
>>> .hc
>>>
>>> arrase:
 After reviewing the code and learned how to make the changes I think
>> I'll
 take this a little further.

 Keeping the backwards compatibility I will rewrite the configuration
 preferences of the hidden services and an extension of the existing
>> Intent
 services.

 It's a big change that will take me a few days but I think it's the
>> right
 thing to do.

 Additionally I have not found a site where are documented the
>> integration
 options offered by Orbot, for example there is already the option that
>> an
 application can register a new port hidden by an Intent but I have not
 known until reading the code despite having searched Information on
>> google.

 2016-11-15 23:26 GMT+01:00 Nathan of Guardian <
>> nat...@guardianproject.info>:

> As I mentioned in the ticket, you need to run > ndk-build in the
> /orbotservice directory to create those native assets first.
>
> We are working on extracting the native binary build components into a
> separate gradle dependency, to make working on the app itself, easier.
> For now though, yes, you must build!
>
> On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote:
>> It's hard to build Orbot, I solved several problems with the
>> toolchain
>> but
>> now I'm stuck here building Tor binary:
>>
>> zip ../orbotservice/src/main/assets/armeabi/pdnsd.mp3
>> ../orbotservice/src/main/libs/armeabi/pdnsd
>> zip warning: name not matched:
>> ../orbotservice/src/main/libs/armeabi/pdnsd
>>
>> zip error: Nothing to do!
>> (../orbotservice/src/main/assets/armeabi/pdnsd.mp3)
>>
>> Is it a known error?
>>
>> For this case I have not found references in google
>>
>>
>> 2016-11-15 20:14 GMT+01:00 arrase :
>>
>>> Great , is all i need to start, many thanks.
>>>
>>> 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <
>>> h...@guardianproject.info>:
>>>

 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 

Re: [guardian-dev] Hi, i' new

[arrase]

Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_SERVICE), I've
extended it to maintain backward compatibility.

I'm going to add another Intent to manage the small security layer that I'm
adding when exporting the key of a service for its backup.
Once the permission for export the key is denied, only the user can
re-grant it from the main application.

The major picture is done, now i'm adding:

- A way for import/export the configuration of a hidden service in zip
fromat (UI and Intent service versions)
- A way for delete a hidden service (UI and Intent service versions)
- Intent for disallowing backup of the service.

2016-11-17 15:47 GMT+01:00 Nathan of Guardian :

> As Arrase point out though, there is an undocumented intent. This is
> what we use for CameraV currently. I think making it official, expanding
> it, and adding it into NetCipher makes a great deal of sense.
>
> On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote:
> >
> > The documentation is mostly in the form of javadoc strings in the
> > NetCipher library, since that's the usual developer interface to this
> > stuff.  Otherwise, there is a little bit here:
> >
> > https://guardianproject.info/code
> >
> > There isn't yet any official way to request a Hidden Service as of now.
> >
> > .hc
> >
> > arrase:
> > > After reviewing the code and learned how to make the changes I think
> I'll
> > > take this a little further.
> > >
> > > Keeping the backwards compatibility I will rewrite the configuration
> > > preferences of the hidden services and an extension of the existing
> Intent
> > > services.
> > >
> > > It's a big change that will take me a few days but I think it's the
> right
> > > thing to do.
> > >
> > > Additionally I have not found a site where are documented the
> integration
> > > options offered by Orbot, for example there is already the option that
> an
> > > application can register a new port hidden by an Intent but I have not
> > > known until reading the code despite having searched Information on
> google.
> > >
> > > 2016-11-15 23:26 GMT+01:00 Nathan of Guardian <
> nat...@guardianproject.info>:
> > >
> > >> As I mentioned in the ticket, you need to run > ndk-build in the
> > >> /orbotservice directory to create those native assets first.
> > >>
> > >> We are working on extracting the native binary build components into a
> > >> separate gradle dependency, to make working on the app itself, easier.
> > >> For now though, yes, you must build!
> > >>
> > >> On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote:
> > >>> It's hard to build Orbot, I solved several problems with the
> toolchain
> > >>> but
> > >>> now I'm stuck here building Tor binary:
> > >>>
> > >>> zip ../orbotservice/src/main/assets/armeabi/pdnsd.mp3
> > >>> ../orbotservice/src/main/libs/armeabi/pdnsd
> > >>> zip warning: name not matched:
> > >>> ../orbotservice/src/main/libs/armeabi/pdnsd
> > >>>
> > >>> zip error: Nothing to do!
> > >>> (../orbotservice/src/main/assets/armeabi/pdnsd.mp3)
> > >>>
> > >>> Is it a known error?
> > >>>
> > >>> For this case I have not found references in google
> > >>>
> > >>>
> > >>> 2016-11-15 20:14 GMT+01:00 arrase :
> > >>>
> >  Great , is all i need to start, many thanks.
> > 
> >  2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <
> >  h...@guardianproject.info>:
> > 
> > >
> > > 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 

Re: [guardian-dev] Hi, i' new

[Nathan of Guardian]

As Arrase point out though, there is an undocumented intent. This is
what we use for CameraV currently. I think making it official, expanding
it, and adding it into NetCipher makes a great deal of sense.

On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote:
> 
> The documentation is mostly in the form of javadoc strings in the
> NetCipher library, since that's the usual developer interface to this
> stuff.  Otherwise, there is a little bit here:
> 
> https://guardianproject.info/code
> 
> There isn't yet any official way to request a Hidden Service as of now.
> 
> .hc
> 
> arrase:
> > After reviewing the code and learned how to make the changes I think I'll
> > take this a little further.
> > 
> > Keeping the backwards compatibility I will rewrite the configuration
> > preferences of the hidden services and an extension of the existing Intent
> > services.
> > 
> > It's a big change that will take me a few days but I think it's the right
> > thing to do.
> > 
> > Additionally I have not found a site where are documented the integration
> > options offered by Orbot, for example there is already the option that an
> > application can register a new port hidden by an Intent but I have not
> > known until reading the code despite having searched Information on google.
> > 
> > 2016-11-15 23:26 GMT+01:00 Nathan of Guardian :
> > 
> >> As I mentioned in the ticket, you need to run > ndk-build in the
> >> /orbotservice directory to create those native assets first.
> >>
> >> We are working on extracting the native binary build components into a
> >> separate gradle dependency, to make working on the app itself, easier.
> >> For now though, yes, you must build!
> >>
> >> On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote:
> >>> It's hard to build Orbot, I solved several problems with the toolchain
> >>> but
> >>> now I'm stuck here building Tor binary:
> >>>
> >>> zip ../orbotservice/src/main/assets/armeabi/pdnsd.mp3
> >>> ../orbotservice/src/main/libs/armeabi/pdnsd
> >>> zip warning: name not matched:
> >>> ../orbotservice/src/main/libs/armeabi/pdnsd
> >>>
> >>> zip error: Nothing to do!
> >>> (../orbotservice/src/main/assets/armeabi/pdnsd.mp3)
> >>>
> >>> Is it a known error?
> >>>
> >>> For this case I have not found references in google
> >>>
> >>>
> >>> 2016-11-15 20:14 GMT+01:00 arrase :
> >>>
>  Great , is all i need to start, many thanks.
> 
>  2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <
>  h...@guardianproject.info>:
> 
> >
> > 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 <
> > h...@guardianproject.info
> >>> :
> >>
> >>>
> >>>
> >>> arrase:
>  2016-11-15 13:23 GMT+01:00 Michael Rogers <
> >> mich...@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 

Re: [guardian-dev] Hi, i' new

[Hans-Christoph Steiner]

The documentation is mostly in the form of javadoc strings in the
NetCipher library, since that's the usual developer interface to this
stuff.  Otherwise, there is a little bit here:

https://guardianproject.info/code

There isn't yet any official way to request a Hidden Service as of now.

.hc

arrase:
> After reviewing the code and learned how to make the changes I think I'll
> take this a little further.
> 
> Keeping the backwards compatibility I will rewrite the configuration
> preferences of the hidden services and an extension of the existing Intent
> services.
> 
> It's a big change that will take me a few days but I think it's the right
> thing to do.
> 
> Additionally I have not found a site where are documented the integration
> options offered by Orbot, for example there is already the option that an
> application can register a new port hidden by an Intent but I have not
> known until reading the code despite having searched Information on google.
> 
> 2016-11-15 23:26 GMT+01:00 Nathan of Guardian :
> 
>> As I mentioned in the ticket, you need to run > ndk-build in the
>> /orbotservice directory to create those native assets first.
>>
>> We are working on extracting the native binary build components into a
>> separate gradle dependency, to make working on the app itself, easier.
>> For now though, yes, you must build!
>>
>> On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote:
>>> It's hard to build Orbot, I solved several problems with the toolchain
>>> but
>>> now I'm stuck here building Tor binary:
>>>
>>> zip ../orbotservice/src/main/assets/armeabi/pdnsd.mp3
>>> ../orbotservice/src/main/libs/armeabi/pdnsd
>>> zip warning: name not matched:
>>> ../orbotservice/src/main/libs/armeabi/pdnsd
>>>
>>> zip error: Nothing to do!
>>> (../orbotservice/src/main/assets/armeabi/pdnsd.mp3)
>>>
>>> Is it a known error?
>>>
>>> For this case I have not found references in google
>>>
>>>
>>> 2016-11-15 20:14 GMT+01:00 arrase :
>>>
 Great , is all i need to start, many thanks.

 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <
 h...@guardianproject.info>:

>
> 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 <
> h...@guardianproject.info
>>> :
>>
>>>
>>>
>>> arrase:
 2016-11-15 13:23 GMT+01:00 Michael Rogers <
>> mich...@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

Re: [guardian-dev] Hi, i' new

[Nathan of Guardian]

As I mentioned in the ticket, you need to run > ndk-build in the
/orbotservice directory to create those native assets first.

We are working on extracting the native binary build components into a
separate gradle dependency, to make working on the app itself, easier.
For now though, yes, you must build!

On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote:
> It's hard to build Orbot, I solved several problems with the toolchain
> but
> now I'm stuck here building Tor binary:
> 
> zip ../orbotservice/src/main/assets/armeabi/pdnsd.mp3
> ../orbotservice/src/main/libs/armeabi/pdnsd
> zip warning: name not matched:
> ../orbotservice/src/main/libs/armeabi/pdnsd
> 
> zip error: Nothing to do!
> (../orbotservice/src/main/assets/armeabi/pdnsd.mp3)
> 
> Is it a known error?
> 
> For this case I have not found references in google
> 
> 
> 2016-11-15 20:14 GMT+01:00 arrase :
> 
> > Great , is all i need to start, many thanks.
> >
> > 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <
> > h...@guardianproject.info>:
> >
> >>
> >> 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 <
> >> h...@guardianproject.info
> >> >> :
> >> >
> >> >>
> >> >>
> >> >> arrase:
> >> >>> 2016-11-15 13:23 GMT+01:00 Michael Rogers :
> >> >>>
> >>  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 

Re: [guardian-dev] Hi, i' new

[arrase]

It's hard to build Orbot, I solved several problems with the toolchain but
now I'm stuck here building Tor binary:

zip ../orbotservice/src/main/assets/armeabi/pdnsd.mp3
../orbotservice/src/main/libs/armeabi/pdnsd
zip warning: name not matched:
../orbotservice/src/main/libs/armeabi/pdnsd

zip error: Nothing to do!
(../orbotservice/src/main/assets/armeabi/pdnsd.mp3)

Is it a known error?

For this case I have not found references in google


2016-11-15 20:14 GMT+01:00 arrase :

> Great , is all i need to start, many thanks.
>
> 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <
> h...@guardianproject.info>:
>
>>
>> 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 <
>> h...@guardianproject.info
>> >> :
>> >
>> >>
>> >>
>> >> arrase:
>> >>> 2016-11-15 13:23 GMT+01:00 Michael Rogers :
>> >>>
>>  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=0xE9E28DEA00AA5556
>> >> ___
>> >> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> >> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>> >>
>> >
>>
>> --
>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>>
>
>

Re: [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 > :
> 
>>
>>
>> arrase:
>>> 2016-11-15 13:23 GMT+01:00 Michael Rogers :
>>>
 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=0xE9E28DEA00AA5556
>> ___
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[arrase]

What do you think about the most obvious approach?

Use public intents than any other app can call to create/delete a hidden
service or for get config files of his service?

2016-11-15 15:17 GMT+01:00 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 <
> h...@guardianproject.info>:
>
>>
>>
>> arrase:
>> > 2016-11-15 13:23 GMT+01:00 Michael Rogers :
>> >
>> >> 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=0xE9E28DEA00AA5556
>> ___
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>
>
>
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[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 :

>
>
> arrase:
> > 2016-11-15 13:23 GMT+01:00 Michael Rogers :
> >
> >> 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=0xE9E28DEA00AA5556
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[arrase]

2016-11-15 13:23 GMT+01:00 Michael Rogers :

> 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.
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[Michael Rogers]

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.

Thanks,
Michael

On 15/11/16 00:32, arrase wrote:
> I have reviewed the application of:
> 
> https://briarproject.org/
> 
> I have it installed and I see that when using its own Tor daemon it
> conflicts with Orbor and I think that is a problem.
> 
> The people of briarproject could configure their application not to
> conflict with Orbot but I do not think that is a solution in the long
> term if it is intended that more applications use self-managed hidden
> services with ability to back up the service so as not to lose it
> between device changes .
> 
> In my opinion extend the Orbot api for hidden services to open these to
> the development of applications that use them intensively would be a
> great idea.
> 
> 2016-11-14 15:29 GMT+01:00 arrase  >:
> 
> 
> 
> 2016-11-14 14:53 GMT+01:00 Nathan of Guardian
> >:
> 
> I'm happy to improve the hidden service API that Orbot offers to
> make it
> work for you. It is trivial for us to add support for requesting a
> completely new hidden service.
> 
> 
> In general terms and in my modest opinion I believe that extending
> the support of hidden services as you say is a good way to take
> Orbot to the next level.
> 
> Personally and I'm not an expert, I think the option of including
> Tor built in an application is not the best option for several
> reasons, i think Orbot should be the standard for building Tor
> applications on phones but needs to be more flexible with the
> configuration of hidden services.
> 
> I believe in the benefits of hidden services, for me it is the best
> Tor has :) and I think they are a great vector to popularize Tor on
> mobile devices.
> 
> Orbot can also support the temporary hidden service capability
> in tor,
> where you generate and provide the .onion key yourself. The issue is
> that you have to do that each time tor is restarted.
> 
> 
>  I have not used ephemeral services since for now I have not found
> them practical use so I do not know much about them, just that they
> exist and how they are configured, i'm sorry.
> 
> As Hans said, Briar is already doing quite a bit with HS
> management with
> their built in Tor, but I do hope many apps will support HS without
> building in tor as well.
> 
> You can also see what the Thali Project from Microsoft did here:
> http://thaliproject.org/ThaliAndTorOnionProxy/
> 
> 
> 
>   As Hans said the Briar project seems to be very similar to my
> idea, maybe I can help instead of duplicating efforts, thanks for
> the clue.
> 
> 
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 


0x9FC527CC.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[arrase]

I have reviewed the application of:

https://briarproject.org/

I have it installed and I see that when using its own Tor daemon it
conflicts with Orbor and I think that is a problem.

The people of briarproject could configure their application not to
conflict with Orbot but I do not think that is a solution in the long term
if it is intended that more applications use self-managed hidden services
with ability to back up the service so as not to lose it between device
changes .

In my opinion extend the Orbot api for hidden services to open these to the
development of applications that use them intensively would be a great idea.

2016-11-14 15:29 GMT+01:00 arrase :

>
>
> 2016-11-14 14:53 GMT+01:00 Nathan of Guardian  >:
>
>> I'm happy to improve the hidden service API that Orbot offers to make it
>> work for you. It is trivial for us to add support for requesting a
>> completely new hidden service.
>>
>>
> In general terms and in my modest opinion I believe that extending the
> support of hidden services as you say is a good way to take Orbot to the
> next level.
>
> Personally and I'm not an expert, I think the option of including Tor
> built in an application is not the best option for several reasons, i think
> Orbot should be the standard for building Tor applications on phones but
> needs to be more flexible with the configuration of hidden services.
>
> I believe in the benefits of hidden services, for me it is the best Tor
> has :) and I think they are a great vector to popularize Tor on mobile
> devices.
>
> Orbot can also support the temporary hidden service capability in tor,
>> where you generate and provide the .onion key yourself. The issue is
>> that you have to do that each time tor is restarted.
>>
>>
>  I have not used ephemeral services since for now I have not found them
> practical use so I do not know much about them, just that they exist and
> how they are configured, i'm sorry.
>
> As Hans said, Briar is already doing quite a bit with HS management with
>> their built in Tor, but I do hope many apps will support HS without
>> building in tor as well.
>>
>> You can also see what the Thali Project from Microsoft did here:
>> http://thaliproject.org/ThaliAndTorOnionProxy/
>>
>>
>   As Hans said the Briar project seems to be very similar to my idea,
> maybe I can help instead of duplicating efforts, thanks for the clue.
>
>
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[arrase]

2016-11-14 14:53 GMT+01:00 Nathan of Guardian :

> I'm happy to improve the hidden service API that Orbot offers to make it
> work for you. It is trivial for us to add support for requesting a
> completely new hidden service.
>
>
In general terms and in my modest opinion I believe that extending the
support of hidden services as you say is a good way to take Orbot to the
next level.

Personally and I'm not an expert, I think the option of including Tor built
in an application is not the best option for several reasons, i think Orbot
should be the standard for building Tor applications on phones but needs to
be more flexible with the configuration of hidden services.

I believe in the benefits of hidden services, for me it is the best Tor has
:) and I think they are a great vector to popularize Tor on mobile devices.

Orbot can also support the temporary hidden service capability in tor,
> where you generate and provide the .onion key yourself. The issue is
> that you have to do that each time tor is restarted.
>
>
 I have not used ephemeral services since for now I have not found them
practical use so I do not know much about them, just that they exist and
how they are configured, i'm sorry.

As Hans said, Briar is already doing quite a bit with HS management with
> their built in Tor, but I do hope many apps will support HS without
> building in tor as well.
>
> You can also see what the Thali Project from Microsoft did here:
> http://thaliproject.org/ThaliAndTorOnionProxy/
>
>
  As Hans said the Briar project seems to be very similar to my idea, maybe
I can help instead of duplicating efforts, thanks for the clue.
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[Nathan of Guardian]

I'm happy to improve the hidden service API that Orbot offers to make it
work for you. It is trivial for us to add support for requesting a
completely new hidden service.

Orbot can also support the temporary hidden service capability in tor,
where you generate and provide the .onion key yourself. The issue is
that you have to do that each time tor is restarted.

As Hans said, Briar is already doing quite a bit with HS management with
their built in Tor, but I do hope many apps will support HS without
building in tor as well.

You can also see what the Thali Project from Microsoft did here:
http://thaliproject.org/ThaliAndTorOnionProxy/

+n

On Mon, Nov 14, 2016, at 05:40 AM, arrase wrote:
> I would like the application itself to manage its hidden services
> configuration, I do not want to have more ports under a single service
> name, I also want to use the .onion address as user identifier so I want
> to
> be able to read it from my application, I'd like to be able to back up
> the
> hidden service configuration files so I can migrate it to another device
> 
> El 14 nov. 2016 2:33 p. m., "Nathan of Guardian" <
> nat...@guardianproject.info> escribió:
> 
> > Orbot was definitely not designed to let any app control its instance of
> > tor. The cookie authentication is the way that is handled, but it is
> > really only meant for Orbot to be the controller app, and other apps to
> > talk to Orbot.
> >
> > What is it you are trying to do? Sounds like you might want to build tor
> > into your app directly.
> >
> > On Mon, Nov 14, 2016, at 05:06 AM, arrase wrote:
> > > NetCipher looks good, but, is there a method to find the orbot control
> > > port?
> > >
> > > I was reading the library and i cannot see a method to connect to the
> > > daemon and i would like to manage my own hidden service.
> > >
> > > I don't understad why orbot uses a random port every run for control
> > > port,
> > > do not adds an extra securety layer, is only tedious
> > >
> > > now i'm parsing proc file to catch the port number
> > >
> > > 2016-11-14 12:54 GMT+01:00 Hans-Christoph Steiner
> > >  > > >:
> > >
> > > >
> > > > Hi, welcome!
> > > >
> > > > If you want to add Tor support to apps, you'll definitely be interested
> > > > in our NetCipher library, which is where we do all our Tor integration
> > > > work:
> > > >
> > > > https://github.com/guardianproject/netcipher
> > > >
> > > > .hc
> > > >
> > > > arrase:
> > > > > Hi, I'm interested in developing applications under Tor and I've
> > known
> > > > your
> > > > > project, I find it interesting.
> > > > >
> > > > > Here is my github:
> > > > >
> > > > > https://github.com/arrase
> > > > >
> > > > > I am currently interested in writing something like TorChat or
> > Ricochet
> > > > for
> > > > > android
> > > > >
> > > > >
> > > > >
> > > > > ___
> > > > > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> > > > > To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> > > > >
> > > >
> > > > --
> > > > PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
> > > > https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
> > > > ___
> > > > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> > > > To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> > > >
> > > ___
> > > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> > > To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> >
> >
> > --
> >   Nathan of Guardian
> >   nat...@guardianproject.info
> >


-- 
  Nathan of Guardian
  nat...@guardianproject.info
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Hi, i' new

[Hans-Christoph Steiner]

I forgot to mention, Orbot is set to use `CookieAuthentication`, so even
if your app connects to the TCP socket, it shouldn't be able to do
anything. If you have root, then of course you can get that cookie and
use it.

.hc

Hans-Christoph Steiner:
> 
> Hmm, this sounds like a bug report then :-/  Apps should not be able to
> use the control port, as far as I know.  I don't think its possible to
> allow apps to use the Tor control port in a secure way, unless there is
> some kind of query-only "guest" mode.
> 
> Orbot should really use ControlSocket to use a UNIX domain socket on the
> filesystem so it can be protected by file permissions.
> 
> .hc
> 
> arrase:
>> NetCipher looks good, but, is there a method to find the orbot control port?
>>
>> I was reading the library and i cannot see a method to connect to the
>> daemon and i would like to manage my own hidden service.
>>
>> I don't understad why orbot uses a random port every run for control port,
>> do not adds an extra securety layer, is only tedious
>>
>> now i'm parsing proc file to catch the port number
>>
>> 2016-11-14 12:54 GMT+01:00 Hans-Christoph Steiner >> :
>>
>>>
>>> Hi, welcome!
>>>
>>> If you want to add Tor support to apps, you'll definitely be interested
>>> in our NetCipher library, which is where we do all our Tor integration
>>> work:
>>>
>>> https://github.com/guardianproject/netcipher
>>>
>>> .hc
>>>
>>> arrase:
 Hi, I'm interested in developing applications under Tor and I've known
>>> your
 project, I find it interesting.

 Here is my github:

 https://github.com/arrase

 I am currently interested in writing something like TorChat or Ricochet
>>> for
 android



 ___
 List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
 To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

>>>
>>> --
>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>>> ___
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org