Mozilla Offers Alternative To OpenID

Enigform by Anonymous Coward · 2012-01-21 01:33 · Score: 2, Interesting

Still more interesting (OpenPGP + HTTP + session management)

Microshill post by Anonymous Coward · 2012-01-21 01:36 · Score: 1, Funny

You should be using Microsoft certified Passport/Windows Live ID for all your cloud authentication needs.

What, me worry? by Anonymous Coward · 2012-01-21 01:36 · Score: 4, Funny

I have an RSA SecureID token for logging in to my company VPN and we all know how rock-solid RSA is.

Re:What, me worry? by Corwyn_123 · 2012-01-21 03:18 · Score: 1

What you need to understand, no security is absolutely perfect. There is no such thing, unless you disconnect the computer from all outside sources and influences, and allow no access to the computer, what that breaks down to is, unplug the computer, disconnect it from the internet, and lock it in a vault. And even that's not 100% secure.
Bottom Line:
Locks only keep honest people honest.
Re:What, me worry? by Surt · 2012-01-21 04:45 · Score: 4, Insightful

Locks, and security in general, are intended to raise the cost of unauthorized access beyond the utility of that access. Success by that measure is effective security.

--
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking

Useful Links by weezel · 2012-01-21 01:45 · Score: 5, Informative

This submission looks like typical content farm / blogspam junk so here's some useful links instead:

The BrowserID main page: https://www.browserid.org/
Mozilla Identity Team's blog: http://identity.mozilla.com/
Source Code: https://github.com/mozilla/browserid

--
EOF

Re:Useful Links by Saint+Aardvark · 2012-01-21 02:08 · Score: 1

I was going to post something similar but you beat me to it. Many thanks!

--
Carousel is a lie!
Re:Useful Links by icebraining · 2012-01-21 02:27 · Score: 4, Informative

I think the JS part is true, but the centralization is only temporary until there are Primary Identity Authorities (which would be mostly email providers, from what I can tell).
http://lloyd.io/how-browserid-works

--
Dilbert RSS feed
Re:Useful Links by Tacvek · 2012-01-21 09:49 · Score: 5, Informative

The way it is supposed to work (eventually)
1. User clicks sing-in link on website.
2. Website calls a Javascript function that is implemented by the browser. They pass in a callback function that takes one argument (described later).
3. The user selects an email address from a list in the browser, or chooses to add a new email address.
4. The browser checks a with the email provider (via http, and a well known location (like robots.txt or favicon.ico)) to verify that they support BrowserID. We will assume the email provider does support BrowserID. The response includes a public key for the Provider, and a provisioning url.
5. The browser opens the provisioning URL in a hidden iframe.
6. The provisioning page requests the email address from the browser.
7. If the user is already signed in goto step 10.
8. The provider indicates that the user is not signed in, and tell the browser the URL of the sign in-page, which the browser shows to the user.
9. The user signs in as normal.
10. The provisioning page asks the browser to generate a cryptographic key pair.
11. The browser passes the public key to the provisioning page, which passes it to the provider's server, which signs it (with a short expiration time) , replies with the signature , which is passed back to the browser.
12. The browser creates an assertion, which is the domain name of the site the user is trying to sign into, the email address, and a short expiration time, signed with the browser-generated private key. The assertion also includes the signed public key.
13. The browser passes the assertion into the callback, which passes it to the website's server.
14. The website's server extracts the email, fetches the provider's public key, much like the browser did. The server validates the assertion includes its domain name, and is not expired, and was signed by the included public key. It also verifies that the public key is not expired. If so, it extracts the email address, and uses it to fetch the email provider's public key. It uses that to verify that the email provider signed the public key found in the assertion.
15. The user is considered signed in by the website.
How this looks to the user
In the most common case, the user is already signed in with their email provider, so the user sees themselves clicking on the login link, picking their email adress, and that's it. They are signed in.
How this currently works
Currently there is no browser support. There is a centralized location that provides a JavaScript polyfill and associated website allowing the system to be used without browser support. Both the provider's provisioning page, and the Relying website's page must use this polyfill, and this must be one one centralized location, since both would need to use the script from the same site in order for this to work.
Currently there are also no email providers that provide this support, so a central provider is used as a fallback. This provider must be in a centralized location, since both the browser/polyfill-site and the relying party must agree on the fallback provider. This provider does the only thing it can to verify ownership of a third party email address, which is sending a standard challange email to the address, which the user will access and reply to.

