@Gargron those answers feel way more suggestive than "yes" and "no"
@Gargron I think they shouldn't be part of the answers though, and should instead be listed outside of the poll. Just a pet peeve.
To do that you'd need a private key that is local to your client (i.e. not stored on your local instance) and you would have to authorize new devices you want to post from in a fashion that they get this key without the server handling it. It also prevents you from recovering your account if you lose the key.
Services such as Signal and Keybase do this, and as such are better suited for truely private communication.
@gargron @jsalvador and why 'no'? Perhaps its not currently possible because it's not been implemented, but why would it be technically impossible to encrypt DMs? Users would have private and public keys and they could be used to encrypt and decrypt DMs. Perhaps an ambitious undertaking, put certainly possible?
@Gargron yes (voted) but also advocating an additional splainer indicating most social media platforms do this
and some E2E suggestions
Thanks for having the integrity to seek community feedback on this @Gargron, doing this isn't the easy way.
I suspect the reason so much of the net feels like a corporation's backyard is because decisions to do what everyone else always did just game made unquestioned.
And that leads to everyone making the same assumptions and the whole thing being fragile to the same kind of failure.
I don't see why not. Plus is it educates ppl who maybe never thought about it and it's such a small thing to do tjat encourages people to think about who has access to the things they post. I guess minus it might be interface clutter? Maybe "Yes, with a 'don't show this again' option"
@ninja85a @Gargron How would Mastodon determine this "privacy" settings? The admin can tell the user whatever they want, and this is not the role of Mastodon to understand the security of where it runs. This feature seems to me hazardous at best.
OTOH implementing PEP would help users utilize strong cryptography from the client for DMs, making it easier to block admin envy.
@Gargron Hi Eugen, although it is common use by all the same sort of platforms. A one time 'cookie notice' that informs new users, or an addition in the TOS will put the users above the party (in this case Mastodon) and give open information about the flaws that other platforms have and not tell their users. As Mastodon is different this will make a big statement and I believe positive effect to people that want to know all. (no hidden benefits for mastondon). Greetings from Holland, Barbara
@Gargron *sends flowers to the orange part of the circle*
@Gargron By the way, thanks for asking your users.
@Gargron ⚠ warning sounds a bit strong
but a little info box saying something to the effect of "direct messages are not encrypted and will be readable by admins and mods of both this instance the recipient instance(s)" (with maybe a link to a more thorough explanation for those interested) would be a good idea
from an end user perspective, I very much like being told what a feature really does instead of having to assume.
@Gargron voted yes; agree with others that it should be unobtrusive and possibly dismissible. disagree with that it should say 'other sites do this too' - when websites do that when they ask for cookies, it feels very forced or showy to me. it would be nice if someone had no idea other sites did it, but to me it seems very smug, like 'oh here's a reminder how much everyone else sucks', which makes it seem more about gloating than being informative!
I agree that it should be a brief reminder that doesn't take a ton of screen real estate and maybe is permanently dismissable with a little icon:
ℹ️ ᴰⁱʳᵉᶜᵗ ᵐᵉˢˢᵃᵍᵉˢ ᵐᵃʸ ᵇᵉ ʳᵉᵃᵈᵃᵇˡᵉ ᵇʸ ⁱⁿˢᵗᵃⁿᶜᵉ ᵃᵈᵐⁱⁿⁱˢᵗʳᵃᵗᵒʳˢ [ᵐᵒʳᵉ ⁱⁿᶠᵒ] [ˣ]
A more thorough explanation can be found at the "more info" link.
I'd be careful about wording. "may be readable" is a bit of a soft sell but I chose that on purpose, other wordings I thought of make it sound like common practice.
@Gargron the lowered barrier to entry cuts both ways, a regulated company that wants to remain a thing™ is still beholden to bad press and the law, whereas private individuals spinning up masto are less capable to both spot and punish bad actors and also protect against external threats.
That's not a criticism of Masto putting this stuff in the hands of everyone, but I find the like for like comparison a bit off. Federation does change the risk profile for the average user.
@Gargron I'd argue that a 'better' solution in the long term would be more general education about where your data ends up and who can see what.
Your local instance operator see your:
They don't see your:
Remote instance operators see your:
DMs to people on that instance
@Gargron People might say that I'm "paranoid" about privacy. Well I am. And I have good reason I should be. Especially after what happened to facebook, who's saying no one else has done it? I knew for YEARS, people around me knew for YEARS, but like I said some hacks never get published. Many sites sweep things like that under the rug. Other sites could have the exact same problem. Such as google. Google does every little trick it can to track your location, so anyone that even glances...
@gargron if a disclaimer is written, it should almost certainly link to more in depth information and secure alternatives.
@Gargron I don't think this poll is fair: I wanted to choose both options. It's not a matter of 'moral obligation' but of availability of better options, e.g., a client-side encryption layer. Still, UI is important. OTOH, such a warning should be written to clearly explain that this is a global risk, not just Mastodon's DMs. See how Caliopen.org is handling it...
@Gargron I think as much transparency as poss is best. Of course that data has to be stored somewhere, but letting users know where and why is important.
I eould love the idea of incorporating public / private keys for sensitive content like DMs and private threads.
There's a project called pass that has cool group gpg functionality
Something similar could be a really rad feature!