family-ops – 家族を支えるテクノロジー

これは、妻・夫を #愛してる ITエンジニア Advent Calendar 2017 企画の2日目です。

はじめに

はじめまして。nunnunと申します。僕は、インターネットにおけるトラストに関する研究をしている研究者で、大学を経て、現在はメルカリという会社に所属しています。
製薬会社で働く妻と結婚してちょうど1年になりました。お互い理系カップルなので、参考にならないかもしれませんが、非エンジニアの妻と、この1年間で家庭を効率的に運用するために使ってみて、役に立ったサービスを紹介したいと思います。

G Suite

Google Appsって言われていたやつです。


登録開始を待ち望んでいた .family gTLDでドメインを取ることができたので、そのドメインを使っています。

Google Calendarはお互いの予定を見えるようにしているので、family eventの調整や遊びに行く調整などもカレンダー見て、invitation送るだけでできるので、非常に便利に活用しています。

Google Photosの共有ライブラリ機能はお互いの写真を撮った後、勝手に自動で共有してくれる上に、RAWで撮影してもそのRAWをダウンロードできるので、後でファイルをもう一回貰わなくて済むというので便利です。

他にもGoogle DriveのTeam Driveで家計簿を管理したり、大切な書類をスキャンして保存したりしています。

Slack

エンジニア同士なら確実に使っていると思うのですが、夫婦でSlackを使っています。
付き合い始めた当初はLINEを使っていたのですが、そもそも僕がLINEをほとんど使っていなかったのでSlackに移行しました。便利な点としては、

  • 会社で使っているツールなので、ひと目につきにくい
  • 履歴の検索が簡単にできる
  • チャンネルをわけることで、コンテクストが混ざらずに済む
  • Integrationが便利

Integrationはなかなか活用しきれていませんが、後に述べるGithubと連携してIssuesの通知などに活用しています。
(便利なIntegration有ったら教えてください!)

10,000メッセージ行くのに1年以上かかるのではと思っていましたが、f2fでない会話はほとんどSlack上でしているので、気がついたら10,000メッセージを超えていました。
そろそろ課金するかGoogleのHangouts Chatが出たらそっちでもいいかなと思います。

GitHub

結婚式は私の母校の教会で挙げました。
ホテルや専門式場での結婚式の場合、会場がある程度準備をしてくれるのですが、教会は式を挙げてくださるだけなので、すべての準備を二人でしなければならず、膨大なタスクリストを共有、解決するためのツールとしてGitHubを使いました。

結婚式の準備と並行して新生活の準備も実施していたため、タスクやマイルストーンを整理しながら意思決定とその記録も残したかったので、GitHubのプライベートレポジトリを活用しました。今は、生活が落ち着いているのであまり活用できていませんが、きっと子育てが始まると大活躍するようになるのかなと思います。

Find My Friends

お互いiPhoneを使用しているので、Apple純正のFind My Friendsを使って位置情報の共有をしています。共働きで、夕飯の支度をしているときに後どれくらいで帰宅するのかわかるので、非常に便利です。

1password for family

航空会社の会員番号や、身分証明書の写真や、家のWiFiのパスワードなど、Secureに共有しておきたいものを共有するのに使っています。

まとめ

参考になりましたでしょうか。
エンジニア同士でなくとも、便利に活用することができるWebサービスを紹介しました。

結婚2年目に突入したばかりですが、新しいサービスや家庭内人柱に常に協力してくれる妻には感謝しています。これからもテクノロジーの力を借りて、二人で効率的で素敵な家族を築いていけたらと思います。

明日は ものものブログ さんです!

KDDI版iOS 9デバイスでIPv6を使う

以前書いたKDDI版iPhone 5/5s/5cでIPv6をつかうのプロファイルでは動作しなくなったので、アップデートしました。

技術的な詳細はIIJてくろぐに記載されていますが、とりあえずLTE NET for DATA用のプロファイルを作成したので公開します。

https://nunnun.jp/ltenetfordata-test.mobileconfig

Eduroamに非参加でも学認に参加機関に所属する人がEduroamを使う方法

