15:58:23 #startmeeting tor anti-censorship meeting 15:58:23 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:23 feel free to add what you've been working on and put items on the agenda 15:58:23 Meeting started Thu Aug 18 15:58:23 2022 UTC. The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:23 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:25 hi~ 15:58:35 hello 15:58:38 hi 15:59:15 hi 15:59:18 hi! 15:59:31 wow, so many people here :) 16:00:00 hi :) 16:01:14 I have removed old topics, please add it back if you think they still need to be discussed 16:02:09 hello 16:02:10 +1 16:02:14 hi! i am nearby but in another meeting. if there is anything for me i will catch up with it in a bit 16:03:17 okay, let's begin the first topic 16:03:18 Think a new name for HTTPT PT? 16:03:18 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/httpt/-/issues/6 16:03:41 The implementation of HTTP PT is about to start 16:03:49 if we wants to rename, it is the time 16:04:14 do we want to rename it? 16:04:28 I see the rationale about HTTPT being hard to pronounce, but obfs4 is neither easy, maybe not a good excuse anyway 16:04:49 https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Baby-Name-Book 16:04:56 the good thing of keeping it HTTPT is that this is the name used by the paper that has proposed it 16:05:08 let's say webtunnel ? 16:05:27 webtunnel is pretty explicit on what it does 16:06:09 haha the baby name book 16:06:16 The way I name thing is try to make sure you can have some understanding of it based on its name 16:06:26 there are good ones there, I like moshpit, but I don't think it fits here 16:06:32 but it is just my opinion 16:07:15 i kinda agree with having the same name as the paper. Do we know how HTTPT is intended to be pronounced? 16:07:22 dcf does still make fun of the obfs4 name, so not choosing another bizarre unpronouncable one could be a win :) 16:07:59 itchyonion: i think just listing the letters, but it is difficult due to the fact that "http" and "pt" are overlapping in the initialization 16:08:50 yea makes sense 16:09:16 if choosing from the baby name book, i think cryptids make the most sense since the webpage is an illusion of sorts 16:09:25 but webtunnel also makes sense to me 16:10:38 if it helps there is no package in debian with the name 'webtunnel' 16:11:02 they will name it golang-xxxxxxx-webtunnel 16:11:15 so I don't think this will be a huge issue 16:11:44 cryptids are nice names ;) 16:11:58 some of them are already taken by popular software, like dropbear 16:12:36 yes... so currently there is two candidate: cryptids, webtunnel 16:12:58 any additional nominations? 16:13:19 I think cohosh proposal is to use any of the cryptids section (I had to look into what cryptids means :) 16:13:28 the section on the baby name book 16:13:38 isn't it? 16:13:45 there's an webtunnel app that seems to be pretty popular (1M+ downloads on Goole play), but maybe this isn't an issue since snowflake is also well-known company 16:14:05 i was looking at this: https://en.wikipedia.org/wiki/List_of_cryptids 16:14:51 ggus: any aracnid-like (that lives in a web...) 16:15:20 ? 16:16:03 https://en.wikipedia.org/wiki/Shelob 16:17:01 we may ask people to setup bridges for httpt . anything that is transparent and not possible scary would be good 16:17:53 if we were a vpn company: cryptotunnel. 16:18:22 but between webtunnel and http, i'd prefer webtunnel. 16:20:12 I'm happy with webtunnel 16:20:33 +1 16:20:50 any objections to webtunnel? 16:21:08 how much do we care about ambiguity in google search results? The only downside I can think of is there seems to be some already existing tools with that name 16:23:24 I hope searching for tor+webtunnel you'll get the right piece 16:24:04 in that case +1 from me 16:24:12 ggus: shelob was also pretty good, but I understand the rethoric of not picking up monsters 16:24:48 the same goes to snowflake, so I think it will not be a big deal 16:26:30 okay, I think we can agree on webtunnel. We should be able to rename it at a higher cost so long as it is not in tor browser yet 16:26:50 now let's move to the next topic 16:26:51 Update on the manifest V3 situation for Snowflake webextensions and possible solutions 16:26:51 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/29 16:26:51 https://bugs.chromium.org/p/chromium/issues/detail?id=1207214 16:27:10 thanks, i have a brief summary to share on this 16:27:27 yes, please go ahead 16:27:37 the short of it is that it's looking unlikely that our snowflake webextension can continue to work on chrome or chrome/chromium based browsers in its current form 16:27:50 16:27:50 google proposed manifest v3 a while ago, and has come up with a timeline for deprecating support for manifest v2 16:27:53 v2 extensions will no longer be supported on chrome/chromium starting january 2023 16:27:56 the difference between v2 and v3 extensions is extensive, and drastically limits the types of actions and apis that extensions have access to 16:27:59 this decrease in extension capabilities was done in the name of security and privacy, but as some have pointed out, is actually a privacy loss since it limits the performance of add blockers 16:28:03 the EFF has written a few articles about it. most recently: 16:28:05 https://www.eff.org/deeplinks/2021/12/googles-manifest-v3-still-hurts-privacy-security-innovation 16:28:08 the biggest issue for us is the move in v3 from allowing background pages, that have pretty much the same access as any javascript running in the browser, to what are called "service workers" 16:28:12 service workers have access to a very limited set of apis: https://developer.chrome.com/docs/extensions/reference/ 16:28:15 note specifically that they do not have access to the webrtc api, which is what caused the issue that arlolra ran into when trying an initial update to v3 (snowflake-webext!21) 16:28:19 there is an open issue in the chromium bug tracker for this: https://bugs.chromium.org/p/chromium/issues/detail?id=1207214 16:28:22 and we've added to the discussion in both the web extension working group: https://github.com/w3c/webrtc-extensions/issues/77 and https://github.com/w3c/webextensions/issues/72 16:28:26 unfortunately there's been no interest from google in supporting this for chrome so it seems unlikely that we'll be able to run snowflake proxies from a webextension in chrome based browsers after January 2023 16:28:30 there are some other pain points of google's manifest v3 that affect snowflake in less fundamental ways 16:28:33 including that extension icons are no longer visible from the browser bar, but hidden behind a puzzle icon 16:28:36 the snowflake icon shows whether or not the proxy is currently in use and whether snowflake is been turned off due to errors 16:28:39 some good news is that mozilla has responded to the discussions i linked above and is preserving support for background pages in their v3 implementation: https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/ (thanks to arlolra for finding this) 16:28:43 there are a few differences to how things work before, but i'm optimistic that we'll be able to get the current snowflake extension working for firefox's manifest v3 16:28:46 although the timeline for that is not as urgent since firefox has not announced a deprecation timeline for v2 and it's likely to be supported for at least another year 16:28:49 16:32:04 so if we take no action, then snowflake proxy will stop working on chrome and some of its forks from next year 16:32:12 yes 16:32:49 we could encourage the use of embedded page on chrome 16:33:00 like pin a page with snowflake 16:33:19 right, one of the ideas i brought up in the issue was a webextension that acts as a snowflake badge helper 16:33:35 i wrote up a quick proof of concept here: https://gitlab.torproject.org/cohosh/mv3-badgehelper 16:34:04 the idea is that it would open a snowflake badge in a new tab and automatically enable it when the extension is installed 16:34:14 and then make sure that tab is open when the browser is started 16:34:48 we could 'pin' that tab so at least doesn't take much space 16:36:03 I guess we could detect if v2 is not supported (or the mozilla webrtc extensions not present) and use this work around only in that case 16:36:18 meskio: ah yes, it looks like we can pin from the api, that's a good idea 16:37:38 there are some other usability features we could implement for this new extension flow, but i'm a bit concerned about how chrome now hides extension icons, so a user might not notice that a tab has been closed or the badge is off or of errors 16:39:08 cohosh: do you think it would makes sense for Tor to write a blogpost about all this? to add to the discussion happening there 16:40:00 gaba: yeah, i was thinking of at least writing to tor-anticensorship-team and tor-dev for some help testing the usability of workarounds 16:40:13 i'm not sure if we should do a blog post now or when we have a clear path forward 16:40:14 cohosh: we could maybe send a message to the tab to see if the tab is closed? https://developer.chrome.com/docs/extensions/reference/tabs/#method-sendMessage 16:40:33 if it is closed, just open it again 16:40:59 understood. better to wait in that case. 16:41:20 shelikhoo: hmm, we could do that, but i don't want it to be too invasive in case a user actually meant to close the tab 16:41:39 the tab should include clear instructions on how to get rid of it (dissabling the extension) 16:41:48 i suppose we might be able to have a popup when that happens asking if the user wants to disable the proxy 16:42:29 yes, but we could detect this, and take action if necessary 16:43:14 it is just going to work less gracefully 16:44:49 yeah it discouraging that our extension is going to take a significant usability hit on the most popular browser 16:45:46 arma2: i'm not sure if advocacy will be useful here, but if you know anyone who has sway on the chromium teams, this issue is the main one we care about: https://bugs.chromium.org/p/chromium/issues/detail?id=1207214 16:45:56 do we have a ticket in gitlab about it? maybe donuts have some thoughts about this 16:46:20 gaba: yes it's https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/29 16:46:24 thanks 16:47:07 can i paste your summary there cohosh? 16:47:49 yes of course! much of it is already sprinkled around there ofc 16:48:35 okay i think my next steps will be to email the anti-censorship and general tor dev mailing lists about this issue to see if some of the other groups with webextension experience have thoughts 16:49:01 +1 16:49:06 and to keep working on this tab workaround to get it into a more usable shape, with the suggestions from shelikhoo and meskio 16:49:18 thank you for the discussion 16:50:04 yes, anything more on this topic? 16:50:29 cohosh: thanks for pushing it forward 16:50:35 nothing more from my side 16:51:02 I think we could also push the adoption of the standalone proxy 16:51:16 which we have way more control over 16:51:19 than browser 16:51:27 EOF 16:51:57 more proxies can help, but i don't think the proxy is enough on its own 16:52:19 the vast majority of unique snowflake ips are webextensions 16:52:50 but yeah it's possible that with more proxies and our firefox users and badges we'll pull through okay 16:53:05 cohosh: re advocacy, i would pick 'brave' and 'we could say it on twitter' as my two top picks 16:53:33 arma2: okay i will respond to the thread meskio started with brave so they are aware of the extent of the issue 16:53:35 yes... do we have the information about the ratio of chrome and firefox users? 16:54:05 cohosh: oh! i would pick 'google ideas or whatever they're called this year' as my third idea 16:54:14 we don't collect those metrics, we might be able to see installs but that's a bit imperfect 16:54:45 yes... 16:55:10 anything more we wants to discuss in this meeting? 16:55:19 i think i'm good for now 16:55:22 Snowflake in Turkmenistan: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40024 16:55:40 arma2: i'll follow up with you and cc gus re: advocacy 16:55:40 we're getting a bunch of users requests in front desk 16:55:49 from TM and china 16:56:28 for china private bridges are working great. but for TM 16:56:36 we need to do something 16:56:41 we should roll out soon the change to use azure in TM (with circumvention settings) 16:56:48 but I'm not sure that will solve the problem 16:56:53 oof :( 16:57:10 are we sure it's an issue with the broker connection? 16:57:14 the tor logs should tell us that 16:57:19 I will finish the review of related PR as soon as possible 16:57:27 a bunch == 70+ requests per day 16:57:51 cohosh: no, we don't know what is happening there, we are trying to get a vantage point in TM 16:58:14 ggus: are any of the users able to share their tor logs? 16:58:30 (was reviewing https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/merge_requests/30 .... but it is draft now) 16:58:54 cohosh: tor logs while trying snowflake? 16:59:05 yes, just from tor browser 16:59:26 ah, this is because snowflake reports log lines to tor, and tor puts them in the log that tor browser can see? 16:59:29 we have snowflake feeding tor log messages about the connection status where the failure may be 16:59:34 right 16:59:36 yes, we have 17:00:16 but, i'll need to ask nina13[m] to upload somewhere 17:00:19 those should be verbose enough to confirm whether the issue is with the domain front 17:00:46 if they aren't we should work on fixing that too 17:03:10 okay, I think that is the end of our meeting 17:03:11 #endmeeting