--
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524

Simplicity by improfane · 2012-01-21 02:00 · Score: 5, Informative

BrowserID is pretty simple. It's basically a single Javascript function that a website can call in the browser. This example on github shows the function that is called. The clientside code is then free to make requests to the server for a specific authentication mechanism, making it very flexible. The Server code just validates the username/password.

Personally, I think it's simpler to understand than things like OpenID which are convoluted and not standardized from the user point of view. Where is the standard account management protocol for OpenID?

An older Slashdot article on BrowserID for reference: http://www.yro.slashdot.org/story/11/07/15/1216222/Mozilla-BrowserID-Decentralized-Federated-Login

Not heard of Enigform but will look into it!

--
Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,

Re:Simplicity by icebraining · 2012-01-21 02:39 · Score: 2

How is Mozilla trying to force anything?

--
Dilbert RSS feed
Re:Simplicity by sgt+scrub · 2012-01-21 03:50 · Score: 1

Am I understanding this correctly? The client sends a login request to the server. The server sends an email to another server. If there is a response to the email the user is then approved?

--
Having to work for a living is the root of all evil.
Re:Simplicity by Lincolnshire+Poacher · 2012-01-21 07:22 · Score: 1

If there is a response to the email the user is then approved?
That's the technique for the "interim"period, in which browserid.org will implement user control verification through an e-mailed link. For each e-mail address that you wish to use as an identifying token you'd have to prove that you control it through that mechanism, until your e-mail provider ( which may also be you ) implements BrowserID.
Unfortunately the end-state to which we are all supposed to move is to have our e-mail providers act as the Primary Identifying Authorities for us. browserid.org would then step out of the limelight and let the PIAs take on the burden of proving that the user controls the identifying token.
So though the pattern used ( client-authenticating certificates ) and the implementation ( JavaScript callback into the browser ) are different, if the Big Corps become the PIAs as the Mozilla team intends then the overall picture won't be any different to OpenID today, with the majority of people's online identities still at the mercy of a handful of companies.
Of course, as with OpenID there will always be a few geeks who act as their own PIAs. Just a few.
Re:Simplicity by 0123456 · 2012-01-21 07:45 · Score: 1

Asa's not a politician.
If he doesn't understand company politics, he shouldn't be making pronouncements about company policy. Particularly stupid ones like writing off the entire commercial market for your product.
Re:Simplicity by Korin43 · 2012-01-21 07:50 · Score: 3, Funny

Oh I don't know, how about when Asa Hitler...sorry, Dotzler, declared that business users didn't matter and they changed the release schedules for Firefox even despite the public outcry against it?
How dare they not let users make marketing decisions for them!

In fact it was so publically derided that Mozilla have back-pedalled and announced an "LTS" version of Firefox specifically for that purpose.
How dare they.. uh.. listen to their users.. Wait what are we angry about again?
Re:Simplicity by hairyfeet · 2012-01-21 11:34 · Score: 3, Insightful

