Is there any significant risk in the communication on web shared workers between main and worker thread?

Question

My personal goal is not to deal with passwords at all. In any way, not even by delegating it to specialized third-party services.

I wrote my API in such a way that all endpoints are based on signed messages using public key algorithms. So in my database I only have one username and one public key to verify the signatures.

The hard part is in the front-end.

NOTE: One thing to note about my web client is that it is entirely based on rust and webassembly. I mention this because it's important to get to the scenario I'm in.

That said, I need a way to manage user sessions. I mean the basics of any app with its public part that anyone can see and its part that only identified users can use.

So the approach I am taking is to use a datatype in the front-end called UserSession which is basically the private key loaded in memory (NOTE: key is hidden behind a SecretBox), this unlocks the private routes of the app. And at same the information is only downloaded from the API if the API calls are successful (i.e. the user's username and private key pair are correct) otherwise the session is cleared.

This works relatively well. But it gives me usability problems because in each browser tab and between page reloads the key is deleted and I have to reload it.

So I need a way to keep the private key in the client without having to encrypt it (encrypting it would break my goal of not dealing with passwords in any way) and have it survive between new tabs and despite page reloads.

That said the conclusion I came to was a SharedWorker

Why?

• My current approach works relatively well but does not survive page reloads or new tabs.

• Any form that relies on using browser storage (cookies, localStorage, sessionStorage, etc) implies the need to encrypt the private key. But this breaks my goal of not dealing with passwords.

• There is a third scenario using the browser's Crypto API. This may be plausible but this API substantially increases the complexity of my code.

So...

• The shared worker provides me with an isolated environment in which to keep the session in memory without having to use any persistent storage.

• At the same time it provides me with a way to transmit that session to multiple clients that persists between tabs and page reloads (as long as there is an open tab that keeps the reference to the worker, but this is acceptable).

• And at the same time SecretBox provides me with a way to avoid unauthorized access at runtime to the memory space where the key is located.

In the first instance this approach seems acceptable to me, both for SecretBox. As well as for XSS attacks taking into account that the shared workers have CORS access control.

The question is that the worker does not have access to the dom, and at the moment that I load the private key (lets call “the login”), there is a space of time where the key is not protected and it is sent through the port to the worker thread.

And this is my question!

What risks exist in communication between threads in the web environment?

Is there a possibility that the channel is “intercepted” and the key stolen?

Are there any additional security risks and/or factors that I am not taking into account?

I greatly appreciate in advance any light that anyone can shed on me.