- anti-censorship-team - lists.torproject.org

Resources related to user testing and screen recording
by David Fifield 14 Jul '19

14 Jul '19

These are in response to a conversation with phw and cohosh about observing how people use Tor Browser. Here are links relating to the 2015 UX Sprint, at which we did one-on-one observations of a few users. https://blog.torproject.org/ux-sprint-2015-wrapup https://trac.torproject.org/projects/tor/wiki/org/meetings/2015UXsprint The videos of the sessions are here: https://people.torproject.org/~dcf/uxsprint2015/ The source code for our screen recording setup is here. I'm attaching the README. https://www.bamsoftware.com/git/repo.eecs.berkeley.edu/tor-ux.git Here's a rough description of the whole process. We ran user experiments over two days. We were hampered by late recruiting (Berkeley only approved the experiment literally the day before) and we only had five participants, three on Saturday and two on Sunday. But that number turned out to be plenty because of how labor-intensive the process was. We had all the devs in a room downstairs with a projector. The experiments were run upstairs in a smaller room on a laptop. What we did was screencast the laptop screen to the projector downstairs (using VLC streaming through an SSH tunnel). Developers could watch user interactions live, and we also recorded the whole thing. We audio recorded the subjects' voices on handheld audio recorders (we encouraged them to think out loud as they were using the software). The idea was to transcribe the audio and add it to the screen recordings as subtitles. That was a huge amount of work, but the videos are really interesting and enlightening. We gave participants the choice of a Windows or Mac laptop. It happens that all of the chose Mac, though we had Windows ready to go. Windows was a big pain to set up with VLC and SSH; I might do that differently a second time. We originally planned to run up to two experiments simultaneously. That would have been way too hectic. It's a lot of work greeting people, doing paperwork, doing the experiment, making sure you reset the computer in between experiments--we really needed an extra person downstairs all that time. With more researchers (i.e., people allowed to interact with participants) it would be possible. We budgeted one hour of one-on-one time with each participant. It ended up taking between 15 and 30 minutes of actual experiment for each (that's how long the resultant videos are), but that doesn't count all the paperwork and setup time. 60 minutes of actual experiment would have been too long. It could be that long if it were not one on one. But also, there was high variance in how long things took to complete. Some users took longer to install than others. Another took a long time trying to find a specific UI element. The repo for our PETS 2017 paper is here: https://github.com/lindanlee/PETS2017-paper The screen capture videos from a pilot session of recording are here: https://github.com/lindanlee/PETS2017-paper/tree/master/sessions/pre/videos Scripts relating to setting up the simulated censorship firewall are here: https://github.com/lindanlee/PETS2017-paper/tree/master/experiment

1 0

"Dissecting Tor Bridges" NDSS'17 paper
by Philipp Winter 09 Jul '19

09 Jul '19

I skimmed Matic et al.'s NDSS'17 paper "Dissecting Tor Bridges: a Security Evaluation of Their Private and Public Infrastructures": <https://censorbib.nymity.ch/pdf/Matic2017a.pdf> Below are the points that stood out the most to me. Note however that the study is from 2017 and some numbers may no longer be valid. * With the exception of China and the U.S., default bridges served by far the most users. The popularity of default bridges makes them a single point of failure that is easy for censors to block. We have been losing default bridges over the last few months and should be recruiting new operators: <https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges> We have a list of criteria for new operators at the bottom of the page. If you are interested in running a default bridge, please get in touch. * Four OR ports (443, 8443, 444, and 9001) were used much more often than others. Today, 19% of bridges use port 9001 and 17% use port 443. Port 9001 is problematic because it is an attractive target for Internet-wide scans. So is port 443 but it has some merit for users who seek to circumvent corporate firewalls. Is there any reason at all to have bridges listen on port 9001? If not, we should ask these operators to pick a new port. * If a censor discovers a bridge and the bridge runs an SSH server, the censor can fetch its fingerprint and use Shodan to find other SSH servers with the same fingerprint. These servers may also be running bridges. Bridge-specific SSH keys would fix this problem. We may want to create a "bridge opsec guide" for subtle issues like these. * Shodan and Censys are search engines for Internet-wide scans. The authors were successful in using these datasets to find 35% of "public" bridges, i.e., bridges that publish their server descriptor to the bridge authority. The idea is to look for certificates that resemble a Tor bridge and then actively probe the port to confirm this suspicion. This is a tricky balancing act: most bridges should probably avoid the ports that Shodan and Censys scan but we need a few of them for users whose firewalls whitelist these ports. * Many bridges run transports that are both resistant *and* vulnerable to the GFW's active probing attacks. The vulnerable protocols are a liability to the resistant protocols. We fixed this issue in BridgeDB (#28655) but it remains a problem for Internet-wide scans: if a censor discovers a bridge via a port 9001 scan, obfs4's probing-resistance doesn't help. The need to haven an open OR port (#7349) remains a painful issue. Also, wouldn't it be useful to have a mechanism to instruct bridges to stop serving a transport? At this point, there is no reason to still serve obfs2, obfs3, or ScrambleSuit. Cheers, Philipp

1 0

Meeting on July 4 cancelled
by Philipp Winter 24 Jun '19

24 Jun '19

Let's cancel the anti-censorship meeting on July 4. It's a national holiday in the U.S. and several of our developers won't be around. Cheers, Philipp

1 0

Future of Traffic obfusication
by Free Beer 11 Jun '19

11 Jun '19