We may not be able to brand him a flip flopper (and the Nazi ref is just tasteless and pointless) but we CAN label him a dumbass and obviously not the right man for the job when he doesn't even bother with a single survey of his actual CUSTOMERS before pulling such a bonehead stunt. Moz may be "free as in beer" but if they don't have users they can't get Google or anybody else to pay for their search results so they had damned well better listen to their users. As we saw here recently the figures show FF has been in a solid death spiral since Version 4, with it shedding more and more users by the month as they get tired of the bullshit. I myself started looking for alternative at V 4 when it started sucking on AMD CPUs and bailed on V 6 for Comodo Dragon. I still have FF installed and keep it updated as well as try each new version but so far its still sucking on AMD CPUs and the CPU spiking and RAM usage, especially on the Zacate dual cores and the older low power singles and multicores like the Phenom e series really sucks.
So instead of wasting their resources and time trying to replace a project that frankly nobody really used in the first place, how about listening to your damned customers and fixing the fricking browser, how about that? Remember the ORIGINAL mission statement, the one you used to get us off the suite, to "build the fastest and lightest standards complaint browser" remember that? Ever since Google released Chrome its been a "ohh me too!" fest at Moz and frankly it sucks. the UI sucks, the performance sucks, and I'd argue its because they are trying to jam shit on there Gecko was never made for, like flash plugin isolation, which at least on AMD causes FF to suck as much as twice the resources playing an SD video as any of the Chromium based.
And finally please fanbois, or those that have "perception bubbles" as I've been told to call you by someone who was offended at the word fanboi, please don't trot out some benchmark because i can trot out one that says the GeForce FX was actually a great Dx9 chip. Of course we all know now that they were writing to the bench which made the benches worthless but IRL all you have to do is use what I call the "Hairyfeet normal folks test" where you fire up a tool like process explorer that will give you the complete resources of a program then send the browser through the basic sites everyone goes to, YouTube, FB, Yahoo Mail/Gmail, and check the resource usage and you'll see for yourself that FF don't stack up so good.
So please moz devs, quit trying to be the saviors of the web and fix your shit first, okay? there are a hell of a lot of us that would be happy to come back to the fold if you'd just quit trying to make a bad Chrome ripoff and go back to making a small fast standards compliant browser we can DIY customize with extensions. Nobody has an extension framework as good as yours, nobody. some come back moz, quit all this crap that has nothing to do with your core business and get back in the business of making browsers because as the numbers show the way you are going now is NOT the correct way to go. kinda sad you are talking about "hiding" the LTS on some back page somewhere just because you are afraid that everyone will dump the main branch for LTS, doesn't that smack you witrh a cluebat that you are on the wrong path?

--
ACs don't waste your time replying, your posts are never seen by me.
Re:Simplicity by gmhowell · 2012-01-21 20:21 · Score: 2

Don't hold back. How do you really feel about firefox?

--
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Re:Simplicity by sgt+scrub · 2012-01-22 04:54 · Score: 1

I hope they are planing PGP (pretty freakin rare) or SMTPS (really freakin rare) to protect the content of emails. It wouldn't be very difficult to snarf "mailto:" out of an email for an ISP, or anyone [cough]NSA[/cough] else managing to get a SPAN port on an ISP's router.

--
Having to work for a living is the root of all evil.

What is wrong with OpenID? by brunes69 · 2012-01-21 02:05 · Score: 5, Insightful

- It is widely adopted among many providers
- It does not share any of your information cross-site unless you allow it
- It works

Why do we need yet another standard? I do not see anything in this article, on browserid.org, or anywhere else that breaks down why Browser ID is superior.

Also, I don't see Google Chrome adopting this, since Google backs OpenID, and I don't see Microsoft adopting it either. So really this is going to end up a Firefox only scheme that will never gain enough penetration to make sites want to go to the effort to implement it.

Re:What is wrong with OpenID? by icebraining · 2012-01-21 02:31 · Score: 5, Informative