Eduroamは学術機関間におけるWiFiの相互ローミング運用プロジェクトで、全世界の大学や研究機関に所属する学生・教職員が利用できるシステムで、日本国内においては国立情報学研究所(NII)が推進をしています。

日本国内における認証連携には学術認証フェデレーションである”学認“を使用しており、学認に参加している機関であればeduroamが利用できるように見受けられますが、実際にはeduroamに別途参加しなければ利用できない仕組みになっています。

例えば慶應義塾大学のように学認に参加しているが、eduroamに参加していない機関に所属する学生・教職員はeduroamの恩恵に預かれず、国内外の学術機関に訪問した際にネットワークを利用できません。

Eduroamでは所属する機関の学生・教職員が持つクレデンシャルを利用して認証を行うため、個人や所属機関が特定されてしまうと言う問題 ((例えばhogehoge@sfc.keio.ac.jpというアドレスで認証すればSFCに所属しているのがわかってしまいます)) がありました。その問題を解決するため学認では一時的に仮名のクレデンシャルを発行する仮名アカウント発行システムというシステムを運用しています。

本来仮名アカウント発行システムは利用者を保護するためのシステムですが、本システムを利用することでeduroamに参加していない機関に所属する人もeduroamを利用することができます。

方法

  1. 仮名アカウント発行システムにログインする
    https://eduroamshib.nii.ac.jp/
  2. ログインに成功したら、アカウントを発行する。
    利用期間は最大1年間まで選べます
  3. 取得したクレデンシャルでeduroamを利用する

免責事項

本記事は私が所属している組織の意見を表明したものではありません。
また本記事の内容について保証するものではありません。

HWD14をMac OS X Yosemiteで使う方法

MacをYosemiteにしてからHWD14の有線Ethernetが使えなくなって、WiFi経由でしか使えなくなってしまい、非常に不便だったのだが使える方法があったのでメモ。

基本的にこの手のデバイスは最初接続するとUSB Composit Deviceとして認識されて、専用のユーティリティがATコマンドみたいなのを飛ばして有線Ethernetデバイスとして認識させるみたいな仕組みなので、初回接続時だけユーティリティのインストールが行われる仕組みになっている。

ただ、OSのアップグレードとかでそのユーティリティが動かなくなると有線Ethernetとしても使えなくなる仕組みなので、そのユーティリティさえアップグレード出来れば問題ないはずなのだけど、残念ながらHWD14はそのアップデートが提供されず購入して1年もたたないのに最新OSで使えないという残念な仕様となっていた。

勿論本国ではそのユーティリティは提供されているので、同じHuawei製のHWD14なら動くはずということで試してみたところ問題なく動きました。というオチ。

リンクはこちら。
http://consumer.huawei.com/en/support/downloads/detail/index.htm?id=31145

ところでHWD14小田急線で全くというほど使い物にならないのだけど(というか動いてると小田急線だけじゃなくダメ)、後継機に乗り換えたら使い物になるのかな?

HTTP2におけるProxyに関する議論

この記事はHTTP2 Advent Calendarの17日目の記事です。

はじめまして。nunnunと申します。HTTP2 newbieなので戦々恐々としておりますが、よろしくお願いします。

注意: HTTP/2.0はHTTP2もしくはh2と表記が変更になりました。

先日HTTP2のExplicit Proxyとそのプライバシー上の懸念について記事を書かせていただきましたが、その後のプロキシに関する議論を書きたいと思います。

IETF 91 HonoluluではProxyに関する議論がいくつか行われました。

  • draft-nottingham-web-proxy-desc-01
  • draft-loreto-wpd-usage-00
  • draft-chow-httpbis-proxy-discovery-00

背景

Explicit Proxyの議論が生まれた背景はGoogle ChromeのSPDY Mobile Proxyをキャリアが運用したいというモチベーションでした。SPDY Mobile Proxyをオペレータが運用することでTransparent Cacheなどのトラフィックエンジニアリングによるトラフィック削減が望めるため、HTTP2においてそうした仕組みを実現したいという目的で提案がなされた模様です。

