データサイエンティストハトリのブログ

PythonとインテリジェントクラウドとAIが好きな学生エンジニア。データ分析、スクレイピング、就職活動などについて書いていきます。

【webスクレイピングと著作権その②】違法を回避するために書くべきコードを技術的、法律的側面から解説

 f:id:hatorihatorihatorik:20181002154957j:plain


こんにちは、どうもハトリです!!

 

TwitterでプログラミングやIT関連のことについてつぶやいているのでよかったら是非フォローしてください →→(@tori_engineer)

 

 

以前スクレイピングの記事を書いたのですが、じゃあ実際にどうすればいいの?という質問を受け、もっと気になったので早速調べてみました。ちなにみ前回書いた記事はこちら。

 
www.torikun.com


 

今回はこの記事の続きを書いていきたいと思います。

 

前回はスクレイピングはどこまでが違法なのか、どんなことはやってよくて、どんなことはをやっちゃだめなのか、という視点で書いていきましたね。

スクレピングは著作権法不法行為責任、動産侵入法などさまざまな法律とかなり密接に関係しているため、注意しながら使用していくのはかなりめんどくさいし、スクレイピングする規模が大きくなればなるほど犯罪のリスクが高まるため、そんなに気軽にできるものではありませんよね。

 

今回は


じゃあ具体的にどうやってスクレイピングをやれば捕まらなくてすむの?


っていう疑問に答える形で具体例を交えながら解説をしていきたいと思います。そして最後にスクレピング関連の訴訟事例を紹介していきましょう。

 

スクレイピングのコードを実行するときに気をつける3つのこと

f:id:hatorihatorihatorik:20181005020048p:plain

気をつけることはただ一つ!!

 

それは、

 

人間らしくみせること!

 

webサイトにユーザーがアクセスする時に、人間がアクセスする場合と機械がアクセスする場合では全くことなる動きをします。


人間だと1つのサイトを読むのに数秒かかります。ネットサーフィンをしていたらわかるとは思いますが、サイトを読む時ってまずページを読み込む時間とか、表示されたあとでスクロールして文字を読んでいく作業がありますよね。


一方で、機械にやらせると1ページ1秒もかからず読み込んでしまい、その後もすぐに次のページを読み込んでいきます。これは相手のサーバー側が頻繁にアクセスしてくると知れば、対策されてしまいますし、そうすると自分の存在がバレてしまいます。
やりすぎると最悪IPアドレスを特定されてブロックされちゃいます。

 

こういう自体の対策としては、機械を人間っぽくみせる仕組みを付け加えることが必要なんです。次は人間っぽく魅せる技を紹介しましょう。

HTTPヘッダの書き換え

f:id:hatorihatorihatorik:20181005015800p:plain


1つ目の対策法はHTTPヘッダを書き換えるというものです。


通常、webサイトにアクセスするときには、HTTPヘッダというものが必ず送られています。私たちが普通にブラウザからアクセスするときのHTTPヘッダと機械がアクセスしたときのHTTPヘッダはかなり違うものになっています。これを書き換えることにより、人間っぽさを出すことができます。



では早速みてみましょう!
今回は例として、Google Chromeの検証機能を使ってはてなブログにアクセスしたときのHTTPヘッダを確認してみたいと思います。

 

HTTPヘッダの確認に関しては以下のサイトを参考にしてやってみてください。

https://marubon.info/method-confirm-http-header-2345/

 

ここで取得できるあたいは人によって異なってきますが、

 

--> GET / HTTP/1.1

Host: hatenablog.com

Connection: keep-alive

Cache-Control: max-age=0

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/547.36 (KHTML, like Gecko) Chrome

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,
image/webp,image/apng,*/*;q=0.8

Accept-Encoding: gzip, deflate

Accept-Language: ja,en-US;q=0.9,en;q=0.8


 
こんな感じになっているのではないでしょうか?

 

一方でスクレイピングの代表的なモジュールであるurllibを用いてアクセスしたときのHTTPヘッダはこちらです。
 

Accept-Encoding: identity
User-Agent: Python-urllib/3.4

 

 

がっつりurlibと書かれていますね。機械がやってるのはバレバレです。

 

これはまずいです。なので、このHTTPヘッダを書き換えて先ほど普通にアクセスした状態に見せかけます。


Beautifulsoupを使ってpythonスクレイピングを行うときは「requests」という便利なモジュールが用意されています。このrequestsモジュールを使うことでHTTPヘッダの値を書き換えられ、人間がアクセスしたかのようにみせることができます。

 

import requests
from bs4 import BeautifulSoup

session = requests.session()
headers = {“User-Agent”: “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5)"AppleWebKit/537.36 (KHTML, like Gecko) Chrome"
"Accept": "text/html,application/xhtml+xml,application/xml;" "q=0.9,image/webp,image/apng,*/*;q=0.8"}

