arthuredelstein

Typically adblockers block ads and trackers, but Privacy Magic does much more than that:

- Fingerprinting resistance: Privacy Magic hardens canvas, time zone, battery, audio, and many more APIs to block fingerprinting - Third-party cookies: all blocked by default - Tracking URL parameters: all removed - Browser Ad APIs: all disabled - Workers and iframes: Hardening is propagated to these contexts

After working for the past decade on Tor Browser, Firefox, and Brave, I wanted to see if it's possible to protect users where 90% of them already are: on Chromium-based browsers such as Chrome and Edge.

I'm happy to answer questions about tradeoffs between privacy and usability!

That is very sad news. I knew Ralph at Brave. He had such a calm, kind presence.

Project Timestamper is an open-source effort to digitially timestamp real human works of art, movies, literature, and science as they exist today, before AI-created content begins to pollute humanity's cultural heritage with false memories.

I hadn't seen that post, but it's great!

This project was largely inspired by my experience with Clojure, and my wanting to have a similar capability when writing JS code.

hakk is a new REPL-based tool for developing Node.js programs. hakk runs your .js source files, and updates your program as it runs whenever you make a change. Unlike the built-in node repl, hakk lets you re-define consts, functions, and class members while your code is running. It works with any code editor.

I would love to get feedback. Do you find this tool useful? What improvements would you like to see?

Hi! Author of PrivacyTests.org here. Thank you very much for the comment. (I only just saw your reply.) PrivacyTests is very much a work in progress, and all feedback is much appreciated.

GPC does differ from Do Not Track in that the former is intended to carry the weight of law. See for example: https://cheq.ai/blog/what-is-a-global-privacy-control/

