What does "log in" or "log out" mean for the Fission SDK and apps?

[boris]

When you visit an app powered by Fission, the “Sign in with Fission” is about giving the app permission to access your file system and store data there for you, related to the app.

To create a new Fission account, you can either visit the Auth lobby auth.fission.codes, and a private key is created in your browser using the WebCrypto API. We ask for a unique username, and also an email address to verify.

Or, you can download the Fission CLI and create a new account on the command line, where a private key is placed in your home folder. This is familiar to developers we’ve surveyed that use Github. This private key is usually never changed until the developer moves to a new machine, and then searches for how to create a Github key

In the CLI case, we assume the desktop operating system is secured by the user, as this is the pattern used for Github and related approaches.

For the browser, we are relying on the WebCrypto API for the same use case. Once the key is resident, you are “logged in”.

We still don’t share any information when browsing to an app (we could, like username). “Sign in with Fission” takes you to the Auth lobby, much like an OAuth flow (This app would like to tweet on your behalf), or a permissions pop up on mobile (App X would like to access your Photos) to let you know what permissions the app wants.

Since we’re file based, we have some basics:

1. The default, non optional permission is access to an “App folder”

• This means the app can write some basics, which might be as basic as some user preferences
• Dropbox has the concept of an App folder
• MacOS has a /User/USERNAME/Libraries path
• This is handled transparently on mobile operating systems

2. The app can ask for a different private, encrypted path to write to

• e.g. Documents/Quotes
• The current version of MacOS asks permission to read/write different folders, like “Downloads”, or “Documents”
• this is one way that multiple apps can share data / documents

3. The app can ask for a public path

• e.g. Public/My Public Quotes
• pushing things public on your behalf might be done “later” – when you understand what the app is publishing for you
• or, you could ask for all of these permissions all at once, if you think the user will accept them all at once

Log Out

With that background, do we want to promote a “log out” button?

We don’t have “log out” when your Github private key is in your file system. We don’t have “log out” on iOS.

You do have logout on Windows and MacOS, which logs you out of the entire desktop. Either for security, or for switching accounts.

You kind of have log out with one or more Google Accounts on Android, but that can be a fairly destructive experience.

We do have multiple “People” in Chrome. Mostly there isn’t a “log out”. After a while, your account icon will display “Paused”, showing that you have to login again to access Google properties.

Install / Uninstall / Delete

I think of “logging out” – in the Fission context – as more like a destructive un-install. Going from app to app, you are always logged into your Web Native File System by virtue of the key being resident.

Visiting an app – like the Quotes app – and giving it permission, is a bit like an install. That Quotes data is resident and is ALWAYS yours. You can revoke permission to the app, so it can no longer write to its App folder – but the data remains yours, under your control.

So, that’s why I think “log out”, out of an individual app, like Quotes, doesn’t make sense.

If you go to “Quotes App 2”, and give it permission, it can prompt the user to point at existing quotes files.

What message/button/account do we want to turn “Sign in with Fission” into, once we’ve given an app permission once?

Right now, if you visit Quotes app again … you’re just logged in. It handshakes automatically, and you’re in.

A little badge icon that indicates you’ve connected this app? Optional. Not sure what it would do, other than guide people to the Auth Lobby so they can delete their key completely.

Note: I do want to see a list of all of the apps you’ve “installed” somewhere. This may be in Drive, which can then also act as a launcher. This is about “what apps do I use?” and could potentially also be used to do operating system like things – like setting a default Markdown editor.

You definitely will have this in a view in the Auth lobby, which will be focused on seeing what permissions you’ve given to which apps (so this is about Security / Account management).

Shared Machines

If you are on a shared desktop machine (eg. a using a web browser at a public library), you want to “log out”. We should support this use case and make it clear to users how to do this.

Likely this can be done by the Auth Lobby, which can also show you who you are logged in as.

So, from an app, maybe “leave” or another command takes you to the Auth lobby – or to the Drive app – where we can explain to users that mostly they don’t need to log out, unless they are on a shared machine.

Developer Multi Account Testing

It can be useful for a developer to test different accounts / account sign ups. This can be done in incognito mode.

It’s somewhat inconvenient to create new accounts and/or continuously have to link existing accounts. This is also the reason (re-linking an account) for mostly not logging users out.

Other than also educating developers to go to Auth lobby to logout, what else should we do?