draft-nottingham-web-proxy-desc-01

httpbisの議長であるMark NottinghamによるProxy Discoveryに関するドラフトです。従来HTTPにおけるProxyの設定はPAC(Proxy Auto Configuration)と言われるJavaScriptを用いてProxyを設定するという方式が用いられていました。JavaScriptを用いるため柔軟な設定が可能である反面、その設定URLを知らなければ設定できない問題が指摘されており、その問題点を解決するためWPAD (Web Proxy Auto Discovery)と呼ばれるDHCPもしくはDNSを用いてそのURLをnotifyする仕組みが提案され、Internet ExplorerやFirefoxなどで実装され、利用されてきました。

本提案ではまずHTTP/2 over TLSの利用を必須としています。従来のPACではクリアテキストでの設定も許容されていましたが、MiTM攻撃なども想定できることから証明書の検証が必須となっています。

またどのホストにどのプロキシを利用するといった設定がJSONによる形式に変更となりました。設定では、Proxyの名称、目的を記載するだけでなく、プロキシが企業などで利用されることが多いことから、プロキシを適用するネットワーク(IPアドレスがレンジにいる場合のみに適用するなど)を追加することができるようになりました。

更にはブラウザにおいてIncognitoモードに代表されるプライバシーモードが広く使われていることから、プライバシーモードの利用を強制するオプションの設定が可能となっています。

従来のWPADによるDiscoveryは禁止されたものの、well-known URIを用いたdiscoveryを行うことが規定されています。

draft-loreto-wpd-usage-00

MarkのWPDドラフトを拡張したドラフトがdraft-loreto-wpd-usage-00です。

特徴としては携帯電話ネットワークなどの高遅延、高ジッター環境で利用することを想定し、いくつかのトラフィックタイプ(Class of Serviceに近い)をlabelというタグを用いて分類し、それらトラフィックタイプ毎にプロキシを設定することを可能にしています。そのため、クライアントはコンテンツに応じてプロキシを使い分けることが可能となり、より最適化された通信が可能となるそうです。

draft-chow-httpbis-proxy-discovery-00

draft-chow-httpbis-proxy-discovery-00はWiFiのキャプティブポータルなどと組み合わせることで、明示的に同意を取ることでhttpsスキームな通信もProxyする(ただし”it MUST NOT alter the end-to-end encryption for “https” requests”と規定)ことも可能としています。
(きちんとドラフト読み込めていないので間違っていたらすみません)

ただしこれはMiTMであり、エンドツーエンドでのセキュアな通信を犯す可能性があるため、個人的にはhealthyではない提案であると感じています。

IETFでの議論

IETFではさまざまな議論が行われましたが、結局WGとしての結論は出ず何かをWG itemとして標準化するという結論には至りませんでした。

まとめ

WPADやPACといった仕組みはold-fashionな技術であるため、新しい仕組みが必要であると個人的に感じ、Internet Confidentialityに関するIABのステートメントや、現在W3C TAG(Technical Advisory Group)によるHTTPSへの移行に関する指摘事項ドラフトなどの流れを踏まえると安全にプロキシをDiscoverする仕組みの策定は重要であると感じています。

第4回IGCJ(日本インターネットガバナンス会議)に参加してきました

去年の6月から開催されているIGCJ(日本インターネットガバナンス会議)が4回目となり、インターネットウィーク期間中に開催されているので参加してきました。(参加自体は初回からしていますが)

IANA監督権限の移管に関するアップデートやITU全権委任会議での報告などがありましたが、スライドなどはアップロードされているので、個人的に気になったポイントをまとめたいと思います。

IANA監督権限まわり

粛々と進んでいるなという印象を受けました。基本的にIANA機能はICANNにお願いするという方針で、LACNICがMONC (Multistakeholder Oversight Number Council)というマルチステークホルダな組織がIANA機能の監視をするといった提案をしているのが変わってるなと感じました。

個人的にはNROが地域RIRの活動のコーディネーションとかもしており、これ以上マルチステークホルダにしなくても良いのではないかと感じましたがどうなるかはこれからです。IETF側もIANAPLAN BoFで粛々と進んでいるので、deadlineは近いですがこのまま行くのかなと思います。

