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