SHA256(sealUrl) we have a unique ID for each seal which is the key to all kinds of verification including the blockchain record and using an IFRAME approach for verification, that ID becomes the most important input parameter to the verification API, and it returns us the verification status and corresponding information.
As we also discussed in Status verification inefficiency the speed of verification is a critical part of the user experience.
Users can be expected to trigger verification on each switch between messages, which means if they switch around quickly between messages (e.g. because they are looking for a specific message) even milliseconds will matter to the user.
This means two things to our solution:
- We have to expect the verification iframe to be started and interrupted / aborted in quick succession;
- we will see the same message repeatedly, and any kind of speed improvement will matter greatly.
To me, this looks like a situation where we might benefit greatly from caching.
The cache should only cache information for mails that the user has actively looked at. In other words: No actively going out to mails in the inbox, looking for mails to potentially verify. But if a user selects a mail and verifies it, that result should be cached.
If at all possible we should do the same for messages that have been selected where the verification has been started, even if the user switches to another mail. That way we don’t waste resources on triggering new and aborting them - we will still have the result, but it will be put straight to cache instead of being displayed to the user, since the user has already moved on.
Caching: Threat Scenario
What would it mean to no longer verify each message when it is viewed, but re-using old information? An attacker might be able to poison or manipulate the local cache, the verification information might be manipulated. But if we keep the cache strictly local and restricted to the browser/device, that risk seems comparable to an attacker having enough control to also intercept actual verification when it happens, and manipulate that result. So this does not seem to add significant risk.
The cache is somewhat short lived in any case, as it would be wiped when local storage gets expired, deleted, refreshed, and we can actively time it out in a couple of days, at most.
Caching: User Experience
A cache would mean that the information may be (slightly, see above) outdated, but it would be instantaneous. If we keep the return value from the iframe from verification and store it with
SHA256(sealUrl) as key, the complexity of this mechanism would seem to be comparatively small, but the benefit might be enormous.
The most outdated information displayed will be the block height (the number of blocks written since the mail was sent) and potentially the mail receipt status. The rest of the information is static and should not change.
So from a UI perspective, we would likely want to show that the information is cached, and offer the user to actively refresh / verify again.
Alternatively we only refresh the information of the block height and received status actively for cached information, start out by showing the cached information, and updating it once we have an update.