recipient of a Confidential E-mail cannot download a File Attachment
I have capitalized the terms that may be concepts.
They declare, and it is true, that recipient can view a File Attachment.
Blocking download is consistent with their idea of Confidential which includes keeping full access control with the sender. When the sender expires the Confidential E-mail, the recipient can no longer open the E-mail, and cannot view the File Attachment.
But my expectation for sending a File Attachment to a recipient is that recipient receive the file onto recipient’s local storage.
This design of the Confidential concept does not support that.
I think “help protect” is telling. One can clearly retain copies of the email and of any viewed attachment by using screen-capture functions. So it is a band-aid, short of “trusted computing” provisions with respect to displays.
There is an interesting case when an attachment has to be downloadable to be useful . Authentication and determination of message integrity becomes relevant.
On first glance, there appears to be a collision with regard to authenticity in the context of confidentiality.
I am reminded of those amazing email footers that claim a message is confidential and that an unintended recipient is obligated to destroy/return the message. It is hilarious when these end up on public mailing lists. When I ask senders about this, the response is usually about some employer’s legal department requiring it on all outgoing email. Confidentiality theatre.
This appears to be an over-constrained problem. Need to step back and figure out what the use case is and whether it should even be appropriate at a utility level.
In EOS, I define an integrity violation as happening when a behavior can occur that is not allowed by the concept’s spec. In CS terms, this is violation of a “safety property”. But what about a “liveness property” that says something must be able to happen? This is much trickier, because we want to be able to compose concepts by synchronization in ways that may reduce their behaviors. Consider composing with authentication and access control concepts, for example: you can’t reply to a post in this forum if you’re not logged in.
So, in its current form, concept design would say that this is not an integrity violation, and the concepts of Email and FileAttachment are still obeyed.
The ability to share a PDF for viewing without downloading is actually pretty useful. You might have a long document you want to solicit comments on, but you don’t want it passed around (and taking screenshots would be too tedious, and it’s not top secret, so you’re not worried someone will do that). Google Drive doesn’t current offer this, but Box does.
Something I’m curious about: what happens if you set up your Gmail account in a client that connects via IMAP? Presumably the Gmail IMAP server won’t let you download confidential messages?