Sensitive content negotiation system #2

zkat commented 2025年08月11日 22:07:15 +02:00

Market stalls should have both a regular tagging system to improve discoverability (easy enough, not in scope here), and a "sensitive content" tagging system that is both plausibly deniably, publicly postable right in microformat metadata, and that can only be decrypted by market stalls it has an explicit relationship with.

This issue is for discussing the specific cryptographic format of this tag, how it is encoded/decoded, what properties it must have, and how key negotiation happens.

Important Properties

The format for the sensitive content metadata must have the following properties:

1. It MUST be an encrypted set representing the tags. It could be a bit array or an array of strings.
2. It MUST be encrypted per-bazaar that the market stall wants to make it available for, and can contain different data per-bazaar (read: it's encrypted with a particular bazaar's public key, possibly keyed by that key's ID)
3. It MUST NOT expose the actual length of the array in any useful way. For example, its apparent length should not vary depending on the number of tags being applied.
4. It MUST be salted with some information based on the work+stall+bazaar combo. For example, the work's name/id, and the stall's name/id, to prevent cross-comparisons.
5. There SHOULD be a migration path as "sensitive content" tags are added/removed.
6. ALL works in a stall (preferably all stalls) will need to have the tag metadata, even if there's no tags applied.

Market stalls should have both a regular tagging system to improve discoverability (easy enough, not in scope here), and a "sensitive content" tagging system that is both plausibly deniably, publicly postable right in microformat metadata, and that can only be decrypted by market stalls it has an explicit relationship with. This issue is for discussing the specific cryptographic format of this tag, how it is encoded/decoded, what properties it must have, and how key negotiation happens. ## Important Properties The format for the sensitive content metadata must have the following properties: 1. It MUST be an encrypted set representing the tags. It could be a bit array or an array of strings. 2. It MUST be encrypted per-bazaar that the market stall wants to make it available for, and can contain different data per-bazaar (read: it's encrypted with a particular bazaar's public key, possibly keyed by that key's ID) 3. It MUST NOT expose the actual length of the array in any useful way. For example, its apparent length should not vary depending on the number of tags being applied. 4. It MUST be salted with some information based on the work+stall+bazaar combo. For example, the work's name/id, and the stall's name/id, to prevent cross-comparisons. 5. There SHOULD be a migration path as "sensitive content" tags are added/removed. 6. ALL works in a stall (preferably all stalls) will need to have the tag metadata, even if there's no tags applied.

irenes commented 2025年08月11日 22:36:55 +02:00

good list of requirements. I generally think this per-target encryption approach is better than trying to be overly clever such as with Bloom filters.

the list of target bazaars kind of leaks the social graph a bit, and would likely make it easy to reidentify the person publishing the tags (ie. link the identity they publish under to a legal identity and any other pseudonyms of theirs). whether that matters, depends on what the privacy model is trying to protect.

it would be good to have a write-up of the expected social ramifications of this tagging system. any sort of metadata is a potential tool both for abuse and for fighting abuse; it's important to game it out adversarially, and it's also good to have an explicit statement of what it's meant to accomplish.

good list of requirements. I generally think this per-target encryption approach is better than trying to be overly clever such as with Bloom filters. the list of target bazaars kind of leaks the social graph a bit, and would likely make it easy to reidentify the person publishing the tags (ie. link the identity they publish under to a legal identity and any other pseudonyms of theirs). whether that matters, depends on what the privacy model is trying to protect. it would be good to have a write-up of the expected social ramifications of this tagging system. any sort of metadata is a potential tool both for abuse and for fighting abuse; it's important to game it out adversarially, and it's also good to have an explicit statement of what it's meant to accomplish.

zkat commented 2025年08月11日 22:46:28 +02:00

@irenes I couldn't figure out how to have a single tag that gets deduplicated somehow. We could have the multiple tags, which will still expose the number of bazaars-that-require-sensitive-tags that a stall is registered with, but completely obfuscate the identity of those bazaars by using a privately-exchanged bazaar identifier unique to that bazaar + stall registration, which would be easy enough. Or a combination of some sort of encrypting things with a bazaar's and a stall's public/private keys that the bazaar can finagle into a way of identifying which of the metadata tags is the one it wants to read from.

@irenes I couldn't figure out how to have a single tag that gets deduplicated somehow. We could have the multiple tags, which will still expose the _number_ of bazaars-that-require-sensitive-tags that a stall is registered with, but completely obfuscate the _identity_ of those bazaars by using a privately-exchanged bazaar identifier unique to that bazaar + stall registration, which would be easy enough. Or a combination of some sort of encrypting things with a bazaar's and a stall's public/private keys that the bazaar can finagle into a way of identifying which of the metadata tags is the one it wants to read from.

circlebuilder commented 2025年08月11日 23:02:11 +02:00

FYI Posted a possibly silly showerthought about Open Badges. Keeping it short here as cryptography noob :)

