From tor at antonela.me Tue Dec 3 15:59:02 2019 From: tor at antonela.me (Antonela Debiasi) Date: Tue, 3 Dec 2019 12:59:02 -0300 Subject: [ux] UX team meeting notes, 3 december 2019 Message-ID: <63e606b2-0fcd-64b4-eaad-32e269322340@antonela.me> Hi! The weekly UX team meeting just happened. Here is our meeting log http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-12-03-14.00.log.html Notes are below: ------------------------ Meeting 2019-12-03 ------------------------ People: - antonela - emmapeel - nah - pili == Updates == Antonela:     - writing November report - https://pad.riseup.net/p/ux-report-kp     - filed #32645 Update URL bar onion indicators     - reviewed #21952 Onion location     - reviewed #32325 Allow letterboxing opt-in/out     - reviewed #30570 Implement per-site security settings support     - working with OONI UX tickets as part of S30 > https://github.com/orgs/ooni/projects/3     - reviewing Nah's onion services user research and planning next research on the Download Tor Browser flow emmapeel:     - Last week:         - debugging the navar and footer with hiro         - reviewing new translations for manual and support.tpo         - send personal messages to translators         - more docs for translators     - This week:         - same         - maybe glossary specs         nah:     - working with s9 partner to run user research         - survey trainer's feedback is ready and ppl are already filling it out :)         - needs to create user researcher feedback survey + swag survey     - research for onion services     - gonna join gus at tor's presentation on a cryptoparty this weekend Pili:     - Finished and submitted S9 Phase 2 report     - S27 November report     - Catching up after a month of reporting ;)            == Discussion == - First meeting of the month means **triage** - Kanban update https://dip.torproject.org/groups/torproject/ux/-/boards - Feature Request - Tor Team / Contributors link in 'About Tor Browser' https://trac.torproject.org/projects/tor/ticket/31963 - Discuss: tor#32324: Introduce Letterboxing to users - [new] - https://bugs.torproject.org/32324 Thanks, A From tor at antonela.me Tue Dec 10 15:50:22 2019 From: tor at antonela.me (Antonela Debiasi) Date: Tue, 10 Dec 2019 12:50:22 -0300 Subject: [ux] UX team meeting notes, 10 december 2019 Message-ID: <0302c507-91e6-50a2-c2ef-e78d5b766b47@antonela.me> Hi! The weekly UX team meeting just happened. Here is our meeting log http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-12-10-13.59.html Notes are below: UX team work meeting pad ------------------------ Meeting 2019-12-10 ------------------------ People: - antonela - pili - nah - emmapeel == Updates == Antonela: - writing November report - https://pad.riseup.net/p/ux-report-kp - working with OONI UX tickets as part of S30 > https://github.com/orgs/ooni/projects/3 - S9, S27, Mozilla meetings - preparing a new /download page for user research > https://lektor-staging.torproject.org/tpo/develop/download/ - reviewing TorBrowserTeam201912 + ux-team tickets     https://trac.torproject.org/projects/tor/ticket/32228     https://trac.torproject.org/projects/tor/ticket/32119     https://trac.torproject.org/projects/tor/ticket/21952     https://trac.torproject.org/projects/tor/ticket/30570 Pili:     - Reviewing December and January roadmap     - OTF Proposal revisions     - S9, S27 and Mozilla Meetings Nah:     - download page user research     - coordinating user research with partners and gus this week!     - onion services research     - gonna set up a pad for a conversation about privacy and feminism by design for the iff emmapeel:     - more translators for manual and support portal     - cleaning up some locales with erinm     - community.tpo translations FORMAT! Name:     This week:         - What you worked on this week.         == Discussion == - Can we have https://lektor-staging.torproject.org/tpo/develop/download/ ready for testing? - iff desk test < do we need to apply to do something like this? == Interesting Links ⚡️ == https://24ways.org/2019/iconography-of-security/ Thanks, A -- Antonela Debiasi UX Team Lead @antonela E2330A6D1EB5A0C8 https://torproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From soncyq47 at protonmail.com Mon Dec 16 02:06:17 2019 From: soncyq47 at protonmail.com (soncyq47) Date: Mon, 16 Dec 2019 02:06:17 +0000 Subject: [ux] Suggestion to unblock bridges in China Message-ID: I heard in some of Roger Dingledine's talks that for Tor bootstrapping, if an Obfs4 bridge is on a dynamic IP, so long as one bridge is still working, it will automatically find the new IP of that bridge when the IP changes. That means when the Great Firewall requested all the IPs of the bridges one by one at https://bridges.torproject.org/ (same as the request button on tor browser) and the gmail bridges at torproject.org bucket, and added them to the blacklist, they automatically get updated when the dynamic IP changes. (Remember the Obfs4 protocol works in China, it's just the bridge distribution that's the problem) The seemingly simple answer is to not update tor users during bootstrapping when the bridges dynamic IPs changes. That would get the massive list of bridge IPs at https and gmail pools out of the nasty hands of the Great Firewall. So many Obfs4 bridges would start working again in China! I am aware that users will have to find a bridge IP again, but it requires a massive resource for the Great Firewall to find them all again, and only a short time for a user to click 'request a bridge from torproject.org' (which works through meek). I assume it would have to be implemented at the rely/directory side rather than the client side for it to work. Implementing my idea should be as easy as removing a harmful feature. Sent with [ProtonMail](https://protonmail.com) Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phw at torproject.org Mon Dec 16 17:46:53 2019 From: phw at torproject.org (Philipp Winter) Date: Mon, 16 Dec 2019 09:46:53 -0800 Subject: [ux] Suggestion to unblock bridges in China In-Reply-To: References: Message-ID: <20191216174653.rtpvzdmnywtcj2qu@nymity.ch> On Mon, Dec 16, 2019 at 02:06:17AM +0000, soncyq47 wrote: > I heard in some of Roger Dingledine's talks that for Tor > bootstrapping, if an Obfs4 bridge is on a dynamic IP, so long as one > bridge is still working, it will automatically find the new IP of that > bridge when the IP changes. I think you're talking about the UpdateBridgesFromAuthority feature. In practice, this feature doesn't work very well: > That means when the Great Firewall requested all the IPs of the > bridges one by one at https://bridges.torproject.org/ (same as the > request button on tor browser) and the gmail bridges at torproject.org > bucket, and added them to the blacklist, they automatically get > updated when the dynamic IP changes. (Remember the Obfs4 protocol > works in China, it's just the bridge distribution that's the problem) We do have bridges with dynamic IP addresses but I believe that the majority still has a static address. One could determine the exact numbers by processing the data at . > The seemingly simple answer is to not update tor users during > bootstrapping when the bridges dynamic IPs changes. That would get the > massive list of bridge IPs at https and gmail pools out of the nasty > hands of the Great Firewall. So many Obfs4 bridges would start working > again in China! I am aware that users will have to find a bridge IP > again, but it requires a massive resource for the Great Firewall to > find them all again, and only a short time for a user to click > 'request a bridge from torproject.org' (which works through meek). I > assume it would have to be implemented at the rely/directory side > rather than the client side for it to work. Implementing my idea > should be as easy as removing a harmful feature. I'm afraid that the GFW is more efficient at getting bridges from BridgeDB than our users are. We believe that the GFW has code to solve BridgeDB's CAPTCHAs and it's clearly outperforming users. See the following ticket for more background: CAPTCHAs are a dead end and we need new methods for distributing bridges. One alternative is snowflake, which relies on the assumption that many ephemeral proxies will be too costly for a firewall to block. Another alternative are social network-based bridge distributors like Salmon: From soncyq47 at protonmail.com Tue Dec 17 02:00:21 2019 From: soncyq47 at protonmail.com (soncyq47) Date: Tue, 17 Dec 2019 02:00:21 +0000 Subject: [ux] Suggestion to unblock bridges in China In-Reply-To: <20191216174653.rtpvzdmnywtcj2qu@nymity.ch> References: <20191216174653.rtpvzdmnywtcj2qu@nymity.ch> Message-ID: Philipp Winter, I've seen your presentation on active probing. It's an honour to talk with you. >>"I'm afraid that the GFW is more efficient at getting bridges from BridgeDB than our users are. We believe that the GFW has code to solve BridgeDB's CAPTCHAs and it's clearly outperforming users."<< Of-course the GFW can get one bridge faster than a user. The point I was trying to make was that users should be able to get one before the GFW gets all of them. Also you didn't address the gmail bridges at torproject.org approach. Google uses more than just captchas to prevent someone from mass creating gmail accounts. But just in terms of captcha, it is known that people have programmed bots to solve text based captchas but I would be surprised if any bot today could solve Google's picture based re-captcha. And even if a team of humans at the GFW gets all of them, their dynamic IPs would get them unblocked again, so they would have to constantly get new accounts for months/years in which case Google would certainly respond. Keep in mind this applies to every distribution method! You could also utilise SMS based distribution. I have another idea. Each install/first launch of tor browser fingerprints your device and converts that into an arbitrary ID that can't be traced back into anything meaningful. The ID should be encrypted or otherwise hidden so that users can't see/have no control over it. Then that ID is sent to bridges.torproject.org and it answers the same ID the same way. When BrdigeDB decrypts the ID it proves knowledge of a secret that prevents adversary clients from sending many random fake IDs. Here's another idea. Why do you think ExpressVPN works in China? It's the pay-wall. If many bridge publishers charged for reachability details, that could help decentralise distribution and get a working bridge using an already working method. Anyway, those are my ideas. Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, December 16, 2019 5:46 PM, Philipp Winter wrote: > On Mon, Dec 16, 2019 at 02:06:17AM +0000, soncyq47 wrote: > > > I heard in some of Roger Dingledine's talks that for Tor > > bootstrapping, if an Obfs4 bridge is on a dynamic IP, so long as one > > bridge is still working, it will automatically find the new IP of that > > bridge when the IP changes. > > I think you're talking about the UpdateBridgesFromAuthority feature. In > practice, this feature doesn't work very well: > https://lists.torproject.org/pipermail/tor-relays/2014-June/004823.html > > > That means when the Great Firewall requested all the IPs of the > > bridges one by one at https://bridges.torproject.org/ (same as the > > request button on tor browser) and the gmail bridges at torproject.org > > bucket, and added them to the blacklist, they automatically get > > updated when the dynamic IP changes. (Remember the Obfs4 protocol > > works in China, it's just the bridge distribution that's the problem) > > We do have bridges with dynamic IP addresses but I believe that the > majority still has a static address. One could determine the exact > numbers by processing the data at https://collector.torproject.org. > > > The seemingly simple answer is to not update tor users during > > bootstrapping when the bridges dynamic IPs changes. That would get the > > massive list of bridge IPs at https and gmail pools out of the nasty > > hands of the Great Firewall. So many Obfs4 bridges would start working > > again in China! I am aware that users will have to find a bridge IP > > again, but it requires a massive resource for the Great Firewall to > > find them all again, and only a short time for a user to click > > 'request a bridge from torproject.org' (which works through meek). I > > assume it would have to be implemented at the rely/directory side > > rather than the client side for it to work. Implementing my idea > > should be as easy as removing a harmful feature. > > I'm afraid that the GFW is more efficient at getting bridges from > BridgeDB than our users are. We believe that the GFW has code to solve > BridgeDB's CAPTCHAs and it's clearly outperforming users. See the > following ticket for more background: > https://bugs.torproject.org/32117 > > CAPTCHAs are a dead end and we need new methods for distributing > bridges. One alternative is snowflake, which relies on the assumption > that many ephemeral proxies will be too costly for a firewall to block. > Another alternative are social network-based bridge distributors like > Salmon: https://censorbib.nymity.ch/#Douglas2016a > > UX mailing list > UX at lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/ux From tor at antonela.me Tue Dec 17 15:49:24 2019 From: tor at antonela.me (Antonela Debiasi) Date: Tue, 17 Dec 2019 12:49:24 -0300 Subject: [ux] UX team meeting notes, 17 december 2019 Message-ID: <581ae572-cfed-6f6a-a1ba-93d9adc548fd@antonela.me> Hi! The last UX team meeting of the year just happened. Here is our meeting log http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-12-17-14.00.log.html Thanks for being part of the Tor UX team this year! A UX team work meeting pad ------------------------ Meeting 2019-12-17 ------------------------ People: - antonela - c1e0 - Pili - nah == Updates == Antonela: - Working on IFF proposals     https://pad.riseup.net/p/iff-privacy-feminism-design-2020     https://pad.riseup.net/p/iff-bridgedb-usability-2020-keep - sent November report, writing December one - https://pad.riseup.net/p/ux-report-kp - S27 reviewed #21952 - reading other teams roadmaps and building the one for the ux team emmapeel:     - translation community.tpo     - reviews other lang translations... problems with the links mostly     - some web/frontend tickets     - translation-only branches https://trac.torproject.org/projects/tor/ticket/32746     - helped weasel debug and fix the broken jenkins builds in lektor https://trac.torproject.org/projects/tor/ticket/32745     next week:         - probably moving the translation server because of scare with https://trac.torproject.org/projects/tor/ticket/32762 c1e0:     - Fixing uncentralized icons at https://www.torproject.org/contact/. Pili:     - S9 Training Partner workflow     - S27 Report     - S9 answers to report questions     - Browser proposal revisions     - Wrapping up items before going on vacation     - afk from Friday 20th December nah:     - this week i'm away for most of the days until thursday     - follow-up with s9 partners     - read and summarize reports     - iff feminist proposal FORMAT! Name:     This week:         - What you worked on this week.         == Discussion == - Next meeting date: January 7th, 2020 (!) - should we sniff users's OS and give them a Download Tor Browser one-click UX? I don't think so. https://trac.torproject.org/projects/tor/ticket/32749 - uxr @ karisma last week - Call for design > https://trac.torproject.org/projects/tor/ticket/32228 - Call for design > https://trac.torproject.org/projects/tor/ticket/3544 A -- Antonela Debiasi UX Team Lead @antonela E2330A6D1EB5A0C8 https://torproject.org From phw at torproject.org Wed Dec 18 17:35:07 2019 From: phw at torproject.org (Philipp Winter) Date: Wed, 18 Dec 2019 09:35:07 -0800 Subject: [ux] Suggestion to unblock bridges in China In-Reply-To: References: <20191216174653.rtpvzdmnywtcj2qu@nymity.ch> Message-ID: <20191218173507.ygqp5s5iagdxwtjk@nymity.ch> On Tue, Dec 17, 2019 at 02:00:21AM +0000, soncyq47 wrote: > > "I'm afraid that the GFW is more efficient at getting bridges from > > BridgeDB than our users are. We believe that the GFW has code to > > solve BridgeDB's CAPTCHAs and it's clearly outperforming users." > > Of-course the GFW can get one bridge faster than a user. The point I > was trying to make was that users should be able to get one before the > GFW gets all of them. The problem I see is that even if a user gets a bridge before the GFW, it would still end up blocked once the GFW gets it too. Or did I misunderstand? > Also you didn't address the gmail bridges at torproject.org approach. > Google uses more than just captchas to prevent someone from mass > creating gmail accounts. But just in terms of captcha, it is known > that people have programmed bots to solve text based captchas but I > would be surprised if any bot today could solve Google's picture based > re-captcha. And even if a team of humans at the GFW gets all of them, > their dynamic IPs would get them unblocked again, so they would have > to constantly get new accounts for months/years in which case Google > would certainly respond. Keep in mind this applies to every > distribution method! We see occasional crawling attempts in BridgeDB's logs: many email addresses that look similar are requesting bridges at the same time. Unfortunately, one can buy plenty of gmail addresses online, which can then be used to crawl BridgeDB's email interface. Google's reCAPTCHA is an interesting suggestion. We would have to self-host it though (if that's even possible) because we don't want to expose our users to Google. There are additional considerations in this ticket: > You could also utilise SMS based distribution. I'm afraid that phone numbers are similar to email addresses: it's just too easy to get your hands on many of them :( > I have another idea. Each install/first launch of tor browser > fingerprints your device and converts that into an arbitrary ID that > can't be traced back into anything meaningful. The ID should be > encrypted or otherwise hidden so that users can't see/have no control > over it. Then that ID is sent to bridges.torproject.org and it answers > the same ID the same way. When BrdigeDB decrypts the ID it proves > knowledge of a secret that prevents adversary clients from sending > many random fake IDs. What prevents a censor from extracting this fingerprinting algorithm, feeding it made-up device information, and using the resulting IDs to fetch bridges? Hiding encrypted IDs in Tor Browser sounds similar to copyright protection in video games, which is a fight you ultimately cannot win given a sufficiently motivated adversary. > Here's another idea. Why do you think ExpressVPN works in China? It's > the pay-wall. If many bridge publishers charged for reachability > details, that could help decentralise distribution and get a working > bridge using an already working method. I don't think I follow. Do you mean that there should be multiple bridge distribution entities (perhaps running their own BridgeDB) that charge money and therefore have an incentive to try hard to distribute unblocked bridges? > Anyway, those are my ideas. Thanks for sharing your thoughts. Don't get me wrong, these are all good ideas, but the critical questions to ask are "how much effort does it take us to build this?" and "how much effort does it take our adversary to break this?". Our adversaries have significantly more resources than we do, so we need to be smart about what distribution strategies to invest in. Cheers, Philipp From soncyq47 at protonmail.com Thu Dec 19 02:21:57 2019 From: soncyq47 at protonmail.com (soncyq47) Date: Thu, 19 Dec 2019 02:21:57 +0000 Subject: [ux] Suggestion to unblock bridges in China In-Reply-To: <20191218173507.ygqp5s5iagdxwtjk@nymity.ch> References: <20191216174653.rtpvzdmnywtcj2qu@nymity.ch> <20191218173507.ygqp5s5iagdxwtjk@nymity.ch> Message-ID: Let me just clear up some misunderstandings... >>"The problem I see is that even if a user gets a bridge before the GFW, it would still end up blocked once the GFW gets it too. Or did I misunderstand?"<< You did misunderstand. Even if the GFW eventually blocks the bridge, once their dynamic IPs change they all would get unblocked again and again each time the IP changes. The GFW would have to constantly pull down bridges for years, some users would slip through the cracks, and if the GFW stops for a month they all automatically get unblocked again. It gets exponentially harder the more people volunteer to run relays because the quantity of bridges that need to be blocked over and over again increases, which applies to every distribution avenue! >>"Google's reCAPTCHA is an interesting suggestion."<< I meant in order to create a gmail you would have to pass Google's reCAPTCHA. But I guess you answered my question about the gmail method not working. You can still go with my unintended suggestion. >>"I'm afraid that phone numbers are similar to email addresses: it's just too easy to get your hands on many of them :("<< I know of a way to get a bunch of phone numbers, but this would be mostly mitigated by separating area codes into different pools. >>"I don't think I follow. Do you mean that there should be multiple bridge distribution entities (perhaps running their own BridgeDB) that charge money and therefore have an incentive to try hard to distribute unblocked bridges?"<< I'm talking about the already existing feature where you can choose to give out the bridge yourself and tor project doesn't even have to know. Tor project could encourage bridge operators to charge money for their own address through SubscribeStar, or even for free through their own social network. If operators do charge though, it incentives them to distribute the bridge themself, hence more decentralised. And as information spreads online, users will become interested in which bridges work in China. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, December 18, 2019 5:35 PM, Philipp Winter wrote: > On Tue, Dec 17, 2019 at 02:00:21AM +0000, soncyq47 wrote: > > > > "I'm afraid that the GFW is more efficient at getting bridges from > > > BridgeDB than our users are. We believe that the GFW has code to > > > solve BridgeDB's CAPTCHAs and it's clearly outperforming users." > > > > Of-course the GFW can get one bridge faster than a user. The point I > > was trying to make was that users should be able to get one before the > > GFW gets all of them. > > The problem I see is that even if a user gets a bridge before the GFW, > it would still end up blocked once the GFW gets it too. Or did I > misunderstand? > > > Also you didn't address the gmail bridges at torproject.org approach. > > Google uses more than just captchas to prevent someone from mass > > creating gmail accounts. But just in terms of captcha, it is known > > that people have programmed bots to solve text based captchas but I > > would be surprised if any bot today could solve Google's picture based > > re-captcha. And even if a team of humans at the GFW gets all of them, > > their dynamic IPs would get them unblocked again, so they would have > > to constantly get new accounts for months/years in which case Google > > would certainly respond. Keep in mind this applies to every > > distribution method! > > We see occasional crawling attempts in BridgeDB's logs: many email > addresses that look similar are requesting bridges at the same time. > Unfortunately, one can buy plenty of gmail addresses online, which can > then be used to crawl BridgeDB's email interface. > > Google's reCAPTCHA is an interesting suggestion. We would have to > self-host it though (if that's even possible) because we don't want to > expose our users to Google. There are additional considerations in this > ticket: https://bugs.torproject.org/24607 > > > You could also utilise SMS based distribution. > > I'm afraid that phone numbers are similar to email addresses: it's just > too easy to get your hands on many of them :( > > > I have another idea. Each install/first launch of tor browser > > fingerprints your device and converts that into an arbitrary ID that > > can't be traced back into anything meaningful. The ID should be > > encrypted or otherwise hidden so that users can't see/have no control > > over it. Then that ID is sent to bridges.torproject.org and it answers > > the same ID the same way. When BrdigeDB decrypts the ID it proves > > knowledge of a secret that prevents adversary clients from sending > > many random fake IDs. > > What prevents a censor from extracting this fingerprinting algorithm, > feeding it made-up device information, and using the resulting IDs to > fetch bridges? Hiding encrypted IDs in Tor Browser sounds similar to > copyright protection in video games, which is a fight you ultimately > cannot win given a sufficiently motivated adversary. > > > Here's another idea. Why do you think ExpressVPN works in China? It's > > the pay-wall. If many bridge publishers charged for reachability > > details, that could help decentralise distribution and get a working > > bridge using an already working method. > > I don't think I follow. Do you mean that there should be multiple > bridge distribution entities (perhaps running their own BridgeDB) that > charge money and therefore have an incentive to try hard to distribute > unblocked bridges? > > > Anyway, those are my ideas. > > Thanks for sharing your thoughts. Don't get me wrong, these are all > good ideas, but the critical questions to ask are "how much effort does > it take us to build this?" and "how much effort does it take our > adversary to break this?". Our adversaries have significantly more > resources than we do, so we need to be smart about what distribution > strategies to invest in. > > Cheers, > Philipp > > UX mailing list > UX at lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/ux