Talk:OWID Gadget

Disappointment is not the word

The WMF breaks things. The WMF doesn't unbreak those things. Volunteers ask for features. The WMF doesn't deliver any solution. Volunteers work on solutions. The WMF blocks those solutions. Volunteers solve the issue. The WMF tries to break those again. Disappointment is not the word for that. We are dying. This is why. -Theklan (talk) 19:55, 26 April 2024 (UTC)

I don't feel like the issue has been solved. There is a major difference in sending users to a third Party and bringing a third party's tech into the movement. -- Sleyece (talk) 22:20, 26 April 2024 (UTC)

For sure, but the WMF doesn't want to bring a third party tech into the movement, while breaking all other options to make interactive graphs. They don't even have a plan for working on interactive content in the next fiscal year. Theklan (talk) 12:10, 27 April 2024 (UTC)

We can bring this tech into the movement, and that was the previous strategy. We might need to look at it again to go multilingual. Doc James (talk · contribs · email) 17:36, 27 April 2024 (UTC)

No, we can't. We have tried, but we can't. It's pretty clear that the WMF doesn't want interactivity. Is not disappointment, nor frustration. It's way more deppresing. Theklan (talk) 18:26, 27 April 2024 (UTC)

If the WMF won't allow gadgets to come in, then we have to be allowed to build them internally. There are only two outcomes. -- Sleyece (talk) 19:28, 27 April 2024 (UTC)

Yes, but both are blocked now. Theklan (talk) 19:49, 27 April 2024 (UTC)

We have now build both methods. Hopefully one will be permitted :-) There are benefits and drawbacks to each however that will need to be balanced. Hopefully demands for perfection will not stop all progress. Doc James (talk · contribs · email) 20:18, 27 April 2024 (UTC)

They have answered clearly: they won't do one, and they won't permit the other. The only thing left is platform death. Theklan (talk) 21:15, 27 April 2024 (UTC)

I can code an internal, scalable, gadget that uses cited material to generate a facsimile interactive graph of the third party data. It'll take me until Monday, and I'll link to the Test Wiki gadget in a new section of this talk page. If anyone is pleased with my work, I'm running in the U4C election, and I'd be honored to be potentially earn some votes by solving a systemic issue with my own coding skills; I'll build the gadget regardless if anyone votes for me as long as it may help the movement. -- Sleyece (talk) 23:47, 27 April 2024 (UTC)

┌─────────────────────────────────┘
Excellent. Interested to see what you can build. These were our internal-ish graphs.[1] Doc James (talk · contribs · email) 02:42, 28 April 2024 (UTC)

Change of plans; as a precaution I won't be posting a build until the question period is closed for all U4C candidates. I'm not sure I can help until May 9th -- Sleyece (talk) 02:29, 29 April 2024 (UTC)

Not first gadget to use a consent pop-up

This is not the first gadget to use a consent pop-up within our movement. This pathway was based off what has been done for years on WikiVoyage with respect to topographical overlays for maps. Doc James (talk · contribs · email) 20:12, 26 April 2024 (UTC)

Hi @Doc James. Two notes here. First, a consent pop-up is an important part of privacy compliance, but it's not the whole thing. Kartographer, and Wikivoyage maps more generally, are part of a service that the Foundation hosts and that staff monitor and maintain. It has policies and security and legal review associated with it. It's not that Wikimedia projects can never send people to third parties, it's that not all third parties are the same. Some of them may collect more data than just IPs, or pose a greater privacy and security risk to users. In that context, a consent pop-up alone doesn't do the trick: we have to review the terms of how the third party uses data and either agree to them as an organization or execute a custom contract with them to handle data more carefully if their terms aren't good enough. The consent pop-up then becomes one piece of properly informing users of how their data is being used by a third party service provider in line with the Foundation's privacy policy. If you just do the pop-up without the review, it doesn't get there as far as privacy compliance is concerned. Second, I'm actually not sure about the quality of the particular gadget here. It looks like that got into place circa 2016, which was a wildly different privacy and security landscape than 2024. Expectations were much lower in terms of hosting a website around the world. If anything, pointing to this example is a second reason why we need a policy now to make sure we're not creating privacy and security risk going forward and are handling issues like this consistently. Jrogers (WMF) (talk) 21:57, 26 April 2024 (UTC)

