You're an idiot if you implement this. On iOS, use the device token and implement truly anonymous login without having to deal with anyone else brokering your users' data; I'm not sure what the Android equivalent is, but it can't be much more difficult.
Remember, Facebook is the same company that cuts deals with shady data brokers like the Datalogix (the company that buys your grocery store discount card data and re-sells it, among other things) to build a comprehensive profile of everything you do. Using them for this pseudo-anonymous "anonymous login" helps them a lot more than it will ever help you, as a standalone developer.
I can't wait for Facebook to trademark the term "Anonymous Login," just to complete the irony. Remember, if it was actually anonymous, you wouldn't need Facebook's help to implement it.
> Remember, if it was actually anonymous, you wouldn't need Facebook's help to implement it.
That sums it up nicely.
And actually, the thing is I could totally see Facebook enabling truly 'anonymous logins' and whatnot, because it can afford to do it at this point. It is too entrenched as the social king, no other competitor comes close to it, and it's not going to fall down anytime soon because it'll be buoyed by networks effects for quite some time... and so it makes sense to ease things up a little to improve their public image. But, the way they got there, to the top, was by using dirty and despicable dark patterns, like 'Privacy Zuckering': http://darkpatterns.org/library/privacy_zuckering/ For this reason alone, I would stay the hell away from anything Facebook.
It truly is an interesting move. Last night my housemate was telling me about MS's moves in the office365 space, I was gobsmacked by what they're up to these days. I actually commented "time to buy some MS shares", pigs were flying. And now this..
It does make sense though. Developers only really want a way to verify the user exists and isn't some spammy bot. Verification like facebook login is the easiest way to go. The problem has always been - far too many people avoid signing up with facebook as it shares "god only knows what" with the site. This works around both issues and really is the only way they can become the single signon entity. Which is what they've been aiming for.
As for "not bothering to implement" (aap), if you already need to handle facebook connect login, its going to be minor to add anon login facebook handles all the identity stuff leaving your app clean of yet another verification loop which annoys the hell out of users.
Sure there is the "apps need that data to make money" situation, but as a matter of fact, the people signing on anonymously were a) going to create a fake facebook or b) signup manually and give you a mailinator address.
In excel they're using some pattern recognition so when you start filling down a column they just fill out the rest instead of waiting for you to use the fill down feature, I thought that was just plain neat.
They're improving collaboration in all products, ie bringing it on par with gdocs.
Something geospatial, dont recall exactly what, maybe it was to do with SharePoint or colo.
The most interesting was they're letting go of forcing ms languages for plugins and allowing you to write and import widgets/plugins as html/js so all those nasty vb scripts of old are going to get some much needed love from all the web devs out there.
I could be wrong on a few of these just what I recall hearing about, happy to be corrected if I misunderstood any of what I was told. Mostly it just sounded like, as a company, they're identifying what their core products are and innovating on them. As in strategically, they're getting their shit together.
The point of this isn't staying anonymous to Facebook. It's anonymity from the app developers using FB-only login.
There's no doubt that Facebook knows who you are even if you use the "Anonymous" login. This just allows a user of RandomApp#100 to login without giving the app everything on their Facebook before they even try it.
Also even with anonymous login, you can later choose to give the app your real info if you trust it more or find it useful.
Do I like Facebook-only login? No. However, this does give the user some more choice as to how much is shared with those apps up front.
Honestly, I don't want to rely on app developers implementing this. I would rather have just the one button, and when I get to the Facebook app, then have a big black "log in anonymously" button.
Probably don't want to do this because it would break a whole bunch of facebook apps, just like disabling permissions after the fact with android apps breaks them too.
They'll probably introduce that reality once 'anonymous' mode has been established and depreciate assumed permissions as time goes on.
I understand that perspective, but at least in my case when I see the Facebook login button, it's already an immediate "Nope" for me. I would never see the black button or know it exists.
"On iOS, use the device token and implement truly anonymous login"
* What about the web?
* What about cross-platform?
* What about when the device token changes? (for example, after restoring the phone from a backup image)
My take: Facebook Login solves a real problem well and this 'Anonymous' option is a good improvement. The name is no worse than other industry uses of terms "Incognito", "Private", and "Cloaked".
on the web, anonymous login would be just a code snippet. What would prevent anyone from showing regular FB login posing as anonymous? Only thing I can think of regular login should have a follow up dialog with confirmation of what's requested, but maybe that can be auto confirmed too? some users may still agree to follow up screen if they trust the anonymous icon.
From the site, it looks like the FB login page you get after clicking the button is all black, and then you get sent back to the app. The regular one would be in the normal colors. Although I suppose they could popup a fake anon one on their own site, but they wouldn't have the right URL. On Android the app allows login without entering a password as well, so I'd immediately know because login through FB doesn't require my password but the app's fake version would.
the question was about posing non anonymous FB login as anonymous to trick users into giving more info about themselves. neither should require a password if yo're already logged into FB.
On the web? There's this great new innovation called cookies that allow for site-based identity!
As for cross-platform and token changes -- well, you can't deal with those situations when you're implementing something that's actually anonymous. You're going to have to implement some sort of persistent identity. At that point, you might as well offer a multitude of options, of which Facebook would be one.
This login creates an unnecessary point of friction for all anonymous applications. Just use an existing token (cookie, device token, etc), allow your user to immediately begin using your app (that's what they expect anyhow), and "ease your user in" to a point of giving you identifying information if you need it.
How would cookies solve it considering that they are temporary?
Even if the cookie expiration was set for 100 years, it's going to disappear the moment someone switches their browser, gets a new computer, clears their cookies, etc.
you can't deal with those situations when you're implementing something that's actually anonymous
True, but this login isn't "actually anonymous" - but I can't think of a better term so I don't blame Facebook for using the one they did. It's effectively a global ID with no data attached to it.
Let's say I want to create a service like Instapaper. I don't care about the person's facebook info, but I'd like to optionally give them a way to login with a simple button press without having to create another username and password.
This seems like a reasonable solution.
> Just use an existing token (cookie, device token)
That won't work because the mobile and web account have to be connected.
Most of what you wrote... most people don't care about. Honestly, I don't care too much about it, and I'm fairly privacy-conscious (I just have a higher threshold for things that I actually care about keeping secret).
Remember, if it was actually anonymous, you wouldn't need Facebook's help to implement it.
People implement FB login for a variety of reasons, but one is that doing proper account management is hard. If you want to implement a non-FB anon login, you basically have to implement a full account management solution yourself, assuming you want the anon account data to be persistent (that is, it's not truly anonymous in the sense that you sign in, do things, sign out, and it's as if you were never there). This basically fixes one of my final issues with FB login, that it's still not clear what data FB will give to the app. If anon login means FB doesn't give anything to the app aside from an opaque ID token, that's pretty cool.
> If you want to implement a non-FB anon login, you basically have to implement a full account management solution yourself, assuming you want the anon account data to be persistent (that is, it's not truly anonymous in the sense that you sign in, do things, sign out, and it's as if you were never there)
That's just not true. Modern web frameworks come with modules that let one have fairly good account management systems without much work.
I do Python mostly. Django? Fine. It has an excellent auth system out of the box. But that kind of auth system isn't very flexible either. Now I barely do Django development today so please excuse me behind any insane changes.
Flask and Pyramid world? Custom auth to me. They both have community modules for auth stuff, but do I really like them? I am not the kind of guy just pip install random "useful" package these days. Let's give another example. A year or two ago I tried to do social auth in some of my django and flask apps. Maybe I was dumb but using that social-auth library took me a while to get some of login working. Plus, the code was messy and buggy. In the end, I said screw that and implemented all of the custom login myself, just reading the official doc from twitter and facebook. That also took me a while but I knew the whole implementation inside-out. If I don't trust my own implement because it is insecure, then I must spend the same amount of time inspecting other people's custom modules.
I like customized auth system based on the api provided by the framework - that' what makes Pyramid powerful to me. Sometimes your community auth module can have limitation that you probably have to hack around.
What kind of customization were you trying to do in Django that you couldn't? I know you can one-to-one models that extend the backend, you can customize the backend, chose custom templates for the login forms, create your own forms, etc. And the docs seem to indicate this was possible since 1.5: https://docs.djangoproject.com/en/1.5/topics/auth/customizin...
Until you want Ajax login. Then you write boilerplate for two hours. If there was a really good ajax reg/login module for Django, I'd gladly pay $10 for it the way I do bootstrap themes.
I’m sure what you are saying is right — but I’m not in anyway smarter reading it then reading the one before. You can’t just say ‘No, not true’ on Hacker News. What makes the existing options not “fairly good”?
To make it easier for him (and others who agree with him), here's a simple question. Name the modules (packages, whatever) that implement password-reset functionality in:
By "password-reset" I mean user clicks "Forgot password" and goes through some process like asking a secret question, doing catpcha test, sending a password reset link via e-mail, handling the click on the link, asking for a new password and resetting it.
In Django? django.contrib.auth.views.password_reset seems like it would do the job, no? If you have specific logic you need to implement, rather than using the framework's default logic, there's likely not much it can do for you.
I can't talk for node.js (although I have found that its authn/authz frameworks are lacking in general) or various PHP frameworks, but Django at the least is fairly professional.
Very, very few apps are used in a multi-device context. If/when you hit that scenario, you're already dealing with significantly more complex situations that would require you to implement some sort of identifying mechanism, which would render the notion of anonymous login useless anyhow.
Most people are going to access your app from one device, their phone. The phone is the one true source of identity. Let us all be glad that a privacy-paranoid company such as Apple sets the standards there, rather than what Facebook would have liked, had their phone efforts worked out.
I will also note that taking advantage of device token for "login-less anonymous use" is way way smarter for developers, from a usage perspective. Every single tap or interaction is a point of friction for your users; just eliminate them altogether. This is, for example, why TouchID-based devices generate more App Store transactions than devices based on the normal password system.
I'm trying to think of a single service that I log into that I don't access from multiple devices. There is one internal work application I have only used from my work computer, but even that should really be accessible from other devices.
I'm truly sick of hearing that the phone is the only device that matters. I use my phone very, very sparingly, and only when I'm away from my laptop. A phone isn't the nicest device for consuming the web, and I doubt it's even the most popular.
Your exasperation is understandable, but the popularity of phones is often backed up by trafic numbers.
‘Often’: many websites don’t see this; I’m willing to bet those I use regularly (StackOverflow, HN) aren’t even close. Most analyst describe a currently slight majority for phone metrics (except time on the site); more importantly, demographic elements suggest phone attention share will grow.
> I'm truly sick of hearing that the phone is the only device that matters.
‘Only’: OC hasn’t said exactly that -- he talked about authentification; most people don’t really say that either. Many journalists exagerate a trend and slight majority, but I would (tongue-in-cheek) blame you first for reading badly written magazines.
My experience is that authentification is safer for non-developer users on their smartphone: you have a lot more stream for consistent two-factor authentification; physical security is better for something in your pocket most of the time; it’s the only random-key generator (capable) most people have close to them. Roughly half of users users actually lock the damn thing…
Everyone (who doesn’t have ulterior motives) can agree that any kind of sign up process for something that will likely always stay on one device should at least be optional. That much should be blindingly obvious. But nice that we talked about it.
Using Facebook (or any kind of login) to solve that would be a bad idea (but many might be tempted to do it).
However, in those cases when the task is more complex than that (I just checked, that applies to eleven† of all 23 third party apps I have installed on my iPhone) that’s not a solution. I – the user – want to be able to access the data from anywhere and do actually use that functionality regularly.
Honestly, I personally would have no issue if each of those apps gave me a choice of signing up with either Google or Facebook. That would massively simplify things for me and I wouldn’t have to lug so many accounts around. I can understand the privacy concerns, so I do see the need for alternatives, but for me personally it’s not an issue.
—
† Reeder, Twitter, FB Messenger, iBooks, Pages, Keynote, Numbers, YouTube, Twitch, Vine and Dropbox; Apps that already don’t force me to log in, most because it’s just not necessary: Castro, arte, Star Guide, six game apps; Apps that force me to log in for some functionality and I’m not sure how I feel about them: iPhoto, iMovie, Remote.
In what way does multi-device login render anonymous login useless? The only difference for the application developer is that Facebook doesn't give them some additional information to store with the account up front.
If the user uses Facebook login they're already showing they trust Facebook. This just means they don't have to also trust every app developer. Also Facebook obviously can't see what your service stores against that anonymous (to you) user, so there's no real data leakage here. Your solution only works if you don't need a login at all - if you do is anybody else offering anything like this? As a user it sounds great.
Downvoted, because you could have written the exact same post without the line "You're an idiot if..." - being derogatory and putting down people who disagree with you isn't really appropriate.
If you use the device token as the authentication and identification, any other app on the device immediately gains the ability to log into your service as that user. May as well use a single password across all services which do this.
On iOS, this is only true for applications that share the same keychain, which would imply they come from the same developer. This is actually a really great under-utilized feature that could be used to create a suite of apps with different behaviors that reference the same anonymous identity.
Well, there is an inbetween - pseudonymous pretty much allows you to have your cake and eat it too. It's a little bit ingenuous that people are pretending the only options are to use your real identity (aka real Facebook account) or be completely anonymous.
MAC addresses are arguably more stable and about as easily user-modified (e.g. device tokens are wildly insecure in the presence of jailbroken devices). So: yes. And for the exact same reasons, you should never use it.
I could claim client-side certificates, but nobody uses those, and certainly not cross-platform.
You are never truly anonymous until you boot Tails and use Tor over a public wifi connection.
This is a big win for users who don't want to share their personal data with a random app developer. Facebook still sees your activity, but they already saw your activity.
Obviously this doesn't keep people 100% anonymous.
This for the millions of users that want to try apps without having to fill in multiple onerous registration fields and without having to worry that if they use facebook login, the app will spam all their friends and post to their newsfeed.
This is actually very smart, and I will be implementing it soon. Definitely not an "idiot" move for developers to implement.
I also don't think it needs to be said, but I'm going to say it anyway: this type of "anonymity" from Facebook is nothing like the true anonymity you get from something like Tor. So don't buy your drugs with an "anonymous" Facebook login.
It's a pretty significant move and a big shift towards Agent Zuckerberg's ultimate goal of replacing the internet and freedom of information and privacy.
Can someone give me some perspective on why Mozilla's Persona is not used more for authentication purposes?
Over the years, Facebook has dabbled with a bunch of different ways of apps requesting/handling user permissions and data.
This is not, actually, the first time Facebook has enabled this level of granularity, as far as users being able to grant permissions piecemeal.
It used to be (not sure if it still is) that an app could request one permission here, one permission there, at various points in its application flow. But with each request (in which you could bundle a bunch of different permissions) it was either an "all or none" decision for the user.
This new approach just makes things a little easier, because you can present all of the permissions and data request up front and let the user pick and choose what should be granted.
I think this Facebook thing is really going to take off one day.
IME when logging in via Facebook, I can choose to not allow that site to have the ability to do certain things (like not post to my wall etc)
I also develop an application that uses Facebook login, and we (using django-social-auth) request one set of permissions initially, and request more later if the user wants to do advanced stuff.
I never use Facebook Login for sites/apps, not because I don't trust the sites/apps with my FB data but because I don't trust FB with my app usage data.
Now, if I could log into Facebook without giving them access to my data, that would be a killer feature.
If a website loads the javascript facebook API on their site, and you're logged into facebook in general, they know who you are and what page you were on when the script was loaded whether you give the site permission or not.
When the http request is made to facebook, they get their domain cookie back which has your user info in it. On top of that, when their javascript runs they get full access to all the data of the window that made the request meaning they get the other site's cookie as well absolutely everything else.
If you don't want to be tracked by facebook online, you only have a few options. Disable cookies, disable javascript, or only login to facebook in an incognito window. Otherwise, they can track exactly who you are and where you go on any site that makes any request to facebook. Even still, if any request is made to facebook, they can still anonymously track you even if you aren't logged in.
As for apps, I don't think the facebook api would be able to find out the specific usage of the app unless the app purposefully gave it up, although they would know when you login.
It was when I started seeing pictures of my friends in ads on other sites, that's what creeped me out the most.
I logged out after that, and rarely log back in. I know that's only part of the battle, but it's something. As a result, if a platform requires a Facebook login, I probably won't use it.
Yes! If we are doing wishing thing, I wish I could install Android applications that require privileges I don't wont to give them. My system would still run the application but give it garbage for, for example, my GPS location or my camera image or my contact book. Also I'd like two sets of spoofed data. One obvious, second as realistic looking as possible, for applications that don't run with obviously spoofed data.
Well now that FB launched their own app ad network or audience network it looks like you may not have a choice in some cases whether or not your app usage is shared with Facebook.
You're only choice now is to not use apps that display FB ads.
As a developer and user, I love this. For many small apps, it just doesn't make sense to ask people to create a username/password, but I still want a way of authenticating them. This move gives me a way to leverage Facebook for that without users giving up any privacy. A total win/win.
Actually at least for me, the concerns are the opposite. I do not want Facebook to know what I am doing. I do not mind you getting my name (though I would consider it rude not not accept a pseudonym of my choice).
As a developer with a production mobile app that uses Facebook for more than just sign in, I hate this. It changes a lot of the fundamental things that we use in a way that is detrimental to our user's experience.
Before, login with Facebook provided a better and more convenient user experience. Now it just seems clunky. Without the information that we get from Facebook for a user that decides to sign in with Facebook, we don't even have a user.
The most important thing FB can do is win universal login. And the #1 thing it can do to promote that is restore some faith in its privacy commitment. This is a very smart move.
Of course let's see how they implement it. If the process is too complex, it won't work for users. Given their reputation on privacy - it will be hard to recover. But (almost) no other company has as good a shot at this opportunity.
I'm working on this problem right now at blockauth.com. Launch is still months away but its an interesting mix of Blockchain publishing, ICANN style franchising, and paranoid levels of verification. The end result
will be a federation of OpenID providers that all vouch for a user to confirm that they are a real unique person all while not giving any personal details about them unless they approve.
Basically its what Facebook is proposing but we do background checks on the accounts to ensure they aren't bots. Our privacy policy will be a lot more serious too. No marketing or targeted advertising.
I am the author of http://platform.qbix.com, and it includes decentralized identity. Each app can run on its own machine/cluster, and communicate with other apps. Each app is itself a user in Q.
When a person using a user-agent authenticates with an app, they can either do it natively (providing, say, their email address) or they can select an external app that they already logged into. The user-agent stores the domain of that app, and it's a simple matter of doing oAuth with that app. Except, of course, the user id isn't given out by the user's "home server" but instead a different "xid" (stands of external id) is given to each consumer app.
In short, an app can start life as a consumer of identity and eventually offer to provide identity. The identity provider doesn't just support oAuth, but ideally would allow the user to publish streams that others can subscribe to and view, import contacts and manage access control (privacy) based on those contacts and labels. Finally, they should be able to connect endpoints (such as their mobile phone, email, facebook account etc.) to receive notifications sent to their account by some apps they've authenticated with.
In the future we might also encrypt this stuff so governments and others can't get it by simply breaking into the database. I don't have any expertise in this last part, so if anyone does I'd be curious to learn.
Because every attempt to make decentralized standards has gradually failed in favour of private services. Reddit et al have replaced Newsgroups, Whatsapp has replaced Jabber, etc. This one will be no different, and the current approach where every users manages dozens of accounts and passwords is untenable and represents an even-bigger-security threat than trusting FB with Auth.
Facebook won universal login two or three years ago. It's offered as a login option on practically every website today. Twitter/Google+/LinkedIn offer no real threat at this point.
I'm bouncing between thinking this is great and this is awful. Ultimately I'm very curious how developers will use it.
The main risk seems to be what happens if Facebook decides to remove Anonymous login. You may have many accounts on your site that had logged in anonymously and participated, but now no longer have a way back in. This seems like an awful scenario, and yet a very possible one -- Facebook is quick to change and remove features on Platform.
You have to register your app with facebook, thus this feature could be removed from all new apps while still preserving existing functionality for apps registered before the feature gets removed (if it ever does get removed).
Fair point, and hopefully this qualifies under Facebook's pledge to maintain backwards compatibility for 2 years.
But of course there's also the issue that this becomes something that developers themselves can't easily remove once they add it to their app. Or worse, if Facebook decides to block a developer's app from platform. At least with regular Facebook login, most developers requested Email so users could always request that a password be sent to them as an alternate login mechanism.
Developers should be mindful that Facebook explicitly prohibits using Platform to build "competing social networks" (An unfortunately broad category): http://techcrunch.com/2013/01/24/my-precious-social-graph/ And they have a history of enforcing this with the bans of Yandex, Wonder, Vine, and Voxer.
For you, perhaps, but not for most people. There have been several occasions where I've wanted to try an app that use only FB login, but it asked for too much information, so I decided not to. Anon login would give me the ability to try these things out, and possibly give me the confidence to allow a real login. (For the record, if an app supports traditional username/email+password login, I'll prefer that, but some support only FB, and understandably so: user account management is hard.)
I'm getting a little tired with how out of touch people on HN seem, especially with regard to things like Facebook. Guess what: the majority of FB's user base does not care about privacy as much as you do. Even people who do care to an extent, and don't implicitly trust FB, are at least comfortable with some level of interaction and sharing on the platform. Anon login is targeted at people who are comfortable with what they share with FB, but are wary of giving their personal info to some random app they want to try.
Exactly this. For a site that supposedly caters to entrepreneurs, the vast majority of people here seem so out of touch I sometimes wonder how they're capable of navigating the real world.
> Guess what: the majority of FB's user base does not care about privacy as much as you do. Even people who do care to an extent, and don't implicitly trust FB, are at least comfortable with some level of interaction and sharing on the platform.
I don't mind this behavior/attitude of not caring because it has allowed many people to experiment with actively exfiltrating data out from behind these walled gardens through various means (some of which have been posted to HN from time to time over the years) without bothering going through OAuth and the like. And increasingly, users behind many of these walled gardens will see the false sense of security they have been offered when people/companies other than facebook can actively leverage and profiteer from "their" data. Once the data is out in the wild, whether facebook gives permission or not is moot.
Comment hating on Facebook gets upvote? Stop the presses.
Maybe I'm misreading you, but it sounds like you believe that upvotes on HN allow you to infer something meaningful about what real, normal people believe. Don't make that mistake. You'll be in for a rude awakening if you do.
There's an important difference between sharing information with facebook, and allowing facebook to share your information with 3rd party developers.
Pure auth has value to developers who want to verify a user without requiring a handshake of verifying an email address, having to manage against spam accounts, and so on. Yes it's possible to have multiple facebook accounts, but there's significantly more friction in facebook's system than in any home-rolled system you're going to come up with. While at the same time, significantly less friction from a "steps the user has to take to log into your app" point of view.
Nor should they! But I don't think that's an argument against this auth product, which only works if a user has an active facebook account (ie has trusted facebook with data) to begin with.
It's another developer option, one flavor among many, that developers can use to make it easier for users to log in. Given the reality that most people actually do use facebook, I think it's kind of interesting.
Didn't everyone trust Facebook to begin with. That's how the world works. You have to trust people to begin trusting them (or an organization) - else you're going to be paranoid of the world and become sick. Facebook has violated that trust multiple times.
We are in agreement re facebook violating user trust in a variety of ways. The Anonymous Authentication product is more about what goes to 3rd party developers though.
I'm just curious, what do you want to get out of using Facebook if you don't tell them anything about you? If you don't tell it who your friends are or what things you like, then what else would you do with the site?
Facebook has proven multiple times they will change settings when they please, and will do what they want with the information as they please. Platforms other than Facebook can facilitate what Facebook currently facilitates.
If you are getting products / services for free you have no right to demand that of them. Simply stop using facebook or any other social networking site for that matter.
I don't see the connection between direct payment for service and the right to demand things (not that the gp was 'demanding', but whatever...). I don't think that most paid apps codify a right for users to demand things of them, and actually terms of service for paid proprietary software have a tendency to be as restrictive as possible of end user rights. But Facebook is a service that monetizes user attention, and so I think that users are just as justified in complaining about, or trying to work around facets of Facebook that they see as misfeatures as they would be for software that they directly paid for. They don't have a lot of power to individually change anything, but they do have the right to complain in open forums. I don't think that the business model really has any bearing on this.
Corrective upvote applied. But maybe don't put a comment to your downvoter in your comments? Downvotes get fixed, and anybody can check your profile to find out whether you are associated.
You could have created another FB account just for these situation instead of waiting.
That's what I've been doing, and I will probably continue to do so since even logging in anonymously on Facebook tells Facebook, and whoever else they feel like sharing it with, e.g. advertisers, that I logged in.
Isn't that against FB TOS? Also, what a pain - at least per-site pwds are easily managed via 1Pass or LastPass, but having dozens of FB pwds sounds crazy.
- people don't trust app developers with their FB data, and don't trust app devs not to post crap to their timelines
- people hate signing up for another service again with email and password (you have to give out your email, you have to create/reuse and remember a password)
The more open question is if it will cannibalize FB logins or get incremental people to sign up with FB (people want to do this anonymously but didn't have the option and gave up).
App developers have never been responsible for a leak. I literally cannot find a reference in the Google to an app company leaking user data they were authorized by FB to hold.
You know what I can find? Facebook having leaky permissions for a year and a half.
I would hope this goes towards the iOS permission model. You would almost always login anonymously. Then pieces of information are requested on demand when a user takes action that specifically needs that information.
> In a move to bolster its new 'Anonymous' strategy, Facebook has acquired 4chan for $30 billion in an all-cash deal
> "It's been an incredible journey", said 4chan founder Christopher Poole at a press conference in Menlo Park, CA. "Our anonymous users have been the driving force behind 4chan, and we look forward to bringing that experience to Facebook"
Not really. Facebook isn't giving up any information at all. So it's nothing particularly unexpected. Actually, it's kind of up FB's alley, because it allows them to gather info on web/app usage patterns of their users while leaking a lot less info to third parties. If anything this program gives FB more control over user information relative to third parties than the current FB Connect program.
We actually implemented Facebook Connect for April Fool's back in 2010. It was a real app and posted your 4chan post(s) to your Facebook wall.
EDIT: Here's a screenshot -- http://i.imgur.com/p0peJp6.png
The best part was the reviews. They were all either 1 or 5 stars. People were shocked it actually worked.
This is the exact opposite of the product I want. The group I least want in control of my data is Facebook and their ever changing security/privacy policies.
This is what happens when users are screaming "I want my privacy back" and you are stuck between corporate goals of monetizing users and user experience.
This is the big question. I assume it is telling Facebook and NOT the app developer, so basically it's all win for Facebook and all loss for the developer who implements it (other than attracting the few extra users who care so much about their privacy that they won't divulge their Facebook data).
I'm curious what happens to functions inside the app that need identity. Do they work as normal but the app developer can't see the information? Or does everything the user does prompt for a login, so the app developer can be pretty assured that nobody will go for any length of time using the app before they give up and log in?
Facebook keeps framing thier role in providing OAUTH as one where they are protecting their users from all the bad guys on the outside. I thought it was clever marketing when I first saw them take this position but it seemed obvious to me that anybody who implemented Facebook login was giving Facebook the upper hand. One party gets free advertising and the other gets a scary looking permissions page that makes them look like an identity thief. In the process, the first party transmutes their bad press into the appreance of good will in countering the second party's apparent bad intentions.
Everybody must have caught on to Facebook's bad will psych game by now so why would anyone keep using Facebook Login?This latest change just moves the bad will to your login page. Every time someone moves to log in they will be reminded who Facebook thinks should be trusted and it's never going to be you.
Wow, it seems like they finally got rid of the minimum e-mail, profile, friends and all that jazz. Just finished reading the dev docs and it seems we can finally limit the minimum scope. Facebook can now just be used as a standard login.
Though they now need to educate users so that they don't still feel that their privacy is being violated.
The only benefit of anonymous facebook login over a native session is the supposed "cost" of creating too many accounts, and enabling things like a http://en.wikipedia.org/wiki/Sybil_attack
Actually I would like to ask if anyone here knows of more good solutions for making creating accounts expensive. Captchas ain't it anymore.
Nice one. I've been using a Chrome extension called fPrivacy to do this presently on the web, since very few websites actually check to see if they've got all the extraneous information they requested. But it sometimes breaks the login process, so it'll be nice to get rid of it.
Next top feature Facebook should introduce: Automatically generate a new anonymous email address for each app. I can then go into Facebook settings later and prevent any of those addresses from forwarding to my personal address if that app starts spamming or gets hacked. They did have an anonymous email feature at some point, but it wasn't fully ready yet.
This is a horrible idea for app developers. If someone wants to sign up for my app, but doesn't want to create a real user account with an email address and personally identifiable information, then I don't have a real customer relationship or anything of value. So, why even make them log in?
I guess I just don't see the point of requiring a user account if it isn't adding value to either the user or the app creator.
One more reason not to use Facebook as a login mechanism I guess.
> I guess I just don't see the point of requiring a user account if it isn't adding value to either the user or the app creator.
It adds plenty of value for the user: they get a logon to the app which allows them to keep information across sessions, while not providing the app vendor any information unnecessary to that function.
It provides a authentication as the same person without providing identification of who that person is.
Now, obviously, anonymous login provides less value to app developers who are using using logins to harvest personal information from users, but then, that's a plus for users.
> using logins to harvest personal information from users
Specifically, he wants some contact information so he can follow up with a lead, which I think is reasonable. Your average customer may not have time to put much effort into a product/service search and a (relevant, informative) follow-up email can be very helpful.
Ideally you do want what's best for the user, but if more revenue is coming in from the old, non-anonymous method, adoption of this one may be slow or limited.
Now if the app creator has a way to push a message back to the user (fb message or something) without knowing who they are, that might be a good compromise.
Because, it's a lot easier to just sign up using your Facebook account rather than trying to remember yet another password. But I don't want every little site to know my personal information. It's none of their business. I just want to log in quickly.
Logging in to a site provides more value than just sharing personal information. For me, I rarely, if ever, want a site to know my personal information. That's why I rarely use Facebook login service. Now I will.
Agreed, however, there are a few pieces of information that I find useful for Facebook to share. Namely my profile picture and sometimes my friends list. Though gravitar somewhat solves the profile picture problem.
1. anyone who wants to use a site has to create an account with a fb "anonymous" login. there would be no more "free" access" because then you can start to tie free user behavior to actual conversion.
2. Once the user wants to pay, this is tied to giving more information--at least name and email address.
Will be interesting to see the details, because tying free behavior to conversion is a holy grail for marketers.
This seems like a fairly natural step for Facebook, as increasing app dependency on Facebook for account authorization is a step towards building a platform.
It's a great idea in theory, but a pile of shit in reality. What's the point in using third-party authentication if you get zero data from it? Unlike Facebook, my goal is not to sell user data to the highest bidder, it's to have the user skip the steps where they enter their real name and confirm their email address.
While it certainly seems like it does you no good, I can definitely see a legitimate use case for it.
Suppose you're creating a site -- let's call it Hacker News -- that requires a user to log in, and all you care about is the part where they enter their username and password.
From there, you're able to assign the user a unique ID and persist their preferences (e.g. header color) across sessions.
It's not exactly a difficult project to roll your own login system, but Anonymous Login gives you the added advantage of being able to "upsell" users into providing more information, if they feel comfortable sharing it.
The anonymous login allows users to become less anonymous by providing real info if they wish to do so later. So you have the potential to get > 0 data.
This would basically make it easier to access or try out all the FB-only-login apps without giving the app owner all the personal info.
having FB login as an option increases your conversion rate. The more ways someone can get an account, the more likely they'll find one they like (to a point).
This is one case where Facebook is really showing Google how it's done. I mean, Google is failing to get Google Plus accepted as a social layer for Google's own pages, while Facebook is working on getting Facebook accepted as a social layer for every other site on the Internet.
We seem to start to really fail making distinction between anonymity and pseudonymity.
"Anonymous login" means you provide no identity information whatsoever. If you're "person #123456789" or "f93f9211-9f49-4bad-ad34-e00f8c536b0f" or whatever - you're not anonymous.
What is the point of this? I don't want to have to login with facebook at all. If some site has facebook login requirements I simply don't use that site anymore.
If you use facebook login for your site then you are shooting yourself in the foot if you care about users.
"If you use facebook login for your site then you are shooting yourself in the foot if you care about users." The vast majority of Internet users would disagree with you here. From the user's point of view, FB login lets you sign up to things in 2 clicks instead of having to fill out forms, most users would consider that a blessing.
I'm confused. You're actually saying the exact same thing as him and assuming something in the process. You're saying that he is not considering other people when he is actually saying the opposite: that people should think of ALL users.
I'm guessing 'What is the point of this?' got you but reading that closely is more this: not everyone is sold on the idea of FB in general as the answer to anything so an alternative product doesn't do him any favors. Like trying to sell someone who doesn't want to drink a smaller bottle of alcohol.
I don't want to sign in with Facebook full stop. I really agree that you shouldn't force people to use a third party service to sign in.
If you're contemplating login, please consider people like us! Do Facebook login as your MVP but please do consider us!
> I don't want to sign in with Facebook full stop. I really agree that you shouldn't force people to use a third party service to sign in.
You and parent are both thinking that it is Facebook's fault that third-party service providers are offering FB login.
Is it FB's fault that your favorite website is only accepting user comments unless you login with a FB account? No!
FB has done its good part. I am not here to argue with you or anyone about whether FB is respecting users' privacy and security demand. But now FB gives developers a new login option so that a site can allow users to do something like leaving a blog comment without revealing personal information such as name to the website. FB has done its good part as a platform.
If your website only offers facebook as the only option, that is not FB's fault. Should a website offer more login options? Why are services related to programming and source code usually come with a twitter or github login option instead of facebook? Because nowadays programmers tend to have a Github (or Bitbucket) account.
So why so much negativity around this new feature?
I don't think we're missing the point. We are not necessarily arguing that developers should not use it. We are hoping they choose not to use the platform _exclusively_ or as a substitute for their own login.
To use an analogy: we have small cars and someone is trying to sell us a big car. We're saying: 'What's the point?' because our desire and needs are already met by something else we have in mind. We see the product as missing a feature or not adding anything extra to the table. Think of it like wanting a mail provider that offers POP but not IMAP. I want one that uses IMAP - am I wrong?
I do not see this as negativity: it's just healthy disagreement. Otherwise every comment here would look the same.
It is unfortunate that the product we're talking about is offered as an alternative to the real thing (Facebook Connect) and it is what a developer would consider using to avoid writing their own login system. The offering does not meet our needs.
What is the point of this? I don't want to have to login with facebook at all. .
and then his reply,
Then use one of the other implementations. The problem is it being facebook, not the concept.
It's basically anti-Facebook login sentiment to me. Fine, I respect that. But,
If you use facebook login for your site then you are shooting yourself in the foot if you care about users.
You can't shoot yourself in the foot if your audience of your service can choose. As I said before, people who only offer FB as a login/sign up option is not FB's fault. In fact, any websites that don't offer the vanilla username/passwrod signup & login mechanism isn't FB's fault. So don't mix that issue in any discussion related to FB's new login mode here.
Now moving to yours:
We are hoping they choose not to use the platform _exclusively_ or as a substitute for their own login.
I will take it as you don't want to use any website not providing the vanilla username/password signup-login, right?
So again this has NOTHING to do with FB and its news announcement.
the product we're talking about is offered as an alternative to the real thing (Facebook Connect) and it is what a developer would consider using to avoid writing their own login system.
I am confused here. Do you like FB connect and like it over anyone's custom login system?
What exactly do you and parent want from Facebook's login and from app developers?
izzydata isn't just saying that he doesn't want a big car. He's saying that there's no point in buying a big car no matter what: "If you use facebook login for your site then you are shooting yourself in the foot if you care about users."
Isn't that what we are doing - we are expressing our views on a site that targets startups, site and app developers
who might be considering what login technology to use?
Afterall, those sites are under construction - they have not been created and developers can weigh the pros/cons. A site that has already been created that only offers Facebook login, I cannot use. Hence our dilemma and the importance of expressing our views in this message board.
Edit: Parent deleted so this reply may not make sense.
Let me re-emphasize. That's the point you and parent are not trying to let go. FB has no part in saying sites must use us. It is a platform. If you don't want your site to offer FB login, then don't. People out there want to use it and appreciate every new bit of privacy added to fb login, great.
what happens when people blindly trust a button and someone decides to exploit that by making a fake one open a phishing pop up requesting your Facebook credentials? Has this been done?
By the way, Facebook already knows you're using an app before you log in, when the app pings Facebook to check the login status. This only prevents usage information leaking back to the app itself.
I've used a sudonym for years. FB depresses me? I guess
because I see my friends ageing. I did reserve my real
name; in case I ever really liked FB, but I am still using
a civil war veterans name.
Seems like an interesting choice for a demo video to showcase Flipboard (i.e. regarding their own stake in this realm of products, Paper). Granted this isn't about that, but that was fun to think about.
Remember, Facebook is the same company that cuts deals with shady data brokers like the Datalogix (the company that buys your grocery store discount card data and re-sells it, among other things) to build a comprehensive profile of everything you do. Using them for this pseudo-anonymous "anonymous login" helps them a lot more than it will ever help you, as a standalone developer.
I can't wait for Facebook to trademark the term "Anonymous Login," just to complete the irony. Remember, if it was actually anonymous, you wouldn't need Facebook's help to implement it.