What this means is that users who sign in to your website with this are Facebook's users, not your users. Facebook controls them and decides if and when your access to them shall be revoked. At least with an email address, you can bootstrap an independent relationship. Not here.
Mozilla Persona got this right - authentication should be decentralized and establish an independent relationship between website and user. Too bad they gave up on it.
> At least with an email address, you can bootstrap an independent relationship. Not here.
Wait, what if I want that? I'd say 95%+ of sites I sign up for I am just trying out. I don't want an independent relationship to be bootstrapped, I just want to play with the site. Chances are, after a week I will never see it again. But instead, I get a newsletter, and have to unsubscribe. Then I get a friend notification or something, and unsubscribe from those, or try to find out how to deactivate or delete my account.
> Facebook's users, not your users
Yes, that's true. I am a Facebook user. I have an account there, which I use. Why should I spread my email around to sites I don't really consider myself a user of, just because I want to save my game or explore the app or something?
Congratulations, you've just handed ownership of your electronic life over to Facebook. Now your access to the internet is gated by Facebook. What? You've used a nickname or an inaccurate photo or you're a sex offender or a drug offender or you've had a DUI or enough people have flagged you? Say goodbye to your entire internet identity, time to start from scratch - assuming FB doesn't recognize your IP address and ban you.
The risks of submitting an email address are overblown. Websites are terrified that you will click the 'spam' button. They don't put those little 'unsubscribe' links at the bottom because they want you to click on them.
I was one of the early adopters of the Facebook platform and 'social login'. Now I think it's a menace. They aren't doing anyone, except themselves, any favors with this.
I resent the way Facebook treats third-party developers, but my early dread has turned into a little excitement over what this could do for soft-touch demos. Right now most product pitches are short videos on the landing page that walk you through the features, but that's a poor substitute for actually logging in and poking around. If you build the anonymous login experience the right way, you cut through the newsletter and transactional email noise from all the people who signup just to try it out, and you just get to communicate with people who actually want to use your product. There's room for both sides to win: users don't have to listen to things they're not interested in, and companies don't have to waste resources on people who aren't listening.
It's also easier to sell a signup when you've got someone in a product they like but can restrict access until they commit. Want to upload a photo? Create an account with Facebook. Want to save your work? Create an account with Facebook. If you're just an anonymous user, you get the same dummy-data experience as logging in with a demo account until you commit and share your email.
It's been my experience from running a Persona+Facebook login system with a nontechnical audience (bicycle racers) that 50% of real customers (the ones buying stuff) prefer not to use to Facebook, and a giant percentage of those are overtly hostile - no Facebook account and refuse to create one. Period.
I don't know if your audience will swing the same way, but I don't expect this is the magic lubricant you're looking for.
> Facebook controls them and decides if and when your access to them shall be revoked.
I share the Persona love but I don't think this is complete: yes, Facebook could zero-day you and drop support but it's really unlikely that they wouldn't announce something in advance which would allow you to pivot, leading to:
> At least with an email address, you can bootstrap an independent relationship.
You can also do this using a Facebook login by having a way for the user to enter an email address. The difference is that you can avoid hitting them for it up front and triggering the “Are they going to spam me?” worry which makes people question using your site in the first place.
You could introduce it at some point where it has a benefit to them – “Please enter your email address if you'd like new turn notifications”, etc. – or, were Facebook to announce that they're discontinuing this service, ask them for another way to login in. Most sites already have a bunch of separate social login services linked to a single identity, this is only one more.
As someone who has built this (one of my sites, http://voo.st/, is literally the poster child for Persona+Facebook login), it's practically impossible to unify accounts unless you get an email address up front. Otherwise you end up with separate accounts and a post-facto merge process that almost always requires some level of administrator touch. Yes, you can solve any problem with a big enough customer support budget. Not helpful.
I still use Persona on over 300 sites for 50k+ users.
It remains one of the best auth components I've ever used, and I have zero issues from users relating to it.
What sucks is that at some point I'll have to remove this great component because they stopped working on it, and will inevitably sunset the hosted service.
It will also lead to many people having to maintain something that they were choosing not to maintain. i.e. a complex piece of software responsible for security.
> The server service is open source, isn't it? Just run your own.
Sort of, ish. The official server includes shims for Google and Yahoo!, so that you can log in to Persona directly through them even though they don't have Persona support directly.
Yeah, Persona is such a simple solution to an annoying problem. I really hope Mozilla makes a second push as I've been enjoying how easily it solves the authentication for small apps.
If someone is worried enough about privacy - then why are they even logging in via their Facebook profile in the first place? Realistically you would just use a throw-away email account and then no one knows.
Secondly - as a developer - why would I want to accept anonymous logins? If I did - then I can just let them create a username + password with no email account instead?
As a developer I want to use this to persist and sync data between devices. It provides a unique identifier I can use for the user before they trust my app enough to want to login.
We have found that a significant number of users will just quit the app if presented with a "sign up or login" with Facebook screen at the beginning of the flow.
With this, they don't have to give us any personal data and can start using our app right away. If they want to activate social features later it is really easy to upgrade their token without having to worry about merging accounts.
Edit: regarding the user side, the problem for a lot of users isn't that they don't trust Facebook. It's that they don't trust the random app/website that is asking for their Facebook data.
"regarding the user side, the problem for a lot of users isn't that they don't trust Facebook. It's that they don't trust the random app/website that is asking for their Facebook data."
Personally I feel it is the other way around.
I guess we'll see how successful this is to see what people really think?
> As a developer I want to use this to persist and sync data between devices. It provides a unique identifier I can use for the user before they trust my app enough to want to login.
Email address, allowing me to use '+' as a mailbox extension. I'll use wtbob+yeldarbsite@example.net. Done.
> We have found that a significant number of users will just quit the app if presented with a "sign up or login" with Facebook screen at the beginning of the flow.
Yup. I refuse to log in with Facebook anywhere but…Facebook.
> With this, they don't have to give us any personal data and can start using our app right away.
I'd still be using Facebook to log in, so no thanks.
> regarding the user side, the problem for a lot of users isn't that they don't trust Facebook.
I don't. In fact, I trust your website with my per-website email a lot more than I do Facebook.
Ok, now you are being honest about it. This is a real problem, and I don't know the answer to that either. There must be better ways than making Facebook the toil taker of the web.
If it makes anything better, I'm one of those people that run away once you ask to log-in with Facebook, and that change won't make me start using it.
I'm guessing that Facebook can put far more resources into random-email-spam-account mitigation than any one company using Facebook Login. You'd face this same problem rolling your own auth/login system.
>We have found that a significant number of users will just quit the app if presented with a "sign up or login" with Facebook screen at the beginning of the flow.
Ditto – it's similar to the push notification / run in the background prompts on first run, where I have nothing invested in the app and don't even know if I’ll use it.
I like this because it allows the developer to solve things like unique sync accounts and only ask me for more info after I've liked the app enough to want to do something like share it.
Even though that's not a problem today, I'm still skeptical of apps because of it. So I'll log in with Google+ or another service, but Facebook still makes me feel gross from those old experiences.
Looks like it replaces the pick-a-username and remember-a-password workflows with a single tap, lowering the bar for new users to start using the service. They can still favourite things, track data, get high scores, whatever the app is for, but delay handing over identifying information until it is actually needed, if ever. Interesting idea.
The thing is - we already have the Facebook (or twitter etc) single login option.
However the are plenty of articles that say this form of sign up is not necessarily effective.[1]
For this idea to take off - you need to assume the reason for the current lack of uptake is that users dont trust the 3rd party with the Facebook data.
However I personally believe, and would have thought, that most people dont trust Facebook with the linked data, since they are learning more about you?
The problem with the existing Facebook single login is that it gives the user another, somewhat daunting, screen that says "Are you sure you want to give this app access to your contacts, email, identity, etc.?" I'm sure Facebook has found that a large percentage of users bail out of new signups at that screen.
And frankly, the user should be bailing out there. Regardless of Facebook's sketchy policy changes, they have demonstrated that they will at least do what they promised with my personal data, but there's no reason that I should a new app/service the same level of trust.
With "Anonymous Login" users don't have to worry that the app will be able to do nefarious things with their Facebook data.
That's the website asking for that information... A website could simply ask for no special permissions. I've hit a few sites that I've signed in with github or google that haven't asked for intrusive permissions.
> However I personally believe, and would have thought, that most people dont trust Facebook with the linked data, since they are learning more about you?
I think most people in the real world, outside our cozy tech bubble, trust Facebook pretty deeply. They give them their thoughts, their photos, their schedule, and their private messages to people. I'm not sure their really that concerned about Facebook also knowing that they signed into Candy Crush Saga XIV
Based on my experience working with a number of companies (n > 15) on onboarding flows, Email + Facebook signup (on the same form) is the most effective. This is trailed only slightly by offering only email signup. Most companies that offer Email + Facebook (on the same form) see a 70/30 split favoring email.
I don't understand why any developer would use FB anonymous login when you can just use email which is equally as effective.
The single-tap could be replaced with a single email field for signup. No username, no password. People try the service, if they like it, they can persist their data. Temporarily, they get emailed an auth link that lets them login to their account for a couple days.
I would consider email address "identifying information". I think if you're hesitant about signing up for a service because you're worried they might be the type of company that will waste your time (making you sign up before convincing you they offer something valuable), then you probably aren't in a place where you want to put the decision in their hands of whether or not to spam you incessantly until you unsubscribe.
> Also a single tap is still often much easier than typing a full email address, especially on mobile.
This could be improved somewhat if iOS or Android had a way to autofill your email address on demand. Unless something's changed recently, the only way to do this now requires asking for permission to the entire address book which many people rightly consider a bad idea.
I was under the impression that still required a permission. If not, that'd be great since it really should be a distinct case because it's only relevant in a very user-controlled context.
> Secondly - as a developer - why would I want to accept anonymous logins?
Because you want the ability to ban people without them being able to create a new account, but you don't care who they are. (E.g. if you are running an online poker site.)
As much as I hate where this is going, it makes sense for a certain type of app. Apps where you need a login, really don't want it to be posting randomly/inviting friends, but in the end really isn't that important.
It helps overcome the username/password signup hurdle AND it helps assuage fears of random Facebook posting. I'm sure it will be a hit with the next semi-skeezy dating app.
For serious apps (business stuff), I don't see why you'd want this.
First social login is nice for a user, I also don't care enough about the app to sign up, have to remember what username plus another password (or more realistically, generate another password with lastpass, but oh your site doesn't like 80 character alphanumeric logins because you don't like the ampersand or you've limited it to 32 characters or whatever I've lost interest) maybe i need to verify the email to complete the login or something I don't know I've wandered off. Now it's not that I don't want them to know who I am, I'm ok when them knowing my email, I just don't trust them not too post on my wall or subscribe me to notifications or whatever (this is why the google social login is IMO nicer because you can clearly switch a box to make it not visible to anyone but you)
Secondly as a developer social login is nice because A) users like it (see above) and B) you off load much of the work of having to deal with authentication and authorization.
Of course it isn't completely anonymous; Facebook isn't claiming that it is. Their documentation very clearly demonstrates that they are linking the "anonymous" user with a Facebook profile on the backened (evidenced by the ability to connect accounts in the future). It is anonymous to developers because they don't see the profile information until the user decides to link it. This isn't some service being offered by Facebook where we have to then worry about them "connecting the dots" in the future - they already told us what they're doing and how.
First thing I thought off. It means the application you are logging into does not know who you are but Facebook does get to know you are logging into that app.
Whichever way you look at it your privacy is better protected if one party knows rather than both parties knowing, so this is definitely a win if you already use Facebook. If you don't then the new option is irrelevant.
It is in their direct interest to do so. They could use that information to better target ads, and to keep an eye on the popularity of potential acquisitions.
In some contexts, Facebook is "reading" the offline behavior of users. Why would they not take advantage of online data, when it could generate revenue in some contexts?
That's true, but there is a difference between offline/not-logged-in and actually "anonymous". If they're offering something which they advertise as being anonymous, there is an explicit understanding that things you do won't be reflected when you login to your primary accounts.
They may very well take advantage of it though; they certainly are able to do so legally. We'll see what the policy looks like.
This is a small feature change with a big marketing angle. Facebook has been cutting the minimum amount of information shared when you "Connect with Facebook" with each iteration of their API. At launch, Facebook literally shared all of your information and most of your friend's information by default with no way to limit it. Then they pared it back to selective requests with a minimum of name, gender, and email. Then name, gender, and anoynimized email. Then it was name and anoynimized email. And now it is just an token specific to that site and nothing else.
They started by building what site owners and developers want - everything about a user without having to build a complex form and have the user agree to fill it out. And they ended up with what the user wants - to share nothing at all with the site owner and fill out no forms.
My guess is this will be stupidly successful, and good for absolutely no one, but Facebook.
> My guess is this will be stupidly successful, and good for absolutely no one, but Facebook.
Why? I see it being very good for Facebook users. I'm very happy about not giving any data about myself to random websites I want to check out just once. I especially look forward for the amount of spam (er, value-added marketing e-mails) it cuts out of the circulation.
This is in no way an anonymous login ... Facebook knows exactly who you are and what application(s) you're logging into. In fact, it's more data to mine so they can serve you targeted advertising.
The proper term for this is "Federated Login". Most enterprises have some form that's used for SSO.
This looks great to me, if it works as I imagine it does: use Facebook to authenticate myself to services, but don't give them any information about me - just an anonymous token.
I want to be able to use the convenience of Facebook login, but usually I don't because I'm worried about how much data the app I'm authenticating with has access to.
For a Facebook user like me, this is awesome. It's really irrelevant how much I trust Facebook (if at all) - I trust someone's random startup less. Giving me an option to use something while not giving the other side enough information to spam me with crap or milk me for marketing money is a win.
OK, so I take it this is "anonymous" only for the application owner, Facebook still knows exactly where you log in, when and whatnot.
So, and please correct me if I'm wrong, this is just logging in using Facebook without (probably) sharing "any" data with the software provider, right?
This is for services that don't need to email users but want to remember them across devices. You're lowering the barrier to entry somewhat but you still have a barrier just to provide the cross-device feature. Why not remove the barrier completely by just using cookies, and then later after the user has created enough state, and is presumably hooked to your service, give them the option to add the cross-device feature. You might even have enough goodwill at that point to be able to ask them for their email without having to use Facebook as a crutch.
I think <guelo>'s advice above is sound. I learned this lesson myself after testing early versions of http://recent.io -- there's a high barrier to convincing users to type in an email address and password, even if it's for personalized news recommendations across multiple devices. It's not necessarily a trust issue -- it's simply a hurdle. Fortunately there are other ways to do it...
I wonder if Facebook will release an according `Anonymous Mail` feature. A way for site owners to reach their `Anonymous Login` users by sending notifications, newsletters, etc right into their FB inbox.
This would surely attract site-owners by providing them with some kind of communication-channel to their users which is important for acquisition, retention, marketing and all that other stuff programmers usually don't like to do :)
The user can unsubscribe/delete account with a click and never gets spam in his inbox for sharing his contact details. Did Persona give away the email-address to site-owners or were there attempts at something like described above (even if persona were just to act as a proxy to your email via api)?
> This would surely attract site-owners by providing them with some kind of communication-channel to their users which is important for acquisition, retention, marketing and all that other stuff programmers usually don't like to do :)
Yes, please. Give me a throw-away app-specific inbox but make sure that I can completely ignore it. It's not only programmers that don't like "acquisition, retention, marketing" - as a user I don't like being subjected to it either.
I get how this works when I'm using a single device. But how do you identify that you're the same anonymous account when you switch from one device to another, without giving any personally identifying information?
I think that for the people that do use facebook this actually does have a decent value. Useless for people that are actually worried about their privacy though.
I would imagine similar to a SAML Persistent Name Alias.
facebook knows who you are - but they just send a non-identifying string/GUID to the service who is trying to log you in. This is a consistent ID (so that service can build a profile) - but it does not contain any identifying data.
I was so hoping for anonymous logins on Facebook, like they announced a little while ago on mobile if I recall correctly (Rooms or something?). But it's only for SSO.
I was there before Facebook changed the expectation. Obviously companies retrieved this information in other ways before federated identity but the idea that you can't get an app or a service without handing over your real name and friends list is entirely on Facebook.
What this means is that users who sign in to your website with this are Facebook's users, not your users. Facebook controls them and decides if and when your access to them shall be revoked. At least with an email address, you can bootstrap an independent relationship. Not here.
Mozilla Persona got this right - authentication should be decentralized and establish an independent relationship between website and user. Too bad they gave up on it.