공동체 건강 이니셔티브/차단 도구 및 개선

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
This page is a translated version of the page Community health initiative/Blocking tools and improvements and the translation is 41% complete.
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎Esperanto • ‎Tiếng Việt • ‎Türkçe • ‎dansk • ‎español • ‎français • ‎magyar • ‎polski • ‎português do Brasil • ‎Ελληνικά • ‎العربية • ‎پښتو • ‎বাংলা • ‎日本語 • ‎한국어
Light-Bulb icon by Till Teenck green.svg

This page documents a feature the Wikimedia Foundation's Anti-Harassment Tools team has prioritized for software development.

🗣   We invite you to join the discussion!
🛠   Track in Phabricator at T120734.

위키미디어 재단의 괴롭힘 방지 도구 팀은 2018년 개발 작업을 위해 2017년 12월에 새로운 차단 도구 및 기존 차단 도구 개선 사항에 대해 논의하기 위해 위키미디어인들의 참여를 요청했습니다. 우리 팀은 중단을 최소화하고, 악의적인 사용자를 위키에서 차단하고, 전체 사이트 차단이 적절하지 않은 상황을 조정하기 위해 위키 공동체를 위해 구축할 수 있는 차단 도구를 결정하기 위해 미디어위키의 현재 차단 기능의 단점을 확인했습니다.

업데이트

2019년 9월 11일

모든 위키여행과 위키문헌, 위키낱말사전 위키에서 부분 차단이 활성화되었습니다. 다양한 프로젝트에 배포된 기능의 지난 몇 개월 동안 버그가 점점 더 적어지는 것을 보았기 때문에 부분 차단 기능이 현재 양호하고 안정적인 단계라고 생각합니다. 팀은 차단 코드의 백엔드 인프라를 개선하는 데 많은 시간을 보냈으며 추가해야 할 향후 기능을 예상하여 코드가 신뢰할 수 있는지 확인했습니다.

부분 차단에 대한 더 많은 위키의 요청이 계속되고 있습니다. 우리는 또한 위키마니아에서 부분 차단에 대해 발표했으며, 여러 참석자들이 홈 위키에서 부분 차단을 활성화하도록 요청하는 등 호평을 받았습니다. 배치 된 위키의 부분 차단에 대한 일반적인 긍정적인 반응을 고려하여, 우리는 앞으로 몇 주 안에 더 많은 위키미디어 프로젝트에 더 넓은 배치를 할 계획입니다.

기능 사용에 대한 데이터 수집과 함께 더 많은 위키에서 기능을 출시함에 따라 부분 차단에 대한 피드백을 계속 수집할 것입니다. 또한 필요할 때마다 기능에 대한 유지 관리 작업을 수행합니다.

2019년 3월 1일

Recommendations for Software to Mitigate Long-term Abuse on Wikimedia, full report, March 1 2019.pdf

오늘 저는 위키에서 발생하는 장기적 악용을 방지하기위한 도구에 대한 위키미디어 재단의 괴롭힘 방지 도구 팀의 권장 사항을 공식적으로 공유합니다. 이 9쪽 짜리 문서는 발생하는 장기적인 남용의 유형을 대략적으로 정의하고, 이러한 행동을 완화하고 용인하는 데 사용되는 기존 도구 및 전술을 설명하고, 이러한 남용(즉 장치 차단)을 방지하기 위해 잠재적인 새로운 소프트웨어를 조사하고 다음 단계에 대한 권장 사항을 제공합니다.

요컨대, 우리의 권장 사항은 성공적인 영향을 미칠 가능성이 매우 낮은 비용이 많이 드는 노력이므로 장치 차단을 피하는 것입니다. 대신, 우리 팀은 사용자 보고 시스템, 검사관 개선, 추가 음소거 기능 등을 포함한 대체 전술을 권장합니다.

이 연구의 즉각적이고 부차적인 결과는 우리 팀이 쿠키 차단 기능을 시각 편집기 및 모바일 편집기로 확장하기 위해 노력할 것이라는 것입니다. — phab:T196575

2019년 2월 15일

