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