I think the main differences are that it uses email addresses instead of an URL (which people don't "get" as being your identity token) and it doesn't give the authorities full power to access your accounts (since the private key for authentication is stored on the browser).

--
Dilbert RSS feed
Re:What is wrong with OpenID? by cdrnet · 2012-01-21 02:50 · Score: 3, Interesting

An email address is exactly what I do NOT want to provide to every second website where I just need some simple customization/profile. And where I do provide an email address, I always use a unique address (essentially allows me both automatic organization into folders but also to get less than 1-2 spam mail per year, simplify by blacklisting aliases which either leaked or obviously have been sold to some spammer (happens usually about a year after some web service/sites shuts down)). This works very well with OpenID, at least with decent neutral providers.
But then I guess BrowserID does not primarily target tech people...
Re:What is wrong with OpenID? by sgt+scrub · 2012-01-21 03:56 · Score: 1

since the private key for authentication is stored on the browser
Sounds like a safe place to keep my one password to everything. [/snark]

--
Having to work for a living is the root of all evil.
Re:What is wrong with OpenID? by tal197 · 2012-01-21 04:09 · Score: 1

I think the main differences are that it uses email addresses instead of an URL (which people don't "get" as being your identity token)
Once it's ready (supporting primary IdP's), the ID doesn't need to be an email address (just an ID with an email-like structure).

and it doesn't give the authorities full power to access your accounts (since the private key for authentication is stored on the browser).
I don't think so. That key is only accepted because it's signed by your IdP, which can just as easily sign another one if the authorities request it. The main advantages I see are:
- Verifying a login doesn't tell you're IdP who signed in to the site. The site only requests the IdP certificate, not your personal one.
- It's designed for browser support, which is necessary to prevent phishing attacks and improve ease of use. It's hard for your browser to log in to OpenID sites (e.g. the Firefox OpenID plugin(s) fail on several sites which use fancy login UIs).
- Putting more of the logic in the browser simplifies the protocol (although they seem to be adding extra complexities quite fast).
Re:What is wrong with OpenID? by Surt · 2012-01-21 04:51 · Score: 1

I think you spotted what's wrong with openId with item #2, at least as far as big corporations like mozilla are concerned.

--
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Re:What is wrong with OpenID? by dog77 · 2012-01-21 06:09 · Score: 1

Are you sure your are correct in saying Browser ID "doesn't give the authorities full power to access your accounts"? Your email authority has your email password, which is what you use to setup the certificate and keys. What information does it lack to prevent it from setting up its own keys and establishing a connection and logging into to one of your accounts?
Re:What is wrong with OpenID? by slasho81 · 2012-01-21 06:15 · Score: 1

Why do we need yet another standard?
We don't have a standard for signing in, yet. OpenID is certainly not universal. BrowserID is yet another option, and a pretty good one, IMHO. Let them compete.
Re:What is wrong with OpenID? by Tacvek · 2012-01-21 10:07 · Score: 1

The email address is most definitely transmitted to the relying party. Indeed the fetching your email adress along with proof of you owning it is the whole point. That is why the function the site calls to kick the whole process off was originally called "navigator.id.getVerifiedEmail" (although it is now renamed "navigator.id.get").
The system can work two ways. Either the browser requests a long-lasting certificate from the email provider, which means no re-authenticating until that certificate expires, or it can request a short-lived certificate, and you re-authenticate every time. However even re-authenticating every time is no big deal, since if you are already signed in with your email provider, the entire process is silent.

--
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
Re:What is wrong with OpenID? by complete+loony · 2012-01-21 12:00 · Score: 1

It all depends on the user experience. From the users point of view, they click a link, and may be prompted to enter their email provider, username and password. How can you guarantee that the web page you clicked on to start this process isn't providing their own form to fool the user and capture their password?

--
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Re:What is wrong with OpenID? by metrometro · 2012-01-21 12:04 · Score: 2

Two things wrong with OpenID --
1) It was a pain to implement. It is not widely adopted among sites I want to log in to.
2) It tells my OpenID provider (say, Google) every site I log in to. This is unacceptable to me as a solution. BrowserID only let's Google know that SOME Google user is logging in.
Re:What is wrong with OpenID? by dkf · 2012-01-21 21:22 · Score: 1

- It's designed for browser support, which is necessary to prevent phishing attacks and improve ease of use. It's hard for your browser to log in to OpenID sites (e.g. the Firefox OpenID plugin(s) fail on several sites which use fancy login UIs).
Auto-login is always problematic in security terms, even if it is exceptionally convenient.

