Hey,
many of you wish for extended attribute support, to allow a variety of features. We’re in the process of planning this. ETA for a first beta is mid 2021. 
Right now, we’re deciding, how to implement it. There are three possible approaches:
- only encrypt xattr values, not names
- also encrypt xattr names
- encrypt-then-hash xattr names
Obviously we don’t want the first option. The second option is the best way in terms of privacy, but has drawbacks in compatibility. The third option provides the best compatibility but leaks some information about xattr names.
How do these methods differ?
To comply with standards, user-defined attributes should be prefixed with user. Furthermore, to identify attributes that have been encrypted, we need our custom prefix, i.e. c9r. In other words, an encrypted extended attribute could look like this:
user.c9r.uU0nuZNNPgilLlLX2n2r+sSE7+N6U4DukIj3rOLvzek=
On macOS, the maximum length for extended attributes is 127 chars (on Linux it is 255). I.e. after subtracting 9 chars for the prefix, we still have 118 usable chars to store our base64-encoded ciphertext, giving us 87 bytes of ciphertext. If the ciphertext contains a 16 byte IV, we’re left with 71 plaintext bytes.
Why am I tellung you all this? Well: If these 71 bytes are sufficient for most use cases, everything is fine. We could basically use any mode of operation, we like. When we want to list or read the attribute again, we simply decrypt it.
Now, if 71 bytes are not enough, we need to be a little more clever: To fit any length into a shorter ciphertext, we would simply hash the ciphertext. This is the same method we use for long file names. Of course, in this case we would need a deterministic encryption scheme such as SIV. Again, the same as with file and directory names. However, other than with filenames, we can not add any dir-specific AD, as it would cause issues when files are moved around.
| don’t encrypt | encrypt | encrypt-then-hash | |
|---|---|---|---|
| Leaks name | Yes | No | Number of Reuses |
| Max name length | 122 | 71 | ∞ |
Why does the latter leak information?
Since the same plaintext results in the same ciphertext, an attacker would see if an attribute is stored multiple times. If so, it is most likely a frequently used attribute. Using statistics, he could guess the plaintext attribute name.
Furthermore, if a well-known attribute is used for certain file types, the attacker would gain some information about this file. For example, if you know that com.apple.quarantine is on some file, you can be pretty sure that this file was downloaded on macOS.
We don’t know if this information can be used, but we should assume that attackers have huge creativity. 
What now?
Well, from a privacy perspective, we obviously want to avoid to leak information. That said, knowing that two attributes are the same is still far less information than no encryption at all. Also, the attribute value is still protected. Therefore, we are willing to compromise on this issue, if we need to ensure compatibility.
It all depends on how long extended attribute names are. We need to find out:
How can you help us?
In order to find out, if we can choose our preferred option, we need to know if extended attributes with more than 71 chars are frequently used. You can help us by issuing one of the following commands and report your results in this thread:
Try to understand what this does! Do not just execute anything you find on the internet!
On macOS:
find ~ -xattr 2>/dev/null | tr \\n \\0 | xargs -0 xattr 2>/dev/null | awk '{if(length($NF) > 71) {print $NF; l71++} total++;} END { print " total: ", total, "\n longer than 71: ", l71}'
On Linux (if you have attr installed):
getfattr -LR ~ 2>/dev/null | grep -v -G '^#.*' | awk '{if(length > 71) {print; l71++} if(length > 0) total++;} END { print " total: ", total, "\n longer than 71: ", l71}'
These commands print any attributes that are “too long” as well as the count. The attribute names are just for information, feel free to omit them. We’re primarily interested in the numbers.