> Neat. Yes, and all built with existing components. In terms of your chart of Fri May 31 05:02:35 UTC 2019, the original Shadowsocks (SS) was at the look-like-nothing end. ShadowsocksR (SSR), by contrast, offers various experiments in protocol mimicry. Of course, as the censorship arms race escalates, you have to become more and more accurate in your mimicry. There are mutterings on the Internet that _some_ original SS servers are now being detected. No one knows for sure what methods the Great Firewall (GFW) uses. Entropy analysis is one possibility. I see this was mentioned in your reference "Seeing through Network-Protocol Obfuscation." Certain detection methods apply only to private servers. For example, the GFW may simply look to see whether the destination IP address belongs to one of the popular low-cost VPS providers with good latency to China. Traffic metrics may also play a part. If all of your traffic goes to one IP address, and you are the only person who sends traffic that IP address, then it sure looks like some kind of private proxy. On the other hand, certain detection methods apply only to a public project like Tor. These include picking bridge IP addresses out of Github, and requesting new bridges by email every day for as long as it takes to enumerate them. In both cases, we could call such methods "obfuscation agnostic." In other words, it doesn't matter how sophisticated your obfuscation techniques become. You need to think about protecting your server addresses from detection. Sent with ProtonMail Secure Email.

1 0

Future of Traffic obfusication
by Free Beer 09 Jun '19

09 Jun '19

> does anyone have any good predicitions about where > the traffic obfusication is in 5 years ? The experience in China is that any given anti-censorship method will be effective for only 4 years before it is blocked. Therefore, what will work in 5 years time has not yet been invented. :) Just out of interest, for countries where both Tor and Tor bridges are blocked by a firewall, you can configure Tor Browser to use ShadowsocksR (SSR) as a proxy server. I put a quick 1'19" proof-of-concept video up on YouTube with the title Tor浏览器+ShadowsocksR(SSR)客户端配置 Client Configuration: https://www.youtube.com/watch?v=VRGZ4dOYv1Q Sent with ProtonMail Secure Email.

2 1

Re: [anti-censorship-team] Future of Traffic obfusication
by Flipchan 07 Jun '19

07 Jun '19

Is there any research or developement done in anti correlation protocols such as system based on ring signatures such as the ring transactions in monero? On June 7, 2019 3:00:09 PM GMT+03:00, anti-censorship-team-request(a)lists.torproject.org wrote: >Send anti-censorship-team mailing list submissions to > anti-censorship-team(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team > >or, via email, send a message with subject or body 'help' to > anti-censorship-team-request(a)lists.torproject.org > >You can reach the person managing the list at > anti-censorship-team-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of anti-censorship-team digest..." > > >Today's Topics: > > 1. Future of Traffic obfusication (Flipchan) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 06 Jun 2019 22:53:32 +0300 >From: Flipchan <flipchan(a)riseup.net> >To: anti-censorship-team(a)lists.torproject.org >Subject: [anti-censorship-team] Future of Traffic obfusication >Message-ID: <1FA6176E-CDB2-483C-B6AD-7987A26371AF(a)riseup.net> >Content-Type: text/plain; charset="utf-8" > >Hey all, > >I am working on a podcast episode about traffic obfusication, and there >is a lot of nice whitepapers talking about potentially anonymous ways >of shuffeling traffic. > >However, I am intresting in the future of traffic obfusication and the >large problems that traffic obfusication faces today, does anyone have >any good predicitions about where the traffic obfusication is in 5 >years ? > >Or do we wait and see for the next big Whitepaper and PoC code ? > >What do you think? > > >Thanks in advance >Sincerely >Flipchan > >

1 0

Future of Traffic obfusication
by Flipchan 06 Jun '19

06 Jun '19

Hey all, I am working on a podcast episode about traffic obfusication, and there is a lot of nice whitepapers talking about potentially anonymous ways of shuffeling traffic. However, I am intresting in the future of traffic obfusication and the large problems that traffic obfusication faces today, does anyone have any good predicitions about where the traffic obfusication is in 5 years ? Or do we wait and see for the next big Whitepaper and PoC code ? What do you think? Thanks in advance Sincerely Flipchan

1 0

roadmap update
by Gaba 28 May '19

28 May '19

Hi! We need to update the roadmap for the team. I'm sure there may be other things coming up that may have a higher priority now than what we though back in January. Is there any date next week that works better for you two? We only need one hour (or less) where we reorganize the roadmap, sorting out priorities, adding anything else or removing something that does not makes sense to work on anymore. cheers, gaba ps. Sorry, I didn't add this to my TODO list and then I forgot. -- Project Manager: Network, Anti-Censorship and Metrics teams and OONI support gaba at torproject.org she/her are my pronouns GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

3 8

No IRC meeting on May 23
by Philipp Winter 20 May '19

20 May '19

Hi team, Cecylia, Roger, and I will be attending a project meeting on Thursday and Friday, and won't have time to attend the meeting. Let's cancel this weeks' meeting and meet again next week, on May 30. Cheers, Philipp

1 0

BridgeDB proposal for Tor's research safety board
by Philipp Winter 25 Apr '19

25 Apr '19

During today's IRC meeting, I mentioned that we should submit the data collection that we intend to do as part of <https://bugs.torproject.org/9316> to Tor's research safety board. I had a chance to write a draft of the proposal -- you can find it attached to this email. Please let me know your thoughts. I'm particularly curious if you can think of risks that I did not consider, and on the heuristics we intend to collect to identify bots. Thanks, Philipp

1 0

2025

2024

2023

2022

2021

2020

2019

anti-censorship-team