Perseids

Trust relationships are fundamental even in the most abstract view of the Web PKI and without the band-aids of Certificate Transparency etc. that trust relationship is: Some random commercial entities that are completely independent of the DNS, make fully trusted statements about the validity of DNS record ownership. It's bonkers to the core. If someone would design it from scratch, of course the domain registrars would be the ones issuing the certificates via their established relationship to the customers, and they would only be able to issue them for the domains they are responsible for. And no: DNSSec does not solve the same problem and is a tragedy all of its own.

In addition to what my sibling comments have said, there is also the advantage of pushing the ecosystem to safe and fast approaches as a whole. Imagine if the default was to run C/C++ software under Fil-C, if no other measures where taken by the developers, e.g. if the consensus interpretation for one of the current security regulations (NIS2 etc.) mandated it. There would then be an enormous incentive for software to provide faster alternatives to Fil-C, as there where 2x-4x speedups for the taking!

Come to think of it, I believe it would actually be a good idea to lobby for exactly that. Memory safety issues have been a plague in IT for far too long.

I'm of two minds about this. On the one hand, you get miraculous results with AI, and that is what you are referring to with "be able to {my-field}". On the other hand you regularly get useless, if not toxic, crap out of the miracle machine. If you work with AI, you know these moments: "no that is not what I meant at all!" [1] or "how could you have already forgotten the central motivation I laid out just ten back-and-forths ago?". We're calling this the jagged frontier, but the jaggedness itself is not the problem, it's how deep these cuts go into aspects that are important. These are, why AI is still not "obviously superior" in its abilities, can't replace mathematicians and software developers and lawyers and everyone else who is primarily working with text. (It's also why people say it is ruining their fields, instead of replacing them in their fields, because it only replaces some part of the work, and what's left is not tenable or pleasant (e.g. doing reviews all the time).)

Over all, I'm not quite sure whether I see these deep cuts occurring less and less with progressing AI. It might just be, that I'm giving them progressively harder tasks as well. But the fact of the matter still is that they aren't there yet and it needs proof they will get there ("there" being able to do competent work that is not strongly limited in their scale by human review and correction). So I'm still not convinced about the point you want to make, even though I see AI disrupting about every part of society, and am hoping for the benevolent super AI to lead us to utopia (and afraid of the cliff of human dictatorship on one side and extinction on the other).

[1] I've started to use these moment to reflect on whether a human in a comparable situation would fare better. Having only a few text inputs and small glimpses into a code base and knowing next to nothing about you or your project personally. Quite a few times I've concluded: No, they would not. But more than 50% they would, and also, these limitations are technological limitations of LLM, so you should probably not excuse them for that.

> I find this unconvincing. Isn't this the exact same security posture as a native app with automatic updates turned on?

Mostly. But the alternative shouldn't be a native app that updates itself, but rather a native app that is updated by a package manager. The big difference is traceability and auditability: With a trusted package manager (and even in good app stores) the company can only decide to push an update to everyone or to no-one. There is no way to push an update just to the pesky journalist or whistle blower. A covert attack is really hard to accomplish this way.

Human languages are a mess. Some mix left-to-right and right-to-left. Some have variable amount of diacritics. Some have non-well-defined character sets where just trying to map it to a manageable complexity still loses cultural heritage. When you are fondly remembering the good old times of ASCII, you just wish back to be able to ignore anyone not speaking English. (Which is in your right to do, if you so desire.)

You seemed to be deeply confused about encodings and character sets.

> The fact that unicode maps the lower 7 bits to its own character set is a nice touch but none of the unicode sets are plain text.

That is only true for the mapping of Unicode character (code point to be exact) to UTF-8, which is an encoding of Unicode characters.

> Unicode are multibyte characters with variable byte length and endianess at play.

That is only true of the UTF-16 encoding. UTF-8 does not have endianess, UTF-32 does not have variable length per code point.

None of that is true for Unicode, because it is abstracted away from any byte representation. Furthermore, getting back to the start:

> ASCII (7-Bit) is the only widely understood charset there is. Everything beyond this point depends on the loaded charset.

ASCII also depends on how you try to decode your text. If you interpret two bytes as one character, ASCII will never be correct. There is nothing magical about one byte mapping to one character. I'd even argue that the only reason ASCII support is so universal internationally is because of UTF-8. Otherwise many countries would default to encodings where ASCII is not a subset (as they did before UTF-8 became common). So IMHO, UTF-8 and Unicode are the only widely understood encoding and character set.

This debate is so broken. AI "sceptics" say: OpenAI should be punished for hacking, because there are no rogue AI agents. AI "believers" say: OpenAI should be punished for hacking, because their agents went rogue. Both argue with each other whether agents went rogue. Can't we unite behind "OpenAI should be punished for hacking"?

> Imagine having a virus escape a sandbox, why are we worried about the virus but not the incompetency of those who are responsible for setting up the sandbox?

> Should we worried about people using LLMs for attacks? Yes, but not in the premise of LLMs going rogue but someone with the intention of abusing it to cause harm.

[Why-not-both?-meme]. To use your example, when you discover prions (a class of pathogen that is much more robust to standard disinfection methods than viruses) you should both be worried about your concrete outbreak of BSE (UK in the 80s and 90s) as well as the wider implication (e.g. do we need to change the sterilization methods for our surgical instruments?).

Seriously, I find the way these discussions are done to be super frustrating, because often people implicitly form tribes that oppose everything the other tribe says. When someone believes AI companies push greatly exaggerated stories of dangerous rogue AI to force out competition via regulation they often implicitly conclude that their argument is fundamentally wrong, whereas in reality the lies that work best are those that distort the truth.

Companies should be punished harshly for the deeds of their AI agents AND we should not allow them to force out competition AND we need take the threat of autonomous AI agents as a new class of danger serious AND we need to worry about the socioeconomic implications of AI companies privatizing new means of production.

Yes, there is competition of these ideas in the attention of the general public, but the methods we can use to solve these problems don't compete with each other. AI slowdown for example helps with all the other topics.

You're making a good point. I was also of the opinion that these books don't land well, because I'm missing the context. And I'm actually still thinking that about quite a lot of these classics. But what I believe I'm also concluding from your comment, is that these books aren't good hooks to get people, especially teenagers, interested in the context and in the society of the time. And that is where YouTube/TikTok/TV might shine. Or a well written and narrated podcast.

Hoping to not sound like a broken record, this is why having full ownership of your device and OS is important. My stock Pixel Android recently told me something along the line of "A security policy blocks screenshots for this app. Talk to your administrator if you want to change the policy". I looked in the mirror and my administrator said "time for a policy change, we're moving to GrapheneOS".

And just as important: Help your friends and family to move as well, so they can have ad blockers, NewPipe etc. We need a critical mass of users invested in their freedom, otherwise its going to be crushed by malicious/dumb security measures of their banking apps, corporate greed ("oh, a simple misunderstanding, when you clicked 'buy' you rented a limited license. Did you not read the ToS?") and police overreach. It's a perpetual battle.

> The bike with the torque sensor behaves a lot more like what you're used to from riding a conventional bike

I agree, but would like to point out that sometimes this might not be what you want. I had a bike with a front motor and a cadence sensor that I used for my commute for a few years, and was very happy with the motor just pulling me along while I lazily pushed the pedals with ~zero torque, barely enough to let the bike know I'm there. Basically like pressing a throttle. If all you want is to get from A to B comfortably, I've found this to be superior to a torque sensor, and it was also dirt cheap.