南極にもIPアドレスはある(???)

Posted on

諸事情で国別IPv4アドレスの一覧を眺めていたのですが、なんと南極にもIPアドレスがあるらしいことに気が付きました。その数、256個。北朝鮮でも1024個あるので、それより輪をかけて少ないのですが、そもそも存在するとは思っていませんでした。だって、南極には国という概念はなじまないし…。

調べて見ると、ARIN(主にアメリカのIPを管理しているところ)が南極に割り当てたようです

arin|AQ|ipv4|23.154.160.0|256|20181017|allocated|b2a4180607264562d56fa4cb02fbc9a4

6つ目の要素は、このIPアドレス範囲が2018年10月17日に予約された事を示しているらしい。すんごく最近ですね。

使われているのか調べる

たった256個となると総当りしたくなるよね…ということで、pingで総当りしてみました:

for i in $(seq 0 255); do
  echo -n "23.154.160.${i}: "
  if ping -c 5 23.154.160.${i} > /dev/null 2>&1; then
    echo 'ok'
  else
    echo 'ng'
  fi
done

結果としては、全てのIPに対して、pingは一切通りませんでした。使われてなさそうです。もちろん、pingが通らないからといって使われていないとは限らないのですが。

南極のインターネット事情を想像する

そういえば、南極の観測基地の人たちはどうやってインターネットやってるんでしょう。データセンターおじさんとしては気になる所です。海底ケーブルが敷設されている…わけないですよね。観測基地はたくさんあるけれど、もちろん、都市に比べたらほとんど無人です。とてもじゃないけど、海底ケーブルなんて採算つきませんもん。でも観測データのやりとりや、連絡を考えるとインターネットは繋がってそうな気はします。衛星通信だろうか。

それとも、実は今まで本当にインターネットが使えなかったのが、最近使えるようになったから、割り当てられたのかな。実際に使えるIPアドレスは254個しかありませんから、昭和基地に割り当てられているIPはせいぜい1個だろうか。うーん、NATを使ってなんとかしのぐつもりか?まぁ、対外向けサーバを運用するわけじゃないから、それでもなんとかなるか。

…などと想像するのも楽しいのですが、ためしに検索してみたところ、昭和基地に関してはKDDIの人が毎年1人派遣されてネットワークの維持管理をしているそうです。衛星経由で南極とKDDI山口衛星通信所を3Mbps(3G回線より遅い)で繋いでいて、(観測優先だけど)隊員はLINEもFacebookも使えるそうな。速度はともかく、意外と現代的だ…。構成的には、LINEやFacebookからは日本のIPアドレスとして認識されるのかな。

まぁ、単に登録を間違えただけかもしれない

whoisをIPアドレスに対して行うと、どの団体に割り当てられたのかをチェックすることができます。南極のIPのうちの1つに対してwhoisした結果はこちら:

% whois 23.154.160.100

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2019, American Registry for Internet Numbers, Ltd.
#