부분 차단에 대한 초기 기능 개발이 완료되었습니다! 관리자는 이제 특정 페이지 또는 이름 공간에서만 편집을 금지하는 차단을 설정할 수 있습니다. 중요한 기능을 잊지 않도록 되돌리기가 느리고 단계적으로 진행됩니다.

2019년 1월 18일

공동체 건강 이니셔티브/차단 도구 및 개선 사항/차단 알림에서 "당신은 차단되었습니다"라는 메시지가 사용자에게 얼마나 자주 나타나는지에 대한 데이터를 수집했습니다. 일부 종합적인 결과 뿐만 아니라 일부 그래프와 원시 데이터 표가 있습니다. 주요 내용은 다음과 같습니다:

  • 차단 알림은 가장 큰 위키미디어 프로젝트에서 자주 나타나며 때로는 실제 편집보다 많을 수 있습니다. (영어 위키백과에서 30일 동안 620만 건의 차단된 편집이 발생했습니다.)
  • 데스크탑 위키 텍스트 편집기는 대부분의 노출을 넓은 여백으로 볼 수 있습니다. (영어 위키백과 98%, 스페인어 89.5%, 러시아어 98.7%)
  • 시각편집기와 모바일 차단 알림은 덜 자주 발생하지만 매달 수천 명에게 표시됩니다. 데스크톱 우선 디자인의 유산을 감안할 때 디스플레이 최적화에는 장애물이 있습니다.

2019년 1월 16일

이탈리아어 위키백과에서 부분 차단이 활성화되었습니다! 🎉 테스트 할 위키백과를 더 찾고 있습니다. 공동체가 테스트 할 의사가 있는 경우 토론 페이지에 메시지를 남겨주세요! 더 많은 정보는 프로젝트 페이지에서 찾을 수 있습니다.

또한 우리 팀은 현재 위키미디어의 장기적 악용을 완화하기 위해 잠재적인 소프트웨어 솔루션을 찾고 있습니다. 위의 §문제 1. 사용자 이름 또는 IP 주소 차단은 정교한 사용자가 쉽게 피할 수 있습니다에 나열된 몇 가지 아이디어를 탐색하고 있습니다. 우리는 2월말까지 예비 조사를 완료하는 것을 목표로 하고 있으며 모든 메모와 조사 결과를 여기 메타위키에 게시 할 예정입니다.

12월 20일

부분 차단은 아직 개발 중입니다. 테스트 위키백과에서 활성화되며 1월에 이탈리아 위키백과에서 활성화 될 예정입니다.

"당신이 차단되었습니다" 메시지에 대한 데이터는 7개의 위키에 대한 이 그래프에서 볼 수 있습니다(곧 추가 될 예정입니다). 저는 오늘 오후에 흥미로운 통찰력이 있는지 알아보기 위해 상호 관련된 차단 데이터를 파헤칠 것입니다. 현재 가장 통찰력있는 점은 다음과 같습니다. 1) 멀리서 대부분의 사람들이 위키 텍스트 편집기를 통해 데스크톱에서 차단된다는 사실을 알게됩니다. 2) API 차단 수가 엄청나게 많은 독일어 위키백과를 제외하고 3) 대략적인 어림잡은 계산으로 모바일 차단 알림은 데스크톱 사이트 알림과 관련하여 일반 편집 트렌드와 동일하게 나타납니다(편집의 약 95%는 데스크톱 편집기에서 가져온 것입니다). 오늘 중으로 제가 가지고 있는 내용에 따라 여기에 부록을 게시 할 수 있습니다.

2018년 종료를 위한 차단에 대한 마지막 참고 사항: 내년에 우리 팀은 문제 1로 설명되고 논의 된 장치 차단을 조사하기 시작할 것입니다. 사용자 이름 또는 IP 주소 차단은 정교한 사용자가 쉽게 회피할 수 있습니다. 2019년 초에 위키미디어 이사회에 제안을 할 예정입니다.

12월 5일