Regarding document.referrer, you are absolutely right that there is a cost/reward balance and most browsers have chosen to allow cross-site passing of the referrer. However, there are browsers on Android that do block cross-site referrer altogether (see https://privacytests.org/android.html).

"Media queries" refers to the fingerprinting threat where, for example, screen width and height is divulged. You are right that JavaScript can also be easily used to get screen width and height: any fingerprinting resistance feature should protect against screen fingerprinting via both JS and media queries, in my view. Some browsers already do that, as the results show.

Your question about scale is a good one. Some browsers (such as Firefox and Brave) embed fairly large blocklists. You are right that query parameters can be changed, but in practice I haven't seen any cases of that happening (yet).

As far as I am aware, Safari is (by default) blocking cookies/storage from Google Analytics and similar trackers, but not blocking the scripts themselves. You can see that cookie blocking reflected in the "Tracking cookie protection tests".

Total Cookie Protection partitions all cookie-like data ("state") between the websites you visit, not just cookies. For a technical discussion, see https://developer.mozilla.org/en-US/docs/Web/Privacy/State_P...

You can see which browsers partition state (and which don't) in the State Partitioning section of https://privacytests.org. Firefox passes nearly all of those tests because Total Cookie Protection is enabled by default.

Let's Encrypt is incredible. Thank you!

Hi -- I'm the maintainer of privacytests.org. To be clear, most of these tests were built before I applied to work for Brave. And I am committed to keeping the tests impartial.

I do hope to include telemetry tests in the future.

> Oh ok. That does make sense. Hopefully you read my comment as feedback and not super negative.

It was helpful feedback. I value all critiques because they help me make the site better.

> Just some verbiage on each test would be wonderful.

There is some explanation for each test, if you click on the test name. But it's clear I need to expand those explanations and also make them easier to find.

Hi -- thanks for the comments!

> it would be very helpful if the table of test results were furnished with a glossary that:

There is some explanation for each test -- to see these explanations, you need to click on category titles, test titles, or test results themselves. But I take your point that these annotations need to be expanded and easier to find.

> I tried to send feedback to this effect but could not as I'm not a Twitter user (it seemingly being the only of sending feedback to PrivacyTests.org).

Actually in the upper-right corner of each page there is a link to an email address for feedback (contact@privacytests.org). And github issues are also welcome. I gather these links could be made more clear. :)

> I was rather surprised to see how poorly Tor featured in the tracking department, it failing every test.

The tracking content section results actually stem from Tor Browser's approach: Tor Browser currently does not block any third-party content from loading in a page. Rather it prevents tracking by various policies, including always using the Tor network, providing full state partitioning, and providing strong fingerprinting resistance. Generally speaking, third-party trackers are prevented from tracking users by these measures. However, I think blocking of trackers could offer defense in depth in Tor Browser, in case any of the other measures fails.

Thank you for the feedback!

Granted, blocklists (lists of tracking domains or URL query parameters) can be circumvented by a determined attacker. Indeed, I agree that blocklists aren't sufficient on their own for a browser to provide solid privacy protection. In my view it's critical, primarily, to have policies that enforce privacy, including such protections as state partitioning and fingerprinting resistance. That's exactly why I included tests for such policies.

However: I do think blocklists provide substantial, though incomplete, privacy protection in practice. And, importantly, blocklists are enforced by a number of popular browsers (Brave, DuckDuckGo, Firefox Private Mode, Firefox Focus) and popular browser extensions and other services (uBlock, ClearURLs, DuckDuckGo Privacy Essentials, Disconnect, etc.). These blocklists seem to work pretty well, at least judging by the ad-free experience they provide. So I felt that to give a more complete picture I should test for blocking.

I tried to avoid cherry picking query parameters or blockers. Here's how I arrived at the current selections for these two sections:

* Tracking query parameter tests: I tried to gather all the query parameters I could find; the list on the page was my full list at the time. (If there are suggestions for more parameters, I will be happy to add them.)

* Tracker content blocking tests: I used the list of the top 20 tracking entities from https://whotracks.me. These are, roughly speaking, 20 of the most widespread third-party tracking domains on the web -- they should be a high priority for any browser respecting privacy, in my opinion. I hope testing for blocking of these 20 serves to gives a sense of each browser's approach to third-party tracking scripts and pixels.

Agreed -- in the future I'm hoping to have a page showing results with browsers with various privacy-helpful extensions installed.

Thank you for the feedback -- I agree more context and explanation is needed for each of these tests.

In the Blob case: the test code is storing a unique string in a Blob URL under one website (first party), and then attempting to read back that string under a second, different website. (See "result, different first party".) If the string is accessible under a different first party, then it is possible to use a Blob URL to track a user between two different websites.

The main "engine" is here: https://searchfox.org/mozilla-central/source/browser/extensi...

The shims are here: https://searchfox.org/mozilla-central/source/browser/extensi...

And the config file for how they are used is here: https://searchfox.org/mozilla-central/source/browser/extensi...

The Tor Project | Seattle, WA | Android Engineers | Remote | Full Time

https://www.torproject.org/about/jobs.html.en

The Tor Project is looking for two browser developers for Mobile (Android) and one Android OS developer. These engineers will work with the rest of the Tor Browser team to develop a full-featured Tor Browser Android version.

I wonder how this will work with self-driving cars. Making eye contact is not an option.

Do you have a link to this? I couldn't find it.

I think nothing in the US Constitution prohibits states from electing their members to the federal House of Representatives by a proportional representation method. For example, California has 53 representatives, and these could be elected not in 53 separate districts, but instead in a single state-wide election.

Making this change would require action by a state's legislature, and likely changes to federal law as well, but no federal constitutional amendment is needed.

I think it's highly germane to discuss alternative election systems in a discussion on fighting gerrymandering.

Maybe this is an opportunity for a startup -- steal Netflix's DVD rent by mail business and offer a very extensive catalog. Seems like Netflix would be happy to cede that market.

I first learned about destructuring through Clojure. Lately I've been working on a Firefox extension and discovered that Firefox JavaScript 1.6 supports destructuring (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), too, and is very pleasant to use. I hope it makes it into the ECMAScript 6 standard.

According to the chart, RIPEMD-160 is deprecated. Does anyone know of a citation?

One thing I learned from the experience of losing a family member to cancer is that doctors aren't all that smart or careful oftentimes. I encourage you and your friend to learn as much as possible, and get a variety of opinions. Stay away from pseudoscience, but don't assume doctors have thought of everything or are up to date on the science. Wikipedia and Google Scholar are good places to start.

You don't find large-scale Clojure projects, because Clojure is very concise.

> Having a growth team is still a good idea--you almost always need to jumpstart things. But don't forget about what you actually have to accomplish.

Maybe it's better not to jumpstart things. One strategy could be to fail faster by purposely not marketing, to quickly find out whether a product is intrinsically viral.

The spoke has been cut (by design) and the shaft passer sits at the cut, where the shaft passes through it. It cleverly does this "airlock-like" without falling apart and letting the two halves of the spoke separate. Similarly, the topoisomerase, after cutting the "spoke" DNA, becomes covalently bound to each side of the cut. Then the "shaft" DNA passes through the topoisomerase, without the topoisomerase falling apart or letting the two sides of the "spoke" DNA drift apart. Multiple "shaft" strands can pass before the "spoke" strand is religated and the enzyme detaches. So I think the principle is quite analogous.

A similar trick is done by Type II topoisomerases, which are molecular machines found in just about every living cell. Type II topoisomerases pass one piece of DNA through another. See https://en.wikipedia.org/wiki/Topoisomerase_II

Very cool. I would love to see immutable, persistent data collections as offered in Clojure.

If the latest Greenwald/Schneier revelations are true, then the past 5 years of TLS have underwhelming to say the least, so I don't see what advantage has been obtained from diversity.

Going forward, how are site admins to know what ciphersuite to use? This needs to be made very clear. And how are web users to know what the green lock in their browser means, if it can mean anything at all? The current state of affairs is incomprehensible to all but a very few.

There needs to be a big public debate about what ciphersuite is the best. And there should be very careful scrutiny of the implementation. Choosing ciphersuite(s) is a political as well as a technical problem -- the goals should be as clear and simple as possible.

Why not adopt the goal of deprecating all ciphersuites but one? Let's have a debate about the best ciphersuite and settle on a single one. That would decrease the attack surface and would allow the crypto community to focus on getting the implementation bug free. It would also give attackers a tighter focus, so we'd better pick the right ciphersuite! To Brian Smith's list of criteria, I would add implementation simplicity as a very important requirement.