[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 <[email protected]> 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 <[email protected]> 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
>>
>> https://owidm.wmcloud.org/
>>
>> 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 <[email protected]>
>> 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 <[email protected]> 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 <
>>>> [email protected]> 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 (
>>>>> [email protected]):
>>>>>
>>>>> 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 -- [email protected],
>>>>> 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/[email protected]/message/TW3UIL7OEDQRVOQNLJS5RVZD546TADHB/
>>>>> To unsubscribe send an email to [email protected]
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Wikimedia-l mailing list -- [email protected],
>>>>> 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/[email protected]/message/TKADHNQOEYPDSJDFEKXDZEME4U55TZWA/
>>>>> To unsubscribe send an email to [email protected]
>>>>
>>>>
>>>>
>>>> --
>>>> James Heilman
>>>> MD, CCFP-EM, Wikipedian
>>>> _______________________________________________
>>>> Wikimedia-l mailing list -- [email protected],
>>>> 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/[email protected]/message/ASKWWMDFHZNR46BCJQ6Q2EIJOELML3BT/
>>>> To unsubscribe send an email to [email protected]
>>>
>>> _______________________________________________
>>> Wikimedia-l mailing list -- [email protected], 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/[email protected]/message/U4P645U2F6GOXGVNTHYARJZZ74DELR5E/
>>> To unsubscribe send an email to [email protected]
>>
>>
>>
>> --
>> James Heilman
>> MD, CCFP-EM, Wikipedian
>> _______________________________________________
>> Wikimedia-l mailing list -- [email protected], 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/[email protected]/message/HPGHRRNY62JCPQOWE3A6GJWQB6LZMQD4/
>> To unsubscribe send an email to [email protected]
>
>
>
> --
> Samuel Klein          @metasj           w:user:sj          +1 617 529 4266
>


-- 
Samuel Klein          @metasj           w:user:sj          +1 617 529 4266
_______________________________________________
Wikimedia-l mailing list -- [email protected], 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/[email protected]/message/YTQG3JPZZGMZHJ7GD6WYAFEZJTYLARJ2/
To unsubscribe send an email to [email protected]

Reply via email to