resist1984 @resist1984@social.privacytools.io

@jalvarez @themactep@fosstodon.org

I suggest creating a forwarding account at one of these services:

* 33mail.com
* erine.email
* anonaddy.com
* simplelogin.eu
* burnermail.io

and create an email account that you share with no one except one of the services above. Then you can create countless aliases. If you're involved with 100 different unrelated activities, you can have a different address for each w/out the burden of managing 100 email accounts.

@hypolite The thing you should take away from the analogy is to reject the idea that a use case is somehow inferior when it doesn't match original intent. Original intent is irrelevant. In the case of Super Glue, the derivative use case is actually *better* than the intended design.

@hypolite Indeed, crypto doesn't remove the need for trust in all situations. But it does remove the need for trust in many cases, and that's a *good thing*. Whenever you can remove trust in a systim, it's /beneficial/ to do so. My thesis is the opposite of the authors.

@hypolite If you don't like the magnetron example, I'll give a super glue example. Super glue was designed to seal off open wounds in the battlefield, to replace stitches. It turns out the toxicity made it bad for what it was designed for. But it was discovered that it was great for gluing housohold items.. a purpose that it wasn't designed for. We don't reject Super Glue simply because it's not being used for what it was designed.

@hypolite Ah, I've read that article. It came out shortly after an over reaction to a flaw was discovered (and fixed) in a couple particular PGP implementations. It's FUD. The premise is the same as what you mentioned ("this wasn't designed for that"). A lot of innovations are derivatives of other wildly different innovations. You don't say microwaves are bad for cooking food b/c they were meant to be radars.

@hypolite If you look at the 10k foot view of my point, you need not accept PGP email. That example muddied the waters. I could have more simply stated: we don't discard encryption in favor of trusting those who see the payload. It's better to use encrytion because it removes some componts of needed trust. I see no case for increasing the need for trust.

@hypolite @jsparknz @aral #Hushmail came close enough to solving the social problem. A novice can open a HM acct as easily as a Yahoo acct. An external expert user can do all the key management on hushtools.com. And for me that worked. I was able to get accountants & lawyers to use crypto effectively. Novice-to-novice => HM-to-HM. BTW, the latacora.micro.blog link is dead for me.

@aral @jsparknz @hypolite When you realize the separation of duties, that email is a means to get data from A to B & crypto serves to mitigate disclosure, then of course email /can/ be used to move a payload without disclosure. It doesn't matter that email predates PGP. PGP over email is cumbersome for many novices with some implementations, but there are exceptions, but this is red herring territory.

@hypolite @jsparknz @aral I fully reject the "this wasn't meant for that" line of reasoning. Magnetrons were meant for radar not microwave ovens, but one day someone realised magnatrons can be used to cook food. We don't reject a usa case because it doesn't match original intent.

Apparently the #Canada border policy doesn't care if travelers have been vaccinated for #covid19. It's essential business only, and quarantine required. Why haven't they worked out that proof of vaccination would make someone nearly risk-free, regardless of whether it's essential?

@mesh4545 If you want to interact with #Mastodon through an IRC client of your choosing, there is a #bitlbee plugin for Mastodon.

@jsparknz @aral He gives zero support for his thesis. Of course the best case is absence of need for trust. Trust /is/ risk. There's nothing favorable about that. If you must trust, then lots of factors come into play and turn a straight-forward decision into a fuzzy one. It's better for your email payload to be PGP-encrypted so you don't need trust vs hoping the MitMs don't exploit.

@QuickSticks @feditips that's a #CloudFlare site. I suggest this link instead: https://web.archive.org/web/20210316185239/docs.joinmastodon.org/

@mesh4545 the DNS is a separate matter than the reverse proxy. But that still sounds like bad advice. #CloudFlare is not trustworthy and you wouldn't want them to be able to keep track of your DNS resolutions.

#VaccineFinder.org is blocking Tor by printing "We’re sorry, the website is temporarily unavailable now. Please try again later" every single attempt, without even the courtesy of saying something like Tor access not allowed. Vaccine info should be public. Someone plz scrape that site & liberate the #covid19 data from walled gardens

@mesh4545 If you want a mainstream addon there is #CloudFirewall which simply blocks tech giants: https://web.archive.org/web/20210215185858/gitlab.com/gkrishnaks/cloud-firewall You get switches to toggle whether to block #CloudFlare, #Amazon, #Microsoft, etc. I've noticed that it has false negatives though. And it's a bit embarrassing that the repo for the app is a CF site: #Gitlab.com

@mesh4545 BTW, Ss is the top most privacy-respecting search engine I've ever encountered. It hides #CloudFlare search results at the bottom. And tor-hostile or dodgy in some way have a red strikethrough and a red cop car light.

@mesh4545 ismitmlinkFX is an addon for #Firefox that will tag dodgy CF / anti-tor links on the page you are viewing, so you know even before you click if it's a #CloudFlare site. You can see the effect of it if you do a search on Ss (https://sercxi.nnpaefp7pkadbxxkhz2agtbv2a4g5sgo2fbmv3i7czaua354334uqqad.onion/)