Then host the software. Theklan (talk) 22:01, 26 April 2024 (UTC)

Their privacy policy is here. We have the software hosted on the wmcloud[2] but from what I understand it needs to be on production servers and it needs to have a technical team within the WMF dedicated to it before it becomes usable on WP. Doc James (talk · contribs · email) 22:08, 26 April 2024 (UTC)

Hosting it would solve the graphs issue by large. But the WMF approach here is just let the projects die. Theklan (talk) 22:13, 26 April 2024 (UTC)

I certainly hope not. After mobile functionality, "multimedia and rich content" was the second highest request from our readers in a 2015 strategic consultation done by the WMF. Doc James (talk · contribs · email) 01:58, 27 April 2024 (UTC)

And still it is. It is part of our strategy, and what @MIskander-WMF and @SDeckelmann-WMF call "multi-generational pursuit". Still, even if this is strategic, there are exactly zero bytes dedicated to it in the Annual Plan. (Wikimedia_Foundation_Annual_Plan/2024-2025/Goals/Infrastructure, Wikimedia Foundation Annual Plan/2024-2025/Product & Technology OKRs, Talk page where @MMiller (WMF) says that they don't have plans for improving interactive content next year).

It would be great to have the foundation recognizing that we solved one of the problems they have forgotten for months. Instead of that, what we have is a call to stop and refrain from improving our infrastructure, our user's experience, and the re-use of free knowledge material. Theklan (talk) 08:28, 27 April 2024 (UTC)

I agree. Users explicitly consent to doing so when utilising these features (many of which I find incredibly useful), which nullifies any privacy concern. --SHB2000 (talk | contribs) 02:08, 27 April 2024 (UTC)

I don't think we would be having this conversation if all privacy concerns were nullified with a pop up. How do you know the user understands the consent popup? -- Sleyece (talk) 03:46, 27 April 2024 (UTC)

Because they are reading an Encyclopedia. Theklan (talk) 05:23, 27 April 2024 (UTC)

People routinely "consent" to absurd terms (check the fine print of Google's). There is no realistic chance for a user to make an informed decision to agree to the terms of most websites, other than just deciding to surrender their rights. I very much like WMF's stance, to defend their users, and that's a major reason for me to contribute to these projects. And, unlike ordinary users, WMF has the resources and the power to choose what terms to agree with. –LPfi (talk) 09:53, 27 April 2024 (UTC)

The WMF is not "protecting their users", is forbidding their users to get knowledge in new and interactive ways. Theklan (talk) 11:32, 27 April 2024 (UTC)

LPfi, regarding "other than just deciding to surrender their rights", there is always the option to just hit disagree and then ignoring the feature in question. --SHB2000 (talk | contribs) 07:29, 28 April 2024 (UTC)

The same way WMF is "forbidding their users to get knowledge in new and interactive ways" by not using some other useful services. We choose in what way we help our users, and we do that in a way that respects our principles, which include respecting privacy.

There is no such thing as making a well-informed decision to agree to e.g. the Google terms. The only way to agree is "whatever, do as you please". The alternative is to disagree, as you say, but that's not what we are discussing.

–LPfi (talk) 08:04, 2 May 2024 (UTC)

Jrogers: You write "we need a policy now to make sure we're not creating privacy and security risk going forward" -- of cousre, we could use a consistent policy. But please don't use this as a reason to ratchet up the iron law of increasing bureaucracy. A very salient risk is that people stop using our sites and go elsewhere because we no longer meet normal expectations of usability. This is also a wildly different web in terms of access to interactive knowledge. When we don't have OWID-level visuals, even I send people directly to OWID for an overview of a topic: which exposes them to many of the same putative risks and never introduces them to a wiki at all.

As we intend to be a pillar of support for the whole free knowledge ecosystem, our benchmark should be the security of that whole ecosystem, not 'security of people who come to our sites, even if that means having fewer people come to our sites'. In the latter case, the surest way to minimize security and legal risks is to stop having readers altogether. –SJ talk  03:52, 28 April 2024 (UTC)

We want to work with the community to strike the right balance between contributions and innovation while making sure there are checks and balances in place to ensure this happens in a way that is safe and legal. Our current request was to PAUSE on the further rollout of the OWID gadget while we could consider privacy, security, legal and performance issues. As we assess, we are taking into account the benefit this service would provide to readers and current interest among editors, which is why we are looking into whether there are options that might allow this work to continue in a safe and sustainable manner. ACooper-WMF (talk) 12:08, 3 May 2024 (UTC)

Risks

How is the risk any different than having a reference for a graph that includes a url linking to OWID? When one clicks on such a url it brings you to OWID and shares your IP address and machine details with them. We have millions of references that include urls without warnings. Doc James (talk · contribs · email) 20:12, 26 April 2024 (UTC)

Clicking an external link is at your own risk. The gadget is a potential threat to the movement because OWID is in control of tech embedded on our turf. A simple consent form is extremely inadequate risk mitigation. -- Sleyece (talk) 22:23, 26 April 2024 (UTC)

The privacy and security teams are currently conducting an in depth look into the design and code of the OWID gadget. A lot of care is taken to ensure that our users are protected and this is one reason why we have dedicated security and privacy specialists who have in depth knowledge of web technologies and vulnerabilities. Even when you click on an external link in a Wikipedia, that experience has been carefully designed to ensure you remain as protected as possible with modern browsers. In a world of third-party content advertising where there are many threats to privacy and the disclosure of information, we want to be a place that people can trust to be different and to protect your personal information and data. This is especially important to some users where the disclosure of information to third parties such as what articles they are reading and interacting with could be a safety concern. There are specific legal, privacy and security risks when content is embedded in a browser IFrame compared to an external link especially as this is new code and does not necessarily adopt the same protections that we have built in elsewhere in the platform. ACooper-WMF (talk) 10:37, 2 May 2024 (UTC)

And that's precisely why the WMF should be adding functionalities and not trying to restrict novelty. There's no solution if there are staff hours used to evaluate improvements instead of developping them. Theklan (talk) 12:10, 2 May 2024 (UTC)

may be required to disallow loading content from ourworldindata.org

The whole point of this approach is that there is no content loaded from ourworldindata.org, only a static image loaded from commons. As Doc James says there is a reference link to the original source of that image and a warning about viewing it, which is actually more risk averse than the normal practice of allowing exit without warning to the reference url, which has no sandboxing. Tim-moody (talk) 21:29, 26 April 2024 (UTC)

OWID Gadget vs Graph extension

To be clear the Graph extension relied on third party libraries and was, I would guess, at least two orders of magnitude greater in scope and complexity than the OWID Gadget, which I expect is less than 100 lines of code. This code has already had three contributors who agree to collaborate on a central source. So reviewing this code should not prove difficult, and it speaks well to the subject of maintenance. Tim-moody (talk) 21:38, 26 April 2024 (UTC)

In terms of coding complexity, the concern is less that the gadget is difficult to code and more about how it would be designed and maintained. As I shared in my update, the OWID gadget raises broader security, privacy, and legal concerns around future globally deployed gadgets. These potential risks, which we’re working to understand better, also mean that maintenance is important to plan for if and when gadget creators and users drift away. In the case of the OWID gadget specifically, we hope to have a clearer picture of the risks soon which we can share with all of you here. ACooper-WMF (talk) 12:09, 3 May 2024 (UTC)

Not a workaround

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.

I want to clarify that this is not a work around while graphs are disabled. This is a solution. Not a workaround. The so-called solution for graphs is light years behind this. If it is solved in the future (it has been broken for a year, and will take at least one more year), it will be non interactive images, and only lines. If the WMF decides to go once more against our strategic goals and close the OWID solution, the interactivity it brings won't come with the proposal mentioned on the graphs discussion. It won't even be near that. Theklan (talk) 21:59, 26 April 2024 (UTC)

I agree, this is a strategic discussion. We will achieve the sum of all human knowledge more rapidly by collaborating with like minded organizations than just going it alone. We need to balance our ideals with the reality of the world around us. Doc James (talk · contribs · email) 22:11, 26 April 2024 (UTC)

The sum of all knowledge will be pay-walled by for profit third parties if we're not careful. -- Sleyece (talk) 00:25, 28 April 2024 (UTC)

Three ideas

Hi! As one of the developers of the OWID gadget, I must admit that after sleeping over the initial setback, I'm glad to see how the security team cares for our users, since I'm also one of them, and that means the care extends to me. Thanks! <3

I have three ideas that may help handle, if not the entire issue of gadgets loading external content, at least the concerns raised for this particular OWID gadget:

• Add an Attention or Warning title to the consent popup, to make it even more conspicuous.
• Modify the code to remove the cookie that stores consent, so that users have to give consent every time they open the gadget.
• Replace the play button overlayed on the image, with a standard Codex button in the image caption, with a label like "Open chart from Our World in Data" or similar, so that users may anticipate what will happen even before they see the consent popup.

I think it would be awesome to reach a consensus about this gadget (and the broader issue) that somehow allows it, since it could really help our shared vision to bring all knowledge to all people! Sophivorus (talk) 11:21, 27 April 2024 (UTC)

Thanks for the thoughtful feedback and the understanding. We are taking this into consideration in our planning and discussions. ACooper-WMF (talk) 11:00, 2 May 2024 (UTC)

Not a security issue but still a growing concern about OWID CC licensing policy

Hello, this is not a security issue, but I want to bring something that I've realized with OWID. It's very good to see an organization releasing their graphs under a CC license compatible with Wikimedia projects, but it has come to my attention that they are normally just compiling other data from third-party sources and then re-licensing it. Example: OWID has compiled these charts on pesticide use, where they claim that the source for this is FAO stats "with major processing by OWID". However, if you go to the original source, FAO STATS, the licensing policy for their data is under a CC BY NC SA (as described here; I think the graphs are dynamic but it's just two steps of doing this same search - "total pesticide use FAO"). In certain cases (and countries), compiling data might not be protected under copyright, but some of these data might have indeed database rights. This means that if they did any "major processing" to the data provided by FAO, then they should use a CC BY NC SA, not a CC BY. To me, their copyright clearance process is less than clear and I think downstream re-users (including Wikipedia) might need to be extremely careful on how they can actually use and re-use these graphs. (On a personal note, I don't think FAO's legal departament will ever go after someone for not respecting their CC licensing statement, but that's an entirely different discussion).

This is not to say that's cool to break the hearts of people that have been working hard on bringing interactive graphs (and I think that issues raised in most of these threads bear some true), but these copyright issues keep on appearing when re-using third-party content where you don't have control of the copyright clearance process. My two cents. Scann (talk) 19:31, 27 April 2024 (UTC)

Yes so the question is did they get the FAO to drop the NC for their reuse. Or have they just used the FAOs facts to create their own separate dataset. With facts themselves not being copyrightable. Have asked... A bigger issue is the flicker upload tools we have, were paid editors upload works of others to flicker, claim to release them under an open license, and then move them to Commons. Doc James (talk · contribs · email) 20:17, 27 April 2024 (UTC)

Data cannot be copyrighted in the USA so i don't think FAO's license matters. Bawolff (talk) 08:57, 28 April 2024 (UTC)

Hello Bawolff, no, it actually does matter because that same criteria then should be applied to all the things that can be fair-used in the US. While in general I'm in favor of adopting some more flexible criterias in certain cases when it comes to copyright, you might create a problem for downstream reusers outside of the US. Scann (talk) 03:15, 1 May 2024 (UTC)

I suppose some legal expertise is needed. Does the UK (where it appears OWID is based) have database rights? If OWID can legally use the data to create a public CC-BY-licensed database, then I assume reusers are allowed to use their licence, not underlying licences. Having to check sources of underlying data every time you include public data in your works seems unworkable. –LPfi (talk) 08:24, 2 May 2024 (UTC)

@Scann Are you also opposed to using PD-Art images? Because it is basically the same argument we use for them. Bawolff (talk) 18:20, 2 May 2024 (UTC)

Hi all, replying here. Database rights tend to always be a difficult question because they are regionally varied and therefore pose different risks to different people depending on where they are located. They are also a bit different than PD-art, which is about what does and doesn't receive copyright in different countries, whereas database rights are a separate right from copyright and can be enforced separately even where no copyright exists. Looking at OWID, we have a couple things. First, they themselves aren't helpful here. Their legal disclaimer explicitly disclaims anything about infringement, so they're not promising to have done any sort of checking or confirmation that what they have is okay. That puts the burden on us (using "us" broadly here to mean community, Foundation, or reusers, whoever might need to do the review or be best positioned to do it). Second, from the Foundation's perspective, this kind of risk is usually okay for us to still host something. Because the US doesn't have database rights and the Foundation is protected by the Digital Millennium Copyright Act, we could accept OWID's representation that the material is CC licensed until such time as someone contacted us with enough information to do a takedown. If that happened, we'd be obligated to remove under our normal DMCA policy. Third, from a reuser perspective, there might be some risk here. The UK does have database rights, which further vary in how broadly they apply based on their timing with respect to Brexit. See https://www.gov.uk/guidance/sui-generis-database-rights. The risk of violating database rights varies and depends on how much of someone else's database was used relative to the whole, so this would most likely be a case by case risk for each different dataset. -Jrogers (WMF) (talk) 17:38, 3 May 2024 (UTC)

Some generalities can be said, on the ground of which case-by-case assessment can be done. It seems that the OWID does not need to honour EEA database rights that have emerged since 2021. Does "laundering" data through the OWID (in the UK) free a reuser from respecting database rights of an original EU data set? What about the cases where the data is from the US (which does not recognize database rights) but the reuser is in the EEA? Can the US owner sue the EU user in an EU court? Are reusers obligated to determine the origins of data in OWID works? –LPfi (talk) 07:03, 4 May 2024 (UTC)

In any case, we are downloading those data and uploading them to Commons. We have been doing that for some years now. If there's any copyright issue, we are saying where the data comes from. Theklan (talk) 11:09, 4 May 2024 (UTC)

This page gets the issues at stake exactly backwards

This is a strangely bureaucratic and risk-averse take on a loving exercise in trying to find a way to integrate valuable knowledge at scale from a partner community into our projects. Can we please stop stepping on our own feet in this way?

Let's start from the end. Are there other concerns or risks not listed above? What else should we be thinking about?

The first think we should be thinking about is the benefits here to the sum of all knowledge. That's why we exist. Sharing knowledge is a risky business, and we exist to find ways to do it all the same. We should take care not to develop a culture that forgets this and tries to simply minimize risk by doing as little as possible.

Benefits

OWID is an extraordinary, award-winning source of the best visualizations in the world for a certain class of knowledge. They have some 10,000 charts providing overviews of available data on important current issues. It is our mission to empower communities to help that knowledge reach people, including by collaborating with them, integrating their work into ours, and vice-versa.

Where communities are trying to do this and failing, we should support them, offer improvements, show ways to succeed. Including in scalable, secure ways; but also in temporary jury-rigged ways until scalable ways exist.

The benefits to reaching a new network with strong visualization and data skills, and an interest in holistic overviews about the state of the world, are significant. And the benefits of supporting the work of dozens of our existing community groups for which this would improve upon and replace their current hand-updated statistics, in time and joy and accuracy, are just as great. If we had a way to directly integrate OWID data on COVID for instance, we could have avoided duplicating thousands of hours of work in recent years.

Risks

Primary risks are that we fail to become infrastructure of any sort for the free knowledge ecosystem, become known as a place where creative ways to share free knowledge go to get tied up in red tape, and become less useful than alternatives to readers, editors, and reusers. Two of the greatest self-imposed obstacles to the adoption of free-software were the weaknesses of its user interfaces, and the unfriendly dogmatism of the FSF during its heyday. Being dogmatic about privacy and security in a way that preemptively blocks experiments in better interfaces to knowledge, rather than helping make such experiments work, combines a bit of both.

1. Partners who develop other world-class free knowledge may stop trying to collaborate with us, and come to see us as a time sink that is hard to work with and in the end cannot help advance the breadth or reach of free knowledge unless it fits into a narrow and increasingly old-fashioned box.
2. New sources of knowledge, new developers, and new ideas for presenting knowledge will stop thinking of us as a natural place to invest time and energy, and stop thinking of our approach as the gold standard for sharing knowledge. We have already weakened once-strong relationships with other technical communities which are pillars of free knowledge by being hard to work with. Here we have no existing relationship with OWID, but this could be the beginning of one, as we have an active community of interest. In a healthy ecosystem we would support 100s of these. Asking 'how can we do this well + efficiently at scale' is a great question, but framing it as 'do we want to do this / is this feasible and a good use of resources' is not.
3. The above can naturally result in our projects becoming less relevant, new generations working on new projects which are as open to creative approaches as we once were, not bound by increasingly arcane restrictions. To the extent that maintaining such restrictions is in line with our mission, it is on us to make that work for our community members and for their collaborations.

We are already on a slippery slope to becoming insular and isolated, and I would be interested to see any metrics that indicate we are becoming infrastructure for anyone other than our own wiki contributors. But we don't have staff or community groups dedicated directly to ameliorating risks around this sort of knowledge expansion, partnership, and community building. So while these seem to me the clear primary risks, we mainly talk about secondary risks with named associated tasks.

Secondary risks include increasing internal demotivation and friction within our existing communities, risks to privacy and security of readers and editors, reduced article quality, and less maintainable workflows.

1. Internal demotivation: the desire to include OWID data is not new. The extensive and thoughtful efforts of a dozen people to make this possible has not been well summarized or honored on this page, nor has the importance of the end goal been acknowledged. The fact that many hours of staff time are going into risk assessment while none are going into building a better integration may reflect where we have spare capacity more than the best way to achieve our mission.
2. Internal friction: recently there has been good momentum around this initiative, which from the perspective of advancing public knowledge is fantastic. This momentum includes specific tasks and efforts currently planned for the Wikimedia Hackathon, where many interested people will be in person. A request to pause all work, without suggesting a new direction to focus technical energies, for 'two weeks' covering the week just before and after the hackathon, is perfectly timed to kill that momentum.
3. Privacy and security risks: Mainly the relative increased risk of cross-project integration, over the combination of accessing both projects separately. These concerns seem to be the primary source of the roadblocks recommended by staff, and the threat to 'disallow loading content from [owid]'.
4. If all integration is blocked, other risks include having outdated information, or separate silos for parallel libraries and workflows, which would each be less robustly maintained than shared infrastructure.

Thanks ACooper and Quiddity for thinking about this, and for developing your thoughts here in public. –SJ talk  06:17, 28 April 2024 (UTC)

Similar conversation 10 years ago

We had a similar conversation in 2014/2015 regarding external map layers were the solution was to "anonymize (proxy) it through our servers, and/or show a privacy warning". Further discussion was here. User:Slaporte (WMF) among others did a legal review in July 2015 at the request of Lila Tretikov. Doc James (talk · contribs · email) 15:34, 28 April 2024 (UTC)

Thanks, we are bearing this in mind in looking into what is the best approach here and also the most expeditious use of resources. We are looking into this as a potential option. ACooper-WMF (talk) 11:02, 2 May 2024 (UTC)