RE: http://www.h-online.com/open/news/item/Mozilla-launches-beta-of-Persona-iden... (English) RE: http://www.heise.de/newsticker/meldung/Einheitliches-Web-Login-Mozilla-veroe... (German) RE: https://github.com/mozilla/browserid
I suggest, as a project for our paid contractors
* to develop a MediaWiki extension similar to https://www.mediawiki.org/wiki/Extension:OpenID * using the new open source "PERSONA" scheme
Tom (Wikinaut)
On Fri, 28 Sep 2012 13:33:44 -0700, Thomas Gries mail@tgries.de wrote:
RE: http://www.h-online.com/open/news/item/Mozilla-launches-beta-of-Persona-iden... (English) RE: http://www.heise.de/newsticker/meldung/Einheitliches-Web-Login-Mozilla-veroe... (German) RE: https://github.com/mozilla/browserid
I suggest, as a project for our paid contractors
- to develop a MediaWiki extension similar to https://www.mediawiki.org/wiki/Extension:OpenID
- using the new open source "PERSONA" scheme
Tom (Wikinaut)
What use does this have to WMF?
BrowserID/Persona currently requires JavaScript to function. So it really doesn't fit the kind of thing that we support as a standard way to login.
I don't think it's a very good use of WMF's funding.
BrowserID/Persona currently requires JavaScript to function. So it really doesn't fit the kind of thing that we support as a standard way to login.
I don't think it's a very good use of WMF's funding.
Is this the begin of a clash of civilisations between WMF and MediaWiki ?
Is this the begin of a clash of civilisations between WMF and MediaWiki ?
http://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_Foundation is the proper place to discuss that more, if you'd like to.
Am 28.09.2012 23:52, schrieb Mark Holmquist:
Is this the begin of a clash of civilisations between WMF and MediaWiki ?
http://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_Foundation is the proper place to discuss that more, if you'd like to.
No
On Fri, Sep 28, 2012 at 5:49 PM, Thomas Gries mail@tgries.de wrote:
BrowserID/Persona currently requires JavaScript to function. So it really doesn't fit the kind of thing that we support as a standard way to login.
I don't think it's a very good use of WMF's funding.
Is this the begin of a clash of civilisations between WMF and MediaWiki ?
No, but generally speaking if WMF devs are going to invest time in a project if it directly benefits the projects or third parties. There's no reason someone couldn't take this up as an extension (like any other).
As to whether this would benefit WMF--it won't. We just discussed this a month ago (see: [wikitech-l] Code ideas thread), and BrowserID was mentioned. It was said at the time that it wouldn't be useful to the WMF (privacy policy issues, if memory serves).
-Chad
Am 29.09.2012 00:03, schrieb Chad:
On Fri, Sep 28, 2012 at 5:49 PM, Thomas Gries mail@tgries.de wrote:
BrowserID/Persona currently requires JavaScript to function. So it really doesn't fit the kind of thing that we support as a standard way to login.
I don't think it's a very good use of WMF's funding.
Is this the begin of a clash of civilisations between WMF and MediaWiki ?
No, but generally speaking if WMF devs are going to invest time in a project if it directly benefits the projects or third parties. There's no reason someone couldn't take this up as an extension (like any other).
As to whether this would benefit WMF--it won't. We just discussed this a month ago (see: [wikitech-l] Code ideas thread), and BrowserID was mentioned. It was said at the time that it wouldn't be useful to the WMF (privacy policy issues, if memory serves).
-Chad
Chad,
thanks for basically positively explaining this. I think, it (BrowserId) should still remain in our focus, and we should follow the developments. My mail was mainly intended as an incentive to develop such a new extension which makes our lovely MediaWiki BrowserId compliant
- independently from what WMF will have or not because they follow different goals. This is what I have learnt from recent discussions.
What use does this have to WMF?
I think we make a lot of cool features that require JavaScript. And yes, it's not universally usable, but it's helpful to spend time on those things, because while they may not make Lynx [0] users happier, they'll probably make things easier for, e.g., people who upload a lot of files [1] or who want to switch between languages more easily [2]. People who want to log in with a central identity and don't like using Google servers seems like a pretty OK group of people to encourage.
This isn't to say that it's not worth discussing--it definitely is, and we should keep our minds open to every possible answer. Daniel, if you disagree with the above, more information would be very helpful :)
Also, implementing BrowserID would pave the way for OpenBadges [3] integration, which would be _really_ cool.
[0] https://en.wikipedia.org/wiki/Lynx_%28web_browser%29 [1] http://www.mediawiki.org/wiki/Extension:UploadWizard [2] https://www.mediawiki.org/wiki/Universal_Language_Selector [3] http://www.openbadges.org/
On Fri, 28 Sep 2012 14:57:51 -0700, Mark Holmquist mtraceur@member.fsf.org wrote:
What use does this have to WMF?
I think we make a lot of cool features that require JavaScript. And yes, it's not universally usable, but it's helpful to spend time on those things, because while they may not make Lynx [0] users happier, they'll probably make things easier for, e.g., people who upload a lot of files [1] or who want to switch between languages more easily [2]. People who want to log in with a central identity and don't like using Google servers seems like a pretty OK group of people to encourage.
This isn't to say that it's not worth discussing--it definitely is, and we should keep our minds open to every possible answer. Daniel, if you disagree with the above, more information would be very helpful :)
I'm fine with features using JS. It's just important that the feature is either an additive feature that is not necessary for use or it has a way to work without JS. In this case we're talking about login. If you disable JS... you can't even log into your own user account. And disabling JS is supposed to be an improvement to the security of logging in.
Also, implementing BrowserID would pave the way for OpenBadges [3] integration, which would be _really_ cool.
[0] https://en.wikipedia.org/wiki/Lynx_%28web_browser%29 [1] http://www.mediawiki.org/wiki/Extension:UploadWizard [2] https://www.mediawiki.org/wiki/Universal_Language_Selector [3] http://www.openbadges.org/
I'm fine with features using JS. It's just important that the feature is either an additive feature that is not necessary for use or it has a way to work without JS. In this case we're talking about login. If you disable JS... you can't even log into your own user account. And disabling JS is supposed to be an improvement to the security of logging in.
OK, here is the misunderstanding--if we implemented BrowserID, it wouldn't be the *only* way to login. It would be like OpenID, in that you could login with either a MW login or with OpenID if you have it. If you don't have JS enabled, we'll put in noscript tags that explain what you're missing.
Sound OK? Admittedly this is all hypothetical, but in case the Foundation wants to pursue this, I don't want there to be huge misunderstandings :)
On Sep 28, 2012 8:40 PM, "Mark Holmquist" mtraceur@member.fsf.org wrote:
I'm fine with features using JS. It's just important that the feature is either an additive feature that is not necessary for use or it has a way to work without JS. In this case we're talking about login. If you disable JS... you can't even log into your own user account. And disabling JS is supposed to be an improvement to the security of logging in.
OK, here is the misunderstanding--if we implemented BrowserID, it
wouldn't be the *only* way to login. It would be like OpenID, in that you could login with either a MW login or with OpenID if you have it. If you don't have JS enabled, we'll put in noscript tags that explain what you're missing.
Sound OK? Admittedly this is all hypothetical, but in case the Foundation
wants to pursue this, I don't want there to be huge misunderstandings :)
-- Mark Holmquist Contractor, Wikimedia Foundation mtraceur@member.fsf.org http://marktraceur.info
I think Mark is correct to point out that we are talking about supporting an additional login method here, not a replacement.
The key question for me is though: how many users would we really be helping by implementing browserid support right now? It sounds like not many, compared to standard login methods or OpenID.
I don't know how many people have looked at the current login form code, but it is a huge piece of shit. My team and several people active on this list have been working to try and update it, and if you're interested in making MediaWiki logins less painful, then we would love your help. There is a lot of work to be done before we think about supporting the beta release of a new standard.
____________________
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
What Steven said. On Sep 28, 2012 8:57 PM, "Steven Walling" steven.walling@gmail.com wrote:
On Sep 28, 2012 8:40 PM, "Mark Holmquist" mtraceur@member.fsf.org wrote:
I'm fine with features using JS. It's just important that the feature is either an additive feature that is not necessary for use or it has a way to work without JS. In this case we're talking about login. If you disable JS... you can't even log into your own user account. And disabling JS is supposed to be an improvement to the security of logging in.
OK, here is the misunderstanding--if we implemented BrowserID, it
wouldn't be the *only* way to login. It would be like OpenID, in that you could login with either a MW login or with OpenID if you have it. If you don't have JS enabled, we'll put in noscript tags that explain what you're missing.
Sound OK? Admittedly this is all hypothetical, but in case the Foundation
wants to pursue this, I don't want there to be huge misunderstandings :)
-- Mark Holmquist Contractor, Wikimedia Foundation mtraceur@member.fsf.org http://marktraceur.info
I think Mark is correct to point out that we are talking about supporting an additional login method here, not a replacement.
The key question for me is though: how many users would we really be helping by implementing browserid support right now? It sounds like not many, compared to standard login methods or OpenID.
I don't know how many people have looked at the current login form code, but it is a huge piece of shit. My team and several people active on this list have been working to try and update it, and if you're interested in making MediaWiki logins less painful, then we would love your help. There is a lot of work to be done before we think about supporting the beta release of a new standard.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The login form should be properly implemented as a FormSpecialPage. I have some initial code drafted for that if you want. The only big problem is supporting the various hooks in the current form.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Sep 28, 2012 at 11:59 PM, Jon Robson jdlrobson@gmail.com wrote:
What Steven said. On Sep 28, 2012 8:57 PM, "Steven Walling" steven.walling@gmail.com wrote:
On Sep 28, 2012 8:40 PM, "Mark Holmquist" mtraceur@member.fsf.org
wrote:
I'm fine with features using JS. It's just important that the feature
is
either an additive feature that is not necessary for use or it has a
way
to work without JS. In this case we're talking about login. If you disable JS... you can't even log into your own user account. And disabling JS is supposed to
be
an improvement to the security of logging in.
OK, here is the misunderstanding--if we implemented BrowserID, it
wouldn't be the *only* way to login. It would be like OpenID, in that you could login with either a MW login or with OpenID if you have it. If you don't have JS enabled, we'll put in noscript tags that explain what
you're
missing.
Sound OK? Admittedly this is all hypothetical, but in case the
Foundation
wants to pursue this, I don't want there to be huge misunderstandings :)
-- Mark Holmquist Contractor, Wikimedia Foundation mtraceur@member.fsf.org http://marktraceur.info
I think Mark is correct to point out that we are talking about supporting an additional login method here, not a replacement.
The key question for me is though: how many users would we really be helping by implementing browserid support right now? It sounds like not many, compared to standard login methods or OpenID.
I don't know how many people have looked at the current login form code, but it is a huge piece of shit. My team and several people active on this list have been working to try and update it, and if you're interested in making MediaWiki logins less painful, then we would love your help. There is a lot of work to be done before we think about supporting the beta release of a new standard.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org