|
|
9/30/2018
|
|
|
|
|
|
16:30 -- 17:25
|
|
|
|
|
|
Session lead: Roger Dingledine
|
|
|
|
|
|
** Current state of things **
|
|
|
|
|
|
- Have a grant on censorship resistance in China starting 10/01/2018
|
|
|
- Funder's goal: Make it easy for people in China to safely upload video from their phones.
|
|
|
- Need to break down project into tasks and teams
|
|
|
- Big Picture:
|
|
|
1. We need something like Snowflake.
|
|
|
2. Tor needs to work in crappy situations.
|
|
|
3. Need to understand if it works in those situations.
|
|
|
4. Tor Browser Android needs to exist and be able to use Snowflake.
|
|
|
5. Need some user education to explain tool to local users.
|
|
|
- Question: Where should the file be uploaded? Answer: Open Archive project has an Android app that has Internet Archive as a repository.
|
|
|
- Question: What is Snowflake? Answer: Tor's public relays are easy to block. Bridges are non-public relays to avoid such blocking, but deep-packet inspection (DPI) can identify Tor traffic. Snowflake is a way to make traffic not look like Tor and instead look like WebRTC, which is a general protocol that Google Hangout (among others) uses.
|
|
|
- Question: Does Snowflake correctly implement WebRTC (i.e. doesn't suffer from "parrot" attacks). Answer: Not quite. Snowflake uses the media channel. However, Google Hangout's uses an extended data channel, which is unfortunately distinguishable on the wire. Handling this problem is on the long-term roadmap.
|
|
|
- Open Archive is a project for which two-year funding currently exists. The Internet Archive is the backend datastore and has an S3-like API for storing/reading data. A goal of Open Archive is to collect data from media organizations (e.g. journalists covering an event) in a standardized way and stored in a common location. An example is journalists in Brazil covering police misconduct who were (unfortunately) uploading data to private servers. Also, HTTP PUT doesn't seem like an ideal protocol for uploading media (or other large files) over low-resource mobile connections. An open data standard like this makes it possible that browsers other than Tor (e.g. Firefox) might build it into their browser.
|
|
|
- Suggestion: do Chinese users actually want secure video uploading? Work with the community team and do their needs-finding process to determine what would most benefit Chinese users. Open Archive project does suggest that uploading media is generally useful, even if Chinese users don't particularly demand it.
|
|
|
- Suggestion: could a peer-to-peer design for uploading video work in China? Response: A strategy might be to solve secure high-bandwidth communication in general, and then network design can be built on top of that.
|
|
|
- Question: can we speed things up by building the circuit as bridge->exit? Users may not distrust Tor that much. Response: Tor prioritizes safety. Users may not recognize the safety that they really need. A few bad outcomes may be worth higher safety for everyone.
|
|
|
- Suggestion: have we identified the gaps in the plans and problems for the project? Response: we should perhaps visualize the project to identify these gaps.
|
|
|
- Suggestion: we should see this as an opportunity to improve several pieces of Tor, such as censorship circumvention in general, mobile access in general, performance for video in general. Viewing this project through the lens of helping mobile Chinese users seems to limiting. Response: we are working on all of these things, and we should make sure that we don't forget the things that are needed for Chinese mobile users in particular. China is on the extreme end of censorship, and we already aren't doing as well as possible in less extreme areas. Shouldn't we solve those first?
|
|
|
- We need a Snowflake that works on Tor Browser Android. This is already being worked on by the Guardian Project (w/ a small amount of funding).
|
|
|
- We need a DPI-resistant WebRTC
|
|
|
- Reproducible builds for WebRTC (?) on Windows so that Tor Browser can bundle Snowflake. https://trac.torproject.org/projects/tor/ticket/25483
|
|
|
- Snowflake needs a better website. Many people are unaware of it. This is an instance of a more general problem where people don't understand Tor's censorship resistance.
|
|
|
- Snowflake has a facilitator that matches up clients and proxies. This is a point of attack: the adversary could request a million connections and also could volunteer a million proxies.
|
|
|
- Question: Why is Snowflake the solution to the problem? Obfs4 works in China. We could instead solve the problem of distributing bridges. Answer: Yes, we could work on other approaches as well. We should have some diversity in our approaches in case some of them don't work as well as expected or are blocked more quickly than expected. Snowflake is promising, though, and so we should make sure it gets adequately developed and tested.
|
|
|
- A related problem is getting Tor in censored areas. We have a system called gettor that is supposed to solve this problem. It currently isn't really working (e.g. provides 6-months old Tor Browser at the moment).
|
|
|
- We need to improve the robustness of BridgeDB. It doesn't have a spec right now.
|
|
|
- We need to understand the reachability of Tor in China. Some old research paper says it is blocked. That's probably not fully correct but may be the best we have. OONI is an important component of the solution, and there are some OONI probes in China. tor could do a better job of explaining why connections failed so that those OONI probes that fail could be better understand. Also, OONI could do more comprehensive tests. Why does WebRTC fail: is it simply blocked, are the TCP connections cut? This OONI testing improvement is a thing that shouldn't be forgotten.
|
|
|
- It would help OONI's censorship reporting if Pluggable Transports had an interface for testing.
|
|
|
- We need to measure resource consumption of Tor Android on mobile phones. How much power, memory, bandwidth? Can we then use such feedback to limit resource consumption?
|
|
|
- Does Tor Browser work to upload videos? Upload to SecureDrop does work. Are the popular websites for video upload (e.g. Facebook, Twitter) compatible with Tor Browser?
|
|
|
- Question: Should Tor Browser warn the user if the user is trying to upload a large file? Answer: This is related to anonymity of obfuscated channel as well as UX to inform users of the activity of their Tor.
|
|
|
- Is there an upload resumption built into Tor Browser? There is download resumption, but upload depends on the website to handle.
|
|
|
- Metrics team should help track tor and pluggable transport usage inside different countries.
|
|
|
- Community team: advocacy of what Tor is, with localization.
|
|
|
- archive.org should have an onion address.
|
|
|
|
|
|
** Now time for brainstorming on anything else that we have missed **
|
|
|
|
|
|
- Question: Any guidance from sponsor about geographic-specific Chinese usage? Answer: No. We should do the smart thing.
|
|
|
- Question: Will photo audio-file uploading be supported. Feedback to user could help them make the best choice of type of data.
|
|
|
- Question: What about media file metadata? Users may well accidentally deanonymize themselves. Answer: This is something we should care about. Perhaps Tor Browser should grow a media-file scrubber. Experience from SecureDrop: media organizations really wanted the metadata and didn't want it scrubbed. Perhaps feedback to the user about existing metadata could help people not shoot themselves in the foot? Also, fingerprinting of devices like cameras and microphones may invalidate explicit metadata scrubbing. It may be possible if you already have a suspect phone, but otherwise the research literature doesn't seem to indicate that this is a problem. Things like lens artifacts can be hard to remove.
|
|
|
- Suggestion: are the Snowflake proxies able to handle the desired load? Response: In an ideal world, we would be able to stripe data upload across multiple proxies.
|
|
|
- Suggestion: periodic course correction by regular contact with reality. We should at least monthly reevaluate our plan and collect data to determine if we are on the right course. Early prototypes seem important to enable such nimble response. We aren't actually providing software to the funder, which gives us some flexibility on what to build and how. Instead, we are writing (six) reports on the results. A person will be in charge of producing these report.
|
|
|
- Question: what about side channels? Could, for example, the WeChat app identify that it is running simultaneously with Tor Browser Android. Answer: This is an important concern, and we should look into the research results on this problem as well as make Tor Browser think about this.
|
|
|
- Suggestion: extension maintenance is important to consider. We should figure out how we can ensure that an app continues to work and even continues to improve. Response: we should partner with a group like the Guardian Project that has this problem as a long-term focus and experience in long-term support of tools. Another response: document everything that goes into the system. People will often build on such work to deploy within their own small groups.
|
|
|
- Question: have we put someone on evaluating the applications for this project? Answer: No. We already have a whole lot of applications. We should talk to Shari about this.
|
|
|
- Question: how do you install the browser and keep updates working. Answer: gettor to get Tor Browser. In the mobile space, there are a few app stores that we will put the app on. At this point, it's available on Google Play. It will be available on F-Droid. For censored areas, the app stores are censored, and then using gettor is a way around that, although Android can't be default install applications downloaded outside the app store. Updates on mobile devices can't automatically occur if they weren't install via the app store, which means that manual installs would also require manual updates. Also, verifying direct downloads (e.g. getting public keys and checking signatures) is not straightforward on mobile devices. This was somewhat solved in the Satori project, which had a database of known good application hashes, which it could then check to verify a downloaded app. This may net be a chicken-and-egg problem if the hash-checking app was allowed on the app store (even if the apps being checked aren't). |