18:59:49 #startmeeting S101 Core Android Components 15 March 2022 18:59:49 Meeting started Tue Mar 15 18:59:49 2022 UTC. The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:49 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:58 hello cyberta ! 19:00:03 :) hi 19:00:06 indeed 19:00:12 Pad: https://pad.riseup.net/p/sponsor101-android-components 19:01:27 I didn't follow up with Guardian Project, so I don't know if _hc or anyone else is around 19:01:37 o/ 19:01:38 and ping: aguestuser PieroV 19:01:42 ah, hello :) 19:02:07 this may be a short meeting 19:02:18 O/ 19:02:20 o/ 19:02:27 but I wanted to meet and make sure we're on the same page 19:03:08 hi Ankit 19:03:17 Ankit joined LEAP recently 19:03:26 o/ 19:03:29 Hello everyone 19:03:33 and will also help in the tor vpn project 19:03:34 welcome 19:03:58 Ankit is an experienced Android dev as well 19:04:06 excellent! 19:04:26 :) 19:04:29 welcome Ankit! :) 19:04:45 Ankit: this is the pad we use for taking meeting notes: https://pad.riseup.net/p/sponsor101-android-components 19:04:46 welcome :) 19:04:58 in case you haven't seen it, we have some notes from last meeting there 19:05:32 yeah, looking through it, it was shared with me earlier. 19:05:36 great 19:06:20 to recap, last meeting we looked at Orbot's components, as documented by Guardian Project: https://docs.google.com/document/d/14mCr8c9pp5jGoGPQH-PB71YWTW6s-4dTjOKiQLgSrCs/edit 19:06:45 and we discussed whether we think each component will be needed in a "tor vpn" 19:07:09 and/or what feature/functionality will be needed instead of that existing component 19:07:38 i believe last meeting we stopped at the last component - IPtProxy 19:07:54 aka pluggable transports 19:08:01 yes 19:08:22 currently, Guardian Project is developing it 19:08:40 tor-android and IPtProxy is also used in Bitmask/RiseupVPN 19:08:59 the advantage of IPtProxy is that it combines the multiple Go lang pluggable transports into a single binary 19:09:41 and, as a result, it reduces the total disk space needed becuase we don't include the same Go runtime in each binary for each PT 19:10:17 we also *need* to bundle all go libs into one big lib 19:10:30 to cross-compile them for mobile 19:10:45 using gomobile 19:10:59 interesting. we were wondering if any other proejct was only using tor-android 19:11:11 seems the answer is yes 19:11:24 yip 19:11:45 did you implement your own wrapper and/or controller service, like OrbotService? 19:11:58 or do you only needed the functionality exposed by TorService? 19:12:41 I basically forked TorService and added an interface for IPtProxy, it became a part of TorService 19:12:49 but it is mostly the original TorService code 19:12:59 I needed only minor adaptions 19:13:12 okay, that's good to know 19:13:13 And it is started/stopped by intents 19:14:55 we use our API service to control the tor service, but that are implementation details 19:15:57 yeah. i need to look closer at OrbotService and see what is it providing - in addition to TorService 19:16:44 Ankit and I can do that until next week, too 19:17:36 that would be very helpful, yes please 19:17:37 thanks 19:19:05 and for the Go libs, you said you need to bundle them together into one big library 19:19:20 is that because of how the Go code is called/executed? 19:19:28 that is right, you cannot have multiple go runtimes 19:19:41 okay, that makes sense 19:19:55 but it is not hard to bundle them 19:20:07 we do the same for Bitmask/RiseupVPN with different components 19:20:56 however for now I only forsee that we would use IptProxy as go dependency or? 19:21:31 you use other Go libraries Bitmask/RiseupVPN? 19:21:44 yes 19:21:58 as long at IptProxy lib keeps being maintained it sounds like the way to go to me 19:22:13 for now, in the Tor VPN, i believe we only need obfsproxy and snowflake, and we can investigate how we want them integrated 19:23:11 Tor Browser doesn't use IPtProxy, but I'm not against using it 19:23:42 but that is a discussion where we should include the anti-censorship team 19:24:04 ok 19:24:11 currently we only compile the obfsproxy and snowflake binaries, and bundle them in the app 19:25:05 that is fine, too, it's more a question of convenience and governance 19:25:11 (to me :)) 19:25:26 i'm under the impress that Guardian Project would like Tor to take over responsility for IPtProxy, so that is a larger/different discussion, too 19:25:30 *impression 19:27:25 shall I give an update wrt. onionmasq prototyping? 19:27:51 cyberta: ah, yes please - I'm just typing some notes 19:28:32 we don't have the JNI yet ready for arti, but we're working on it 19:28:49 so the integration of arti into any java service is not yet finished 19:29:30 however I see it as the next pending step 19:30:09 next to that I investigated how we can build tor circuits per app 19:30:52 based on ip package to Android UID mapping 19:31:47 it seems to be possible to filter packages per app and handle them separately 19:32:44 Android VPN APIs also have provision to either exclude certain apps or include certain apps. 19:33:00 right 19:33:17 ankit will work on UI parts to select apps in the toy vpn prototype 19:33:33 yep 19:33:48 excellent 19:34:05 that's good progress 19:34:53 I think that's it for now wrt. onionmasq 19:34:56 Committee 2 was talking about that last week a well (circuits per App). 19:35:08 interesting 19:35:20 what was the outcome? 19:35:30 and hi kwadronaut[m] :) 19:35:43 part of our discussion at our last meeting here is how (or what) replaces TorService when we integrate Arti instead of Tor 19:36:05 No answers iirc, hard questions because we're limited in what we can do. 19:36:13 to me, this sounds like the JNI is in-progress and we should begin learning more about what is needed 19:37:05 like, do we try dropping Arti into TorService, and just adapt TorService so it talked with Arti 19:37:26 or do we build a new wrapper around Arti and that JNI 19:37:27 I think for a first iteration that is reasonable 19:37:39 (the former) 19:37:55 i don't expect immediate answers, I know this is a work-in-progress :) 19:38:11 okay 19:39:11 we should be flexible, and have a goal of creating a library that makes Tor integration easy for developers 19:39:20 The learning part is a good plan though :) 19:39:37 if maintaining TorService is the best option, then that's fine with me 19:39:49 kwadronaut[m]: yep :) 19:40:32 but i want to make sure everyone understands that we are not required to use TorService if it's not best for us 19:42:07 i know there are other discussions that will happen soon around defining the "Arti Interface" 19:42:13 is it a question if we are required to keep the API backwards compatible to current TorService? 19:42:28 so that it can be a drop-in replacement? 19:42:30 so our "best option" may change as those discussion develop 19:42:39 or are we flexible with it as well? 19:42:56 cyberta: i would argue that we're flexible there 19:43:06 i would like to make migrating easy 19:43:13 ok, good 19:43:18 but that isn't a specific priority of this project 19:45:22 any other reports/comments/questions? 19:45:34 not from my side 19:45:57 Logistics: next meeting in 2 weeks? 19:46:13 i'll work on scheduling a meeting with Guardian Project regarding Orbot's components 19:46:22 kwadronaut[m]: yes, that's correct 19:47:02 always tuesdays 19 UTC now, right? 19:47:10 yes 19:47:13 cool 19:47:27 Meeting gp sooner than later is a good idea, thanks for taking that on 19:47:57 yep. alright, if nothing else, then thanks for coming everyone and talk with you soon! 19:48:06 ciao 19:48:11 cyberta: No DST changes? Aguestuser had that question earlier today 19:48:21 bye 19:48:27 #endmeeting