Hacker News Reader

Comment by lazyjones | Hacker News Reader

This doesn't work with JS disabled, with no indication that it doesn't work as intended (it just bounces the visitor back and forth between 2 pages).

Persona is very convenient for users, but it would be more secure to not trust a 3rd party.

View on HN

My understanding of the technology is that the endgame for persona is that you don't have to trust a third party. Instead, the authentication will be provided by the browser itself (the protocol behind Persona is called Browser ID). The current implementation is just a shim until browsers provide support for it natively.

The authentication will actually be provided by your identity provider (which will usually, but not necessarily, be your email provider).

Did they give up on the in-browser stuff? Or did I just get the plan completely wrong then?

If I recall correctly, the in-browser stuff is just a UI for selecting your email address and contacting your identity provider.

I wouln't say "just". It solves an important problem, the fact that the site you are logging in could have a javascript keylogger to read the password you are going to enter.

Oh, certainly, I meant "just" as in "just the client-side part of the protocol".

And what's the timeline for Mozilla providing it in Firefox?

As JavaScript is basically a required feature on the web these days, who cares? All web browsers that anyone tests for come with JS enabled. Anyone who runs NoScript or similar knows that when sites randomly break, they need to either enable JS or accept the fact that they can't visit that site without it.

You can run your own Persona provider, meaning you don't have to trust a 3rd party.

>As JavaScript is basically a required feature on the web these days, who cares?

People who don't live in a fantasy bubble world where that is true? "Hey, just throw away 1% of your potential user base for no reason" isn't a very compelling sales pitch.

I'd be very, very surprised if the number of people with JavaScript disabled is as high as 1%.

The number of people who have JavaScript disabled and don't know how and when to re-enable it is so small as to be irrelevant.

It's generally less than 0.5% and the few techies that do it via NoScript are well aware of what to do when things break. And you'll spend far more than 0.5% of your time and budget working to make a JS-less fallback version of all your work.

It's like supporting IE6 at this point. It's a tradeoff. And for the vast majority of us, it's a near-complete waste of resources to cater to them.

Depends... if it takes 20% of your time to make your site work for 1% of your potential users who have a feature disabled, I say forget it.

The caveat to this rule is, of course, if you have a site that is very heavily trafficked.

That's an arbitrary and useless guideline, using made up numbers. If losing 1% of your potential users costs $100k in lost sales a year, and 20% of my time costs $20k, then spending that 20% time seems like a pretty good idea.

See listed caveat. If 1% of your users are netting you 100k, your site is likely heavily trafficked.

Real teams are doing that all the time, you have to prioritize bugs, they rather fix important stuff and not care for people using IE6-8 and people using linx.

Reply on news.ycombinator.com