NetRange:       23.154.160.0 - 23.154.160.255
CIDR:           23.154.160.0/24
NetName:        ANYCAST-TEST1
NetHandle:      NET-23-154-160-0-1
Parent:         NET23 (NET-23-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       
Organization:   Windscribe (WL-242)
RegDate:        2018-10-17
Updated:        2018-10-17
Ref:            https://rdap.arin.net/registry/ip/23.154.160.0


OrgName:        Windscribe
OrgId:          WL-242
Address:        9251 Yonge St #8901
City:           Richmond Hill
StateProv:      ON
PostalCode:     L4C 9T3
Country:        AQ
RegDate:        2016-03-07
Updated:        2018-12-21
Ref:            https://rdap.arin.net/registry/entity/WL-242


OrgTechHandle: SAKYE-ARIN
OrgTechName:   Sak, Yegor 
OrgTechPhone:  +1-647-725-2536 
OrgTechEmail:  yegor@windscribe.com
OrgTechRef:    https://rdap.arin.net/registry/entity/SAKYE-ARIN

OrgAbuseHandle: ABUSE5829-ARIN
OrgAbuseName:   Abuse Manager
OrgAbusePhone:  +1-647-727-8859 
OrgAbuseEmail:  abuse@windscribe.com
OrgAbuseRef:    https://rdap.arin.net/registry/entity/ABUSE5829-ARIN

「南極」を示す「Country: AQ」以外の部分の住所は、カナダにある「Windscribe Limited」というVPNを提供する会社の住所と一致しています。…だから、まぁ、申請するときに国コードを間違えて、そのまま誰も気づかないままIPアドレスが割り当てられただけかもしれませんね。

…いや?わかりませんよ。ひょっとすると、国家権力に影響されない最強のVPN…データーヘイブン…を実現するために、南極に拠点を作ろうとしているのかもしれません。イギリスのすぐそばにあった、シーランド公国よりは厄介で、そして頼りになるサービスになるかもしれませんね。知らんけど〜


WordPressの検索機能を悪用するSPAMが押し寄せてきてつらい

Posted on

最近、分散SNS「Pleroma」のインスタンスを立ち上げたのですが(マストドンからもリモートフォローできます: @psi@sabbat.hexe.net)、デバッグのために、nginxのログをtail -fで眺めていて気づきました。ここ二週間ほど、このブログの検索結果のページへ対するリクエストが異常なまでにやって来ていることに。しかもUserAgentは検索エンジンです。クロールしている検索エンジンの会社は様々で、よく知らないドイツの会社?の検索エンジンなどからも来ていました。IPアドレスを逆引きした結果を見る限り、どれも本物の検索エンジンと思われます。

そんなに何を熱心に検索しているのやら、と思って、URLをクリックせずにコピーしてdecodeしてみると、謎の韓国語。Google翻訳に入れると、よくわからないけどなにやらアダルトな雰囲気。

もしやと思って、検索結果が出なかったときに表示される”Nothing found”でこのサイト内をしてみると…:

…これは検索エンジンSPAMですねぇ。間違いない。なんだこれは…。たまげたなぁ。

必ずドメイン名が含まれている事、あと翻訳した文章の内容を見る限り、この韓国語のメッセージを見て、何か期待を膨らませた人がドメイン名を手打ちしてアクセスしてくれることを期待しているのでしょうか。いろんなことを考えるなぁ。

書かなくても分かると思いますが、良い子のみんなはこの画像中のドメインにアクセスしてはなりません

たぶん、これらの長い検索クエリが含まれるURLがずらっと並んだページを、業者?の人がどこかに一生懸命つくって、検索エンジンのbotにクロールを指示しているんだと思います。

今年に入ってのリクエストがほぼSPAMでつらい

% cat access.log | grep "GET https://7io.org\(/?s=\|/search/\)" | wc -l 
1989392
% cat access.log | grep "GET https://7io.org/" | wc -l 
2355234

今年に入ってから処理している235万件ほどリクエストのうち、この検索結果へのリクエスト(ほとんどがこのSPAMだと思われる)は198万件。せっかくCPUをぶん回してリクエストを処理しても84%がSPAMとな。ビットコインのマイニングより虚しいCPUの使い方なんじゃないか。

検索エンジンにインデックスしないようにお願いした

とりあえず、使っているテーマのhead.phpに、検索結果に関してはインデックスしないようにお願いするmetaタグを書きました

でも、これは対症療法にすぎません。検索結果は汚染されなくなりますが、クロールのリクエストは際限なく飛び続けるでしょう(検索エンジンの裏にいる「AI」ってやつがよしなに判断して、アクセスする前に止めてくれるようになる可能性は、無いとは言えませんが)。SPAMをやってる人たちがいつかインデックスされない事に気づいてくれたら止むかもしれませんが、それを期待するのは違和感があります。かといって、検索エンジンを全部ブロックするのもおかしいし。

どうしたもんか。

もはやDOS攻撃に近い

いまのサーバはそれなりの性能があるからあんまり困っていませんけど1、もしラズベリーパイとか、昔使ってた玄箱のような非力な自宅サーバだったら間違いなくCPUのリソースを使い切っていたに違いない。こんなん実質DOS攻撃やんけ

なんとなく、UDP Amplification攻撃にも似ています。UDP Amplification攻撃では、攻撃者はIPアドレスを隠しつつ様々なサーバに元の数倍のトラフィックを流すことが可能なわけですが、このSPAMもどこの誰なのかを隠しつつ様々な検索エンジンを動員して膨大なHTTPリクエストを発生させています。UDP Amplification攻撃と同じように、パケット自体は第三者からやってくるのでブロックするわけにもいかないし、するにしてもキリがない、という点でも似ています。もちろん、本物のDOS攻撃と違ってサーバがダウンしたらSPAMをやってる人たちは目的が達成できなくなるわけですが、まぁダウンしたらその人たちは別のブログで同じような事やるだけですよね、きっと。

インターネット…どうしてこんな事に…

かなしい

2019/03/16 追記

robots.txtに検索ページのURLのパターンを記載することで、検索エンジンからの無意味なアクセスはなくなりました。ページ毎の指定だと一回はやってくるわけですが、この方法ならロボットはアクセスする前に判断してくれるようです。

User-agent: *
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /search/*
Disallow: /*.php$
Disallow: /*?*
Disallow: /*?

 

  1. うそ。nginxのログが肥大化するのでちょっとだけ困ってます。消すからいいけど。 []

HTTPSをやめたらChromeから接続できなくなった話

Posted on

ブンブンハロー、はいどーも。

HTTPSからHTTPへ

最近、わたしと友達がやっている、妖精⊸ロケット(hexe.net)というウェブサイトをHTTPSからHTTPへ移行しました。HTTPSへの移行ではなく、HTTPへの移行です。暗号化するのを、やめました。

んん??時代に逆行しているような気がしますな。Let’s encryptで無料のSSL証明書が簡単に手に入る時代だというのに、お前は一体なにをやっているんだ!

実をいうとHTTPSにも対応してます。HTTPにリダイレクトするけどな!

「保護されていない通信」ですが、何か?

常時https化が叫ばれて久しいですね!

…たったそれだけの理由で、このサイトも含めてなんとなく流されてHTTPSに対応していましたが、…これ、本当に必要なんでしょうか?

そもそも、一体HTTPSで何を保護しているというのか。わたしたちのウェブサイトには公開鍵で署名をしないといけないような、誰が書いたか(あるいは、書いていないか)が極めて重要な、そんなソーシャルな内容はありません。ついでに、このサイトは等しく公衆に公開されているものですから、盗聴されても困らないはずです。まぁ、パケット書き換えられて勝手に改竄されるのは嫌ですけど。でも、ソーシャルな内容でもないのに、わざわざ改竄する人なんか、いるのだろうか?

っていうか、実は常時HTTPSなんかしてもしょうがないから「検索エンジンでの検索結果の順位を上げます(SEOのためにHTTPS対応してね!)」とかいってHTTPSにするモチベーション作ってるんじゃないの。

疑い始めると止まらない!

うぉー、人間が憎い!

「信用できるHTTPSを売りつけてくる人間」が信用できない!

…というわけでHTTPSからHTTPにしてみました。

なぜかChromeでアクセスできない(Firefoxはできる)

設定自体は簡単です。表のnginxが、裏はgoで書かれたバックエンドに対してリバースプロキシしているという構成なので、表のnginxの設定をHTTPとHTTPSでごそっと入れ替えるだけです。

これで際限なく暗号化する潔癖症から逃れられたと思ったのもつかの間。いつも使っているFirefoxでは何の問題もなくHTTPでも表示できたのですが、Chromeでhexe.netを開いてみるとなぜか全く表示されないことに気づきました:

HTTPの方を開いても、勝手にHTTPSへなぜかリダイレクトされてしまいます。サーバはHTTPへリダイレクトし返すので、そこで堂々巡りが発生して「リダイレクトが繰り返し行われました」となってしまったようです。

元々は301でHTTPからHTTPSへ投げていたわけだから、それがChromeのキャッシュに残っていたのだろうか?と思って消してみても、効果はありませんでした。

開発者ツールの「ネットワーク」で確認してみると、301ではなくて「307 Internal Redirect」だそうな:

な、なんじゃそりゃ。307はTemporary Redirectだったはずですが…。そしてもちろん、サーバーでは307を返す設定なんかしていません。

HSTSってのが悪いのか?

そこで思い至ったのがヘッダに書かれているHSTS、一度HTTPで繋いだ時に、次以降は常にHTTPSを利用するよう要請できるという機能でした。HSTSを設定した覚えは一切ないんですが、ひょっとすると、ほら、まぁ、ね、nginxの設定をコピペし間違えるなどして昔設定したことが無いとは言えない…じゃん?

chrome://net-internals/#hstsからHSTSの設定キャッシュは削除できるはずなのですが、やはり効果はありませんでした。変だなぁと思いながら状態を確認してみると:

dynamicなんとかとstaticなんとかの値があって、staticの方にだけ意味のありそうな値が入ってます。ん…static…?

と思って調べていくと、HSTS Preload Listというものに突き当たりました。

ChromeとFirefoxで中身が違うHSTS Preload List

HSTSを指定する方法には、HTTPリクエストへ対するレスポンスのヘッダで指定する方法の他、HSTS Preloadingという方法もあるそうです。

HTTPで最初に接続した時にHSTSを要請する方法の場合、その定義から初回のリクエストは安全でないHTTPで通信しなければなりません。この初回時に改竄でもされたらオシマイです。そこでHSTS Preload Listの出番なのであります。HSTS Preload List Submissionというサイトに「わたしのサイトはHSTSに対応していますよ」と登録しておくと、なんとブラウザの中にその情報が書き込まれて、最初から安全なTLSで通信できるようになりますよ…と。段々宣伝みたいになってきたのでこの辺でやめておきますが、HSTSのRFCの著者の1人がGoogleの中の人なこと、HSTS Preload List Submissionもいかにも「公共」な雰囲気を纏ってはいますがChromium(実質Google)がやってることは指摘しておきましょう。

ここで登録されたリストは最終的に週一の頻度Chromiumのコードに反映されるようです。見てみると…:

ありました。ここでHSTSが有効とマークされているせいで、ブラウザ側でhttpからhttpsへの自動リダイレクトが行われているのでしょう。原因がわかってすっきり。…身に覚えがないけど…。

git blameしまくった結果、この行は2016年11月18日のコミットで追加されたことがわかりました。その時はまだhexe.netは持って無かった気がするので、前の持ち主の人が設定したのかもしれません。前にも使われていた事があるような短いドメイン名はこういう事もあるのでしょう…。

さて、上記のHSTS Preload List SubmissionのサイトではFirefoxでも使われていると書いてありますが、Firefoxのソースコードを参照する限り、hexe.netは入っていません。これで、FirefoxからはHTTPでも見れることが説明できました。…でも、なんで入ってないんでしょう?管理系統が別なんでしょうか。Mozillaのページには特に説明はなく、コミットが3日おきくらいに粛々となされているのは分かるのですが、この変更のソースがどこから来ているのかはコードレビューを見てもよくわかりませんでいた。コードは読めても社会がわからーーーーん!

HSTS Preload ListはWeb標準じゃないけど、Chromeのシェアは大きいから…

このHSTS Preload Listなんですが、Mozillaのページに書いてあるとおり、実はRFCとかW3C勧告のようなWeb標準ではなく、各々のブラウザが勝手に実装したりしていなかったりする「独自拡張」にすぎません。

ところで、こんなニュースがあります:

グーグル、完全HTTPS接続で安全なアプリ用ドメイン「.app」–早期登録を受付開始 – CNET Japan

.appドメインは、アプリ開発者のウェブ運営向けとして用意するTLD。例えば、「アプリ名.app」「開発者名.app」「開発会社名.app」といったURLでアプリの最新情報やダウンロード用リンク、アプリ内コンテンツなどを提供すれば、ユーザーに覚えてもらいやすい、といったメリットがあるという。

最大の特徴は、.appドメインのウェブサイトが必ずHTTPS接続となること。個別にHSTSなどの設定をする必要がなく、.appドメイン内のサイトは自動的にすべてHTTPS接続される。これにより、アクセスするユーザーの安全を手間なく確保できる。

このニュースに対応するように、Chromeの方でもFirefoxの方でも”app”というエントリが含まれています:

Chrome

# https://cs.chromium.org/codesearch/f/chromium/src/net/http/transport_security_state_static.json?cl=0193585e14d2baf5c9ae96a767c532a13973b011

    // gTLDs and eTLDs are welcome to preload if they are interested.
    { "name": "android", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    { "name": "app", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    { "name": "bank", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    { "name": "chrome", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    { "name": "dev", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    { "name": "foo", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    { "name": "gle", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    { "name": "google", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true, "pins": "google" },
    { "name": "insurance", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    { "name": "new", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    { "name": "page", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    { "name": "play", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    { "name": "youtube", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },

Firefox

# https://hg.mozilla.org/mozilla-central/file/4d15e90af575/security/manager/ssl/nsSTSPreloadList.inc#l3893

...
apothes.is, 1
app, 1
app-at.work, 1
...

ソースコードは非公開だけどInternet ExplorerとかEdgeとかSafariとかでも似たような設定がされてるでしょう。きっと、たぶん。そうにちがいない。

curlではHTTPでアクセスできるけどきっとこれは何かの間違いでしょう:

% curl -vvv get.app
*   Trying 216.239.32.29...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0xe52310)
* Connected to get.app (216.239.32.29) port 80 (#0)
> GET / HTTP/1.1
> Host: get.app
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 302 Found
< Location: https://get.app/
< Cache-Control: private
< Content-Type: text/html; charset=UTF-8
< X-Content-Type-Options: nosniff
< Date: Wed, 13 Mar 2019 03:26:39 GMT
< Server: sffe
< Content-Length: 213
< X-XSS-Protection: 1; mode=block
< 
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="https://get.app/">here</A>.
</BODY></HTML>
* Connection #0 to host get.app left intact

…うーん、なんか胡散臭いと感じてしまう。

今後どうしようか

  • HSTS Preload List SubmissionRemoval formから削除してもらう
    • 数カ月後のChromeのリリースで、たぶん接続できるようになる
  • HTTPSに戻す
  • すべてを放置し、Chromeからは接続できないウェブサイトを運営していく(自称ダークウェブ)

一番最後でも、良いかなぁ。それぐらいで、ちょうどいいのかもしれない。「地獄少女」みたいで面白くない?(どうかな…)

GoogleのクローラーはHSTS Preload Listを使っていない

ちなみに、GoogleのクローラーはたぶんHeadless Chromeを動かしているけれど、HSTS Preload Listは使っていないと思います。

なんでそんなことが分かるのかというと、次の検索結果からです:

この「WebGL not supported.」はJSを実行した結果DOMに追加される文字列なので、おそらくクローラーはHeadless Chromeを動かしていると思われます。が、このメッセージが出せるということはリダイレクト地獄に陥いっていないということなので、HSTS Preload Listは使ってないと思われます。…ってことは検索結果は改竄されてるかもしれないって事だな!(?)

you can also see


世界で一番美しい容姿の美少女Vtuberおじさん

Posted on

はいどうもー。
世界で一番美しい容姿の
美少女
Vtuber
おじさん
ナニモ・ナイでーす。

えー。あのぉ、
よく知らないんですけど最近vtuberというのが流行ってるらしくてですね、
かわいい少女とか少年の絵とかCGに声を当てて喋る遊びらしいんですよ。

でー、まぁ、人の仔…?
人間はそういうの(かわいい少女とか)見ると「世界一」とか「ナンバーワン」を決めたくなるじゃないですか。

ミスユニバース、みたいな? アイドル総選挙、とか。

でも、でもですよ。

人間の容姿ってやっぱり人によって趣味が違うからNo.1とか決められないと思うんですよね。

美少女にしたって、俺はロリコンだー、とか、俺はボンキュボンが良いとか、
そもそも俺は少年の方が好きだ、とか、女装がいいとか。

キリがない。そうキリが無いわけですよ。

そこで、そこでですよ、

真っ暗なスタジオで収録してるって設定にして画面を真っ黒にしておいたので、
こう、各々の視聴者のみなさんに自分の一番好きな容姿を思い描いてもらおうかなと。

あの、声と容姿は一致していないっていうのは暗黙の了解になっていると思うので、声はそのままでいいのかなと。

キャラクター設定も人によって理想は違うし、正直考えるのも面倒くさいので自分で考えてもらえればなと。

どんな事をやってどんな番組コンテンツを配信してもらいたいかも人によって違うと思うので、
これから次の、2回目以降の配信もみなさんの想像に任せようかなと。

それではーまた。
世界で一番美しい容姿の
美少女
Vtuber
おじさん

世界で一番面白くて刺激的で扇情的な配信を次回からお楽しみに。

ナニモ・ナイでしたー。

動画の生成について

真っ黒なbg.png(640×360)を用意してから、

ffmpeg -loop 1 -i bg.png -i input.wav -c:v libx264 -pix_fmt yuv420p -profile:v baseline -level 3 -tune stillimage -acodec aac -b:a 128k -shortest tmp.mp4
ffmpeg -i tmp.mp4 -c:v libx264 -preset slow -crf 22 -pix_fmt yuv420p -c:a copy nanimo-nai.mp4

二行目が無いとFirefoxで上手く読み込めませんでした。

参考:


美少女をランダムウォークで生成し続けた

Posted on

make.girls.moeは、ブラウザ上のニューラルネットワークを使って美少女を生成してくれるサービスです。すこし内部に立ち入ると、このネットワークは、162次元の実数ベクトルを受け取って、128×128の「美少女」の画像を返すことに気がつきます。今回は、そのベクトルの「ゼロ点(全要素がゼロ)」からちょっとずつランダムに動かしながら生成し続けた、40人の「美少女」の動画を作りました。

github repo


make.girls.moeで10回ぐらい「美少女ガチャ」を回してみると、いわゆる「絵を描く」という行為とはすこし雰囲気が違うと感じました。

それを言葉で説明するのはまぁ置いておくとして、「機械が美少女を生成する行為」と「人間が絵を描く行為」が違うとして、機械ででしか出来ないことはなんだろうか、と考えてみました。

このニューラルネットワークの上では、「美少女」は162次元のベクトルです。

ベクトルであるということは、ある「美少女」AとBが与えられた時に、それらを使っていろいろな演算が出来るということです。例えば、C = αA + (1-α)Bとすれば、美少女AとBをα:1-αで「混ぜ」た新しい美少女Cができますね1。これはαを変数として見ると美少女AとBの間に直線を引いて、その間にいる無数の「美少女」を「生成」する、あるいは美少女を「連続的に変化させる2」式ですが、直線じゃなくても、色々な曲線を引いて、その間にある美少女を「連続的に変化」させて「生成」することもできるでしょう。

でも、「美少女を混ぜる」ことだったら人間でも出来ます。「ベクトル空間上の美少女」を混ぜるための方法が直線だけではなくたくさんあるのと同じように、例えば「髪は涼風青葉だけど目と口は八神コウ」とか。「数学的に混ぜている」わけではありませんが、描こうと思えば色々な「混ぜ方」で描けそうな気がします。ですから、「人間は出来ないけど、機械なら出来る」という感じはあんまりしません。

じゃあ、こんなのはどうでしょう。遠くはなれた他の点だけでなく、ベクトル空間では、ある点のすぐ近くに、無数の他の点が存在します。美少女の世界で言えば、ある美少女の近くに、無数の、よく似た、しかし相異なる3「美少女」が存在すると言うことになるでしょう。これも、一見人間とよく似ている気がします。以前、犬吠埼樹ちゃんを50人描いた事がありましたが、同じ樹ちゃんではあるものの、描かれた樹ちゃんは間違いなく全員異なる姿をしていました。なんか近い感じがします。

しかし、ランダムウォークはどうでしょうか。ランダムウォークは、ある点のすぐ近くの点に、きまぐれな散歩のようにどんどん移動する運動です。

一次元空間と二次元空間では、ランダムウォークには再帰性があって、「いつかは元居た所に帰ってくる」らしいです。まぁ、「いつか」だから、「一億年後」かもしれないけど。これは、全然意味は違いますが、人間のやっていることに近い感じがします。様々な試行錯誤をして異なる美少女の絵を描きながらも、「樹ちゃん」という目標はあり、そこの近くをぐるぐる行ったり来たりしている。そんな感じがしました。

でも、三次元以上のランダムウォークには、再帰性はないそうなのです。運が良ければ元のところに戻ってくるかもしれないけど、普通はもう二度と戻ってきません。そして、その行き先は、まったくのランダム。これは人間には、たぶん難しい。オリジナルのキャラクターを描くとしても、何回も試行錯誤しながら描いてる最中に「こっちがよさそう」と思いながらなんとなく方向転換をしていくわけで、まったくのランダムな方角へ進みながら、よく似た、でもまったく別の絵を描き続けることは、たぶん難しい。でもコンピュータなら簡単です

というわけで、冒頭の動画では全く同じところから出発した、40人の「美少女」を並べました。


@0枚目

これがmake.girls.moeが定義する「美少女」の「ゼロ点」です。なんとなく「無個性」な感じするかな。そうそう、162次元中、いわゆる「属性」34次元で、残りは「ノイズ」らしいよ。個性は、ノイズ。

それぞれの美少女はすぐに異なる美少女へ「変化」していきますが、そこでとどまることなく、常に変化をし続けていきます。

@36000枚目

@60000枚目

@72000枚目

まぁ、雲みたいな感じかな。じっと眺めていると同じだけど、気がつくと変わってる。


FAQ

有用性は?

知るか。

新規性は?

お前が新しいと思った所があればあるし、なければない。

ところで「新規性のある美少女」は、居るとすればこのニューラルネットワークの中と外、どっちに居ると思いますか。


(→別の紹介

  1. 本当に「混ぜた」ことになっているかはわかりませんが、そもそも「美少女の演算」ってよくわかんないですし []
  2. ネットワークの定義見てないしそもそも比喩的な意味でしかないけど、数学的にもback propergationしないといけないからネットワーク全体を関数として見た時にも連続だよ…ね…? []
  3. 厳密に単射かどうかはわかりません []

#クソポンチ絵forまんがタイムきらら を集合知で描いてる話、あと架空のまんがタイムきらら

Posted on

open-dokidokivisual.com

きららのクソポンチ絵で社会貢献!

2020までに”きららシンギュラリティ“達成へ

公式ハッシュタグ

#クソポンチ絵forまんがタイムきらら

あと一応、初期の属人性があった頃のモーメント

昔の

過去→

現在→そして子供たちに残したい未来の「きらら」へ

今期のきららアニメ面白い

今期のきららアニメ、「甘くて白い綿の花」めっちゃ面白くないですか?南北戦争時代のアメリカ南部のプランテーションで働く黒人奴隷のおんなのこ4人が主人公という設定はかなり攻めてるなと感じましたけど、「あぁ、奴隷にだって『日常』はあったんだよな」という当たり前のことを思い出させてくれて、それがまた儚くて、キラキラしてて。学校で学ぶ歴史とはまた少し違った当時のリアルな生活と、その中での「まんがタイムきらら」が織り交ぜられていて、時間を行き来しているような、そんな気持ちになります。

主人公の女の子たちの一人の子が持っている幽霊のぬいぐるみは「うらら」のマツコさんよりも輪を掛けて可愛くないし喋れもしない本当のぬいぐるみなのですが、話数を重ねるにつれ持ち主の子と大事な友情を育んでいることが分かるので、可愛いなと感じるようになってきました。わたしにも見えない友達が居るので、すごく共感します。誰にも見えなくても、大切な友達は大切な友達なんですよね。

コミックス版の煽りは「褐色多めでお送りします!」なだけあって「褐色フェチ」成分が多くてすこしセクシャルな感じはするのですが、まぁそれも「きらら」のいち側面に収まる範囲なので、わたしは許容できています。実のところ、ヌードデッサンの題材にさせてもらっています。リアルとアニメのバランスがいいですし、現実の裸はちょっと苦手なので重宝しています。

ぞいぞいぞい!

今日も一日がんばるぞい!

日曜日は物足りないぞい!

働いたら働いたぶん
本当の自分になれるんだぞい!



「※希望はありません」の誕生を観察してみよう

Posted on
がっこうぐらし!のOPのフレーズ「ここには夢がちゃんとある」の時に起こる弾幕、「※希望はありません」がどういうふうに生まれてきたのか、観察してみました。

ニコニコ動画の弾幕は歌詞の内容を元にした「空耳」であることが多く、歌詞には直接出てこないフレーズであるこの弾幕は面白い存在だと思います。

これは今日やったハッカソンでやったことのまとめで、使ったソースコードとデータ一式はこちらにあります

方法

  • 配信開始から一週間分の過去ログを集める
  • 「夢」「希望」(わかば*ガールば「鳴」)の少なくとも一方が含まれるコメントを抽出
  • 正規化されたレーベンシュタイン距離を使って適当にクラスタリング
    • 似ているコメント同士でも1000コメント以上離れたコメントは別グループに分け、グループ同士をエッジで接続しました。
    • 書かれているコメントを真似して書くコメントと、独立に思いついて偶然にたコメントを区別するためです。
  • 時系列にまとめて図に書く
    • デカいグループ(結果として「※希望はありません」になる)を真ん中に書く
    • そのグループに近い順に周辺に配置する

結果

1話

観察

  • かなり初期(No3326)に「※希望はありません」が出現
    • ほぼ同時期に「夢はあるけど希望はない」「※希望はない」も出現
  • 「※希望はありません」は最初からヒットした訳ではなく、一回目はそのままフォロワが無く消滅。
    • 2万コメント後に復活して細々続き、4日目にしてなぜか大ヒット。
    • 一旦少なくなるタイミングもある
      • コメントは1000件のキューであることを考えると、待ち行列的な混雑の揺らぎみたいなものだと考えていいのだろうか?
  • 初期は「夢がちゃんとある(〜とは言ってない)」のような従来的な歌詞に基づいたコメントが多い
    • その後も継続的に出現するが、「※希望はありません」と比べると相対的に弱くなる
  • 「※ただし希望は無い」などの派生系コメントは本家のヒット後に出現
    • しかしフォロワーはなく消え、暫くたつとまた似たような「※(希望と救いは)ないです」みたいなのが発生してくる。たぶん独立に何度も発生してる。
    • おなじ「まんがタイムきらら」作品が元ネタの「夢もキボーもありゃしない」系コメントも独立に散発的に出現している

なぜ4日目に大ヒットしたのか?

よく見ると4日目、07/12はGoogleTrendでの最大ピークと一致している。

SNSを見て検索して大量に流入したバズ志向の新規視聴者がこの弾幕でお祭り的に盛り上がろうとしたのが 大ヒットの原因であるという憶測はできるが、これだけでは証拠が弱すぎる。単なる偶然かもしれない。

2話

  • 一話の流行を受けて「※希望はありません」は最初から大人気

おまけ

「わかば*ガール」1話

わかば*ガールの今季一番アレな弾幕「TNP鳴らして」も調べました。

  • こちらです

  • 初期は「GONG鳴らして」、ないし素直に「ピンポン鳴らして」
  • 猛烈に書かれている瞬間があるが、よく見ると連投回避のためにちょっと文字変えてるのが固まってる
    • 実はクソ下品な弾幕書いてるのは極一部の人間だけだった説
    • 弾幕へ面白おかしく反応するコメントが「※」に比べて目立つのも気になる

ニコニコ動画のタグネットワークをリアルタイムに可視化する

Posted on

巨大なグラフ1を階層的に纏め上げてくれるLouvain Method(Blondel, et al. [2008])というアルゴリズムの論文と、これをリアルタイム可視化に用いている(Praneenararat et al.[2011])論文を発見して、面白そうだなぁと思ったので(小学生並みの感想)、ニコニコデータセットに適応してやってみました。

明日、日曜日(4/26)に「ニコニコ超会議」内の「ニコつく」でサークルの一つとして展示します。I19です。

デモサイトはこちら

(2018/04/24: メモリの圧がキツいので終了しました)

ネットワーク・クラスタリング

ニコニコ動画へのタグって、ふつう「アニメ, 遊戯王, この虫野郎」みたいな感じで相互に関連するタグが付けられますよね。

このタグ同士の関連をネットワークとして可視化したら、ニコニコ動画の中でどんな概念同士がリンクしてるのかなー、とか、詳しくないジャンル2でどんなワードが流行っているのかなー、とかが一目で把握できそうです。

というわけで、今回はタグを頂点、辺を 「同じ動画に付けられている回数(共起回数)」としたグラフ(ネットワーク図)を作り、可視化してみました。

20140424_02

それだけ?って感じかもしれませんが、実はグラフをそのまま表示しただけでは頂点も辺も数が多すぎて人間には解釈不能な「Hair-ball graph(髪の毛もじゃもじゃグラフ)」になってしまいます。たとえば、ノードが1万4000のグラフを可視化した結果がこんな感じだそうです

20150425_01

うーむ、とてもじゃないけど、人間には読めない図です。今回は15万タグを対象としたので、この10倍ほどの頂点とエッジがあります。

この問題に対処するために、可視化する前にタグを階層的にまとめるクラスタリングを行います。たとえば、「ぽいぽい教」や「金剛」タグをまとめて「艦隊これくしょん」クラスタを作り、さらに「艦隊これくしょん」と「ご注文はうさぎですか?」や「きんいろモザイク」とまとめて「アニメ」クラスタを作るわけです。その状態で可視化を行えば、先ほどの図のように「ゲーム」「音楽」「アニメ」みたいなざっくりとした関係の図が出来上がります。

もちろん、その纏めた「アニメ」クラスターの中身もダブルクリックすれば見ることができます。ニコニコデータセットはそこまで最近のデータはないので、例として2011年データから「IS(インフィニットストラトス)」のクラスタを持ってきました。

20150424_03

わたし自身はこのアニメを見てないのであまり詳しくないのですが、一時期エースコンバットとのMADが流行っていたのと、(キャラ名)党っていうタグでお気に入りのキャラクタを示す文化があるのがわかります。

今回の売りは、この集計を「その場」で行っていることです。従来でもさいころ [2013], tasukuchan [2009]など可視化は行われているのですが、基本的には「事前に」集計しておいて、それを可視化しています。しかし今回のシステムでは、表示するたびに毎回、15万ノード+200万エッジの大規模なグラフを、クラスタリングしつつその場で可視化してしまいます。かかる時間はさくらのVPS2Gのような非力なマシン1台でも2秒以下です。

今回これをやった本心としては「データの分析をして知識をマイニングしたい!」とかよりは「この超高速なクラスタリングアルゴリズムを使ってみたかった」という感じなので、実際にこのソフトウェアから有益な知識が得られるかどうかは微妙です。客観的評価とかもとくにしてないし、まぁそのへんはご愛嬌。

タグネットワークで時間旅行

今回のシステムのもう一つの売りは、高速性を活かしてインタラクティブに集計期間を変更して好きな時期のデータをその場で可視化できることです。

上のバーを左右に動かすことで、時間を行き来しながらネットワークの様子を可視化できます3

初音ミクの居ない頃のニコニコ動画

たとえば、初音ミクはニコニコ動画文化を象徴するものだと言っていいと思うのですが、できた当時の2007年すぐには初音ミクはありません。なので、2007年の最初期のデータで可視化すると初音ミクがなかったころのニコニコ動画が見えます。

20150424_04

最近はもう見なくなったものもちらほらありますが4、今でも人気な作品も多いですね。「涼宮ハルヒの憂鬱」はアニメなのにアニメクラスタに入っていませんが、このような人気な作品はそれ自体が大きなコミュニティを形成しているので、独立して一個のクラスタになることがよくあります。また「ヘタリア」みたいな腐女子向け作品がちょくちょく独立してますが、腐女子向け作品は「アニメ」「ゲーム」タグと同時につかない動画が多いのが原因みたいです。

2011年3月

時間を行き来しながら見ると、時事ニュースによるその時の流行タグも自然と浮上してきます。たとえば、2011年4月の画面を見てみましょう。

20150424_05

右下のほうに「東北地方太平洋沖地震」とありますね。一ヶ月弱前にあった地震を扱った動画がたくさん投稿されていたことがわかります。ちなみに中はほとんど政治的な動画で、みんな大好き「あいさつの魔法。」は「エンターテインメント」の中に入ってます。ただいマンボウ。

20150424_06

 

昔の流行の思い出に浸るもよし、新規ジャンル開拓に使うもよし、まぁなんか暇つぶしにご活用ください。

「超大規模なグラフをその場で可視化して仮説発見に役立てる」というのはPraneenararat et al.[2011]. が元ネタです。彼らはバイオインフォマティクスで日々生まれる膨大なデータを素早く可視化するために使っていますが、これをニコニコ動画に適応したらどうなるかなーと考えた所、こんな感じになりました。

ソースコード

ソースコードはこちらに置いてあります。

結果を再現するためのプログラムが全部置いてあるので、あなたも自分のサーバで動かすことができます。データはNIIのサイトからダウンロードしてきてください。

また、クラスタリングアルゴリズムであるLouvain Methodの実装はゼロから書き起こした物を使っています。元の実装よりも少し制限がキツい(エッジの重みがintのみ)いのですが、その分だけ頑張って高速化して、だいたい3倍ぐらい速いです。

現状の問題点

  • 多くのタグを一度にまとめてしまって、部分的に一部のクラスタ以下がHair-ballになって破綻することが稀によくあります。
  • 実装がマルチスレッドになってないので本当に何人も同時にアクセスするとサーバが沈黙します。優しくしてあげてください。

  • !データがいまいち古い!
    ドワンゴ氏〜〜〜〜
    最新のデータくだされ〜〜〜〜〜〜〜〜〜

他のデータでもやってみたい?

もしも、「ニコニコデータセットじゃなくてウチのデータセットでもやってみたいんだけど…」という方が居た場合はご相談ください。本当に有益な情報をマイニングしようとするとここから更に何段階か努力しないといけないとおもいますが…。

  1. 頂点と辺からなる方 []
  2. わたしは鉄道とか全くわからない []
  3. 集計に使う長さは約二週間分 []
  4. ひぐらしのなく頃にとかね… []

JSによるcrypt関数の実装

Posted on

だいぶ前にJSで実装したcrypt関数を紹介します。crypt関数はパスワードを暗号化するための関数です。

char *crypt(const char *key, const char *salt);

Perlではビルトインで使えます。実際に使ってみるとこんな感じです。keyは8文字(8 bytes)まで、saltには2文字(2 bytes)までしか使えません。

% perl -e "print(crypt('Hello', 'wl'))"
 wlCoUbJ6h11vY

saltとkey、どちらが変わっても出力結果が変わります。パスワード認証をするときはユーザーのパスワードをそのまま保存するのではなく、このような関数でハッシュにしてから保存しなさいというのはよく言われていますが、さらにその際にユーザーの入力をそのままハッシュに掛けるとハッシュ表が盗まれた時にレインボー攻撃と呼ばれる攻撃ができてしまうので、keyにユーザーごとに異なるsalt(塩)も加えてからハッシュにかける…というのが典型的な使い方です(受け売りです)。

2chのトリップはこのcrypt関数を使っており、この(ledyba.org)サイトに設置してあったCGI「2chトリップ生成システム」をCGIからJSへ移植するために必要になったので書いたというわけです。

Apacheから流行りのnginxに移行したのですが、nginxではCGIを動かすのがかなり面倒臭くなっており、JSで書きなおすのが一番楽そうだったのでそうしました。Public DomainのcryptのCでの実装があったので、それをほぼそのまま移植しています。

ただし、暗号は理論だけでなく実装も注意深く行う必要があり、たとえばキーによって処理時間が変わるような実装だとその差を使ったタイミング攻撃ができたりします。 この実装は私が適当に作ったものなので、2chのトリップのようなどうでもいいアプリならともかく、実際に暗号に用いる場合はもっと有名で枯れた実装を使うのをお勧めします。