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 <[email protected]> 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 <[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]
_______________________________________________ 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/L57N2SLV44XYKQJG5P4B3OBLTVVAN222/ To unsubscribe send an email to [email protected]
