南極にも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で上手く読み込めませんでした。

参考:


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

Posted on

open-dokidokivisual.com

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

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

公式ハッシュタグ

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

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

昔の

過去→

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

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

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

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

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

ぞいぞいぞい!

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

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

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


トリビア:Google+アカウントにアップデートするときは気をつけないと全データが全部飛ぶ

Posted on

 泣きたい

 GoogleのGoogle+へのプッシュ具合は最近すごいですよね。今までほとんどGoogle+はつかっていなかったのですが、最近必要にせまられたので登録してみました。

 Google+ができてしばらくたってからのアカウントでは、gmailのアカウントでもPicasaのアカウントでも登録時にGoogle+にも一緒に登録することが必要になっていますが、比較的昔から使っているアカウントの場合には、Google+へ追加で登録を行う(Google曰く「アップデート」)ことになっています。

 今回、ふるいgmailアカウントをGoogle+にアップデートしようとしたら悲しい自体になったので周知徹底等させて頂きたく存じ上げます(敬語)

 Google+の登録時の画面で、性別と年齢を入れるわけですが…

20120711_01.png

 はまちちゃんも実名だけはやめとくよう言うし、私も実際その通りだと思うので、年齢も性別も毎度適当に入れています。で、今回は歌詞になってて覚えやすい鉄腕アトムの誕生日を入れて登録してみたのですが…

