File system "warming up" forever

[expede]

For example, the auth lobby with warm up forever and never redirect back to the app

Reproduced By

• Brooke
• Boris

Environment

• macOS 11.2 / Safari 14
• macOS 11.2 / Firefox 87

Ruled Out

• [ ] IPFS Cluster
• [ ] Web API
• [ ] DNS
• [ ] SDK
• [ ] Application code

[expede]

I'm uncertain if this is webnative or the auth lobby, but someone mentioned similar in Drive, so starting here. Feel free to move if this isn't the case.

[matheus23]

I believe the root issue for this is fixed. What I'm saying is: New accounts should not have this issue unless they use apps with an outdated webnative or malicious apps.

The remaining thing to fix here is to make sure that webnative handles corrupt private filesystems gracefully.

[expede]

or malicious apps

@matheus23 can you explain the threat model? (I'd like to be as BFT as possible while we're revising the whitepaper)

[matheus23]

Not exactly sure what you mean by threat model (are we talking a simple explanation or actual diagrams?).

Here's a short explanation for a start:

• A user creates an account
• The user logs in with fission in an app that's running malicious code, giving it permission to access (parts of) their private file system
• The app code will create a private file header and add it to the user's private file system
• The app code doesn't add the file content to the private file system. Thus the CID in the private file header is pointing to something nobody in the IPFS network knows about.
• When the users navigates to the auth lobby to permission another app, the auth lobby tries to load the private filesystem, but will fail to do so because it (potentially) tries to fetch a CID that doesn't exist on the IPFS network.

Therefore, we should make webnative more resilient against missing CIDs/malformed file headers or more generally resilient against any kind of file system corruption.

[expede]

@matheus23

Not exactly sure what you mean by threat model

Threat model means "in what way do you we expect people to abuse this?" For example, we're not going to worry about "what if someone has physical access to your phone, unlocked, and all of your passwords". We consider that already game over. Our threat model definitely DOES include "what if you load a malicious application that can steal exportable keys?". Threat model also extends to "what if there's a client that's broken in ways X, Y, and Z".

So, my question translates to roughly "which bits are you concerned about that we actually care about handling?"

[gotjoshua]

curious if there are any updates here? (both to the threat model discussion and the warming up issue)