jcgl

Yes, I know you're aware of them :) And maybe I'm splitting hair here--I agree with you that Signal isn't as robust wrt anonymity as, e.g. Tor.

Signal explicitly considers anonymity/a private social graph to be a design goal. Their documented considerations of things like sealed sender and use of Intel SGX's remote attestation clearly demonstrate this.

Yes, these measures are imperfect. Like you say, it's a centralized service and has weaker anonymization properties because of that. However, because of its design, to de-anonymize Signal users requires the server operator to do continual, non-trivial work as long as they want to de-anonymize users.

In other words, deanonymization attacks against Signal users works just like any other kind of attack: the question isn't whether it can be done, but whether the attacker has the resources to do it. Presumably you'd consider Tor to be an anonymity tool. Yet, even though they're distributed, deanonymization attacks against certain users can succeed, given enough resources. (I don't mean to imply that Signal is equally resistant as Tor!)

Note: big fan of the work you all are doing at Amutable! I'm following the news eagerly. Best of luck!

One of the goals of Signal is that they do not know who is talking to whom. Sealed sender and all that. This can possibly break down in certain scenarios with some server-side correlation. But they certainly do have a design goal that the social graph is entirely private.

I presume though that the mentioned fix only installs the terming for the user, rather than system-wide. I don’t see how that’d be rude (assuming it’s some non-root user that you should reasonably be considered to have control over).

Exactly. What factors limited tech debt before? Mostly two things, I’d guess: velocity, and Good Practice. And I’d guess that the former plays at least as large a role as the latter. So if you then unconstrain velocity, you’ve likely done a lot to unconstrain tech debt.

I remember RHEL being quite slow with copyfail as well. It'd be nice to have some more comprehensive statistics though.

And I don't put a lot of faith in container scans as a metrics. (More properly, I don't have faith in most containers scanners to properly identify package versions and backports.)

Good example. There is simply a long tail of things that are valuable to static sites that HTML can't/won't provide. Some other examples from my simple blog:

- Using buttons/links to seek to specific times in a <video>

- Localizing dates

- Expanding/collapsing sets of comments

Sure, for the most static of static sites. But without JavaScript you can’t even do basic things client-side, such as having some variable-length list of fields in a form. Or customized field validation.

If such client-side behavior counts as “basically an application,” then “applications” is a larger set than seems useful.

No, but my point that was AI coding changed the balance of a system such that a previously useful heuristic no longer works.

But most bad developers were likely not making a fully-featured, useful mail client. Creating such a mail client was a proof of work, if you will.

In addition to what the other commenters say about electricity generation, heat pumps are more than 100% efficient. So using an incandescent bulb as a resistive heater loses there too.

> TPM signatures are only useful for verifying the state of your own computers, and only because you control when and how the upgrades happen. And by “you” I really mean large enterprises with tens of thousands of computers (both real and virtual) to manage and a dedicated staff to keep track of everything.

Yes! And part of what makes this new systemd tooling so exciting to a sysadmin like me is that it’s making this very useful stuff available to less-enterprisey shops too.

This is very exciting to me. systemd-sysupdate is a very nice building block for delivering updates, but having some opinionated (and secure) repo system that sysupdate can consume would be very, very nice.

The Go team as a whole was not adamantly against generics though, as I recall. Rather, they were against implementations that would have bad overall implications for the language (especially its complexity, both in usage and in implementation).

Once a sufficiently good proposal was made, generics were adopted.

I’m quite happy with RSS Guard. Pleasant and quick to use, plenty of features, and can stay out of your way as much as you like.

Not if the response to the AirPods losing capacity is to replace them altogether.

The world is a big place. Of course it happens. But, colloquially speaking, "getting people's attention" suggests that more than a rounding error took heed.

I'm glad your CEO cares. It makes a difference and I hope you feel good about that. And the world would be a better place if more did care. But, to a first approximation, it seems like organizations don't care about data breaches.

At best, it would come down to the details of what their marketing materials have claimed wrt to keeping contents secret. Do you have anything concrete they've promised? I don't remember anything, but maybe that's just my bad memory.