20120711_02.png

 …ん?

 20120711_03.png

 なん…だと…10年間分のメール…が…

 どうやら13歳以上じゃないと使えない、ということらしいです。小学生はgmailを使ってお友達とメールすることができないらしい!です。うーん、リアル小学生のときyahoo!mailもhotmailも取ったような気がするのですが…。Google先生は厳しいですね。Google社内にスーパー小学生エンジニアとか居ないのかしらん(ぉ

 Googleに身分証明書を送付するなどすれば解除と削除回避は可能だそうですが、Googleにそこまで個人情報を教える気にはどうしてもなれませんし、そもそも偽名だし…であきらめるしかなさそうです。規約上たぶん本名を入れることになってると思うので、私の自業自得ではあるのですが…悲しい。

 そういえば上の画像だと「波動関数 ぷさい」ですが、最初これははじかれました。Google+の命名ルールに従っていない、もっというと「本名じゃないでしょそれ」と言われてしまいました。でも昨今の「DQNネーム」とやらを見てると、これぐらい変わった名前の人がいてもおかしくないと思うのだけど…Googleに身分証明書送らないとアカウント作らせて貰えないのかな??そこまでしてやるもんんかなあ?

 ファーストサーバの中の人の気持ちがわかった気がします


HTTP1.1のLocationヘッダは、絶対URLでないとRFC違反

Posted on

さきゅばす2のバグ対処で知ったお話です。とりあえず、HTTPの基礎知識はあることを前提にします。

さきゅばす2では、公式動画のDLがどうしても出来ませんでした。こんなエラーが出ちゃうんです。

[E][    PyBridgeImpl] Python says:
(略)
HTTPError: HTTP Error 302: Found - Redirection to url '/watch/1339405721' is not allowed

どうやらリダイレクションの段階で問題が発生してるみたいですねぇ。

HTTPでのリダイレクション

とあるページにアクセスした時に他のページにジャンプしなおさせる「リダイレクション」ですが、このリダレクションはHTTPはレスポンスヘッダで301,302,303,307のレスポンスコードを返した上で、Locationヘッダを設定することで実現しています。

どこかのページのレスポンスヘッダで、

Location: http://www.google.com/

こういうふうなヘッダを返すと、そのページにアクセスした人がGoogleに無条件で飛ばされるわけですね。

で、ニコニコ動画のリダイレクションでは、

Location: /watch/1339405721

となっていて、http://www.nicovideo.jp/watch/1339405721 にジャンプするようになっていました。うーん、特に問題なさそう。

Locationヘッダは絶対パスしか認められない。

…ところがどっこい、実はLocationヘッダのURLは絶対パスしか認められないのです。RFC見ましょうか。

Location       = "Location" ":" absoluteURI

で、このabsoluteURIはRFC2396: Uniform Resource Identifiers (URI): Generic Syntaxで定義されておりまして、

absoluteURI   = scheme ":" ( hier_part | opaque_part )

ということで、URIスキーム(httpとかftpとか)から始まる絶対URIであることがわかります。

とはいえ、色々調べてみると、携帯とか一部のブラウザを除くと大体相対パスでも動くそうで、絶対URIを作成時に予測するのが難しい、他人に配布するスクリプトなどでは相対パスで指定していることが多いそうです。

 

ニコニコ動画の場合は絶対URIでも良いと思うのですが今回は相対パスで指定されていて、ふつうのブラウザなどではこれで意図通りに動くのですが、さきゅばす2のPythonでは最近のバージョンまで相対パスに対応していなかったため問題になったようです。で、最新のバージョンでは相対パスに対応しているので、配布バイナリを最新バージョンに差し替えることにしました。

で、ほかのヘッダではどうなってるの?

HTTPのヘッダには、ほかにもいくつかパスを指定できるものがありましたよね。いくつか調べてみました。

Request-URI

リクエストURIは、GET ****** HTTP/1.1みたいな形式で指定されるときの、あのURIです。

Request-URI    = "*" | absoluteURI | abs_path | authority

なんと…。実は絶対URI指定でも良いのですね。たまに絶対URIでのリクエストがこのサーバに飛んでくるのですが、てっきり不正なリクエストなんだと思ってました。…とはいえ、ほとんどのクライアントは絶対パスで取得するのがふつうなので、ちょっと警戒すべきだとは思いますけど…。

 

Content-Location:

Locationと似てますが別物です。リクエストされたコンテンツが別のところからも取得可能な時に使われる…そうですが、実際使われてるのを見たことがありません…。だれか教えて(ぇ

Content-Location = "Content-Location" ":"
( absoluteURI | relativeURI )

こっちは相対URIも可能です。同じサーバであることが自然だからなのかなあ。

Referer

リファラです。ほかのページのリンクなどをたどって来たことを示すわけですが…

Referer        = "Referer" ":" ( absoluteURI | relativeURI )

なんと!これも相対URIはOKでした。とはいえ、世の中のクライアントは大体絶対URIじゃないでしょうか?

以上です。たまにはRFC読んでみると意外な発見がいろいろありますね。

追記:RFC7321では相対URLが認められている

その後2012に出たRFC7231では相対URLもOKになりました。以下、引用です:

7.1.2. Location

   The "Location" header field is used in some responses to refer to a
   specific resource in relation to the response.  The type of
   relationship is defined by the combination of request method and
   status code semantics.

     Location = URI-reference

   The field value consists of a single URI-reference.  When it has the
   form of a relative reference ([RFC3986], Section 4.2), the final
   value is computed by resolving it against the effective request URI
   ([RFC3986], Section 5).

   For 201 (Created) responses, the Location value refers to the primary
   resource created by the request.  For 3xx (Redirection) responses,
   the Location value refers to the preferred target resource for
   automatically redirecting the request.

   If the Location value provided in a 3xx (Redirection) response does
   not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim"

Twitterで住所がバレる!?「Twitter住所特定実験」

Posted on

なにやら物騒なタイトルで。たまにはタイトル一本釣り。

リア充の皆様。AndroidにiPhoneといったスマートフォンを活用してリアルを充実させていらっしゃることと存じます。今回、私どもは、皆様のスマートフォンからTwitterへ送信することができる位置情報から、住所を特定できるのでは無いか、というありがちだけど実際検証した人は居ない†1仮説に基づき、実際にそれを行えるのかどうかやってみました。

今回開発したアプリでは、過去のツイートのうち、位置情報を持っている物を抜き出してGoogleMaps上に配置します。このアプリでは自分の位置情報のみを取得するようにしていますが、誰でも取得できる情報です。

実例と結果

こちらからアクセスしてください。

使い方も解説します。

20110626_01.jpg

この画面で「Twitter経由でログインする!」をクリックすると、このようにOAuthの認証画面が現れます。ログインを押して続行できます。

20110626_02.jpg

ログインに成功すると、このような画面になりますので、「ロード」を押してツイートの読み込みを開始してください。

20110626_03.jpg

うまく読み込むと、こんな感じで地図上にマッピングされます。このψ(プサイ)という人は関東から…出ていないようです…w

20110626_04.jpg

ズームしていくと…つくばエクスプレスユーザーだと一目で分かってしまいますーー;;

20110626_05.jpg

自宅周辺では、たくさんのピンが立っているのが特徴なのはもちろん、こういった自宅でしてるっぽいツイートがあるのも特徴です。

住所を特定するコツ

単に位置情報だけでは通勤・通学で使う駅等で呟いてることが案外多かたりで、それだけで住所まで絞り込むのは難しいです。

ですので、発言内容も手がかりにしてみてください。住所だけじゃなくてよく使うレストランとかも特定できます←父親のアカウントで検証済み、こがねちゃん弁当乙

色々と生活パターンが分かって怖い…^^;こち亀でGPSの大きな装置を背負って生活してもらう!なんて話が100巻~120巻くらいにありましたけど、それが現実になってるんだな~、って感じです。もちろん、背負わなきゃいけないほど大きな装置ではありあませんが。

住所が第三者からでも特定できちゃいそう!どうすれば?

Twitterの設定画面から、あなたの位置情報をすべて消すことができます。

20110626_twitter-acount-settings.jpg

書かれている通り、大体30分くらい時間が必要なようです。何か怖いと感じたら消してしまって良いと思います。

そもそも

位置情報って活用されてるんでしょうか?私はなんとな~くiPhoneの時は毎回入れていましたけど、冷静に考えるとあんまりいらない機能である気がして仕方がありません…w

政情不安とか地震とかの超リアルタイム緊急時だったら案外活用されてるのかな。

その他

sessionでOAuth用のtokenの受け渡しとかが出来るのが便利~。やっぱりフレームワーク使うとサクサクできていいですね~。

  • †1: Google先生調べ

東大ニコ研が23日11時からZUNさんの講演会を生放送するお!

Posted on

 東京大学は駒場祭真っ最中なう!

 本日、午前11時より東大でまるきゅう(東方のダンス踊る人たち)主催による、ZUNさんの講演会が行われます!

 私の所属している東大ニコ研では、この中継を生放送します!!いろいろと面白いお話が聞けそうなので、ぜひ聞いてみてくださいね!

五月祭の東方ダンスを、今度は実況中継!

 五月祭で好評だった本講演会主催のまるきゅうによる東方ダンスが、駒場祭でも行われます!最高学府の⑨な人たちによるダンスもぜひ見てゆっくりしていってね。

五月祭の模様

今日の放送

で、あんた何やってるの?

 上記の放送と前後の準備時間以外は、五号館三階、531教室の半分がニコニコ動画研究会で延々と生放送します!

 私は東大の本屋さんでもベストセラーとなったライトノベル僕は友達が少ないに登場する「エア友達」の作り方を、現役エリートぼっち東大生ψ(プサイ)がgdgdと伝授します!

 リア充でもこのご時世、エア友達は必須です!ぜひ作り方を覚えて帰って行ってね。

 ちなみに百合柄の浴衣着てるのでよろしく。今回はちゃんと化粧するよ!そんなんやってるから友達できないんじゃ…。


明日(8/2)東大ニコ研でニコ生!&公式サイト

Posted on

 東大ニコ研の公式サイトが出来ました。こちら。

 8/2の20:00に東大ニコ研で生放送を行うことが決定しました!!私もそのうちの一人として参加するので、ぜひ見てね。まずは、ユーザー生放送からはじめる、という形に落ち着きました( gdgdだと思うけどみんな見てね!!