[tor-project] hackweek starting this Monday at 15UTC!

[Gaba]

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
> 

-------------- 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/20210329/86cc7ac1/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/20210329/86cc7ac1/attachment-0001.sig>