FANDOM


  • TimmyQuivy
    TimmyQuivy closed this thread because:
    18:10, August 17, 2015

    Hello Wikia.

    I would like to provide some updates about the weekend security actions and some clarity about what changes Wikia will be making around customizations in the near and long-term.

    First and foremost, here’s where we stand today. The MediaWiki namespace was locked down starting Monday so that only staff can edit. We have begun to ease these restrictions by opening editing of the MediaWiki namespace back to admins on the communities that use those pages the most. Editing on the most used MediaWiki pages - Common.css, Wikia.css, Monobook.css, Wiki-navigation, and Community-corner - is open to all admins. For now, editing of *.js pages specifically will continue to be restricted to staff only, but we also anticipate removing these edit restrictions for some community admins next week, along with allowing users to edit their own personal JS. We will continue to examine and scale these abilities out over the next few weeks.

    Now for some words on how Wikia plans to move forward.

    With regards to JavaScript, Wikia is looking to move towards a code review system that will hopefully improve collaboration between communities and make the reuse of code a simple task. Admins will be able to write JS and submit it for review. Then a group will review code changes to ensure they are both secure and don’t include any major breaking changes. Changes will not go live until they do. There is also the vision of a code library as part of this change, in which admins can easily import bits of common, pre-approved code so they don’t have to write it out locally. This is something we are definitely aiming to do before the end of the year and currently we are targeting early autumn for the first tests and beta versions.

    With regards to the Verbatim extension, we are currently running analytics to determine the most common use cases of the tool as it stands today. The goal is to ultimately turn these big needs from being used in the catch-all solution of Verbatim to a more secure, structured, and built-out tool. A great example of this is Twitter feed integration into a community. An in-house tool to embed these feeds should be a lot simpler than the current Verbatim method.

    Once we have firmer dates and products to demonstrate, we will share more on the Staff Blog. Thanks again to the community for your continued patience as we work towards ensuring a safer environment for you all, while retaining the work you’ve done to make your communities as awesome as they are today.

    Edit 1: Posted this response to widely address some concerns and follow up questions raised in the replies.

    Edit 2: JavaScript editing ability is returning over the span of this coming week. Read more here.

      Loading editor
    • This is mainly a message about the lifting of the emergency restrictions, but has anything been decided about login security?

        Loading editor
    • Helios, a new authentication platform, is already close to being rolled out.

        Loading editor
    • So, to get it straight, no one can add *any* JS without approval?

      Shyguy-emoticon.gifJoey (talk)

        Loading editor
    • Josephyr wrote:
      So, to get it straight, no one can add *any* JS without approval?

      I hope that isn't the case.

      Also, I hope Twitter won't be forced to be used wtih verbatim code. My firewalls block Twitter, disabling verbatim code on accident!!!

        Loading editor
    • What about removing the edit restriction from personal js pages?

        Loading editor
    • Slyst wrote:
      What about removing the edit restriction from personal js pages?

      And CSS pages. And why not have a blacklist of uneditable pages? Pages like this one are still locked despite being perfectly fine as such?

        Loading editor
    • Personal CSS pages are editable - MediaWiki pages are still under protection.

      Shyguy-emoticon.gifJoey (talk)

        Loading editor
    • Code review system, verbatim changes. Сan you just move the form to login on a separate, protected from the custom js site or it isnt solution (phishing/etc.)?

        Loading editor
    • So then, will there be an exact date where JavaScript will be editable once more?

        Loading editor
    • Stop making unnecessary and destructive changes to things that weren't broken to begin with.

      Line spacing there is broken. Unfixed. I can't customize my toolbar on Chrome for some reason. Unfixed. And yet we're getting updates to stuff that wasn't problematic to begin with. I don't even...

        Loading editor
    • DaNASCAT wrote:

      With regards to JavaScript, Wikia is looking to move towards a code review system that will hopefully improve collaboration between communities and make the reuse of code a simple task. Admins will be able to write JS and submit it for review. Then a group will review code changes to ensure they are both secure and don’t include any major breaking changes. Changes will not go live until they do. There is also the vision of a code library as part of this change, in which admins can easily import bits of common, pre-approved code so they don’t have to write it out locally. This is something we are definitely aiming to do before the end of the year and currently we are targeting early autumn for the first tests and beta versions.


      Great. We basically reached a similar conclusion in c:dev that a code review system similar to the Extension:gadgets is the only possible way forward. Also, I'm wondering about who will review this code?

      I disagree with the idea that people who have the admin or bureaucrat rights are automatically competent in using javascript and coding. In c:dev the only requirement seems to basically paste some scripts there and you're automatically "competent". 

      A more viable alternative is maybe to partner up with either code-academy to create an introduction and advanced course for mediawiki hacking (creating js and such), and allowing only people who have shown their competence there as code-editors/reviewers along with any criteria wikia chooses.  Wikimedia has at least created the basic foundations. Since we are on the subject of coding, I think something could also be done for lua modules. It would be possible to create a tutorial using javascript for module development in a wikia. I know they aren't generally security risks, but given enough time some coder is likely to find an exploit.

      Thanks for the heads up!

        Loading editor
    • Security is our top priority as we work through these updates. We cannot provide very specific dates for updates because we want to get them live whenever they are ready.

      We are working to remove restrictions on personal JS pages as well. (Edit: added this to the original post)

      Please be aware that our plans are fluid, and the list here is not exhaustive - we definitely welcome feedback as we work on various fronts.

        Loading editor
    • Kirkburn wrote:
      Security is our top priority as we work through these updates. We cannot provide very specific dates for updates because we want to get them live whenever they are ready.

      We are working to remove restrictions on personal JS pages as well.

      Please be aware that our plans are fluid, and the list here is not exhaustive - we definitely welcome feedback as we work on various fronts.

      Do you mind blacklisting MediaWiki pages to not edit? That works better when custom MediaWiki pages are made that must be constantly updated.

        Loading editor
    • so by code library, couldn't we just use dev wiki for that purpose?

      I really do hope that any CSS written will also be reviewed as well in addition to personal css/js, never know when someone's able to mess something up without being able to fix it on their own, ie no ability to click edit button because its covered up.

      @Dessamator well now giving out codeeditor is decided by cqm so should be more secure, besides the experienced people test their code elsewhere before importing it. perhaps removal of codeeditor rights from those who were just copy-paste code should be considered. i agree that not admins/bureaucrats are all competent in css or js or even both.

      the best outcome would be to have codeeditors, volunteer developers or even staff review if this "code library" is to be the dev wiki.

      if the editinterface user right is removed from admins/Bcrats and given to competent people, might be trouble some to ask them for help - would get annoying to request something or just to import scripts. the wikis are not independant which makes having a dedicated group harder, there are not that many people competent anyways.

        Loading editor
    • Brainulator9 wrote:

      Do you mind blacklisting MediaWiki pages to not edit? That works better when custom MediaWiki pages are made that must be constantly updated.

      We're looking at ideas around this, though don't have specific to announce at the moment. If you have specific MediaWiki messages that you think should be whitelisted for editing around Wikia, please feel free to send a note into Special:Contact about it - we do certainly anticipate expanding the current whitelist.

        Loading editor
    • Is codeeditor a different usergroup that bureaucrats can toggle to edit code page? I'm up for that, actually.

        Loading editor
    • Nerfmaster8
      Nerfmaster8 removed this reply because:
      19:39, August 14, 2015
      This reply has been removed
    • Brainulator9 wrote:
      Is codeeditor a different usergroup that bureaucrats can toggle to edit code page? I'm up for that, actually.

      its only at the dev wiki and  that would be bad security. not everyone is competent with css, js or both as Dessamator mentioned above.

        Loading editor
    • Nerfmaster8 wrote: I really do hope that any CSS written will also be reviewed as well in addition to personal css/js, never know when someone's able to mess something up without being able to fix it on their own, ie no ability to click edit button because its covered up.

      You can disable personal css with ?useusercss=0 parameter, and css from these pages shouldn't be applied while editing them too – just add ?action=edit to the url. Imo code review on personal pages will add unnecessary work for reviewers.

        Loading editor
    • Nanaki wrote:

      Nerfmaster8 wrote: I really do hope that any CSS written will also be reviewed as well in addition to personal css/js, never know when someone's able to mess something up without being able to fix it on their own, ie no ability to click edit button because its covered up.

      You can disable personal css with ?useusercss=0 parameter, and css from these pages shouldn't be applied while editing them – just add ?action=edit to the url.

      oh never knew that

        Loading editor
    • Nerfmaster8 wrote:

      Nanaki wrote:

      Nerfmaster8 wrote: I really do hope that any CSS written will also be reviewed as well in addition to personal css/js, never know when someone's able to mess something up without being able to fix it on their own, ie no ability to click edit button because its covered up.

      You can disable personal css with ?useusercss=0 parameter, and css from these pages shouldn't be applied while editing them – just add ?action=edit to the url.

      oh never knew that

      There's a full set of these:

      • ?useusercss=0
      • ?useuserjs=0
      • ?usesitecss=0
      • ?usesitejs=0
        Loading editor
    • Nanaki wrote:

      Nerfmaster8 wrote:

      Nanaki wrote:

      Nerfmaster8 wrote: I really do hope that any CSS written will also be reviewed as well in addition to personal css/js, never know when someone's able to mess something up without being able to fix it on their own, ie no ability to click edit button because its covered up.

      You can disable personal css with ?useusercss=0 parameter, and css from these pages shouldn't be applied while editing them – just add ?action=edit to the url.
      oh never knew that
      There's a full set of these:
      • ?useusercss=0
      • ?useuserjs=0
      • ?usesitecss=0
      • ?usesitejs=0

      thanks, let me add that to a blog in case someone ever complains about screwing something up and actually needs to disable ether or both

        Loading editor
    • I'm not really liking this solution. :/

      Can't the login form just be moved?

      Or will the code review be really quick? Then I wouldn't mind it as much. If this is going to be a custom user group it probably won't be that bad. I still don't really like it though.

        Loading editor
    • Thanks for the updates on these issues, and for these much-needed improvements in wiki security!

      Any plans for JS editing on Dev Wiki to be re-enabled soon? I'd like to make a few fixes/changes to a script there I wrote, but all JavaScript files are locked down.

        Loading editor
    • Just great... now after this we have to submit them for approval? -_-

        Loading editor
    • Nanaki wrote:

      You can disable personal css with ?useusercss=0 parameter, and css from these pages shouldn't be applied while editing them too – just add ?action=edit to the url. Imo code review on personal pages will add unnecessary work for reviewers.

      I never knew that. Thanks!

        Loading editor
    • OneTwoThreeFall wrote:
      Thanks for the updates on these issues!

      Any plans for JS editing on Dev Wiki to be re-enabled soon? I'd like to make a few fixes/changes to a script there I wrote, but all JavaScript files are locked down.

      How you plan do it if since now no-one (js/wiki-editor) can be trusted?


      #1:
      With regards to the Verbatim extension, we are currently running analytics to determine the most common use cases of the tool as it stands today.

      Most=/=all. Apparently you will go from a free to embed html code to so-called templates with special logic: radio/tag cloud etc. the usual practice of the "sites hosting".


      Сan you explain what is the security problem and why it was discovered and was resolved only now?

      • using translator
        Loading editor
    • I hope the turn-over time for JavaScript review is pretty quick. The longer we have to wait after every edit, the less likely I'm going to feel like editing JS.

        Loading editor
    • I really need to edit my wikia so is there a time it will be opened specifically? 

        Loading editor
    • DEmersonJMFM wrote: I hope the turn-over time for JavaScript review is pretty quick. The longer we have to wait after every edit, the less likely I'm going to feel like editing JS.

      Exactly. Having a designated group for "approving" JS is a safe route to go for now... but it's going to be straining on new and old people who are trying to learn JS on their own.

        Loading editor
    • Vogel100 wrote: I'm not really liking this solution. :/

      Can't the login form just be moved?

      Or will the code review be really quick? Then I wouldn't mind it as much. If this is going to be a custom user group it probably won't be that bad. I still don't really like it though.

      This isn't just about the login form issue (which will be eliminated by Helios anyways). Users shouldn't add arbitrary Javascript that affects everyone who browses to the wiki. It's a miracle it was not exploited that often.

        Loading editor
    • Hi, I am an admin on the Pretty Little Liars Wikia and I understand you guys had a problem with a hack on the wikia servers last week and had to disable javascript. Has the issue been fixed 100%? Cause we still can't edit our CSS as much as before and all of our colored usernames we had for the admins are gone... How can this be fixed? 

        Loading editor
    • TK-999 wrote:

      you got any further info as to what Helios is?

        Loading editor
    • Its laconical description (https://github.com/Wikia/app/blob/dev/extensions/wikia/Helios/Helios.setup.php ) summarizes it as a "Wikia approach to user authentication." IMO it should address most shortcomings and security issues of the current system.

        Loading editor
    • Fearless Diva wrote:
      Hi, I am an admin on the Pretty Little Liars Wikia and I understand you guys had a problem with a hack on the wikia servers last week and had to disable javascript. Has the issue been fixed 100%? Cause we still can't edit our CSS as much as before and all of our colored usernames we had for the admins are gone... How can this be fixed? 

      core mediawiki is back to editable, kirkburn did update on that along with community corner

      there isn't a timeline

        Loading editor
    • DaNASCAT wrote: With regards to the Verbatim extension, we are currently running analytics to determine the most common use cases of the tool as it stands today.

      Please make an option for a "mobile mainpage" then. Since many communities use templates for mainpage, you don't have to worry about the two pages getting out of date. Or create "mobile only" / "desktop only" tags (since currently to hide things on mobile you have to "cheat" by importing CSS in the mobile header and add a "mobile hide" class which doesn't work on wikia apps anyways).

      Also, please keep in mind that some of us end up realizing we need to tweak stuff 4-5 times after submitting a change, so make sure the form allows us to overwrite our submission with something new.

      I'm glad your taking our security seriously (even though I don't expect this code-review system to go very smoothly in practice), and while your looking at javascript / css fundamental changes, I hope you consider giving us a little more mobile control (even if the wikia apps limit this somewhat).

      DaNASCAT wrote: There is also the vision of a code library as part of this change, in which admins can easily import bits of common, pre-approved code so they don’t have to write it out locally.

      So kinda like dev wiki imports, but maybe with a check list on WikiFeatures / special:preferences?

      Edit: Also, will the effect personal js pages? I'm just asking since I can use whatever js I want with an addon, but would prefer not to since I access Wikia on two different computers.

        Loading editor
    • Nerfmaster8 wrote:
      Fearless Diva wrote:
      Hi, I am an admin on the Pretty Little Liars Wikia and I understand you guys had a problem with a hack on the wikia servers last week and had to disable javascript. Has the issue been fixed 100%? Cause we still can't edit our CSS as much as before and all of our colored usernames we had for the admins are gone... How can this be fixed? 
      core mediawiki is back to editable, kirkburn did update on that along with community corner

      there isn't a timeline

      Thank you for the quick answer. Guess its just a wait and see then.

        Loading editor
    • As much as a code review system may help some, it would make js editing on a wiki where I'm the only one there near impossible. I expect the amount of time it'll take for the review process will be about as long as it takes to get a real response from Wikia.

      This is frustrating, I got a test wiki and now I can't even test js on it. I already have changes I'm thinking about...


      Will examples of its use go along with the pieces of code in the code library, as well as details on what things are needed to go along with it?

        Loading editor
    • EternalLocket wrote: As much as a code review system may help some, it would make js editing on a wiki where I'm the only one there near impossible. I expect the amount of time it'll take for the review process will be about as long as it takes to get a real response from Wikia.

      This is frustrating, I got a test wiki and now I can't even test js on it. I already have changes I'm thinking about...


      Will examples of its use go along with the pieces of code in the code library, as well as details on what things are needed to go along with it?

      Especially since testing can't be done in preview - do you need to have 10 permissions for 10 minor fixes?

      Alternatively, maybe certain personal test wikis could be whitelisted?

        Loading editor
    • Tupka217 wrote:

      EternalLocket wrote: As much as a code review system may help some, it would make js editing on a wiki where I'm the only one there near impossible. I expect the amount of time it'll take for the review process will be about as long as it takes to get a real response from Wikia.

      This is frustrating, I got a test wiki and now I can't even test js on it. I already have changes I'm thinking about...


      Will examples of its use go along with the pieces of code in the code library, as well as details on what things are needed to go along with it?

      Especially since testing can't be done in preview - do you need to have 10 permissions for 10 minor fixes?

      Alternatively, maybe certain personal test wikis could be whitelisted?

      Plus, people have things coded so that it works for them. So anyone wanting to copy them would need to at least see the source of all the things affected by that code.

      It wouldn't matter if the test wikis are whitelisted, if you can't use the code on any other wiki.

      I think I take back what I previously said, I feel review times will be quite long which is even more frustrating.

        Loading editor
    • Tupka217 wrote:

      Especially since testing can't be done in preview - do you need to have 10 permissions for 10 minor fixes?

      Alternatively, maybe certain personal test wikis could be whitelisted?

      Testing for most things can be done in preview in MonoBook skin, or in your browser console.

        Loading editor
    • Reading between the lines, you want to get rid of verbatim?

        Loading editor
    • Real coders use the console to test JS things.. That's like the basics. For CSS, you can use w:c:dev:PortableCSSPad.

        Loading editor
    • Jr Mime wrote: Real coders use the console to test JS things.. That's like the basics. For CSS, you can use w:c:dev:PortableCSSPad.

      So... Instead of adding to the discussion, you're just gonna take a jab at others who do things a different way?

      The point is there's a wait time, regardless of how large the change you're making. Chances are that Wikia will be swamped when they open up the review process, meaning wait times will likely be very long.

      Edit: I never claimed to be a "real coder" :/

        Loading editor
    • What do you mean different way? Every single person I know uses console to test JS things, they never publish an unfinished code (unless they have to go).

        Loading editor
    • Jr Mime wrote: What do you mean different way? Every single person I know uses console to test JS things, they never publish an unfinished code (unless they have to go).

      That doesn't make you right. There are various places where people can go to test code, that would have less of an effect on the users end. When I think I've finished I try it on my test wiki and see how things go. If it's not working as intended, I remove it and check to see where I went wrong.

        Loading editor
    • EternalLocket wrote:

      Jr Mime wrote: What do you mean different way? Every single person I know uses console to test JS things, they never publish an unfinished code (unless they have to go).

      That doesn't make you right. There are various places where people can go to test code, that would have less of an effect on the users end. When I think I've finished I try it on my test wiki and see how things go. If it's not working as intended, I remove it and check to see where I went wrong.

      It's highly unlikely Wikia would whitelist certain test wikis—nasties could just ask for a whitelist, then abuse this privilege. What Mime is suggesting that this change will not break your testing procedure—JS consoles are functionally equivalent to putting the code on a test wiki, so you can still test the code to ensure it works as intended before letting it go live. :)

        Loading editor
    • Is Java Script programming really an admin function?

      Now don't get me wrong, I know that lots of admins are also programmers/coders but that's not what being an admin is about. I'm willing to bet that a lot of good admins can't code their way out of a paper bag, and that a lot of people who are very good at Java Script aren't really ready to be an admin yet. (for example, the numpty who started all this by hacking wikia)

      I think you're conflating two roles here, one of which we don't have at the moment, Trusted Developer and Admin. Maybe you need a class of user who is entitled to submit JS for review but who isn't an admin.

        Loading editor
    • What about chat.css?

        Loading editor
    • As an administrator and bureaucrat on several wikis for many years now I completely disagree on these new changes

      The JavaScript coding on wikis can be used to enrich and add fun to wiki communities and sites, such as changing user-identity-box-group MediaWiki pages to change "Admin" tags into "Black Widow" for example on a Pretty Little Liars Wiki or a "SpearLeader" on a Britney Spears Wiki ...  The .js of wikis were also previously editable which allowed admins to add special features (see http://gossipgirl.wikia.com/wiki/MediaWiki:Common.js) from w:c:dev to allow  new features to be enabled like an additional view source button, wall greeting edit button,  and a Reveal Anon IP code which shows the IP addresses in wiki activity so you don't have to click each time if multiple anons are spamming, it's easier to keep track of

      It bothers me that all of these features can no longer be used because of this update, and verbatim worked excllently the way it was made already.. and  I do not wish to contact staff each time I want to make a small change for the better on my wiki that will enrich it..

      I hope that my comments and notes will be taken into consideration. Thank you

        Loading editor
    • Josephyr wrote:
      So, to get it straight, no one can add *any* JS without approval?


      If this is the case then might have to move my wikis tot a different farm.

        Loading editor
    • MikeLacey wrote: Is Java Script programming really an admin function?

      Now don't get me wrong, I know that lots of admins are also programmers/coders but that's not what being an admin is about. I'm willing to bet that a lot of people who are very good at Java Script aren't really ready to be an admin yet. (for example, the numpty who started all this by hacking wikia)

      I think you're conflating two roles here, one of which we don't have at the moment, Trusted Developer and Admin. Maybe you need a class of user who is entitled to submit JS for review but who isn't an admin.

      Being an admin doesn't mean you have to know javascript, just an understanding of it.

      What should this 'right' be named?

        Loading editor
    • Princess Diva wrote: As an administrator and bureaucrat on several wikis for many years now I completely disagree on these new changes

      The JavaScript coding on wikis can be used to enrich and add fun to wiki communities and sites, such as changing user-identity-box-group MediaWiki pages to change "Admin" tags into "Black Widow" for example on a Pretty Little Liars Wiki or a "SpearLeader" on a Britney Spears Wiki ...  The .js of wikis were also previously editable which allowed admins to add special features (see http://gossipgirl.wikia.com/wiki/MediaWiki:Common.js) from w:c:dev to allow  new features to be enabled like an additional view source button, wall greeting edit button,  and a Reveal Anon IP code which shows the IP addresses in wiki activity so you don't have to click each time if multiple anons are spamming, it's easier to keep track of

      It bothers me that all of these features can no longer be used because of this update, and verbatim worked excllently the way it was made already.. and  I do not wish to contact staff each time I want to make a small change for the better on my wiki that will enrich it..

      I hope that my comments and notes will be taken into consideration. Thank you


      Princess Diva 

      Proud admin or moderator of Britney Spears Wiki, Gossip Girl Wiki, The Lying Game Wiki, and Pretty Little Liars Wiki.

      JS will remain fully editable, and if your changes did not contain anything malicious, there should be no problems getting it approved. Allowing people, however, to add whatever scripts their want without oversight is a security risk, which has been exploited. While this new CR process may not be an ideal solution, and will probably not start smoothly, it is a definite improvement with regards to security.

        Loading editor
    • I'm not a JS programmer. I don't write scripts from nothing therefore I don't need a console. I can, however, follow directions with scripts that others have written and allow users to use (by this I mean primarily dev scripts). Having to get someone to review customization (such as UserTags) of scripts that already exist or when someone forgets say a comma is a negative of code review. If that review takes as long as it takes for a response from Staff (even longer over the weekend), it's not worth Staff having to go through these tedious reviews or subjective users to the wait to an update (or fix from lack of comma).

        Loading editor
    • Kittynator wrote:

      Being an admin doesn't mean you have to know javascript, just an understanding of it.
      What should this 'right' be named?

      Among the standard right no "tech" or "expert programming", perhaps because it's not a standard feature of the MediaWiki engine. http://stackoverflow.com/questions/8213631/javascript-in-mediawiki

      It just Wikia so damn special and broken.

        Loading editor
    • DEmersonJMFM wrote: I'm not a JS programmer. I don't write scripts from nothing therefore I don't need a console. I can, however, follow directions with scripts that others have written and allow users to use. Having to get someone to review use of scripts that already exist or when someone forgets say a comma is a negative of code review. If that review takes as long as it takes for a response from Staff (even longer over the weekend), it's not worth Staff having to go through these tedious reviews or subjective users to the wait to an update (or fix from lack of comma).

      Staff have stated that commonly used code snippets will be grouped into a kind of code library, allowing for easy reuse. This should make the whole JS editing process smoother in the long run as the library gets populated with scripts for all kinds of purposes, all verified by Staff and easily includable.

      As for those annoying minor bugs, I'd argue that pasting the script into your console before saving is a rock-solid way of squashing them. Your console will always throw an error if you messed up the syntax.

        Loading editor
    • Kittynator wrote:

      MikeLacey wrote: Is Java Script programming really an admin function?

      Now don't get me wrong, I know that lots of admins are also programmers/coders but that's not what being an admin is about. I'm willing to bet that a lot of people who are very good at Java Script aren't really ready to be an admin yet. (for example, the numpty who started all this by hacking wikia)

      I think you're conflating two roles here, one of which we don't have at the moment, Trusted Developer and Admin. Maybe you need a class of user who is entitled to submit JS for review but who isn't an admin.

      Being an admin doesn't mean you have to know javascript, just an understanding of it.

      What should this 'right' be named?

      Well, I used the term Trusted Developer in my post, but the name of the role isn't something I'm bothered about.

      What bothers me is that technical knowledge doesn't equal admin expertise, treating them as the same thing leads to this - numptys hacking wikia.

        Loading editor
    • Hedgeg wrote:

      Kittynator wrote:

      Being an admin doesn't mean you have to know javascript, just an understanding of it.
      What should this 'right' be named?

      Among the standard right no "tech" or "expert programming", perhaps because it's not a standard feature of the MediaWiki engine. http://stackoverflow.com/questions/8213631/javascript-in-mediawiki

      It just Wikia so damn special and broken.

      It isn't. Wikia does not allow adding raw script tags like that post author wants to do. The issue is with the potential of malicious scripts being added to Common.js etc., which is a core MediaWiki feature, as it has always been. But if you have a wiki farm with hundreds of thousands of wikis and a global user database, this becomes a security issue.

        Loading editor
    • Hedgeg wrote:

      Kittynator wrote:

      Being an admin doesn't mean you have to know javascript, just an understanding of it.
      What should this 'right' be named?

      Among the standard right no "tech" or "expert programming", perhaps because it's not a standard feature of the MediaWiki engine. http://stackoverflow.com/questions/8213631/javascript-in-mediawiki

      It just Wikia so damn special and broken.

      I noticed the question is from 2011, and Wikia might upgrade to MW 1.23 or later.

        Loading editor
    • It just seems that rather than making it a fun place, wikia is kind of becoming too stiffling. Like just the other day, we had a troll problem and needed immediate help, so I message wikia staff by email and then on their message wall... Like some have said, if its just a minor thing, do we have to wait 1-2  business day for approval?

        Loading editor
    • Kittynator wrote:

      Hedgeg wrote:

      Kittynator wrote:

      Being an admin doesn't mean you have to know javascript, just an understanding of it.
      What should this 'right' be named?

      Among the standard right no "tech" or "expert programming", perhaps because it's not a standard feature of the MediaWiki engine. http://stackoverflow.com/questions/8213631/javascript-in-mediawiki

      It just Wikia so damn special and broken.

      I noticed the question is from 2011, and Wikia might upgrade to MW 1.23 or later.

      Not sure about the upgrade, but OP is wrong about custom JS in that it's "not a standard feature of the MediaWiki engine"—that post talks about adding script tags and raw HTML directly into articles, which is not possible because the parser sanitizes them as it should.

        Loading editor
    • DEmersonJMFM wrote:
      I'm not a JS programmer. I don't write scripts from nothing therefore I don't need a console. I can, however, follow directions with scripts that others have written and allow users to use. Having to get someone to review use of scripts that already exist or when someone forgets say a comma is a negative of code review. If that review takes as long as it takes for a response from Staff (even longer over the weekend), it's not worth Staff having to go through these tedious reviews or subjective users to the wait to an update (or fix from lack of comma).

      Preach!

        Loading editor
    • 452
      Admins will be able to write JS and submit it for review. Then a group will review code changes to ensure they are both secure and don’t include any major breaking changes.
      That is a ridiculous solution.

      I've made over 500 edits to Mediawiki:Common.js, and have 15 subscripts with many more edits. The concept of having to submit minor changes for review is preposterous.

      And the concept of "all admins are guilty of adding malicious javascript until reviewed to be innocent" is insulting to all admins who have never done so.

      Kirkburn wrote:

      If you have specific MediaWiki messages that you think should be whitelisted for editing around Wikia, please feel free to send a note into Special:Contact about it - we do certainly anticipate expanding the current whitelist.

      According to Special:AllMessages, I've modified exactly 189 mediawiki messages - should I write in requesting they all be unlocked? Admins shouldn't have to use Special:Contact every time they want to edit one.

      He who sacrifices freedom for security deserves neither.
      ~ Benjamin Franklin (Allegedly )
        Loading editor
    • 452 wrote:

      Admins will be able to write JS and submit it for review. Then a group will review code changes to ensure they are both secure and don’t include any major breaking changes.
      That is a ridiculous solution.

      I've made over 500 edits to Mediawiki:Common.js, and have 15 subscripts with many more edits. The concept of having to submit minor changes for review is preposterous.

      And the concept of "all admins are guilty of adding malicious javascript until reviewed to be innocent" is insulting to all admins who have never done so.

      While imperfect, this is a decent interim solution. It might be subject to change in the long run. I agree with your point that the bulk of admins never write anything malicious, but there needs to be an added layer of mitigation (code review or anything else) when it comes to a wiki farm this large.

        Loading editor
    • 452

      TK-999 wrote:

      While imperfect, this is a decent interim solution.

      Could you please quote where Wikia Staff have stated that this is an interim solution?

      Nanaki wrote:

      There's a full set of these:

      • ?useusercss=0
      • ?useuserjs=0
      • ?usesitecss=0
      • ?usesitejs=0

      No, it's allowusercss and allowuserjs.

        Loading editor
    • 452 wrote:

      Admins will be able to write JS and submit it for review. Then a group will review code changes to ensure they are both secure and don’t include any major breaking changes.
      That is a ridiculous solution.

      I've made over 500 edits to Mediawiki:Common.js, and have 15 subscripts with many more edits. The concept of having to submit minor changes for review is preposterous.

      And the concept of "all admins are guilty of adding malicious javascript until reviewed to be innocent" is insulting to all admins who have never done so.

      Kirkburn wrote:

      If you have specific MediaWiki messages that you think should be whitelisted for editing around Wikia, please feel free to send a note into Special:Contact about it - we do certainly anticipate expanding the current whitelist.

      According to Special:AllMessages, I've modified exactly 189 mediawiki messages - should I write in requesting they all be unlocked? Admins shouldn't have to use Special:Contact every time they want to edit one.

      He who sacrifices freedom for security deserves neither.
      ~ Benjamin Franklin (Allegedly )

      Sorry, I was unclear. I meant that this solution is decent enough as a short-term mitigation—but it can become inconvenient in the long run.

      As for the MediaWiki namespace whitelisting, I think it would be much better to just ditch the Verbatim extension—most of its functionality can be imitated through Javascript anyways, and snippets such as Twitter widgets can be rewritten as MW extensions to provide tighter integration.

        Loading editor
    • 452 wrote:

      TK-999 wrote:

      While imperfect, this is a decent interim solution.

      Could you please quote where Wikia Staff have stated that this is an interim solution?

      Nanaki wrote:

      There's a full set of these:

      • ?useusercss=0
      • ?useuserjs=0
      • ?usesitecss=0
      • ?usesitejs=0

      No, it's allowusercss and allowuserjs.

      Both work.

        Loading editor
    • 452

      Ah, so they do, I stand corrected. I guess it must have been changed within the last few months. I always thought it was dumb that they weren't consistent.

      Edit: It was changed on June 15th.

      Thanks for letting me know!

        Loading editor
    • It sounds like I missed do something big. Could someone link to a thread talking about what prompted the emergency restrictions in the first place?

        Loading editor
    • It says it in the first sentence, http://community.wikia.com/wiki/Thread:890734

        Loading editor
    • Sorry, I overlooked the link.

        Loading editor
    • Jr Mime wrote: Real coders use the console to test JS things.. That's like the basics. For CSS, you can use w:c:dev:PortableCSSPad.

      But not everyone who uses JavaScript is a programer. what if someone wanted to add a script to their wiki, but then wanted to see how it behaved on different "settings"? each time they have to wait for a code review. (just to give an idea of what could happen in some cases).

        Loading editor
    • I still don't get it.

        Loading editor
    • In other words, we are going to blacklist the editing of pages when they're merely text, forcing us to go back to default or keep things as they are without ever being able to change them again. Do we really want to see threadmoderators be called "moderators"? Why can't we just customize our wiki the way we want?

      Relevant comic (do not quote):

      BUL9 Wikia Boardroom meme

        Loading editor
    • is this why i can't  add galleries?

        Loading editor
    • Brainulator9 wrote: In other words, we are going to blacklist the editing of pages when they're merely text, forcing us to go back to default or keep things as they are without ever being able to change them again. Do we really want to see threadmoderators be called "moderators"? Why can't we just customize our wiki the way we want?

      The MediaWiki namespace restrictions should be gone once the Verbatim extension, which is a security issue by design, is sorted:

      With regards to the Verbatim extension, we are currently running analytics to determine the most common use cases of the tool as it stands today. The goal is to ultimately turn these big needs from being used in the catch-all solution of Verbatim to a more secure, structured, and built-out tool.
        Loading editor
    • TK-999 wrote:

      The MediaWiki namespace restrictions should be gone once the Verbatim extension, which is a security issue by design, is sorted:


      With regards to the Verbatim extension, we are currently running analytics to determine the most common use cases of the tool as it stands today. The goal is to ultimately turn these big needs from being used in the catch-all solution of Verbatim to a more secure, structured, and built-out tool.

      Thanks for that. If anything, I just want our liberties to be respected. I'm not asking for a trip to the moon here.

        Loading editor
    • i ask again, does this have anything to do with not being able to add galleries and slideshows.

        Loading editor
    • Flitter2 wrote: i ask again, does this have anything to do with not being able to add galleries and slideshows.

      You should still be able to add one.

        Loading editor
    • Whether the blacklist vs. whitelist debate is still an issue or not, a whitelist is more secure in any situation. Simply blacklisting all MediaWiki pages (which can, in fact affect the Wikia mainframe even though they are located on a subdomain) and allowing only high traffic/priority MediaWiki to be edited is much easier to control and spot. If it were just a blacklist of a select number of pages, then malicious code could easily be loaded into the Wikia mainframe through a small and unknown wikia; thus causing yet another security issue like the one that was just investigated. Web security is a serious and difficult issue to resolve in any span of time. Staff are doing all they can to resolve this quickly and effectively, while protecting your security as a user while using Wikia's services. --V1c (@c)

        Loading editor
    • What about opening up Special:Allmessages to administrators?

        Loading editor
    • Uh.... Those are all MediaWiki pages...

        Loading editor
    • I only can view the source on my wiki.

        Loading editor
    • Yes, that's like what TimQ said "First and foremost, here’s where we stand today. The MediaWiki namespace was locked down starting Monday so that only staff can edit. We have begun to ease these restrictions by opening editing of the MediaWiki namespace back to admins on the communities that use those pages the most. Editing on the most used MediaWiki pages - Common.css, Wikia.css, Monobook.css, Wiki-navigation, and Community-corner - is open to all admins. For now, editing of *.js pages specifically will continue to be restricted to staff only, but we also anticipate removing these edit restrictions for some community admins next week, along with allowing users to edit their own personal JS. We will continue to examine and scale these abilities out over the next few weeks."

        Loading editor

    • EternalLocket wrote:

      Flitter2 wrote: i ask again, does this have anything to do with not being able to add galleries and slideshows.

      You should still be able to add one.



      i still can't get it up. could you help? it is called the wind on fire wiki of knowledge

        Loading editor
    • What error are you getting?

        Loading editor
    • @Flitter2 I'm not sure why it's not working, your gallery appears to be set up properly. Though it seems like one of your images is spelled incorrectly, and another doesn't seem to exist.

        Loading editor
    • Seriously all I need to do is edit my pagetitle. Let me do this crap again already...

        Loading editor
    • Here's a better solution than evaluating each script when it's published:

      Set up each third party script the way I set up TumblrShare. Anyone can edit the beta version, which is only to be used for testing and never in a production environment, and only people with the codeeditor permission can edit the production version. We could do this for each script. That way, there's no issues of untrustworthy people editing production code, but there's also not a backlog of scripts waiting for staff approval. Everyone wins.

      As a side-note, Wikia should probably set up personal scripts so that people can only edit their own user-level-scripts and stylesheets, with some exceptions for admins. This would protect people more.

        Loading editor
    •   Loading editor
    • GarnetPearlFusion wrote:
      was it this person?http://community.wikia.com/wiki/Message_Wall:Peridork_The_Illuminati_Lemon_Lime_Dorito they are blocked from all wikias.

      yes, global block. please try and stay on topic...

        Loading editor
    • HypercaneTeen wrote:
      Just great... now after this we have to submit them for approval? -_-

      pretty sure scripts on the dev wiki will be check throughly and then imports of those would be allowed without review, not sure if that's what kirkburn meant. I mean the dev wiki is a code library already...

        Loading editor
    • MikeLacey wrote:
      Is Java Script programming really an admin function?

      Now don't get me wrong, I know that lots of admins are also programmers/coders but that's not what being an admin is about. I'm willing to bet that a lot of good admins can't code their way out of a paper bag, and that a lot of people who are very good at Java Script aren't really ready to be an admin yet. (for example, the numpty who started all this by hacking wikia)

      I think you're conflating two roles here, one of which we don't have at the moment, Trusted Developer and Admin. Maybe you need a class of user who is entitled to submit JS for review but who isn't an admin.

      the editinterface right gives access to mediawiki pages. hopefully with oversight by staff and those competent, review will be faster.

        Loading editor
    • TheV1ct0ri0u5 wrote:
      Whether the blacklist vs. whitelist debate is still an issue or not, a whitelist is more secure in any situation. Simply blacklisting all MediaWiki pages (which can, in fact affect the Wikia mainframe even though they are located on a subdomain) and allowing only high traffic/priority MediaWiki to be edited is much easier to control and spot. If it were just a blacklist of a select number of pages, then malicious code could easily be loaded into the Wikia mainframe through a small and unknown wikia; thus causing yet another security issue like the one that was just investigated. Web security is a serious and difficult issue to resolve in any span of time. Staff are doing all they can to resolve this quickly and effectively, while protecting your security as a user while using Wikia's services. --V1c (@c)

      I'm still new to this but I fail to see how something like mediawiki:edit a namespace which exists solely to change the edit button's labeling, could effect wikia as a whole or possiably be used for malcious intent. DrRush12358 (talk) 04:46, August 15, 2015 (UTC)

        Loading editor
    • DrRush12358 wrote:

      I'm still new to this but I fail to see how something like mediawiki:edit a namespace which exists solely to change the edit button's labeling, could effect wikia as a whole or possiably be used for malcious intent. DrRush12358 (talk) 04:46, August 15, 2015 (UTC)

      last weekend a staff account was hacked/hijacked, then promoted & demoted accounts. they also add malicious js to the homepage of a wiki that was stealing login info.

        Loading editor

    • Jr Mime wrote:
      What error are you getting?

      Every time I try to add it, it looks like three pics next to each other.

      And my little slideshow insert button is gone.

      ):

        Loading editor
    • Also, so much for security, I was in chat today and  had several pm opened... One of my friends signed off for the night but I hadn't refreshed so she still apeared on there. I looked at her tab 5 minutes after she was gone and saw that eventhough the friend was offline there was 12 notifications. I clicked on them and there was a whole other chat going on there with several people  on the pm between me and my friend. Most of the username were innapropriate and  had never been on our wikia. The friend I was having a pm with was Jarialover1993 and shortly after she logged off these other  users popped on our PM... not regular chat

      2015-08-14 2145
        Loading editor
    • TK-999 wrote:

      Not sure about the upgrade, but OP is wrong about custom JS in that it's "not a standard feature of the MediaWiki engine"—that post talks about adding script tags and raw HTML directly into articles, which is not possible because the parser sanitizes them as it should.

      nope, asked staff and they said no upgrades for mediawiki.

        Loading editor
    • Fearless Diva wrote:
      Also, so much for security, I was in chat today and  had several pm opened... One of my friends signed off for the night but I hadn't refreshed so she still apeared on there. I looked at her tab 5 minutes after she was gone and saw that eventhough the friend was offline there was 12 notifications. I clicked on them and there was a whole other chat going on there with several people  on the pm between me and my friend. Most of the username were innapropriate and  had never been on our wikia. The friend I was having a pm with was Jarialover1993 and shortly after she logged off these other  users popped on our PM... not regular chat
      2015-08-14 2145

      glitch/bug, report it to staff

        Loading editor
    • If a new group were to be created, bcrat's should not be the ones handing it out. it should be others already in the group check that anyone who requests for the right is competent before staff grants via special:contact.staff is super fast on granting bot requests especially if either you are an admin or admins have granted permission, hopefully staff granting this right are just as fast provided at least one other competent user from the group confirms (providing a link for that). yes, in the long run this will limit how admins can add css or js; hopefully this code review isn't just wikia staff and includes potentially those competent with writing js or css from scratch - i'm looking at codeeditors and voldev, not vstf. vstf is for spam and vandalism, they should not be given the extra task of dealing with reviewing code if procedure says they don't bother with social issues. social issues are for local admins to resolve, wikia staff apparently backs this despite the number of so called "bad" admins. 

      'as 'a refresher for anyone out of the loop: keep in mind that roughly a week ago, the dev wiki had numerous scripts vandalized because not all were locked to codeeditors and now cqm is the one approving requests. a staff account was hijacked last weekend and now security's a big issue. so to those that still want the set up from the past, we are only going to have more exploits by hackers or mischievous people.

      something a bit more serious: no idea how many people were aware that admins could edit other people's personal css or js until kirkburn brought it up, ducksoup said it was for emergency cases only (from thursday office hours). i don't even know if that affected the individual wiki or if it was wikia-wide. who's to say that a "bad" admin if they knew about this wouldn't go about to screw with people or worse say someone gets on the bad side of local staff, how would that be prevented? I doubt there was any prompt that asked before admins jumped in to "change" something; the only thing the victim could do is report to wikia staff. I call that a large security risk and am grateful that risk is now GONE! I mean if someone screwed up their own personal page, they can either request local staff to revert to a previous edit/delete or contact staff to fix. in a nutshell, not every admin is competent in js, css or both for that matter. 

        Loading editor

    • Nerfmaster8 wrote:
      If a new group were to be created, bcrat's should not be the ones handing it out. it should be others already in the group check that anyone who requests for the right is competent before staff grants via special:contact.staff is super fast on granting bot requests especially if either you are an admin or admins have granted permission, hopefully staff granting this right are just as fast provided at least one other competent user from the group confirms (providing a link for that). yes, in the long run this will limit how admins can add css or js; hopefully this code review isn't just wikia staff and includes potentially those competent with writing js or css from scratch - i'm looking at codeeditors and voldev, not vstf. vstf is for spam and vandalism, they should not be given the extra task of dealing with reviewing code if procedure says they don't bother with social issues. social issues are for local admins to resolve, wikia staff apparently backs this despite the number of so called "bad" admins. 

      'as 'a refresher for anyone out of the loop: keep in mind that roughly a week ago, the dev wiki had numerous scripts vandalized because not all were locked to codeeditors and now cqm is the one approving requests. a staff account was hijacked last weekend and now security's a big issue. so to those that still want the set up from the past, we are only going to have more exploits by hackers or mischievous people.

      something a bit more serious: no idea how many people were aware that admins could edit other people's personal css or js until kirkburn brought it up, ducksoup said it was for emergency cases only (from thursday office hours). i don't even know if that affected the individual wiki or if it was wikia-wide. who's to say that a "bad" admin if they knew about this wouldn't go about to screw with people or worse say someone gets on the bad side of local staff, how would that be prevented? I doubt there was any prompt that asked before admins jumped in to "change" something; the only thing the victim could do is report to wikia staff. I call that a large security risk and am grateful that risk is now GONE! I mean if someone screwed up their own personal page, they can either request local staff to revert to a previous edit/delete or contact staff to fix. in a nutshell, not every admin is competent in js, css or both for that matter. 

      Do you think my wind on fire wiki could be in danger?

        Loading editor
    • i doubt that

        Loading editor
    • Deadcoder wrote:
      As a side-note, Wikia should probably set up personal scripts so that people can only edit their own user-level-scripts and stylesheets, with some exceptions for admins. This would protect people more.

      MediaWiki software already does that. Admins can edit anyone's personal js and css. Everyone else can only edit their own js and css.

        Loading editor
    • Saftzie wrote:

      MediaWiki software already does that. Admins can edit anyone's personal js and css. Everyone else can only edit their own js and css.

      actually, that's not entirely true. unless admins have the following, editusercss and edituserjs; they can't edit other's personal js or css. I would say no for admin access due to the numerous complaints on central over bad admins, just imagine what those people could do.

        Loading editor
    • Nerfmaster8 wrote:
      ... unless admins have the following, editusercss and edituserjs; they can't edit other's personal js or css. ...

      Good to know, but the point was that non-admins cannot edit anyone else's js and css, so Wikia doesn't have to implement any new restrictions beyond what MediaWiki provides in that regard.

        Loading editor
    • Minor editing a JS file shouldn't need a code review. For example, adding a missing semicolon. --AStranger195 (talkcontribsguestbook), 05:30, August 15, 2015 (UTC)

        Loading editor
    • Monchoman45
      Monchoman45 removed this reply because:
      Harassment
      05:49, August 15, 2015
      This reply has been removed
    • Monchoman45
      Monchoman45 removed this reply because:
      Harassment
      05:49, August 15, 2015
      This reply has been removed
    • Monchoman45
      Monchoman45 removed this reply because:
      05:49, August 15, 2015
      This reply has been removed
    • Monchoman45
      Monchoman45 removed this reply because:
      Harassment
      05:49, August 15, 2015
      This reply has been removed
    • Is all of this security necessary? 35px-MediaWiki_Emoticons_Sweat.png It kinda makes me feel like a kid whose mother tells him to go to his room. I won't be surprised if, in a very short time, this over-safe environment will begin to suppress creativity and development of useful stuff.

      Well, not really- but why on earth would you need a courthouse to approve a script if you were careful enough, and are 100% sure that it will not cause troubles? And even if it does break, if it's a syntax error, Common.js would usually only ever return a console error instead of its content, and if it doesn't, how much damage can you cause simply by making a mistake? Codes can be easily reverted anyway.

      What i find most fun in development is working on my script (or css), debugging it on my own for a while, and watching other users mocking me for stupid fails when it breaks after its launch... seriously, we wil soon miss these days...

        Loading editor
    • Mainly because you aren't the only one who can access this.

      You may be as careful as you can be but what you do is not the only thing in question here.

      If you are able to freely do something then others can do the exact same thing. So while you are doing good things others can be using it for bad things.

        Loading editor

    • Nerfmaster8 wrote:
      i doubt that

      Phew.


        Loading editor
    • Here is my ideas :

      • Remove the login form in all pages, force the login thought Special:UserLogin where JS codes are not executed, so no possibility to get the password from here, avoiding the using on Special:ChangePassword by a script to change the user password.
      • Avoid email changes by scripts or send a email confirmation to allow the change, avoiding a script to change the email and ask for a new password thought email.
      • Detect malicious script with some regex, for example, let allbody edit JS and ask for a review all scripts with a action=delete in a loop, preferences modifications, ask for Special:ChangePassword page... Ask all codes for a review could lead to chaos, because mostly, the majority of js modifications are minor changes.
      • For review, like I read above, there is no need they are all admins but they have to be trustworthy.
        Loading editor
    • Hiddenlich wrote:
      What about opening up Special:Allmessages to administrators?


      • using translate

      Wikia probablу cant do that so easy. They allow import any MW for a long time. Now to ensure full security they need to check the specific MW page for all projects and to ensure the impossibility of recording scripts and import them using verbatim before unlocking the page.

      • probably this leads to delay unlocking of pages: if the security team took up the mind they are now looking for all possible places of leakage of your data using the built-in scripts. however, this is only a suggestion based on personal experience.

      For example css import at right moment: http://ru.test.wikia.com/wiki/(Verbatim)_тест_импорта_стандартных_MediaWiki_страниц?oldid=9714 / http://ru.test.wikia.com/wiki/MediaWiki:Wikia.css?oldid=9713 verbatim gives an empty string, because apparently accesses a file, pre-processed by the server according to the rules of CSS (i.e. all incorrect for CSS syntax deleted) and not the source code of the page.

      "No more <script> in media wiki messages" /truly deep freeze due to unresolved security issue that no one asked to decide in this way..

        Loading editor
    • Gguigui1 wrote: Here is my ideas :

      • Remove the login form in all pages, force the login thought Special:UserLogin where JS codes are not executed, so no possibility to get the password from here, avoiding the using on Special:ChangePassword by a script to change the user password.
      • Avoid email changes by scripts or send a email confirmation to allow the change, avoiding a script to change the email and ask for a new password thought email.
      • Detect malicious script with some regex, for example, let allbody edit JS and ask for a review all scripts with a action=delete in a loop, preferences modifications, ask for Special:ChangePassword page... Ask all codes for a review could lead to chaos, because mostly, the majority of js modifications are minor changes.
      • For review, like I read above, there is no need they are all admins but they have to be trustworthy.
      • The old login form is already due to be removed when the Helios authentication platform goes live.
      • There is no regex to detect malicious Javascript. You could write it a thousand ways, obfuscate it, etc.—the only way to detect them is through a review by another human. This code review system will certainly have a rough start, but the morebthe code library gets populated with pre-reviewed snippets, the easier it will become to implement common changes.
        Loading editor
    • There are several problems with simply trusting users:

      • Ignorant users can cause problems without even knowing about it (e.g. visual editor not working because of javascript (Thread:822694))
      • People copy/pasting or importing script without truly understanding it can  expose exploits. Those are the worst offenders in fact.
      • The fact that many wikis could have been used and abused for several years even a decade without anybody being aware of it.
      • Authors updating or changing the original code without warning anyone and causing problems or exploits because these are updated automatically.
      • Being able to create scripts doesn't mean one is aware of security problems related to that code. Someone could easily code a perfectly useful code that has many exploits, and this has happened in dev.wiki.
      • Even simple performance issues that can be solved by regular users are left unattended for years (proof).
      • A wiki is awful for code-editing/review . There is no possibility of Sanity_check, no proper lint,  no way to comment or highlight problems in specific lines, and edits can be immediately saved even if there are  serious problems.

      There are more developers using mediawiki and wikia than one might expect. If Wikia has 300,000 wikis with one user and just 0.1/100 of those are developers, that would mean there are already 300 developers around. 

      A relevant discussion by  MediaWiki software engineers, developers, and users:

      https://phabricator.wikimedia.org/T71445

      Edit: added more info...

        Loading editor
    • Those hackers. They ruin the wiki experience for everyone. :(

        Loading editor
    • Brainulator9 wrote:
      BUL9 Wikia Boardroom meme

      The problems addressed here are there since cross-wiki login and custom js came together. So yeah... fixing issues that have been lingering for years.

        Loading editor
    • I disagree with the new method strongly.

      It severely hinders the rate of editing JS scripts. Nobody appreciates having to wait for an unknown period, when they can do the goddamn JS editing themselves, likely within a few minutes (or a couple of hours at max).

      Google search for MediaWiki: "MediaWiki is a free software open source wiki".

      ^ For God's sake, the very purpose of using MediaWiki is to be able to customize websites easily. Now that is to be disabled as well? Waiting for somebody else to "review" every minor change is an overprotective, inefficient and frustrating approach, especially for people good at coding.

      No offense meant to the staff, but in my opinion, the Wikia network has been growing more and more locked down, and it is frankly quite stiffling. The assumption of apparent incompetence of everyone else other than the staff is highly irritating as well. We're not fucking 5-year olds, yeah? So kindly stop treating us like morons who can't handle simple JS editing.

      Actually, you know what? F*** it. I'm done talking. It's not like anybody actually gives a shit about what I'm trying to say anyway. But I would like my extreme dislike for the ever-increasing mother****ing red tape on the Wikia network to be present on record.

        Loading editor
    • Lord Kavpeny wrote: I disagree with the new method strongly.

      It severely hinders the rate of editing JS scripts. Nobody appreciates having to wait for an unknown period, when they can do the goddamn JS editing themselves, likely within a few minutes (or a couple of hours at max).

      Google search for MediaWiki: "MediaWiki is a free software open source wiki".

      ^ For God's sake, the very purpose of using MediaWiki is to be able to customize websites easily. Now that is to be disabled as well? Waiting for somebody else to "review" every minor change is an overprotective, inefficient and frustrating approach, especially for people good at coding.

      No offense meant to the staff, but in my opinion, the Wikia network has been growing more and more locked down, and it is frankly quite stiffling. The assumption of apparent incompetence of everyone else other than the staff is highly irritating as well. We're not fucking 5-year olds, yeah? So kindly stop treating us like morons who can't handle simple JS editing.

      Actually, you know what? F*** it. I'm done talking. It's not like anybody actually gives a shit about what I'm trying to say anyway. But I would like my extreme dislike for the ever-increasing mother****ing red tape on the Wikia network to be present on record.

      I understand that you are frustrated but while on Community Central you need to mind your language, please.

        Loading editor
    • the natural right to Express own rage > any rules of conduct in the community

        Loading editor
    • Hedgeg wrote: the natural right to Express own rage > any rules of conduct in the community

      You do not have that right here I am afraid.

      We prefer it if you keep things civil and level-headed. In doing so we forbid users from swearing, insulting others, and in general being argumentative. I ask that while you are here you simply refrain from doing any of the above.

        Loading editor
    • @Shining-Armor: I dislike offensive language myself, but in this particular case, I felt it was optimal to convey my agitation, so I stand by every word.

      However, I did not wish to violate any regulations with my outburst. As such, I apologize for the previously posted crude language. I meant no disrespect meant to either the Staff, or to Community Central.

        Loading editor
    • Shining-Armor wrote:

      We prefer it if you keep things civil and level-headed. In doing so we forbid users from swearing, insulting others, and in general being argumentative. I ask that while you are here you simply refrain from doing any of the above.

      I feel your message as a typical error is not a perfect administrator. "creating oftop by making warnings in theme"

      If you take out the warning as an administrator, you must do it on the talk page of the contributor, but not create offtopic in this thread (warning must be clear, not part of the conversation between people with equal status like it is must always be).

        Loading editor
    • Personally, I think that some users should be able to bypass the auditing. If you've shown that you routinely make good edits and are capable at Javascript, then your script edits should be whitelisted, and not need to be audited.

        Loading editor
    • Hedgeg wrote:

      Shining-Armor wrote:

      We prefer it if you keep things civil and level-headed. In doing so we forbid users from swearing, insulting others, and in general being argumentative. I ask that while you are here you simply refrain from doing any of the above.

      I feel your message as a typical error is not a perfect administrator. "creating oftop by making warnings in theme"

      If you take out the warning as an administrator, you must do it on the talk page of the contributor, but not create offtopic in this thread (warning must be clear, not part of the conversation between people with equal status like it is must always be).

      I am free to ask users not to do things in the relevant places. This not only serves as a warning to that particular user but also, hopefully, others who are browsing the thread as well.

        Loading editor
    • @Shining-Armor, two things:

      • A little cursing isn't going to kill anyone. If anyone does die simply from reading profanity, they were probably going to die very soon anyway.
      • Try to stay on topic about the new Javascript policy and how it's a pain in the ass.
        Loading editor
    • Users know how to behave. This is offtopic/noice, not bringing any benefit to a particular topic.

      "When a sculptor works on a sculpture he didn't use it as a dining table, bed of love, and a dartboard. because it will ruin the sculpture."

      Our dispute spoils.

        Loading editor
    • Wow, some flame in here now much? :/

        Loading editor
    • Maybe Wikia should support Javascript this the way the dev wiki does things: with an additional usergroup for code editor who can edit sensitive Javascript, and everyone else having limits.

        Loading editor
    • Deadcoder wrote: @Shining-Armor, two things:

      • A little cursing isn't going to kill anyone. If anyone does die simply from reading profanity, they were probably going to die very soon anyway.
      • Try to stay on topic about the new Javascript policy and how it's a pain in the ass.
      • It does not matter if it does not cause damage it is how things are on Community Central and it is how things shall remain.
      • This started as a message to another user telling them that we do not allow swearing. And furthermore, if I deem that diverging from the topic is necessary I will do so.

      Hedgeg wrote:

      Users know how to behave. This is offtopic/noice, not bringing any benefit to a particular topic.

      "When a sculptor works on a sculpture he didn't use it as a dining table, bed of love, and a dartboard. because it will ruin the sculpture."

      Our dispute spoils.

      May I remind you that you were not involved in the original discussion and instead decided to interject?

      Specifically with this comment.

      Hedgeg wrote:

      the natural right to Express own rage > any rules of conduct in the community

      Either way neither of you were involved in the warning so I would appreciate if it you would cease in furthering this off-topic discussion.

        Loading editor
    • Perhaps the issue could be somewhat eased if certain trusted users could also audit scripts for approval.

        Loading editor
    • Listen, the moment people are allowed to swear, we will become a 4-chan/sub-reddit of questionable nature, not a dedicated commmunity of editors in a fanbase who actually wanna talk about something. We get your frustration Lord Kavepny. You wanna edit while Wikia takes care of domain, accounts and security. But expletives in a comment that does not try to adress the problem is not necessarily a good response. And justifying it after the user apologised is disrespectful to him as he's obeying the rules, Hedgeg.

      Hedgeg wrote:

      the natural right to Express own rage > any rules of conduct in the community

      Stop trying to flame, you can express rage in many ways: "I am enraged" "This is highly dissapointing" all of those are civil without caps or swears; he used the latter. When Shining Armor says "This is a warning." he is not out to ban you, he just wants to not see swears spread across the page. When you join a site, you follow its rules & there is no freedom outside it. This is a community not a group of warring people and that rule maintains that existence and modus operandi.

      OK, in any case, could Wikia consider unlocking Mediawiki:Licenses immediately and allowing the custom message tool to send welcome messages in time (hopefully this is possible). I've had users join and they didn't get the message so they started uploading untagged images and one used questionable behaviour in a comment etc. which isn't great.

      PS: I'd like to note that Shining Armor would probably message you if he wanted to issue a ban or ban warning directly. Which means that he is understanding of the frustration being a motivation for the message. So the user retains the right to express himself without the expletives.

        Loading editor
    • Deadcoder wrote:
      Perhaps the issue could be somewhat eased if certain trusted users could also audit scripts for approval.

      Trusted user at any time may become a pest. That's why on Wikia unavailable plug-ins and extensions to make deal with vandalism for ordinary users. a small group of participants like VSTF easier to prepare, monitor, and "exterminate" in case of abuse of rights than hundreds, thousands of "trusted", uncontrolled strangers. That is Wikia politic in such questions.

        Loading editor
    • VSTF is a good example of what I'm hoping for. That's a successful model for dealing with certain issues. I'm proposing we make a similar group for approving code edits.

        Loading editor
    • Perhaps VSTF collaborating with Dev Wiki, that would help Wikia staff get support and suggestions from trusted and experienced members from the community as well as patrolling help from them in case this happens again. There are a lot of good helpful people there and their site is a beacon of security inside the Wikia domain.

        Loading editor
    • I am an admin on the Henry Danger wikia and now unable to create and or edit MediaWiki pages. When will it be back up.

        Loading editor
    • If you'd read the first message...

      First and foremost, here’s where we stand today. The MediaWiki namespace was locked down starting Monday so that only staff can edit. We have begun to ease these restrictions by opening editing of the MediaWiki namespace back to admins on the communities that use those pages the most. Editing on the most used MediaWiki pages - Common.css, Wikia.css, Monobook.css, Wiki-navigation, and Community-corner - is open to all admins. For now, editing of *.js pages specifically will continue to be restricted to staff only, but we also anticipate removing these edit restrictions for some community admins next week, along with allowing users to edit their own personal JS. We will continue to examine and scale these abilities out over the next few weeks.
        Loading editor
    • Yeah, that was before I posted that comment. Then I started reading the article.

        Loading editor
    • Hello,

      Wanted to post a general update to touch on concerns or lines of questions raised higher up in the thread.

      First off, I want to re-stress that what I've announced in the "moving forward" realm is tentative. While I feel very confident we are moving in the direction I stated (otherwise I would not make such a statement!), keep in mind that this week we spent most of our time investigating the incident and taking emergency measures. We have had little time to nail down specifics on either the JavaScript review system or the Verbatim replacement tools. We have just begun our normal product building process - talking to all stakeholders inside our company and broaching the subject with Community Council. While we are doing that in the most rapid way we can, that still takes time. Until we have scoped out exactly what we're going to build, there's literally not much more I can say.

      Regarding JavaScript review, it's essential to understand that not all wikias have custom JavaScript - that number is less than 4% of our 330,000 current communities. And of that subset, very few touch their JavaScript files once per day much less per month. Of course, there definitely are communities that are very active JavaScript editors. We will be looking at some of them to better understand the volume and needs. I will be scoping out who exactly will be a reviewer in the week to come. It will likely start with ComSup techs though I could certainly envision a VSTF-ish global group that helps with both a review and library system.

      At first, yes, it's entirely possible that there will be some delays in approving JavaScript as we initialize who is reviewing it and get a feel for an approval interface. While stating that, I think again it's important to look at perspective. VSTF has one of the fastest response times of any group anywhere I've ever seen and despite immense volume, Wikia Staff has a 48h response time and 90% of our tickets get replied to within 24h (yes, including weekends). I expect the volume of review to be very low compared to both groups' workload. So yes, there may be growing pains, but please do not jump to conclusions that there will be week-long waits getting JavaScript approved.

      Regarding login security, as touched on earlier in this thread, Helios authentication has a number of additional security tools that will help. Helios will be explained either late this month or early next month as we talk about how Wikia is tackling some of our architectural needs through SAAS (Software as a service). In addition, we have been throughout the summer aggressively scoping out the most feasible way to bring SSL/HTTPS services into Wikia (this being tied into some of the core components of Helios). Simply put our scale and number of domain structures has made this difficult, but it has been a priority for some time before this incident.

      I also want to very directly address those who expressed concern that a code review process either takes away our users' freedom or enjoyment from using our platform. Custom, user-written, executable JavaScript simply doesn't make sense on today's internet. We can close one hole (like login form security) with attackers simply quick to try to find another. One of our engineers has literally most of his free time all year doing penetration/vulnerability tests on our code and made improvements as needed. But on the front end, there is nothing more dangerous than JavaScript.

      That said, we understand and respect what our communities have done with JavaScript. The aim of this project is to continue to allow JavaScript to be used as a customization method on our site with an extra layer of review for security. JavaScript is not going to be reviewed for the purpose of determining if an idea is "good" or "bad". It is simply going to be reviewed to see if it breaks (causes fatal errors) or harms our communities in any way. If the code submitted meets that criteria, it will be approved. If an attacker is trying to phish, it will be denied and Community Support will investigate. It's a safer environment for everyone that should not infringe on the power of customization our communities have.

        Loading editor
    • Wow, it's really sad that my comic is getting more likes than the thread itself.

        Loading editor
    • I've stayed mostly quiet regarding my opinions on this topic, but this suggestion that code will need to be submitted for review, is absolutely preposterous to me as an actual script writer.

      Even if the waiting time for code review is five minutes, that's still far too long for quickly testing new scripts. It's painful enough as it is having to clear cache and purge the page and all the rest of it, without having to wait for god-knows-how-long for someone else to say 'yes, adding a semicolon to line 46 isn't malicious, have a good day'. This review system is going to destroy the creativity Wikia's script writers have exhibited over the last twelve years.

      From where I'm standing a far better solution would be to introduce an extra user class which can only be given by Wikia staff, and only after sufficient demonstration of proficiency with JavaScript, which allows editing of code.

      The whole thing just reeks of over-protectivity. How many wikis use custom JavaScript? And how often do JavaScript incidents occur? To force all users to have their code submitted for review just seems like overkill.

      And another question: what's going to be the cut-off for what's being considered 'malicious'? It's already difficult enough to figure out whether anyone is going to take offence to your script if it's any more complicated than 'make a table that adds item prices together'. Who's going to be responsible for reviewing the code, especially enormous scripts like Monchoman's chat hacks, or that options script every other chat seems to use? What about scripts that for instance modify a message a user sends, such as chat censor scripts? Are they going to be allowed?

        Loading editor
    • I have to agree with Brain and Dragon. Wikis with high-traffic JavaScript are exactly the places where code-review shouldn't be foreced massively. What's the point of asking for review of the same code several times a days if these wikis have people who are familiar with JS? Even then fails happen, but the consequences are not "fatal", and either way are usually fixed within seconds.

        Loading editor
    • Dragonfree97 wrote:

      From where I'm standing a far better solution would be to introduce an extra user class which can only be given by Wikia staff, and only after sufficient demonstration of proficiency with JavaScript, which allows editing of code.

      The whole thing just reeks of over-protectivity. How many wikis use custom JavaScript? And how often do JavaScript incidents occur? To force all users to have their code submitted for review just seems like overkill.

      if you bothered to actually read DaNASCAT's above response, then you would have found that 4% of the 330,000 wikis constantly change their JS and that is 13,200 wikis by calculation. perhaps you like to figure out errors on your own if the editor doesn't throw a warning, sometimes you may still need to go ask a competent user for help so what's the harm in checking say imports are correct?

      additionally, it was mentioned that we may get a new global group. that would be great, especially if it either involved their tech support staff (no idea if they have the time to be fast) or the current list of codeeditors from the dev wiki.

        Loading editor
    • I am honestly neutral on the Javascript part. I mean, I have rarely used it, and when I have used it for the Global.js and Common.js, it didn't work, even when I performed the instructions over and over again. But the Mediawiki pages however should be the first to be fully open. Some Mediawiki pages are crucial for Wiki customization. Mediawiki:Emoticons is an example of this.

        Loading editor
    • Dragonfree97 wrote:

      The whole thing just reeks of over-protectivity. How many wikis use custom JavaScript? And how often do JavaScript incidents occur? To force all users to have their code submitted for review just seems like overkill.

      I think only people who don't really understand javascript can make claims that each "semi-colon" requires review. Even if one doesn't want to use the javascript console, one can still use greasemonkey or tampermonkey to make any changes without submitting them to a wiki. Making the username/user.js completely unnecesary. In fact, submitting every change to a wiki is a bad practice that will in some cases make certain wikia features stop working in the event of a script error breaking functionality and in some cases breaking the TOU.  

      There are apps like jslint and json lint that can quickly identify simple mistakes like that anyway.

      If one really wants to take it to the next level, there's nothing stopping anyone from downloading the whole mediawiki/wikia's source code and debugging it locally. Anyone who changes javascript, is immediately forcing everyone in the wikia to trust them, based on nothing but the idea that an "admin"  who more often than not uses a "pseudonymn" is trustworthy. 

      Actually one could argue that the current way of changing javascript goes entirely against a wiki. In a true wiki [1] every single change (including js) is peer reviewed and accepted or rejected. The reality is that unlike a normal article there are  fewer competent peer reviewers for js.

      Ultimately, even mediawiki developers aren't allowed to merge code without peer review, and they are far more competent than any wiki user.

        Loading editor
    • Hiddenlich wrote:
      I am honestly neutral on the Javascript part. I mean, I have rarely used it, and when I have used it for the Global.js and Common.js, it didn't work, even when I performed the instructions over and over again. But the Mediawiki pages however should be the first to be fully open. Some Mediawiki pages are crucial for Wiki customization. Mediawiki:Emoticons is an example of this.

      it does seem like besides the core css and js pages, the rest are relatively safe but staff's trying to be cautious.

        Loading editor
    • Nerfmaster8 wrote: if you bothered to actually read DaNASCAT's above response, then you would have found that 4% of the 330,000 wikis constantly change their JS and that is 13,200 wikis by calculation. perhaps you like to figure out errors on your own if the editor doesn't throw a warning, sometimes you may still need to go ask a competent user for help so what's the harm in checking say imports are correct?

      That was a rhetorical question.

      Out of those thirteen thousand wikis, how many actually have major problems that warrant Wikia Staff stepping in and having to fix it for them?

      I'm in support of having to have code review for the cases where some eight-year-old admin adds every single script on the damn site to his wiki and then wonders why his main page redirects to editing the chat welcome message, but to force admins and developers who have been writing javascript for wikis for years on end seems absolutely absurd and counter productive.

      Deadcoder wrote: Personally, I think that some users should be able to bypass the auditing. If you've shown that you routinely make good edits and are capable at Javascript, then your script edits should be whitelisted, and not need to be audited.

      This is definitely something I can agree with.

      Dessamator wrote:

      Dragonfree97 wrote:

      The whole thing just reeks of over-protectivity. How many wikis use custom JavaScript? And how often do JavaScript incidents occur? To force all users to have their code submitted for review just seems like overkill.

      I think only people who don't really understand javascript can make claims that each "semi-colon" requires review. Even if one doesn't want to use the javascript console, one can still use greasemonkey or tampermonkey to make any changes without submitting them to a wiki. Making the username/user.js completely unnecesary. In fact, submitting every change to a wiki is a bad practice that will in some cases make certain wikia features stop working in the event of a script error breaking functionality and in some cases breaking the TOU.

      There are apps like jslint and json lint that can quickly identify simple mistakes like that anyway.

      Obviously I'm exaggerating to express my point.

      Dessamator wrote:

      If one really wants to take it to the next level, there's nothing stopping anyone from downloading the whole mediawiki/wikia's source code and debugging it locally. Anyone who changes javascript, is immediately forcing everyone in the wikia to trust them, based on nothing but the idea that an "admin"  who more often than not uses a "pseudonymn" is trustworthy. 

      Another reason to introduce a 'code-editor' group that only Wikia Staff themselves can give out to people.

      Dessamator wrote: Actually one could argue that the current way of changing javascript goes entirely against a wiki. In a true wiki [1] every single change (including js) is peer reviewed and accepted or rejected. The reality is that unlike a normal article there are  fewer competent peer reviewers for js.

      Ultimately, even mediawiki developers aren't allowed to merge code without peer review, and they are far more competent than any wiki user.

      I don't think it's fair to compare MediaWiki to Javascript on one wiki. MediaWiki is a standard which billions of pages across the internet rely on, local JS affects only a few thousand at most.

        Loading editor
    • While I'm glad that staff is finally taking security seriously, I'm worried about evaluation times. Perhaps Wikia should do this: users who have a reputation of safe useful Javascript edits can edit scripts "where they have the rights" without evaluation. Everyone else gets their code evaluated. As more edits are made, your reputation grows and eventually, you get an additional permission, and you no longer need your code audited.

        Loading editor
    • Deadcoder wrote:
      While I'm glad that staff is finally taking security seriously, I'm worried about evaluation times. Perhaps Wikia should do this: users who have a reputation of safe useful Javascript edits can edit scripts "where they have the rights" without evaluation. Everyone else gets their code evaluated. As more edits are made, your reputation grows and eventually, you get an additional permission, and you no longer need your code audited.

      That sets a bad precendent. There are many admins and users who have been good editors for years, but one day they decide to simply go rogue and start vandalising or making a mess of wikis. 

      That's like saying that police officers who have been competent for a decade shouldn't be evaluated or that "internal affairs"  aren't needed. The fact remains that many police officers may become corrupt, and that even those people who have the best intentions sometimes may unknowingly make mistakes that expose others to danger.

      Code-review means that even code-reviewers themselves should (at least if it is implemented correctly) also have to submit their own code for review.

        Loading editor
    • Dessamator wrote:

      Deadcoder wrote:
      While I'm glad that staff is finally taking security seriously, I'm worried about evaluation times. Perhaps Wikia should do this: users who have a reputation of safe useful Javascript edits can edit scripts "where they have the rights" without evaluation. Everyone else gets their code evaluated. As more edits are made, your reputation grows and eventually, you get an additional permission, and you no longer need your code audited.

      That sets a bad precendent. There are many admins and users who have been good editors for years, but one day they decide to simply go rogue and start vandalising or making a mess of wikis. 

      That's like saying that police officers who have been competent for a decade shouldn't be evaluated or that "internal affairs" or isn't needed. Many police officers may become corrupt. 

      Code-review means that even code-reviewers themselves should (at least if it is implemented correctly) also have to submit their own code for review.

      I think there's a bit of a difference between (a) your average person competent enough with JavaScript to deserve these additional rights (b) a ten-year-old kid vandalizing a wiki because lulz (c) the police force.

      How does Wikia know its VSTFs aren't going to go rogue and delete everything? Do all their contributions and help need to be patrolled and watched by some review squad? Surely they could do more damage since they have powers across the whole of Wikia? A local code-editor group would be a group only for users who, like VSTFs, are trusted by Wikia not to do anything wrong.

        Loading editor
    • Huh?

        Loading editor
    • Code should always be reviewed before it is implemented. The best coders make mistakes, without going rogue or wishing to cause havoc, which can cause major problems. Truly competent, well trained software coders/ programmers know this. Reviews may take a little time but knowing the final product functions properly is worth it.

        Loading editor
    • @DaNASCAT: Wikia Staff has a 48h response time

      Huh, so can your staffs fix errors on my code? Or I have to wait 48 hours to hear your staffs say: "Ah, this code is broken, so it's ok. Doesn't break any security rules"

        Loading editor
    • 14.171.191.123 wrote: @DaNASCAT: Wikia Staff has a 48h response time

      Huh, so can your staffs fix errors on my code? Or I have to wait 48 hours to hear your staffs say: "Ah, this code is broken, so it's ok. Doesn't break any security rules"

      No, he means that Wikia Staff will respond to all support tickets within 48h currently

        Loading editor
    • Dragonfree97 wrote:

      14.171.191.123 wrote: @DaNASCAT: Wikia Staff has a 48h response time

      Huh, so can your staffs fix errors on my code? Or I have to wait 48 hours to hear your staffs say: "Ah, this code is broken, so it's ok. Doesn't break any security rules"

      No, he means that Wikia Staff will respond to all support tickets within 48h currently

      The matter i want to say here is if you make a lot of change on your code, this review system which WIkia want bring to us will be a a complex and time-consuming process. 

      This review system like you make any edit of any editor on your wiki had to be approved first by sysop before they can publish their edit.--> And Wikia is not a Wiki anymore. 

        Loading editor
    • Dragonfree97 wrote:

      I think there's a bit of a difference between (a) your average person competent enough with JavaScript to deserve these additional rights (b) a ten-year-old kid vandalizing a wiki because lulz (c) the police force.

      How does Wikia know its VSTFs aren't going to go rogue and delete everything? Do all their contributions and help need to be patrolled and watched by some review squad? Surely they could do more damage since they have powers across the whole of Wikia? A local code-editor group would be a group only for users who, like VSTFs, are trusted by Wikia not to do anything wrong.

      Such police must be like FBI?: total preventing JS changes, control over the members in order to discourage collusion with criminals. "No one trust" still real, remember?

      BethanyM wrote: Code should always be reviewed before it is implemented. The best coders make mistakes, without going rogue or wishing to cause havoc, which can cause major problems. Truly competent, well trained software coders/ programmers know this. Reviews may take a little time but knowing the final product functions properly is worth it.

      Global-used code yes (http://dev.wikia.com/wiki/Thread:7172). Custom unique js, which cannot steal personal information due to improvement of security ─ no.

        Loading editor
    • Sysops are the only ones that can add JS on their wiki. Having every editor allowed to make suggestions and spam the system is not the solution. Also, sysops were the main cause of this conflict.

        Loading editor
    • Sysops are also admins. They also enforce the rules.

        Loading editor
    • Dragonfree97 wrote:

      14.171.191.123 wrote: @DaNASCAT: Wikia Staff has a 48h response time

      Huh, so can your staffs fix errors on my code? Or I have to wait 48 hours to hear your staffs say: "Ah, this code is broken, so it's ok. Doesn't break any security rules"

      No, he means that Wikia Staff will respond to all support tickets within 48h currently

      Also, the moderation of code function is pretty simple to do in the forums here and/or Dev Wiki. There are definitely people willing to help with that but I don't think Wikia Staff should be made to review the function and syntax of people's code to ensure its working well and optimized.

      Dev Wiki are bae, they will happily help you with that and give fast responses so long as you only message each time you make or want a new feature. The Wikia Staff have their hands full without content creation anyway. While we submit content, they host the domain, add sitewide features, answer our queries and perform vandalism maintenance with help from local admins.

        Loading editor
    • DaNASCAT wrote:
      ...

      At first, yes, it's entirely possible that there will be some delays in approving JavaScript as we initialize who is reviewing it and get a feel for an approval interface. While stating that, I think again it's important to look at perspective. VSTF has one of the fastest response times of any group anywhere I've ever seen and despite immense volume, Wikia Staff has a 48h response time and 90% of our tickets get replied to within 24h (yes, including weekends). I expect the volume of review to be very low compared to both groups' workload. So yes, there may be growing pains, but please do not jump to conclusions that there will be week-long waits getting JavaScript approved.

      ...

      Wikia are not going to fix this? http://habrahabr.ru/company/yandex/blog/245637/

        Loading editor
    • DaNASCAT wrote:
      For now, editing of *.js pages specifically will continue to be restricted to staff only, but we also anticipate removing these edit restrictions ... allowing users to edit their own personal JS.

      But then ...

      DaNASCAT wrote:
      I also want to very directly address those who expressed concern that a code review process either takes away our users' freedom or enjoyment from using our platform. Custom, user-written, executable JavaScript simply doesn't make sense on today's internet.

      So personal JavaScript is or isn't going away? The first quote assures us it's coming back. The second quote says it isn't.

        Loading editor
    • Personal JS will continue to be accessible and freely editable once we finish making some tweaks to the permission structure.

        Loading editor
    • Jr Mime wrote: Sysops are the only ones that can add JS on their wiki. Having every editor allowed to make suggestions and spam the system is not the solution. Also, sysops were the main cause of this conflict.

      The users who made the hack were not elevated and we would be informed by some sort of admin vetting feature or disciplining or sysop permission deactivation in full if it was admins hacking the Wikia.

      Are you sysop? People don't randomly become sysop, and rogue admins have to put a lot of effort into scoring a lot of quality edits for a high editcount before it pays for the effort and they can abuse their responsibility.

      I know I got sysop on one wiki only because of HARD WORK. I would never cash that in for a stupid troll and its too much of a bother anyway. Community complaints usually wind up pretty quickly for that sort of behaviour and Wikia Staff can demote automatically if the admin uses his power to interfere in the community discussion to get a editor consensus on stripping the rogue admin's rank.

      From the above points, I hope its clear that blaming the editors in the sysop class is not the solution. Besides, the users were confirmed to be new and barely authenticated not sysop. Refrain from playing the blame game. The very nature of infiltrating a wiki to become a rogue admin makes the idea so intensely ridiculous. You have VSTF authority, would you do this for the banter and risk losing your position?

      PS: It is now to my understanding that the user Jr Mime referred specifically to users whose accounts were compromised and were elevated; a view which I agree with when he explained further. I apologise sincerely for assuming that the comment was critical of Wikia's local admins and hope Jr Mime accepts this apology.

        Loading editor
    • DaNASCAT wrote:
      Custom, user-written, executable JavaScript simply doesn't make sense on today's internet.

      no comments


      • Yandex translate

      Entire JS pre-check is radical method. post-check does not create a delay.

      • JS need take under control, but not in "total control" manner

      How VSTF works: they deal with real consequences. roll back in case of vandalism. of course the really serious security problem - the theft of user data is not visible, however you can go through the collection of statistics on the server: as soon as you encounter a malicious script you will have full information about log ins, log outs, passwords changes, mail changes, the changes in the contribution of the participant.

      • hey and most still have a mobile phone for emergencies

      /based on these data, it is possible to make specific conclusions (I'm sure there are a couple dozen possible scenarios of what is happening) and to prevent the loss of accounts./

      • but still to check scripts will need a lot of people, the sharing of scripts between members and global access to scripts for malware removal. global administration of js namespace (closer to wiki-realities). very responsible, selfless and interested in reading thousands of codes.

      you assert that not a single line of code can't be trusted and that the script that is written by ordinary participants are meaningless? do you realize how silly that sounds in the wiki-realities?

        Loading editor
    • much harsh, many feelings Speedit.

      Yes, people don't randomly become sysop, but the big issue resolved around sysops multi-wiki. I won't go in big details, but all of the corrupt system resolved around sysops on other wikis, then on FNAF. A normal user certainly can't reproduce this, but an admin can. Admins on FNAF didn't create this, it was created via the hacker using the admin's powers. If he gotten a normal account, nothing would happen (just trolling on said account). Anyone editing the MediaWiki JS pages can cause issues. Letting admins to changes won't do anything, the same thing will happen over and over again. Nothing will be patched at all.

        Loading editor
    • They're right in that executable code should not be given free pass to cause havoc as it pleases and that the idea of anyone with a login executing their own code to manipulate the side without monitoring is a bad one. Perhaps tools for importing pre-written clean code from Dev Wiki without monitoring is a good idea, and gets the delay outta the way while giving people a feature they dreamt of before.

        Loading editor
    • Yup, that's what of their main ideas, a library of tools you can easily select and import from dev wiki (I guess it'll turn into the Dev Library! :P). That would be very good, it'll reduce the amount of reviews needed.

        Loading editor
    • Jr Mime wrote: much harsh, many feelings Speedit.

      Yes, people don't randomly become sysop, but the big issue resolved around sysops multi-wiki. I won't go in big details, but all of the corrupt system resolved around sysops on other wikis, then on FNAF. A normal user certainly can't reproduce this, but an admin can. Admins on FNAF didn't create this, it was created via the hacker using the admin's powers. If he gotten a normal account, nothing would happen (just trolling on said account). Anyone editing the MediaWiki JS pages can cause issues. Letting admins to changes won't do anything, the same thing will happen over and over again. Nothing will be patched at all.

      I agree with this, I guess. Its just that many people just scream "sysop" or "bad admin" for something they don't like. Someone said this in the last thread, but there should be 2-factor authentication for any elevated user especially staff. I would be happy to double lock my account in this fashion as sometimes admins even place passwords accidentally in articles or comments (this is RARE but it DEFINITELY happens). Admin accounts, staff and VSTF/code-editor should NOT be so vulnerable to compromise even by brute force methods. This would really be a good idea.

      Hope this clears that up, I made assumptions in my last comment so please accept my sincere apology.

        Loading editor
    • What I don't understand is why no one understands that FNAF was attacked because FNAF is hated by many. I don't think there are any other wikias that people hate more than FNAF, therefore they all shouldn't be on lockdown.

        Loading editor
    • This whole situation seems like massive, massive overkill for the situation at hand, and the proposed changes simply inconvenience experienced users who know what they're doing.

      At the risk of drawing up a terrible analogy, have we not learnt anything from watching the way governments have handled the risk of terrorism? It's the same thing here where malicious users are the terrorists. Turn the entire site into a 'police state' if you will but hackers and phishers etc will still get through eventually

        Loading editor
    • Any wiki coulda gotten hacked by it. FNAF was hit because of it's popularity. They coulda hit w:c:disney if they wanted, or even this wiki. And they still could if we only kept the lockdown on that wiki.

      Also, there were 3-4 more wikis that were attacked.

        Loading editor
    • Jr Mime wrote:
      Any wiki coulda gotten hacked by it. FNAF was hit because of it's popularity. They coulda hit w:c:disney if they wanted, or even this wiki. And they still could if we only kept the lockdown on that wiki.

      Also, there were 3-4 more wikis that were attacked.

      Mine was attacked, and I still highly disagree with this. As I said, Wikia is more focused on fixing things that were never problematic to begin with versus things that need to be fixed.

        Loading editor
    • Is the mentally insane bear involved?

        Loading editor
    • Why emoticons?

        Loading editor
    • Huh?

        Loading editor
    • ClocksNetwork wrote:
      Is the mentally insane bear involved?

      despite getting off topic, enjoyed this

        Loading editor
    • What? That bear is mentally insane.

        Loading editor
    • So if a verbatim feature won't get added, it will have to be imported to javascript (thus creating extra work reviewing it)? Hmm, in many cases that could work, but maybe instead of disabling verbatim, MediaWiki edits could go through the same reviewing process? (but only ones that contain script/HTML syntax, the others, notably those with just plain wikitext, could freely go after being checked by a machine filter).

      There is another problem though: wikiamobile skin, where absolutely no standard javascript/css works and any code that is absolutely necessary needs to be injected that way. I get it that wikia wants its sites to work on washing machines, but my phone is not a washing machine. I usually switch to desktop skin due to those limitations and never had performance issues. I dream of a skin that is designed for small touch devices, while at the same time not limiting me much and even allowing me to maintain a wiki comfortably.

      Well, maybe I went slightly off-topic, but if we had a skin designed for decent decent phones instead of (or in addition to) washing machines, we could at least get rid of that one place where it's irreplacable.

        Loading editor
    • Vengir wrote: So if a verbatim feature won't get added, it will have to be imported to javascript (thus creating extra work reviewing it)? Hmm, in many cases that could work, but maybe instead of disabling verbatim, MediaWiki edits could go through the same reviewing process? (but only ones that contain script/HTML syntax, the others, notably those with just plain wikitext, could freely go after being checked by a machine filter).

      There is another problem though: wikiamobile skin, where absolutely no standard javascript/css works and any code that is absolutely necessary needs to be injected that way. I get it that wikia wants its sites to work on washing machines, but my phone is not a washing machine. I usually switch to desktop skin due to those limitations and never had performance issues. I dream of a skin that is designed for small touch devices, while at the same time not limiting me much and even allowing me to maintain a wiki comfortably.

      Well, maybe I went slightly off-topic, but if we had a skin designed for decent decent phones instead of (or in addition to) washing machines, we could at least get rid of that one place where it's irreplacable.

      I've messaged and messaged a few staff such as Kirkburn and DaNASCAT about various bugs inside the Wikiamobile skin, but its not a priority as the staff I messaged reported horrid problems from trying to leave all the code and CSS in. Perhaps they're right, but a solution is needed especially for table widths.

      And I hope Helios and HTTPS come by September as its nice to know I can admin without being hacked or used to demote other users indefinitely by most or any means.

      PS: Feel free to read the following thread, I don't think it is massively high on their priorities and the staff always have other problems and updates to deal with.

        Loading editor
    • Is phishing even possible with just CSS?

        Loading editor
    • Sinthoniel wrote: Is phishing even possible with just CSS?

      I'm not sure if anyone has ever succeeded at phishing, but there's other things you can do. For example, if a browser security flaw is found in a browser's image parser; just modify the CSS page to bring up a background image which uses an exploit. Fairly simple.

        Loading editor
    • or just make an invisible image on top of everything that, when clicked, downloads something bad or something?

        Loading editor
    • People have lost their old accounts including myself in these past cyberattacks against wikia and it worries me that their will be even more threats that will challenge the wikia staff to its breaking point.

      The feeling of being safe is highly questionable at the moment.

        Loading editor
    • Its shocking that staff accounts did not have 2FA cos the havoc a compromised staff account could cause would be phenomenal and that's what happened. Either the hacker couldn't exploit them or they didn't get to do it and the FNAF thing was a test. I wish all the FNAF admins luck with their work there as they've been hard hit. I don't think its funny how hackers go for FNAF and its quite childish to do something like that. It is an encyclopaedic source after all.

        Loading editor
    • Speedit wrote: Its shocking that staff accounts did not have 2FA cos the havoc a compromised staff account could cause would be phenomenal. Either the hacker couldn't exploit them or they didn't get to do it and the FNAF thing was a test.

      It wouldn't be Phenomenal, it can end wikia as we know as they can have total control of the entire infrastructure and possibly erase Decades of research that has been conducted by fellow gamers like myself along with those who do not game like artists, Philosphers, historians the list goes on exceptionally.

      We're talking about virtual Defcon if that happens

        Loading editor

    • When the JS will be unlocked again?

      We really need to update them now.

      Also, in SU Wiki , why the Wikia CSS is not editable even for admins? or atleast that's just what an admin told me few days ago

        Loading editor
    • Perlen297 wrote:


      When the JS will be unlocked again?

      We really need to update them now.

      Also, in SU Wiki , why the Wikia CSS is not editable even for admins? or atleast that's just what an admin told me few days ago

      Your admins should be able to edit CSS now. A couple of days ago some wikis were hacked and thus made apparent some security flaws, there is currently no set date for when JS will be, to any degree, editable.

        Loading editor
    • The thing that worries me most isn't the restrictions on advanced JS users, who could probably write most of their code in one hit before sending it off for review, but on the way the review will pose an additional barrier to those who are just starting to learn and use JS. When learning how to code in any language, it is common to write your scripts in small parts, testing those, finding where they break, fix the problems, find out they break again, fix even more, and only then writing the next part of the function. When you're starting out, there will generally be a lot of trial and error involved, and the user will learn from the failures as much as the successes. Sending the code through a review process not only slows down this process of trial and error, but also may prevent a user from learning how to make the function properly by having any and all mistakes pointed out by the reviewer rather than letting them find them for themselves. If a person can find their own mistakes, they are more likely to remember them and as a result less likely to do them again than if somebody else just points them out. If the person wanted somebody else to make the function, they would have asked, but instead chose to do it themselves in order to learn. If you take that learning experience away from users, or even just present more barriers to the learning process, you will find far fewer people will be willing to start learning how to code in JS, which will in turn eventually lead to less people knowing how to edit JS as the current coders slowly drift away over time and there are fewer new ones to take their places.

        Loading editor
    • Imamadmad wrote: The thing that worries me most isn't the restrictions on advanced JS users, who could probably write most of their code in one hit before sending it off for review, but on the way the review will pose an additional barrier to those who are just starting to learn and use JS. When learning how to code in any language, it is common to write your scripts in small parts, testing those, finding where they break, fix the problems, find out they break again, fix even more, and only then writing the next part of the function. When you're starting out, there will generally be a lot of trial and error involved, and the user will learn from the failures as much as the successes. Sending the code through a review process not only slows down this process of trial and error, but also may prevent a user from learning how to make the function properly by having any and all mistakes pointed out by the reviewer rather than letting them find them for themselves. If a person can find their own mistakes, they are more likely to remember them and as a result less likely to do them again than if somebody else just points them out. If the person wanted somebody else to make the function, they would have asked, but instead chose to do it themselves in order to learn. If you take that learning experience away from users, or even just present more barriers to the learning process, you will find far fewer people will be willing to start learning how to code in JS, which will in turn eventually lead to less people knowing how to edit JS as the current coders slowly drift away over time and there are fewer new ones to take their places.

      This is how most of us learned Javascript, both in general and for Mediawiki.

        Loading editor
    • You can always test in your personal JS and then move to code review once you have something that works. In fact, you should probably be doing this already, so that you aren't subjecting the other people on your wiki to whatever bugs you might create while developing.

        Loading editor
    • For those interested, Wikia seems to have a HTTPS login form available at https://www.wikia.com/signin.

      You can also add ?redirect=http://example.wikia.com/ to the URL, if you'd like to be redirected to a particular wiki or page afterwards.

        Loading editor
    • "Regarding JavaScript review, it's essential to understand that not all wikias have custom JavaScript - that number is less than 4% of our 330,000 current communities."

      On the flip-side: 1 stupid administrator who had his account compromised is the sole reason for this huge planned restriction. One f****** administrator is going to cause a lot of headache for those 4% of communities who have their own custom CSS and JS files. Your statistics would be very different if you looked at the big communities only, the ones who are going to be affected the most.

      tibia.wikia.com has had issues with people spamming malicious links on content pages since 2010. If you're going to restrict us from editing common JS and CSS files because one administrator on one community got hacked out of his own stupidity and started f****** with others, then you should restrict everybody from mainspace pages because the same problem exists. Wikia accounts are not a huge deal since they aren't connected to any kind of very sensitive information like bank accounts. On the other hand, the ability for administrators to autonomously contribute interactive content for their community is a pretty big deal.

      Please get your s*** together because this planned change is absolutely ridiculous.

        Loading editor
    • Sixorish wrote: "Regarding JavaScript review, it's essential to understand that not all wikias have custom JavaScript - that number is less than 4% of our 330,000 current communities."

      On the flip-side: 1 stupid administrator who had his account compromised is the sole reason for this huge planned restriction. One f****** administrator is going to cause a lot of headache for those 4% of communities who have their own custom CSS and JS files. Your statistics would be very different if you looked at the big communities only, the ones who are going to be affected the most.

      tibia.wikia.com has had issues with people spamming malicious links on content pages since 2010. If you're going to restrict us from editing common JS and CSS files because one administrator on one community got hacked out of his own stupidity and started f****** with others, then you should restrict everybody from mainspace pages because the same problem exists. Wikia accounts are not a huge deal since they aren't connected to any kind of very sensitive information like bank accounts. On the other hand, the ability for administrators to autonomously contribute interactive content for their community is a pretty big deal.

      Please get your s*** together because this planned change is absolutely ridiculous.

      You've been censored, please stop using expletives in thread cos its improductive and doesn't help anyone. But yeah, extraordinary privelige comes with extraordinary responsibility and that's why my password has a symbol, one caps, six lowercase and five numbers. HACK THAT! 2FA would be really good for this sort of thing and I would not mind the extra effort at all, pretty much.

        Loading editor
    • I'd also like to rant about this statement as well.

      "The specific feedback is that it is unnecessary to transclude the login form on every page. Great news! We agree with that. For a long time, Wikia has been working on our backend for a new log-in and user registration system called Helios. It's built outside of the traditional MediaWiki architecture, which allows us to avoid a lot of the traps MediaWiki architecture has put us in."

      How exactly is this statement relevant ...?

      Not including the login on every page is a security problem, so you bring up your work on an upcoming login feature that avoids MediaWiki's traps ...? Wikipedia's skin, and all previous versions of it, never had the problem you describe. It's a front-end problem of your skin and it's yours and yours alone. Don't blame someone else for your own problems. I use Monobook and I have to navigate to Special:UserLogin to log in. I don't have the problem described. Wikipedia's current skin does not have the problem described. THIS PROBLEM IS CREATED BY YOU AND NOBODY ELSE. What you mean to say is that you are working on a whole new system to combat the problems of your old system because it's just too simple to change the heavy interactive login field to a link to log in.

        Loading editor
    • Sixorish wrote: I'd also like to rant about this statement as well.

      "The specific feedback is that it is unnecessary to transclude the login form on every page. Great news! We agree with that. For a long time, Wikia has been working on our backend for a new log-in and user registration system called Helios. It's built outside of the traditional MediaWiki architecture, which allows us to avoid a lot of the traps MediaWiki architecture has put us in."

      How exactly is this statement relevant ...?

      Not including the login on every page is a security problem, so you bring up your work on an upcoming login feature that avoids MediaWiki's traps ...? Wikipedia's skin, and all previous versions of it, never had the problem you describe. It's a front-end problem of your skin and it's yours and yours alone. Don't blame someone else for your own problems. I use Monobook and I have to navigate to Special:UserLogin to log in. I don't have the problem described. Wikipedia's current skin does not have the problem described. THIS PROBLEM IS CREATED BY YOU AND NOBODY ELSE. What you mean to say is that you are working on a whole new system to combat the problems of your old system because it's just too simple to change the heavy interactive login field to a link to log in.

      This isn't just about the login form. It's a security nightmare to allow anyone to just create a wiki, put malicious JS in Common.js and lure a target user there.

        Loading editor
    • TK-999 wrote:

      Sixorish wrote: I'd also like to rant about this statement as well.

      "The specific feedback is that it is unnecessary to transclude the login form on every page. Great news! We agree with that. For a long time, Wikia has been working on our backend for a new log-in and user registration system called Helios. It's built outside of the traditional MediaWiki architecture, which allows us to avoid a lot of the traps MediaWiki architecture has put us in."

      How exactly is this statement relevant ...?

      Not including the login on every page is a security problem, so you bring up your work on an upcoming login feature that avoids MediaWiki's traps ...? Wikipedia's skin, and all previous versions of it, never had the problem you describe. It's a front-end problem of your skin and it's yours and yours alone. Don't blame someone else for your own problems. I use Monobook and I have to navigate to Special:UserLogin to log in. I don't have the problem described. Wikipedia's current skin does not have the problem described. THIS PROBLEM IS CREATED BY YOU AND NOBODY ELSE. What you mean to say is that you are working on a whole new system to combat the problems of your old system because it's just too simple to change the heavy interactive login field to a link to log in.

      This isn't just about the login form. It's a security nightmare to allow anyone to just create a wiki, put malicious JS in Common.js and lure a target user there.

      They specifically addressed the feedback that the login form should not be on every page. So, the answer is: it is not relevant at all. Wikia designed their skin, including the fancy login-on-every-page aspect of it, so they should accept the blame instead of deferring the blame to MediaWiki's developers. If there's a "MediaWiki trap" for the problem being discussed then it's allowing Wikia to design their own security-flawed skin.

        Loading editor
    • The skin is probably fine with Helios, MediaWiki injection is a problem if abused tho. See, giving sysop accounts the same security as normal ones is not really a good idea and I can't repeat myself enough.

      Its not nice knowing my account just needs a run-of-the-mill universal hack to get sysop access/privileges on the backbone of Wikia's architecture. Let alone a staff account. Extraordinary risk requires extraordinary security. If no admins have refused 2FA, then it would be a good idea to force the feature on users with more than one usertag (which would be possibly poweruser), or one of sysop, vstf, codeeditor or staff specifically and cite the risk their account could pose if hacked.

       Speedit   talk contribs  13:18, August 16, 2015 (UTC)

        Loading editor
    • Now on the PLL Wikia we seem to not even be able to update certain pages on it. I have contacted VTSF but idk why its saying what we're adding is spam. Here, take a look.

      Spam filter mix up
        Loading editor
    • Replying to you on the VSTF wiki. It doesn't have anything to do with Security Measures.

        Loading editor
    • Jr Mime wrote:
      Replying to you on the VSTF wiki. It doesn't have anything to do with Security Measures.

      Alright, I wasn't 100% if it wasn't so I figured I'd post it on here as well just to be on the safe side.

        Loading editor
    • Okay. So MediaWiki such as "User-identity-box-group-sysop" is respectively protected for Staff-Only-Editing, along with Common.js. Is there a way I could possibly request Wikia Staff to edit this for me?

      Thanks.

        Loading editor
    • Jr Mime wrote:
      Replying to you on the VSTF wiki. It doesn't have anything to do with Security Measures.

      Is the issue fixed now? Can we edit this particular page now?

        Loading editor
    • Tbrays30 wrote:
      Okay. So MediaWiki such as "User-identity-box-group-sysop" is respectively protected for Staff-Only-Editing, along with Common.js. Is there a way I could possibly request Wikia Staff to edit this for me?

      Thanks.

      You probably could. I mean, the All Messages page is locked down, so if you ask staff kindly enough, they could probably edit it for you.

        Loading editor
    • Jr Mime wrote: Replying to you on the VSTF wiki.

        Loading editor
    • Hiddenlich wrote:
      Tbrays30 wrote:
      Okay. So MediaWiki such as "User-identity-box-group-sysop" is respectively protected for Staff-Only-Editing, along with Common.js. Is there a way I could possibly request Wikia Staff to edit this for me?

      Thanks.

      You probably could. I mean, the All Messages page is locked down, so if you ask staff kindly enough, they could probably edit it for you.

      Alright.

        Loading editor
    • What about for my own wiki? I'm currently the only administrator and bureaucrat on there, and someone's got to be able to edit my MediaWiki pages, not just my personal ones, but all my wiki ones.

        Loading editor
    • While I do think the hacker problem was bad, I don't really see why MediaWiki pages should be under lockdown for so long. I have my own wiki and I can't edit chat.jss, chat.css or even the emoticons. So it's very bland and boring there on chat.

      I understand locking it down when the hacker was on the loose, but haven't they been caught by now?

        Loading editor
    • SonicStorm478 wrote:
      While I do think the hacker problem was bad, I don't really see why MediaWiki pages should be under lockdown for so long. I have my own wiki and I can't edit chat.jss, chat.css or even the emoticons. So it's very bland and boring there on chat.

      I understand locking it down when the hacker was on the loose, but haven't they been caught by now?

      I know how you feel.

        Loading editor
    • They are locked down because they pose an enormous security threat. Regardless of whether or not that user is still here the security hole is still very much there and it is still a threat to Wikia.

      It is unfortunate that you can't edit these for the moment but it is for the better.

        Loading editor
    • As long as we'll be able to edit these pages again on our respective wikis as administrators in the future whether it be near or distant, then I'm not too worried.

        Loading editor
    • Me too.

        Loading editor
    • SonicStorm478 wrote:
      While I do think the hacker problem was bad, I don't really see why MediaWiki pages should be under lockdown for so long. I have my own wiki and I can't edit chat.jss, chat.css or even the emoticons. So it's very bland and boring there on chat.

      I understand locking it down when the hacker was on the loose, but haven't they been caught by now?

      Be caught? I doubt it. But I guess some people have lost their accounts to hackers. A good hacker tries to never use his own computer or account for attacks.

        Loading editor
    • I'm just going to say one simple thing- Some wikis need the color and other .ss pages unlocked (At least for staff on the wikis) to update it or the wiki's new pages look outdated compared to the older ones. Can you make it so anyone with a rank on that wiki can assess them instead of just staff on THIS wiki/staff members of wikia? I now leave and see how this turns out.

        Loading editor
    • You say only 4% of communities have custom JavaScript, but that still is13200 communities which are inconvenienced. Also people make repeat edits, how are people supposed to test JavaScript with this review process?

      For God's sake, just put the damn login form on a seperate, JS-free page! Surely that would solve  many security concerns! Why have you not addressed that issue, staff? Get your act togethor.

        Loading editor
    • Shining-Armor wrote: They are locked down because they pose an enormous security threat. Regardless of whether or not that user is still here the security hole is still very much there and it is still a threat to Wikia.

      It is unfortunate that you can't edit these for the moment but it is for the better.

      I sent a Mediawiki edit request to add a template to the Licenses page in the MediaWiki space, what's the chance of staff backlog on the request or the request being denied for security reasons. I mean, there are templates already linked to it so its probably not a problem as such.

        Loading editor
    • 213.120.234.122 wrote: You say only 4% of communities have custom JavaScript, but that still is13200 communities which are inconvenienced. Also people make repeat edits, how are people supposed to test JavaScript with this review process?

      For God's sake, just put the damn login form on a seperate, JS-free page! Surely that would solve  many security concerns! Why have you not addressed that issue, staff? Get your act togethor.

      You test JS by typing it out in a text editor, pasting it into your browser console, and checking for error/unexpected behavior. If it is functioning fine then write it to a page, if not then rinse and repeat.

      As stated many times though the login form is not the only security issue. The main issue is that there are thousands of wikis that are unmonitored and anyone can write w/e JS they want and put it on one. After putting malicious code on one and luring users to it you can do quite a bit of damage as seen. The issues lie within a completely unchecked system where all JS can be put anywhere, not just in the login form.

        Loading editor
    • 213.120.234.122 wrote: You say only 4% of communities have custom JavaScript, but that still is13200 communities which are inconvenienced. Also people make repeat edits, how are people supposed to test JavaScript with this review process?

      For God's sake, just put the damn login form on a seperate, JS-free page! Surely that would solve  many security concerns! Why have you not addressed that issue, staff? Get your act togethor.

      They've got a new architecture that will roll out with SSL/TLS that will fix this called Helios. The skin will stay and the Helios will allow a secure implementation of this.

      They have clearly addressed this issue many times, please take care to read DaNASCAT's comments so that your comments are more informed. The Helios developement was well underway, and this issue has only galvanised these efforts to bring secure login on all pages with SSL/TLS involved.

        Loading editor
    • JS runs on the user's side. if the vulnerability of user data is closed, there are other vulnerabilities that cannot be detected by the user. as I understand the problem is the import scripts from external sites and sending statistics about the user to "enemies". it's always been the problem owners hosting. but why should it become a problem for the editors of js and entire wikis?

      the test scripts do not exclude the presence of malware. solve a problem where its source. if this is the essence of the language, figure out how to fix it, use a different language but do not put obstacles to the free edit.

        Loading editor
    • Sixorish wrote:

      TK-999 wrote:

      Sixorish wrote: I'd also like to rant about this statement as well.

      "The specific feedback is that it is unnecessary to transclude the login form on every page. Great news! We agree with that. For a long time, Wikia has been working on our backend for a new log-in and user registration system called Helios. It's built outside of the traditional MediaWiki architecture, which allows us to avoid a lot of the traps MediaWiki architecture has put us in."

      How exactly is this statement relevant ...?

      Not including the login on every page is a security problem, so you bring up your work on an upcoming login feature that avoids MediaWiki's traps ...? Wikipedia's skin, and all previous versions of it, never had the problem you describe. It's a front-end problem of your skin and it's yours and yours alone. Don't blame someone else for your own problems. I use Monobook and I have to navigate to Special:UserLogin to log in. I don't have the problem described. Wikipedia's current skin does not have the problem described. THIS PROBLEM IS CREATED BY YOU AND NOBODY ELSE. What you mean to say is that you are working on a whole new system to combat the problems of your old system because it's just too simple to change the heavy interactive login field to a link to log in.

      This isn't just about the login form. It's a security nightmare to allow anyone to just create a wiki, put malicious JS in Common.js and lure a target user there.

      They specifically addressed the feedback that the login form should not be on every page. So, the answer is: it is not relevant at all. Wikia designed their skin, including the fancy login-on-every-page aspect of it, so they should accept the blame instead of deferring the blame to MediaWiki's developers. If there's a "MediaWiki trap" for the problem being discussed then it's allowing Wikia to design their own security-flawed skin.

      We've visited the topic of Wikia's domain-based design decisions in general MANY MANY times. When you go to Wikia, expect ads, login on all pages and other things that the staff have conclusively and internally developed a consensus for. Your complaint will probably not be accepted under the reason that all contribution-based online communities are currently growing with low-editcount users and are losing the 1% of top-quality editors at haemorrhaging speed. The uptake of new editors WILL slow if the option is removed. I see no point in removing it if it can be patched with Helios and I want to see more editors around Wikia so I agree with the staff. The staff decide to try and do what's best for Wikia and implement that in a secure way. We should trust them to take care of the domain and security while we edit. You can try to convince them to use a login page but its probably not going to change, even though existing users would be happy for a secure TLS/SSL login page.

      Good luck with that suggestion however.

        Loading editor
    • TK-999 wrote: Its laconical description (link retracted) summarizes it as a "Wikia approach to user authentication." IMO it should address most shortcomings and security issues of the current system.

      From the code library description and the size of the library, looks well underway. They'll be using the OAuth2 certification, which Google ported to 4 months back; more great news. Seems like we will have secure JS login embedded in all the pages with partial/full SSL and Mediawiki's account sytem.

        Loading editor
    • And here I am, wondering why emoticons are blocked too.

        Loading editor
    • Why is messaging to new users also switched off? Not editable or active.

        Loading editor
    • CyanSkull wrote:
      And here I am, wondering why emoticons are blocked too.

      They strangely blocked off the Mediawiki page to administrators. I asked about the page being blocked, but no one has cared to shed light on it. I mean, if some Mediawikis are being allowed to admins, that page should be one of them.

        Loading editor
    • Hiddenlich wrote:

      They strangely blocked off the Mediawiki page to administrators. I asked about the page being blocked, but no one has cared to shed light on it. I mean, if some Mediawikis are being allowed to admins, that page should be one of them.

      Since the beginning of time, MediaWiki pages have always been locked to sysops. That I'm fine with. What I'm not fine with is peer reviewing every single change to the code in order to ensure well-known and functional code works.

        Loading editor
    • Brainulator9 wrote:
      Hiddenlich wrote:
      They strangely blocked off the Mediawiki page to administrators. I asked about the page being blocked, but no one has cared to shed light on it. I mean, if some Mediawikis are being allowed to admins, that page should be one of them.
      Since the beginning of time, MediaWiki pages have always been locked to sysops. That I'm fine with. What I'm not fine with is peer reviewing every single change to the code in order to ensure well-known and functional code works.

      What I am talking about is that administrators can't edit the Emoticon page. Only staff can.

        Loading editor
    • Brainulator9 wrote:

      Hiddenlich wrote:

      They strangely blocked off the Mediawiki page to administrators. I asked about the page being blocked, but no one has cared to shed light on it. I mean, if some Mediawikis are being allowed to admins, that page should be one of them.

      Since the beginning of time, MediaWiki pages have always been locked to sysops. That I'm fine with. What I'm not fine with is peer reviewing every single change to the code in order to ensure well-known and functional code works.

      I completely disagree!

      I find that when multiple developers examine and contribute to the code it tends to produce better and more error free code and thus a better product for the end user.

      Not only that but it also adds an extra layer of security as any malicious/bad code that may try to slip through will be quickly blocked.

      All-in-all I would love to see more peer-reviewing on Wikia (and have subsequently created this GitHub organization to facilitate that!).

        Loading editor
    • Why did they block off the emoticons to the admins though? What is the harm with that? Admins should be able to edit it without having to ask staff to add the emoticons for them. It's ridiculous.

        Loading editor
    • Hiddenlich wrote:
      Why did they block off the emoticons to the admins though? What is the harm with that? Admins should be able to edit it without having to ask staff to add the emoticons for them. It's ridiculous.

      Because they blocked all the MediaWiki pages.

        Loading editor
    • 89.241.67.207 wrote:
      Hiddenlich wrote:
      Why did they block off the emoticons to the admins though? What is the harm with that? Admins should be able to edit it without having to ask staff to add the emoticons for them. It's ridiculous.
      Because they blocked all the MediaWiki pages.

      No. They unlocked some pages so that admins could edit them. If you read the post above, you would have noticed it.

        Loading editor
    • Hiddenlich wrote: Why did they block off the emoticons to the admins though? What is the harm with that? Admins should be able to edit it without having to ask staff to add the emoticons for them. It's ridiculous.

      Well, they have a good reason- you don't want some cool admin to add a FNAF gif that will cause everyone who watches it a heart attack. Only MLP gifs are allowed! iBU22xs.gif

        Loading editor
    • Penguin-Pal wrote:

      Well, they have a good reason- you don't want some cool admin to add a FNAF gif that will cause everyone who watches it a heart attack. Only MLP gifs are allowed! iBU22xs.gif

      Not on all wikis.

        Loading editor
    • Shining-Armor wrote:

      All-in-all I would love to see more peer-reviewing on Wikia (and have subsequently created this GitHub organization to facilitate that!).

      the organization must have a common goal. if the purpose of a member organization is the creation of an advanced sorting of table for mlp wiki, and the goal of the other is sliders for everyone it's just two lone persons "collected in one place".

      having a common space to work does not guarantee assistance and support from others.

      the idea "to edit the wiki you need to use an external service" quite unattractive

        Loading editor
    • Hedgeg wrote: the idea "to edit the wiki you need to use an external service" quite unattractive

      Agreed. Can't the review system just be based inside the wiki? I think having a GitHub makes things unnecessarily complicated.

        Loading editor
    • Vogel100 wrote:

      Hedgeg wrote: the idea "to edit the wiki you need to use an external service" quite unattractive

      Agreed. Can't the review system just be based inside the wiki? I think having a GitHub makes things unnecessarily complicated.

      Please see this.

        Loading editor
    • Yes, right now we know nothing about the device of "js test system".


      rephrase: "GitHub is not solution for everyone", "Its utopia" imo

        Loading editor
    • Why can't we edit the emoticons? Seriously, we can edit the Wikia.css (which can be much more destructive), but we can't add a silly picture to chat.

        Loading editor
    • Hedgeg wrote:

      Shining-Armor wrote:

      All-in-all I would love to see more peer-reviewing on Wikia (and have subsequently created this GitHub organization to facilitate that!).

      the organization must have a common goal. if the purpose of a member organization is the creation of an advanced sorting of table for mlp wiki, and the goal of the other is sliders for everyone it's just two lone persons "collected in one place".

      having a common space to work does not guarantee assistance and support from others.

      the idea "to edit the wiki you need to use an external service" quite unattractive

      The complete goal of WikiaDevs is:

      To create a library of peer-reviewed code for Wikians

      Right now there are two members of the group (and a third on the way!) and we are hoping to get more as time goes on.

      Though, having a common space dedicated to peer-reviewing code pretty much guarantees that the code will be peer-reviewed.

      As stated earlier you do not need to use this to create scripts. This group is completely optional for users who wish to participate in a peer-review scheme.

        Loading editor
    • Nice to see that something is underway. Hopefully the system will have the simplicity of automatic edit summaries in selecting code and the Import tool in inserting it securely. I wish you and the Wikia staff good luck with that, @Shining-Armor.

        Loading editor
    • Sorry to ask but: Is there a time frame of when it might be turned back on?

      Thanks.

        Loading editor
    • Hello,

      As of this morning we have begun to re-enable JS editing on a few of our top communities. We will then be scaling it downward as the week moves along. If at the end of the week your community still does not have proper access to JS editing, please send a message into Special:Contact.

      As stated earlier in the thread, ultimately we are still a few weeks away from being able to release some new features that will hopefully address a number of security holes while adding some extra features. Until then, some of these security measures will remain in place. We will communicate additional changes as needed and certainly preview the new features as soon as we possibly can.

        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message