우리 팀은 이탈리아어 위키백과에서 부분 차단을 활성화하기 전에 최종 결함을 해결하기 위해 계속 노력하고 있습니다. 우리는 다음 주에 이 이정표를 달성할 수 있다고 낙관합니다! 그 동안 테스트는 지금까지 준비된 것을 살펴보고 싶은 사용자를 위해 테스트 위키백과테스트 위키데이터에서 사용할 수 있습니다. 우리는 또한 겨울 휴가를 시작하기 전인 12월말까지 이름 공간 차단을 거의 준비된 상태로 만들 수 있다고 확신합니다. 이 기능은 1월에 테스트 위키에서 준비될 것입니다.

어제 사용자에게 표시되는 차단 알림 메시지(즉, "당신은 차단되었습니다" 메시지)에 대한 추적을 활성화했습니다. 데이터는 이 그래프에 표시됩니다. 이 데이터는 현재 이탈리아어 위키백과에서만 측정되고 있지만 다음 주에 추가로 19개의 위키에서 활성화 할 계획입니다. 이를 다른 알려진 차단 데이터와 비교하여 차단 된 사용자가 편집을 시도하는 빈도를 더 잘 이해할 수 있습니다. 이는 이러한 메시지를 개선하고 사용자의 워크 플로를 차단 해제 할 것인지 여부 또는 방법에 대한 결정을 알려야합니다.

11월 8일

부분 차단은 테스트 위키백과테스트 위키데이터에 있습니다! 다른 위키의 관리자이고 기능을 테스트하고 싶다면 토론 페이지에 메시지를 작성하세요.

이 첫 번째 기능 묶음은 제한됩니다. 관리자는 사용자 또는 IP가 최대 10개의 지정된 페이지를 편집하지 못하도록 차단할 수 있습니다. 현재 작업중인 몇 가지 알려진 결함이 있으며(예를 들어 관리자가 페이지에서 부분적으로 차단 된 경우 "어떤" 페이지도 삭제할 수 없습니다) 11월 말에 이름 공간과 업로드 차단 구축으로 돌아갈 것입니다.

부분 차단을 테스트하는 경우 우리는 여러분의 의견을 듣고 싶습니다! 도구 사용 경험에 대한 메모를 남겨주세요. 특별히 다음에 대한 피드백을 찾고 있습니다.

  • 사용자가 차단해야하는 페이지 수의 적절한 제한은 무엇인가요? 첫 번째 버전에서는 10개로 제한되지만 숫자에는 제한이 없습니다.
  • 부분 차단이 기록되는 방식에 만족하나요?
  • 이미 구축 된 것을 변경해야하나요?
  • 시각편집기의 경고 메시지가 너무 부드럽나요?

감사합니다!

2018년 8월 22일

부분 차단(phab:T2674)에 대한 작업의 일환으로 공동체가 다른 만료 날짜에 대해 다른 제재를 설정할 수 있도록 단일 계정(사용자 또는 IP)에 대해 여러 동시 차단을 설정할 수 있는 시스템도 구축해야한다고 결정했습니다.(예를 들어 사용자는 파일 업로드에 대한 무제한 차단이 있지만 사이트 전체에서 24시간 차단 될 수 있습니다.) 우리는 이 작업을 멀티 차단이라고 부르고 있으며 이 작업은 phab:T194697에서 추적 할 수 있습니다. 또 다른 디자인 라운드가 진행 중이며 다음 주 프로젝트 페이지에서 공유됩니다.

차단의 기술적 측면에 관심이 있는 사람들을 위해 우리가 만들 계획인 데이터베이스 변경에 대한 기술적 RFC를 보유하고 있습니다. 변경 사항 요약은 phab:T199917에서 확인할 수 있습니다.

2018년 6월 28일

지난 몇 달 동안 위키미디어 재단의 괴롭힘 방지 도구 팀은 차단 도구를 개선하기 위해 노력해 왔습니다. 최근에 정확한 차단 만료(phab:T132220)를 보다 쉽게 설정할 수 있도록 특수:차단 도구에 기한 선택기를 추가했습니다. 또한 모바일 장치 사용자에게 차단되었음을 알리는 알림을 업그레이드했습니다(phab:T165535). 차단을 더 강력하게 만들기 위해 쿠키 차단을 IP 차단으로 확장하여 사람들이 차단을 회피하는 것을 더 어렵게 만들었습니다(phab:T152462).

