JA:破壊行為

From OpenStreetMap Wiki
(Redirected from JA:Vandalism)
Jump to: navigation, search
利用できる言語 — Vandalism
· Afrikaans · Alemannisch · aragonés · asturianu · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · Bân-lâm-gú · Basa Jawa · Basa Sunda · Baso Minangkabau · bosanski · brezhoneg · català · čeština · corsu · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · latviešu · Lëtzebuergesch · lietuvių · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tagalog · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · беларуская · български · қазақша · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · मराठी · हिन्दी · भोजपुरी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · བོད་ཡིག · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ ⵜⴰⵏⴰⵡⴰⵢⵜ‎ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 中文(繁體)‎ · 吴语 · 粵語 · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް
その他の言語このウィキの翻訳を支援してください
偽物の町を作った破壊行為

破壊行為(Vandalism)は OpenStreetMap コミュニティで合意された規範を意図的に無視することです。単純ミスと編集間違いは破壊行為ではありませんが、破壊行為の修正に使われるものと同じツールを使ってリバートする(訳注:編集を元に戻すこと)必要がある場合があります。

破壊行為やその他の悪い編集の種類

GPS 軌跡への落書き(3つの地名)。

もっとも素朴な感覚の破壊行為は、地図上に「落書き」をすることで、子供じみた悪戯の動機から行われること、意図的に OpenStreetMap に損害を与えるものもあります。純粋な破壊行為が行われることは比較的まれです。 OpenStreetMap は非営利のよい理想であり、地図データはコミュニティが「所有して」います。ほとんどの人がこれを尊重しています。

子供じみた悪戯を動機として行われる破壊行為に近い、悪い編集の様々な他の種類のものがありますが、結果的に修正する方法は同じです。以下のようなものがあります。

  • 著作権侵害
  • OpenStreetMap データベース内の紛争(編集合戦)
  • ウィキ上の紛争
  • ボットの不適切な使用
  • データの大掛かりな編集(タグの追加や変更など)
  • 繰り返される破壊的な行為
  • スパム
  • 正しいと考えられているデータの意図的な削除や退化
  • 議論されていないインポート

単純ミスと編集間違いは破壊行為ではありませんが、リバートする必要がある場合もあります。

法的な位置づけ

多くの国ではサイバー犯罪に対する法律があり、「コンピュータシステムのデータの改竄とそれによる損害の発生」などに対応しています。 OSM での破壊行為で裁判沙汰になったり有罪になったりした事件は認知されていませんが、 OSM に「落書き」をしつこく追加する人にも、それが OSM に損害を与える行為だと通告すれば、理論的には適用できます。

検出

Detecting vandalism within OSM is a tricky situation as the types of vandalism above are wide ranging in type, extent, and effect. One of the easiest ways to detect vandalism is using the history tab on the main page and inspecting edits in a location--accomplished easier when looking at a limited area like a town or small municipality.

There are multiple approaches to automated vandalism detection that generally fall within two categories: changeset focused and user focused. But, as in the case of any detection system, either focus will often have false positives or miss "smart" vandals.

変更セットに注目する方法

Changeset focused detection relies on scanning changesets for nefarious behavior by examining the metadata of the changeset and perhaps the actual objects or nature of tags used. One common method employs limits on the amount of objects edited, added, or deleted. An example program in pseudocode:
for changeset in diff file:
    if more than 1000 objects are added:
        flag as a potential import
    if more than 1000 objects are modified:
        flag as a potential mechanical edit
    if more than 1000 objects are deleted:
        flag as a potential vandal
This type of scanning lends itself to the idea that users generally do not edit a large amount of objects in every day mapping. But, in the above example, all events are flagged "potential" as there are often very reasonable explanations for performing so many actions (e.g. authorized imports, reversions of bad edits, etc.).

In the changeset approach, tags can also reveal potentially bad behavior. Listing copyrighted data as a source is usually a red flag, though some users unfamiliar with the source of default imagery like Bing may list a generic trademark (e.g. Google, Garmin) creating a false positive. Using very outdated or uncommon editors, adding very long tag values, including many extraneous changeset tags, and other behaviors are other examples of leveraging tags in detecting bad edits.

Another component of the changeset approach is examining the spatial characteristics of the objects in a changeset. Added or edited objects could be compared to samples of smiley faces, drawn out words, anatomical features, and doodles to test how similar they are to this list of graffiti.

ユーザーに注目する方法

User focused detection looks at the editing character of the individual. Did a user make 300 edits within 10 minutes of joining? Are all edits of a new user deletions? This detection aims to catch the behavior of the individual instead of the characteristics of the objects.

破壊行為への対応

一般ガイドライン

