improved wormhole signup page

[exarkun]

Fixes #495

For reviewer convenience, attached are screenshots of the two signup confirmation pages, one for email-based signup and the other for wormhole-based signup.

email:

wormhole:

[meejah]

Looks pretty good!

It feels like either method should be able to work with both GridSync and "plain Tahoe-LAFS". The latter would be "todo later" -- only after the tahoe-invite.3 branch is merged and released.

So but for the email method should we also offer people the chance to download GridSync (along with instructions on how to skip the "invite code" method and configure manually)?

It would be nice to have a "more detailed instructions" page (perhaps part of GridSync docs?) including instructions on what the signatures are and how to verify them.

[crwood]

Good stuff! :)

+1 to everything @meejah said.

To expand on the verification instructions suggestion, I was thinking that we could perhaps have a help/question-mark link (a simple "(?)" or whatever should suffice) next to the "[sig]" that would take users to a simple page briefly explaining what a signature is, why it's important, and how to go about verifying. I can write this up in the Gridsync docs but would argue that we should mirror its contents somewhere under the leastauthority.com domain as well (and mirror the release signing key there too), that way the user gets a stronger sense that the information is coming from the same "trusted" source (particularly in the case of non-technical users who may not even know what "a GitHub" is --and who are already very unlikely to check the sigs.. Doubly so if they have to go to some "other" site to read about it).

A few other/misc. comments:

1. The second "thank you" is redundant. Maybe the first one (i.e., the title) should say "Success!" or "Sign-up complete!" instead?

2. I really like the "We are deploying" bit for the humanistic flair that it adds. :) To capitalize on this further, it would be cool if, in the future, there was an accompanying animation in here somewhere showing a very determined (and possibly very sweaty) POLA bear working away on a server in a data center -- eventually wiping his brow in satisfaction and giving the user a hearty thumb-up when the process completes.. ;)

3. I'm a bit reluctant to describe Gridsync as "a graphical user interface for Tahoe-LAFS" since Gridsync currently only provides a GUI for a very limited subset of Tahoe-LAFS' features -- namely joining multiple grids/configuring clients, creating/removing magic-folders on those grids, and getting information/notifications about those processes.. Accordingly I worry that readers might mistakenly believe that Gridsync can do everything that tahoe might "normally" do (e.g., tahoe backup and the like) and be disappointed to learn that it doesn't after the fact (which is probably worse than being disappointed before). Maybe this description should be rephrased to qualify this limitation somehow? Perhaps something along the lines of something like "a new, graphical user interface for Tahoe-LAFS that makes it easy to join storage grids and create magic-folders"?

4. Since the invite code is (arguably) the most important bit of information on the page, I'd suggest moving it down onto its own line, center aligned and in a (slightly) bigger font.

5. Totally nitpicky, but that double-hyphen (--) should be an en-dash (–). ;)

Related: What does the user see just before this page? How do they select between traditional "introducer fURL"-style signup and the new wormhole-based one? Can they choose? How can I test this? In any case, it might be a good idea, in the same vein as meejah's suggestion above, to always provide both options together (perhaps in the form of a "manual configuration" link/button below the invite code that reveals the introducer fURL, etc.).

[meejah]

@chris you can select between the two by deleting a cookie; you can create the cookie via https://s4.leastauthority.com/s4-signup-style?style=wormhole

edit: +2 to @exarkun for easy-to-grep docstrings that made this easy to find :)

[meejah]

I really like the "We are deploying" bit for the humanistic flair that it adds. :) To capitalize on this further, it would be cool if, in the future, there was an accompanying animation [..]

