17:03:42 <sysrqb> #startmeeting Android Core Components 20 April 2022
17:03:42 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:03:55 <ahf> o/
17:04:38 <sysrqb> Pad: https://pad.riseup.net/p/sponsor101-android-components
17:04:52 <sysrqb> Please add any agenda/discussion items
17:06:38 <sysrqb> (ping n8fr8 _hc cyberta )
17:07:08 <_hc> I can't be present right now, but I'll check back in
17:07:15 <sysrqb> okay
17:08:05 <PieroV> sysrqb: is bim usually on these meetings?
17:08:26 <sysrqb> no, but we'd like to participate if you're available
17:08:58 <PieroV> I meant bim from leap :)
17:09:25 <PieroV> that isn't in this channel but we could ping them on tor-vpn in case
17:09:26 <sysrqb> err, sorry, "if they're available"
17:09:52 <sysrqb> *we'd like them to participate if they're available
17:10:40 <cyberta> hi
17:10:52 <sysrqb> for this meeting I only see one agenda item
17:10:59 <cyberta> sorry, I was still eating
17:11:07 <sysrqb> no worries, hi cyberta
17:11:38 <ahf> it was GP who was mostly curious about this question, no?
17:11:50 <ahf> because it is related to how much we can steal from orbot-vpn/android ?
17:12:48 <sysrqb> yes
17:13:15 <ahf> 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 <ahf> 1. all buffers can be statically allocated
17:13:28 <ahf> which means i feel safe defining an upper bound in memory usage
17:13:28 <sysrqb> 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 <sysrqb> hi bimshethey[m]
17:14:19 <ahf> 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 <ahf> it will also be used for the IPv6 IP cookies if we want ~128-120 bit cookies
17:14:42 <cyberta> isn't the idea would be that orbot and tor-vpn use android-tor as the component that integrates arti?
17:15:16 <ahf> 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 <ahf> and a bit of timeout logic
17:15:28 <ahf> 4. smoltcp is pure rust
17:17:31 <ahf> (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 <ahf> those are the primary things. we right now have a tiny patch on top of smoltcp and that is it
17:18:01 <sysrqb> cyberta: yes, it will likely be something like that
17:18:07 <ahf> otherwise it has been flexible enough for us to get it to the state where we are today
17:18:27 <sysrqb> ahf: thanks, that explanation is helpful
17:19:06 <sysrqb> i assume orbot isn't doing (creating/relying upon) any magic/fake addresses
17:19:13 <ahf> 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 <ahf> no, i think they handle DNS specially and then map it to the socks port of C tor
17:19:41 <ahf> we don't need to deal with socks with arti -- we are free! :-P
17:20:51 <sysrqb> 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 <sysrqb> s/expose/support/
17:21:13 <ahf> 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 <ahf> it has an internal socket like api that is exposed via a socks port too
17:21:28 <ahf> but arti being a library, this is way more flexible
17:21:33 <ahf> we don't use the socks port for onionmasq
17:21:40 <sysrqb> okay, right, good. that was my understanding
17:21:53 <ahf> 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 <sysrqb> ahf: do you know if using smoltcp works on iOS?
17:25:29 <ahf> we haven't tested it, but ios have an api for giving us a tunnel interface integer unix file descriptor
17:25:29 <sysrqb> like, do you know if it is written with some linux-specific assumptions?
17:25:34 <ahf> it is not
17:25:37 <sysrqb> okay
17:25:40 <ahf> it's made for IoT bare metal devices
17:25:50 <ahf> (also why they have the memory model they have)
17:26:03 <trinity[m]> 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 <ahf> trinity[m]: everything: first android and probably linux, then ios, freebsd, openbsd, etc.
17:27:54 <sysrqb> ahf: thanks. hopefully this helps start the conversation with GP about why arti is taking a different path
17:28:23 <ahf> 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 <sysrqb> alright, i see someone added: using dummy VPN app for development of tor-android (arti)
17:30:21 <cyberta> 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 <cyberta> right :)
17:30:30 <sysrqb> is that a discussion item someone wants...
17:30:53 <sysrqb> great, please go :)
17:31:32 <cyberta> so, in the last lower components meeting we were discussing how to proceed with tor-android
17:31:56 <cyberta> as part of the discussion which orbot components we want to reuse
17:32:25 <cyberta> I think one of the ideas was as a next step to replace c-tor with arti in tor-android
17:33:19 <cyberta> I would like to propose to reuse our dummy android app for (manual) integration testing
17:33:44 <cyberta> so adding tor-android as a submodule would be step 1
17:33:48 <bimshethey[m]> 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 <bimshethey[m]> 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 <ahf> 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 <cyberta> it uses it iirc
17:35:06 <bimshethey[m]> it does
17:35:18 <cyberta> bimshethey[m]: I think there are 2 android apps currently
17:35:30 <cyberta> one lives in the onionmasq repo
17:36:09 <cyberta> the other one ... in another tor repo, which showcases how to run arti on android
17:36:21 <cyberta> I would need to search the repo
17:36:26 <cyberta> I can post the link later
17:37:28 <cyberta> wrt. controlPort, tor-android uses it internally and we could replace it with whatever is needed
17:37:37 <ahf> perfect
17:37:41 <cyberta> to control arti
17:38:10 <sysrqb> ahf: does arti have an API for configuring/controlling?
17:38:33 <sysrqb> we began discussing it in the ARTI Interface meetings, but i thought that conversation stalled
17:38:43 <cyberta> 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 <ahf> 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 <cyberta> this way we can easily check if the arti integration in android-tor works correctly
17:39:42 <sysrqb> okay, starting/stopping and minor configuration may be enough for early testing
17:40:05 <sysrqb> cyberta: that sounds like a good plan to me
17:40:06 <cyberta> bimshethey[m]: I'm happy to work on that together
17:40:29 <ahf> yeah, i am sure you can do that today - it has a socks proxy exposed and such
17:40:47 <ahf> remember to note down what is missing and create S101 tickets for tpo/core/arti
17:41:15 <sysrqb> cyberta: can you create a ticket under (referencing) tpo/applications/vpn#5 for tracking this?
17:41:33 <bimshethey[m]> 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 <bimshethey[m]> cyberta cool :~)
17:42:00 <sysrqb> cyberta: and what ahf said :)
17:42:10 <cyberta> yes
17:42:53 <sysrqb> bimshethey[m]: arti may not have event notifications yet - i guess cyberta and you will find out :)
17:44:17 <sysrqb> alright, this is good process
17:44:34 <sysrqb> anyone else have comments/questions/concerns they want to bring up in this meeting?
17:45:01 <ahf> 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 <sysrqb> s/process/progress/
17:45:33 <sysrqb> ahf: yep, thanks for that offer, i'll follow up with them, as well
17:45:47 <ahf> sounds good
17:45:54 <sysrqb> them == n8fr8 and _hc, in particular
17:46:01 <ahf> ya
17:46:14 <sysrqb> bimshethey[m]: i assume you don't have any immediate questions/comments about ahf's explanation?
17:47:34 <bimshethey[m]> 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 <sysrqb> sounds good, thanks bimshethey[m]
17:48:26 <sysrqb> alright, thanks everyone for joining
17:48:35 <bimshethey[m]> 👋
17:48:35 <cyberta> have a nice day everybody!
17:48:37 <PieroV> thanks! o/
17:48:39 <sysrqb> o/
17:48:44 <sysrqb> #endmeeting