January 2021 - tbb-dev - lists.torproject.org

Weekly Meeting (18 January)
by Matthew Finkel 18 Jan '21

18 Jan '21

Hi everyone, We're moving today's weekly meeting to tomorrow - same time and place as usual: 1900 UTC in #tor-meeting. See some of you there tomorrow.

1 0

About Tor Source Code
by adhith adhi007 12 Jan '21

12 Jan '21

Hi, we are a team but newbies, and we have an idea using tor features so we are wondering about source code. actually for android.like any tutorials or videos or wiki pages anything. what we want is our customers need to be using tor and maximum tor anonymity and proceed to our app (like in tor browser android not to all apps). Is there any way we can achieve this in an android app. We know android app development using android studio and Xamarin or do we need to learn any other language? help us.

2 2

Chrome's Proposed Privacy Budget?
by Sanketh Menda 05 Jan '21

05 Jan '21

Hello, #ChromeDevSummit this month hosted a talk on the privacy budget (https://youtu.be/0STgfjSA6T8) and in the talk they mentioned that they are currently running a large-scale study to identify which potentially identifying APIs sites are using and how much they are using them. This data might be really useful for us to improve the fingerprinting protections in the Tor Browser so we might want to keep an eye on the developments here. Also, I think I am finally beginning to see the brilliance in the privacy budget proposal (https://github.com/bslassey/privacy-budget) To the best of my knowledge, current mainstream browsers use some combination of hardcoded lists of companies (like the disconnect list used by Firefox's Enhanced Tracking Protection), hardcoded lists of scripts (like uBlock Origin), and heuristics (from the relatively simple Privacy Badger to the more complicated Intelligent Tracking Prevention in Safari). These approaches are oddly reminiscent of old-school signature-based AV and they don't really attack the core problem but try to identify bad scripts. For starters, as AV experience has taught us, these approaches might work for mass attacks but don't work well against targeted attacks. So these approaches, while they allow for mainstream browser-level usability, don't seem compatible with the threat model of the Tor Browser. This is where IMO the privacy budget shines. It goes straight to the problem: APIs that reveal potentially identifying information and keeps a ledger of the calls. This is more conservative than the above approaches and seems closer to the Tor Browser's current approach (which is to block or spoof the outputs of potentially identifying APIs). Of course, this comes with the same false positive issue that currently affects the Tor Browser, but hey we can't have everything. Moreover, this seems to lend itself nicely to a good affordance where the browser can easily expose to the user how much data they are leaking to the webpage and if the webpage exceeds the set budget and requests more API calls, how much more data they would expose by allowing these calls. Right now, the Tor Browser's fingerprinting protection is all-or-nothing and it might soon become per-origin all-or-nothing (see Mozilla Bug 1450398), privacy budget might be a nice next step where a user can allow access to some fingerprinting surface without potentially being completely identifiable. What do you folks think? Best, Sanketh

2 2