progval

None, as far as I know. But it doesn't seem like Meta's stance changed either.

Matrix/Element wrote more on the issue than what is referenced in the article: https://matrix.org/blog/2024/09/whatsapp-dma/

> No protocol in the world can force anyone to delete anything from their own device.

But they either do not sign the messages or allow repudiating the signatures. Matrix signs all events forever.

Matrix also makes the entire event history (minus message content depending on room configuration) available to servers on join, even if that server's users are not allowed to see it.

What makes you think they are going to be more power-hungry than if Apple manufactured them itself?

The pure Python code in the last example is more verbose than it needs to be.

    groups = {}
    for row in filtered:
        key = (row['species'], row['island'])
        if key not in groups:
            groups[key] = []
        groups[key].append(row['body_mass_g'])

can be rewritten as:

    groups = collections.defaultdict(list)
    for row in filtered:
        groups[(row['species'], row['island'])].append(row['body_mass_g'])

and

    variance = sum((x - mean) ** 2 for x in values) / (n - 1)
    std_dev = math.sqrt(variance)

as:

    std_dev = statistics.stddev(values)

These are only available on the Ultimate tier. If (like me) you don't care about the LLMs then there is no reason to be on the Ultimate tier so you don't pay for it.

The author of the tweet you linked prompted Claude with this:

> Read this attached paper from Anthropic on a "AI-orchestrated cyber espionage campaign" they claimed was "conducted by a Chinese state-sponsored group."

> Is there any evidence or proof whatsoever in the paper that it was indeed conducted by a Chinese state-sponsored group? Answer by yes or no and then elaborate

which has inherent bias indicated to Claude the author expects the report to be bullshit.

If I ask Claude with this prompt that shows bias toward belief in the report:

> Read this attached paper from Anthropic on a "AI-orchestrated cyber espionage campaign" that was conducted by a Chinese state-sponsored group.

> Is there any reason to doubt the paper's conclusion that it was conducted by a Chinese state-sponsored group? Answer by yes or no.

then Claude mostly indulges my perceived bias: https://claude.ai/share/b3c8f4ca-3631-45d2-9b9f-1a947209bc29

Neither the EU nor American companies are Congress, so they are not bound by the 1st amendment.

There is: https://adstransparency.google.com/

Heh. I have a 30-nodes Tinc network over the internet but some hosts are behind a NAT. It keeps randomly losing routes between these nodes. It even has the infuriating behavior that often it loses the route a few seconds after I successfully established a SSH connection.

Also, traffic seems to be decrypted and re-encrypted by relaying nodes. For end-to-end encryption, you need "ExperimentalProtocol = yes" added by Tinc 1.1, which was never formally released.

I'd like to rewrite something like it in a language I'm familiar with (perhaps based on cjdns' protocol which is better documented than Tinc's) but it's not easy.

> This attack already exists in several forms (leaking a TLS private key, DNS hijack, CA validation attack, etc).

An attacker who gets the TLS private key of a website can't use it easily, because they still need to fool users' browser into connecting to a server they control as the victim domain, which brings us to:

> You could tack a DNS name onto the crypto-cookies if you wanted to, but DNS is trivial to attack.

It's not. I can think of two ways to attack the DNS. Either 1. control or MITM of the victim's authoritative DNS server or 2. poison users' DNS cache.