- Putting more of the logic in the browser simplifies the protocol (although they seem to be adding extra complexities quite fast).
It simplifies the code in the part of the implementation of the protocol that is written in Javascript and sent by sites to the browser. The protocol itself is rather complex, as is the parts that are intended to be implemented in the browser's own code. It's also not clear just how much effort has been put into making things easy for the other parties in the action: if it's not easy for sites to implement, it won't get much adoption anyway. A particular issue is that not everyone uses LAMP; there's quite a few website stacks out there, and it's next to impossible to share code between them. (Also, persuading browser vendors to adopt this will be "interesting".)
I'm more concerned about how sites are going migrate to this new way of operating. How do they detect that a browser will support the protocol? How do they provide a reasonable fallback for everyone else?
Also, why do the authors seem to hate established security standards so much? What they write sounds a lot like client-certificates with SAML, "except we're doing it all in JSON so it is bound to be better!!!" OK, maybe that's misreading it slightly but really it's sounding a lot like things that others have worked on for ages, but without the benefit of actually talking to those other people to get their experience of what the pitfalls are.

--
"Little does he know, but there is no 'I' in 'Idiot'!"
Re:What is wrong with OpenID? by tal197 · 2012-01-22 04:13 · Score: 1

- It's designed for browser support, which is necessary to prevent phishing attacks and improve ease of use. It's hard for your browser to log in to OpenID sites (e.g. the Firefox OpenID plugin(s) fail on several sites which use fancy login UIs).
Auto-login is always problematic in security terms, even if it is exceptionally convenient.
I don't think anyone is suggesting auto-login (the browser logs the user in without action from the user). The issue is whether the browser can provide a login button in the chrome which, when clicked, allows the browser to handle the rest of the process securely (e.g. not displaying any random phishing site that the web-page tries to send you to). If you need to authenticate, the browser needs to ask for the password in a way that clearly shows it's OK to enter it (e.g. in a clearly-marked popup).
Re:What is wrong with OpenID? by Lennie · 2012-01-22 05:13 · Score: 1

Here are some old mockups:
http://www.flickr.com/photos/azaraskin/4128966575/sizes/l/
It is just mockups ofcourse.

--
New things are always on the horizon
Re:What is wrong with OpenID? by BZ · 2012-01-22 12:19 · Score: 1

Google and Microsoft don't have to adopt this. The system is designed such that browsers that have no native support can still work with it via a JS polyfill. So sites can deploy this right this second, even though no browser (and that includes Firefox) has native support yet.

Mozilla eh? by AbRASiON · 2012-01-21 02:07 · Score: 5, Funny

I'll wait for BrowserID v9 in 6 months

Re:Mozilla eh? by RaBiDFLY · 2012-01-21 04:06 · Score: 2

That must be a typo. Surely you meant 6 weeks.

Mixed feelings by marcello_dl · 2012-01-21 02:07 · Score: 1

It is easy to implement, with your own provider if you want.
It is not cross browser nor noscript friendly so the usual login methods will have to be kept, but that's not a big problem, one is offering a shortcut, just like openID or logins through FB, openID...

OTOH the browser acquires new functionality and an internet world ruled by a bunch of www browsers, instead of the multitude of clients of the internet 1.0, means that security issues will turn into catastrophes, like it happened with a windows monoculture.

--
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol

and how does it work? by allo · 2012-01-21 02:14 · Score: 2

The official site just says "you choose your email-adress to use and you're logged in". So, now assume i am a attacker, and i choose YOUR e-mail address ... i am logged in?!

so please some good links to the techniques behind it, especially:
- why it is decentral (is it?)
- how it is secure (is it?)
- how to set up my own server to use for myself (can i?)
- why not use openid (why?)

Re:and how does it work? by icebraining · 2012-01-21 02:35 · Score: 3, Informative

It stores a private key in your browser that you need to auth yourself (transparently to the user).

--
Dilbert RSS feed
Re:and how does it work? by allo · 2012-01-21 04:03 · Score: 1