우리는 관리자가 브라우저 정보의 해시 조합으로 사용자를 차단할 수있는 방법을 구축하는 방법을 조사했지만 편집 세션 동안 더 많은 데이터를 캡처하지 않으면 효과적이지 않을 것이라고 판단했습니다(phab:T188160). 이 때문에 현재 이 기능을 사용하지 않기로 결정했습니다. 대신, 우리는 검사관에게 IP 주소 또는 IP 범위 및 브라우저 사용자 요원(phab:T100070) 별로 차단할 수있는 기능을 제공하는 티켓을 준비했습니다. 이 작업은 준비되고 구축 할 준비가 되어 있으며 우선 순위 지정을 기다리고 있습니다.

우리 팀은 현재 부분 차단 또는 관리자가 특정 페이지, 이름 공간 내의 모든 페이지 또는 파일 업로드에서 사용자를 차단하는 기능을 구축하는 작업을 진행하고 있습니다. 우리는 이것이 위키의 다른 부분에서 생산적인 문제가 있는 사용자를 위해 더 많은 전술적 제재를 설정할 수 있다고 믿습니다(phab:T2674). 해당 프로젝트를 팔로우하고 커뮤니티 건강 이니셔티브/사용자 별 페이지, 이름 공간 및 업로드 차단에서 디자인을 볼 수 있습니다.

미디어위키의 현재 차단 기능

Quicksand warning sign Texel 2004.jpg

현재 위키미디어 위키에서 사용자와 IP는 문서 편집에서 차단 될 수 있습니다.[1] 차단은 사용자가 위키의 모든 이름 공간에 있는 모든 페이지를 편집하는 것을 금지합니다. 단, 차단 된 당사자의 사용자 토론 페이지는 예외입니다. 차단은 기본적으로 관리자에게 허용되며 Special:Log와 Special:BlockList, Special:Block에 공개적으로 기록됩니다.

차단과 유사하게 전역 계정 잠금은 사용자가 위키미디어 위키에 로그인하는 것을 금지하고 전역 차단은 사용자가 위키미디어 위키에 로그인하는 것을 금지하며 전역 차단은 IP 주소에 대해 설정할 수 있습니다.

자동 차단은 사용자 이름 차단에 할당 될 수 있으며, 이는 위반 사용자가 24시간 동안 사용하는 IP 주소를 자동으로 차단합니다.

문제 1. 사용자 이름 또는 IP 주소 차단은 정교한 사용자가 쉽게 피할 수 있습니다

사용자 이름과 IP 주소 또는 IP 범위에 대해 차단을 설정할 수 있습니다. IP 주소는 프록시를 통해 쉽게 스푸핑되거나 변경 될 수 있습니다. 새 계정을 만드는 장벽은 매우 낮고 쉽게 피할 수 있습니다. 위키미디어 운동은 개방성과 프라이버시를 중시하므로, 우리는 선의의 신규 사용자들이 우리 플랫폼에 접근 할 수 있도록 유지하는 것과 악의적 인 행위자를 차단하는 균형을 유지해야합니다.

우리는 좀 더 현대적인 식별 기술을 사용하는 새로운 차단 기술을 구현할 수 있습니다. 이러한 기능은 우리의 개인 정보 보호 정책이용 약관을 준수해야합니다.

제안 된 잠재적인 솔루션:

  • 사용자 요원에 의한 차단[2][3][4] (검사관 검색 포함)
  • 장치 ID로 차단(검사관 검색 포함)
  • 사용자 이름에 대한 전역 차단[5]
  • 전역 차단에 "계정 생성 방지" 추가[6]
  • 익명 사용자에 대한 쿠키 차단[7]
  • 자동 차단을 1일 이상으로 연장하는 방법 추가[8]
  • 오픈 프록시를 사전 예방 적으로 차단합니다(또는 IP를 위키 간 공유하는 시스템 구축)
  • Hash personally identifiable data to surface as a percentage match to CheckUser[9]
  • AI that compares editing patterns and language to predict possible sockpuppets[9]
  • Identify sockpuppets by typing patterns (e.g. rhythm/speed), network speed, and editing patterns (e.g. time of day, edit session length, categories of pages edited)[9]
  • Display all contributions made within an IP range on one feed (aka 'Range Contributions')[9][10]
  • Extend Nuke to IP ranges[9]