2009年9月のメーリングリストでの議論からの観点は次の通り:[1]

  • 全ての投稿者はいつでも良い、正確でよく調査された変更を試みようとしているはずだ、ということを念頭におくべきです
  • 我々はあらゆる投稿者はデータセットをより良くしようという(より悪くではない)バランスの上にいるということを確認する必要があります。もし投稿が疑わしいものであれば、相手の投稿者に調査と返信を依頼すべきです。
  • 我々は、人は誤りを犯すものであり、学習には時間が掛り、新しい参加者はしばしば手助けに反応するものだとということに目を向けるべきです。
  • 我々は投稿者に対して、変更セットにコメントを追加したり、その興味と知識についての詳細を個人ページに役に立つからと言って掲載してもらうようにお願いすることはできますが、強制することはできません。とはいえこれをやっていると、リバートをする必要が無く、必要な時にその個人が手助けされる傾向にあります。
  • 誰かが奇妙な編集をしているように思えた際には、最初に「良心(訳注:good faith)」を信じながらも、注意深く見守り、必要であれば他の人と議論すべきです。
  • もし、ウェイに対する編集の多くが悪意があったり、不快なものであったり、中傷であったりであることが明確に証明された場合や、これらがプロジェクトの信用を失墜させる可能性があれば、関連する変更セットは議論や変更セットを100%チェックすることなしに、直ちにリバートすることができます。
  • その編集が、疑わしいが正しくないと証明できない場合、その人に連絡をとり、詳しい話を聞くべきです。筋道だてた説明が無かったり(あるいは返事がなかったり)、疑わしい編集が引き続き行われ、あまり有益な投稿であると思えない場合には、少なくともひとつ、正しくない編集を証明し、他の人とその疑念のある、及び当人が作成した可能性のある全ての変更セットをリバートすることが適切であるかどうかを議論した上で決定すべきです。
  • いったん誰かが問題のある投稿者として識別されたら、それから先の変更セットをリバートする前に、まずは一連の編集を手短に検査すべきです。
  • もし問題が続くようであれば、「バーチャル・バン(訳注:仮アカウント削除)」します。この状態になると、当人がシステム管理者に連絡して、心を入れ換えたのでもういちどチャンスを欲しい、と言わない限り、変更のメリットを検査することなしにその編集がリバートされます。
  • もし誰かが世界のどこかで悪い編集を行ったら、世界中からの反応を期待できるでしょう。というのも、誰かがアイスランドにちょっかいを出す一方でアイルランドで良い編集を行い、現地の人たちの頭の中で何が起こるか私にはあまりよく分からない、ということは考えにくいからです。 —私は他人の良い作業を、何らかの良い編集もまた無意味なものと化してしまうめったにない機会に巻き込まれてしまう損傷から保護することを選ぶでしょう。
  • 他の人々の作業をリバートする人は、それがその問題に対して十分な理由に基づき、バランスの取れたものであることを示す用意がなければなりません。
  • 「null」編集 — 要素を「変更する」以外に目的がない編集 — は、誤りやエディタの都合で行われたり、エリアを更新するために有益であったりします。しかし、「null」編集を多用することは、混乱を招く行為だとみなされるでしょう。

通常のリバート

破壊行為の範囲がローカルで、コミュニティ全体への影響が限られたものである場合、礼儀正しい直接の人間による連絡をOSMサイトのメッセージ機能で、悪意が無いという前提で行い、反応を24~48時間待ってください。もし適切な反応が無ければ、適切なメーリングリスト(通常はその国やローカルのリスト)上や信頼できる個人とその問題について議論するのが適切でしょう。いくつかの編集が非生産的であることが証明でき、役に立つ編集が明らかでない場合は、疑念のある変更セットはリバートされるべきです。

リバートのログをセットアップするのは適切です。Within England/Wales/Scotland please put requests on the GB revert request log.

スピーディなリバート

もし、ウェイに対する大多数の編集が完全に悪意があったり、不快なものであったり、中傷であったりということが証明されるか、プロジェクトの信用を失墜させると考えられる場合には、即座に反応することが重要であり、最初にリバートするのと並行してその投稿者に問いかけてください。同時にデータ・ワーキング・グループに連絡することも適切です。 Objects that have been touched since the initially bad edit may require using a complex reversion method, so if you are unfamiliar with these tools then seek assistance from the community or Data Working Group.

一時的なブロック

If, after contact has been made with the mapper via changeset discussions and/or messages, the mapper refuses to respond and does not alter their behavior, the Data Working Group may place a temporary block on the user in question. This is neither a presumption of guilt nor a banishment from the project. Rather, it is a measure to get the attention of the mapper as they must log in to the OSM site and read the block message before they can continue uploading edits through the API.

Blocks come in varied time lengths to expiration from 0 to 96 hours. They also have the capability to require a user to log in and read the block message before it is removed, regardless of expiration time. DWG members will often place a 0 hour block on an account with the block message read condition as an initial measure to unresponsive conflicting mappers. A history of blocks is available here.

永久追放

See the OSM Foundation ban policy for more information.

ツールとリンク

関連する地物にそれ以上引き続き編集が加えられていない限りにおいて、特定の変更セットをリバートすることができるツールがあります。これらのツールは現時点では使うのが難しく、さらなる打撃を引き起こすことなしに操作するには優れた技術的知識が必要です。

ガバナンス

可能な場合にはローカルのOpenStreetMapコミュニティが上記手順を通して破壊行為を解決すべきです。

データ・ワーキンググループ

詳細はData working groupを参照

データ・ワーキンググループはより深刻な破壊行為を取り扱うことをファウンデーションより任じられており、月次の理事会会議で理事会に報告します。コミュニティのアプローチが機能しないレアケースにおいてはデータ・ワーキンググループ(data@osmfoundation.org)に報告すべきです。

開発

破壊行為に関連する問題を扱うのに使えそうな多くのツールがあります。使えそうなツールとは以下を含みます:

  • White lists
  • Data rollback — Let the community run this task using tools that have been tested
  • Data deletion — Let the community run this task using tools that have been tested
  • Change rollback
  • History removal — Requires high level privileges
  • Rollbacks
  • Data with later history

関連項目

外部リンク