Persona does everything right, yet it is not being pushed forward anymore; I have my doubt as to whether it ever was. In "keeping the web open", it is such a low hanging fruit I simply don't understand the complete disinterest behind Persona - is Mozilla just waiting to see if a protocol with a cuter name comes along?
Unfortunately it isn't solving a problem that people have.
You answered this dilemma in your own message. Websites are using Google, Facebook, Twitter, GitHub, etc... for logging in. This solves a problem for publishers that want extra info on the user without asking (e.g. their email, their avatar) and users that care about privacy are simply siloing logins - e.g. I'm not connecting with Facebook for work related issues and I have a Google and a Twitter and a GitHub account too.
And surely, if it were popular, then Persona would be a good alternative. Unfortunately it has a chicken and egg problem.
> The lack of interest in pushing Persona forward has made me wildly change my stance on Mozilla.
Persona is simply an example of a product failing due to lack of interest and resources are limited - if you care so much, I'm sure they'll let you contribute ;-)
Besides, they aren't done yet.
I also push for it very hard in open source projects. This is where the change needs to happen. Wiki software such as mediawiki for example is ubiquitous, if it can be automatically configured to present the user with a Persona option a lot of people won't bother disabling it and will see it as a nice bonus.
And unlike OAuth, Persona can be readily available with zero configuration! It doesn't need API keys, that's the beauty of it!
Imagine Mozilla Persona being named Mozilla Login (recognition barrier down), being an integral part of the browser, just like Chrome does with Google Login (first use barrier down) and integrating seamlessly with Google and Facebook logins (registration barrier down).
I'd wager the user counts would be a significant percentage of Firefox users, making Mozilla Login a first-class citizen of Web Authentication APIs and breaking the chicken-and-egg problem. From there on, it'd be expectable that technical superiority could carry it to the top.
We actually did some testing along those lines, and it came back pretty negative. When "Mozilla" was too prominent, people did not expect it to work with other browsers, and wouldn't even attempt to use Persona.
For reference, I pulled this login screen from an image search on google: http://raygun.io/blog/2013/08/mozilla-persona-support/
The question must be asked: Does Persona have any chance of being used, in that context?
This branding issue can be compensated by having the browser pull out a dedicated login interface, or by really leveraging the known Mozilla brand (accepting the negative aspect you presented, which is inescapable). Without compensation, it is indeed a lost cause.
You _still_ have to pass verification details back to the Mozilla servers in order to discover whether the login information you're passed is valid, which (a) means that Mozilla can track all of your users and (b) slows everything down.
This is going to put any large site off of relying on it.
Business also prefer Twitter/Facebook/Google login, because they can get more info this way.
Persona as an alternative needs to be there and officially supported by Mozilla. I know they use it internally and "support" it, but the way they stopped all forms of promotion towards it etc makes it sound as if the protocol is abandoned.
Who cares what trendy new oauth2-based method RandomBlog#123 implements? Open source in general is very incremental. If it's there and solves a problem, it is a tool in the software engineer's belt. When it becomes apparent that companies don't permanently support their oauth2 "customers" and revoke all their API keys etc and Business asks "we can't have that happen again", then Persona becomes attractive. When updating the "log in with facebook" buttons will become tiresome because of social networks changing every few years, suddenly "logging in with the browser itself" becomes relevant.
It's an opportunity and they don't see the gain in it, but this is what "Keep the web open" is all about. Preventing every website in the world to depend on Google and Facebook's good graces. Protecting users from the really, really stupid password auth system.
The battle for federated authentication is kinda lost already. Big centralized authentication are a major advantage for both the authenthication providers (lockin) and users(information and assets provided) and consumers(ease of use).
I mean a sign in with Github is kind of awesome. You can authorize Travis or Circle to scan your repos and do their magic. Could Persona allow something like this? I kinda doubt it.
Sign in with Facebook allows you to see who of your friends is playing.
It's not meant to. Persona is not meant to replace OAuth as a data provider but as an authentication method.
When you log in with a third party auth, you don't necessarily want the site to have access to all your personal details. The reverse is also true: when you want the site to have access to your details from ShadySocialNetwork1952.ru, you don't necessarily want them to handle authentication for you.
OAuth was originally designed for sharing data. The way it works though allows for federated logins as all you are doing is checking that a person is who they say they are.
I do get a shiny icon that says sign-in and it pops a window that says I should login with given info.
EDIT: Thanks for downvotes, but I'm trying to demonstrate that those that use authentication won't really understand or value the complex background/guarantees of Persona.
The protocol does it right... it's up to marketing to sell it to the devs, and up to UX to sell it to the users.
And that is kind the crux of the issue, this protocol was a no sell to users and it didn't offer any incentive to the developer. To paraphrase your previous statement, it wasn't chicken and an egg. It was an chicken and an egg versus a goose and a golden egg.
People would pay for information/services (I think it gives you your friend graph + poking your friends) that FB connect allows you to have for free. Its users are 'taught' because developers made those logins ubiquitous, because more info on the customers. Or tighter integrations with services like Github. Or easier login experience (like StackExchange).
Except one thing: it requires cash (SSL cert[1]) you're stuck with the google/facebook/etc-style situation of having to rely on a 3rd party to maintain your identity.
It's not a popular opinion here where most people have well-paying tech jobs, but real identity and privacy on the net is something the retired, disabled, unemployed, single-parent, and other poor people need as well. Without solving this problem fist, you are simply incentivizing the current status quo and dooming any new scheme to fail.
[1] No, that SSL cert is not "cheap" when you have to live on SSDI that doesn't even cover rent/food/etc fully. The domain itself is less expensive, and can be sub-delegated between a few people.
I don't really get what you're getting at.
"The support document, provisioning page and authentication page must all be available over HTTPS, and the server's SSL certificate must be certified by a trusted CA whose certificate is in the standard Mozilla certificate bundle."
I suspect you're still stuck in the "users will just use somebody else as their identify provider" trap. We've seen where that leads - it gave us Hotmail, GMail, Facebook, G+, "MS passport", and the like. Persona, on the other hand, correctly allows anybody to host their own identity - iff you can pay for it.
"millions of users"
Stop with the narrow thinking - that's not the only use-case for encryption, as the internet is not a many-to-one medium like TV. The personal website I put up for my friends should be encrypted, just like everything else we send over the net.
And if you can't use HTTPS, nothing on your site is secure, so fussing over which authentication system you're going to critically compromise seems a bit academic.
A domain is free, if it's delegated. It's also something many people already have.
StartSSL is not an option (had problems with them pre-openssl-mess; absolutely not an option now).
This stuff misses the point, though: REAL privacy (not relying on a 3rd party like facebook) is a selling point that is becoming more popular "post-snowden". While I assume technical challenges can be made point-and-click easy over time, requiring cash is a hurdle that will shut out MANY people. Evidence: free email vs minor-fee/year email.
Right now, any competing service is already up against the hurdle of trying to get people to switch from what they currently use (facebook, google). The idea of not being tide to a big company is enough to overcome that hurdle, for at least some people. Requiring cash scraps that window of opportunity, sometimes for actual cash-availability reasons, and others for perceived reasons.
I don't see how they're worse than no security at all, which is the alternative you appear to be proposing.
VP8 is proprietary.
I'd appreciate it if downvoters could point me towards the standards body that oversees the VP8 standard. Apparently I just missed the news when it was submitted to an independent standards organisation…
(This debate makes me appreciate how RMS must feel trying to educate people about the difference between free-as-in-beer and free-as-in-freedom)
As an example, there are license pools for MP3, and companies generally pay them. Yet over the course of several years, German customs cleared out displays with mp3 players at Cebit because their creators didn't know that there's another patent to license.
Now, that isn't too bad for someone providing indemnification: It would be a matter of the pool paying that third party, and including that in their future pool fees.
"Unfortunately" a patent holder is generally allowed to control distribution entirely (eg refuse to license to any single party they dislike). Indemnification in that case would probably mean reimbursing the costs of development and production (and maybe lost future income).
For example XUL is proprietary, even though the specification is available under a CC licence, because it is controlled by a single vendor, not an open vendor-neutral standardisation process.
Unless VP8 has been submitted to some standards body that I'm unaware of it remains proprietary. Evidence of such a submission and ratification is the only thing that would be relevant to this discussion. The licence of various implementations, or any patent grants are irrelevant to its status as proprietary.
>"Proprietary" as in "sole proprietor" is appropriate for a project with zero governance, launched by Google after some incubation closed-source, dominated by Googlers.[1]
Which sounds exactly like VP8 to me (even libvpx for that matter).
For example, there are various implementations of both H.264 and VP8 that meet that definition of non-proprietary software. The licence of those implementations has no bearing on the status of the standards themselves. I could write a proprietary, closed source VP8 or H264 encoder and again that would make no difference at all to the status of the standards because it would just be an implementation.
You are, apparently. Why do you think that's what anyone else is talking about?
>For example, there are various implementations of both H.264 and VP8 that meet that definition of non-proprietary software.
H.264 is patent-encumbered.
This thread started with the quote "proprietary codecs vs vp8". That is clearly talking about standards not implementations. The very post you replied to talked about standards, standards bodies and ended with "The licence of various implementations […] are irrelevant to its status as proprietary".
>H.264 is patent-encumbered.
I've no idea what you are getting at here. You seem to still be confusing standards and implementations. Are saying that software that is affected by patent claims must be proprietary? x264 is proprietary? LAME is proprietary? ffmpeg is proprietary? Are you aware of the huge number of extremely broad software patents that have been granted? Just about any non-trivial software will infringe some patent or other.
A codec is an implementation. http://en.wikipedia.org/wiki/Codec "A codec is a device or computer program"
>Are saying that software that is affected by patent claims must be proprietary?
Yes, I'm saying that if a piece of software cannot be freely distributed and used because of intellectual property laws, it is proprietary.
>Are you aware of the huge number of extremely broad software patents that have been granted? Just about any non-trivial software will infringe some patent or other.
In practice, it all depends on to what extent the patents are enforced. Real-world usage of "proprietary" reflects practicalities.
and "VP8" is a standard not an implementation (libvpx is an implementation). So the original comment was not clear, but in the context of Mozilla pushing VP8 as video standard for the web it would be very strange if the original poster had meant implementations rather than standards. Unless Mozilla are advocating that everybody use a specific implementation of VP8, but that would be hugely hypocritical and inconsistent after their war against WebDB/SQLite.
>Yes, I'm saying that if a piece of software cannot be freely distributed and used because of intellectual property laws, it is proprietary.
I think that is a ridiculous definition. That means all VP8 implementations are proprietary[1]. In a world of submarine patents and patent trolls your definition of proprietary is meaningless because any software could become proprietary at any time when a previously unknown or unenforced patent starts being enforced. Additionally, it's a definition that is very location specific - many of these software patents are not valid or recognised in most of the world. I don't have much interest in the US legal system being forced upon me by people obsessed with US patent law when I'm not a US citizen or resident.
[1] They are encumbered by these patents: http://datatracker.ietf.org/ipr/2035/ and Nokia have actively brought cases against HTC over some of those patents (see http://www.scribd.com/doc/143400898/Nokia-VP8-Infringement-C... ).
It's apparently called "libvpx" internally, but the project page refers to it as "the VP8 video codec, a high quality, royalty free, open source codec". http://www.webmproject.org/docs/vp8-sdk/index.html
>So the original comment was not clear, but in the context of Mozilla pushing VP8 as video standard for the web it would be very strange if the original poster had meant implementations rather than standards.
No one on this thread besides you has said anything about standards. The original comment included "proprietary codecs vs vp8" on a list of positive things Mozilla has done, which also included other implementation-specific things like "javascript performance".
>Unless Mozilla are advocating that everybody use a specific implementation of VP8, but that would be hugely hypocritical and inconsistent after their war against WebDB/SQLite.
Mozilla is, in their own browser, using a codec (read as: implementation) which isn't proprietary. This has two positive effects: it keeps Firefox from becoming proprietary; and it also helps push other browsers to implement the same video format (either using the same codec or not), which helps increase the format's marketshare, meaning that more videos on the Web can be viewed using a non-proprietary codec (implementation).
>In a world of submarine patents and patent trolls your definition of proprietary is meaningless because any software could become proprietary at any time when a previously unknown or unenforced patent starts being enforced.
It's not meaningless, it's just somewhat fuzzy. I think you're committing the continuum fallacy here. A piece of software which I can only use if I pay the patent owner a million dollars is clearly proprietary. A piece of software which is more than 20 years old is clearly not proprietary (unless it's proprietary for copyright reasons), since any patents would have expired. In between are some gray areas, but that doesn't invalidate the overall concept. As a practical matter, it's useful to only consider software proprietary on patent grounds if there is a specific patent holder who has asserted a specific patent against it.
>Additionally, it's a definition that is very location specific - many of these software patents are not valid or recognised in most of the world. I don't have much interest in the US legal system being forced upon me by people obsessed with US patent law when I'm not a US citizen or resident.
So, you think it doesn't matter if people in the US can't see videos on the Web without paying for a patent license as long as it doesn't affect you directly?
>Nokia have actively brought cases against HTC over some of those patents.
Wikipedia mentions that a German court ruled against Nokia.
Why did you leave? I'm interviewing there at the moment and would love some pointers
They have some bad reviews recently on glassdoor but everyone there seems pretty passionate
Just read the reviews. I left in 2011, before the FirefoxOS stuff had really kicked off. I can believe the strategic direction complaints in the reviews, but I didn't experience it too much myself.
But one doesn't need to care a lot about money in order for money to become a major factor, perhaps unconsciously, in your long-term decision-making. I remember there being public anxiety whenever there was doubt about whether Google would renew the search deal. Over time, that kind of anxiety takes a toll. Perhaps it's less of a concern for ordinary employees, but top-level executives definitely think about money a lot. $300M/yr is a lot of money to take for granted.
That's why long-lived organizations have internal checks and balances. Even if the individuals eventually fail sometimes, the organization can identify and self-correct.
Checks and balances are for preventing individuals' interests from swaying the organization. They're useless when the whole organization's interest, or even survival, is at stake.
Mozilla is almost completely dependent on its partnership with Google, and apparently, the majority of Mozilla's board members are okay with this. And of course this decision has everything to do with the fact that 90%+ of the organization's revenue would evaporate if they refused the partnership.
Instead of debating theoretical scenarios, wouldn't you like to describe what such a situation would look like so we could reason what layers of internal or external controls would have to kick in so the issue could be corrected?
As a former Mozillian, I can't begin to describe how inaccurate this is. Discussion of money, or revenue, were relatively rare compared to the things that Mozillians actually care about. Here's a list of things that were discussed about 100x more than advertising revenue:
- building the mozilla community - open source - rust and servo - where to go for lunch - javascript performance - keeping the web open - making firefox builds fast - firefox memory usage - proprietary codecs vs vp8