15:12:59 #startmeeting Tor VPN/Orbot components 23 March 2022 15:12:59 Meeting started Wed Mar 23 15:12:59 2022 UTC. The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:12:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:13:08 hello and welcome! 15:13:41 :) 15:13:41 https://pad.riseup.net/p/sponsor101-android-components 15:13:53 that is where we were previously taking notes 15:14:11 So, how can we help and/or where are the sticking points? 15:15:47 One piece of context, is that the funding support the VPN work, also is meant to support broadening developer adoption of tor as a component, and thus, decisions we are making here about when to fork/merge/cherry-pick/EOL things should take that into consideration 15:16:27 yes, agreed 15:18:11 two major points that need to be discussed are: 1) does orbot's internal architecture change (and, therefore, does Tor VPN's architecture) when we integrate arti? 15:18:55 there is an argument for trying to "drop" arti into TorService and keep everything else roughly the same 15:19:00 moin 15:19:11 (hi) 15:19:41 but, there is also an argument for taking advantage of this opporunity and making tor integation easier, and leveraging arti as a fresh(er) start 15:20:02 i don't expect we'll come to an agreement in this meeting around this 15:20:17 but is an on-going discussion we should have 15:20:46 * n8fr8[m] waiting for bim to type :) 15:21:09 the second major point: 2) who/which team/org(s) should be maintaining which component - the gdoc indicates some thoughts in this direction, but we should come to agreements 15:21:34 and, 3) can the architecture be simplied in any ways (possibly related to (1)) 15:22:02 I imagined arti would be deployed into something like tor-android, replacing that C tor binary with arti. Provided the minimal java wrapping around the binary in tor-android's TorService doesn't change, Orbot in theory wouldnt' need any significant changes 15:22:17 it might be best to use onionshare-android as primary consumer of current and future components, since it is the latest, best clean room impl of tor on android: https://github.com/onionshare/onionshare-android 15:23:02 <_hc[m]> I think we should frame discussion as more bottom up: lets design the core pieces to fit in the modern world (e.g. arti/rust, TorService/Android-native, etc). Then adapt the old codebases to fit into those. 15:23:16 bim[m]: we should not that the current JNI wrapper for tor is just calling main() without any other functions exposed. i think that could change perhaps, so we don't have to rely on control port sockets, etc. 15:24:28 yes, there are separate discussions (where we'd love your involvement/input) around designing a clean API for arti 15:24:42 threeletteracronym[m] has been in some of those discussions, already 15:24:54 <_hc[m]> n8fr8[m]: onionshare-android does use TorService but they didn't go android-native and instead hacked their own direct access to the private UNIX domain socket. That should not be emulated 15:25:14 but, this is an opportunity to allow controlling/configuring "tor" in a reasonable way 15:25:53 (see relevant meeting pad: https://pad.riseup.net/p/ARTI_Interfaces-keep) 15:26:20 one consideration is running in-process vs separate process as a service. with Orbot we run everything in process, but OnionShare runs in a separate process. I think both should be tested, supported, etc, since those are both acceptable models of how an Android Service works. 15:27:02 in the VPN use case, you have one VPNService instance, and ideally there isn't another service. I can see, for that case, that you would just pipe the TUN i/o streams directly into arti within the single VPNService, and be done with it. 15:27:16 i feel like this could need its own dedicated meeting for working through these details 15:27:37 Yes, we don't have to get into arti design specifics now. 15:27:38 i'd like this meeting to make sure everyone's on the same page, and then we can go into details leter 15:29:31 I think recognizing that there are a few different usage models by developers. I am seeing how a VPN app might want to just use arti directly once it has the UserSpace IP support, while most other apps, like OnionShare or Save, should use it in the TorService/tor-android model, as a proxy. 15:29:32 n8fr8[m]: I agree with your statement about the VPNService 15:30:02 Orbot on Android is a hybrid since it both offers a VPN service and a tor daemon/proxy for other apps to utilize. 15:30:31 n8fr8[m]: our discussions have been around providing both "interfaces" in the vpn, too 15:31:12 <_hc[m]> it is important to also consider that Google has put a lot of effort into making WorkManager a reliable way to run short and long lived background tasks that tie into the system scheduling. We really should be moving towards it as much as possible 15:31:29 <_hc[m]> plus it has good debugging tools 15:31:47 _hc[m]: I don't see that point 15:31:58 eighthave[m]: Agreed. the VPN API they provide has a different long-lived lifecycle model however. 15:31:59 <_hc[m]> so native Android `Services` are good, but WorkManager is better 15:32:42 +1 what n8fr8[m] says, VPNService can run long-lived 15:32:44 <_hc[m]> I know little about the VPN, so I cna't speak to that. But for Tor/arti, PTs, or any other thing running in the background 15:32:57 (in background) 15:32:58 <_hc[m]> WorkManager is the way forward 15:33:00 cyberta: in the case of integrating Save for Android's upload-over-tor functionality, the WorkManager is a better approach that can bootstrap tor for a single operation, vs starting a Tor foreground service 15:33:40 in the VPN-Service model we would want to run the VPN all-time or?+# 15:33:46 long-live vs short-lived; service-oriented vs task-oriented... i think these two models are emerging as both valid ways to use tor that may require different considerations on the API/developer library front. 15:34:16 +1 15:34:17 ok 15:35:11 or for example, we are building Radio Free Asia's mobile news apps... it needs to periodically sync new content. Rather than starting/stopping a Service instance with Tor for that, designing around the Workmanager model is the more modern approach. 15:36:03 cyberta: worth noticing that by default on Android 29+ users can configure VPNs to be running all the time https://developer.android.com/reference/android/net/VpnService#isAlwaysOn() (though this can be disabled) 15:36:11 In my understanding (until now) I thought the User would want to run tor most of the time for most of it's apps 15:36:35 bim[m]: I know :) 15:36:41 brb 15:36:43 AFAIK, WorkManager API are designed more towards on way flow, and the scheduling of task is not guaranteed to execute in timely manner. 15:37:08 we're investigating both ways - always-on with per-app exceptions, and per-app tunneling 15:37:45 <_hc[m]> with TorService and WorkManager, we have more fleixibilty for how to deliver on the UX of having Tor always on. For example, with quick start times, tor can be started on demand 15:37:47 both ways might work while the vpn app is always running 15:38:13 but I see that there are different ideas how the vpn service is used 15:38:15 <_hc[m]> but maybe that doesn't fit with the VPN API 15:39:47 it sounds like we should have a separate meeting where we sketch the app-integration scenarios, and which architecture works best in each 15:40:33 and then we work "backwards" and see how best we can integrate arti in these architectures 15:40:41 +1 15:40:51 i liked thinking about this from the ground-up - starting at arti 15:41:25 but this discussion makes it clear that we should think of this from an "android-native" design, and build around that 15:42:48 i'd like to use the android-components meetings for this purpose 15:43:10 but apparently the current timing is not very good for everyone who should be there 15:43:28 so i'll create another poll and email it, so we can find a better time 15:44:42 the current time is becoming 21 in CEST soon 15:45:08 this meeting has been productive in helping us re-focus on the important pieces of this project - and future app integration 15:45:21 PieroV: indeed :) 15:45:30 that seems a little late, as well 15:46:09 i'll create a poll and we can find a regular meeting time where we can continue these discussions 15:46:22 thanks sysrqb 15:46:56 +1 15:46:57 any final thoughts/comments/questions for this meeting? 15:47:10 i don't want to go passed 16UTC, due to other meetings 15:47:16 so i'm happy ending here. 15:48:29 * sysrqb hears nothing 15:48:35 sounds good! 15:48:39 bye ~ im happy to elucidate any existing orbot architecture type things whenever 15:48:46 thanks everyone! i'm looking forward to continuing these conversations! 15:48:55 bim[m]: awesome, thank you! 15:48:57 oki, cu 15:48:57 One last though about future discussions 15:48:58 <_hc[m]> thanks! I'd be happy to discuss further, and definitely ping me with questions! 15:49:04 bye :) 15:49:05 n8fr8[m]: yes? :) 15:49:32 - i think talking about Tor VPN as VPN vs proxy-for-other-apps is something I'd like to dig into more, as it impacts our plans with serving developers 15:49:42 and also Leaf-vs-arti-userland 15:50:06 EOL 15:50:18 sounds good 15:50:48 we've had some other similar discussions, but this group should have that conversation and come to an understanding, as well 15:52:09 alright, thanks everyone! 15:52:11 #endmeeting