Save circuit data to user's local storage

[smburdick]

Is your feature request related to a problem? Please describe. Circuit data is not saved on the cloud, or associated with any particular user. The first thing we can do to address this is enabling user sign-in. We will need to provide a token from our own backend, but everything else should be trivial -- we won't have to worry about managing passwords.

Describe the solution you'd like User can click "sign in with google" to have their session tied to their Google account.

Describe alternatives you've considered Status quo is to leave it as-is. Saving large amounts of work (and data) in the browser only on Redux is dangerous, so we should also add a database that saves user circuits.

Additional context Google Sign-in dev page

[nelimee]

As a side note, as a user, I always really prefer to have an option to sign in with regular login/password or a passkey.

I understand the developer perspective to prefer the simpler third-party authentification method though.

[smburdick]

@nelimee That's fair. By default, Google Sign-In is also more secure than manually implementing a username/password database correctly.

I know folks in quantum computing (myself included) have a lot of security/privacy concerns. This issue can be deferred to the point where we are actually saving data at rest, which should be E2E encrypted -- we should have no way of viewing our user's circuits. If we had a Google sign-in, if the user also wanted to have E2E encryption, we could have them use a 6-digit pin, and put a 24-hour block on an account with more than say 5 unsuccessful attempts to access encrypted circuits.

[nelimee]

Google Sign-In is also way worse in terms of privacy.

Also, a more generic comment on security: I think it is fine to leave the web app completely "unsecure" for the moment, or at least not dedicate too much time in making it secure. People that want security and E2E can (and likely will if it is a company policy or personal belief) do everything locally. I really see the online web app as a playground for everyone to quickly discover the tool and check if it suits their needs (in which case => local installation) or not.

Going all-in in this view, it may even be better to explicitly make the webapp usage public: all the creations are public, people can explore, load a previous creation from someone else, improve on that or use it as a template for its own creation... Basically enriching the webapp as a demonstration of what can be done using the tool.

[vtomole]

I think this is the appropriate time to air out my doubt towards "webapping" tqec. I actually lean on having tqec be a desktop application for the following reasons

• It will be very costly on our end to maintain a web infrastructure. As @nelimee is saying, this app must be completely public. Are we ready to start looking for people to foot the bill on increasing cloud costs as more people use this app?
• Desktop applications have fewer security risks

I'm aware of the advantages of making this a web app (easier accessibility e.t.c) but i think in the case of tqec the advantages of a desktop app outweigh the disadvantages.

Let me know what ya'll think.

[smburdick]

Google Sign-In is also way worse in terms of privacy.

It would be far better than us doing it ourselves, unless we had a security engineer onboard. We don't have to maintain nearly as much state ourselves. I think Apple Sign-in is also good, since it automatically masks your email.

I think it is fine to leave the web app completely "unsecure" for the moment, or at least not dedicate too much time in making it secure.

Agreed. These were just some thoughts I have

it may even be better to explicitly make the webapp usage public: all the creations are public, people can explore, load a previous creation from someone else, improve on that or use it as a template for its own creation...

That may work, as long as you couldn't change someone else's template: you could fork their copy under your own name. What is mine and what is yours on the cloud requires a sense of ownership, and thus signing in.

What if I didn't want my surface codes to be public, though? Lots of defense R&D is interested in QC.

It will be very costly on our end to maintain a web infrastructure

Right now, it is costing me pennies a month to host tqec.app. I think having a public endpoint is really important for our user/developer outreach efforts.

Even if we had ~100 active users, it still wouldn't be expensive, as their data would fit well within the 5 GB allowance on App Engine.

Desktop applications have fewer security risks

Not true. I do not trust executables off the internet -- we'd have to provide a checksum a way to build from source, which not everyone, even with security concerns, is willing or able to perform.

[smburdick]

I feel a good compromise would be to provide the option to save files locally. Right now, I'm saving to a Redux store, but should provide the option to import/export with local files. I'll create an action item for that

[nelimee]

It would be far better than us doing it ourselves

We know what we store and what we don't. We also know that, realistically, Google, Apple, and any company large enough to provide a decent third-party authentication mechanism that is actually usable by the greater number of people/developers, will store any information they possibly can. So privacy-wise, I strongly disagree, third-party authentication is not better. Security-wise, I strongly agree with you. I just wanted to raise that before any decision is made.

What if I didn't want my surface codes to be public, though? Lots of defense R&D is interested in QC.

Then they can install locally.

I do not trust executables off the internet

Me neither, in that case just install from sources.

a way to build from source, which not everyone, even with security concerns, is willing or able to perform.

My opinion is that there is a point where not everything is possible. If someone has {national-security,defense}-like concerns and is not able to install anything from source, then they probably cannot do their job. Also, it seems illusory to me that someone with {national-security,defense}-like concerns would use a web-based, non-self-hosted, tool without a ton of guarantees around (signed contracts, background screening of people, ...).

Edit: I diverged the discussion from the initial question, sorry for that. I fully agree with your compromise.

[nelimee]

This issue is not relevant anymore. Closing it. See #323 for more details.