Ideally we could provide some kind of real progress-updates here .. like at minimum a progress-bar (via websockets or whatever's cool by the time we get to this). Bonus points if said progress-bar is Fritz going from black-and-white to colour or something.

[meejah]

New thought: what if the only way is "via wormhole", but we can deliver the code one of two ways: in a Web page, or via email?

Justification: I think people are used to "instant" email communication, clicking on links etc to verify accounts -- and we're already planning to keep the wormhole active for potentially quite a while. I really doubt anyone paying money to sign up for a thing will wait days before activating it?

Edit: alternatively, what about delivering the introducer-furl via the web-page instead of email -- I think that would be 100x more secure than sending it via email (rough estimate ;)

[exarkun]

Thanks guys. I've addressed some of the simpler feedback. For some of the deeper stuff:

It feels like either method should be able to work with both GridSync and "plain Tahoe-LAFS". The latter would be "todo later" -- only after the tahoe-invite.3 branch is merged and released.

Yep, that makes sense. I think this means that at some point the content that includes a wormhole code needs multiple sets of instructions that the user can easily select between. The Gridsync intructions, the tahoe invite instructions, perhaps more things in the future (we may even want more specific sets of instructions, like "tahoe invite for a backup-style use-case" vs "tahoe invite for a magic-folder-style use-case"). I don't think there are any particular barriers to this, it's mostly about writing more words somewhere, probably a website or maybe in an email. And releasing "tahoe invite" of course.

New thought: what if the only way is "via wormhole", but we can deliver the code one of two ways: in a Web page, or via email?

That might be good. It seems like this might be something the users themselves might want to choose between? If so then we need to expand our signup form a bit to capture this information. I haven't looked at that code much but it doesn't seem like it would be too difficult.

There's a definite advantage to email in that it's basically persistent. Instead of a fragile cookie in a browser we can rely on the user not losing their initial subscription email. OTOH the downside is that email is basically always entirely insecure, so that's a bummer. Did we have some discussion about another service that decided to have no kind of persistent identity apart from ability to receive email at a specified address? Like, any time you want to log in, you click a button and you get an email with a short-duration log in link? Perhaps something like that could be viable. OTOH, email is still entirely insecure so I'd want to think about what new kinds of attacks that opens up (attacker can request a login link for themselves on demand??? aaaa)

Edit: alternatively, what about delivering the introducer-furl via the web-page instead of email -- I think that would be 100x more secure than sending it via email (rough estimate ;)

I guess we need to settle on an opinion about email. :) I agree this idea is more secure than what we do now. OTOH, usability wise, I think anything based on a furl is almost a 100% failure. Gridsync and "tahoe invite" are big advances over what we do with email now - even if we just email the wormhole code.

[meejah]

Did we have some discussion about another service that decided to have no kind of persistent identity apart from ability to receive email at a specified address? Like, any time you want to log in, you click a button and you get an email with a short-duration log in link?

Yeah, that's "sandstorm" the "other" capability-based web-service thing ;)

But yes, they have no accounts: every time you "log in" it's exactly like a "password reset" flow, except you get a cookie at the end instead of a new password.

[meejah]

The codify my thoughts a little better here:

• email is insecure
• any flow where users touch secret things like fURLs is bad
• in order of security: wormhole code via webpage; wormhole code via email; fURL via web page; fURL via email.

So my suggestion about putting a fURL in the Web page was to replace sending it in an email -- that is, for "expert" users who know what to do with a fURL, it'd be better to give it to them via the Web page rather than email.

Sending a wormhole code via email is definitely less secure than displaying it on a web page, but also way more secure than sending a fURL via email.

Actually, typing that out, maybe that's how we should handle this: if you "sign up" you get the wormhole code via the Web page. If you forget, or it doesn't work or whatever, then you can "re-request" it via email (but only the same email as the one you signed up with). That is, don't do any of the "cookie" stuff for now.

Alternatively to the last thing: if you click "i forgot" then we send a one-time link to their registered email, and then once they click that they get a new wormhole code (although honestly this sounds like just more moving parts than sending them the wormhole code via email).

IMO, anything in email will leak, so a one-time code is cool (whether that's a link or a wormhole code) but a long-term secret is not.

[meejah]

p.s. the last 4 changes look great 👍

[exarkun]

Great, thanks for the extra analysis and explanation. I've linked to this discussion on #575 which may be where the next major improvements (beyond just prose tweaks: #577; #578; #579) for this signup stuff happens.

For now, addressing a final few typographic issues and then merging this.