ITU全権委任会議報告

4年に1度開催されるITU全権委任会議、ITUの最高意思決定機関。今回の焦点(インターネット的な文脈)はWCIT-12で問題となり改正ITR(アラブ諸国などの提案からセキュリティやスパムなどに国が積極的に関与すべき, インターネットに関するルール策定に国連がもっと介入すべきという方針になったが、日本を含む欧米各国は不署名)によって広がった対立をどう回避出来るかが焦点。
ITUではポリシーの策定は、各国が既存の決議に対して修正提案をする or 新規決議の提案をするという形で実施される。

基本的に日本を含む先進各国はインターネットに対する政府の権限を増やすという提案には反対をしたので、修正提案は取り下げという形となった。ITUの作業部会をもっとオープンにすべきという提案についてはインターネットに関する作業部会は事前にオープンなコンサルテーション会合を開くという方針に。これもマルチステークホルダモデルを踏まえた形なのかなと。

質疑で日本が決議に反対する理由としてITUのマンデート外なので反対という理由をしているが、現実的にはどういう観点で決議への賛否を決めているのかという質問があり、情報な自由の流通を確保することが大前提。それが阻害されるような項目については反対をするという方針という説明がされてた。

インターネットの透明性や非合法盗聴などについては、そもそも国連では人権を担当する委員会とかがあるのでそっちが担当して、ITUは技術について注力するという話があった。個人的にはここは重要なのかなと思っているので、そこら辺のアップデートが聞ける場があったらよいなと思いました。

IGCJを考える会レポート

いろいろな意見が出ていましたが、個人的に思ったのは「プロ」「コーカス」「オーディエンス」という分類で、インターネットガバナンスに関わる人は割と限定されてしまっているため、会社を代表していう意見とインターネットを利用する個人としての意見をうまく帽子を被り変えながら喋らないといけないというのが難しそうだなと言うのを感じました。個人の意見と会社の意見が一緒であればいいのですが、なかなか難しかったりしそうだなと・・・。

IGF2014報告

NETmundialとかはオープンといえども招待を受けないと参加できないのに対してIGFは誰でも参加できるというのが特徴。IGFについては僕の勉強が足りていないので情報収集をしないとなという印象を受けました。(ちゃんと議論を聞けなかったので、まとめきれてなくてすみません。そしてごめんなさい)

雑感

全体的に感じたのはインターネットガバナンスに関して日本ではJPNIC, JPRSさんに頼りすぎているなというのを感じました。もちろん彼らの業務範囲であるので情報集めて、僕らにわかりやすいようにまとめて、そして僕らが考えてそうなことを会議とかで発言していただいているのかなと思うのですが、インターネットはみんなのものだと思うのでもっとインターネットに関わるいろいろな人が意見を出したり、情報を発信していかないといけないなと思いました。JPNICさんとかは妖精さんではないですからね。。。

マルチステークホルダモデルについては勉強が足りてないのですが、究極のマルチステークホルダってマルチステークホルダモデルを作るにはどうしたら良いかの議論をマルチステークホルダでやろうみたいな話になって、以下無限ループみたいになってしまうのですが、ある程度の妥協とわかりやすい仕組み作りが大切かなというのは思いました。

エンジニアな観点だとポリシーの世界はいろいろややこしいと思いますが、エンジニアリングだけで解決できない問題はいっぱいあるのでそのためにももっとエンジニアがガバナンス・ポリシー策定に関わるとよいなと思いました。

インターネットガバナンスnewbieなので、いろいろ間違った認識、おまえ何言ってんだとかあると思いますので是非是非ココ間違ってるよとかご指摘いただけるとうれしいです。

カナダ国境でのlaptop searchについて

2013年11月にカナダ バンクーバーで行われたIETF 88に参加する時に起きた話なので少し古い情報です。

