Yep. I've used it for a few sites because it's simple to implement and saves me the hassle of making my own registration system. Actually, I've used it for every site I've made requiring login, except for one which sadly couldn't use it (targeting the Nintendo 3DS web browser, which is legacy WebKit).
Well, it's not abandoned, just Mozilla isn't really leading the charge now. If more people adopt it, perhaps they could be convinced to fund development once again.
OP here. Excited to start showing this stuff to the world. We think identity and login are really broken today, especially on devices that are becoming smarter (mobile, TV, etc.), and we are hoping to provide a solution that lets you take an identity with you wherever you want/need it.
Since we're not a social network, we can avoid a lot of the risk and confusion about how to use the product without accidentally sharing too much information, and really focus on building a first-class identity product.
We're happy to answer questions if you have them. There's more to come, soon!
So, the biggest draw of the social-network-based logins (as well as their biggest flaw) was that you probably already had an account. With Hoomi, what's the advantage of using your Hoomi account rather than just giving an email address?
Also, how does this compare (in both features and privacy) to Persona?
Hoomi sits somewhere between email/password login and social login. Users still get the benefit of Single Sign-on (that grows as more developers adopt), but don't have to have (or tie their account to) a social profile. You're also welcome to use your phone number to create a Hoomi account.
As far as Persona goes, one of the major differences is the primacy of mobile as a medium for login. And while Persona focuses on using email addresses as identifiers, we go one step further than that, isolating users/apps into their own ID spaces that aren't tied to any particular existing identifier. As a result, a user can change their email address with us without disrupting their service or updating their applications (https://developer.mozilla.org/en-US/Persona/The_implementor_...), and users don't have to divulge this information if it's not necessary, as with apps that just use login for personalization.
We're rapidly building and adding features to Hoomi, and you can expect to see the benefits to users and develoeprs grow as we flesh out users' ability to create profiles for themselves that they can give their apps access to.
Unlike Persona, Hoomi will be able to know which application the user logs into, and for how long, correct? From what I've seen so far, it seems like the user and/or the application will have to make requests to Hoomi's servers.
Does this mean that Hoomi will become essentially a single point of failure: if Hoomi's servers get compromised, the malicious agent will be able to collect the user's identities and activities? Especially if a lot of apps implement Hoomi, then it may even be possible for the malicious agent to profile the user's entire digital life by tracking them everywhere.
This is what Persona aimed to prevent: it delegates the responsibility of identifying users to a third party and multiple such third parties can exists. Also, as far as I remember from when I used it, it also is designed to ensure that the authenticator have no knowledge of what the user is up to.
We're encouraging developers to use this alongside social login (or as a replacement for building their own email/password-based login). Developers can avoid having to build and design large amounts of UX around login, registration, email/phone verification, password resets, etc. by adopting Hoomi, while still giving their users an alternative to social login.
We plan to add a number of compelling features for both users and developers. These will increase the value of a Hoomi account as well as the benefit of adding Hoomi login to your applications.
I'm excited for the possibilities this opens up, but I have some questions.
How does this service pay for itself? If its not a for-pay service how can I know you're not trying to amass a database of info to resell to marketers?
I like the idea of anonymous login, but how anonymous exactly is this? Of course I have to auth to your site so you know my IP, how long do you keep logs for? If I don't login for 6 months can I rest assured that my IP is gone from your logs and can't be tied to my account until I auth again?
We will eventually have some premium services that developers can get access to that will help them engage with their users or administer their services.
As for "Anonymous" login, that's Facebook's term for the service they promised (and we don't use it in our own description of the product for exactly the reasons you mentioned). We act as brokers between apps and users for their data, which includes an identifier that can be used for login. When an app chooses not to ask for personal data, we let the user know that we won't be sharing any of their information with the application.
Why would successful developers and publishers integrate Hoomi?
Is user demand for Hoomi their only incentive? Or is there a positive benefit for them as well?
If the former, it's not clear why developers would rush to support it until it accumulates a very large and uncompromising user base; and building that user base will be hard without a lot of apps/sites already integrating it.
There's definitely a benefit to developers. Hoomi provides an alternative to social login as well as an easy way to get single sign-on across their suites of applications. Furthermore, developers can adopt Hoomi rather than adding their own email/password-based login mechanism and avoid having to build screens for login, signup, email/phone verification, password reset, account management, etc. Essentially, developers can treat Hoomi as their login-as-a-service provider.
>> Hoomi provides an alternative to social login as well as an easy way to get single sign-on across their suites of applications
How does "an alternative to social login" itself benefit developers? Every other benefit you've listed out is already being provided by social login providers.
Users are reluctant to use social login given the context of social login being sharing. This sharing sometimes results in accidental sharing or over sharing with the application and its users or "friends" on the providers social network.
I'm not trying to be rude, but you're conflating developers with end-users, and didn't really answer my question.
I'm curious how developers specifically benefit from integrating with Hoomi, over other social identity providers.
Developers want to convert as many users as possible into their apps. Social login turns off individuals that care about their privacy. Developers that adopt Hoomi don't have to implement an alternative to social login.
You're exactly right. We don't require email addresses or phone numbers to be requested from users by apps. Those are just ways to get and verify a Hoomi account. Once a user authorizes an app, the app only gets a stable, unique identifier (unrelated to the email address or phone number on the account).
* Mozilla doesn't have any information on you
* Mozilla doesn't store your password if possible, and instead falls back to your email provider (but they do NOT learn which site you logged into)
* It can eventually be decentralised and browser-integrated (though this may have been abandoned)
* The site only knows your email address
I can't remember, but I don't know if Mozilla knows which sites you log into, either.