Better privacy in screenshots

[Amzd]

Previously if you screenshotted a conversation it included the recipients email which is not great for privacy. I prefer the email hidden in screenshots. This does not change any visuals for the user, only in screenshots/recordings is the subtitle hidden.

Before	After

[r10s]

i know this is a draft, but already some thoughts:

this only affects the subtitle of one-to-one-chats in non-chatmail one-to-one chats, right?

this may raise support-requests and false expectations, eg. why the email address is not removed in other places. avatars? others may expect screenshots to be authentic - which may also be important for documentation purposes. others may see this as a bug or wonder why android or desktop are different :)

in many cases, when doing screenshots, the email address will be the least privacy wise compromising information :) (still, doing screenshots are and important feature that we do not want to block, there were older discussions around that)

so, i am not sure functionality-wise. is that really a real-world-issue? - note, we’re getting lots of feedback, and also do user testings a lot, esp. with groups in explicitly risky situations, but afaik, this did not came to the radar yet. cc @kermoshina, @adbenitez

technically, while being interesting and i sympathise with hacking around, this may also strike back on any iOS update - comments as https://stackoverflow.com/a/77841188 also imply that that is not given forever :)

[Amzd]

this only affects the subtitle of one-to-one-chats in non-chatmail one-to-one chats, right?

Correct. This hides the email in screenshots in that case.

doing screenshots are and important feature that we do not want to block

I agree but imagine if WhatsApp would leak someone's phone number whenever you screenshot the conversation, that would not be great IMO, and it's basically what Delta Chat does unless you are using chatmail.

this may also strike back on any iOS update

The assertionFailure at PrivacySensitiveView.swift:31 will go off if this no longer works in a later iOS version at which point you can decide what to do. I wrote it in a way that would not break anything in the future even if the secure container is not found (assertions are only called in DEBUG builds).

[r10s]

I agree but imagine if WhatsApp would leak someone's phone number whenever you screenshot the conversation

WhatsApp is doing exactly that - i think, they just do not care:

arguably only if you did not give access to the phone book, but when it comes to privacy, that's maybe not that unusual. but sure, one should also not take WhatsApp as a privacy role model :)

I wrote it in a way that would not break anything in the future even if the secure container is not found

that's nice!

so, remaining questions are about user expectations as mentioned above. but i would not veto this PR, i just wanted to raise the questions

alternative or successor might be to remove the address completely from the subtitle, that would mitigate some real-world attacks pointed out by @kermoshina at deltachat/deltachat-android#2916 (comment) also for non-chatmail or for non-guaranteed-e2ee (for guaranteed-e2ee, apart from other expectations here and there, the removal was not a big deal in practise)

[Amzd]

I just read through that and seems that some people want an actual private mode that doesn't show emails ever? If we make all places where we show emails PrivacySensitiveViews and have a permanent global toggle that makes them always hidden we would be able to serve the needs of those people? Idk if that is a good way.

I did already run into an issue where if you use this PrivacySensitiveView in a a cell that gets a context menu it hides the privacy sensitive content in the preview (because it gets filtered by UIView.snapshotView I think?)

[r10s]

Idk if that is a good way.

i do not think so :)
in general, we avoid modes and options wherever we can, designing UI and UX for the many, not the few. and that seems to be pretty special, i would not like to clutter even advanced settings with that.