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