17:03:42 #startmeeting Android Core Components 20 April 2022 17:03:42 Meeting started Wed Apr 20 17:03:42 2022 UTC. The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:42 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:03:55 o/ 17:04:38 Pad: https://pad.riseup.net/p/sponsor101-android-components 17:04:52 Please add any agenda/discussion items 17:06:38 (ping n8fr8 _hc cyberta ) 17:07:08 <_hc> I can't be present right now, but I'll check back in 17:07:15 okay 17:08:05 sysrqb: is bim usually on these meetings? 17:08:26 no, but we'd like to participate if you're available 17:08:58 I meant bim from leap :) 17:09:25 that isn't in this channel but we could ping them on tor-vpn in case 17:09:26 err, sorry, "if they're available" 17:09:52 *we'd like them to participate if they're available 17:10:40 hi 17:10:52 for this meeting I only see one agenda item 17:10:59 sorry, I was still eating 17:11:07 no worries, hi cyberta 17:11:38 it was GP who was mostly curious about this question, no? 17:11:50 because it is related to how much we can steal from orbot-vpn/android ? 17:12:48 yes 17:13:15 it's hard to me to argue in the context of the orbot-vpn situation, but one reason that i went with small tcp comes from two things: 17:13:21 1. all buffers can be statically allocated 17:13:28 which means i feel safe defining an upper bound in memory usage 17:13:28 specifically, I got the impression that they are concerned arti and orbot are diverging w.r.t. arti using Smoltcp and Orbot relying on leaf 17:14:14 hi bimshethey[m] 17:14:19 2. the code is dirt simple and you can do a lot of trickery to avoid "ratching" the protocol state machines forward: this allows you to build packet filters but also to do what we do to inject "virtual end-points" into the code which is how we create a "fake" DNS server and how we dynamically will create end-points for onion services 17:14:41 it will also be used for the IPv6 IP cookies if we want ~128-120 bit cookies 17:14:42 isn't the idea would be that orbot and tor-vpn use android-tor as the component that integrates arti? 17:15:16 3. Arti is flexible enough for its API that the internal proxies are very simple. we have no middle layer: it's just client.read() => endpoint.write(), endpoint.read() => client.write() 17:15:21 and a bit of timeout logic 17:15:28 4. smoltcp is pure rust 17:17:31 (for people who don't know, leaf gets its packet engine from lwip which was what is used in orbot on ios too) 17:17:58 those are the primary things. we right now have a tiny patch on top of smoltcp and that is it 17:18:01 cyberta: yes, it will likely be something like that 17:18:07 otherwise it has been flexible enough for us to get it to the state where we are today 17:18:27 ahf: thanks, that explanation is helpful 17:19:06 i assume orbot isn't doing (creating/relying upon) any magic/fake addresses 17:19:13 if we were to build something that had to handle a socks proxy as an intermediate layer, then i'd think of using leaf 17:19:28 no, i think they handle DNS specially and then map it to the socks port of C tor 17:19:41 we don't need to deal with socks with arti -- we are free! :-P 17:20:51 hrm. are you saying arti will not expose a socks port? or only in this context of a vpn, there won't be a socks port? 17:21:07 s/expose/support/ 17:21:13 arti does expose a socks port, if you want it to, but it can also just be fed data payloads for tcp sockets 17:21:22 it has an internal socket like api that is exposed via a socks port too 17:21:28 but arti being a library, this is way more flexible 17:21:33 we don't use the socks port for onionmasq 17:21:40 okay, right, good. that was my understanding 17:21:53 we don't expose any network ports at all to the host: everything is in the virtual network stack exposed to the OS via the tun interface 17:25:04 ahf: do you know if using smoltcp works on iOS? 17:25:29 we haven't tested it, but ios have an api for giving us a tunnel interface integer unix file descriptor 17:25:29 like, do you know if it is written with some linux-specific assumptions? 17:25:34 it is not 17:25:37 okay 17:25:40 it's made for IoT bare metal devices 17:25:50 (also why they have the memory model they have) 17:26:03 Is arti-vpn meant to be Android/iOS only, or linux compatible too? Some planned features like isolation by user (which maps to apps in Android if I understood well) sounds interesting, even for some non-mobile usage 17:26:32 trinity[m]: everything: first android and probably linux, then ios, freebsd, openbsd, etc. 17:27:54 ahf: thanks. hopefully this helps start the conversation with GP about why arti is taking a different path 17:28:23 yeah. we do onionmasq outside of the arti repo also because the path is not 100% sure, but i think we can pull it off with this tech 17:30:20 alright, i see someone added: using dummy VPN app for development of tor-android (arti) 17:30:21 I've added another point to the list, if we're done with this one, I could continue and explain what I ment 17:30:26 right :) 17:30:30 is that a discussion item someone wants... 17:30:53 great, please go :) 17:31:32 so, in the last lower components meeting we were discussing how to proceed with tor-android 17:31:56 as part of the discussion which orbot components we want to reuse 17:32:25 I think one of the ideas was as a next step to replace c-tor with arti in tor-android 17:33:19 I would like to propose to reuse our dummy android app for (manual) integration testing 17:33:44 so adding tor-android as a submodule would be step 1 17:33:48 cyberta this is something i'm a bit curious about... i haven't had the time to build + run arti yet but have been following it from a distance. i have a bit of experience with getting rust code running on android 17:34:16 also i'm curious about where to find the dummy app, n8fr8 told me about it over tea a few days ago 17:34:36 keep in mind that arti doesn't have a ControlPort compatible interface - i don't know how much tor-android uses that 17:34:57 it uses it iirc 17:35:06 it does 17:35:18 bimshethey[m]: I think there are 2 android apps currently 17:35:30 one lives in the onionmasq repo 17:36:09 the other one ... in another tor repo, which showcases how to run arti on android 17:36:21 I would need to search the repo 17:36:26 I can post the link later 17:37:28 wrt. controlPort, tor-android uses it internally and we could replace it with whatever is needed 17:37:37 perfect 17:37:41 to control arti 17:38:10 ahf: does arti have an API for configuring/controlling? 17:38:33 we began discussing it in the ARTI Interface meetings, but i thought that conversation stalled 17:38:43 so basically my idea would be that we can choose in the dummy app to either start our onionmasq vpn or android-tor 17:38:58 yeah, for some of the things i believe. it has an API but not a protocol, but i don't think a lot of the ControlPort features are implemented 17:39:31 this way we can easily check if the arti integration in android-tor works correctly 17:39:42 okay, starting/stopping and minor configuration may be enough for early testing 17:40:05 cyberta: that sounds like a good plan to me 17:40:06 bimshethey[m]: I'm happy to work on that together 17:40:29 yeah, i am sure you can do that today - it has a socks proxy exposed and such 17:40:47 remember to note down what is missing and create S101 tickets for tpo/core/arti 17:41:15 cyberta: can you create a ticket under (referencing) tpo/applications/vpn#5 for tracking this? 17:41:33 tor-android's use of the control port is pretty minimal, Orbot subscribes to a few events. as of right now onion services aren't spun up via the controller but via torrc. I'm assuming that arti provides similar APIs for some very basic tor events, and if so then it wouldn't be too much of an upheaval to swap out c tor in tor-android and try it in something like Orbot 17:41:54 cyberta cool :~) 17:42:00 cyberta: and what ahf said :) 17:42:10 yes 17:42:53 bimshethey[m]: arti may not have event notifications yet - i guess cyberta and you will find out :) 17:44:17 alright, this is good process 17:44:34 anyone else have comments/questions/concerns they want to bring up in this meeting? 17:45:01 maybe if GP has more questions here now that they missed this, i can just do a bbb sync with them about this too 17:45:17 s/process/progress/ 17:45:33 ahf: yep, thanks for that offer, i'll follow up with them, as well 17:45:47 sounds good 17:45:54 them == n8fr8 and _hc, in particular 17:46:01 ya 17:46:14 bimshethey[m]: i assume you don't have any immediate questions/comments about ahf's explanation? 17:47:34 not immediately,,, i didn't know this meeting was happening til just before i joined and have only been half invested ~ i'm gonna be afk for a few days but i'll sync back with yinz once i have more time next week 17:48:14 sounds good, thanks bimshethey[m] 17:48:26 alright, thanks everyone for joining 17:48:35 👋 17:48:35 have a nice day everybody! 17:48:37 thanks! o/ 17:48:39 o/ 17:48:44 #endmeeting