groovecoder

Populism isn’t just bad elites or gullible masses. It’s what happens when both sides lose the virtues that once held them together. Elites forget humility and justice, turning reason into arrogance; populists forget prudence and temperance, turning righteous anger into resentment.

HN itself is a kind of popu-elitism. Look at the other comments here. We're a crowd of self-identified “slow thinkers” who often post fast, intuitive reactions. The irony is that our intuitions here are shaped by analytic habits, not moral ones.

The real goal isn’t to think faster or slower, but to build a society that makes a virtuous life first possible, and then easy.

Do you know which will happen first? Specifically, will the court put forth its remedies before the appeals begin? Or will those actions happen in parallel? Or what?

Containers?

Look I don't have any reason to praise Twitter, but ...

This "Twitter-scale mastadon implementation" is when my red flags went up. It's meant to demonstrate a simpler and more performant architecture, but it actually demonstrates "things you should never do" #1: rewrite the code from scratch.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

"The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed."

The "1M lines of code" and "~200 person-years" of Twitter being trashed on in this article is the outcome of Twitter doing the most important thing that software should do: deliver value to people. Millions of people (real people, not 100M bots) suffered thru YEARS of the fail-whale because Twitter's software gave them value.

This software has only delivered some artificial numbers in a completely made-up false comparison. Okay it's built on "fundamentally better abstractions", but until it's running for people in the real world, that's all it is: abstract.

Please don't tout this as a demonstration of how to re-create all of Twitter with simpler and more performant back-end architecture.

I assume this means you have an MX record at example.com pointing to your/mailbox.org SMTP server? AIUI, a sending MTA will look up the MX record for example.com by preference order and will deliver emails to the first server that accepts the connection.

So it may depend if you can configure your mailbox.org account/server to reject connections from servers trying to send mail to unknown addresses? Then the sending MTA server might "fail over" to the Relay server instead?

Oh interesting. Do you mind filing an issue for what you have in mind here?

https://github.com/mozilla/fx-private-relay/issues/new

FWIW, when you get a Relay number, we text you a contact card for it, so you can save it into your phone's contacts app.

Yeah, "Bring your own domain" is a super cool feature idea. We could even re-use Acme HTTP-01 or DNS-01 challenges to verify the domain.

(Mozilla Privacy & Security ENGR) Stay tuned ... :)

This was the part I latched onto in Moxie's piece too: "A protocol moves much more slowly than a platform. After 30+ years, email is still unencrypted; meanwhile WhatsApp went from unencrypted to full e2ee in a year. People are still trying to standardize sharing a video reliably over IRC; meanwhile, Slack lets you create custom reaction emoji based on your face."

In the Firefox OS days here at Mozilla, I was a huge believer and advocate for our desire to push web protocols & standards into mobile. But as it turns out, proprietary walled-garden mobile platforms move faster than web standards - who knew?!

But, I like the phrase you used - "hoping for an inefficient market". At this point in my tech career and looking around at what the tech market is doing in the world, I think slowing down and getting less efficient might be good for us?

Thanks for reporting it! Nothing like an influx of new users (and now premium customers!) to re-light some fire under a bug! We'll work on it.

Howdy. I'm an engineer on both Facebook Container and Relay.

We fixed the original bug in Facebook Container that was showing the prompt on every website - now it only shows the prompt on websites where Facebook trackers are detected.

Facebook Container is something that inspired and influenced the development of Relay in the first place. Facebook Container users reported that they used websites and still saw ads from those websites in their Facebook feed, even though they were using Facebook Container. Because Facebook lets anyone create custom audiences for re-targeting, we need to give users a way to protect themselves from "back end" data sharing & tracking.

(https://www.facebook.com/business/help/744354708981227?id=24...)

Howdy, relay engineer here.

The random aliases at mozmail.com are certainly the most private option. The subdomain aliases are for convenience so you can make up any alias you want even if you don't have a device on you. (e.g., checking into a hotel, etc.)

As you say - there's always trade-offs involved.

(Tech lead of Relay here)

Thanks for the detail! We'll look into this. We definitely want to maximize deliverability.

We sent them a pull request to remove mozmail.com now that the aliases should be "safe"r for relying parties to accept.

upvotes maybe?

https://github.com/disposable/disposable-email-domains/pull/...

Can you file that here so I don't forget?

https://github.com/mozilla/fx-private-relay

(Relay tech lead)

Oops, thanks for catching that. We'll add a LICENSE file.

(Relay tech lead here)

Yeah, the all_urls add-ons are always concerning. We have an issue filed to move that to optional_permissions instead, but need to get the UX right:

https://github.com/mozilla/fx-private-relay/issues/252

(Relay tech lead here)

It's in the privacy policy (https://www.mozilla.org/en-US/privacy/firefox-relay/), but yes - the emails are sent thru Amazon SES in plaintext.

We have kicked around the idea of enabling + preserving E2EE emails thru Relay, but ... it's tricky.

https://github.com/mozilla/fx-private-relay/issues/360

Howdy. I'm the tech lead on Relay. We're working on replies right now:

https://github.com/mozilla/fx-private-relay/pull/770

Note: we have an update coming that includes a "Limit to Designated Sites" feature in the base Multi-Account Containers extension: https://github.com/mozilla/multi-account-containers/pull/165...

psst ... check out https://monitor.firefox.com/protect-my-email

M-A-C dev here ...

We're actually pretty deep into the work of adding sync to M-A-C. https://github.com/mozilla/multi-account-containers/pull/161...

Predictably, synchronizing data is complicated, so it's taking a while and we're trying to do it in a way that doesn't destroy any existing data. So we'll be doing some heavy internal testing on it before we release it.

But it's definitely coming.

It's pretty verbose and lengthy, but I recently read the NIST "Trustworthy Email" publication and it did a great job explaining these technologies - Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain Message Authentication, Reporting, and Conformance (DMARC) - that are used for modern email authentication.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S... (PDF obv.)

Opinion article; is thinly-veiled content-marketing piece for an AI cybersecurity company.

I found the statements about PII uploaded by advertisers confusing. The authors say “PII uploaded by advertisers to target customers via custom audiences” was NOT found “being used for advertising” but the whole point of uploading PII into custom audiences is to target them for advertising.

You have to read the details later, where they uploaded 2 different pieces of PII for a customer - one already associated with a FB user, and therefore targetable. The other was brand new PII. Only the latter was not found to be targetable.

So yay - Facebook doesn’t use rainbow table lookups to extract plaintext PII from hashes that advertisers upload. Gold star for them.

Answered here: https://news.ycombinator.com/item?id=20465981