Problem 2. Aggressive blocks can accidentally prevent innocent good-faith bystanders from editing

Many IPs and IP ranges are shared by multiple users (e.g. libraries, schools, office buildings) and most individual IPs can (and will) be reassigned by ISPs to other users. If one bad actor gets the IP or IP range blocked, other users cannot edit. Some IP blocks allow for logged-in editing, and good usernames can be whitelisted from IP blocks that prohibit logged-in editing.

We could implement new features that prohibit IPs from editing or creating throwaway accounts, but allow good faith bystanders to still create accounts and productively edit.

Proposed potential solutions:

  • Require all accounts created in an IP range to confirm their email address before editing.
  • Prevent the use (or flag incidents) of blacklisted email addresses from being associated with new user accounts
  • Throttle account creation and email sending per browser as well as IP address[11][3]
  • Require email address to be unique for edits in certain IP ranges (potentially requiring whitelisted email domains)[9]
  • Allow CheckUsers to compare hashed email addresses[9]
  • Build AI that automatically sets a block length and type based on UserAgent, IP and/or email[9]
  • Require two-factor authentication for edits in certain IP ranges[9]
  • Convert Twinkle and/or Huggle from gadgets to extensions, increase their accuracy[9]

Problem 3. Full-site blocks are not always the appropriate response to some situations

Smaller, more tactical blocks may defuse situations while retaining constructive contributors. On some wikis such as English Wikipedia, this concept is dictated by bans. However, technical means to enforce bans are currently limited, and consequently a user may unnecessarily be blocked from editing the wiki as a whole.

Full-site blocks are akin to a sledgehammer. How can we build fly-swatters to prevent a user from causing limited harm while keeping them a part of the wiki.

Proposed potential solutions:

  • Block a user from...
    • ...individual pages[12][13][14][15]
    • ...all pages inside a specific category
    • ...specific namespaces[16]
    • ...creating new pages
    • ...uploading files[17]
    • ...all pages except talk pages[18][19]
    • ...all pages, except a whitelist
    • ...viewing Special:Contributions
    • ...emailing or pinging other users[20][21]
  • Allow admins to specify exactly which permissions to block.[22][23][24][25]
  • Allow admins to temporarily revoke a users' autoconfirmed status.[19]
  • Require all edits by a user to go through deferred changes.[26]
  • Block that only expires when a user has read a specified page (training module, user talk page, etc.)[27][28]
  • Allow admins to throttle a user's edits to a maximum number per day/hour/etc[9]
  • Build a version AbuseFilter that runs on all edits of specified users to create custom, complex blocks[9]
  • Tool to prevent users from writing about themselves.[9]
  • User masking systems to obfuscate or ‘hide’ users from each other on wiki [9]

Problem 4. The tools to set, monitor, and manage blocks have opportunities for productivity improvement

The existing blocking tools (Special:Block, the API, Twinkle, Special:BlockList, etc.) are used daily by numerous users across all Wikimedia wikis. Using these tools can be time intensive, so we would like to explore ideas of how we can simplify the workflows to set or modify a block, monitor block logs, and check the status or details of a block.

Proposed potential solutions

  • When leaving a warning on a user talk page, display how many other warnings have ever been given to that user.[29]
  • Twinkle should automatically know the appropriate warning template to use on that user.
  • Log bans like blocks, which could result showing the information on their user page, contributions, or autogenerate a list of all banned users.[30]
  • Allow CheckUsers to watch specific IPs[31]
  • Allow admins to annotate previous blocks as accidental[32][33][34]
  • Allow admins to set a block date range via datetime selector[35]
  • Allow admins to set different expiration times for blocking editing vs. account creation[36]
  • Allow admins to oversight usernames while blocking them[37]
  • Display block expirations in logs[38]
  • Display a warning on the block page when admins are blocking a sensitive IP[39]
  • Special:Block could suggest block length for common policy infractions[9]
  • Improved way to set mass blocks[9]
  • Block appeal process could be improved to reduce the work required for admins[9]
  • Display if a user is currently blocked on another wiki on Special:Block[9]
  • Mobile block notices are abysmal [9][40]
  • Allow admins to ‘pause’ a block so the user can participate in on-wiki discussions[9]

