I feel like Facebook screwed this up for everyone when people's feeds were covered with apps their friends were using. Now when a site asks you to authorize it with facebook, users don't feel like they can trust what it's going to do.

Most app people are very happy to immediatly use the account email to send you stupid personalized followups, aka "Peter From Lame-App".

If it would be "click, see and forget" - OAuth signup would be great, but being required to accept spam really breaks the deal. I am not sure if too many people share that feeling, but it really bugs me.

The issue you point out with aggressive App spam on facebook is different with other services, I feel. Twitter Apps usually ask whether they might tweet something in my name. So I believe you are right, facebook might have screwed this up a little.

If you wish to track data that is connected to my identity, i.e. provide continuity in your service, store some stuff that I made, settings, preferences, you don't need my email address.

If you really wish to communicate: Talk to me on twitter, it's nearly public! With oauth you receive a token as a representation of my identity, not my email address. If you really need an email address - then why do you need oauth?

If I go to a store to just browse through the shelves I don't have to give the clerk my telefone number. Why would he need it anyway? To annoy me every once in a while and bully me into visiting his store, which I voluntarily entered in the first place?

Here is a positive example: - Go to iron.io - Log in with your twitter account - Nothing happens: You can use the app and they show you around pretty nicely.

Yet Iron provides a service upgrade, which requires credit information. They ask for it, specificly when they need it: When you want more from their service. In that case you have to provide them with the info.

This is how websites could handle this issue. Log in with oauth. If you REALLY personally need to contact me, then you can ask me later. Not upon login or to distinguish me from other people or provide continuity.

Emails are communication handles. They shouldn't be a poor man's surrogate database primary key.

I remain very curious: What does _your_ service need my email address for?

Regardless of how legitimate you think my usage of email addresses is the inability to even ask for it _is_ a downside. For those use cases that do require it immediately you now have a system where the user clicks the 'Login without filling in a form' button and gets thrown to a form anyway, which is exactly what we were trying to avoid.

Depending on how many users his service has, this could be a significant amount of work, even though the absolute probability of it happening is very low.

But do you have to do this whenever a completely new user tries to access the website? Is setting up an alternative access method not a very different concern?

So the only safe thing is abstinence. Don't type your FB password anywhere but when logging in directly to https://facebook.com

As you say, the whole point of OAuth is that you can safely use your FB account to log in to this other site. But -- to take this metaphor even further -- each time I encounter one of those things I always feel like a teenager being pressured into sex and being told "don't worry, this is safe, I promise, I love you." And I simply just don't know.

I'm confident I could recognize that www.facebook.com.scottba.io isn't Facebook, and I could probably train my parents on how to recognize that. But there has been extremely little user education on just what a "safe OAuth" site looks like. It's now putting an asterisk on all the old rules.

But I realize this kind of anti-phishing checking is beyond most users, and "Just don't enter your facebook password anywhere but when you are logging into facebook" probably IS a good heuristic for them.

I also don't know if some facebook oauth login paths use some kind of fancy ajax window-in-a-window so you _don't_ actually see facebook.com in your address bar -- which would make it pretty impossible for users to know if they're being phished or not.

This can never happen, because of the situation you highlighted. Most browsers do not let you do that anymore.

I went looking for sites using facebook logins and found this one just as the first unlucky example: http://www.nydailynews.com/login Once you know the browser and OS, it wouldn't be too hard to get something mostly like that pop-up into a div.

Even if they realize there is a consensual relationship going on between newsite.com & facebook, people don't know what's going on. Does this give newsite.com the ability to see my friends? Spam them? Does this give facebook access to my newsite.com stuff?

Is 'sign in with google" like that time linkedin had access my gmail and spammed everyone?

I think that's a grayer area than phising and something more people have actually been bitten by.

At this point, Facebook asks me to share my friends list (often much more) with site X: the only rational response is scrambling for the "close tab" button in the browser and writing off site X as untrustworthy jerks, because they dared to ask for unneeded personal information.

Now tell me again, how convenient is this global login that can at any time disappear from under your feet?

Also, whereas GMail is not inclined to police the morality of its users, FB is. Not the same as data-mining, not the same as "legality" - for example, you have repeatedly used a word that FB retroactively considers a bannable offense, say goodbye to your account; or you have, a long time ago, posted pictures that are considered indecent under the new rules; or enough other users maliciously coordinate to flag an innocuous item of yours - and the banhammer falls automatically.

Moreover, GMail != e-mail: you are completely free to register with any of the bazillion e-mail providers, there is no need to use GMail; as for Facebook, there is only one.