I don’t think we want to support multiple Fission accounts logged in at the same time. This adds simplicity for the main case of many end users – they only have to remember one account. Multiple accounts CAN be created, this just ends up being a more sophisticated, advanced use case.

[icidasset]

Good stuff Boris

@boris

We still don’t share any information when browsing to an app (we could, like username).

The auth lobby does pass the username to the app.

@boris

Note: I do want to see a list of all of the apps you’ve “installed” somewhere. This may be in Drive, which can then also act as a launcher.

Makes sense. We could make private/Apps a special folder transformed into a launcher, but you could still browse through the app data.

@boris

You definitely will have this in a view in the Auth lobby, which will be focused on seeing what permissions you’ve given to which apps

I don’t think we can do that, can we? Otherwise we would need to store UCANs in the user’s filesystem, which doesn’t seem like a good idea. We can however list existing permissions when you are redirected to the lobby from an app. Correct me if I’m wrong @expede

@boris

So, that’s why I think “log out”, out of an individual app, like Quotes, doesn’t make sense.

Your vision on this is finally sinking in
I agree

We indeed need something for shared machines.
There’s two parts to this:

1. We need to remove the local UCANs from the app. Removing the ability to send updates to the API.
2. Log out of the auth lobby.

I like the approach you suggested, where “leave” redirects to the auth lobby and then explains it.

Sitenote: I need to look into suggesting to the user that they need to link another device when creating an account

[boris]

@icidasset

auth lobby does pass the username to the app.

If I have an active key in the browser, but haven’t “installed” / given permission to an app I’m visiting, the app doesn’t know my username, even though a key representing the username is present.

So, “logged in” to Fission account, but app not installed is another state.

[bgins]

Good post, this helps me to see the big vision for how this will all work. I have a couple of questions.

How tightly coupled is a user’s Fission account to the email they use when they initially sign up?

With Fission being a new thing to users, I can see folks using a throw-away email account to try it out. I myself signed up in Firefox and Chrome using email plus addressing hijinks, and ideally I’d like to register my real emails! Does it make sense for users to be able to change their email in the auth lobby?

How does account recovery work if a user gets a new laptop? Are they able to bring their account and data onto their new machine?

Will a user be able to completely delete all of their data and their Fission account? Extreme scenarios perhaps, but this might matter for users in countries with “unfriendly” governments.

[boris]

@bgins

How tightly coupled is a user’s Fission account to the email they use when they initially sign up?

It’s not coupled. Currently one email = one account, email can be changed at will if you still control at least one key.

Essentially this is one of the minimal pieces of info that we need as a hosted platform, to be able to communicate with users.

Yes Auth or similar to edit account details makes sense.

@bgins

How does account recovery work if a user gets a new laptop? Are they able to bring their account and data onto their new machine?

Web to Web and Web to CLI linking. This is similar to having a 2FA Authenticator on your phone. When you get a new phone, you need to have access to the old one.

The data is available encrypted and syncs to your local device as needed.

We’re still exploring various recovery solutions. There are some zero knowledge proof methods where we can store part of a key and the user can recover in a browser. That’s another write up

@bgins

Will a user be able to completely delete all of their data and their Fission account? Extreme scenarios perhaps, but this might matter for users in countries with “unfriendly” governments.

Short answer is yes. Right now we would delete accounts manually on request.

Also worth a longer write up, including some scenarios where the Fission infrastructure can block list data. Also related to abuse scenarios.

[bgins]

Got it, that all makes sense.

@boris

There are some zero knowledge proof methods where we can store part of a key and the user can recover in a browser. That’s another write up

Whoah cool, look forward to reading about that.

[boris]

I’m not sure if this Proof of Concept is still working, but you can test it out here:

Identity Proof of Concept

Identity Proof of Concept Here’s a brief rundown of the architecture and setup behind our identity proof of concept that we just launched Check out the app here: https://safe.fission.name/ And the code here: https://github.com/fission-suite/zerowallet-poc [Screenshot%20from%202019-11-07%2017-09-13] Overview The goal of this application to to equip a user with a private key while providing UX similar to a traditional web app. In the demo application, a user stores a private note in IPFS tha…

It gives us a way to continue to NOT hold user secrets, and not have access to a user’s data. This will need to be integrated into the platform to work alongside the account system.

[expede]

@icidasset

I don’t think we can do that, can we? Otherwise we would need to store UCANs in the user’s filesystem, which doesn’t seem like a good idea.

