Perform all the decryption/verification operations in the context of GmailElementReplacer

[rrrooommmaaa]

Don't rely on additional processing/message fetching inside pgp_block.htm

Originally posted by @sosnovsky in #3448 (comment)

[tomholub]

If Roma agrees with it, I'm ok with it too

[rrrooommmaaa]

Is it actionable? It makes sense to do this prior to #1509

[tomholub]

yes, it is. thanks

[rrrooommmaaa]

ok, I'm assigning this to myself, then

[rrrooommmaaa]

I'm looking to build a single processor/renderer for both GmailElementReplacer (gmail page) and InboxActiveThreadModule (extension's own settings/inbox page)
to get rid of the code duplication.
However, I noticed that in InboxActiveThreadModule we currently get message in raw format, meaning the message is loaded in full with
all the attachments prior to rendering.

GmailElementReplacer, on the other hand, prefers full to save some loading time (the attachments are loaded later, on demand), we should continue to adhere to this approach, correct?

In this case, the single renderer should support both full and raw message format as input data, or can we just use the single model of full
with separate attachment loading. Or are there some cases when full format doesn't allow to properly decrypt a message?

Another question I have -- for big attachments we have progress display like Retrieving message... 15%

As we trying to move all decryption to the content script, we shouldn't delegate loading and decrypting of an attachment to pgp_block.htm frame,
so I suggest to refactor it in a separate issue -- "pgp block" display with animation will be injected to the page, but not in a iframe

Are we on the same page here?
What are your opinions, @tomholub, @sosnovsky ?

[tomholub]

GmailElementReplacer, on the other hand, prefers full to save some loading time (the attachments are loaded later, on demand), we should continue to adhere to this approach, correct?
In this case, the single renderer should support both full and raw message format as input data, or can we just use the single model of full
with separate attachment loading. Or are there some cases when full format doesn't allow to properly decrypt a message?

Would it save you any time at all in this iteration to nearly ignore InboxActiveThreadModule, short of completely breaking it?

If you do want to have both unified, then we could probably use full for both.

But I do recall there may have been some edge cases, when it comes to signed messages, where we had to get it raw. I think? Maybe my memory is outdated on this. I think it's worth to go with full and see what our tests think about that, and then adjust from there for individual tests that broke that way, if any.

[tomholub]

Another question I have -- for big attachments we have progress display like Retrieving message... 15%

As we trying to move all decryption to the content script, we shouldn't delegate loading and decrypting of an attachment to pgp_block.htm frame, so I suggest to refactor it in a separate issue -- "pgp block" display with animation will be injected to the page, but not in a iframe
Are we on the same page here?

I'd need to understand this more. Is it just the loader that gets injected? Or is it loader and then the actual content?

If you plan to inject actual decrypted content in Gmail page itself without the separation of an iframe, that would be a vulnerability - Gmail page javascript could snoop on the decrypted content. They can't do that if it's in an iframe.

[sosnovsky]

GmailElementReplacer, on the other hand, prefers full to save some loading time (the attachments are loaded later, on demand), we should continue to adhere to this approach, correct?
In this case, the single renderer should support both full and raw message format as input data, or can we just use the single model of full with separate attachment loading. Or are there some cases when full format doesn't allow to properly decrypt a message?

Yes, it's ok to use full by default, we implemented similar approach on iOS (https://github.com/FlowCrypt/flowcrypt-ios/blob/master/FlowCrypt/Functionality/Mail%20Provider/Message%20Provider/Gmail%2BMessage.swift#L22), but there are still a couple cases when raw message should be fetched - https://github.com/FlowCrypt/flowcrypt-ios/blob/master/FlowCrypt/Functionality/Mail%20Provider/Message%20Provider/MessageHelper.swift#L179, so we need to support both formats.

[tomholub]

GmailElementReplacer, on the other hand, prefers full to save some loading time (the attachments are loaded later, on demand), we should continue to adhere to this approach, correct?
In this case, the single renderer should support both full and raw message format as input data, or can we just use the single model of full with separate attachment loading. Or are there some cases when full format doesn't allow to properly decrypt a message?

Yes, it's ok to use full by default, we implemented similar approach on iOS (https://github.com/FlowCrypt/flowcrypt-ios/blob/master/FlowCrypt/Functionality/Mail%20Provider/Message%20Provider/Gmail%2BMessage.swift#L22), but there are still a couple cases when raw message should be fetched - https://github.com/FlowCrypt/flowcrypt-ios/blob/master/FlowCrypt/Functionality/Mail%20Provider/Message%20Provider/MessageHelper.swift#L179, so we need to support both formats.

👍 although it's possible that those cases could be made to work with full as well, but we didn't spend enough effort trying earlier. Hard to say.

[rrrooommmaaa]

If you plan to inject actual decrypted content in Gmail page itself without the separation of an iframe, that would be a vulnerability - Gmail page javascript could snoop on the decrypted content. They can't do that if it's in an iframe.

Yes, the idea was not to scatter decryption between the content script and pgp_block iframes, keep it in a single place. It makes little sense to me to decrypt in the content script and then decrypt again in a frame. What other options do we have? Sending the decrypted content in a message?