It would tend towards centralisation just because of the popularity of certain posters/instances and how scale-free networks behave when they’re not handled another way.

Ah, I get you. That’s true.

making the place less equal, more of a broadcast medium, and less accessible to unconnected individuals and small groups.

I do not think it is a very good analogy. I do not see how this would turn into a broadcast medium. Though I do agree it can feel less accessible and there is a risk of building echo chambers.

How does an instance get into one of these archipelagos if they use allowlists?

By reaching out, I would say. It’s most likely a death sentence for one-persone instances. Which is not ideal. On the other hand, I’ve seen people managing their own instance give up on the idea when they realized how little control they have over what gets replicated on their instance and how much work is required to moderate replies and such. In short, the tooling is not quite there.

I think both models (i.e. allowlist/blocklist) have their own perks and drawbacks and are all necessary for a healthy and enjoyable internet.

I would tend to agree. I think both methods have their merits. Though ideally I’d rather have most instances use a blocklist model. This is less cumbersome to the average user and this achieves (in my opinion) one of fediverse goal of having an online identity not tied to an instance, an online identity you can easily migrate (including comments, follow, DMs, …) if needed.

But the blocklist model is too hard to maintain at this time. There are various initiative to try and make it work, such as fediseer, and it might be good enough for most. But I think it’s a trap we should not fall into. On the fediverse, “good enough for most” is not good enough.

Now that people are fleeing to the Fediverse, we’re just gathering our tribe - and this is a natural phenomenon.

I think there is indeed something of that effect going on as well, this is true. But I do not think this warrants a move to allowlist by itself.

I think the move to allowlist is mandated by the fact that building a safe space for “minorities” is hard. The tools to alleviate issues such as harassment and bigotry are not sufficient at this time to keep those communities fully open.

Which is a shame as I think the best way to fight those issues, as a society, is to have people express themselves and have healthy conversation on issues that are rarely brought up.

But we are not entirely giving that up by moving to an archipelago model. It just means that individuals would have multiple accounts, on different archipelago. The downside is that it makes the fediverse less approachable to the average person.

I think the current technical limitations push us toward this archipelago model.

The thing is, bigotry and racism, to name only two, will exist on any social media, any platform where anyone is free to post something. And since those are societal issue, I don’t think it is up to the fediverse to solve. Not all by itself by any means.

What the fediverse can solve however, is to allow instances to protect themselves and their members from such phenomenon. And my limited understanding, as a simple user, is that’s it’s not possible right now. Not on lemmy nor on Mastodon, if I trust the recent communications around moderation and instance blocking. Not without resorting to allow list.

This is annoying to admit because it goes against the spirit of the fediverse. But the archipelago model is the only sane solution short term IMO. And it will stay that way until the moderation tools make a leap and allow some way to share the load between instances and even between users.

What a shit show. And if it is confirmed that laptop CPU are also affected, even if to a lower extent, AMD will be the only option on consumer hardware in the coming couple of years. Thankfully, Qualcomm entered the scene recently which should stir up the competition and prevent AMD from resting on its laurels.

On the topic of exposing sequence number in APIs, this has been a security issue in the past. Here is one I remember: https://www.reuters.com/article/us-cyber-travel-idUSKBN14G1I6/

From the article:

Two of the three big booking systems - Amadeus and Travelport - assign booking codes sequentially, making brute-force computer guesswork easier. Of the three, Amadeus, through its web portal CheckMyTrip, is especially vulnerable, Nohl said.

The PNRs (flight booking code) have many more security issues, but at least nowadays, their sequential aspect should no longer be exposed.

So that’s one more reason to be careful when exposing DB id in APIs, even if converted to a natural looking key or at least something easier to remember.

I would not have expected anyone to go to ASUS’ office to press the issue. So, good on GN and hopefully will see some long-term results. But seeing how the company has a hard time acknowledging some issues such as the ROG Ally SD card one, I would not hold my breadth.

The reason behind kernel mode/user mode separation is to require all user-land programs to have to go through the kernel to do any modification to the system. In other words, would it not be for syscalls, the only thing a user land program could do would be to burn CPU cycles. And even then, the kernel can still preempt it any time to let other, potentially more important programs, run instead.

