Thanks for your work on this, Chris.
Forwarding to Wikitech-l.
Pine On Apr 20, 2015 4:58 PM, "Chris Steipp" csteipp@wikimedia.org wrote:
On Apr 20, 2015 4:13 PM, "Andrew Sherman" asherman@wikimedia.org wrote:
Hello Everyone,
We just published "Improving the security of our users on Wikimedia
sites" to the blog. URL:
https://blog.wikimedia.org/2015/04/20/improving-security-for-our-users/
Thanks to Chris for writing and helping us edit this post.
Below are some proposed social media messages. Tweak as needed.
We teamed up with @iSECPartners and @OpenTechFund to assess the security
of our sites. Check out the report here [link]
FB/G+
We teamed up with iSEC Partners to assess the security of our sites and
protect the privacy of our users. Their engineers developed attacks against the current version of MediaWiki to identify security flaws, in a new report sponsored by the Open Technology Fund. [link]
Maybe just "MediaWiki" instead of "the current version of MediaWiki", since we did a release to specifically fix issues that they found. Might confuse some people as is.
Thanks,
Andrew Sherman Digital Communications | Wikimedia Foundation
E: asherman@wikimedia.org WMF: ASherman (WMF)
Social-media mailing list Social-media@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/social-media
I personally find one of the suggestions in the report worrying:
"Eliminate custom CSS/JavaScript. iSEC found multiple issues with the custom JavaScript system. This system appears to pose significant risk for relatively small benefit. As such, iSEC recommends that Wikimedia Foundation deprecate this functionality and allow users instead to customize their experience on the client side using browser extensions such as Greasemonkey or Tampermonkey."
This is related to one of the problems identified by the team: "Users can inspect each other's personal JavaScript"
While the custom JS is used by a relatively small number of users, the ability to learn and copy another user's scripts has played an important part in the development(and maintenance) of scripts that are now considered essential by many Wikimedians (twinkle and wikied come to mind).
Furthermore, replacing those script with Greasemonkey scripts would lead to a "black market" of Wiki-scripts shared through channels external to our sites. Those scripts would be even more prone to social engineering attacks and could endanger our user's security.
I would like to know if the WMF is indeed considering completely dropping the custom JS feature and if so, what is the timeline for this change?
Thanks, Strainu
2015-04-21 4:41 GMT+03:00 Pine W wiki.pine@gmail.com:
Thanks for your work on this, Chris.
Forwarding to Wikitech-l.
Pine On Apr 20, 2015 4:58 PM, "Chris Steipp" csteipp@wikimedia.org wrote:
On Apr 20, 2015 4:13 PM, "Andrew Sherman" asherman@wikimedia.org wrote:
Hello Everyone,
We just published "Improving the security of our users on Wikimedia
sites" to the blog. URL:
https://blog.wikimedia.org/2015/04/20/improving-security-for-our-users/
Thanks to Chris for writing and helping us edit this post.
Below are some proposed social media messages. Tweak as needed.
We teamed up with @iSECPartners and @OpenTechFund to assess the security
of our sites. Check out the report here [link]
FB/G+
We teamed up with iSEC Partners to assess the security of our sites and
protect the privacy of our users. Their engineers developed attacks against the current version of MediaWiki to identify security flaws, in a new report sponsored by the Open Technology Fund. [link]
Maybe just "MediaWiki" instead of "the current version of MediaWiki", since we did a release to specifically fix issues that they found. Might confuse some people as is.
Thanks,
Andrew Sherman Digital Communications | Wikimedia Foundation
E: asherman@wikimedia.org WMF: ASherman (WMF)
Social-media mailing list Social-media@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/social-media
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Let me just say that removing custom JS from Wikimedia sites would cause the mother of all shitstorms amongst the "old hands" editors, including Yours Truly. It would make the German Wikipedia resistance to the Media Viewer seem like a mild, slightly fragrant breeze. I do not believe the Foundation would actually consider doing this.
On Mon, Apr 27, 2015 at 4:36 PM Strainu strainu10@gmail.com wrote:
I personally find one of the suggestions in the report worrying:
"Eliminate custom CSS/JavaScript. iSEC found multiple issues with the custom JavaScript system. This system appears to pose significant risk for relatively small benefit. As such, iSEC recommends that Wikimedia Foundation deprecate this functionality and allow users instead to customize their experience on the client side using browser extensions such as Greasemonkey or Tampermonkey."
This is related to one of the problems identified by the team: "Users can inspect each other's personal JavaScript"
While the custom JS is used by a relatively small number of users, the ability to learn and copy another user's scripts has played an important part in the development(and maintenance) of scripts that are now considered essential by many Wikimedians (twinkle and wikied come to mind).
Furthermore, replacing those script with Greasemonkey scripts would lead to a "black market" of Wiki-scripts shared through channels external to our sites. Those scripts would be even more prone to social engineering attacks and could endanger our user's security.
I would like to know if the WMF is indeed considering completely dropping the custom JS feature and if so, what is the timeline for this change?
Thanks, Strainu
2015-04-21 4:41 GMT+03:00 Pine W wiki.pine@gmail.com:
Thanks for your work on this, Chris.
Forwarding to Wikitech-l.
Pine On Apr 20, 2015 4:58 PM, "Chris Steipp" csteipp@wikimedia.org wrote:
On Apr 20, 2015 4:13 PM, "Andrew Sherman" asherman@wikimedia.org
wrote:
Hello Everyone,
We just published "Improving the security of our users on Wikimedia
sites" to the blog. URL:
https://blog.wikimedia.org/2015/04/20/improving-security-for-our-users/
Thanks to Chris for writing and helping us edit this post.
Below are some proposed social media messages. Tweak as needed.
We teamed up with @iSECPartners and @OpenTechFund to assess the
security
of our sites. Check out the report here [link]
FB/G+
We teamed up with iSEC Partners to assess the security of our sites
and
protect the privacy of our users. Their engineers developed attacks
against
the current version of MediaWiki to identify security flaws, in a new report sponsored by the Open Technology Fund. [link]
Maybe just "MediaWiki" instead of "the current version of MediaWiki", since we did a release to specifically fix issues that they found. Might confuse some people as is.
Thanks,
Andrew Sherman Digital Communications | Wikimedia Foundation
E: asherman@wikimedia.org WMF: ASherman (WMF)
Social-media mailing list Social-media@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/social-media
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, 27 Apr 2015 17:41:06 +0200, Magnus Manske magnusmanske@googlemail.com wrote:
Let me just say that removing custom JS from Wikimedia sites would cause the mother of all shitstorms
Indeed, I think everyone is aware of that.
All activity related to publishing this report (and fixing the bugs mentioned in it) was tracked on https://phabricator.wikimedia.org/T85862 (which has been now made public, it used to be private), which doesn't seem to be linked in the blog post.
Two subtasks related to user JS system are https://phabricator.wikimedia.org/T85855 and https://phabricator.wikimedia.org/T85856 , you can read the discussion there. No one was seriously considering getting rid of the system.
Hi Strainu,
We were trying to balance how much data vs summary information to give to people, but you can find the issues vs. resolution table here:
https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Check/iSEC_Assessment...
For the issue you pointed out in particular, we have https://phabricator.wikimedia.org/T85856 where you can follow the discussion. The end result was that this was a low severity issue, we're definitely not going to do away with user javascript, instead we may add a warning if we can find a useful UX experience for the user.
On Mon, Apr 27, 2015 at 8:35 AM, Strainu strainu10@gmail.com wrote:
I personally find one of the suggestions in the report worrying:
"Eliminate custom CSS/JavaScript. iSEC found multiple issues with the custom JavaScript system. This system appears to pose significant risk for relatively small benefit. As such, iSEC recommends that Wikimedia Foundation deprecate this functionality and allow users instead to customize their experience on the client side using browser extensions such as Greasemonkey or Tampermonkey."
This is related to one of the problems identified by the team: "Users can inspect each other's personal JavaScript"
While the custom JS is used by a relatively small number of users, the ability to learn and copy another user's scripts has played an important part in the development(and maintenance) of scripts that are now considered essential by many Wikimedians (twinkle and wikied come to mind).
Furthermore, replacing those script with Greasemonkey scripts would lead to a "black market" of Wiki-scripts shared through channels external to our sites. Those scripts would be even more prone to social engineering attacks and could endanger our user's security.
I would like to know if the WMF is indeed considering completely dropping the custom JS feature and if so, what is the timeline for this change?
Thanks, Strainu
2015-04-21 4:41 GMT+03:00 Pine W wiki.pine@gmail.com:
Thanks for your work on this, Chris.
Forwarding to Wikitech-l.
Pine On Apr 20, 2015 4:58 PM, "Chris Steipp" csteipp@wikimedia.org wrote:
On Apr 20, 2015 4:13 PM, "Andrew Sherman" asherman@wikimedia.org
wrote:
Hello Everyone,
We just published "Improving the security of our users on Wikimedia
sites" to the blog. URL:
https://blog.wikimedia.org/2015/04/20/improving-security-for-our-users/
Thanks to Chris for writing and helping us edit this post.
Below are some proposed social media messages. Tweak as needed.
We teamed up with @iSECPartners and @OpenTechFund to assess the
security
of our sites. Check out the report here [link]
FB/G+
We teamed up with iSEC Partners to assess the security of our sites
and
protect the privacy of our users. Their engineers developed attacks
against
the current version of MediaWiki to identify security flaws, in a new report sponsored by the Open Technology Fund. [link]
Maybe just "MediaWiki" instead of "the current version of MediaWiki", since we did a release to specifically fix issues that they found. Might confuse some people as is.
Thanks,
Andrew Sherman Digital Communications | Wikimedia Foundation
E: asherman@wikimedia.org WMF: ASherman (WMF)
Social-media mailing list Social-media@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/social-media
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2015-04-27 18:51 GMT+03:00 Chris Steipp csteipp@wikimedia.org:
Hi Strainu,
Thanks for the additional information Chris!
We were trying to balance how much data vs summary information to give to people, but you can find the issues vs. resolution table here:
https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Check/iSEC_Assessment...
I was happy to see that some of the issues found by iSEC was previously identified in-house. However, I couldn't help noticing that https://phabricator.wikimedia.org/T64685 lingered for almost an year (or more, I'm not sure if the bugzilla import kept the dates) and the patch was only merged after this report found the bug as well. We all know the WMF is slow in merging patches, especially from outsiders, but shouldn't you have *some* guidelines (or preferably rules) on the time that a security bug can stay opened?
I'm not trying to start yet another endless fight between WMF staff and the community, but the tendency in the last few years has been for the researchers to release the vulnerabilities after a certain time regardless if the software has been patched or not. Seeing MW exploits in the wild and knowing that developers had a chance to fix them and didn't does not help WMF's image.
Regards, Strainu
For the issue you pointed out in particular, we have https://phabricator.wikimedia.org/T85856 where you can follow the discussion. The end result was that this was a low severity issue, we're definitely not going to do away with user javascript, instead we may add a warning if we can find a useful UX experience for the user.
On Mon, Apr 27, 2015 at 8:35 AM, Strainu strainu10@gmail.com wrote:
I personally find one of the suggestions in the report worrying:
"Eliminate custom CSS/JavaScript. iSEC found multiple issues with the custom JavaScript system. This system appears to pose significant risk for relatively small benefit. As such, iSEC recommends that Wikimedia Foundation deprecate this functionality and allow users instead to customize their experience on the client side using browser extensions such as Greasemonkey or Tampermonkey."
This is related to one of the problems identified by the team: "Users can inspect each other's personal JavaScript"
While the custom JS is used by a relatively small number of users, the ability to learn and copy another user's scripts has played an important part in the development(and maintenance) of scripts that are now considered essential by many Wikimedians (twinkle and wikied come to mind).
Furthermore, replacing those script with Greasemonkey scripts would lead to a "black market" of Wiki-scripts shared through channels external to our sites. Those scripts would be even more prone to social engineering attacks and could endanger our user's security.
I would like to know if the WMF is indeed considering completely dropping the custom JS feature and if so, what is the timeline for this change?
Thanks, Strainu
2015-04-21 4:41 GMT+03:00 Pine W wiki.pine@gmail.com:
Thanks for your work on this, Chris.
Forwarding to Wikitech-l.
Pine On Apr 20, 2015 4:58 PM, "Chris Steipp" csteipp@wikimedia.org wrote:
On Apr 20, 2015 4:13 PM, "Andrew Sherman" asherman@wikimedia.org
wrote:
Hello Everyone,
We just published "Improving the security of our users on Wikimedia
sites" to the blog. URL:
https://blog.wikimedia.org/2015/04/20/improving-security-for-our-users/
Thanks to Chris for writing and helping us edit this post.
Below are some proposed social media messages. Tweak as needed.
We teamed up with @iSECPartners and @OpenTechFund to assess the
security
of our sites. Check out the report here [link]
FB/G+
We teamed up with iSEC Partners to assess the security of our sites
and
protect the privacy of our users. Their engineers developed attacks
against
the current version of MediaWiki to identify security flaws, in a new report sponsored by the Open Technology Fund. [link]
Maybe just "MediaWiki" instead of "the current version of MediaWiki", since we did a release to specifically fix issues that they found. Might confuse some people as is.
Thanks,
Andrew Sherman Digital Communications | Wikimedia Foundation
E: asherman@wikimedia.org WMF: ASherman (WMF)
Social-media mailing list Social-media@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/social-media
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Apr 27, 2015 at 2:32 PM, Strainu strainu10@gmail.com wrote:
2015-04-27 18:51 GMT+03:00 Chris Steipp csteipp@wikimedia.org:
Hi Strainu,
Thanks for the additional information Chris!
We were trying to balance how much data vs summary information to give to people, but you can find the issues vs. resolution table here:
https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Check/iSEC_Assessment...
I was happy to see that some of the issues found by iSEC was previously identified in-house. However, I couldn't help noticing that https://phabricator.wikimedia.org/T64685 lingered for almost an year (or more, I'm not sure if the bugzilla import kept the dates) and the patch was only merged after this report found the bug as well. We all know the WMF is slow in merging patches, especially from outsiders, but shouldn't you have *some* guidelines (or preferably rules) on the time that a security bug can stay opened?
Hi Stainu,
I specifically addressed this in the "What did we learn?" section of the blog post. We are hiring to make sure we can address issues faster.
In this particular case, if we had any indication that the issue was known outside the WMF, or being abused, I would have raised the priority and addressed it ahead of other issues that I'm working on.
I'm not trying to start yet another endless fight between WMF staff and the community, but the tendency in the last few years has been for the researchers to release the vulnerabilities after a certain time regardless if the software has been patched or not. Seeing MW exploits in the wild and knowing that developers had a chance to fix them and didn't does not help WMF's image.
Regards, Strainu
For the issue you pointed out in particular, we have https://phabricator.wikimedia.org/T85856 where you can follow the discussion. The end result was that this was a low severity issue, we're definitely not going to do away with user javascript, instead we may add
a
warning if we can find a useful UX experience for the user.
On Mon, Apr 27, 2015 at 8:35 AM, Strainu strainu10@gmail.com wrote:
I personally find one of the suggestions in the report worrying:
"Eliminate custom CSS/JavaScript. iSEC found multiple issues with the custom JavaScript system. This system appears to pose significant risk for relatively small benefit. As such, iSEC recommends that Wikimedia Foundation deprecate this functionality and allow users instead to customize their experience on the client side using browser extensions such as Greasemonkey or Tampermonkey."
This is related to one of the problems identified by the team: "Users can inspect each other's personal JavaScript"
While the custom JS is used by a relatively small number of users, the ability to learn and copy another user's scripts has played an important part in the development(and maintenance) of scripts that are now considered essential by many Wikimedians (twinkle and wikied come to mind).
Furthermore, replacing those script with Greasemonkey scripts would lead to a "black market" of Wiki-scripts shared through channels external to our sites. Those scripts would be even more prone to social engineering attacks and could endanger our user's security.
I would like to know if the WMF is indeed considering completely dropping the custom JS feature and if so, what is the timeline for this change?
Thanks, Strainu
2015-04-21 4:41 GMT+03:00 Pine W wiki.pine@gmail.com:
Thanks for your work on this, Chris.
Forwarding to Wikitech-l.
Pine On Apr 20, 2015 4:58 PM, "Chris Steipp" csteipp@wikimedia.org
wrote:
On Apr 20, 2015 4:13 PM, "Andrew Sherman" asherman@wikimedia.org
wrote:
Hello Everyone,
We just published "Improving the security of our users on Wikimedia
sites" to the blog. URL:
https://blog.wikimedia.org/2015/04/20/improving-security-for-our-users/
Thanks to Chris for writing and helping us edit this post.
Below are some proposed social media messages. Tweak as needed.
We teamed up with @iSECPartners and @OpenTechFund to assess the
security
of our sites. Check out the report here [link]
FB/G+
We teamed up with iSEC Partners to assess the security of our sites
and
protect the privacy of our users. Their engineers developed attacks
against
the current version of MediaWiki to identify security flaws, in a new report sponsored by the Open Technology Fund. [link]
Maybe just "MediaWiki" instead of "the current version of MediaWiki", since we did a release to specifically fix issues that they found.
Might
confuse some people as is.
Thanks,
Andrew Sherman Digital Communications | Wikimedia Foundation
E: asherman@wikimedia.org WMF: ASherman (WMF)
Social-media mailing list Social-media@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/social-media
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org