Post AccmM2U3a5PtmE8l5k by huitema@social.secret-wg.org
(DIR) More posts by huitema@social.secret-wg.org
(DIR) Post #AccmLz3iJZYv9enB7A by hrefna@hachyderm.io
2023-12-08T20:58:29Z
0 likes, 0 repeats
I really think "soft restrictions" statements are undervalued by engineers. Soft restrictions are things that are not enforced in a hard way, but are part of a spec. They are guardrails, not a wall.You can't propose anything in this regard without people coming out of the woodwork with one of: 1. Esoteric attacks that the proposal never claimed to address. 2. "But it won't STOP the bad behavior!"3. "Well if you want that then you should just <do horribly obnoxious and unusable thing>"
(DIR) Post #AccmM03OcEu0ExeRG4 by hrefna@hachyderm.io
2023-12-08T21:12:26Z
0 likes, 0 repeats
For example, if I add a field that says "this message is not addressed to $foo but may be seen by $foo" (the original form of audience: https://github.com/w3c/activitystreams/issues/300)—basically a way of scoping posts—you can anticipate several predictable responses. Response 1: "But it isn't _access control_" and "but if an administrator on an instance wants to they can ignore the field!"Response 2: "A bad actor can still…"Response 3: "if you want to limit the audience you should just use e2ee!"Not useful.
(DIR) Post #AccmM0sRYRjenHXCpE by hrefna@hachyderm.io
2023-12-08T21:21:51Z
0 likes, 0 repeats
Another example: Let's annotate fields with their level of sensitivity. We can say "this field contains user data," "this field can be anonymized if taken separately from the user," and "this field is set by the server and is not remotely private."Guardrails to prevent someone from accidentally logging a password, or keeping user data because they don't recognize it in the message because AP is a mess here.I can guarnatee what the responses would be: I've actually done this proposal before
(DIR) Post #AccmM1iuPNhdQ056bQ by hrefna@hachyderm.io
2023-12-08T21:26:16Z
0 likes, 0 repeats
(Not in the context of AP, but in the context I proposed it in the same ideas apply)* "But in the case of a malicious process on the system reading the memory…" (you are confusing this proposal with security typing, go talk to them)* "Okay but what prevents a server from…" (nothing, they are guardrails for prevent tripping, not a harness to prevent someone from being shoved off)* "You shouldn't be sharing personal information you don't want disseminated in an unencrypted form."
(DIR) Post #AccmM2U3a5PtmE8l5k by huitema@social.secret-wg.org
2023-12-08T21:35:28Z
0 likes, 0 repeats
@hrefna You are arguing for an intermediate state between "fully public" and "privacy enforced by encryption". I think the big issue is trust. The participants "trust" a set of parties to enforce the "guardrails" -- mostly, other participants in the group and the admins of their servers. Is that obvious to them? What happens if some trusted parties fail to enforce the guardrails? Once? Repeatedly? Because they were hacked?
(DIR) Post #AccmM3f5CZpZQiJ4uu by hrefna@hachyderm.io
2023-12-08T21:40:19Z
0 likes, 0 repeats
@huitema This is a great illustration of a response in the genre of Category 2.
(DIR) Post #AccmM4SiE3WtudWiH2 by hrefna@hachyderm.io
2023-12-08T21:54:23Z
1 likes, 0 repeats
@huitema To put a fine point on it: annotating which fields can contain passwords means that your logger can be told to reject those messages, which would have prevented this rather embarrassing incident: https://about.fb.com/news/2019/03/keeping-passwords-secure/It won't stop a hacker, it won't stop a malicious admin or an employee with elevated permissions, but that's not the reason you do it or propose a solution like this.You do it to prevent, for instance, _your_ server from sending it to servers you don't want to see it.