jerheinze

This has been a solved problem since 2016: https://signal.org/blog/reproducible-android/

The Signal app can be used as a honeypot to plant a pseudo-secure messenger

Given its open source nature that would be exceedingly difficult.

The Tor network was deemed the culprit of anonymity and secure connections not long ago. We all know how it went.

What are you talking about? Tor is still the uncontested king of low-latency anonymity networks.

https://annas-archive.org/torrents#ia

Run a snowflake-proxy instance to help censored users access the Tor network (To be clear: no traffic exits from your IP, you're just relaying that traffic to a bridge that then connects to the Tor network): https://community.torproject.org/relay/setup/snowflake/stand...

For more information on Snowflake check: https://snowflake.torproject.org/

BookMyName.com, just look at their interface! ;)

You still haven't made any clear case against them. Why even stick with v2 onions in the first place?

How was the deprecation of v2 onions in any form or shape "early"?

This is one of the main reasons why I keep using Tor daily. The more people use Tor for normal browsing, the less interesting it becomes to be a Tor user, the better the anonymity for everyone else.

You can use pluggable transports to camouflage your traffic (they're already built into the Tor Browser, e.g. snowflake, obfs4 ...).

Here's one that is "production" ready: the Mirage-Firewall microkernel built using MirageOS and running on Qubes OS.[0] In general MirageOS allows you to:

... construct unikernels for secure, high-performance network applications across a variety of cloud computing and mobile platforms. Code can be developed on a normal OS such as Linux or macOS, and then compiled into a fully-standalone, specialised unikernel that runs under a Xen or KVM hypervisor.[1]

[0] https://github.com/mirage/qubes-mirage-firewall

[1] https://mirageos.org/

Not that explicitly, but many warned about Google abusing their power if it started hitting their profits.

It's not like no one was making warnings about this.

You can help by running a Snowflake proxy (which merely functions as a gateway to the Tor Network, so you don't need to worry as no traffic exits from your IP) if you're in a country that doesn't censor Tor. You can either run the standalone Snowflake proxy:

https://community.torproject.org/relay/setup/snowflake/stand...

Or by installing the browser addon: https://snowflake.torproject.org

Hearing these pleas, the Internet Archive proposed temporarily lifting the technical controls enforcing its one-to-one ratio. Since all of the libraries were closed, the Internet Archive reasoned, there were surely more non-circulating copies locked up in shuttered libraries than would be borrowed via the Internet Archive even without those technical controls in place.

https://www.eff.org/files/2022/07/07/hachette_v._internet_ar...

I don't think this is the most solid argument, but I really hope that line of thinking is deemed sufficient for not loosing in this legal case.

This has been eloquently addressed by Tor veteran Mike Perry:[1]

Concerns about Javascript are rooted in two avenues:

1. Fingerprinting concerns.

2. Zero-day exploits against Firefox.

The reason we feel that leaving Javascript enabled trumps these concerns is:

1. We want enough people to actually use Tor Browser such that it becomes less interesting that you're a Tor user. We have plenty of academic research and mathematical proofs that tell us quite clearly that the more people use Tor, the better the privacy, anonymity, and traffic analysis resistance properties will become.

In fact, my personal goal is to grab the entire "Do Not Track" userbase from Mozilla. That userbase is probably well in excess of 12.5 million people: http://www.techworld.com.au/article/400248/

I do not believe we can capture that userbase if we ship a JS-disabled-by-default browser.

2. Exploitable vulnerabilities can be anywhere in the browser, not just in the JS interpreter. We disable and/or click-to-play the known major vectors, but the best solutions here are providing bug bounties (Mozilla does this; we should too, if we had any money) and sandboxing systems (Seatbelt, AppArmor, SELinux).

[1] https://lists.torproject.org/pipermail/tor-talk/2012-May/024...

Thanks, corrected.

This is deeply misleading and based on old data.

A reminder that Tor Browser might be one of the least safe browsers you can run: it's a fork of Firefox, meaning that its maintainers have to coordinate and port patches from the mainline project.

Tor Browser ships updates as soon as new ESR versions come out.

Firefox is already not one of the most hardened browser engines.

That might've been true in the past, it's hard to argue for it now.

Meanwhile, the fork you'll be running is specifically designed to hide sensitive traffic, and collapses all those users into a single version for exploits to target.

The overwhelming majority of exit traffic now is using HTTPS and Tor Browser ships with HTTPS Everywhere to avoid SSL Striping attacks (in fact the next version of the Tor Browser will have the HTTPS-Only mode enabled by default, it's already being tested in the alpha release), so how will those evil exit node burn those exploits?

I'm ambivalent about Tor, but if you're using Tor, don't use the Browser Bundle.

First off, the "Tor Browser Bundle" is a deprecated name. If you're not using the Tor Browser you're making yourself both insecure (it ships with a smaller attack surface, no WebGL for example) and fingerprintable defeating thus the full privacy advantages of the Tor Browser. There is simply no other alternative.

You can read the Tor Browser design documentation (though old) to get a rough sketch of what it's trying--and what it's not trying--to achieve: https://2019.www.torproject.org/projects/torbrowser/design/

Further reading in case you think VPNs are the solution: https://matt.traudt.xyz/posts/2019-10-17-you-want-tor-browse...

The article stresses that if you reduce too much for the distant vision then you will have too much blur which will only lead to blur adaptation, and won't yield any improvements.

The problem with LASIK is that it doesn't address the root of the problem which is that the eyeball gets longer, it only works as if someone carved glasses on your cornea. So you might still get the negative consequences of having a longer eyeball after it.

But, as far as I know, eyeball never shorten.

There are many anecdotal reports about people seeing shorter eyeballs as measured by an autorefractor while doing the reduced lens method, one example that I recall is this one from cliffgnu[1].

For LASIK the real thing that isn't communicated is that it doesn't address the root of the problem which is that the eyeball gets longer, it only works as if someone carved glasses on your cornea.

[1] https://www.youtube.com/watch?v=efsgkBHaTlI

Have you tried snowflake instead?

Running a Tor snowflake[1] 'bridge' is now as easy as installing an addon and forgetting about it:

https://addons.mozilla.org/en-US/firefox/addon/torproject-sn...

https://chrome.google.com/webstore/detail/snowflake/mafpmfcc...

[1] https://snowflake.torproject.org/

Might be a good time to list some Discord alternatives:

* Revolt - FOSS and self-hostable, still a long time before reaching feature parity https://github.com/revoltchat

* Guilded.gg - closed source alternative https://www.guilded.gg/

In case the link doesn't work for some reason switch to another Invidious instance: https://redirect.invidious.io/watch?v=Xo7V4PPHijs

How will that help a person reach a website that's blocked in their country?

Remember you have to leave a tab open for it to work

Better yet just install the Snowflake addon (available for both Firefox and Chrome), so it becomes more of a set-and-forget thing.

A mobile browser addon would be less than ideal since you'd want the client to stay running in the background and since not everyone uses Firefox. The Guardian Project is working on implementing that standalone proxy server approach directly into Orbot: https://github.com/guardianproject/orbot/issues?q=is%3Aissue...

FWIW there's another method for bootstrapping Snowflake that uses Google's AMP cache: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-...

For context: https://teddit.net/r/DataHoarder/comments/rhttac/with_reddit...

Does an attacker only need to control the guard and exit nodes, or the middle relay node(s) as well?

No, only controlling the guard and exit nodes is necessary.

If the latter, can you configure Tor to use more than one middle relay node, depending on your threat model?

Tor makes dozens of circuits in a typical use. You never stick to a single circuit. In the Tor Browser you have first party stream isolation so you get a different circuit (and hence different middle and exit nodes) for each first party domain that you visit.