(in light of today's FB blackout)

So color me skeptical. It's good that I don't use Facebook or Twitter to log into your site. They successfully filter me out from the sort of site designed by people whose business needs are met better by social login. Yes, it's not you, it's me. I am only hindering your growth. So fly away freely. Come back only if our true love was meant to be.

Segmentation is a good thing, so long as it's recognized as segmentation.

But then Snowden dropped by to tell us that we can trust our own governments even less than all these companies.

What they don't make clear is that Facebook is informed every time people visit (or in some cases, login in to) those other sites and can generate better profiles from that data, even sleep schedules, even for people who rarely use FB itself.

I guess for me, the reason why signing up via Google is not as creepy feeling inducing as Facebook is because Google gives you the option of putting on Google+ whether or not you sign in to a given website. The default is still to put it in your feed, but at least you can choose not to put it in your feed.

If I have to sign in before I can see anything about it, I leave.

Getting users to do this though is part of my job and my job is often made easier either by auto-fill options in browsers and good form design.

URL based autho systems are pretty limited in their applications as anything on the other side would have to be of little importance. The security implications of such a system are massive...What if you need to log into an account and you use a work computer? Surely all someone needs to do is press ctrl-h(or access server logs) and visit the same url to gain access to your information.

There's a popular Dutch site, datumprikker.nl (date picker) that works exactly like the author describes. No need for accounts; just a link and you fill in only the stuff that's actually necessary for the service to work. It's very popular for a reason: no hassle, easy to use, nobody has to register or sign up.

I only use bugmenot for those sites.

My pet peeve is the arbitrary rules that sites now have for passwords. When I am registering for something I don't care much about just because I have to, my inclination is to use the same easy-to-remember password I always use. But the rules thwart this, and no two sites can agree on the same rules, thus forcing me to alter the password, and guaranteeing that I will not remember it.

Stupid or nefarious, I'm not sure which.

Complaining about loss of privacy, but eagerly weakening your security for convenience. I don't understand this argument at all.

Thre are a lot of sites that want me to have "an account" so that I can do action X. That includes nearly all my passwords in my password manager. For every account that I want to be secure (say, my email) there are ten accounts that I don't want to have. If I want to do X, I don't want to have an account. "Having an account" is a cost - I have to remember the account's data (even the bit 'do I have an account on fancysite.com?' is a cost). If I have to have an account, I have no need for the account to be mine and mine only. If I have to have an account for me specifically, I have no need for it to be protected from others; but I do need to remember it easily - to avoid the inconvenience of creating a new account.

The site owners often make very different policies, for reasons that benefit them - but they are often opposite to the user needs. All the security problems related to the accounts are the fault of those people who required "an account" in the first place - the Adobe breach is a good example, none of those accounts shouldn't have existed in the first place; none of those people should have been asked their emails; none of those people should have been asked to choose a password. The stricter password requirements Adobe would have made - the worse that would harm the actually important accounts. The sole fact of Adobe asking large number of people for their email address and asking to 'choose a password' - that's a hostile attack that harms mass security on the internet (as the consequences of that breach); we should actively subvert such policies. If a site asks you for an identity more than actually needed (i.e., if they need to ship stuff then they need an address) or asks you for more authentification stuff (choosing passwords, security questions, etc) than you need, then that's [security-wise] hostile to you; if you like that site you can suffer through that but you should do the absolute minimum that fits their policies.

Ignoring client-side tools that hide the complexity, let's list some reasonable possibilities for user authentification for the actual accounts (where I explicitly don't care about others getting access to that account but I care about protecting other accounts) sorting them by ease of use (i.e., how I would like to 'log in' to the site), more preferred options first.

1. No identification or authentification at all. For many scenarios that's the optimum that we'd like to have, but it's prohibited by the site operators, so we're forced to go 'downwards'. #1 on ease of use; #1 on security (no risk to be a proxy for attacks on important accounts), #1 on privacy.

2. Arbitrary identification with no authentification - i.e., I pick a name/tag, and that gets used as a semi-unique handle. This allows semi-personalized communication (i.e., distinguish multiple commenters) or some persistence of data. For some scenarios, e.g., most of online commenting this is the optimal point. On some sites I'd want to 'build a reputation' by having a handle that's unique to me; but on most of them the hassle of remembering an account name is larger than this benefit, so I'd prefer to post with an unauthentificated pseudonym. This again is often prohibited, so we're forced to go 'downwards' or to not use such sites - all the next options are just drawbacks that users choose to take in order to gain access.