Anything specific from the GDPR you'd apply here?

What grounds would the lawsuit be based on? I can’t imagine that slurping any kind of data would be inconsistent with their EULA.

The only risk would be the reputational damage. And as far as their bottom line is concerned, the impact of that would be negligible—how many of WhatsApp’s billion(?) users know that it’s supposed to be E2EE, let alone are under the illusion that Meta doesn’t have access to their data?

WhatsApp is E2EE, but Meta controls both ends. Instead of reading your plaintext on the server, they read it on the client. Not that tricky.

I presume the hardest part would be avoiding detection via decompilation and other reverse engineering techniques. Not familiar with that space (can anyone here shed some light?), but it seems likely that an entity with Meta’s resources would be able to figure that out.

E2EE probably protects well against bulk data collection (traffic analysis would sniff out sending 2x volume of data pretty quickly). But something more subtle and targeted, smuggled out in various fields of various protocols, would be hard to detect.

Just like well-publicized data breaches over the years got people’s attention? Color me skeptical.

That’s why I think atproto is cool. It’s the only thing I’m aware of that provides for actually forking a public social network.

Same thing as if something equivalent happens to your VPN service I guess? Switch to another one.

Oh yeah crap, you're right about DNS over regular TCP. I totally brainfarted on that.

These things you suggest incur significant latency. Also, can you simply pipe DNS over Tor? I don't see how, since Tor is TCP-only. I suppose DoT or DoH could potentially work, but not all authoritative servers may support those protocols. The TCP handshake will also add further latency.

Furthermore, even once you layer all that tunneling on top, it's still unclear how doing recursive resolution from your end of the tunnel is better than going through one of the big resolvers. The privacy benefits seem marginal at best. Overall, I don't think you have convinced me in the slightest of your original point that "really anyone who cares about bypassing national blocking orders should run a local caching recursive resolver."

- Personal details isn't the point (and while a VPN service may have those, a big DNS resolver certainly doesn't)--the point is that correlating DNS traffic with your source/home IP address is likely easier with a big DNS resolver. In any case, I don't see how the VPN approach is superior here.

- People may also live under regimes where VPN providers are blocked. Unless there's some order of magnitude more limitations on DNS resolvers, I don't see how the VPN approach is superior here.

I don't see how that's an improvement over using a big public resolver. Probably worse privacy (you've basically just swapped your ISP for another virtual ISP), and worse performance (likely longer network paths from your resolver to various authoritative servers, as well as not getting the benefits from the nicely-warmed caches that big public resolvers will have).

I don’t honestly see how that’s necessarily better. Now your ISP can tap your individual household to see what’s being queried. Whereas if you use Do[THU] to connect to some remote recursive resolver it practically functions as a mixer.

I'm not advocating dual stack either. Like I said in my other reply to you, I am suggesting IPv4-as-a-service using standard translation technologies and architectures.

I'm not suggesting dropping v4 connectivity altogether. I'm suggesting migration to a v6-only core by providing IPv4 as a service via 464XLAT, IPv6-Mostly, or only offering IPv4 to select network segments using SIIT-DC-2xlat: https://nicmx.github.io/Jool/en/intro-xlat.html#siit-dc-dual...

> So I don't bother with ipv6 - it's a toy.

Since I can't edit my other comment: I don't agree with this. I agree with the challenges of v6 that wouldn't be there if translation had been prioritized from the start, and with your characterization of DNS64 as a hack.

Well performance really isn't something I would point to at all. While I believe it can become problematic with great scale (e.g. those expensive CGNAT boxes), it's more the architectural and connectivity aspects that are problems:

Architecturally, dealing with two different address spaces is a complication. A flat address space is easier to reason about and more flexible. This is amplified by the fact that IPv4's RFC1918 address space is very small. Have you ever had to merge IPv4 networks from different companies? It's rarely the case that they don't have overlapping ranges.

Connectivity-wise, stateful IPv6 firewalling is very different from NAPT in IPv4 because the applications cannot reason about the ports being used (without rendezvous servers).