2013年11月3日にIETF 88に参加するためにカナダのバンクーバー空港で入国後、バゲージクレームエリアでカナダ国境サービス庁による手荷物捜索を受けました。通常手荷物捜索は税関などが非申告の禁輸品の所持を確認するためなどの行うのですが、すべての乗客の荷物を捜索することは難しいため、ランダム(もしくは彼らが疑うに足る事由がある場合)に選択して捜索を行うのですが、私が受けた手荷物捜索では児童ポルノの所持を確認するために所持していたデジタル端末すべてのパスワードを教えてなければならないというものでした。

詳細な経緯は以下の通りです。

手荷物を受け取った後、通関ゲートに向かっていたところ、カナダ国境サービス庁の職員にカナダを訪れた理由を聞かれ、IETFへの参加であることを告げたところ、手荷物の捜索を行うということで、ブースに案内されました。
そこで手荷物の捜索に協力していたところ、デジタル端末の捜索(laptop search)も行うのでこの場で(ちなみにオープンなカウンターで他にも”ランダム”に選ばれたアジア系の若い男性が同じようにデジタル端末の捜索を行われていました)パスワードを口頭で言えと告げられました。
そもそも児童ポルノは禁輸品であり、児童の人権は守られなければならないということは認識していましたが、オープンな場所であることや、通常この手の捜索は捜査令状などが必要なのではないかと思い、拒否することを告げたところ、職員より拒否する権限はないと言われました。
しかしながらオープンな場所で口頭でパスワードを告知することは避けたかったため、文字で書くので代替できないかと交渉したところ、それは認められ、職員が所持していたメモ帳(ちなみにそれには過去に同じように捜索を受けた人のパスワードがいっぱい書いてありました)に書くよう言われました。その後職員は私の所持していたデバイスをすべて持ち、バックオフィスに行きカウンターで待機するよう命じ約30分ほど待機しました。
もちろん私は法で禁じられた画像や動画などは所持していないため、30分ほどした後職員は戻り、私は空港の外に出ることが出来ました。

私はこの捜索にはいくつもの問題があると感じています。

  • 捜索の妥当性
    どのような理由で私が選ばれたのかわかりませんが、数百人の乗客から同じように捜索を受けていたのがアジア人の若い男性のみであったことはたとえランダムだとしてもとても恣意的に感じました。
  • 運用方法について
    BC Civil Liberties Associationによると、捜索では”Electronic Media Search Form”に記入をしなければならいと規定されていますが、実際には口頭申告されたパスワードをメモ帳に書き込むというずさんな方法で捜索が行われました。職員の対応にはプロフェッショナルさを感じることは出来ませんでした。
  • 何を優先すべきか
    児童の人権は優先すべきですが、一方個人のプライバシーも大切です。児童ポルノの捜索だけを行うのであれば、別室にラップトップを持っていくというオペレーションではなく、目の前で捜索することも可能だと思います。別室にラップトップを持っていったということは児童ポルノも関係なくデータはコピーされたと考えざるを得ず、またPRISM問題直後でしたのでバックドアを仕込まれた可能性も否定できませんでした。
    また例えば私が政府関連の仕事に従事していた場合、この捜索の結果機密が他国の政府にわたる可能性もあり、これには外交官特権のみでしか対抗することができません。
    更にはもし私が仮に児童ポルノを所持していたとしたらデータを物理デバイスに入れて国境を横断するなどというわかりやすい行為はしないでしょう。暗号化してどこかのサーバにアップロードするなどすると思います。つまりこのlaptop searchでどれくらい児童ポルノが国内に持ち込まれるのを防げたかについては疑問が残り、それにより侵害される個人のプライバシーの方が大きいのではないかと思います。

法治国家に生きる市民として法律に定められた正当な行為なので従いましたが、残念ながら心地よい対応ではなく、タイミングもあって強い憤りを感じました。

法律の専門家ではありませんので、細かいところは違うかもしれません。
その直後のFacebookポストも参考にリンクしておきます。

[追記]
後日IETF 88のTechnical Plenaryの議事録が公開され、そちらに私の発言が記録されていました。

児童の人権と個人のプライバシーどちらもが尊重される社会が訪れるとよいなと切に願います。