3. Authentification without identification - publicly available login data, such as the BugMeNot system. This attempts to go to the goal (#1) by sharing data, but again, those accounts often get prohibited by the operators, forcing us to worse measures further down the list.

4. Username/password - optimizing for ease of remembering. That would ideally be a single username and a single password for everything - i.e., the best password was no password (#3), the next best password is a single, simple, short password such as "password". Again, that doesn't work because [some] site owners have expressly prohibited it, so the next best option is a single, simple, semi-short password with a number of special characters such as "Tr0ub4dor&3" - so that it could actually be single and fit policies of a majority of sites. This approach sucks security-wise, as you note - however, the major security flaw for this is actually not the weakness of passwords, but the weakness of usernames - since the authentification doesn't matter for those sites, but this approach leaks and connects identities, which is bad on principle. However, without moving to things such as password managers which wouldn't work when you sit down on a random untrusted computer, I'm not aware of any better options that don't have this flaw; if there are multiple usernames/passwords, then something needs to remember them; and that something itself needs to be accessible with very easy-to-remember (and most likely completely insecure) settings.

5. "Classic" system of not-the-same IDs (to prevent linking them) and secure, periodically changed passwords that are unique for every site - that's not an option. For the large class of unimportant accounts, the total value of the account is less than the cost of that effort. The only way around this is by client-side systems such as password managers that can automate account creation and maintenance - so that while the "hidden" account is secure, the whole process from the user point of view behaves as one of the previous options. That is also a threat, since then (due to natural habits) people use those tools also for the important accounts, and that opens another source of vulnerabilities for them; in an ideal world I'd choose to have no authentification for the vast majority of places, and I'd be able to remember proper passwords (+2FA) for the couple things that actually matter.

Why should people spend any effort at all to secure things that shouldn't be secured in the first place? Why should anyone remember a single bit of info or download an app or spend an extra keypress to protect an account that's already public in intent; but "private" because someone else wanted it to be private?

There are security problems if you use your 'throwaway' password for your primary email (as some of the people on Adobe list have done), but that's not the fault of the throwaway password, but in throwing away the keys to something valuable. That throwaway password should be something that's not a secret, as an equivalent to no password.

It should not even attempt to be protected - it's something that you tell your friends/colleagues openly (so that they'd not have to create their own accounts there, it's quicker to login with yours), post it publicly on the internet (again, bugmenot.com as an example), don't bother to change it years after some site has leaked it, etc. The password as such exists only because someone forces you to some tradeoff of "more security/less usability" - the only reason that the password is not, say, a 0-length string is that you're forced to do so, but there's no reason at all to go any further than the minimum.

For the majority of accounts that I have, the most appropriate level of authentification is not "a reasonable level", not "a minimum", but exactly zero.

If I'm following your logic correctly, you might as well not go to the extra expense of vaccinating your kids, because the anti-vaxxers have already broken down herd immunity.

http://www.rogerbinns.com/blog/gplus/a-pet-peeve-is-company-...

Peter (fictional archetype) might click through on his work computer; then go home, and might want to have another look at the site; however he won't have any recollection of his "personal URL", nor any way to access it. Peter will, at this point, perceive all his time investment going down the drain. He will either re-register (to be wacked on the head when he's back at work again), or refuse the site altogether.

Note this is different in Doodle's case, due to it's inherent sharing nature: people will email the link as part of the main process, so they're able to get back later.

One way to see how this affects user's lifecycle is measuring: 1, username only; 2, username + email; 3, username, email, password variants against eachother, across the entire user funnel: registration, main mechanics, retention (or length of lifecycle).

Actually of the 5000 people who have "registered", more than half have given their email address... probably means people like optional stuff, I know I do.

Nice work by the way.

But yes that's a good idea.

The testimonials make it look like something I'd like to use, if only I could understand how to use it.

Capabilities are quite different from access control lists (ACLs). In an ACL system, the list of authorized principals is attached to the resource. Thus, sharing access to a resource requires updating the resource. For instance, if Alice creates a document and wants to share it with Bob, then Bob needs an account and Alice needs to add Bob to the document's ACL. In a capability system, the capabilities designate the resource and sharing the resource is as simple as copying the capability. In fact, Bob can also share the document (without copying it first) with Carol. In an ACL system, Bob would not typically have permission to update the ACL.

For more information about capabilities, start with, for instance, the e-rights wiki at http://erights.org/elib/capability/index.html .

* Something only the user knows (e.g., password, PIN, pattern);

* Something only the user has (e.g., ATM card, smart card, mobile phone); and

* Something only the user is (e.g., biometric characteristic, such as a fingerprint).

Your example was two things that someone knows -- one factor.

I recently launched an app that requires Facebook registration. I expected it to be a disaster, but a necessary evil for our first pass. I was shocked to find a conversion rate from opening the app to logging in of 95%; it's not hurting us nearly as badly as I anticipated. Measure!

But as I read the article I realized that it's really something else.

Requiring a user name and email means a trip to Epcot. It ain't Europe. There are hyperlinks and pages and it looks like the internet. But it isn't. The links will all be part of a sitemap. Registering is symptomatic of crabtraps: once in, the only way out is back the way I came in and usually what's in the middle is pretty much a three day old fish head, which isn't too bad if one is a crab, I imagine, but a fishhead in a cage is still pretty much a fishhead in a cage compared to the entire fucking ocean...even to a crabby bastard like me.

I'm the first to admit that there are a lot more smart people in the world than I tend to imagine, but the odds that I want to spend time in someone's crabtrap for a few bytes of the someone's idea of the best fishhead ever are pretty low. I mean if I'm that bored, there's YouTube and HN and Facebook and Twitter. And one of them doesn't even require me to register...at least not yet.

Don't get me wrong, you probably don't want me as a customer anyway - requiring registration makes sense by filtering out people who might be harder to track. It's the strategy successfully used by Nigerian princes.

http://research.microsoft.com/apps/pubs/default.aspx?id=1677...

"Free Registration" doesn't mean anything: if you get me to register for something, you should really ask for money too.

Now we should ask the younger generation and people with non-IT jobs what they think about logging in through a social network. Perhaps it's just another noise like managing URLs and Adobe updates.

Indeed, for them it's probably just a click, they already have no expectation of privacy on the Web. I'd really like to see numbers for various registration methods (where several are available), as well as age distribution for each.

One part already exists - the new html5 input type="foo" classes which COULD be used if sites would actually USE them. The other part is the password manager - it would need some rework to generate truly random passwords. Oh, and if the email confirmation messages could be standardized, too, then the mailclient could automatically confirm the mail.

edit: dear website owners, please allow facebook, twitter or any OpenID based flow, no matter how much you dislike these services. I hate nothing more than the tedious crap of filling out differently laid out forms, captchas and email confirmations.

The lack of a standardized registration form is not likely to change as long as sites manage their own accounts. However, perhaps there is some way that accounts and registration could be outsourced to a third party. It would have to be a company, or perhaps some not-for-profit entity, that did account management as their only business, so that they weren't just trying to use it as a vehicle to advertise their other business or sell your data, like Facebook. If it was simple, streamlined, and effective for both site owner and user, it could become a de facto standard.

There were simple, streamlined solutions for this a decade ago. Nobody used them and many of them died. Some still exist out there like zombies. I was shocked to see inames.net is still out there.

The example I usually bring up is Windows CardSpaces, which shipped with Windows as recently as Windows 7. It was easy for people to get conceptually. It was easy for site admins to implement. But it never went anywhere.

When I talked to people about identity solutions like this, there were problems on both ends. From the user side, an identity solution needed to solve an obvious problem and/or be easier than the status quo. For many users, the status quo is to give out personal information freely and use the same username/password everywhere. Anything that adds choices or variety to the process is too much friction for little perceived benefit. Even if the actual process is simpler (clicking a card) than the status quo (filling out a form), there's a mental cost in adapting to something new.

For site owners, there was the added difficulty of educating and supporting users about the new identity solutions. But, the real biggie was that they'd lose the ability to collect & sell all that personal data. That can be more profitable than advertising, and it's a revenue stream some sites can't live without.

I don't have a preconceived idea of what a 3rd-party account system should do. It could be anywhere from the least amount that would get a webmaster to install it up to a full username and password. Somewhere in there must be something better than the status quo.

Of course not. In fact, business models were only considered tangentially in most cases because the general goal was to create an ecosystem of federated identity providers transacting over open protocols. Differentiation would come from the relationship between customers and their providers - charging for background checks to add extra confidence to third-party claims, for example. Or, by selling enterprises more secure identity claim brokers for their employees.

> One problem is username and password proliferation. Another is filling out the same information over and over, like phone number, email address, and so on. E-commerce sites will often not bother checking email addresses and not require accounts because unnecessary obstacles drive potential customers away.

I'd love to see the Digital Identity discussion revived, and between high-profile security breaches (Adobe, Target...) and the NSA, I think it might be time.

I know you don't have or necessarily want a preconceived idea of what a 3rd-party account/identity provider should be, but I encourage you to look at what's been done & discussed before.

Dick Hardt's keynote from the 2006 Identity 2.0 conference is entertaining and informative: https://www.youtube.com/watch?v=RrpajcAgR1E - it's also the talk that got me hooked on Vanilla Stoli for a couple of years.

Kim Cameron's "Laws of Identity" were the cornerstone of the discussion back them. They outline a system of federation, user control & consent, and minimal disclosure. Cameron's site also has lot of information about CardSpace/InfoCards (the open standard) and his blog covers some more modern Identity systems from Microsoft: http://www.identityblog.com/stories/2004/12/09/thelaws.html

Chris Love's 2007 post-mortem on OpenID and CardSpace: http://love2dev.com/#!article/The-Identity-Crisis--Are-CardS...

I guess it would also be good to look at tools like 1Password which can fill out registration forms and passwords already, and see why they haven't been adopted more widely.

This is never the solution. The solution is to abstain from services which need your data, and which don't give you the source code of the software so that you can verify whether or not it does what they say it does.

Try instead: KeePassX, or KeePass2

https://lastpass.com/how-it-works/

- Saving your username and password and then filling in the details when you visit the site.

- Keeping secure notes for things like security questions (or anything else you want)

- Filling in information on registration forms.

Encryption and decryption take place on your computer. The only thing that goes to LastPass is the encrypted information. They have no way to see what you're storing on their servers. That's why you're out of luck if you lose your password.

The biggest advantage to me is that I want to generate unique passwords like %T124_tatWE4%%^&Tx-234rq for each registration, but there's no way I could possibly remember them, so I'd be forced to carry a written copy everywhere. That's not very secure so I reuse semi-safe passwords instead. With LastPass I generate a unique 16-character password and never have to remember it.

That addresses some of the inconvenience of account proliferation, but not all.

I.e., solve the 'identity problem' by removing the identity core; your client software should be able to create fake identities for you on the go, and preferably with less than one click - automatically without prompting.

- Give the site a username (and negotiate a new one if my preferences are already taken)

- Generate a password and store it somewhere sensible

- Generate a unique email address and pass it to the site

- Handle the email confirmation

My initial reaction was, of course, why would sites ever support such a thing (they don't get real names or real email addresses)? But then I realized that could be a great way for a site to prove to me that they have absolutely no intention of handing my details to other people - so it might work as a way of identifying sites that have honorable intentions.

Edit: Does anything like this already exist?

You give a site your user name and password via a form. Your browser converts these into a http request to a link via parameters. The site sends you your account page, or makes you try again if you fluffed it.

Isn't this the equivalent of giving somebody private URL, like in the article? It's essentially the same, functionally, as a password you remember. Except passwords are less secure, as people use the same ones repeatedly, or generate them from a simple system repeatedly (less vulnerable to automated password guessing attempts, but as vulnerable to a dedicated human attacker).

Are their web frameworks that let you determine if a user is genuine by their behaviour as much as their passwords? E.g. if I usually log in from the US, why am I suddenly logging in from Russia, less than a half-hour since I logged in via the US?

Thanks for that hotmail, very helpful.

>>Isn't this the equivalent of giving somebody private URL, like in the article? It's essentially the same, functionally, as a password you remember. Except passwords are less secure, as people use the same ones repeatedly, or generate them from a simple system repeatedly (less vulnerable to automated password guessing attempts, but as vulnerable to a dedicated human attacker).

Sort of, but not exactly. Login forms, when correctly submitted, usually set a session cookie in the browser. Cookies are sent back to the server with later requests, so you could think of the cookie as if it was part of the URL. Every time you log in, though, you get a cookie with different data inside. That's different from a private URL, because the private URL would always remain the same once it has been assigned.

If the private URLs are generated by a secure random number generator, then they could potentially be more secure than passwords are. Being secure and hard to guess also makes them long and difficult to remember; and that's why passwords are used far more often than random private links. Passwords are meant to be possible for a person to remember and type. Also, passwords are possible to change, so if your password is compromised, you can keep your account and just change the password.

>>Are their web frameworks that let you determine if a user is genuine by their behaviour as much as their passwords? E.g. if I usually log in from the US, why am I suddenly logging in from Russia, less than a half-hour since I logged in via the US?

I'm not sure if there are frameworks for that, but I know that some companies have implemented similar kinds of things. Bank of America's website that allows you to access your account data adds a few extra features that add security to the standard username/password combo.

But when you submit your user/pass and are logged in, a cookie is set on your browser, and then a private link with your page is sent back to you.

To access the private link, you'd need to be authenticated by that cookie. And the only way to obtain the cookie is through a user/pass form.

Not necessarily. Usually either the link is public (i.e. the same for everyone) and the session ID is in the cookie, or the session ID is in the URL (considered unsafe). This is the default behaviour of various Java application servers when cookies are disabled, for example (a jsessionid=... paramter is added to the URL). The "unique private URL" concept is then functionally equivalent to session IDs in the URL with sessions that never expire.

This can happen if you use Tor, a proxy, etc.

There are a few drawbacks to this approach such as a user losing their device. Essentially all of their history would be lost with it unless you used something like CloudKit to back the users info up. The problem with an API like CloudKit is that it isn't cross platform (yet). A user with multiple devices could join the same game, but I don't see how that would stop users with multiple emails from accomplishing the same thing.

Just something I was thinking about, but I do agree with not creating more accounts. There needs to be a more elegant solution.

I think that's a very risky assumption, and only bound to be less-true as time goes on.

With CloudKit the app get an unique persistant identifier related to the iCloud account. The cons are it only works through Apple devices for now.

But if you have an iOS only app, it's so easy to identify the user through all his devices without asking him anything.

And if it loose his phone or use the app on another device, his CloudKit ID is persistant (and related to your app(s) only, not global).

My pain from registration is largely due to the friction from having to think up a unique username (I hate when my favorite username is already taken) and making up a password.

I am really not bothered by receiving email from services as most respectable sites will unsubscribe you with one click and if they don't I simply mark their email as spam.

I never sign up with social services (GooFaceTwit) due to my irrational fear that at some point my activity on the site will be made public without my consent.

Your takeaway as a product owner I think is that if you are building a service for technical folks (would your typical user hang out on HN? If so, read on. If not, ymmv), you should really think about if your service truly needs user registration (I have seen some creative workarounds that don't impose a burden on the customer and still allow the product to achieve business objectives). If you do need registration, you should remove as many impediments as you can (meaningful engagement prior to registration, email as username, only ask for information you absolutely need to have, stagger your profile updates within the user lifecycle, etc).

Personally, I would like to see a structural solution to the registration problem. This is such a common issue for a significant portion of the web that it should be solved at the browser level. Why is there not a "Register for this site" button on the browser chrome? The user signs into their browser and from then on can simply create an account on any site by clicking the button. A little drop down or tooltip can show what information they need to share to successfully register so the user is making an informed choice.

I shouldn't need to enter a user name password combo on any website ever again and the entire process should be as easy as hitting the back button.

Most sites that require e-mail I will just leave an never come back. If it looks SUPER useful or amazing I'll go to the trouble of getting a disposable e-mail account.

BrowserId (Persona) would work a bit better for me.

He is wrong in that "Nooooo people do not want to create an account either". If there is a reason to register, I am perfectly happy creating an account with a self-invented password and email validation, even if it's to do only so much as post a few comments under the same name somewhere.

I think the only reasonable time to require someone's email (or other contact information) is when sending emails delivers real value to your users - when there is no other way to accomplish what you need to, except by sending email.

Most people will check their email from their mobile devices. Could be a different browser than where they started, so now they have no easy way of removing the alert, (unless we generate new codes for that in every email?)

It seems that the solution to having a username/password is to make everything run from links via those emails, after they've confirmed. This may be worth exploring.

No, you can definitely make it simpler.

I found the discussion about registration so inspiring, that I wanted to throw in a different approach that I outlined in an own blog post and posted as different thread.

https://news.ycombinator.com/item?id=7884415

I am using a CRM as our main website. It has a small "Register" link in the corner which I was unable to remove until now due to my poor html/css knowledge. It doesn't have any functionality. Still we have around 3 new user every day :)

In the other hand, the signing up issue is valid

She just plays from the beginning restarting each time and picking a different path through the game.

(Signing up might still be an optional way of persisting that state beyond the cookie, for example to share progress between cookies, but that could easily come later and only when the user wants it)

You don't need ALL the money, just enough money.

EDIT: the email address is so we can send you the product you just ordered.

4 Fields, all relevant.

By the way the French version is not the translation, it's the original.

But as I said in the message the site is usable so I don't really care that much, it's just some polishing that would make it greater.

http://worrydream.com/#!/tripphrase