FYI [Posted](https://social.coop/@smallcircles/115012132434479033) a possibly silly showerthought about [Open Badges](https://openbadges.org). Keeping it short here as cryptography noob :)

jalil commented 2025年08月11日 23:26:27 +02:00

Why is the sensitive content tags publicly available but encrypted? Can't it be privately accessible instead? E.g. /game/<id>/sensitive-content/<bazaar-public-key>.

This way you allow list the bazaars by public key and the bazaars themselves aren't public information.

User flow would be going to an allowed-bazaars menu and adding the urls, then the server would go to <bazaar>/.well-known/bazaar.pub and register that as the public key for that bazaar.

Trying to access metadata with an unregistered pub key will generate a valid encrypted message that exemplifies an error, this way you cannot test if a game is in a bazaar by using its public key.

Allowed bazaar

1. bazaar -> stall: GET /game/<id>/sensitive-content/<bazaar-key> + nonce
2. stall -> bazaar: <encrypted with=<bazaar-key>>sensitive tags + nonce</encrypted>

Not allowed bazaar

1. bazaar/malicious-user -> stall: GET /game/<id>/sensitive-content/<bazaar-key> + nonce
2. stall -> bazaar/malicious-user: <encrypted with=<bazaar-key>>not allowed + nonce</encrypted>

Why is the sensitive content tags publicly available but encrypted? Can't it be privately accessible instead? E.g. `/game/<id>/sensitive-content/<bazaar-public-key>`. This way you allow list the bazaars by public key and the bazaars themselves aren't public information. User flow would be going to an `allowed-bazaars` menu and adding the urls, then the server would go to `<bazaar>/.well-known/bazaar.pub` and register that as the public key for that bazaar. Trying to access metadata with an unregistered pub key will generate a valid encrypted message that exemplifies an error, this way you cannot test if a game is in a bazaar by using its public key. ### Allowed bazaar 1. `bazaar -> stall: GET /game/<id>/sensitive-content/<bazaar-key> + nonce` 2. `stall -> bazaar: <encrypted with=<bazaar-key>>sensitive tags + nonce</encrypted>` ### Not allowed bazaar 1. `bazaar/malicious-user -> stall: GET /game/<id>/sensitive-content/<bazaar-key> + nonce` 2. `stall -> bazaar/malicious-user: <encrypted with=<bazaar-key>>not allowed + nonce</encrypted>`

jalil commented 2025年08月11日 23:28:40 +02:00

I also thought about posting the metadata directly to the bazaar instead of replying to the GET request with the metadata, but I don't think this gives additional protections.

I also thought about posting the metadata directly to the bazaar instead of replying to the GET request with the metadata, but I don't think this gives additional protections.

zkat commented 2025年08月11日 23:32:54 +02:00

The current protocol for work metadata exists entirely in the HTML for the work itself, on the work's website. The idea is you could, in theory, have a statically generated site as your market stall, with no dynamic part whatsoever, and have that just work. Dynamic endpoints based on bazaar credentials would prevent that from happening.

The current protocol for work metadata exists entirely in the HTML for the work itself, on the work's website. The idea is you could, in theory, have a statically generated site as your market stall, with no dynamic part whatsoever, and have that just work. Dynamic endpoints based on bazaar credentials would prevent that from happening.

jalil commented 2025年08月12日 00:24:17 +02:00

The endpoints are not technically dynamic since they are keyed on the bazaar's public key. They could be pre-generated based on a list. You loose the ability to use a nonce, and the endpoints are enumerable since unknown keys return 404s now.

The endpoints are not technically dynamic since they are keyed on the bazaar's public key. They could be pre-generated based on a list. You loose the ability to use a nonce, and the endpoints are enumerable since unknown keys return 404s now.