So if a program can harm your system from userland, it’s because the kernel allowed it, every time. Which is why we currently see a slow move toward sandboxing everything. Basically, the idea of sandboxing is to give the kernel enough information about the running program so that we can tailor which syscalls it can do and with which arguments. For example: you want to prevent an application from accessing the network? Prevent it from allocating sockets through the associated syscall.

The reason for this slow move is historical really: introducing all those protections from the get go would require a lot of development time to start with, but it had to be built unpon non-existant security layers and not break all programs in the process. CPUs were not even powerful enough to waste cycles on such concerns.

Now, to better understand user mode/kernel mode, you have to realize that there are actually more modes than this. I can only speak for the ARM architecture because it’s the one I know, but x86 has similar mechanisms. Basically, from the CPU perspective, you have several privilege levels. On x86 those are called rings, on ARM, they’re called Exception Level. On ARM, a CPU has up to four of those, EL3 to EL0. They also have names based on their purpose (inherited from ARMv7). So EL3 is firmware level, EL2 is hypervisor, EL1 is system and EL0 is user. A kernel typically run on EL2 and EL1. EL3 is reserved for the firmware/boot process to do the most basic setup, partly required by the other ELs. EL2 is called hypervisor because it allows to have several virtual EL1 (and even EL2). In other words, a kernel running at EL2 can run several other kernels at EL1: this is virtualization and how VMs are implemented. Then you have your kernel/user land separation with most of the kernel (and driver) logic running at EL1 and the user programs running at EL0.

Each level allocates resources for the sub-level (under the form of memory map, as memory maps, which do not necessarily map to RAM, are also used to talk to devices). Would a level try to access a resource (memory address) it has no rights to, an exception would be raised to the upper level, which would then decide what to do: let it through or terminate the program (the later translates to a kernel panic/BSOD when the program in question is the kernel itself or a segmentation fault/bus error for user land programs).

This mechanism is fairly easy to understand with the swap mechanism: the kernel allows your program to access some page in memory when asked through brk or mmap, used by malloc. But then, when the system is under memory pressure, and it turns out your program has not used that memory region for a little while, the kernel swaps it out. Which means your program is now forbidden from accessing this memory. When the program tries to access that memory again, the kernel is informed of the action through a exception raised (unintentionally) by your program. The kernel then swaps back the memory region from disk, allows your program to access the memory region again, and then let the program resume to a state prior to the memory access (that it will then re-attempt without even realizing).

So basically, a level is fully responsible for what a sub-level does. In theory, you could have no protection at all: EL1 (the kernel) could allow EL0 to modify all the memory EL1 has access to (again, those are memory maps, that can also map to devices, not necessarily RAM). In practice, the goal of EL1 is to let nothing through without being involved itself: the program wants to write something on the disk: syscall, wants more memory: syscall, wants to draw something on the screen: syscall, use the network: syscall, talk to another program: syscall.

But the reason is not only security. It is also, and most importantly, abstraction. For example, when talking to a USB device, a user program does not have to know the USB protocol. This is implemented once in the kernel and then userland programs can use that to deal with all the annoying stuff such as timings, buffers, interruptions and so on. So the syscalls were initially designed for that: build a library of functions all user programs can re-use without having to re-implement them, or worse, without having to deal with the specifics of every device/vendor: this is the sole responsibility of the kernel.

So there you have it: a user program cannot harm the computer without going through the kernel first. But the kernel allows it nonetheless because it was not initially designed as a security feature. The security concerns came afterward and were initially implemented with users, which are mostly enough for servers, and where root has nearly as many privileges as the kernel itself (because the kernel allows it). Those are currently being improved under the form of sandboxes, for which the work started a while ago, with every OS (and CPU architecture) having its own implementation. But we are only seeing widespread adoption by userland since fairly recently on desktop. Partly thanks to the push from smartphones where application-level privileges (to access the camera for example) were born AFAIK.

Nowadays, CPUs are powerful enough to even have security features to try to protect a userland program from itself: from buffer overflow, return address manipulation and the like. If you’re interested, I recommend you look at the concept of pointer authentication.