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.
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.
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.
Now tell me again, how convenient is this global login that can at any time disappear from under your feet?
(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.
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.
Complaining about loss of privacy, but eagerly weakening your security for convenience. I don't understand this argument at all.
http://www.rogerbinns.com/blog/gplus/a-pet-peeve-is-company-...
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!
That's basic market segmentation. Don't take it personally, but some companies don't want you as a customer. There are lots that don't want me either, if it's any consolation and you need consoling.
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.
- 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?
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.
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?
>>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.
Thanks for that hotmail, very helpful.
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.
So, since these users want to receive emails from us, the system proposed simply won't work.
We've spent a fair amount of time refining our process, and still have ways to go, but this is the current process:
1. User is not logged in, wants to get a price alert on their favorite protein. They click the button.
2. A modal popup comes in, only asking for their email.
3. They're now logged in, and the alert is saved (but not activated). They're told to check their email.
4. We send an activation email via Mandrill.
5. They activate, when entails entering a password and their (optional) full name, and all price alerts are now active for them.
6. After they activate, we send them on over to a welcome page, showing them where they can see their settings.
This process is as simple as we can make it. The only thing I want to change is some of the verbage in #4. Right now it's a blanket Confirmation email, but doesn't mention the product they want to follow.
Our userbase is all over the map in terms of gmail, facebook, and twitter. I don't trust any of those. So this is our best thing. See my profile if you want to test it out.
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.
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).
EDIT: the email address is so we can send you the product you just ordered.
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.
yeah that would be cool. You open YOUR page and it asks for your email id. So you need to know the username (assuming that's what u make url from) and the email id. Simle two factor auth without annoying sign ups
* 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.
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.
The testimonials make it look like something I'd like to use, if only I could understand how to use it.
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.
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.
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.
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 .
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.
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.
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.
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.
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
4 Fields, all relevant.
I agree with the premise, but you shouldn't come up with passwords when you register. You should use a password manager that generates a unique password for every site you use.