같이 보기

  • /Links — A list of links on Meta Wiki, MediaWiki.org, and Phabricator about existing blocking tools or suggestions for improvements.
  • /English Wikipedia policies — A list of links on English Wikipedia about blocking policies or tools, and talk page conversations about improvements.
  • /Block notices — Data about how often the "you are blocked" notices appear to people attempting to edit a wiki.
  • Community health initiative/Editing restrictions — The WMF's Anti-Harassment Tools team's documentation page about how new tools could support the socially enforced editing restrictions used by English Wikipedia.
  • Community health initiative/Partial blocks — Project page for partial blocks, which allow admins to prevent a user from editing specific page(s) or namespace(s).

Footnotes

  1. MediaWiki.org의 도움말:사용자 차단하기
  2. T100070 — 사용자 에이전트 (UA) 기반 IP 차단 허용
  3. a b 2015년 공동체 위시리스트 설문 조사/검토 및 관리 도구#미디어위키 차단 도구 개선
  4. 2017년 공동체 위시리스트 조사/스마트 차단
  5. 작업 항목의 우선 순위 지정, 사무장 방문 2015년, 9쪽
  6. T17273 — 전역 차단에 "계정 생성 방지"를 추가하세요
  7. T152462 — 익명 사용자 차단시 쿠키 추가
  8. T27305 — 자동 차단을 1일 이상으로 연장하는 방법 추가
  9. a b c d e f g h i j k l m n o p q r s t Talk:Community health initiative/Blocking tools and improvements
  10. phab:T145912
  11. T106930Throttle account creation and email sending per browser as well as IP address
  12. T2674Allow users to be blocked from editing a specific article
  13. See also: Community health initiative/Editing restrictions
  14. 2015 Community Wishlist Survey/Moderation and admin tools#Enhanced per-user, per-article protection/blocking
  15. 2017 Community Wishlist Survey/Per-page user blocking
  16. T179110Allow users to be blocked from editing a specific namespace
  17. T6995Ability to block users from uploading files only
  18. T18644Allow users to be blocked from editing non-talk pages only
  19. a b Wikipedia talk:Blocking policy/Archive 21 on English Wikipedia
  20. It is currently possible to block someone from using Special:EmailUser, but this requires also blocking them from editing
  21. T104099Add ability to block users from emailing other users (without performing a full block)
  22. T27400Software should allow admins to give specific users permission to edit specific pages through blocks
  23. Extended_blocking on MediaWiki.org
  24. Wikipedia talk:Blocking policy/Archive 23 on English Wikipedia
  25. 2017 Community Wishlist Survey/Allow further user block options ("can edit XY" etc.)
  26. 2016 Community Wishlist Survey/Categories/Moderation tools#All edits from hardblocked IP mark as unreviewed
  27. T18447Set a block that only expires when a user has read a specified page (training module, user talk page, etc.)
  28. Wikipedia talk:Blocking policy/Archive 22 on English Wikipedia
  29. Wikipedia talk:Administrators' noticeboard/Archive 8#Warnings and discussion before blocks on English Wikipedia
  30. Wikipedia talk:Banning policy/Archive 3#Recording of Bans on English Wikipedia
  31. T21796CheckUser watchlist feature
  32. T46759Allow marking blocks that were made in error
  33. 2016 Community Wishlist Survey/Categories/Admins and stewards#Enable administrators to update block logs
  34. Wikipedia talk:Blocking policy/Archive 20 on English Wikipedia
  35. T132220Add datetime selector to block and protect interface to select expiration
  36. T65238Different lengths of block and block account creation
  37. 2016 Community Wishlist Survey/Categories/Admins and stewards#Allow admins to hide names of users while blocking them
  38. T148649Display an entry for page in watchlist when page protection expired; Display an entry in user page when user blocking expired
  39. T151484Display a warning on the block page when admins are blocking a sensitive IP
  40. phab:T165535