okay, so its one of the solutions, i cannot use when using multiple computers/devices/browsers. Lets wait for the next solution, if its any better.
Re:and how does it work? by Tacvek · 2012-01-21 10:31 · Score: 1

Actually it works fine with multiple devices/compters/browsers.
One finished it will work like this:
You click login. The website calls a javascript function provided by your browser. If you pick/enter an email adress.
If you have not used the adress before the browser generates a cryptographic key pair. It contacts your email provider. If you are already signed in the provider simply signs the browser's generated public key (which includes the email address). A signed public key is also known as a certificate. If you are not signed into the email provider's site, you get redirected there, you sign in, and then the certificate generation continues.
If you have used the email address before, and the certificate is expired, the above is also done to generate a new certificate. If the certicate is not expired, it can be used without even contacting your email provider.
Your browser generates a message that contains the domain name of the site you are signing into, an and expiration date. It signs it with the private key corresponding to the certificate. It then sends the signed message, and your certificate to the website. The website verifies the message has its domain name, is not expired, that it was signed with the included certificate. Then it extracts the email address from the certificate, and uses that to get the public key of your email provider, and it verifies your certifiate with that key.
If all the verifications worked out the website now has proof that you control that email address, and you are signed in.
Oh, last but not least, while I kept saying email address, and email provider, it does not need to be a real working email address, it just needs to be shaped like one. An id like "twittername@twitter.com" could work too if Twitter decided to become an BrowserID provider.

--
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
Re:and how does it work? by DarwinSurvivor · 2012-01-22 12:08 · Score: 1

Cool, so now it impossible to access the websites from any other computer. With OpenID you can set up sms, e-mail, password, browser certificate (same as browserID appears to do), or even having a special usb button next to your home server connected to a serial port to authenticate you.

Wrong problem! by EzInKy · 2012-01-21 02:15 · Score: 1

The bigger issue today is how not to be ID'd on the internet. This is where I feel Google crossed the line to the darkside with their insistent request for phone numbers and attempts to force their "new and improved" UIs on people. Everybody and their brothers are working on getting identifying information from users. Google used to be different before they switched from focusing on aggregating "anonomys" data to gathering personal information.

--
Time is what keeps everything from happening all at once.

Re:Wrong problem! by tftp · 2012-01-21 09:48 · Score: 1

