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(a)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(a)gmail.com>
*Sent:* Sunday, April 28, 2024 8:56 AM
*To:* Wikimedia Mailing List <wikimedia-l(a)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(a)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
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 <ladsgroup(a)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(a)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(a)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(a)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(a)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(a)lists.wikimedia.org/message/
TW3UIL7OEDQRVOQNLJS5RVZD546TADHB/
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l(a)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(a)lists.wikimedia.org/message/
TKADHNQOEYPDSJDFEKXDZEME4U55TZWA/
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
--
James Heilman
MD, CCFP-EM, Wikipedian
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l(a)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(a)lists.wikimedia.org/message/
ASKWWMDFHZNR46BCJQ6Q2EIJOELML3BT/
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l(a)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(a)lists.wikimedia.org/message/
U4P645U2F6GOXGVNTHYARJZZ74DELR5E/
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
--
James Heilman
MD, CCFP-EM, Wikipedian
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l(a)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(a)lists.wikimedia.org/message/
HPGHRRNY62JCPQOWE3A6GJWQB6LZMQD4/
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
--
Samuel Klein @metasj w:user:sj +1 617 529 4266
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l(a)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(a)lists.wikimedia.org/message/
YNWGR25BMJE4FSZ4BEFZEAKNTJ7PU33V/
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org