Re: [Wikitech-l] Let's improve our password policy
On Sun, Jan 26, 2014 at 9:49 AM, Gryllida gryll...@fastmail.fm wrote: On Sun, 26 Jan 2014, at 0:02, rupert THURNER wrote: for the password policy: display a strength indicator is great. anything more? i would say just leave it to the user. rupert. THANK YOU. My thoughts exactly. :-) Everyone who has a thought should write it on-wiki for these people to hear you without manually scanning a mailing list. Thanks. gry I once saw a can be brute forced on commodity hardware in x field instead of an abstract strength field - but phrased less techy. I liked that. ___ 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
Re: [Wikitech-l] Let's improve our password policy
fde#@%62jtgjsl$#5kgsgjgseojgro@#$%SEGsgesjojahREAGHkerahj23YJ34pwyjw3$#^WrejgshSH Time Required to Exhaustively Search this Password's Space: Online Attack Scenario: 5.04 thousand trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries Offline Fast Attack Scenario: 50.42 million trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries Massive Cracking Array Scenario: 50.42 thousand trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries Now just remember that password. On Tue, Feb 4, 2014 at 10:18 AM, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Sun, Jan 26, 2014 at 9:49 AM, Gryllida gryll...@fastmail.fm wrote: On Sun, 26 Jan 2014, at 0:02, rupert THURNER wrote: for the password policy: display a strength indicator is great. anything more? i would say just leave it to the user. rupert. THANK YOU. My thoughts exactly. :-) Everyone who has a thought should write it on-wiki for these people to hear you without manually scanning a mailing list. Thanks. gry I once saw a can be brute forced on commodity hardware in x field instead of an abstract strength field - but phrased less techy. I liked that. ___ 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
Re: [Wikitech-l] Let's improve our password policy
A three/four colour lamp + it might be forced in approx X days sounds great! Vito Inviato con AquaMail per Android http://www.aqua-mail.com Il 04 febbraio 2014 10:19:12 Martijn Hoekstra martijnhoeks...@gmail.com ha scritto: On Sun, Jan 26, 2014 at 9:49 AM, Gryllida gryll...@fastmail.fm wrote: On Sun, 26 Jan 2014, at 0:02, rupert THURNER wrote: for the password policy: display a strength indicator is great. anything more? i would say just leave it to the user. rupert. THANK YOU. My thoughts exactly. :-) Everyone who has a thought should write it on-wiki for these people to hear you without manually scanning a mailing list. Thanks. gry I once saw a can be brute forced on commodity hardware in x field instead of an abstract strength field - but phrased less techy. I liked that. ___ 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
Re: [Wikitech-l] Let's improve our password policy
On Tue, Feb 4, 2014 at 10:33 AM, Petr Bena benap...@gmail.com wrote: fde#@%62jtgjsl$#5kgsgjgseojgro@ #$%SEGsgesjojahREAGHkerahj23YJ34pwyjw3$#^WrejgshSH (...) Now just remember that password. All my passwords look like that and there is no need to remember them. You can use a password manager[1]. I am aware of the fact that most people on this list do not use one, and that people that are not technical do not even know what a password manager is. Željko -- 1: https://en.wikipedia.org/wiki/Password_manager ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Timeline Generator for mediawiki
Hi everyone, I recently came across a mentorship project at https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Provide_a_way_to_create_interactive_2D.2F3D_timelines_and_infographics_e.g._Java_applets.2C_AJAX.2C_Flash After having discussion on this topic with some people, I want to know what is the usability of this project. Is it really necessary. What features necessary to be added through this project? How this features can be visualized ( I mean live examples ) Project has been mentioned at :- 1.https://bugzilla.wikimedia.org/show_bug.cgi?id=43616 2.https://bugzilla.wikimedia.org/show_bug.cgi?id=54221https://bugzilla.wikimedia.org/show_bug.cgi?id=54221#c0 apsdehal -- Amanpreet Singh, IIT Roorkee ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
To be honest one of things I liked most on wikipedia over other sites, was no password policy whatsoever. I hope we never get into such a creepy state like oracle website which requires so complicated password that I always immediately forget it... On Tue, Feb 4, 2014 at 3:04 PM, Petr Bena benap...@gmail.com wrote: hacking into password manager might be easier than hacking into a human brain :P On Tue, Feb 4, 2014 at 11:03 AM, Željko Filipin zfili...@wikimedia.org wrote: On Tue, Feb 4, 2014 at 10:33 AM, Petr Bena benap...@gmail.com wrote: fde#@%62jtgjsl$#5kgsgjgseojgro@ #$%SEGsgesjojahREAGHkerahj23YJ34pwyjw3$#^WrejgshSH (...) Now just remember that password. All my passwords look like that and there is no need to remember them. You can use a password manager[1]. I am aware of the fact that most people on this list do not use one, and that people that are not technical do not even know what a password manager is. Željko -- 1: https://en.wikipedia.org/wiki/Password_manager ___ 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
Re: [Wikitech-l] Let's improve our password policy
hacking into password manager might be easier than hacking into a human brain :P On Tue, Feb 4, 2014 at 11:03 AM, Željko Filipin zfili...@wikimedia.org wrote: On Tue, Feb 4, 2014 at 10:33 AM, Petr Bena benap...@gmail.com wrote: fde#@%62jtgjsl$#5kgsgjgseojgro@ #$%SEGsgesjojahREAGHkerahj23YJ34pwyjw3$#^WrejgshSH (...) Now just remember that password. All my passwords look like that and there is no need to remember them. You can use a password manager[1]. I am aware of the fact that most people on this list do not use one, and that people that are not technical do not even know what a password manager is. Željko -- 1: https://en.wikipedia.org/wiki/Password_manager ___ 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
Re: [Wikitech-l] TitleValue
On Fri, Jan 24, 2014 at 8:55 PM, Daniel Kinzler dan...@brightbyte.dewrote: Am 24.01.2014 14:44, schrieb Brad Jorsch (Anomie): It looks to me like the existing patch *already is* getting too far into the Javaification, with it's proliferation of classes with single methods that need to be created or passed around. There is definitely room for discussion there. Should we have separate interfaces for parsing and formatting, or should both be covered by the same interface? Should we have a Linker interface for generating all kinds of links, or separate interfaces (and/or implementations) for different kinds of links? I don't have strong feelings about those, I'm happy to discuss the different options. I'm not sure about the right place for that discussion though - the patch? The RFC? This list? I vote mailing list. Maybe it'll be livelier. Personally, as I said in previous mails, I like the idea of pulling things out of the Title class. I'm going to pose questions and answer them in the order that they come to me. * Should linking, parsing, and formatting live outside the Title class? Yes for a bunch of reasons. At a minimum the Title class is just too large to hold in your head properly. Linking, parsing, and formatting aren't really the worst offenders but they are reasonably easy to start with. I would, though, like to keep some canonical formatting in the new TitleValue. Just a useful __toString that doesn't do anything other than print the contents in a form easy to read. * Should linking, parsing, and formatting all live together in one class outside the Title class? I've seen parsing and formatting live together before just fine as they really are the inverse of one another. If they are both massively complex then they probably ought not to live together. Linking feels like a thing that should consume the thing that does formatting. I think putting them together will start to mix metaphors too much. * Should we have a formatter (or linker or parser) for wikitext and another for html and others as we find new output formats? I'm inclined against this both because it requires tons of tiny classes that can make tracing through the code more difficult and because it implies that each implementation is substitutable for the other at any point when that isn't the case. Replacing the html formatter used in the linker with the wikitext formatter would produce unusable output. I really think that the patch should start modifying the Title object to use the the functionality that it is removing from it. I'm not sure we're ready to start deprecating methods in this patch though. In a parallel to getting the consensus to merge a start on TitleValue we need to be talking about what kind of inversion of control we're willing to have. You can't step too far down the services path without some kind of strategy to prevent one service from having to know what its dependencies dependencies are. Nik ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] TitleValue
Thanks for your input Nik! I'll add my 2¢ below. Would be great if others could chime in. I have just pushed a new version of the path, please have a look at https://gerrit.wikimedia.org/r/#/c/106517/ Am 04.02.2014 16:31, schrieb Nikolas Everett: * Should linking, parsing, and formatting live outside the Title class? Yes for a bunch of reasons. At a minimum the Title class is just too large to hold in your head properly. Linking, parsing, and formatting aren't really the worst offenders but they are reasonably easy to start with. Indeed I would, though, like to keep some canonical formatting in the new TitleValue. Just a useful __toString that doesn't do anything other than print the contents in a form easy to read. done * Should linking, parsing, and formatting all live together in one class outside the Title class? I've seen parsing and formatting live together before just fine as they really are the inverse of one another. If they are both massively complex then they probably ought not to live together. There are two questions here: should they be defined in the same interface? And should they be implemented by the same class? Perhaps the answer is no to the former, but yes to the latter... A good argument for them sharing an implementation is the fact that both formatting and parsing requires the same knowledge: Namespace names and aliases, as well as normalization rules. Linking feels like a thing that should consume the thing that does formatting. I think putting them together will start to mix metaphors too much. Indeed * Should we have a formatter (or linker or parser) for wikitext and another for html and others as we find new output formats? I'm inclined against this both because it requires tons of tiny classes that can make tracing through the code more difficult maybe, but I don't think so and because it implies that each implementation is substitutable for the other at any point when that isn't the case. Replacing the html formatter used in the linker with the wikitext formatter would produce unusable output. That's a compelling point, I'll try and fix this in the next iteration. Thanks! I really think that the patch should start modifying the Title object to use the the functionality that it is removing from it. I'm not sure we're ready to start deprecating methods in this patch though. I agree. I was reluctant to mess with Title just yet, but it makes sense to showcase the migration path and remove redundant code. In a parallel to getting the consensus to merge a start on TitleValue we need to be talking about what kind of inversion of control we're willing to have. You can't step too far down the services path without some kind of strategy to prevent one service from having to know what its dependencies dependencies are. Let's try and be clear about how inversion of control relates to dependency injection: you can have IoC without CI (e.g. hooks/listeners, etc), and DI without IoC (direct injection via constructor or setter). In fact, direct DI without IoC is generally preferable, since it is more explicit and easier to test. Specifically, passing in a kitchen sink registry object should be avoided, since it makes it hard to know what collaborators a service *actually* needs. You need IoC only if the construction of a service we need must be deferred for some reason. Prime reasons are a) performance (lazy construction of part of the object graph) b) information needed for the construction of the service is only known later (this is really a code small, indicating a design issue - the service wasn't really designed as a service). In any case, yes, we'll need IoC for DI in some cases. In my experience, the best approach usually turns out to be one of the following two: 1) provide a builder function. This is flexible and convenient. The downside is that there is no type hinting/checking, you have to trust that the callback actually implements the expected signature. A single-method factory interface can fix that, but since PHP doesn't have inline classes, these are not as convenient to use. 2) provide a registry that manages the creation and re-use of different instances of a certain kind of sing, e.g. a SerializerRegistry managing serializers for different kinds of things. We may not know in advance what kind of thing we'll need to serialize, so we need to have the registry/factory around. In the simple case, this could be handled via (1) by simply wrapping the registry in a closure, but we may want to access some extra info from the registry, e.g. which serializers are supported, etc. I don't think we should pick one over the other, just make clear when to use which approach. I can't think of a use case that isn't covered by one of the two, though. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Google Summer of Code 2014 starts NOW
Google Summer of Code 2014 has started. https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014 (Thank you Raylton for creating this page) The first step is to apply as Wikimedia organization before February 14. I can do this, with your help: * We need another org admin ready to work. I was the primary org admin in GSoC 2013 and I'm also primary/only org admin in FOSS OPW and Facebook Oen Academy. Google Code-in was different, with Andre and me really sharing the org admin role. This brought better and more reliable program administration, plus useful knowledge shared by more people for future editions. Interested? Please reply. * We need to add proposals with mentors and community buy-in under the Featured project ideas section at https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Featured_project_ideas . Either you step in now, or you wait at least six months until the next call. Interested? Just edit the page. The sooner the better. PS: I will be offline on holidays next week. I will submit the Wikimedia application before leaving, almost week before the deadline. You will be able to keep improving our proposal by improving the related wiki pages. Original Message Subject:[GSoC Mentors Announce] Now Accepting Applications for Mentoring Organizations for GSoC 2014 Date: Mon, 3 Feb 2014 11:01:15 -0800 From: Carol Smith car...@google.com Reply-To: gsoc-mentors-announce+own...@googlegroups.com To: GSoC Mentors Announce gsoc-mentors-annou...@googlegroups.com Hi all, We're pleased to announce that applications for mentoring organizations for Google Summer of Code 2014 are now being accepted [1]. If you'd like to apply to be a mentoring organization you can do so now via Melange [2]. If you have questions about how to use Melange, please see our User's Guide [3]. Please note that the application process has changed a bit from previous years: to apply you must now create your individual profile and then an organization profile before submitting your application. Please note that the application period [4] closes on 14 February at 19:00 UTC [5]. *We will not accept any late applications for any reason.* [1] - http://google-opensource.blogspot.com/2014/02/mentoring-organization-applications-now.html [2] - http://www.google-melange.com [3] - http://en.flossmanuals.net/melange/ [4] - http://www.google-melange.com/gsoc/events/google/gsoc2014 [5] - http://goo.gl/bYYgV3 Cheers, Carol -- You received this message because you are subscribed to the Google Groups Google Summer of Code Mentors Announce List group. To unsubscribe from this group and stop receiving emails from it, send an email to gsoc-mentors-announce+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/gsoc-mentors-announce. For more options, visit https://groups.google.com/groups/opt_out. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
On Tuesday, February 4, 2014, Petr Bena benap...@gmail.com wrote: To be honest one of things I liked most on wikipedia over other sites, was no password policy whatsoever. I hope we never get into such a creepy state like oracle website which requires so complicated password that I always immediately forget it... I fully agree. This is why the RFC explicitly On Tue, Feb 4, 2014 at 3:04 PM, Petr Bena benap...@gmail.comjavascript:; wrote: hacking into password manager might be easier than hacking into a human brain :P On Tue, Feb 4, 2014 at 11:03 AM, Željko Filipin zfili...@wikimedia.orgjavascript:; wrote: On Tue, Feb 4, 2014 at 10:33 AM, Petr Bena benap...@gmail.comjavascript:; wrote: fde#@%62jtgjsl$#5kgsgjgseojgro@ #$%SEGsgesjojahREAGHkerahj23YJ34pwyjw3$#^WrejgshSH (...) Now just remember that password. All my passwords look like that and there is no need to remember them. You can use a password manager[1]. I am aware of the fact that most people on this list do not use one, and that people that are not technical do not even know what a password manager is. Željko -- 1: https://en.wikipedia.org/wiki/Password_manager ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; 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
Re: [Wikitech-l] Let's improve our password policy
On Tue, Feb 4, 2014 at 11:58 AM, Steven Walling steven.wall...@gmail.comwrote: On Tuesday, February 4, 2014, Petr Bena benap...@gmail.com wrote: To be honest one of things I liked most on wikipedia over other sites, was no password policy whatsoever. I hope we never get into such a creepy state like oracle website which requires so complicated password that I always immediately forget it... I fully agree. This is why the RFC explicitly Sorry, was on my phone. I meant to say... I fully agree, and this is why the RFC is very clear that the *only immediate change proposed* is an increase in required minimum length from one character to six. It does not suggest that we require more complex character types, such as mixed upper/lower case, numbers, symbols and so on. Just increasing the length, and hopefully suggesting to users how to pick a strong password, is plenty for MediaWiki defaults. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sphinx Documentation CI Build Task
With some help from Hashar and Marktraceur I added some new CI build jobs for some fundraising stuff -- I noticed we had a job that indicates it'll build sphinx documentation so I figured I might as well add that and see where I get. ... Which is not very far -- the build fails with *19:11:58* + python setup.py build_sphinx*19:11:58* python: can't open file 'setup.py': [Errno 2] No such file or directory This makes sense; I don't have a setup.py file. But I cannot create it because I also don't know what's expected to be in that file and there doesn't seem to be anything on wikitech about this... I've used sphinx before via makefile and sphinx-build but clearly we are doing something different. Guidance please! :D ~Matt Walker Wikimedia Foundation Fundraising Technology Team ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sphinx Documentation CI Build Task
I actually answered my own question mostly. Sartoris seems to be the only project with that job enabled; and it's using python's setuptools to run sphinx. Given that my stuff is predominantly PHP and I was just going to use sphinx for nice looking documentation that's not wiki based; I'm not sure I want to introduce a setuptools dependency. Any thoughts about using some sort of documentation makefile? /me has to go read up on how we automatically build the doxygen stuff. ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Tue, Feb 4, 2014 at 2:31 PM, Matthew Walker mwal...@wikimedia.orgwrote: With some help from Hashar and Marktraceur I added some new CI build jobs for some fundraising stuff -- I noticed we had a job that indicates it'll build sphinx documentation so I figured I might as well add that and see where I get. ... Which is not very far -- the build fails with *19:11:58* + python setup.py build_sphinx*19:11:58* python: can't open file 'setup.py': [Errno 2] No such file or directory This makes sense; I don't have a setup.py file. But I cannot create it because I also don't know what's expected to be in that file and there doesn't seem to be anything on wikitech about this... I've used sphinx before via makefile and sphinx-build but clearly we are doing something different. Guidance please! :D ~Matt Walker Wikimedia Foundation Fundraising Technology Team ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla Etiquette
Today I removed the This page is currently a draft banner on https://www.mediawiki.org/wiki/Bug_management/Bugzilla_etiquette as the comment rate on its Discussion page has been very low recently, hence I assume consensus has been found. The page is the outcome of lots of discussion among numerous community members (as a Bugzilla etiquette guideline drafted: help complete it banner was shown for several weeks on mediawiki.org). I would like to thank everybody who participated and helped in creating this document! andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Etiquette
On 02/04/2014 07:05 PM, Andre Klapper wrote: Today I removed the This page is currently a draft banner on https://www.mediawiki.org/wiki/Bug_management/Bugzilla_etiquette as the comment rate on its Discussion page has been very low recently, hence I assume consensus has been found. The page is the outcome of lots of discussion among numerous community members (as a Bugzilla etiquette guideline drafted: help complete it banner was shown for several weeks on mediawiki.org). This is a good step forward. Andre, thanks for getting the ball rolling, and thanks to everyone who provided constructive feedback that helped shape the current version. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
Steven Walling wrote: I fully agree, and this is why the RFC is very clear that the *only immediate change proposed* is an increase in required minimum length from one character to six. It does not suggest that we require more complex character types, such as mixed upper/lower case, numbers, symbols and so on. Just increasing the length, and hopefully suggesting to users how to pick a strong password, is plenty for MediaWiki defaults. General consensus (on this mailing list and at the RFC) seems to be that we can certainly encourage stronger passwords, but we should not require stronger passwords for standard accounts. Accounts with escalated privileges (admin, checkuser, etc.) should likely be treated differently. Ultimately, account security is a user's prerogative. If a user wants to use wiki as his or her password, we can say that's not a great idea, but I don't see why we would outright ban it. Similarly, more complex passwords lead to people using a sticky note or similarly poor practices. Wikimedia wiki accounts are nearly valueless. Banks and even e-mail providers have reason to implement stricter authentication requirements. Meanwhile on Wikimedia wikis, there's very little incentive to log in. What's the purpose of securing such standard accounts? This has an associated cost. What's the benefit? Perhaps there are better arguments for why we should lock an unknown number of users out of their accounts every time someone upgrades MediaWiki, but currently the pros column seems a lot weaker than the cons column for implementing this change to $wgMinimalPasswordLength. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
On Wed, Feb 5, 2014 at 2:20 AM, MZMcBride z...@mzmcbride.com wrote: Ultimately, account security is a user's prerogative. [...] Banks and even e-mail providers have reason to implement stricter authentication requirements. This is conflicting logic. If it is the user's job to enforce their own account security, what reason would banks or email providers have to require long passwords? If somebody guesses a user's password and empties their bank account, the bank could care less, since it is the customer's fault for not making sure their password is long enough. Rather account security, and security in general, is a combination of both administrative oversight and user awareness. It is the system administrators' responsibility to try and make up for the fact that users are not security experts, and thus cannot be expected to take every possible measure to ensure the safety of their account. Accordingly it is our responsibility to set a password policy that ensures that users will not do something stupid, as all users are inclined to do. Of course, it is still valid that a Wikimedia wiki account is nearly valueless. However, that is probably more of a personal opinion than it is a fact. I'm sure a very heavy Wikipedia editor, who uses his/her account to make hundreds of edits a month but isn't necessarily an administrator or other higher-level user, sees their account as something more than a throwaway that can be replaced in an instant. Sure there is nothing of monetary value in the account, and no confidential information would be leaked should the account become compromised, but at the same time it has a personal value. For example, MZMcBride, what if your password is wiki, and somebody compromises your account, and changes your password and email. You don't have a committed identity, so your account is now unrecoverable. You now have to sign up for Wikipedia again, using the username MZMcBride2. Of course, all your previous edits are still accredited to your previous account, and there's no way we can confirm you are the real MZMcBride, but at least you can continue to edit Wikipedia... Obviously you are not the best example, since I'm sure you have ways of confirming your identity to the Wikimedia Foundation, but not everybody is like that. You could argue that if you consider your Wikipedia account to have that much value, you'd put in the effort to make sure it is secure. To that I say see the above paragraph. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