Everybody and their brothers are working on getting identifying information from users.
This is probably related to the US government starting to monitor what you are saying on the Internet.
In such conditions the only prudent thing to do is to use many different logins, and use one login for one site only. This still allows an observer to use your unique writing style to suspect authorship - but that would be far weaker than the certain knowledge that all these @posts are written by the same individual. Now all they need to do is to go and find him (by, for example, serving a National Security Letter to one of the blogs where he posts and getting his IP in real time.)
These days being paranoid is a synonym for being informed :-(

Obligatory xkcd by mattgoldey · 2012-01-21 02:23 · Score: 1, Insightful

http://xkcd.com/927/

Different problems by improfane · 2012-01-21 02:26 · Score: 4, Insightful

I think BrowserID and OpenID solve slightly different problems. BrowserID standardized the process of you logging in through your web browser while OpenID is about authenticating yourself through some authority (be it a server controlled by you or some third party). So that's a user-website interaction for BrowserID or website-website for OpenID.

They could actually be used together, any service that accepts OpenID logins could expose a BrowserID interface too.

--
Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,

Re:Different problems by icebraining · 2012-01-21 02:28 · Score: 2

OpenID is for logging in too, and BrowserID also authenticates through an authority (the Primary Identity Authorities).

--
Dilbert RSS feed
Re:Different problems by Daengbo · 2012-01-21 21:44 · Score: 1

Why not use XMPP? See my two-year old sig below.Unfortunately, OWS, a working social network, was run over by Diaspora, which was vaporware at the time. XMPP+ extensions would give you federated social for free.

--
Put identity in the browser.

Re:Centralized by icebraining · 2012-01-21 02:37 · Score: 2

It's only centralized until there are other providers. http://lloyd.io/how-browserid-works

--
Dilbert RSS feed

Duplicate story from 6 months ago by Anonymous Coward · 2012-01-21 02:38 · Score: 1

There really isn't any new news about this.

I would have thought the more appropriate Mozilla news is that they have released Rust 0.1 or general browser news that natively supported WebM browser share exceeds natively supported H.264 share

Re:Duplicate story from 6 months ago by Goaway · 2012-01-21 03:26 · Score: 1

natively supported WebM browser share exceeds natively supported H.264 share
Which matters not one bit, as long as Flash exists and supports H.264.

Re:Centralized by rtfa-troll · 2012-01-21 02:42 · Score: 2

From the web page you reference:

NOTE: You may choose to validate assertions on your own server. While a bit more complicated you can reduce your dependencies on others. Refer to the specification and the source for the reference validator.

It seems to me that there is currently a centralised server, but that that is just for temporary convenience. Did I misunderstand?

--
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();

Re:Centralized by TheRaven64 · 2012-01-21 02:51 · Score: 1

It seems to suffer from the problem that all other similar systems do: it makes it easy to tie multiple independent accounts to a single person.

--
I am TheRaven on Soylent News

Re:Centralized by icebraining · 2012-01-21 02:57 · Score: 1

Just like every sign up that asks for your email, which is almost all of them.

--
Dilbert RSS feed

Re:Centralized by cdrnet · 2012-01-21 03:39 · Score: 1

Almost all allow you to specify a different email address on every website though. I personally do that, for all kind of reasons. This also works fine with OpenID, as long as your provider allows you to configure it such that it does not provide any email address (afaik doesn't work with Google) - you're then usually asked for your email address after the first login to complete the profile, if needed.

Although BrowserID allows multiple email address, it looks like this workflow wouldn't work well in practice (with hundreds of aliases) - since instead of a neutral claim as in OpenID (which the site then maps to your profile there) you're forced to use an email address as claim instead.

Re:Simplicity = BAD by dkf · 2012-01-21 03:46 · Score: 3, Informative

https://www.browserid.org/about
No password?? Are you kidding me??
The moment I saw that 3rd step, I just.... I'm speechless. What the fuck?

When you dig into the details past all the JS crap, it's actually just a variation on client-authenticated SSL. I'm not 100% sure what exactly is being asserted in the client's identity (before checking back with the issuer) but it most certainly does work, and it should be fine provided the private keys remain locked outside of the grasp of even the browser JS. That is, the private key must provably not ever leave the browser; if anything can make that happen, it's insecure whatever the developers think.

--
"Little does he know, but there is no 'I' in 'Idiot'!"

fix the damn browser first by Lazy+Jones · 2012-01-21 04:18 · Score: 1, Interesting

Seriously, what are they thinking? HTML5 support in FF is absymal (how hard is it to implement sliders a.k.a. input type=range?), memory consumption is ridiculously high (despite all claims to the contrary), who cares about the Nth alternative for a solved problem? After they retardedly jumped 5 major version numbers in 6 months without any important changes and lost a big chunk of the market, they should slowly get their act together...

--
"I love my job, but I hate talking to people like you" (Freddie Mercury)

Re:Centralized by TheRaven64 · 2012-01-21 04:28 · Score: 1

It's easy to provide a different email address to each one. Lots of people do for spam filtering and there are even third-party sites that will give you a randomly generated email address that forwards to a real one.

--
I am TheRaven on Soylent News

Browser based... ugh D: by shish · 2012-01-21 04:31 · Score: 4, Interesting

a new browser-based system

The only problem I have with OpenID is that it's so web-centric it's a pain in the ass to implement for native apps. Could we please have a distributed ID system that *can* use a web browser, but doesn't *require* one?

--
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment

Re:Browser based... ugh D: by metrometro · 2012-01-21 12:08 · Score: 1

If only Mozilla Foundation had some sway with browser makers... wait... they are a browser maker.
BrowserID is being user tested as a standalone, but incorporating it directly into Firefox is explicitly their end game. Once there, others will follow.
Re:Browser based... ugh D: by metrometro · 2012-01-21 12:09 · Score: 1

I completely misunderstood the parent. Native apps. Derp derp derp.
Re:Browser based... ugh D: by Kalriath · 2012-01-22 00:45 · Score: 1

I'm pretty sure SAML can be used in native apps - just that almost no-one does. Ditto for OAuth (the problem with OAuth is that although it can be used for native apps, the OAuth-using services all seem to demand you open a web page so they can display their pretty auth UI).

--
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
Re:Browser based... ugh D: by Lennie · 2012-01-22 05:22 · Score: 1

Mozilla actually wants to solve that problem I hear. They are exploring ideas and haven't created a framework for it.

--
New things are always on the horizon
Re:Browser based... ugh D: by stub667 · 2012-01-22 22:22 · Score: 1

The fundamental problem is that the user needs a trusted channel between themselves and the authentication provider. The only common & cross platform communication channel is a web browser. Native apps work around this by embedding a web browser, which is insecure in that they might be stealing your password. But the user experience is sucky, and most opinions seem to be that the existing systems have sacrificed too much usability for security.
Now it is supported by Google & Facebook, XMPP might be an alternative way of communicating with the end user that would work better for native applications, at least on the desktop. I suspect mobile devices would suck a bit here.

Re:Centralized by Tacvek · 2012-01-21 11:01 · Score: 1

The centralized server does 2 things.

One it provides support for using BrowserID with browsers that do not have built-in BrowserID support. It does this by providing a JavaScript polyfill used by relying sites. This script uses the central server to provide a UI for login. This needs to be centralized, since the providers also use javascript function in the browser, and they must use the same fallback service as browsers without built-in support.

Two it provides a service to validate the assertions. This does not need to be centralized. A relying site can do this itself or use service provided by any third party it trusts. In the long term relying sites should do this themselves, but having an simple third party service makes this easier to implement an relying site.

--
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524

Re:Centralized by rtfa-troll · 2012-01-21 14:50 · Score: 1

Thanks; I had almost, but not quite, fully understood that. Now I do.

--
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();

Re:Well said, but... by Kalriath · 2012-01-22 00:31 · Score: 1

It's a handy tool written by Mark Russinovich. Formerly Sysinternals, now Microsoft.

--
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".

Re:Simplicity = BAD by Kalriath · 2012-01-22 00:34 · Score: 1

Personally, I'd be more inclined to write it off because browserid.org... does not support BrowserID.

--
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".

Re:Simplicity = BAD by Kalriath · 2012-01-22 00:37 · Score: 1

Ugh, I hate replying to myself. Reading further, it's just a plain crappy system. Yet another third party service that wants me to hand them my entire member base.

--
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".

Re:Simplicity = BAD by Lennie · 2012-01-22 05:05 · Score: 1

Then you would be wrong.

It is a system to verify your email address, but only ones.

It is a protocol, which means it can be implemented inside the browser UI, unlike OpenID (Mozilla tried that, that wouldn't work).

Browserid.org is only used because email providers and browsers don't yet support it directly.

--
New things are always on the horizon

Re:Centralized by Lennie · 2012-01-22 05:18 · Score: 1

When it is part of Firefox, someone just needs to write an extenstion to change the UI to allow for easily generating lots of browserids (verifiable email-address like things you own: let's you have you your own domain).

--
New things are always on the horizon

Re:Adoption & implimentation by Lennie · 2012-01-22 05:24 · Score: 1

The good thing about this is, Firefox has a 25%+ marketshare and this will be part of the browserUI to make it really easy.

Here is an old mockup:

http://www.flickr.com/photos/azaraskin/4128966575/sizes/l/

--
New things are always on the horizon

Re:Simplicity = BAD by Kalriath · 2012-01-22 09:46 · Score: 1

So, basically, what you're saying is that I'm right at this point in time. Gotcha.

--
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".

Slashdot Mirror

Mozilla Offers Alternative To OpenID

72 of 105 comments (clear)