url = ("http://hatenablog.com/")
req = session.get(url, headers = headers)

 

このようなコードを書くことでHTTPヘッダを書き換えた状態でスクレイピングを行うことができます。

タイミングを工夫する

f:id:hatorihatorihatorik:20181005015744p:plain

スクレイピングをコンピュータの早さに任せてしまうと、とても早いリクエストをサーバーに送り続けてしまいます。

 

ページをクリックしてから次のクリックまでの妥当な秒数は2~3秒くらいだと言われています。なのでそのくらいの間を保ってスクレイピングをしていくことで、相手のサーバーリソースに負荷をかけにくくします。
これはpythonのtimeモジュールを使えば簡単に実装できます。

 

time.sleep(2) #引数には秒数を入れてください

 

たったこの1行を書くだけで犯罪者にならなくてすむので、念のため絶対にやっておきましょう。

ハニーポットに気をつける

ハニーポットとは、webサイト提供者側が、自身のwebサイトをスクレイピングされるのを防ぐために仕掛けるトラップのようなものです。


例えば、はてなブログでログインをしようと思ったとき、メールアドレスとパスワードをフォームに打ち込むことでログインをすることができます。


しかし、私たちの目から見えない隠しフォームというのが存在する可能性があるみたいです。下手に書いたコードだと、自分が作ったスクレイピングツールがこのフォームに入力をしてしまうため、人間ではなく機械がスクレイピングを行なっていることがばれてしまいます。

この隠しフォームのことをハニーポットといいます。

 
f:id:hatorihatorihatorik:20181006121016p:plain





スクレイピング初心者がやるとこの隠しフォームに適当な値を入れて送ってしまうことも多いそうです。フォームは本来値が入ってはいけないことになっているので、値が入った状態で送ってきたユーザーを悪意のあるユーザーとみなしブロックします。

 

膨大なデータの個人情報を扱っているfacebookなどでは、セキュリティ管理がとてもシビアな課題となっているため、このような対策が取られています。

 

対策法は以上です。しかしこれらを全て守っていても犯罪になるケースもあります。過去の事例をしっかりと違法にならないように注意しましょう。

 

スクレイピングと法律(海外の事例)

f:id:hatorihatorihatorik:20181002154949j:plain

eBayとBidder’s Edgeのサーバー負荷問題

Bidder’s Edgeという、日本でいう価格コムのようなビジネスをやっているメタオークションサイトがありました。この会社はいろんなオークションサイトの価格情報を引っ張ってきて、最も価格が安い商品を紹介する、というビジネスをやっていました。

もちろん価格情報をもってくるためにスクレイピングを使用していました。当時、オークションプラットフォーム最大手のeBayという会社は、Bidder’s Edgeからの1日10000以上のアクセスを受けてとても迷惑でした。

 


eBay側もIPアドレスをブロックするなど様々な対策をしたものの、プロキシサーバーを用いて別のIPアドレスを使ってアクセスすることでこれを回避しました。ブロックされるごとに新しいプロキシサーバーを使ってスクレイピングをし続けました。

 

結局Bidder’s Edgeは動産侵入法で訴えられ、金で解決して終わったそうです。

 

参考: eBay v. Bidder's Edge - Wikipedia

AT&Tの情報セキュリティ事例


AT&Tというアメリカ最大手の電話会社があります。Andrew AuernheimerはiPadAT&Tのサイトにアクセスすることで、ユーザーのメールアドレスを集められることを発見しました。


メールアドレスを発見できたという情報をGawker Mediaというメディアに送ったところ、メディアが重大ニュースとして取り上げられてしまいました。
その後Auernheimerはコンピュータアクセス謀議で有罪隣73000ドルの支払いを命じられました。

 

おそらく、個人情報、営業機密、政府機密などの重要なデータはスクレピングできる状況であったとしてもしないほうが安全だと思っています。また、これはAT&Tにセキュリティの脆弱性を通知する前に、メディアに伝えてしまったのが問題だと言われています。


セキュリティの脆弱性を発見した場合でも、メディアに直接報告するのではなく、相手企業のセキュリティ責任者に伝えてあげるほうが賢明のようです。むしろセキュリティの欠陥があったのを教えてくれてありがとう!ってなると思います。!

 

caselaw.findlaw.com

Googleのキャッシュ機能と著作権問題

Gordon Roy Parkerという作家が訴訟を起こした事件です。もともとParkerは、自分の書籍の1章をUsenetの掲示板で公開していました。しかし、あるときにその公開を取りやめたにも関わらず、ウェブサイトの一部を検索結果として表示されており、著作権法違反になるのではないかと訴訟を起こした事件でした。

 

結局Google側が勝訴したようです。他にも似たような事例がありましたが、キャッシュに関しての事例は著作権法違反にはならないようです。

 

 japan.cnet.com