I also think that generic solutions are best, however in this case I fear it may be a bit premature. Right now we don’t know what extra features we’ll add so I’d rather have something simple that can’t be misused, and adapt as we go. Also on the topic of new features:
This would be great, but really we shouldn’t confuse planning for new features and their actual implementation; I don’t think option 1 or 2 would prevent us from adding cool features in any way!
I think @paulyoung makes a really good point that an attacker could use dfx to add another protected recovery phrase!
So, how do we go forward? The II team is really in favor of option 2 to keep things simple and maintainable, would you be ok with revisiting the tags option in the future if necessary?
We’ve moved forward with option 2 above. @lastmjs, @Oleksii, and I want to share the last decision with what we’ll be submitting shortly:
There is currently no concept of “updating” a device in Internet Identity, meaning any sort of logic that turns a Recovery Phrase into a Protected Recovery Phrase would need to be written.
Given that this seems like a substantial change and likely to affect memory management, we will submit a flow that excludes logic for “updating” devices and restrict the submission exclusively to “adding” or “removing” devices.
When the user wants to “lock” (protect) or “unlock” (remove protection) their existing recovery phrase, we query for that public key, remove it, and add it back either as protected or unprotected (whichever the user chose)
Rely on users making a protected/unprotected selection at the point of generating their recovery phrase
We’ve chosen option 2 because option 1 can’t be done atomically, meaning we can’t guarantee that these actions in sequence would succeed even with a retry policy.
Jordan mocked this screen together to show the frontend change
I’m a bit curious, didn’t we say we’d add a canister method to update the phrase atomically? I really don’t think there’s any significant risk related to having a method that updates the memory to add/remove the protected flag atomically.
Very nice! I guess we’ll need to clarify the difference between “Seed phrase” and “Protected …” a bit though, right now the user has no reason to click on the first one.
Apologies for the silence, June has been a little crazy. I took over from Jordan and Oleskii last week but really struggled to find the time to make progress.
That being said, it’s almost ready! I’ve deployed a demo version, you ahead and try it out (don’t use your identity.ic0.app anchors, this is a test deploy): http://fgte5-ciaaa-aaaad-aaatq-cai.ic0.app
This deviates slightly from the original plan, in particular:
We don’t offer to create a protected phrase, ever. We just allow making an existing phrase protected. The reason is that it’s really hard to explain what a protected phrase is to someone who doesn’t even have a recovery phrase yet. We’ll do another iteration with our UX guy and improve and clarify the recovery creation process, most likely with a full blown wizard.
There’s a new page for handling a device or recovery phrase (including removal), instead of another button on the anchor management page:
That aside, it’s mostly what we all discussed above.
@frederikrothenberger will prepare a release soon and will update you once everything is live; I’ll be away enjoying a cocktail on a sunny beach but with you in spirits to celebrate.