Storage

It would be totally fine to store them in the file system. Storing classic JWTs would be an issue, but we have a totally different security model.

1. We “assume that the pipes are leaky”

We have security beyond relying on TLS — even if someone gets a hold of your UCAN, they can’t do anything with it unless they also have your private key. At that point, you have bigger problems.

Do we want just anybody reading your UCAN? I mean, it’s not ideal, but it’s also not actively harmful.

2. Shared With Me

Users will be able to use the “shared with me” WNFS segment to store credentials broadly. The “trick” here is that you need to think of the case where “I shared this with myself”.

Revocation Propagation

The bigger challenge that exists is that if you revoke a UCAN, you also revoke all of its further delegations. This is a feature not a bug, but worth noting. So, you can absolutely revoke a UCAN, but if they’ve delegated write access to say, a third party service to run compute offline, they’ll need to get a new UCAN with still-valid proof.

[expede]

@boris

Likely this can be done by the Auth Lobby, which can also show you who you are logged in as.

Yes, this is how I was imagining it In many way, it’s like”signing into your iPhone” when you upgrade devices. Apple uses the phrase “erase all content and settings” by which they mean “from this specific hardware, not from iCloud”.

An app layerd on top of a browser is a bit of a different beast, so this wording doesn’t work for us, but something similar perhaps

@boris

We still don’t share any information when browsing to an app (we could, like username). “Sign in with Fission” takes you to the Auth lobby, much like an OAuth flow

Also, from a technical perspective, there’s nothing stopping us from issuing UCANs between devices app@machien1 -> app@machine2 or even auth_lobby@machine1 -> app@machine2. We want to seed as many root credentials as possible, so this probably makes most sense if/when we have a WalletConnect style mobile app.

[aside, maybe “context” is better than machine, because it could also be a different browser, CLI, &c].

[expede]

@icidasset

I don’t think we can do that, can we? Otherwise we would need to store UCANs in the user’s filesystem, which doesn’t seem like a good idea. We can however list existing permissions when you are redirected to the lobby from an app. Correct me if I’m wrong @expede

The final difference/challenge for showing “all credentials” is that you create UCANs on the fly, even in offline situations, and don’t necessarily need to register them somewhere. Most of them have a lifespan of 30 seconds, so they can be pretty ephemeral. What we can store are the longer-living ones that the user controls. Auth lobby tokens, app tokens that it issues to apps, and so on. But down the chain from there we have a lot less control over. Even in the auth lobby scenario, there’s the edge case where the user is offline, issues a bunch of UCANs, and then wipes their browser before we can sync the state to the network. The UCANs exist “in the world”, but Fission will never know about them. But(!) we can make sure that we have a copy of the original UCAN for that browser, and can revoke that if need be.

[expede]

But all that said, the most likley scenario here is the “shared computer” case (e.g. public library), where you want to revoke access to the entire machine.

[expede]

@icidasset

We need to remove the local UCANs from the app. Removing the ability to send updates to the API.

There are two models of security — ACLs and OCAP. Everyone kind of wants both, but they’re not super compatible. ACLs tend to devolve into a horrible mess of exceptions and pointers. Pure OCAP can’t be revoked.

Doing a pure OCAP service is a pretty hard pill to swallow since the service doesn’t control the credentials. A pure ACL service is essentially impossible (hence all the custom logic in apps). This is an old problem going back at least 30 years. The generally agreed upon solution is to maintain a revocation list. But where would you keep that list? Enter commons infrastructure (IPFS, Ethereum, &c)

Because we’re not only an auth solution, we can do better! We can maintain a store of revoked credentials that haven’t otherwise expired. This doesn’t exist yet, but it’s in the roadmap. Basically, revocation is adding an entry to a special directory that’s the CID of the UCAN. Since we can garbage collect expired UCANs from this store, and it’s an uncommon case, the store will typically be empty or sparse. On reciept of a UCAN, we then check if it’s in the revocation store. If it’s there, then treat the UCAN as expired.

[expede]

Sorry for all the technical babble there in a primarily UX thread

[expede]

@bgins

@boris

That’s another write up

Whoah cool, look forward to reading about that.

In super brief, there’s two options:

1. A zero knowledge variant on recovery codes, using client-generated codes and hashing under the hood — super clean and secure, but recovery codes less familiar to most people
2. Email based recovery with a ZeroWallet type of scheme (a form of key stretching)