[tor-project] hackweek DEMO day starting at 15UTC on Friday 2nd

Gaba gaba at torproject.org
Thu Apr 1 13:59:16 UTC 2021

Hi people!

Hope you all had a great week! We are going to be doing a demo of all
the projects that people worked on during this hackweek. It will be at
15UTC tomorrow Friday.

You can look at the projects and find the url for the lounge in

see you tomorrow,

On 3/29/21 11:13 AM, Gaba wrote:
> Hi everybody!
> Hackweek is kicking off in less than an hour!  You can read about it in
> https://gitlab.torproject.org/tpo/community/hackweek and come hangout
> with us in irc.
> cheers,
> gaba
> On 3/24/21 3:50 PM, Gaba wrote:
>> Hi!
>> Next week we are hacking on small projects all week! There are 10
>> proposals so far from visualizing metrics data to adding onion services
>> v3 support to arti.
>> To kickoff the week we will have an opening session on **Monday March
>> 29th at 15UTC**. Projects will be presented at that session and teams
>> will be created. The link for the opening session room will be posted on
>> Monday. We will close the hackweek on Friday with a demo session where
>> teams will be able to show the work done during the week.
>> You can take a look at the proposed projects in
>> https://gitlab.torproject.org/tpo/community/hackweek
>> 1 Torify signal-cli with torsocks
>> Summary: Work through blocking bugs for getting signal-cli working with
>> torsocks. Interesting because signal is being blocked in some locales.
>> Lead by jnewsome and/or dgoulet
>> 2 Prometheus alerts for anti-censorship metrics
>> Summary: We have BridgeDB exporting prometheus metrics so far, and we
>> could implement this for Snowflake. It would be great if we could get
>> alerts when usage changes to notify us of possible censorship events.
>> Somewhat related, it would also be nice to get alerts when default
>> bridge usage drops off suddenly or directly connecting Tor users from
>> different regions.
>> Lead by cohosh and anarcat
>> 3 Prototype network-namespace-based torsocks
>> Summary: Use network namespaces (or maybe something else?) to run target
>> software in an environment where it can't talk to the real network; it
>> can only talk to the tor socks port and/or some "shim" adapter. Might be
>> able to remove or lessen dependence on LD_PRELOAD (which isn't available
>> everywhere, can be "escaped", and can be a bit fragile). If we continued
>> to use LD_PRELOAD could at least be used to prevent accidental
>> connections to the real network.
>> Lead by jnewsome and/or dgoulet
>> 4 Add support for UDP sockets over onion services, possibly with
>> enabling support for WebRTC in Tor Browser
>> Lead by sysrqb
>> 5 Visualize Tor metrics's data in ways that it can be useful for community
>> Summary: The goal is to have a dashboard with Tor usage per country in a
>> way that is easy to see big changes happening. Right now we need to
>> select each country to see the Tor usage. It would be good to have a way
>> to see all the countries and the onews where usage is increasing (via
>> bridge and direct connection)
>> Lead by gus and gaba
>> 6 Prototype Rust+Arti-based HTTP frontend cache for directory authorities
>> Summary: Directory authorities are under a lot of unnecessary load from
>> excessive download requests.  We have other projects in mind to reduce
>> those requests, but one workaround is to add a frontend cache in front
>> of one or more of the authorities' HTTP ports.  With this project we'll
>> write a Rust server use Arti's download and validation code to fetch
>> directory information from an authority, and expose that information via
>> a set of HTTP requests.  With luck, our code will be reuseable in the
>> future when relays or authorities are rewritten in Rust.
>> Lead by nickm
>> 7 Onionshare download accelerator
>> Summary: Journalists are requesting ways to download large files from
>> onion services faster. This is actually possible already with HTTP,
>> without any Tor client modifications. By splitting up requests into 250k
>> chunks using HTTP range requests, and using SOCKS username and password
>> to allocate these requests properly onto different circuits, we can hit
>> ~6 megabytes/sec per guard (so ~12 megabytes/sec with 2 gaurds), with a
>> custom HTTP download acelerator. This download accelerator could be
>> provided as part of onionshare. For more details, see
>> https://github.com/micahflee/onionshare/issues/1295.
>> Lead by mike
>> 8 Vanguards doc updates, bugfixes, packages for onionshare and/or Tor
>> Browser
>> Summary: The vanguards Tor control port addon provides defense against
>> Guard discovery attacks, as well as other attacks against onion
>> services, onion clients, and even Tor Browser exit traffic. Vanguards is
>> in need of some doc updates, bugfixes, and we could even package it for
>> one of onionshare or Tor Browser. Packaging it with Onionshare also
>> helps improve the security properties of the above download accelerator
>> item. See the bugtracker for specific items:
>> https://github.com/mikeperry-tor/vanguards/issues
>> Lead by mike
>> 9 Circuit Padding Simulator
>> Summary: The Tor circuit padding framework is under active use by
>> researchers to improve padding defenses against website traffic
>> fingerprinting, and onion service circuit fingerprinting. The simulator
>> is in need of update to the latest Tor release, as well as in need of
>> performance improvements, and a more accurate way to deal with
>> time-based features. See
>> https://github.com/pylls/circpad-sim/blob/master/README.md
>> Lead by mike
>> 10 Onion service v3 support for arti
>> Summary: arti currently does not do v3 onion services. Let's do some
>> solid work towards making that possible.
>> Lead by asn
>> _______________________________________________
>> tor-project mailing list
>> tor-project at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
> _______________________________________________
> tor-project mailing list
> tor-project at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x180DB06C59CABD19.asc
Type: application/pgp-keys
Size: 56735 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20210401/75e23dab/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20210401/75e23dab/attachment-0001.sig>

More information about the tor-project mailing list