We have Interactive graphs from OWID working on Basque Wikipedia, following a consent popup.
https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
Still need to figure out a way to make them multilingual.
Thanks, James, for all the work done, We now have 14 articles with interactive graphs, as we are exploring this new feature:https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten.... The deployment is pretty easy, it took around 10 minutes with only four things: a template, a css, a js and a gadget definition. This is so simple, that I think it should be implemented by everyone.
We should think on how we make it multilingual.
Thanks again to all the members of WikiProject Med for the step forward.
Galder ________________________________ From: James Heilman jmh649@gmail.com Sent: Tuesday, April 16, 2024 11:14 PM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
We have Interactive graphs from OWID working on Basque Wikipedia, following a consent popup.
https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
Still need to figure out a way to make them multilingual.
-- James Heilman MD, CCFP-EM, Wikipedian
Amazing work, James and Galder!
Today I was bold, made it fully multilingual and generalized it so that it can be easily installed in any wiki (Wikimedia or not). See https://www.mediawiki.org/wiki/Template:OWID for the documentation and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code and https://www.mediawiki.org/wiki/Template_gadgets for more context
Galder, perhaps you'd like to update the usage at the Basque Wikipedia (see https://www.mediawiki.org/wiki/Template:OWID) so as to help centralize and coordinate our efforts? Some technical notes: - I simplified the code considerably using the pre-built methods OO.ui.alert and OO.ui.confirm rather than those complicated (and unnecessary, in this case) OOUI classes. I hope you like it. - I wrapped the code with an "OWID" object to keep it out of the global space and make sure the 'oojs-ui-windows' dependency is always loaded. - The localized messages should probably be moved to their own JSON file and loaded from there, but I'm not sure about the best way to do that while keep it template gadgets centralized at MediaWiki.org, and possibly having the strings translated by translatewiki.net. Perhaps we can set up a call to discuss some options?
PS, I enabled the template on the Spanish Wikipedia (see https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some local trouble with template gadgets so it's not working right now. I should be able to fix it in the next few hours.
On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks, James, for all the work done, We now have 14 articles with interactive graphs, as we are exploring this new feature: https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten.... The deployment is pretty easy, it took around 10 minutes with only four things: a template, a css, a js and a gadget definition. This is so simple, that I think it should be implemented by everyone.
We should think on how we make it multilingual.
Thanks again to all the members of WikiProject Med for the step forward.
Galder
*From:* James Heilman jmh649@gmail.com *Sent:* Tuesday, April 16, 2024 11:14 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
We have Interactive graphs from OWID working on Basque Wikipedia, following a consent popup.
https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
Still need to figure out a way to make them multilingual.
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
This is exciting -- let's make sure we capture any usage requirements for the upcoming Graphs modernization work so we can have these features built in again soon!
-- brooke
On Wed, Apr 17, 2024 at 7:43 AM Felipe Schenone schenonef@gmail.com wrote:
Amazing work, James and Galder!
Today I was bold, made it fully multilingual and generalized it so that it can be easily installed in any wiki (Wikimedia or not). See https://www.mediawiki.org/wiki/Template:OWID for the documentation and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code and https://www.mediawiki.org/wiki/Template_gadgets for more context
Galder, perhaps you'd like to update the usage at the Basque Wikipedia (see https://www.mediawiki.org/wiki/Template:OWID) so as to help centralize and coordinate our efforts? Some technical notes:
- I simplified the code considerably using the pre-built methods
OO.ui.alert and OO.ui.confirm rather than those complicated (and unnecessary, in this case) OOUI classes. I hope you like it.
- I wrapped the code with an "OWID" object to keep it out of the global
space and make sure the 'oojs-ui-windows' dependency is always loaded.
- The localized messages should probably be moved to their own JSON file
and loaded from there, but I'm not sure about the best way to do that while keep it template gadgets centralized at MediaWiki.org, and possibly having the strings translated by translatewiki.net. Perhaps we can set up a call to discuss some options?
PS, I enabled the template on the Spanish Wikipedia (see https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some local trouble with template gadgets so it's not working right now. I should be able to fix it in the next few hours.
On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks, James, for all the work done, We now have 14 articles with interactive graphs, as we are exploring this new feature: https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten.... The deployment is pretty easy, it took around 10 minutes with only four things: a template, a css, a js and a gadget definition. This is so simple, that I think it should be implemented by everyone.
We should think on how we make it multilingual.
Thanks again to all the members of WikiProject Med for the step forward.
Galder
*From:* James Heilman jmh649@gmail.com *Sent:* Tuesday, April 16, 2024 11:14 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
We have Interactive graphs from OWID working on Basque Wikipedia, following a consent popup.
https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
Still need to figure out a way to make them multilingual.
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
A bit more background on Our World in Data.
They currently have about 4,500 data visualization https://ourworldindata.org/charts
They come in two main formats:
1) Grapher: These are simpler and their older work https://ourworldindata.org/grapher/deaths-from-substance-disorders 2) Explorers: These are newer with more ways to adjust data https://ourworldindata.org/explorers/natural-resources
Both of these work via the consent pop up workflow.
We last coordinated the mass upload of still images from OWID to Commons in 2020. https://commons.wikimedia.org/wiki/Category:Our_World_in_Data And are beginning to look at doing an update. One thought as part of this update would be to include within the commons page the mediawiki markup needed to have the consent pop up work in target languages that have it activated.
James
On Wed, Apr 17, 2024 at 1:29 PM Brooke Vibber bvibber@wikimedia.org wrote:
This is exciting -- let's make sure we capture any usage requirements for the upcoming Graphs modernization work so we can have these features built in again soon!
-- brooke
On Wed, Apr 17, 2024 at 7:43 AM Felipe Schenone schenonef@gmail.com wrote:
Amazing work, James and Galder!
Today I was bold, made it fully multilingual and generalized it so that it can be easily installed in any wiki (Wikimedia or not). See https://www.mediawiki.org/wiki/Template:OWID for the documentation and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code and https://www.mediawiki.org/wiki/Template_gadgets for more context
Galder, perhaps you'd like to update the usage at the Basque Wikipedia (see https://www.mediawiki.org/wiki/Template:OWID) so as to help centralize and coordinate our efforts? Some technical notes:
- I simplified the code considerably using the pre-built methods
OO.ui.alert and OO.ui.confirm rather than those complicated (and unnecessary, in this case) OOUI classes. I hope you like it.
- I wrapped the code with an "OWID" object to keep it out of the global
space and make sure the 'oojs-ui-windows' dependency is always loaded.
- The localized messages should probably be moved to their own JSON file
and loaded from there, but I'm not sure about the best way to do that while keep it template gadgets centralized at MediaWiki.org, and possibly having the strings translated by translatewiki.net. Perhaps we can set up a call to discuss some options?
PS, I enabled the template on the Spanish Wikipedia (see https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some local trouble with template gadgets so it's not working right now. I should be able to fix it in the next few hours.
On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks, James, for all the work done, We now have 14 articles with interactive graphs, as we are exploring this new feature: https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten.... The deployment is pretty easy, it took around 10 minutes with only four things: a template, a css, a js and a gadget definition. This is so simple, that I think it should be implemented by everyone.
We should think on how we make it multilingual.
Thanks again to all the members of WikiProject Med for the step forward.
Galder
*From:* James Heilman jmh649@gmail.com *Sent:* Tuesday, April 16, 2024 11:14 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
We have Interactive graphs from OWID working on Basque Wikipedia, following a consent popup.
https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
Still need to figure out a way to make them multilingual.
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Note that a third-party web service is not ideal; in addition to the issues of tracking and privacy, it can't work offline and likely would require additional work to get the graphics working on mobile web, mobile apps, and offline (kiwix etc). Integrating fully with a self-contained service that is supported by our whole ecosystem and maintained in the future would be desirable in the work I'd like to make sure we do on multimedia.
-- brooke
On Wed, Apr 17, 2024 at 12:59 PM James Heilman jmh649@gmail.com wrote:
A bit more background on Our World in Data.
They currently have about 4,500 data visualization https://ourworldindata.org/charts
They come in two main formats:
- Grapher: These are simpler and their older work
https://ourworldindata.org/grapher/deaths-from-substance-disorders 2) Explorers: These are newer with more ways to adjust data https://ourworldindata.org/explorers/natural-resources
Both of these work via the consent pop up workflow.
We last coordinated the mass upload of still images from OWID to Commons in 2020. https://commons.wikimedia.org/wiki/Category:Our_World_in_Data And are beginning to look at doing an update. One thought as part of this update would be to include within the commons page the mediawiki markup needed to have the consent pop up work in target languages that have it activated.
James
On Wed, Apr 17, 2024 at 1:29 PM Brooke Vibber bvibber@wikimedia.org wrote:
This is exciting -- let's make sure we capture any usage requirements for the upcoming Graphs modernization work so we can have these features built in again soon!
-- brooke
On Wed, Apr 17, 2024 at 7:43 AM Felipe Schenone schenonef@gmail.com wrote:
Amazing work, James and Galder!
Today I was bold, made it fully multilingual and generalized it so that it can be easily installed in any wiki (Wikimedia or not). See https://www.mediawiki.org/wiki/Template:OWID for the documentation and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code and https://www.mediawiki.org/wiki/Template_gadgets for more context
Galder, perhaps you'd like to update the usage at the Basque Wikipedia (see https://www.mediawiki.org/wiki/Template:OWID) so as to help centralize and coordinate our efforts? Some technical notes:
- I simplified the code considerably using the pre-built methods
OO.ui.alert and OO.ui.confirm rather than those complicated (and unnecessary, in this case) OOUI classes. I hope you like it.
- I wrapped the code with an "OWID" object to keep it out of the global
space and make sure the 'oojs-ui-windows' dependency is always loaded.
- The localized messages should probably be moved to their own JSON file
and loaded from there, but I'm not sure about the best way to do that while keep it template gadgets centralized at MediaWiki.org, and possibly having the strings translated by translatewiki.net. Perhaps we can set up a call to discuss some options?
PS, I enabled the template on the Spanish Wikipedia (see https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some local trouble with template gadgets so it's not working right now. I should be able to fix it in the next few hours.
On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks, James, for all the work done, We now have 14 articles with interactive graphs, as we are exploring this new feature: https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten.... The deployment is pretty easy, it took around 10 minutes with only four things: a template, a css, a js and a gadget definition. This is so simple, that I think it should be implemented by everyone.
We should think on how we make it multilingual.
Thanks again to all the members of WikiProject Med for the step forward.
Galder
*From:* James Heilman jmh649@gmail.com *Sent:* Tuesday, April 16, 2024 11:14 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
We have Interactive graphs from OWID working on Basque Wikipedia, following a consent popup.
https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
Still need to figure out a way to make them multilingual.
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Was involved in 2019 with loading the datasets that form these graphs https://commons.wikimedia.org/wiki/Data:CO2PerCapita.tab onto Commons. And then we were using these data sets within our currently dead graph tool https://en.wikipedia.org/wiki/User:Doc_James/OurWorld. While we got it to work, sort of, it was never nearly as nice as what OWID does. For example our tool could not "zoom in" to Europe.
With respect to offline use, the still images are offline functional within ZIMs for Kiwix, but yes the interactive graphs are not functional in these ZIMs/offline.
The graphs actually work beautifully on mobile web. Not sure about the Wikipedia app.
All of OWIDs source code is open source and we could definitely look at pulling it into our ecosystem. We already made a copy of it with a number of modifications at https://owidm.wmcloud.org/ Another major benefit to bringing it in house is that we would have greater control over making it multilingual (that was one of the reasons we looked at the mirror).
Another strategy could be to look at a partnership with OWID for these specific 4,500 graphics. We could help them become more multilingual, with an agreement around our reuse / mirroring their site on production servers. Plus we could feedback other datasets to be graphed for either of our use.
James
On Wed, Apr 17, 2024 at 2:22 PM Brooke Vibber bvibber@wikimedia.org wrote:
Note that a third-party web service is not ideal; in addition to the issues of tracking and privacy, it can't work offline and likely would require additional work to get the graphics working on mobile web, mobile apps, and offline (kiwix etc). Integrating fully with a self-contained service that is supported by our whole ecosystem and maintained in the future would be desirable in the work I'd like to make sure we do on multimedia.
-- brooke
On Wed, Apr 17, 2024 at 12:59 PM James Heilman jmh649@gmail.com wrote:
A bit more background on Our World in Data.
They currently have about 4,500 data visualization https://ourworldindata.org/charts
They come in two main formats:
- Grapher: These are simpler and their older work
https://ourworldindata.org/grapher/deaths-from-substance-disorders 2) Explorers: These are newer with more ways to adjust data https://ourworldindata.org/explorers/natural-resources
Both of these work via the consent pop up workflow.
We last coordinated the mass upload of still images from OWID to Commons in 2020. https://commons.wikimedia.org/wiki/Category:Our_World_in_Data And are beginning to look at doing an update. One thought as part of this update would be to include within the commons page the mediawiki markup needed to have the consent pop up work in target languages that have it activated.
James
On Wed, Apr 17, 2024 at 1:29 PM Brooke Vibber bvibber@wikimedia.org wrote:
This is exciting -- let's make sure we capture any usage requirements for the upcoming Graphs modernization work so we can have these features built in again soon!
-- brooke
On Wed, Apr 17, 2024 at 7:43 AM Felipe Schenone schenonef@gmail.com wrote:
Amazing work, James and Galder!
Today I was bold, made it fully multilingual and generalized it so that it can be easily installed in any wiki (Wikimedia or not). See https://www.mediawiki.org/wiki/Template:OWID for the documentation and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code and https://www.mediawiki.org/wiki/Template_gadgets for more context
Galder, perhaps you'd like to update the usage at the Basque Wikipedia (see https://www.mediawiki.org/wiki/Template:OWID) so as to help centralize and coordinate our efforts? Some technical notes:
- I simplified the code considerably using the pre-built methods
OO.ui.alert and OO.ui.confirm rather than those complicated (and unnecessary, in this case) OOUI classes. I hope you like it.
- I wrapped the code with an "OWID" object to keep it out of the global
space and make sure the 'oojs-ui-windows' dependency is always loaded.
- The localized messages should probably be moved to their own JSON
file and loaded from there, but I'm not sure about the best way to do that while keep it template gadgets centralized at MediaWiki.org, and possibly having the strings translated by translatewiki.net. Perhaps we can set up a call to discuss some options?
PS, I enabled the template on the Spanish Wikipedia (see https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some local trouble with template gadgets so it's not working right now. I should be able to fix it in the next few hours.
On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks, James, for all the work done, We now have 14 articles with interactive graphs, as we are exploring this new feature: https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten.... The deployment is pretty easy, it took around 10 minutes with only four things: a template, a css, a js and a gadget definition. This is so simple, that I think it should be implemented by everyone.
We should think on how we make it multilingual.
Thanks again to all the members of WikiProject Med for the step forward.
Galder
*From:* James Heilman jmh649@gmail.com *Sent:* Tuesday, April 16, 2024 11:14 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
We have Interactive graphs from OWID working on Basque Wikipedia, following a consent popup.
https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
Still need to figure out a way to make them multilingual.
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
As per the last input by James Heilman regarding multilingualism:
Whatever translations we could implement in the interactive graphs that may imply some kind of a “mirroring back” to OWID, is a win-win for both projects and for the sake of free knowledge. Considering the relevance of OWID in academic environments, it would be great that our efforts in adapting them on-wiki for our articles can revert to a better language accessibility there as well.
Salutacions/Kind regards,
Xavier Dengra
As per the latest input by James El dc, 17 abr., 2024 a 22:41, James Heilman <[jmh649@gmail.com](mailto:El dc, 17 abr., 2024 a 22:41, James Heilman <<a href=)> va escriure:
Was involved in 2019 with loading the [datasets that form these graphs](https://commons.wikimedia.org/wiki/Data:CO2PerCapita.tab) onto Commons. And then we were using these data sets within our [currently dead graph tool](https://en.wikipedia.org/wiki/User:Doc_James/OurWorld). While we got it to work, sort of, it was never nearly as nice as what OWID does. For example our tool could not "zoom in" to Europe.
With respect to offline use, the still images are offline functional within ZIMs for Kiwix, but yes the interactive graphs are not functional in these ZIMs/offline.
The graphs actually work beautifully on mobile web. Not sure about the Wikipedia app.
All of OWIDs source code is open source and we could definitely look at pulling it into our ecosystem. We already made a copy of it with a number of modifications at https://owidm.wmcloud.org/ Another major benefit to bringing it in house is that we would have greater control over making it multilingual (that was one of the reasons we looked at the mirror).
Another strategy could be to look at a partnership with OWID for these specific 4,500 graphics. We could help them become more multilingual, with an agreement around our reuse / mirroring their site on production servers. Plus we could feedback other datasets to be graphed for either of our use.
James
On Wed, Apr 17, 2024 at 2:22 PM Brooke Vibber <bvibber@wikimedia.org> wrote:
Note that a third-party web service is not ideal; in addition to the issues of tracking and privacy, it can't work offline and likely would require additional work to get the graphics working on mobile web, mobile apps, and offline (kiwix etc). Integrating fully with a self-contained service that is supported by our whole ecosystem and maintained in the future would be desirable in the work I'd like to make sure we do on multimedia.
-- brooke
On Wed, Apr 17, 2024 at 12:59 PM James Heilman <jmh649@gmail.com> wrote:
A bit more background on Our World in Data.
They currently have about 4,500 data visualization https://ourworldindata.org/charts
They come in two main formats:
- Grapher: These are simpler and their older work https://ourworldindata.org/grapher/deaths-from-substance-disorders
- Explorers: These are newer with more ways to adjust data https://ourworldindata.org/explorers/natural-resources
Both of these work via the consent pop up workflow.
We last coordinated the mass upload of still images from OWID to Commons in 2020. https://commons.wikimedia.org/wiki/Category:Our_World_in_Data And are beginning to look at doing an update. One thought as part of this update would be to include within the commons page the mediawiki markup needed to have the consent pop up work in target languages that have it activated.
James
On Wed, Apr 17, 2024 at 1:29 PM Brooke Vibber <bvibber@wikimedia.org> wrote:
This is exciting -- let's make sure we capture any usage requirements for the upcoming Graphs modernization work so we can have these features built in again soon!
-- brooke
On Wed, Apr 17, 2024 at 7:43 AM Felipe Schenone <schenonef@gmail.com> wrote:
Amazing work, James and Galder!
Today I was bold, made it fully multilingual and generalized it so that it can be easily installed in any wiki (Wikimedia or not). See https://www.mediawiki.org/wiki/Template:OWID for the documentation and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code and https://www.mediawiki.org/wiki/Template_gadgets for more context
Galder, perhaps you'd like to update the usage at the Basque Wikipedia (see https://www.mediawiki.org/wiki/Template:OWID) so as to help centralize and coordinate our efforts? Some technical notes:
- I simplified the code considerably using the pre-built methods OO.ui.alert and OO.ui.confirm rather than those complicated (and unnecessary, in this case) OOUI classes. I hope you like it.
- I wrapped the code with an "OWID" object to keep it out of the global space and make sure the 'oojs-ui-windows' dependency is always loaded.
- The localized messages should probably be moved to their own JSON file and loaded from there, but I'm not sure about the best way to do that while keep it template gadgets centralized at MediaWiki.org, and possibly having the strings translated by translatewiki.net. Perhaps we can set up a call to discuss some options?
PS, I enabled the template on the Spanish Wikipedia (see https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some local trouble with template gadgets so it's not working right now. I should be able to fix it in the next few hours.
On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga <galder158@hotmail.com> wrote:
Thanks, James, for all the work done, We now have 14 articles with interactive graphs, as we are exploring this new feature:https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten_artikuluak. The deployment is pretty easy, it took around 10 minutes with only four things: a template, a css, a js and a gadget definition. This is so simple, that I think it should be implemented by everyone.
We should think on how we make it multilingual.
Thanks again to all the members of WikiProject Med for the step forward.
Galder
From: James Heilman <jmh649@gmail.com> Sent: Tuesday, April 16, 2024 11:14 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
We have Interactive graphs from OWID working on Basque Wikipedia, following a consent popup.
https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
Still need to figure out a way to make them multilingual.
--
James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/MFERHIM5S5BNJCM52YYB2Q6T7FO3ZLAL/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/RKXWQ2QVN6XMFBKHFYDXUWO4SXRL64LK/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/4CXDQL5XXNEJ4NDC42BROSM6LUWH7QFI/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
--
James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/WB3IV5GBHNK2LKUQJXQS4HAQDQ3QIHAC/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/A4CFX6DAU7VLO7SG3IL7A3IO6IXRHWI6/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
--
James Heilman MD, CCFP-EM, Wikipedian
Agreed. This work is absolutely fantastic, and OWID itself is a wonder of the data-viz world, run by a small team, advancing what it means to effectively convey the sum of current knowledge on a topic. We should actively support them however possible.
On Wed, Apr 17, 2024 at 2:38 PM F. Xavier Dengra i Grau via Wikimedia-l < wikimedia-l@lists.wikimedia.org> wrote:
As per the last input by James Heilman regarding multilingualism:
Whatever translations we could implement in the interactive graphs that may imply some kind of a “mirroring back” to OWID, is a win-win for both projects and for the sake of free knowledge. Considering the relevance of OWID in academic environments, it would be great that our efforts in adapting them on-wiki for our articles can revert to a better language accessibility there as well.
Salutacions/Kind regards,
Xavier Dengra
As per the latest input by James El dc, 17 abr., 2024 a 22:41, James Heilman <jmh649@gmail.com <El+dc,+17+abr.,+2024+a+22:41,+James+Heilman+%3C%3Ca+href=>> va escriure:
Was involved in 2019 with loading the datasets that form these graphs https://commons.wikimedia.org/wiki/Data:CO2PerCapita.tab onto Commons. And then we were using these data sets within our currently dead graph tool https://en.wikipedia.org/wiki/User:Doc_James/OurWorld. While we got it to work, sort of, it was never nearly as nice as what OWID does. For example our tool could not "zoom in" to Europe.
With respect to offline use, the still images are offline functional within ZIMs for Kiwix, but yes the interactive graphs are not functional in these ZIMs/offline.
The graphs actually work beautifully on mobile web. Not sure about the Wikipedia app.
All of OWIDs source code is open source and we could definitely look at pulling it into our ecosystem. We already made a copy of it with a number of modifications at https://owidm.wmcloud.org/ Another major benefit to bringing it in house is that we would have greater control over making it multilingual (that was one of the reasons we looked at the mirror).
Another strategy could be to look at a partnership with OWID for these specific 4,500 graphics. We could help them become more multilingual, with an agreement around our reuse / mirroring their site on production servers. Plus we could feedback other datasets to be graphed for either of our use.
James
On Wed, Apr 17, 2024 at 2:22 PM Brooke Vibber bvibber@wikimedia.org wrote:
Note that a third-party web service is not ideal; in addition to the issues of tracking and privacy, it can't work offline and likely would require additional work to get the graphics working on mobile web, mobile apps, and offline (kiwix etc). Integrating fully with a self-contained service that is supported by our whole ecosystem and maintained in the future would be desirable in the work I'd like to make sure we do on multimedia.
-- brooke
On Wed, Apr 17, 2024 at 12:59 PM James Heilman jmh649@gmail.com wrote:
A bit more background on Our World in Data.
They currently have about 4,500 data visualization https://ourworldindata.org/charts
They come in two main formats:
- Grapher: These are simpler and their older work
https://ourworldindata.org/grapher/deaths-from-substance-disorders 2) Explorers: These are newer with more ways to adjust data https://ourworldindata.org/explorers/natural-resources
Both of these work via the consent pop up workflow.
We last coordinated the mass upload of still images from OWID to Commons in 2020. https://commons.wikimedia.org/wiki/Category:Our_World_in_Data And are beginning to look at doing an update. One thought as part of this update would be to include within the commons page the mediawiki markup needed to have the consent pop up work in target languages that have it activated.
James
On Wed, Apr 17, 2024 at 1:29 PM Brooke Vibber bvibber@wikimedia.org wrote:
This is exciting -- let's make sure we capture any usage requirements for the upcoming Graphs modernization work so we can have these features built in again soon!
-- brooke
On Wed, Apr 17, 2024 at 7:43 AM Felipe Schenone schenonef@gmail.com wrote:
Amazing work, James and Galder!
Today I was bold, made it fully multilingual and generalized it so that it can be easily installed in any wiki (Wikimedia or not). See https://www.mediawiki.org/wiki/Template:OWID for the documentation and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code and https://www.mediawiki.org/wiki/Template_gadgets for more context
Galder, perhaps you'd like to update the usage at the Basque Wikipedia (see https://www.mediawiki.org/wiki/Template:OWID) so as to help centralize and coordinate our efforts? Some technical notes:
- I simplified the code considerably using the pre-built methods
OO.ui.alert and OO.ui.confirm rather than those complicated (and unnecessary, in this case) OOUI classes. I hope you like it.
- I wrapped the code with an "OWID" object to keep it out of the
global space and make sure the 'oojs-ui-windows' dependency is always loaded.
- The localized messages should probably be moved to their own JSON
file and loaded from there, but I'm not sure about the best way to do that while keep it template gadgets centralized at MediaWiki.org, and possibly having the strings translated by translatewiki.net. Perhaps we can set up a call to discuss some options?
PS, I enabled the template on the Spanish Wikipedia (see https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some local trouble with template gadgets so it's not working right now. I should be able to fix it in the next few hours.
On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks, James, for all the work done, We now have 14 articles with interactive graphs, as we are exploring this new feature: https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten.... The deployment is pretty easy, it took around 10 minutes with only four things: a template, a css, a js and a gadget definition. This is so simple, that I think it should be implemented by everyone.
We should think on how we make it multilingual.
Thanks again to all the members of WikiProject Med for the step forward.
Galder
*From:* James Heilman jmh649@gmail.com *Sent:* Tuesday, April 16, 2024 11:14 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong We have Interactive graphs from OWID working on Basque Wikipedia, following a consent popup.
https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
Still need to figure out a way to make them multilingual.
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
On Tue, 16 Apr 2024 at 22:14, James Heilman jmh649@gmail.com wrote:
We have Interactive graphs from OWID working
What are the accessibility implications of presenting data in this manner? How is the data available to people with a visual impairment, for instance?
Has anyone done an audit, to check compliance with WCAG [1]? Or performance in screen-readers [2]?
[1] https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
[2] https://en.wikipedia.org/wiki/Screen_reader
Hey Andy
We have added alt text
https://www.mediawiki.org/wiki/Template:OWID
Not sure how well the OWID website works with screen-readers. Would be interested in hearing feedback regarding this. James
On Thu, Apr 18, 2024 at 5:51 AM Andy Mabbett andy@pigsonthewing.org.uk wrote:
On Tue, 16 Apr 2024 at 22:14, James Heilman jmh649@gmail.com wrote:
We have Interactive graphs from OWID working
What are the accessibility implications of presenting data in this manner? How is the data available to people with a visual impairment, for instance?
Has anyone done an audit, to check compliance with WCAG [1]? Or performance in screen-readers [2]?
[1] https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
[2] https://en.wikipedia.org/wiki/Screen_reader
-- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
Hey Andy
How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. We have millions of references that include urls without warnings or consent before loading.
James
On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Hello Andy, There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.
Best
Galder
2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du ( acooper@wikimedia.org):
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
[1] https://meta.wikimedia.org/wiki/OWID_Gadget _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
(Not Andy, but a global interface admin in my volunteer capacity) Hi, The difference is that here the third party code is being run under the context of Wikipedia. That means even with sandboxing mitigation such as iframe (which has been broken before), it's much easier to break out and collect user credentials such as session information or run any arbitrary action on behalf of the users. While, opening a link explicitly is protected by browsers to make sure they won't be able to access cookies in wikimedia or run arbitrary code on behalf of the user targetting wikimedia projects. That's not impossible to break but it's much much harder (and zero day bugs of this type are in range of millions of dollars). That's why it's recommended to avoid opening unknown links or if you really have to, open them in services such as "Joe's sandbox". What I'm saying is that it's making it easier and cheaper to attack users.
The second aspect is trust. Users understand links go to external website we don't control but a dialog is not enough to convey wikimedia's lack of control. People might assume the code or security has been vetted by wikimedia which is not the case. It's worth noting that the click through rate for SSL/TLS security warnings for Chrome was 70% ( https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_...). Even in many cases where it was a legitimate "man in the middle attack". It got better since 2013 but it's still quite high.
Another aspect is that, it basically this turns OWID into a target for what's called "watering hole attacks" ( https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to what happened to MeDoc, a tax helper app where it got compromised to launch NotPetya, one of the most devastating cyber attack ever recorded ( https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed... ).
It also brings to question of users data being transferred. As far as I know (I might be very wrong), we instruct browsers not to provide referer information to target websites (via noreferrer attribute) so they can't see any information that the user has clicked on Wikipedia while that's no longer the case here and no way to prevent that from happening (I might be wrong again. Writing this on phone).
Last but not least, I'm seriously worried about the impact of this change on wikis where editors are in countries that don't have a good track record of respecting human rights. Breaking iframe or compromising OWID is not something a basic hacker can do but it's not hard to do for an APT or a government with deep pockets. That's why I urge you (as a fellow volunteer) to remove this.
Hope that helps, Obviously my own ideas and limited knowledge. Not on behalf of WMF or the security team.
Best
James Heilman jmh649@gmail.com schrieb am Fr., 26. Apr. 2024, 22:16:
Hey Andy
How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. We have millions of references that include urls without warnings or consent before loading.
James
On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Hello Andy, There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.
Best
Galder
2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du ( acooper@wikimedia.org):
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
[1] https://meta.wikimedia.org/wiki/OWID_Gadget _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
The other option would be to have a copy of the OWID software on our own servers (it is all openly licensed). We tried this sort of with the OWID mirror which you can see here on the wmcloud
And functional within a mediawiki install here
https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
From what I understand moving in this direction would require the software running on production servers with WMF staff support and maintance.
We have already uploaded all the data that makes these graphs to Commons by the way.
James
On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani ladsgroup@gmail.com wrote:
(Not Andy, but a global interface admin in my volunteer capacity) Hi, The difference is that here the third party code is being run under the context of Wikipedia. That means even with sandboxing mitigation such as iframe (which has been broken before), it's much easier to break out and collect user credentials such as session information or run any arbitrary action on behalf of the users. While, opening a link explicitly is protected by browsers to make sure they won't be able to access cookies in wikimedia or run arbitrary code on behalf of the user targetting wikimedia projects. That's not impossible to break but it's much much harder (and zero day bugs of this type are in range of millions of dollars). That's why it's recommended to avoid opening unknown links or if you really have to, open them in services such as "Joe's sandbox". What I'm saying is that it's making it easier and cheaper to attack users.
The second aspect is trust. Users understand links go to external website we don't control but a dialog is not enough to convey wikimedia's lack of control. People might assume the code or security has been vetted by wikimedia which is not the case. It's worth noting that the click through rate for SSL/TLS security warnings for Chrome was 70% ( https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_...). Even in many cases where it was a legitimate "man in the middle attack". It got better since 2013 but it's still quite high.
Another aspect is that, it basically this turns OWID into a target for what's called "watering hole attacks" ( https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to what happened to MeDoc, a tax helper app where it got compromised to launch NotPetya, one of the most devastating cyber attack ever recorded ( https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed... ).
It also brings to question of users data being transferred. As far as I know (I might be very wrong), we instruct browsers not to provide referer information to target websites (via noreferrer attribute) so they can't see any information that the user has clicked on Wikipedia while that's no longer the case here and no way to prevent that from happening (I might be wrong again. Writing this on phone).
Last but not least, I'm seriously worried about the impact of this change on wikis where editors are in countries that don't have a good track record of respecting human rights. Breaking iframe or compromising OWID is not something a basic hacker can do but it's not hard to do for an APT or a government with deep pockets. That's why I urge you (as a fellow volunteer) to remove this.
Hope that helps, Obviously my own ideas and limited knowledge. Not on behalf of WMF or the security team.
Best
James Heilman jmh649@gmail.com schrieb am Fr., 26. Apr. 2024, 22:16:
Hey Andy
How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. We have millions of references that include urls without warnings or consent before loading.
James
On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Hello Andy, There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.
Best
Galder
2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du ( acooper@wikimedia.org):
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
[1] https://meta.wikimedia.org/wiki/OWID_Gadget _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Very well, I just deactivated the gadget from the Spanish Wikipedia and removed the now broken template from the two articles that used it, until some decision is made about it. I shared my views at https://meta.wikimedia.org/wiki/Talk:OWID_Gadget#Three_ideas, in case anyone's interested. Kind regards,
On Sat, Apr 27, 2024 at 2:50 PM James Heilman jmh649@gmail.com wrote:
The other option would be to have a copy of the OWID software on our own servers (it is all openly licensed). We tried this sort of with the OWID mirror which you can see here on the wmcloud
And functional within a mediawiki install here
https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
From what I understand moving in this direction would require the software running on production servers with WMF staff support and maintance.
We have already uploaded all the data that makes these graphs to Commons by the way.
James
On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani ladsgroup@gmail.com wrote:
(Not Andy, but a global interface admin in my volunteer capacity) Hi, The difference is that here the third party code is being run under the context of Wikipedia. That means even with sandboxing mitigation such as iframe (which has been broken before), it's much easier to break out and collect user credentials such as session information or run any arbitrary action on behalf of the users. While, opening a link explicitly is protected by browsers to make sure they won't be able to access cookies in wikimedia or run arbitrary code on behalf of the user targetting wikimedia projects. That's not impossible to break but it's much much harder (and zero day bugs of this type are in range of millions of dollars). That's why it's recommended to avoid opening unknown links or if you really have to, open them in services such as "Joe's sandbox". What I'm saying is that it's making it easier and cheaper to attack users.
The second aspect is trust. Users understand links go to external website we don't control but a dialog is not enough to convey wikimedia's lack of control. People might assume the code or security has been vetted by wikimedia which is not the case. It's worth noting that the click through rate for SSL/TLS security warnings for Chrome was 70% ( https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_...). Even in many cases where it was a legitimate "man in the middle attack". It got better since 2013 but it's still quite high.
Another aspect is that, it basically this turns OWID into a target for what's called "watering hole attacks" ( https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to what happened to MeDoc, a tax helper app where it got compromised to launch NotPetya, one of the most devastating cyber attack ever recorded ( https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed... ).
It also brings to question of users data being transferred. As far as I know (I might be very wrong), we instruct browsers not to provide referer information to target websites (via noreferrer attribute) so they can't see any information that the user has clicked on Wikipedia while that's no longer the case here and no way to prevent that from happening (I might be wrong again. Writing this on phone).
Last but not least, I'm seriously worried about the impact of this change on wikis where editors are in countries that don't have a good track record of respecting human rights. Breaking iframe or compromising OWID is not something a basic hacker can do but it's not hard to do for an APT or a government with deep pockets. That's why I urge you (as a fellow volunteer) to remove this.
Hope that helps, Obviously my own ideas and limited knowledge. Not on behalf of WMF or the security team.
Best
James Heilman jmh649@gmail.com schrieb am Fr., 26. Apr. 2024, 22:16:
Hey Andy
How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. We have millions of references that include urls without warnings or consent before loading.
James
On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Hello Andy, There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.
Best
Galder
2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du ( acooper@wikimedia.org):
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
[1] https://meta.wikimedia.org/wiki/OWID_Gadget _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Thoughtful mirroring would address some of Amir's concerns. (Amir: which ones remain?)
Could you use the gadget with a mirror?
On Sat, Apr 27, 2024 at 1:50 PM James Heilman jmh649@gmail.com wrote:
The other option would be to have a copy of the OWID software on our own servers (it is all openly licensed). We tried this sort of with the OWID mirror which you can see here on the wmcloud
And functional within a mediawiki install here
https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
From what I understand moving in this direction would require the software running on production servers with WMF staff support and maintance.
We have already uploaded all the data that makes these graphs to Commons by the way.
James
On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani ladsgroup@gmail.com wrote:
(Not Andy, but a global interface admin in my volunteer capacity) Hi, The difference is that here the third party code is being run under the context of Wikipedia. That means even with sandboxing mitigation such as iframe (which has been broken before), it's much easier to break out and collect user credentials such as session information or run any arbitrary action on behalf of the users. While, opening a link explicitly is protected by browsers to make sure they won't be able to access cookies in wikimedia or run arbitrary code on behalf of the user targetting wikimedia projects. That's not impossible to break but it's much much harder (and zero day bugs of this type are in range of millions of dollars). That's why it's recommended to avoid opening unknown links or if you really have to, open them in services such as "Joe's sandbox". What I'm saying is that it's making it easier and cheaper to attack users.
The second aspect is trust. Users understand links go to external website we don't control but a dialog is not enough to convey wikimedia's lack of control. People might assume the code or security has been vetted by wikimedia which is not the case. It's worth noting that the click through rate for SSL/TLS security warnings for Chrome was 70% ( https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_...). Even in many cases where it was a legitimate "man in the middle attack". It got better since 2013 but it's still quite high.
Another aspect is that, it basically this turns OWID into a target for what's called "watering hole attacks" ( https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to what happened to MeDoc, a tax helper app where it got compromised to launch NotPetya, one of the most devastating cyber attack ever recorded ( https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed... ).
It also brings to question of users data being transferred. As far as I know (I might be very wrong), we instruct browsers not to provide referer information to target websites (via noreferrer attribute) so they can't see any information that the user has clicked on Wikipedia while that's no longer the case here and no way to prevent that from happening (I might be wrong again. Writing this on phone).
Last but not least, I'm seriously worried about the impact of this change on wikis where editors are in countries that don't have a good track record of respecting human rights. Breaking iframe or compromising OWID is not something a basic hacker can do but it's not hard to do for an APT or a government with deep pockets. That's why I urge you (as a fellow volunteer) to remove this.
Hope that helps, Obviously my own ideas and limited knowledge. Not on behalf of WMF or the security team.
Best
James Heilman jmh649@gmail.com schrieb am Fr., 26. Apr. 2024, 22:16:
Hey Andy
How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. We have millions of references that include urls without warnings or consent before loading.
James
On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Hello Andy, There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.
Best
Galder
2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du ( acooper@wikimedia.org):
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
[1] https://meta.wikimedia.org/wiki/OWID_Gadget _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
No, we can't. The Wikimedia Foundation also blocked the option for mirroring, that was our first approach because it reduces 3rd party involvement and we could translate the software. WMF's approach is "don't do anything".
A complete waste of time.
Galder ________________________________ From: Samuel Klein meta.sj@gmail.com Sent: Sunday, April 28, 2024 8:56 AM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Thoughtful mirroring would address some of Amir's concerns. (Amir: which ones remain?)
Could you use the gadget with a mirror?
On Sat, Apr 27, 2024 at 1:50 PM James Heilman <jmh649@gmail.commailto:jmh649@gmail.com> wrote: The other option would be to have a copy of the OWID software on our own servers (it is all openly licensed). We tried this sort of with the OWID mirror which you can see here on the wmcloud
And functional within a mediawiki install here
https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
From what I understand moving in this direction would require the software running on production servers with WMF staff support and maintance.
We have already uploaded all the data that makes these graphs to Commons by the way.
James
On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani <ladsgroup@gmail.commailto:ladsgroup@gmail.com> wrote: (Not Andy, but a global interface admin in my volunteer capacity) Hi, The difference is that here the third party code is being run under the context of Wikipedia. That means even with sandboxing mitigation such as iframe (which has been broken before), it's much easier to break out and collect user credentials such as session information or run any arbitrary action on behalf of the users. While, opening a link explicitly is protected by browsers to make sure they won't be able to access cookies in wikimedia or run arbitrary code on behalf of the user targetting wikimedia projects. That's not impossible to break but it's much much harder (and zero day bugs of this type are in range of millions of dollars). That's why it's recommended to avoid opening unknown links or if you really have to, open them in services such as "Joe's sandbox". What I'm saying is that it's making it easier and cheaper to attack users.
The second aspect is trust. Users understand links go to external website we don't control but a dialog is not enough to convey wikimedia's lack of control. People might assume the code or security has been vetted by wikimedia which is not the case. It's worth noting that the click through rate for SSL/TLS security warnings for Chrome was 70% (https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_...). Even in many cases where it was a legitimate "man in the middle attack". It got better since 2013 but it's still quite high.
Another aspect is that, it basically this turns OWID into a target for what's called "watering hole attacks" (https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to what happened to MeDoc, a tax helper app where it got compromised to launch NotPetya, one of the most devastating cyber attack ever recorded (https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed...).
It also brings to question of users data being transferred. As far as I know (I might be very wrong), we instruct browsers not to provide referer information to target websites (via noreferrer attribute) so they can't see any information that the user has clicked on Wikipedia while that's no longer the case here and no way to prevent that from happening (I might be wrong again. Writing this on phone).
Last but not least, I'm seriously worried about the impact of this change on wikis where editors are in countries that don't have a good track record of respecting human rights. Breaking iframe or compromising OWID is not something a basic hacker can do but it's not hard to do for an APT or a government with deep pockets. That's why I urge you (as a fellow volunteer) to remove this.
Hope that helps, Obviously my own ideas and limited knowledge. Not on behalf of WMF or the security team.
Best
James Heilman <jmh649@gmail.commailto:jmh649@gmail.com> schrieb am Fr., 26. Apr. 2024, 22:16: Hey Andy
How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. We have millions of references that include urls without warnings or consent before loading.
James
On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> wrote: Hello Andy, There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.
Best
Galder
2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du (acooper@wikimedia.orgmailto:acooper@wikimedia.org):
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
[1] https://meta.wikimedia.org/wiki/OWID_Gadget _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.orgmailto:wikimedia-l-leave@lists.wikimedia.org
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- Samuel Klein @metasj w:user:sj +1 617 529 4266
Hi y'all,
Maybe a naive question but why don't we store the data in Wikidata and/or on Commons (in the data namespace) ?
Cheers, Nicolas
Le dim. 28 avr. 2024 à 09:18, Galder Gonzalez Larrañaga < galder158@hotmail.com> a écrit :
No, we can't. The Wikimedia Foundation also blocked the option for mirroring, that was our first approach because it reduces 3rd party involvement and we could translate the software. WMF's approach is "don't do anything".
A complete waste of time.
Galder
*From:* Samuel Klein meta.sj@gmail.com *Sent:* Sunday, April 28, 2024 8:56 AM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Thoughtful mirroring would address some of Amir's concerns. (Amir: which ones remain?)
Could you use the gadget with a mirror?
On Sat, Apr 27, 2024 at 1:50 PM James Heilman jmh649@gmail.com wrote:
The other option would be to have a copy of the OWID software on our own servers (it is all openly licensed). We tried this sort of with the OWID mirror which you can see here on the wmcloud
And functional within a mediawiki install here
https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
From what I understand moving in this direction would require the software running on production servers with WMF staff support and maintance.
We have already uploaded all the data that makes these graphs to Commons by the way.
James
On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani ladsgroup@gmail.com wrote:
(Not Andy, but a global interface admin in my volunteer capacity) Hi, The difference is that here the third party code is being run under the context of Wikipedia. That means even with sandboxing mitigation such as iframe (which has been broken before), it's much easier to break out and collect user credentials such as session information or run any arbitrary action on behalf of the users. While, opening a link explicitly is protected by browsers to make sure they won't be able to access cookies in wikimedia or run arbitrary code on behalf of the user targetting wikimedia projects. That's not impossible to break but it's much much harder (and zero day bugs of this type are in range of millions of dollars). That's why it's recommended to avoid opening unknown links or if you really have to, open them in services such as "Joe's sandbox". What I'm saying is that it's making it easier and cheaper to attack users.
The second aspect is trust. Users understand links go to external website we don't control but a dialog is not enough to convey wikimedia's lack of control. People might assume the code or security has been vetted by wikimedia which is not the case. It's worth noting that the click through rate for SSL/TLS security warnings for Chrome was 70% ( https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_...). Even in many cases where it was a legitimate "man in the middle attack". It got better since 2013 but it's still quite high.
Another aspect is that, it basically this turns OWID into a target for what's called "watering hole attacks" ( https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to what happened to MeDoc, a tax helper app where it got compromised to launch NotPetya, one of the most devastating cyber attack ever recorded ( https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed... ).
It also brings to question of users data being transferred. As far as I know (I might be very wrong), we instruct browsers not to provide referer information to target websites (via noreferrer attribute) so they can't see any information that the user has clicked on Wikipedia while that's no longer the case here and no way to prevent that from happening (I might be wrong again. Writing this on phone).
Last but not least, I'm seriously worried about the impact of this change on wikis where editors are in countries that don't have a good track record of respecting human rights. Breaking iframe or compromising OWID is not something a basic hacker can do but it's not hard to do for an APT or a government with deep pockets. That's why I urge you (as a fellow volunteer) to remove this.
Hope that helps, Obviously my own ideas and limited knowledge. Not on behalf of WMF or the security team.
Best
James Heilman jmh649@gmail.com schrieb am Fr., 26. Apr. 2024, 22:16:
Hey Andy
How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. We have millions of references that include urls without warnings or consent before loading.
James
On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Hello Andy, There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.
Best
Galder
2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du ( acooper@wikimedia.org):
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
[1] https://meta.wikimedia.org/wiki/OWID_Gadget _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- Samuel Klein @metasj w:user:sj +1 617 529 4266 _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
My main concern is that we’re risking third parties controlling the movement. I don’t mean to make a slippery slope argument, but it is kind of easy to head off at the pass before things get worse.
- Charles
On Sunday, April 28, 2024, Nicolas VIGNERON vigneron.nicolas@gmail.com wrote:
Hi y'all,
Maybe a naive question but why don't we store the data in Wikidata and/or on Commons (in the data namespace) ?
Cheers, Nicolas
Le dim. 28 avr. 2024 à 09:18, Galder Gonzalez Larrañaga < galder158@hotmail.com> a écrit :
No, we can't. The Wikimedia Foundation also blocked the option for mirroring, that was our first approach because it reduces 3rd party involvement and we could translate the software. WMF's approach is "don't do anything".
A complete waste of time.
Galder
*From:* Samuel Klein meta.sj@gmail.com *Sent:* Sunday, April 28, 2024 8:56 AM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Thoughtful mirroring would address some of Amir's concerns. (Amir: which ones remain?)
Could you use the gadget with a mirror?
On Sat, Apr 27, 2024 at 1:50 PM James Heilman jmh649@gmail.com wrote:
The other option would be to have a copy of the OWID software on our own servers (it is all openly licensed). We tried this sort of with the OWID mirror which you can see here on the wmcloud
And functional within a mediawiki install here
https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
From what I understand moving in this direction would require the software running on production servers with WMF staff support and maintance.
We have already uploaded all the data that makes these graphs to Commons by the way.
James
On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani ladsgroup@gmail.com wrote:
(Not Andy, but a global interface admin in my volunteer capacity) Hi, The difference is that here the third party code is being run under the context of Wikipedia. That means even with sandboxing mitigation such as iframe (which has been broken before), it's much easier to break out and collect user credentials such as session information or run any arbitrary action on behalf of the users. While, opening a link explicitly is protected by browsers to make sure they won't be able to access cookies in wikimedia or run arbitrary code on behalf of the user targetting wikimedia projects. That's not impossible to break but it's much much harder (and zero day bugs of this type are in range of millions of dollars). That's why it's recommended to avoid opening unknown links or if you really have to, open them in services such as "Joe's sandbox". What I'm saying is that it's making it easier and cheaper to attack users.
The second aspect is trust. Users understand links go to external website we don't control but a dialog is not enough to convey wikimedia's lack of control. People might assume the code or security has been vetted by wikimedia which is not the case. It's worth noting that the click through rate for SSL/TLS security warnings for Chrome was 70% ( https://www.usenix.org/system/files/conference/ usenixsecurity13/sec13-paper_akhawe.pdf). Even in many cases where it was a legitimate "man in the middle attack". It got better since 2013 but it's still quite high.
Another aspect is that, it basically this turns OWID into a target for what's called "watering hole attacks" (https://en.wikipedia.org/ wiki/Watering_hole_attack). This is similar to what happened to MeDoc, a tax helper app where it got compromised to launch NotPetya, one of the most devastating cyber attack ever recorded (https://www.wired.com/story/ notpetya-cyberattack-ukraine-russia-code-crashed-the-world/).
It also brings to question of users data being transferred. As far as I know (I might be very wrong), we instruct browsers not to provide referer information to target websites (via noreferrer attribute) so they can't see any information that the user has clicked on Wikipedia while that's no longer the case here and no way to prevent that from happening (I might be wrong again. Writing this on phone).
Last but not least, I'm seriously worried about the impact of this change on wikis where editors are in countries that don't have a good track record of respecting human rights. Breaking iframe or compromising OWID is not something a basic hacker can do but it's not hard to do for an APT or a government with deep pockets. That's why I urge you (as a fellow volunteer) to remove this.
Hope that helps, Obviously my own ideas and limited knowledge. Not on behalf of WMF or the security team.
Best
James Heilman jmh649@gmail.com schrieb am Fr., 26. Apr. 2024, 22:16:
Hey Andy
How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. We have millions of references that include urls without warnings or consent before loading.
James
On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Hello Andy, There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.
Best
Galder
2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du ( acooper@wikimedia.org):
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
[1] https://meta.wikimedia.org/wiki/OWID_Gadget _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/ hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/ TW3UIL7OEDQRVOQNLJS5RVZD546TADHB/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/ hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/ TKADHNQOEYPDSJDFEKXDZEME4U55TZWA/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/ hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/ ASKWWMDFHZNR46BCJQ6Q2EIJOELML3BT/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/ hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/ U4P645U2F6GOXGVNTHYARJZZ74DELR5E/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/ hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/ HPGHRRNY62JCPQOWE3A6GJWQB6LZMQD4/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- Samuel Klein @metasj w:user:sj +1 617 529 4266 _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/ hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/ YNWGR25BMJE4FSZ4BEFZEAKNTJ7PU33V/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
[Changing the topic to be more precise: how to get OWID specifically to work]
Ah, I recall that Amir said last year that he sees this as complex, requiring a sanitized mirroring service inside WM production, which in turn requires traversing an entire 'path to production' that is underspecified. https://phabricator.wikimedia.org/T301044#8792949 https://phabricator.wikimedia.org/T301044
Getting OWID to work on WM sites seems like a cleanly-scoped and accomplishable task. Less ambiguous than the current partial plan for a Graph: replacement https://www.mediawiki.org/wiki/Extension:Graph/Plans#Update_April_2024, for instance. The question for our priority-queue is: how do we make this possible and maintainable, how do we get the many people interested working towards a common goal? This depends on basic questions about how community devs can work within current WMF frameworks, which I hope this can serve as motivation to resolve.
SJ
(Galder: Obviously we could still help translate the text of Our World in Data via a mirror, which would benefit the 100M/yr users of OWID graphs -- a natural collaboration -- but you're right that there's less motivation for our communities to translate this when they can't see the results directly on their home projects.)
On Sun, Apr 28, 2024 at 3:18 AM Galder wrote:
No, we can't.
On Sun, Apr 28, 2024 at 2:56 AM Samuel Klein meta.sj@gmail.com wrote:
Thoughtful mirroring would address some of Amir's concerns. (Amir: which ones remain?)
Could you use the gadget with a mirror?
On Sat, Apr 27, 2024 at 1:50 PM James Heilman jmh649@gmail.com wrote:
The other option would be to have a copy of the OWID software on our own servers (it is all openly licensed). We tried this sort of with the OWID mirror which you can see here on the wmcloud
And functional within a mediawiki install here
https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
From what I understand moving in this direction would require the software running on production servers with WMF staff support and maintance.
We have already uploaded all the data that makes these graphs to Commons by the way.
James
On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani ladsgroup@gmail.com wrote:
(Not Andy, but a global interface admin in my volunteer capacity) Hi, The difference is that here the third party code is being run under the context of Wikipedia. That means even with sandboxing mitigation such as iframe (which has been broken before), it's much easier to break out and collect user credentials such as session information or run any arbitrary action on behalf of the users. While, opening a link explicitly is protected by browsers to make sure they won't be able to access cookies in wikimedia or run arbitrary code on behalf of the user targetting wikimedia projects. That's not impossible to break but it's much much harder (and zero day bugs of this type are in range of millions of dollars). That's why it's recommended to avoid opening unknown links or if you really have to, open them in services such as "Joe's sandbox". What I'm saying is that it's making it easier and cheaper to attack users.
The second aspect is trust. Users understand links go to external website we don't control but a dialog is not enough to convey wikimedia's lack of control. People might assume the code or security has been vetted by wikimedia which is not the case. It's worth noting that the click through rate for SSL/TLS security warnings for Chrome was 70% ( https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_...). Even in many cases where it was a legitimate "man in the middle attack". It got better since 2013 but it's still quite high.
Another aspect is that, it basically this turns OWID into a target for what's called "watering hole attacks" ( https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to what happened to MeDoc, a tax helper app where it got compromised to launch NotPetya, one of the most devastating cyber attack ever recorded ( https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed... ).
It also brings to question of users data being transferred. As far as I know (I might be very wrong), we instruct browsers not to provide referer information to target websites (via noreferrer attribute) so they can't see any information that the user has clicked on Wikipedia while that's no longer the case here and no way to prevent that from happening (I might be wrong again. Writing this on phone).
Last but not least, I'm seriously worried about the impact of this change on wikis where editors are in countries that don't have a good track record of respecting human rights. Breaking iframe or compromising OWID is not something a basic hacker can do but it's not hard to do for an APT or a government with deep pockets. That's why I urge you (as a fellow volunteer) to remove this.
Hope that helps, Obviously my own ideas and limited knowledge. Not on behalf of WMF or the security team.
Best
James Heilman jmh649@gmail.com schrieb am Fr., 26. Apr. 2024, 22:16:
Hey Andy
How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. We have millions of references that include urls without warnings or consent before loading.
James
On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Hello Andy, There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.
Best
Galder
2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du ( acooper@wikimedia.org):
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
[1] https://meta.wikimedia.org/wiki/OWID_Gadget _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- Samuel Klein @metasj w:user:sj +1 617 529 4266
Ultimately, this seems a case of "Fix it or get out of the way".
There was already a suggestion of restoring graphs with the ability to modify them restricted to interface admins. People with IA permissions could, quite frankly, do far more harmful things to user security if they "went rogue" then messing with graphs. They're highly trusted people who we trust to not do anything like that, and who have the technical skills to edit code without introducing such issues.
Why can't that be implemented as at least an interim solution while a more permanent fix is underway?
Todd
On Sun, Apr 28, 2024 at 1:46 AM Samuel Klein meta.sj@gmail.com wrote:
[Changing the topic to be more precise: how to get OWID specifically to work]
Ah, I recall that Amir said last year that he sees this as complex, requiring a sanitized mirroring service inside WM production, which in turn requires traversing an entire 'path to production' that is underspecified. https://phabricator.wikimedia.org/T301044#8792949 https://phabricator.wikimedia.org/T301044
Getting OWID to work on WM sites seems like a cleanly-scoped and accomplishable task. Less ambiguous than the current partial plan for a Graph: replacement https://www.mediawiki.org/wiki/Extension:Graph/Plans#Update_April_2024, for instance. The question for our priority-queue is: how do we make this possible and maintainable, how do we get the many people interested working towards a common goal? This depends on basic questions about how community devs can work within current WMF frameworks, which I hope this can serve as motivation to resolve.
SJ
(Galder: Obviously we could still help translate the text of Our World in Data via a mirror, which would benefit the 100M/yr users of OWID graphs -- a natural collaboration -- but you're right that there's less motivation for our communities to translate this when they can't see the results directly on their home projects.)
On Sun, Apr 28, 2024 at 3:18 AM Galder wrote:
No, we can't.
On Sun, Apr 28, 2024 at 2:56 AM Samuel Klein meta.sj@gmail.com wrote:
Thoughtful mirroring would address some of Amir's concerns. (Amir: which ones remain?)
Could you use the gadget with a mirror?
On Sat, Apr 27, 2024 at 1:50 PM James Heilman jmh649@gmail.com wrote:
The other option would be to have a copy of the OWID software on our own servers (it is all openly licensed). We tried this sort of with the OWID mirror which you can see here on the wmcloud
And functional within a mediawiki install here
https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
From what I understand moving in this direction would require the software running on production servers with WMF staff support and maintance.
We have already uploaded all the data that makes these graphs to Commons by the way.
James
On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani ladsgroup@gmail.com wrote:
(Not Andy, but a global interface admin in my volunteer capacity) Hi, The difference is that here the third party code is being run under the context of Wikipedia. That means even with sandboxing mitigation such as iframe (which has been broken before), it's much easier to break out and collect user credentials such as session information or run any arbitrary action on behalf of the users. While, opening a link explicitly is protected by browsers to make sure they won't be able to access cookies in wikimedia or run arbitrary code on behalf of the user targetting wikimedia projects. That's not impossible to break but it's much much harder (and zero day bugs of this type are in range of millions of dollars). That's why it's recommended to avoid opening unknown links or if you really have to, open them in services such as "Joe's sandbox". What I'm saying is that it's making it easier and cheaper to attack users.
The second aspect is trust. Users understand links go to external website we don't control but a dialog is not enough to convey wikimedia's lack of control. People might assume the code or security has been vetted by wikimedia which is not the case. It's worth noting that the click through rate for SSL/TLS security warnings for Chrome was 70% ( https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_...). Even in many cases where it was a legitimate "man in the middle attack". It got better since 2013 but it's still quite high.
Another aspect is that, it basically this turns OWID into a target for what's called "watering hole attacks" ( https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to what happened to MeDoc, a tax helper app where it got compromised to launch NotPetya, one of the most devastating cyber attack ever recorded ( https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed... ).
It also brings to question of users data being transferred. As far as I know (I might be very wrong), we instruct browsers not to provide referer information to target websites (via noreferrer attribute) so they can't see any information that the user has clicked on Wikipedia while that's no longer the case here and no way to prevent that from happening (I might be wrong again. Writing this on phone).
Last but not least, I'm seriously worried about the impact of this change on wikis where editors are in countries that don't have a good track record of respecting human rights. Breaking iframe or compromising OWID is not something a basic hacker can do but it's not hard to do for an APT or a government with deep pockets. That's why I urge you (as a fellow volunteer) to remove this.
Hope that helps, Obviously my own ideas and limited knowledge. Not on behalf of WMF or the security team.
Best
James Heilman jmh649@gmail.com schrieb am Fr., 26. Apr. 2024, 22:16:
Hey Andy
How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. We have millions of references that include urls without warnings or consent before loading.
James
On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Hello Andy, There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.
Best
Galder
2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du ( acooper@wikimedia.org):
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
[1] https://meta.wikimedia.org/wiki/OWID_Gadget _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- Samuel Klein @metasj w:user:sj +1 617 529 4266
-- Samuel Klein @metasj w:user:sj +1 617 529 4266 _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Hi,
Just as a practical suggestion. The Wikimedia Hackathon is next week, and there are likely enough relevant people (volunteers, WMF tech) onsite who could answer how to proceed to get a possible path forward. The other global gadgets that use 3rd party data would also require resolution on how they could work safely. (for example, Wikimedia Commons uses global petscan-based gadgets; wiki voyage uses maps) If somebody is going there, let's organize a meeting or something (or at least create a phabricator ticket)
[1] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024 [2] https://phabricator.wikimedia.org/project/board/6865/
Br, -- Kimmo Virtanen, Zache
On Sun, Apr 28, 2024 at 10:47 AM Samuel Klein meta.sj@gmail.com wrote:
[Changing the topic to be more precise: how to get OWID specifically to work]
Ah, I recall that Amir said last year that he sees this as complex, requiring a sanitized mirroring service inside WM production, which in turn requires traversing an entire 'path to production' that is underspecified. https://phabricator.wikimedia.org/T301044#8792949 https://phabricator.wikimedia.org/T301044
Getting OWID to work on WM sites seems like a cleanly-scoped and accomplishable task. Less ambiguous than the current partial plan for a Graph: replacement https://www.mediawiki.org/wiki/Extension:Graph/Plans#Update_April_2024, for instance. The question for our priority-queue is: how do we make this possible and maintainable, how do we get the many people interested working towards a common goal? This depends on basic questions about how community devs can work within current WMF frameworks, which I hope this can serve as motivation to resolve.
SJ
(Galder: Obviously we could still help translate the text of Our World in Data via a mirror, which would benefit the 100M/yr users of OWID graphs -- a natural collaboration -- but you're right that there's less motivation for our communities to translate this when they can't see the results directly on their home projects.)
On Sun, Apr 28, 2024 at 3:18 AM Galder wrote:
No, we can't.
On Sun, Apr 28, 2024 at 2:56 AM Samuel Klein meta.sj@gmail.com wrote:
Thoughtful mirroring would address some of Amir's concerns. (Amir: which ones remain?)
Could you use the gadget with a mirror?
On Sat, Apr 27, 2024 at 1:50 PM James Heilman jmh649@gmail.com wrote:
The other option would be to have a copy of the OWID software on our own servers (it is all openly licensed). We tried this sort of with the OWID mirror which you can see here on the wmcloud
And functional within a mediawiki install here
https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
From what I understand moving in this direction would require the software running on production servers with WMF staff support and maintance.
We have already uploaded all the data that makes these graphs to Commons by the way.
James
On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani ladsgroup@gmail.com wrote:
(Not Andy, but a global interface admin in my volunteer capacity) Hi, The difference is that here the third party code is being run under the context of Wikipedia. That means even with sandboxing mitigation such as iframe (which has been broken before), it's much easier to break out and collect user credentials such as session information or run any arbitrary action on behalf of the users. While, opening a link explicitly is protected by browsers to make sure they won't be able to access cookies in wikimedia or run arbitrary code on behalf of the user targetting wikimedia projects. That's not impossible to break but it's much much harder (and zero day bugs of this type are in range of millions of dollars). That's why it's recommended to avoid opening unknown links or if you really have to, open them in services such as "Joe's sandbox". What I'm saying is that it's making it easier and cheaper to attack users.
The second aspect is trust. Users understand links go to external website we don't control but a dialog is not enough to convey wikimedia's lack of control. People might assume the code or security has been vetted by wikimedia which is not the case. It's worth noting that the click through rate for SSL/TLS security warnings for Chrome was 70% ( https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_...). Even in many cases where it was a legitimate "man in the middle attack". It got better since 2013 but it's still quite high.
Another aspect is that, it basically this turns OWID into a target for what's called "watering hole attacks" ( https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to what happened to MeDoc, a tax helper app where it got compromised to launch NotPetya, one of the most devastating cyber attack ever recorded ( https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed... ).
It also brings to question of users data being transferred. As far as I know (I might be very wrong), we instruct browsers not to provide referer information to target websites (via noreferrer attribute) so they can't see any information that the user has clicked on Wikipedia while that's no longer the case here and no way to prevent that from happening (I might be wrong again. Writing this on phone).
Last but not least, I'm seriously worried about the impact of this change on wikis where editors are in countries that don't have a good track record of respecting human rights. Breaking iframe or compromising OWID is not something a basic hacker can do but it's not hard to do for an APT or a government with deep pockets. That's why I urge you (as a fellow volunteer) to remove this.
Hope that helps, Obviously my own ideas and limited knowledge. Not on behalf of WMF or the security team.
Best
James Heilman jmh649@gmail.com schrieb am Fr., 26. Apr. 2024, 22:16:
Hey Andy
How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. We have millions of references that include urls without warnings or consent before loading.
James
On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Hello Andy, There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.
Best
Galder
2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du ( acooper@wikimedia.org):
Hello everyone,
I’m Andy Cooper, the Director of Security at the Wikimedia Foundation. Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement.
As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps.
Thanks, Andy
[1] https://meta.wikimedia.org/wiki/OWID_Gadget _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- Samuel Klein @metasj w:user:sj +1 617 529 4266
-- Samuel Klein @metasj w:user:sj +1 617 529 4266 _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
wikimedia-l@lists.wikimedia.org