Re: Gmail confidential mode

[Dave Warren <dw...@thedave.ca>]

On 2022-10-16 10:38, Alex wrote:
> 
>      > What do you know about "Gmail confidential mode" emails? I'm
>     starting to
>      > see a few of these come in to users now, and not sure how to
>     treat them.
>      > They are sent through gmail, but require a one-time passcode sent
>     to the
>      > recipient,
> 
>     Did you actually look at them?  What do they look like?  What does the
>     recipient have to do to actually get the mail?  Does this only work
>     gmail to gmail?
> 
> 
> Some of those questions I was hoping others could help me to answer. 
> This is a legitimate email service provided by gmail. It was routed 
> through google's servers only. It passed DKIM and SPF, but not DMARC. I 
> don't think it's only gmail-to-gmail, as the recipient is not a gmail 
> account.

I neglected to send my reply and found it in drafts, sorry for the late 
reply.

This isn't e-mail, it's a hosted text document and a link sent by email. 
It is functionally the same as putting something on a (vaguely) private 
PasteBin and telling your recipient where to go look at it.

ProtonMail has their own thing, when you send an "encrypted" message to 
someone not on ProtonMail...

Luckily these things don't usually take off since most people use email 
because they want email.

Google is completely unable to address their outbound spam problem so it 
is unlikely they'll manage to address their 
spam-via-online-documents-that-bypass-spam-filters either and spammers 
are good at finding ways to send messages that hide within something 
otherwise legit looking.

Re: Gmail confidential mode

[Grant Taylor via users <us...@spamassassin.apache.org>]

On 11/17/22 10:13 PM, Dave Warren wrote:
> This isn't e-mail, it's a hosted text document and a link sent by email. 
> It is functionally the same as putting something on a (vaguely) private 
> PasteBin and telling your recipient where to go look at it.

Agreed.

I have read about some email encryption methods that do send the 
encrypted message but don't provide the key with the cipher text. 
Rather the client has to get the key from the sender (or their host) 
upon disposition.

This is germane as it means that the sender can refuse to give out the 
key after a certain point.  Thereby expiring the encrypted message 
contents.  (Assuming that the message encryption is sufficiently 
advanced that it effectively can't be read without the key.)

N.B. message expiry is subject to the recipient saving the key for later 
re-use and / or screen shot and / or over the shoulder security holes.



-- 
Grant. . . .
unix || die