Control/MITM of the authoritative server is not an option for everyone (only ISPs/backbone operators), and according to Cloudflare: "DNS poisoning attacks are not easy" (https://www.cloudflare.com/learning/dns/dns-cache-poisoning/)

> Requests are already slowed down by the gigantic amount of cookies constantly being pushed by default

Yes, although adding more data and adding a round-trip have different impacts (high-bandwidth high-latency connections exist). Lots of cookies and more round-trips is always worse than lots of cookies and a fewer round-trips.

> The server can send a reply-header once which will tell the client which URLs need cookies perpetually, and the client can store that and choose whether it sends the cookies repeatedly or just when requested.

Everyone hate configuring cache, so in most cases site operators will leave it to a default "send everything", and we're back to square one.

> No change is needed.

I was thinking that servers need to remember state between the initial client request and when the client sends an other request with the cookies. But on second thought that's indeed not necessary.

> So the engine of modern commerce is just a collection of easy hacks. Fantastic.

I'm afraid so

While that's pretty convenient, I'm worried about what happens when the vendor shuts down the website. "Ugly broken vendor tools" can be run forever in a VM of an old system, but a website would be gone forever unless it's purely client-side and someone archived it.

> They should be tied to cryptographic keypairs (client + server).

So now, if a website leaks its private key, attackers can exfiltrate cookies from all of its users just by making them open an attacker-controlled link, for as long as the cookie lives (and users don't visit the website to get the rotated key).

> If the web server needs a cookie, it should request one

This adds a round-trip, which slows down the website on slow connections.

> the client can submit again to "reply" to this "request"

This requires significantly overhauling HTTP and load-balancers. The public-suffix list exists because it's an easy workaround that didn't take a decade to specify and implement.

If you want more of this: https://www.youtube.com/watch?v=Y65FRxE7uMc . You can skip to 7:45 if the long intro bores you, but it's worth listening to it.

How is that different from what the article documents?

It's indeed not a good one. Discord refined instant messaging and bolts other things on top like forums but isn't fundamentally different. Google Wave was (and still is) a completely different paradigm. Everything was natively collaborative: it mixed instant messaging with document edition (like Google Docs or pads) and any widget you could think of (polls, calendars, playing music, drawing, ...) could be added by users through sandboxed Javascript. The current closest I can think of is DeltaChat's webxdc.

Do you have examples of lies that the majority was indoctrinated to believe?

For what it's worth, you can already do: x = retry(3)(failure_prone_call)(y)

But that's not end-to-end encryption, that's a pastebin with a login

"send end-to-end encrypted (E2EE) emails to anyone, even if the recipient uses a different email provider" but the video shows Gmail asking the recipient to authenticate. How does that work? If a Gmail user sends an email to my self-hosted server, there is nowhere to authenticate me to.

And it means either Gmail or the actual email stores decryption keys, so what is the threat model in which E2EE is useful here?

The only "advantage" I see is that now recipients must manually archive these "encrypted" emails if they want to keep access to them in the future (so most of them won't). That would be consistent with Google's strategy with AMP's editable emails.

> - They got rid of the heavyweight compression and just stuck with the Delta/Dictionary/RLE stuff. Heavyweight compression never did anything anyway, and was super annoying to implement, and basically required you to pull in 20 dependencies.

"Heavyweight compression" as in zstd and brotli? That's very useful for columns of non-repeated strings. I get compression ratios in the order of 1% on some of those columns, because they are mostly ASCII and have lots of common substrings.

I love that the two replies to this comment are: "this definition matches no technology in existence" and "So, like my coffee maker?"

Then don't put anything on the root domain and use www.paypal.com for the main operations. corp.paypal.com's cookies are separated from www.paypal.com's.

> who wants to reach the point where you find that out?

Enough people to steal 20 billion USD a year according to https://stripe.com/en-fr/resources/more/chargeback-fraud-101

I don't know what to make of it. The author looks prolific in the field of ML, with 8 published articles (and 3 preprints) in 2025, but only one on LLMs specficially. https://scholar.google.com/citations?hl=en&user=AB5z_AkAAAAJ...

You need to spend a lot of time looking through badly labeled offers, and be willing to buy from sellers with no reputation.

> 2. U2F/Webauthn key as second factor is phishing-proof. TOTP is not.

TOTP doesn't need to be phishing-proof if you use a password manager integrated with the browser, though.

It depends on how you identify a timezone. If you use an IANA identifier then short of a war it's pretty safe that the place of the appointment will use the same IANA timezone; because those follow changes in DST rules and even changes in offsets.

> Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow.

Not that in invalidates your overall point, but in that case the TZ database would create a new timezone (eg. named Europe/Dnipro) to reflect that from 1996 to 2030 it was UTC+2/UTC+3 (with EU DST rules); then switched to UTC+3 only.

This reflects that there is a place whose rules changed on 2030. Places don't move to an other existing timezone because that would prevent reasoning about past datetimes.

It is not computer-friendly because the timezone is unspecified. And in some timezones, it is ambiguous during changes from DST to winter time.