Jump to content
Wikimedia Meta-Wiki

Talk:Third-party resources policy: Difference between revisions

From Meta, a Wikimedia project coordination wiki
Content deleted Content added
Line 7: Line 7:


=== Are risks sufficiently explained and relevant? ===
=== Are risks sufficiently explained and relevant? ===
A security-wise less educated user can probably not understand the scope of the risks from these explanations alone (it is e.g. not obvious what you can do through harvested cookies and session tokens). I suggest adding links to somewhere where the concepts can be discussed a bit more in depth (perhaps a tailored set of security pages). It could also be worth pointing out that anything the owner of the script can do can be done by an attacker who succeeds in bypassing their defences – a benevolent owner may still use naïvely coded building blocks for their own scripts or otherwise neglect security.
=== Do the definitions and required precautions make sense? ===(削除) (削除ここまで)

The section on user privacy and safety does not differentiate between what a tool does and what it could do when interacting with a third-party resource. I think the section should concentrate on information that leaks regardless on how the tool is coded, as that's the (implicit) rationale for the proposal. Other leakage can be mentioned, but as this may include anything that the third party could do on a direct connection, it doesn't need to be thoroughly covered here. The latter theme could be covered on a page on WWW safety.

–[[User:LPfi|LPfi]] ([[User talk:LPfi|talk]]) 14:25, 5 June 2023 (UTC)

=== Do the definitions and required precautions make sense? ===
It seems the proposed policy would require all interaction with third-party resources to be done through interfaces offered by WMF production servers. For it not to cause disruption, these need to be offered. My understanding is that OSM tiles are nowadays fetched and cached by these. Are there other resources needing similar treatment?

For the restrictions to make sense, WMF needs to guarantee privacy when using production servers or possible external resources needed e.g. for participating in elections and surveys. I am afraid WMF shouldn't trust third parties in such matters, but instead guarantee that no sensitive information is sent to third parties.

–[[User:LPfi|LPfi]] ([[User talk:LPfi|talk]]) 14:25, 5 June 2023 (UTC)

=== How do you think the policy should be enforced? ===
=== How do you think the policy should be enforced? ===

=== When would it make sense to start enforcing the policy? ===
=== When would it make sense to start enforcing the policy? ===

=== Should WMCS-hosted resources be considered third-party resources? ===
=== Should WMCS-hosted resources be considered third-party resources? ===
I assume that some of the resources are essential tools for part of the community, while coding tools isn't restricted to highly trusted users. For the proposed policy to make sense, tools that aren't scrutinised and controlled by trusted users must be regarded as third-party ones, while regarding all the tools as untrusted would cause severe disruption. –[[User:LPfi|LPfi]] ([[User talk:LPfi|talk]]) 14:25, 5 June 2023 (UTC)


==Examples of what this will end==
==Examples of what this will end==

Revision as of 14:25, 5 June 2023

Welcome here! The Security team is calling for feedback on a proposed Third-party resources policy from June 05 to July 17, 2023. Your suggestions and comments are warmly encouraged below.

05 June 2023: Start of the policy conversation

Latest comment: 1 year ago 4 comments2 people in discussion

Hello, feedback regarding the Third-party resources policy is welcome below this message. Feel free to use the initial questions below as a starting point for the conversation or bring your own. Thank you!

On behalf of the Wikimedia Foundation’s Security team — Samuel (WMF) (talk) 00:50, 5 June 2023 (UTC) Reply

Are risks sufficiently explained and relevant?

A security-wise less educated user can probably not understand the scope of the risks from these explanations alone (it is e.g. not obvious what you can do through harvested cookies and session tokens). I suggest adding links to somewhere where the concepts can be discussed a bit more in depth (perhaps a tailored set of security pages). It could also be worth pointing out that anything the owner of the script can do can be done by an attacker who succeeds in bypassing their defences – a benevolent owner may still use naïvely coded building blocks for their own scripts or otherwise neglect security.

The section on user privacy and safety does not differentiate between what a tool does and what it could do when interacting with a third-party resource. I think the section should concentrate on information that leaks regardless on how the tool is coded, as that's the (implicit) rationale for the proposal. Other leakage can be mentioned, but as this may include anything that the third party could do on a direct connection, it doesn't need to be thoroughly covered here. The latter theme could be covered on a page on WWW safety.

LPfi (talk) 14:25, 5 June 2023 (UTC) Reply

Do the definitions and required precautions make sense?

It seems the proposed policy would require all interaction with third-party resources to be done through interfaces offered by WMF production servers. For it not to cause disruption, these need to be offered. My understanding is that OSM tiles are nowadays fetched and cached by these. Are there other resources needing similar treatment?

For the restrictions to make sense, WMF needs to guarantee privacy when using production servers or possible external resources needed e.g. for participating in elections and surveys. I am afraid WMF shouldn't trust third parties in such matters, but instead guarantee that no sensitive information is sent to third parties.

LPfi (talk) 14:25, 5 June 2023 (UTC) Reply

How do you think the policy should be enforced?

When would it make sense to start enforcing the policy?

Should WMCS-hosted resources be considered third-party resources?

I assume that some of the resources are essential tools for part of the community, while coding tools isn't restricted to highly trusted users. For the proposed policy to make sense, tools that aren't scrutinised and controlled by trusted users must be regarded as third-party ones, while regarding all the tools as untrusted would cause severe disruption. –LPfi (talk) 14:25, 5 June 2023 (UTC) Reply

Examples of what this will end

Latest comment: 1 year ago 2 comments2 people in discussion

Would be good to clarify what features this policy will end. For example we have the option for relief maps on WikiVoyage which notifies users that to activate it will share details with an external service.[1] I imagine this policy would end that? These relief maps are excellent especially for hiking.

Additionally we have a great deal of functionality on the wmcloud which could than become less usable, which IMO would be unfortunate. Doc James (talk · contribs · email) 10:57, 5 June 2023 (UTC) Reply

Yes, I'm confused on how OpenStreetMap falls into the "Risks" category. SHB2000 (talk | contribs) 11:48, 5 June 2023 (UTC) Reply

This is a step backwards on our strategic goals

Latest comment: 1 year ago 1 comment1 person in discussion

I'm concerned with this proposal, and I have some reasons. Graphs have been broken for more than a month now, and it doesn't seem that they are going to recover, losing opportunities to show things in a more interesting way. Some efforts we have made to show Ourworldindata maps and graphs are also stopped at "security review". Some years ago, we launched (and invested lot of money on) a system that would read the articles in some languages but it never succeeded because of the same reason.

And I would accept that having third-party resources is not the best option if we had product team working on those features. But this isn't happening and doesn't seem it will happen in the future. Some years ago we were obsolete. Now we are paleolithic, a relic for archaeologists of the Internet. Meanwhile, other platforms are advancing by the day on new features. Every day we are further from our 2030 strategic goal. Theklan (talk) 11:18, 5 June 2023 (UTC) Reply

AltStyle によって変換されたページ (->オリジナル) /