Seems like it still has no official support for any kind of disk encryption, so you are on your own if you fiddle that in somehow and things may break. Such a beautiful, peaceful world where disk encryption is not needed!
You underestimate the value of this piece of information taken at different times. It can be enough to know in which country a person was yesterday or is today.
Wound be great if you posted the URL to the relevant documentation for this… I guess there must be some docs about these delicate details? Thank you very much!
It's generally pretty sparse docs because everything is fairly "beta" still and because it is cryptography if you fuck it up you permanently lose control over your account forever. This is one of the reasons they don't advertise non-custodial recovery keys super aggressively.
And the protocol that is used for maintaining a ledger of key changes isn't exactly ideal or to my knowledge final but rather is in a "it's good enough until we douse the other fires" state.
How many people do the security code review with this process? How do they avoid piling dozens of well hidden holes when you not use a library that is publicly available and seen by thousands of eyes?
Isn’t the best argument for open source code that it has so many people, most companies can not afford such a global quality assurance.
How well tested is this in combination with encryption?
Is the ZFS team handling encryption as a first class priority at all?
ZFS on Linux inherited a lot of fame from ZFS on Solaris, but everyone using it in production should study the issue tracker very well for a realistic impression of the situation.
Main issue with encryption is occasional attempts by certain (specific) Linux kernel developer to lockout ZFS out of access to advanced instruction set extensions (far from the only weird idea of that specific developer).
The way ZFS encryption is layered, the features should be pretty much orthogonal from each other, but I'll admit that there's a bit of lacking with ZFS native encryption (though mainly in upper layer tooling in my experience rather than actual on-disk encryption parts)
These are actually wrappers around CPU instructions, so what ZFS does is implement its own equivalents. This does not affect encryption (beyond the inconvenience that we did not have SIMD acceleration for a while on certain architectures).
The new features should interact fine with encryption. They are implemented at different parts of ZFS' internal stack.
There have been many man hours put into investigating bug reports involving encryption and some fixes were made. Unfortunately, something appears to be going wrong when non-raw sends of encrypted datasets are received by another system:
I do not believe anyone has figured out what is going wrong there. It has not been for lack of trying. Raw sends from encrypted datasets appear to be fine.
You probably don’t realise how important encryption is.
It’s still not supported by Proxmox, yes, you can do it yourself somehow but you are alone then and miss features and people report problems with double or triple file system layers.
I do not understand how they have not encryption out of the box, this seems to be a problem.
What is the evidence for people being confused about that? Did any scientist some research about this, are there any facts or studies about this issue? Or does just someone think it is an issue?
Personal anecdotes. It's always personal anecdotes that coincidentally corroborate whatever position someone was already arguing for. As I noted elsewhere, it would be a lot easier to take these seriously if they weren't so on the nose, and if they instead took the form of "well it seems they have account migration figured out BUT instances are confusing BUT the sign up process is streamlined BUT it's not easy to explain to people..."
It would be clear we were at least talking about things where "the people" had reactions to specific things for specific reasons that were in principle solveable and not merely ghosted into existence to support a point the commenter wanted to make anyway.
I think people see one another doing it and kind of collectively converge on this ritual of collective storytelling where we offer anecdotes that don't offer any kind of truth tracking accountability.
I was in a discussion with someone and the instance just booted me out. No explanation. No appeal. I still had a handful of windows open to various conversations (I’m a slob) and could not find a single reason.
I shopped around for another home and found fussy rules. I got rejected for reasons that made no sense.
It encourages narrow minded balkanization and it retains your identity so you have to form a new one.
So don't join them if you don't want to be coddled. Anyone who does wants to engage with a different slice of the fediverse, and why do you care if they don't see you?
fyi mastodon.social is by far the biggest (almost sole) source of spam, thus more and more servers are "limiting" it (as opposed to outright blocking/defederating) so people only see posts from users they explicitly follow from that server.
Eh, I don't have any links to hand, but I vividly remember when I used Mastodon an instance of an admin being tagged and pressured to remove an individual off their server or be blocked.
From what I've seen, some niche servers have very detailed and very strict rules intended to address the needs of certain marginalized groups. An example I've seen is requiring a content warning for any image where a person or animal is staring directly into the lens, appearing to make eye contact with the viewer.
Of course pressuring mainstream servers to adopt such a rule is not reasonable. Automatically applying a content warning to all media from servers that don't have the same rule would be a good solution. Bluesky's labelers provide a way to do something similar, but I don't think the Bluesky appview has a way to express something like "blur all media without the 'safe for my needs' label".
