Tetsu=TaLowの雑記(はてブロ版)

しがない大学教員が琵琶湖のほとりから呟きます

Googleフォームを使った簡易電子投票システム

この記事はKMC Advent Calendar 2018の9日目の記事になる予定でした。でも大幅遅刻…。8日目は現在KMC最年少部員のkanaさんによる16年間を振り返って整理する - kana_kmcのブログでした。16!私の1/3以下ですねぇ。趣味色々楽しい時期ですねぇ。でも、まずは受験頑張って下さいね!と思ってしまうのは大学教員の性でしょうか。

adventar.org

ごあいさつ

こんにちは、Tetsu=TaLowです(kmc-idはtetsu)。京大マイコンクラブ(KMC) 32回生です。現役最年長部員(51歳)です。KMCは誰でも部費さえ払えば会員になれるので、私のようにはるか昔に学生だった者でも会員で居続けられるのです。今年も年甲斐もなくAdventarに登録してみたのは、今年はついに忙しくて秋のKMC OB会もでられなかったので、これくらいしないとKMC的活動が全然できなくないなと思ってのことでした。一昨年は毒にも薬にもならない話を、昨年はちょっとは役に立つかもしれない話を書きましたが、今年は「もしかしたら、人によっては、役に立つ、かもしれない、くらいの話」を書いてみたいと思います。あ、その前に12月9日は素数日ですよね。今年はあと2回、12月23日と29日に素数日があるのですが、来年最初の素数日は2月21日までないのですよね。その代わり1月以外には全て素数日があります。総数は19日と今年より1日多いのですが、連続素数日双子素数日もなく、いとこ素数日(差が4日)が1組、セクシー素数日(差が6日)が2組ありますね。

20190221
20190227
20190301
20190319
20190323
20190421
20190523
20190529
20190601
20190613
20190719
20190811
20190823
20190913
20191009
20191027
20191109
20191117
20191231

最近素数日botと化している私のTwitterアカウントですが、来年も呟いていこう*1と思いますのでよろしくお願いします。

きっかけはCSSx2.0での投票

ところで皆さん、投票ってやりますよね。選挙権は18歳以上なら普通持っているはずなので議員や首長を選ぶ選挙は機会があるはずですし、仕事なんかでもたまに投票の機会があるかもしれません。私は大学教員という仕事をしている関係からか、教授会や学位審議委員会での各種議決投票、学会の役員選挙など日常的に投票してますので、割と投票の機会が多い人間だと思います。ですが、これらは、いまだに紙の投票が多いのですよね。集計大変なのに…でも色々考えると、匿名性と二重投票防止を確保しつつ電子投票にするってそれなりのインフラが必要でなかなか難しい。しかし、こうすれば簡単に実現できるんじゃないのかな、というアイデアはいくつか温めてました。でもそれを実装しようにも、そもそも私って投票する側に回ることはあっても、投票を取りまとめる側になることってあまりなかったんですよね。

それが、今年割と大きな投票を取りまとめる羽目に陥ったのです。

日本のセキュリティ研究者の大きな集まりの一つに情報処理学会コンピュータセキュリティ研究会(CSEC)が主催する「コンピュータセキュリティシンポジウム(通称CSS)」があります。このCSSではキャンドルスターセッション(CSSx2.0)と呼ばれる、いわゆるランプセッション*2があり、ここで各発表について投票が行われるのですが昨年のCSS2017のCSSx2.0で私うっかり優勝してしまいまして*3(キャンドルスター1等星という称号が与えられる)、今年の実行委員長を拝命してしまったのです。ということは投票を管理しないといけないわけですが、これまではこの投票が原始的でして…発表会場で投票用紙が配られ、これに良かったと思われる発表の番号を書いて退場時に投票箱に放り込むだけなんですよね。しかも、この投票がキャンドルスター賞を選ぶためと、別の特別賞(CSS2017の場合にはアルタイル賞)を選ぶための2つ投票が行われるわけですが、この投票用紙がセットになっちゃってます。こんな感じ。

f:id:tetsutalow:20181209021405p:plain

委員長引継ぎで受け取った投票用紙

はい見事なネ申Excelですね!これを印刷して、4つに切って配って、投票してもらったらそれを集計するわけです。しかも集計はキャンドルスター賞と特別賞で2回やらなきゃいけない。それを500人分やるとかちょっとやりたくないよなぁと。そこで強く決意したわけですよ。今年のキャンドルスターセッションでは電子投票に置き換えてやると!というわけで、前からちょっと温めてたアイデアをこの際、実装してみることにしました。それも、最小の手間で(これ重要)。

電子投票システムの設計

実際に投票システムを考えるにあたっては以下のことに注意しました。

  1. 新規のシステムを作るのは面倒なので、ありあわせのものだけで構築すること。
  2. 2重投票が防止できること。
  3. 投票の匿名性は保たれること。
  4. 投票はスマホやパソコンからできるだけ平易に行えること。
  5. 会場にスマホもパソコンも持ちこまない人がいるかもしれないので、紙でも投票可能なこと。
  6. 集計が楽になること。

まず1.ですが、そのため道具立ては以下のもので十分なようにしました。

2.と5.を実現するために、投票用紙を配ることにしました。その投票用紙に投票用コードを書いておき、ネット経由での投票時にそれを入力してもらうことにしました。投票者は会場に来ることが前提になっているので、全投票用紙に個別の投票用コードを印刷しておいて、一人1枚配ることにすれば2重投票は防止できますし、コードを十分予測困難にすればイタズラ投票も防止できるでしょう。投票用紙をランダムに配れば匿名性も保たれ、3.も実現できます。スマホやパソコンを持たない人には投票用紙を会場の投票箱に投入してもらいますが、それを回収した後に事務局側でそれを改めてネット投票してしまえば、集計はネット上でできるので6.も実現できるはずです。

ということで、こんなシステムにしました。

f:id:tetsutalow:20181209051755p:plain

投票の流れ

これなら、スマホとPCから入力されたものはGoogleフォームを通じてGoogleスプレッドシート上に集計できるようになるはずです。この際、Google Apps Scriptを使って2重投票のチェックもしてしまえば後が楽になります。できるだけ紙投票ではなくネット投票して下さいと呼びかけて成功すれば、集計の負荷も下がるでしょう。さて、これを出来るだけ少ない手間で実現しちゃいましょう。

投票システムの実装

投票用コードの生成

投票用コードは、少なくとも投票する人数分は用意する必要があります。今回は1000人分作ってみました。投票用コードはスマホ入力の際にはQRコードに埋め込んでしまうことにしますが、PCから投票する人には手入力してもらうことになるので、誤入力が少なくて済むように、読み間違えやすい0とO(ゼロとオー)、1とIやl(イチとアイやエル)が混在しないように考えます。投票の匿名性を確保し不正を防ぐという意味では、容易に覚えられない長さがあった方がいいはずです。数字だけで12桁とかでもいいかなと思ったのですが、Excelでの扱いやすさを優先して今回は大文字のアルファベットのみ10文字で生成してみました。プログラミング言語はPython3。このまま手元にコピペして実行していただいてもいいですが、Google Colaboratoryを使っているのでこのままWeb上でも実行可能です*4

generatecodes.ipynb

…まぁ実は1000個くらいならこんなコードを書くまでもなくて、こちらのExcelシート(Google Spreadsheetですが)を使ってもいいかと思います。とてもダサい方法ですが*510文字の投票用コードを1000個生成してくれます。厳密にはPython版と違って重複チェックしてないのですが、1000人なら重複しちゃう確率は十分低いでしょう*6
docs.google.com

これを使って必要な数の投票用コードが入ったCSVファイルをまず作ります。上記プログラムを使った人は出力をファイルに落として 投票用コード.csv とでもして保存したあと、それを開いて先頭行(1行目)に空行を挿入して見出し行にします。A列の見出し行は「投票用コード」とでもしましょう。上記ExcelシートをExcel形式(.xlsx)でダウンロードした人は*7、そのままだと投票用コードが再計算のたびに変わってしまうので、一度CSV形式で保存してから再度そのファイルを開いて関数を消します。いずれにせよ、出来上がりはこんな状態になっているはずです。

f:id:tetsutalow:20181209093346p:plain

投票用コードを用意したところ

とりあえずこれは置いておいて、次はGoogleフォームの準備です。

Googleフォームを使った投票フォームの作成

ここでは投票に使うGoogleフォームを投票フォームと呼びますが、これを作ります。Googleフォームの使い方については他にも多く記事があるのでお任せするとして、ポイントだけご紹介します。

  • 入力項目の先頭は投票用コードにします。入力項目としては必須にします。入力形式を記述式にします。回答の検証はオンにして、正規表現で入力内容をチェックした方がいいでしょう。

f:id:tetsutalow:20181211085421p:plain

投票用コードの入力欄
  • 投票する項目はラジオボタンにしておくのが楽です。入力必須項目にするかどうかは白票を許すかどうかに依存しますが、必須にしておいた方がトラブルが少ないと思います。どうしても白票を許したければ「白票」とか「棄権」という項目を作るといいでしょう。

f:id:tetsutalow:20181209121615p:plain

投票項目の設定
  • 回答はスプレッドシートに集約されるようにします。回答タブを押し、右側の縦に点が3つ並んだメニューアイコン*8をクリックして回答先を選択し、新しいスプレッドシートを作成するように選びます。

f:id:tetsutalow:20181209130424p:plain

回答をスプレッドシートに集計するようにする(1)

f:id:tetsutalow:20181209131304p:plain

回答をスプレッドシートに集計するようにする(2)
  • 設定ボタン(ブラウザ画面右上の、歯車みたいなアイコン)を押して、収集時の挙動を設定します。重要なのは「回答を1回に制限する」をチェックしないことです。チェックするとGoogleアカウントにログインして回答することを要求するので、投票の匿名性が失われてしまいます。同様にメールアドレスを収集するのも投票では意味ありませんよね。回答者が行える操作の2つについてはよく考えて使った方がいいでしょう。「送信後に編集」は状況によっては便利ですが、例えば投票者が端末を共用する可能性がある時には人の投票が見えてしまうのでやめた方がいいです。設定の「プレゼンテーション」のタブで投票後に出るメッセージが指定できますが、固定メッセージしか出せないのであまり気の利いたことはできません。

    f:id:tetsutalow:20181210090345p:plain

    投票フォームの挙動の設定

    f:id:tetsutalow:20181210091051p:plain

    投票受付時のメッセージを設定


入力用URLの取得

次に、作った投票フォームへ飛ぶためのURLを2種類取得します。

  1. 既定値が入ったURLの取得。このためにはまず、フォームの右上のメニューをクリックして「事前入力したURLを取得」を選びます。

    f:id:tetsutalow:20181209134443p:plain

    既定値が入ったURLの取得


    そうすると作成中の投票フォームが現れるので、既定値を入れるべき質問項目にデータを入力して「リンクを取得」を押します。ここでは投票用コードに仮の値を入力します。

    f:id:tetsutalow:20181209150950p:plain

    既定値を入力してURLを取得する

    すると

    https://docs.google.com/forms/d/e/1FAIpQLScEiLaxf9HM7ulrLQDx0dI-wyk3zUDZ8W8xY0U6615WA4CTvQ/viewform?usp=pp_url&entry.1077401194=ABCDEABCDE
    のようなURLが手に入ります(指示されたとおりに操作するとクリップボードにリンクがコピーされます)。この最後のentry.1077401194が投票用コードを既定値にするためのURLパラメータになります。各投票用紙には投票用コードを印刷するのですが、スマホ向けにはこれを既定値として組み込んだURLをQRコードとして印刷すれば、投票者は楽に投票できるはずです。

  2. 上記のURLのうち、先頭からviewfromまでを抜き出します。これが既定値のないURLになります。例えば今回の例だと
    https://docs.google.com/forms/d/e/1FAIpQLScEiLaxf9HM7ulrLQDx0dI-wyk3zUDZ8W8xY0U6615WA4CTvQ/viewform
    になります。このURLはパソコンで投票する人向けに投票用紙に書くのですが、さすがにこんな長いURLを手で入力させるのは困難なので、bit.lyを使って短縮します。単に縮めるだけでなく、わかりやすい名前を付けると入力が楽になります。今回はhttp://bit.ly/KinokoTakenokoとしてみました。

 これらのURL、一度確定するとフォームを編集しても変わりません。なので、例えば投票項目や内容がまだ固まっていない段階でURLだけ取得してしまい、先に投票用紙を作っておいて、あとで投票項目を調整してもいいでしょう。実際CSSx2.0では発表者は直前まで決まらないので、フォームを作って投票用紙を印刷するところまでは前もってやっておき、当日直前に投票項目を作りました。

 投票用紙を作る

次に投票用紙を作ります。投票用紙に必要なのは

  • 投票用コード
  • PC入力用のURL(投票フォーム)
  • スマホ入力用の、投票用コードが既定値としてセットされた投票フォームのURLをQRコードにしたもの
  • 手入力用の記入欄

です。このうち、特にスマホ入力用のQRコードを楽に作成したいので、まず投票用紙の数だけURLが入ったExcelシートを作ることにします。

先ほど作成した投票用コードが入ったCSVファイルを開いて、これのB列に「既定値として投票用コードが入ったURL」を作ります。例えばB2セルをこのようにします。

=CONCAT(”https://docs.google.com/forms/d/e/1FAIpQLScEiLaxf9HM7ulrLQDx0dI-wyk3zUDZ8W8xY0U6615WA4CTvQ/viewform?usp=pp_url&entry.1077401194=”,A2)

CONCATの第1引数はさきほど得たURLのうちABCDEABCDEを除いたものです。これをオートフィルで引き伸ばせばB列が「投票用コードが既定値としてセットされた URL」になります。こんな感じですね。

f:id:tetsutalow:20181210030547p:plain

URLに投票用コードを反映させる

B列の見出しは「投票用コード入りURL」としておきました。このファイルを「投票用コード.xlsx」として保存して、これを使って投票用紙の印刷に使います。

docs.google.com

投票用紙はWordの差し込み印刷で作りました。Wordの差し込み印刷はわかりにくい機能ですけど、使いこなせれば非常に強力です。特に私はバーコード印刷がお気に入りです。さくっと作ってしまいましょう。

f:id:tetsutalow:20181210044924p:plain

投票用紙作成の様子

紙記入の場合の記入欄は白紙でももちろんいいし、事前に投票項目が決まっていればこういう風に丸をつけるように作ってもいいでしょう。

余談ですが、世の中Wordの罫線が使いにくいという人が多いのですが私は全然気にならないのですよね…むしろExcelの罫線の方が使いにくいです。Wordの罫線は「表のプロパティ」などを駆使するときっちり高さや幅がmm単位指定すれば、思った通りの表が固定的に作れると思ってます*9。なので、今回もまず表だけ作りました。1つのA4の紙から投票用紙を8枚作るようにレイアウトを決めて、まず左上の1枚だけを作ります。なお、これに差し込み印刷しますので、「1ページ以内に収まるように作ること」「データによって1ページに収まらないことがあると困るので、ページの下方は少し余裕を残しておくこと」はちょっとしたコツです。

これに、「投票コード」の右に投票用コードを、右側の欄にQRコード差し込み印刷されるようにすれば投票用紙は完成です。そのためにまず差し込むデータを指定します。「差し込み文書」タブの「宛先の選択」*10「既存のリストを使用」を選び*11、先ほどの「投票用コード.xlsx」を指定します。

f:id:tetsutalow:20181210082419p:plain

差し込み印刷用のデータの指定

投票用コード.xlsxの場合Excelシートなので、複数のシートに分かれていることがあります。そのせいか、.xlsxファイルを差し込み印刷のデータに使おうとするとシートを指定させられます。たとえシートが1枚であっても。なお、今回の私のデータの場合はcodes.csvから作ったのでシート名がcodesになってますが、多くの人はSheet1かもしれません。ポイントは「先頭行をタイトル行として使用する」にチェックをいれておくことです。

f:id:tetsutalow:20181210082640p:plain

データが入ったシートの指定

次に差し込みフィールドを挿入していきます。元のシートだと、投票用コードが入ったA列の見出しが「投票用コード」、これがセットされたURLが入ったB列が「投票コード入りURL」となっていたので、リボンの「差し込みフィールドの挿入」をクリックするとこんな感じになります。

f:id:tetsutalow:20181210091840p:plain

差し込みフィールドの選択

これを使って、投票用紙の「投票コード」の後ろに「投票用コード」フィールドを挿入します。

f:id:tetsutalow:20181210092129p:plain

投票用コードを挿入したところ

必要であればプレビューした方が分かりやすいですね。

 

f:id:tetsutalow:20181210100459p:plain

差し込みフィールドのプレビュー

つぎにQRコードの挿入です。これは「バーコードフィールドの挿入」で行います*12。これをクリックすると挿入するフィールドとバーコードのタイプが選べますが、今回埋め込もうとしているようなURLだと文字数が多いので、フィールドを選択すると自動的にバーコードのタイプとしてQRコードが選択されます。

f:id:tetsutalow:20181210104616p:plain

QRコードを挿入しようとすると…

ただ、プレビューの時点で気づくと思うのですが大きすぎるのですよね。QRコードの大きさは文字数に比例しちゃうので、URLが長いとどうしても大きくなります。プレビューの大きさは実際の埋め込みの大きさなので、これがそれなりに小さくなるまで「詳細設定」で調整した方がよいです。

f:id:tetsutalow:20181210111446p:plain

QRコードのサイズ調整

まず、エラー修正のデフォルトがQ(25)になっていますが、よほどプリンタや用紙がダメでなければM(15)くらいでよいと思います。スケールはうちの環境だと経験上50%くらいまでは平気ですが、小さくしすぎるとスマホでも読めなくなってしまうので、実際に印刷して試しながら小さくなりすぎない程度にした方がよいでしょう。

挿入後は実際にレイアウトが崩れないかどうかを「結果のプレビュー」で確認します。大きすぎるときは、バーコードの上で右クリックして「バーコードの編集」を選べば上記画面に戻れます。

f:id:tetsutalow:20181210112437p:plain

QRコードが大きくなりすぎたら

f:id:tetsutalow:20181210112801p:plain

投票用紙1枚分が完成!

うまく収まったらこれを複製します。まず大事なことは、差し込み印刷で1枚の用紙に複数のレコードを印刷するときには「ルール」を使って、次のレコードへの移行を促す「Next Record」フィールドを埋め込まないといけません。そのために、まず「結果のプレビュー」をオフにします(重要)。そうしないとこのフィールド、見えないので。

QRコードの続きに、≪Next Record≫を埋め込むのですが、これがとてもわかりにくいアイコンなのです…「差し込み文書」タブで現れるリボンの「文書入力とフィールドの挿入」の右上の、小さな?がついたアイコンです。

f:id:tetsutalow:20181210114413p:plain

Next Recordの挿入

うまくいったら、これを残りの7つのセルにコピペします。

f:id:tetsutalow:20181210115751p:plain

コピペして8枚に展開する

大事なのは、最後の≪Next Record≫は削らないといけないことです。というのは、差し込み印刷では1枚の印刷が終わったら自動的に次のレコードに進んでしまうので、最後に≪Next Record≫が残っているとそのレコードがスキップされ、印刷されないレコードが出てしまいます。

完成した投票用紙はこうなりました(ここでは「結果のプレビュー」を有効にしています)。

f:id:tetsutalow:20181210140246p:plain

完成した投票用紙

念のため、1枚だけ先に印刷してQRコードが正常に読み取れるかチェックした方がいいでしょう。試しに投票して、先に指定したGoogle Spreadsheetに集計結果が反映されるのを確認してもいいでしょう。一度投票しても、集計のGoogle Spreadsheetの該当行を消去すれば、集計結果をキャンセルできます。

読み取ることができたら、「完了と差し込み」を押して、差し込み印刷して(1000件なら125枚ですね)裁断機などで切り分ければ投票用紙の完成です。これを投票する人に配って処理すれば、投票の集計はできるようになります。参考までに、私の方で作ったこの投票用紙のWordファイルを置いておきます。

きのこたけのこ投票用紙.docx - Google ドライブ

きのこたけのこ 投票用紙(差込後).docx - Google ドライブ

これで完成?

一応この状態までくれば、投票結果を集計することまでは可能です。無効投票か、2重投票のチェックは、集計後のスプレッドシート上で投票用コードを確認すればいいでしょう。

…ただそれではつまらないですよね。それに面倒です。無効なコードによる投票や2重投票のチェックはできればその場でやりたいものです。そこでGoogle App Scriptで無効票をリアルタイムチェックします。

今回は、次のようなスクリプトを作ります。

  1. Googleフォームから回答集計用のGoogleスプレッドシートに回答が送信され、集計用スプレッドシートに1行追加が行われたときにそれをトリガに起動する。
  2. 集計用スプレッドシートは、回答で書き込まれた投票用コードが、有効な投票用コードが並んだスプレッドシートに含まれているか検索する。見つからなければ不正コードなので、集計用スプレッドシートの当該行にエラーを表すEを書き込む。
  3. 有効な投票コードが見つかれば、すでに使用して無効にされているかどうかをチェックする。無効にされている場合にはそのスプレッドシートの該当する投票用コードの列にXが書き込まれており、そうでなければ空白であるはずなので、そのセルの内容を投票集計用シートにコピーする。さらに投票コードを無効にするため、投票用コードの該当行にXを書き込む。

手順は以下の通りです。まず、先ほどの投票用コードが含まれるExcelシート(ここでは「投票用コード.xlsx」)を、Googleフォームと同じアカウントのGoogleドライブにアップロードしてしまいます。さらに、これをGoogleスプレッドシートとして開きます。ここでC列に、投票に使用された投票用コードにマークをつけるべく見出し行をつけます。

f:id:tetsutalow:20181210165940p:plain

投票用コード一覧で重複チェックの準備

さらにURLを見てスプレッドシートのIDを取得します。URLは、https://docs.google.com/spreadsheets/d/<スプレッドシートID>/という形式なので、これをメモしておきます。

次に投票フォームの「回答」タブから集計用のスプレッドシートを開きます。緑色のスプレッドシートのアイコンが目印です。

f:id:tetsutalow:20181210155649p:plain

Googleフォームから回答を集計するスプレッドシートを開く


 開いた回答集計フォームの回答に続く列を、不正投票や二重投票をメモする列にしましょう。下記の場合はD列ですので、適当に見出しを付けます。

f:id:tetsutalow:20181210160519p:plain

不正や二重投票を記録する列に見出しを付ける

ではいよいよスクリプトを。この集計フォームを開いた状態で「ツール」メニューから 「スクリプトエディタ」を開きます。そこに、myFunctionのスケルトンが表示されますが、その代わりとしてこのコードを貼り付けます。

投票集計のためのGoogle Apps Script

このうち4行目のSpreadsheetApp.openById()のID部分を、上で取得した投票用コードのスプレッドシートのIDと入れ替え、getSheetByName('codes')のcodesも該当シート名で入れ替えておいてください。また、プロジェクト名が「無題のプロジェクト」になっていると思うので、これを適当に変えます。ここでは「投票コードチェック」としました。

コードとしてはそれで準備OKなのですが、さらに2つ設定が必要です。まずこのコードがスプレッドシートを書き換えられるように権限を渡さないといけません。これ面倒なので、乱暴ですがその権限が必要な部分を無理やり実行します。具体的にはcodecheck()を引数もなしに実行しちゃいます。

f:id:tetsutalow:20181211134431p:plain

codecheck()を無理やり実行して権限取得画面を出す

 

すると次のような画面になります*13

f:id:tetsutalow:20181211135913p:plain

権限の付与

するとこんな画面になります。

f:id:tetsutalow:20181211141157p:plain

権限付与しようとすると…

なかなかおどろおどろしいですが、このスクリプトに不用意に権限付与するとGoogleドライブ上のデータを書き換えられてしまうのでかなり慎重な手順になっています。要するに自分が何をやっているかわかってない人はクリックしてはいけないってことでしょう。「詳細」「<<プロジェクト名>>に移動」をクリックすると、こんな画面になります。

f:id:tetsutalow:20181211141859p:plain

権限付与画面

Google Apps Scriptの場合はOAUTHを権限管理に使ってるので、OAUTHを使うサービスをよく使う人にはおなじみの画面になりました。これを使って先ほどのプログラム(を含むプロジェクト)にGoogleドライブ内のスプレッドシートへの編集権限を付与します。すると直ちに先ほどの関数codecheck()が走り、引数が空なのでエラーで止まりますが、権限付与はできました。

次に、codecheck()が動作するトリガを設定します。スクリプト編集の画面から「編集」「現在のプロジェクトのトリガー」を選びます。

f:id:tetsutalow:20181211142901p:plain

現状はトリガーがないので追加します。

f:id:tetsutalow:20181211143119p:plain

トリガーを追加する

トリガーは、フォームの送信をトリガとしてcodecheck()が起動するようにします。

 

f:id:tetsutalow:20181211143647p:plain

追加するトリガを設定

これで保存すれば動くはずです。やってみましょう!

f:id:tetsutalow:20181211151827p:plain

投票が集計される様子

f:id:tetsutalow:20181211152523p:plain

投票用コードが消費される様子

今回の投票集計フォームについても閲覧可能にしておきますので、上記の投票用コードのスプレッドシートでまだ使われていないものを探して、https://bit.ly/KinokoTakenoko に入力してみて動きを観察してみてください。

docs.google.com

CSSx2.0 in CSS2018での利用結果

このシステム、だいたい構築に半日(午後いっぱい、というイメージ)という短時間でほぼ構築できた(一番時間がかかったのは投票用紙のレイアウトと印刷・裁断)というお手軽システムの割にはうまく動かせたと思います。CSS2018ではこれをつかって集計しましたが、その結果の概要は以下の通りです。

  • 総得票数:207票
  • うち紙で投票されたもの:4票
  • 有効投票数:191票
  • 無効コードによる投票:4票
  • 重複投票:12票(同一コードによる2回投票5、3回投票2、4回投票1)
  • 最高10秒間に12票、5分間に71票を処理

まぁ性能としてはこの規模なら十分かと思います。ただ、残った課題もありまして…

まず、Googleフォームで投票完了時、重複投票や無効な投票用コードによる投票を注意するようなメッセージを出したいのですが、この部分に出るメッセージは動的に変更できない*14のでできません。つまり、自分がその投票用コードを使って投票したかどうか思い出せないような人はもう一度投票するしかないわけですが、その投票が実際に重複だったのかどうかを確かめる方法がないのです。これはGoogleフォームの制限なので、他のなにかよいシステムで作ればいいのですけど、Googleフォームの手軽さと性能の高さ、堅牢さはなかなか得難いものがあるので、まぁ「簡易なシステム」なのでご勘弁くださいというところでしょうか。

もう一つの課題は集計です。とはいえ、エラーチェックと重複チェックは終わっているので、集計スプレッドシートをダウンロードしてExcelでちょっと作業すれば集計できるのですが、そこもGoogle Apps Scriptで自動化してしまいたいなと思ってます。これはもう少し頑張ればできる程度のコーディング量なので*15、また暇をみてやってみたいと思っています。

12月15日追記

暇じゃないのに逃避でやっちゃった…集計用のシートを加えるならすぐできるなと思ってしまい。

投票集計のためのGoogle Apps Script(Ver.2)

おわりに

コーディングという意味ではほんの少しだったのにblogにまとめると思ったより大作になってしまいましたけど、「投票」っていうものをもし管理する必要にかられた方がいたら、何かのお役に立つでしょうか。

さて、Advent Calendar10日目の担当はnakarioくんです。といっても、もう記事が出ていますね。

nakario.hateblo.jp

超人ロック!私が学生だった30年以上前はもちろん、そのさらに前から40年近く、KMCで盛んに遊ばれてきたゲームです。超人ロックという作品は根強いファンがいますが、このゲームがこんなに長く遊ばれてるコミュニティはKMCぐらいじゃないかと思います。是非記事を読んでその魅力に触れてみてください!

KMCM

KMCは、年齢所属居住地など問わず誰でも入部できます。実際現役女子高生もいれば私みたいなおっさんもいますし、京都周辺に限らず東京にも九州にも部員がいます 。コンピュータを使って「何か」をしたい人は是非ご連絡を。

www.kmc.gr.jp

また、もうすぐ平成最後のコミケですが、この冬もKMCは日-東タ31aに出ていますのでお立ち寄りください*16。Webカタログにアクセスできる方は、こちらへどうぞ

いじょ。

*1:予約Tweetを使って、素数日当日の夜中に呟くように設定をしています。

*2:まだ煮詰まっていない研究の紹介や、場合によっては冗談のような発表を集めたセッションで、よく夜に行われる。CSSの場合にはネタ色が強いです。

*3:ネタはマイナンバーのチェックデジットがおかしい話でした

*4:なぜかEdgeでは動かないようですが…そういやEdgeもChroniumベースになるんですねぇ

*5:英大文字の文字コードが65から90であることを利用してCHAR( RANDBETWEEN(65,90) )を文字数だけ繰り返してるだけです

*6:26^{10}のものから1000個選ぶ時の重複の確率はだいたい1-e^{-(1000*999)/2*26^{10}}なので10億分の3.5くらい。

*7:直接csvでダウンロードすることもできるが文字コードがUTF8なので日本語の見出しが文字化けしてしまう

*8:あの点3つとか線3本のメニューアイコンの正式名ってあるんですかね?欧米人はkebabとかburgerと呼んでるようですが…

*9:よくレイアウトがわからなくなるという話もありますが、あれは図表に「アンカー」というものが位置決めのために存在していることがわかれば使いこなせるようになります。ただそのアンカーが、実にWordのシステムとしての構造の都合で決まっているものなので、普通の人には評判悪いのでしょう。プログラマとしては理解できる方法なので受け入れられるのですが。

*10:この「宛先」という表現が分かりにくいのですが、住所録(Address Book)のことのようです。要は差し込み印刷の元データなら別に住所録相当のものでなくとも選択すればよいのです。

*11:ここで「差し込み印刷の開始」を選びたくなりますが、無駄なこといっぱいやってくれるので使わない方がマシです…私はまず使わなくなりました

*12:余談ですが、このバーコードフィールド、私は特に1次元バーコードを良く活用しています。1次元バーコードのリーダが安いので(今や3000円ほどです)、例えば学生に配る小テストは回答用紙に学籍番号と名前を印刷しておいてものを配って、回収後これをバーコードリーダで読み取って集計するExcelマクロを組んで処理したりしてます。QRコードは最近、スキャンデータをPythonで読み取って処理するのを始めてますが、手軽さでは1次元バーコードの方がずっとよいですね。

*13:個人向けのGoogleアカウントとGsuitesアカウントで少し違うようですが、ここでは個人向けGoogleアカウントの例です

*14:おそらくセキュリティを担保するのが難しいからだと思います

*15:今回は、投票を数えた結果をさらに別のスプレッドシートにまとめるほうがよいけど面倒だな、という理由でやめました

*16:私もKMCブースでないどこかにいると思います

3つの事件で振り返る「何をやったらウイルス罪で捕まるか2017」

この記事はkmc-id tetsu (id:tetsutalow)によるKMCアドベントカレンダー2017の24日目の記事です。遅刻です。

adventar.org

23日はwass88くんの予定だったのですが現時点ではまだ上がってないですね。「年内・・・」だそうですので、年内にはupできるように頑張って下さい。かくいう私もすっかり忘れてて慌てて書いてるので遅刻です。そもそもブログエントリそのものがほぼ1年ぶりじゃないですか困ったなぁ。

はじめに

メリークリスマス、Tetsu=TaLowです(kmc-idはtetsu)。KMC 31回生です。今年もKMC最年長ヒラ部員を続けてます。昨年書いた素数秒記事が思いのほか楽しかったので、今年も勢いでエントリしてしまいました。来年にはついにKMC 32回生、片手で数えられなくなってしまう*1のね・・・

さてこれを書き始めた日はクリスマスイブだったのですが、間に合わずクリスマス当日になってしまいました*2。クリスマスと言えば国産初のウイルスとも言われる*3クリスマスウイルス」が思い出されますね(強引)。あれは1989年のことで、思えば当時はウイルスと言えばイタズラでしかない牧歌的な時代でした。あれから30年近くが経った現在は、非常に犯罪性が高いマルウェアが大量に生み出され跋扈している大変な時代です。しかしそれらの攻撃は「目に見えない」ために、被害者本人にすら気がつかれず、話題にならないという厄介な時代でもあります。今年を代表するウイルスと言えば5月に大規模なパンデミックを起こしたWannaCryがありました。とはいえWannaCryは日本では比較的被害が小さくて済みました*4し、解説する記事もいっぱい出てますので、ここでは扱いません。今日書くエントリはそんな話ではなくて、今年、日本でウイルスに関する罪で逮捕されたり、逮捕されそうになった事案でちょっと気になるものがあったので、振り返りながら書いてみたいと思います。

事件その1:日本初の「ランサムウェア作成による逮捕」事案は14歳の少年

WannaCryの騒ぎの後、6月はじめにこんなニュースが出回りました。

digital.asahi.com

このニュースは、日本では初めてのランサムウェア作成者の逮捕だったこと*5と、この作成者が14歳だったことで話題になりました。

しかしこのランサムウェアと称するもの、内容は単なるバッチファイルでして、技術的にもかなり稚拙な*6内容です。しかも、暗号化に使った鍵をそのままディスク内に残してしまうので、実際に使われたとしても暗号化されたデータはすぐに回復できる作りでした。詳しくはid:Kangoさんのまとめをどうぞ。

d.hatena.ne.jp

このことが明らかになるとネット上では「これで逮捕されるの?」という感想が駆け巡っていました。その後私の所に毎日新聞から取材がありまして、お答えしたものが記事になっています。

身代金ウイルス逮捕の中3 おもちゃレベルでも作成罪?(毎日新聞)

本件ですが、神奈川県警が作成者の逮捕に踏み切ったのはウイルスの動作やその出来よりも、作成者に明確な目的があることを重く見たのではないかと感じます。不正指令電磁的記録に関する罪はこんな条文です。

第168条の2 正当な理由がないのに,人の電子計算機における実行の用に供する目的で,次に掲げる電磁的記録その他の記録を作成し,又は提供した者は,3年以下の懲役又は50万円以下の罰金に処する。
一 人が電子計算機を使用するに際してその意図に沿うべき動作をさせず,又はその意図に反する動作をさせるべき不正な指令を与える電磁的記録
二 前号に掲げるもののほか,同号の不正な指令を記述した電磁的記録その他の記録

この条文が成立した直後に法務省が公開した「いわゆるコンピュータ・ウイルスに関する罪について」では、この罪が成立するには

  • 「正当な理由がないのに (正当な理由の不存在) 」
  • 「人の電子計算機における実行の用に供する目的で (目的) 」
  • 「 第1号又は第2号に掲げる電磁的記録その他の記録を (客体) 」
  • 「作成し,又は提供した (行為)」

の全てが満たされていることを必要とするとしています。このうち「目的」は人の内心の問題なのでウイルス罪の捜査の上で疎明するのが難しい点なのですが、この少年がTwitterで呟いていた内容を見る限りは「ヤル気満々」だったので、目的は十分あると見られてしまったのではないかと思います。本件がTwitterでの書き込みを発端として立件されている点も含め、ここがクリアされているのであれば、客体としてのウイルスの出来が少々稚拙でも、一応ランサムウェアとして動作するようになっているので立件した、というような印象です。

なお、このランサムウェアによる被害はなかったと考えられますが、ウイルス作成罪は被害の有無にかかわらず罪としては成立するので、その点は関係ありません。そのことも、多少出来が悪くても明確な目的を持って作られた以上ウイルスであると判断された理由になっているかもしれません。

ということで事件その1の結論は「少々ウイルスとして出来が悪くても、他人に感染させて悪意ある動作をさせることを明確な目的としてプログラムを書くと、捕まる(ことがある)」です。

事件その2:Shareのキャッシュを持っていたらウイルス保管罪

2つめの事件は、世間ではそれほど話題にならなかったけれどもセキュリティ業界的にはかなり大きな衝撃が走った事件でした。

itpro.nikkeibp.co.jp

ditはP2Pファイル共有ソフトShareの監視業務を行っています。Share上で蔓延している情報漏洩ウイルス(Antinnyなど)は、感染したPCからあらゆるファイルがShareネットワーク上に流出してしまうので、企業などから営業秘密が流出したりすることがあります。ditが行っていたのは情報漏洩ウイルスが流出させたファイルを収集して、その中に委託を受けた企業等に関連するファイルがないか監視することなのですが、そういった流出ファイル内にもそのウイルスが入っています。ですので、その収集をShareそのものを使って行うと、P2Pファイル共有の性質上ファイルのダウンロードと同時に再送信が始まってしまうので、ウイルスを再配付する結果になりかねません。そこで普通はShareのファイル送信機能*7を殺して運用するものですが、ditはどうもそれをちゃんと行っていなかったようです*8。報道によると、情報漏洩ウイルスに新たにファイル感染した人がいるのを受けて*9、Shareネットワークを「サイバーパトロール」で追いかけていた結果ditが運用していたノードに行き着き、このノードがウイルス入りのファイルばかり大量に保持していること*10、そのノードから実際にファイルのダウンロードが行われることが確認されたことが今回の捜索や逮捕に繋がっているようです。なお、それならウイルス保管罪ではなく供用罪で立件するべきなのでないかという意見もありそうですが、供用は具体的に特定の被害者が当該ノードからファイルを受信した事実を疎明せねばならず、それは容易ではないので証拠がすぐ揃うウイルス保管罪で立件したのだろうと思います。

しかし本件、セキュリティ業界的にはかなりの影響がありました。

PCウイルス「保管は罪?」 監視会社社員の逮捕波紋 : 京都新聞

itpro.nikkeibp.co.jp

ditの主張は前述の4条件のうち「正当な理由がない」「目的」の2点が成立しないのでウイルス罪にあたらない、とのことでしたが、特に論点は目的になります。ditはセキュリティの会社ですから、この監視システムの運用によってウイルスが再配付されてしまうことは当然認識できたはずですから、それでも運用してきたことをもって「目的」の要件が足るとするか否かという議論になると思います。目的にも未必の故意が成立しうるかは、犯罪の類型によって多少異なるものの一般にはあり得るようですので、「他人に感染することがあるかもしれない」との認識で目的は成立する、という判断もあり得そうです。となると、ウイルスの研究や対策ソフトウェアの開発の過程においてウイルスが漏れてしまう可能性はないとは言えないので、保管が罪に問われるのではないか?という懸念がセキュリティ業界に走ったのです。特にハニーポットは一般的にはウイルスの再配付が起きないように工夫しますが、その工夫をすり抜けてウイルスの再配付が起きてしまった場合に、ウイルス供用罪や保管罪が問われるかもしれない、という懸念は私も感じました。特に、目的犯の場合それは内心の問題ですから、外形的に上記4条件のうち3条件が満たされていそうで、目的の部分だけが不明なら、警察はとりあえずは事情聴取、そこで不審な点があれば逮捕して調べようとするでしょう。

結果的に本件は逮捕された社員はすぐに釈放されましたし、組織としてのditにウイルスを拡散させる明確な目的意識があったとは言えないでしょうから、証拠不十分になりそうで起訴は見送られるのではないかと思います。ただ、逮捕されてしまうとそれだけで社会的制裁が下りてしまう世の中ですから、「どの程度の状況であれば外形的にウイルス供用の目的が『あるかもしれない』と警察が感じて動き出すか」はセキュリティ研究者として気になるところですし、広義では警察関係者でもある身*11としては、セキュリティ業界の肌感覚を警察内に伝えていく努力をしたいと思います。

ということで事件その2の結論は「自分が管理するシステムから誰かにウイルスを感染させてしまった場合、そのシステムも他に感染させられたなど被害者であることが外形的に判断できなければ、警察が事情聴取や逮捕で目的を調べようとするので、捕まる(ことがある)」です。

事件その3:Bitcoin暗号通貨*12のマイニングを行うWebアプレットはウイルス供用か?

今年はBitCoinが高騰したこともあって、暗号通貨の採掘を行うマルウェアが流行りました。比較的昔からある採掘botだけではなく、スマートフォンのアプリ内で暗号通貨採掘とかも結構あったようです。そんな中、Webサイト訪問者にJavaScriptが送り込んでブラウザ内でマイニングさせるなんて手法が現れまして物議を醸しました。

mainichi.jp

特に有名になったのはイケダハヤトさんが自サイトに仕掛けて非難されたからですね。

news.yahoo.co.jp

この件、単に行儀が悪いだけではなくて、ウイルス供用罪に当たるのではないかという議論があります。

www.nikkei.com

上記記事から引用しますと

仮想通貨技術などに詳しい斎藤創弁護士は「サイトの閲覧者に告知せず意図に反してマイニングをさせる行為は、不正指令電磁的記録供用罪などに当たる可能性がある」と指摘している。

・・・そうです。

このスクリプトが前述のウイルス罪4条件のうち「客体」にあたるのでしょうか。そもそもブラウザ内のスクリプトがウイルス罪に問われるかといえば、他でもない最初の検挙事例がブラウザクラッシャーだったりしますので、「問われる」が答えになります。なので論点になるのは「人(この場合はサイト訪問者)の意図に沿う動作」ではないか、つまり「告知していたかどうか」なのですね。告知が行われていればサイト訪問者の意図に反する動作にならないのでウイルスにならないが、告知がなければウイルスではないか、という論点です。しかし例え告知を行ったとしても許されることではないという風潮も強いようで、実際各社のウイルス対策ソフトウェアがこの手のスクリプトをウイルスと判断して除去したり、サイトを遮断したりする方向になっているようです。

この議論、Web広告とのバランスが悪く、私個人はちょっと気持ち悪いです。Webサイトを運営するのももちろんコストが必要なので、閲覧者から何らかの形でそれを回収しようとするのは正当な行為だろうと思います。現在、Webサイトにおける広告で賄うことは広く行われ、人々に受け入れられています。それが暗号通貨になった途端に世間の目が厳しくなるのは、広告と違って「裏でこっそり行われるから」なんでしょうか。では告知すればOKなんでしょうか。世の中には目障りなWeb広告より演算能力の提供の方がよいという人もいそうですし、実害という意味でも、特にスマートフォンにおいてマイニングによるバッテリーの消費と動画広告によるパケットの消費なら、どちらが深刻な被害かは悩ましいところです。何より気持ち悪いのは、広告はスクリプトが入っていなければプログラム=指令電磁的記録ではないのでどれだけ迷惑をかけてもウイルス罪の射程に入らないのに、スクリプトになった途端に被害の大小にかかわらずウイルス罪になりうるという構造にバランスの悪さを感じてしまうのです。

話がずれましたが主題に戻りますと、この事件3の結論は「Webサイト内のJavaScriptでも、サイト訪問者の想像外にあるような動作をさせ何らかの被害を与えることがあれば、ウイルス供用罪に問われる(かもしれない)」です。とはいえWebブラウザの計算能力をサイト閲覧の対価として支払うというアイデア自体は私は割と好みでして*13、何とか合法的にできる方法が欲しいなと思ってしまいます。例えば、どうしてもWebサイトで暗号通貨を採掘したいなら、「このサイトの閲覧にはハッシュ計算X回が必要です、実行して良いですか?」と事前に聞いてきた上でサイトを表示するような構造にすればいいんじゃないでしょうかね。

おわりに

ということで、実はウイルス罪というのはちょっとヤンチャなことをすると問われうる、割と身近な犯罪であることが実感していただけたでしょうか。すっごくザックリまとめますと

  • 出来が悪くても「ヤル気満々」で作ればウイルスはウイルスとして罪に問われるから気をつけて。演習とか研究とか目的をはっきりさせて作って、供用にならないように隔離環境で試すべき。
  • ウイルス持ってるだけで罪に問われる訳じゃないから安心して。自分が感染して結果として他人を感染させてもそれは過失なので罪には問われないはず。ただ感染していることをはっきりと認識したままずっと放置してたら未必の故意を問われかねなくなってくるので、早く対処しましょう。
  • Webサイト上のスクリプトだってウイルス罪に問われうるので行儀の悪いことはしないように。閲覧者の想像外のことが起きるような状況だったら、告知などの工夫をした方が安全ですよ。

って感じでしょうか。とにかく今回起きた3つの事件(ひとつは事件未満ですが)が、セキュリティ研究者の萎縮に繋がらないことを祈ります。

さて、もうKMCアドベントカレンダー2017の最後を飾るのはid:inonoaくんの「まずは同人誌をかけ」です。もうUpされてますね素晴らしい!

inonoa.hatenablog.com

そしてもうすぐコミケですね。そういや懸案だった2020年の夏コミ問題も決着しまして、GW開催になったようですね。少しホッとした気分でコミケを楽しめそうです。KMCは金曜日 東ク33bに出展してますので、起こしの方は是非お立ち寄り下さい。

あと、KMCのもう一つのアドベントカレンダーである「お絵描きカレンダー」もよろしくお願いします。

adventar.org

いじょ。

*1:5bitに収まらない

*2:細かいことをいうと、当時の暦は日没が日の区切りだったので、24日の日没から「クリスマス」です

*3:PC-9801に感染したというだけで、本当に「国産」なのかはわかりません

*4:Windows Updateをちゃんとしていれば感染しないし、それが出来てなくてもport445を塞いでいれば感染しなかったので、比較的ブロードバンドルータでのフィルタが効いている日本では感染しにくかったのではないかと思っています

*5:神奈川県警はそう発表したのですが、2015年に不正アクセス等で逮捕された少年がランサムウェアを作っていたことが捜査の過程で分かっています。少年だったので再逮捕とされず立件されてないからノーカウントってことなんでしょうけど。

*6:例えば、内部でaescryptとopensslを使っているので公開鍵暗号使ってるのかと思って見たら結局単にaesで2回暗号化してるだけという・・・

*7:厳密にはファイルそのものではなくてファイルのキャッシュの断片ですが

*8:同じP2Pファイル共有ソフトでもWinnyはファイル再送信をしないようにする設定がありますが、ShareにはないのでShareそのものを改造するか新たに互換プロトコルでダウンロードだけを行うクライアントを開発するしかありません

*9:実際に被害者がいたとの報道は読売新聞しかしてないのがちょっと気になりますが

*10:情報漏洩ウイルスからの漏洩ファイルばかり集めていると結果的にそうなる

*11:他ならぬ京都府警のアドバイザーを務めていますので・・・

*12:当初BitCoinと書いてましたが、Coinhiveなど今回使われたサービスはMoneroではと指摘を受けて暗号通貨にしました

*13:かつてグリッドコンピューティングが華やかだった頃にSETI@HomeFolding@Homeって流行りましたよね、あれはボランティアでしたが、あの頃ああいうサービスから収益を得られないかと真剣に考えていた人たちがいたのを思い出します。Pay by powerと呼ばれるコンセプトでした。そもそもBitCoinそのものが「システムの運用のために計算能力を差し出して対価を得る」システムですから・・・

税抜きでも税込みでも素数になる価格

これでちょっと気になったので逃避を兼ねた小ネタ。

消費税素数の検索

京大の素数ものさしが税込み売価が577円で、税抜きだと素数にならないことに端を発して、税抜きでも税込みでも素数になる価格を探すことにしました。またJavaScript書こうかと思ったらOrionがまた重くて役に立たないので、手元のPython3でざっと。素数判定はsympyパッケージに頼りました。

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import math
import sympy
for i in range(1,1000000):
    fi=math.floor(i*1.08)
    ci=math.ceil(i*1.08)
    if(sympy.isprime(i) and sympy.isprime(fi)):
        print(i,fi,end=" ")
        if(i*1.08-fi<0.5):
            print("切り捨て・四捨五入")
        else:
            print("切り捨て")
    if(sympy.isprime(i) and sympy.isprime(ci)):
        print(i,ci,end=" ")
        if(ci-i*1.08<=0.5):
            print("切り上げ・四捨五入")
        else:
            print("切り上げ")

税抜き価格100万円までの間には、税抜き税込みとも素数になる組合せは10901通りあるらしいです。

1223は素数だけど20161223は素数じゃなかった~素数秒の提案~

この記事はkmc-id tetsu(id:tetsutalow)によるKMC Advent Calender 2016の23日目の記事です。

www.adventar.org
昨日はkmc-id base64(id:basemusi)さんの記事「いい感じのメドレーを自動生成したい」でした。素晴らしい。きっと自作で特定のアニメの主題歌挿入歌などなどメドレー、なんてのを気軽に作ってカラオケとかできますね。

basemusi.hatenablog.com

ごあいさつ

あらためましてこんにちは、京大マイコンクラブ(KMC)部員のtetsuです。KMC的には10期生です。30回生です*1。OBではないのかと思われるかもしれませんが、今でも部費を払い続けているので*2身分は部員なのです*3。京大で教員してた頃は顧問をしていた気がしますが、今は京大を離れたのでまたヒラ部員をしています。ヒラ部員らしく、たまにはAdvent Calendarにも参加してみようかなと思い立ってエントリを立てた次第です。

そのKMC Advent Calender 2016もあと残すところ3日、これまで他の部員たちによる楽しいエントリが並んでおり、とても役に立ったり勉強になったりするものも少なくないのですが、私は全く役にも立たず毒にも薬にもならないエントリで参加しようと思います。よろしくお願いします。

今年の素数素数日あれこれ

年も押し迫ってテレビ等で10大ニュースなども流れるようになりましたが、今年初めの大きなニュースといえばなんといっても、現時点で最大のメルセンヌ素数が見つかったことでしょう。新聞などでも数学に関する記事にしては大きく取り上げられましたね。

wired.jp

www.asahi.com

本当は発見されたのは去年の9月だったんですけどね。

それに比べれば小さなニュースですが、今年は北米での素数蝉(17年ゼミ)の大発生*4も話題になりましたね。

www.tenki.jp

米国のセミはちゃんと数学がわかるようで羨ましいですね。日本のセミは個別には7年とか地中にいるようですが、我々にとっては毎年鳴くので節操がなく思えます。それとももしかして、日本のセミは1を素数に復活させよと主張しているのでしょうか。

さて、素数愛好家界隈でメジャーな遊びに「素数日」を探したり愛でたりすることがありますよね。素数日の定義は本来いろいろ考えられますが、最も一般的な定義は西暦表記の年月日を8桁の数字で表したときに素数になる日のことを言うようです。例えば今日の日付である1223は素数ですが、これを素数日と呼ぶ人はあまりいないんじゃないでしょうか。一方20161223は残念ながら素数日ではないのですね。思わずテンション下がりますね。

そもそも2015年は例年になく素数日が少なく、13日しかありませんでした。その余波か、今年のはじめ頃には2ヶ月ほど素数日がないという日々を過ごさねばなりませんでした。そして、12月にも素数日がないのですよね。まとめると2016年の素数日はこんな感じでした。

tetsutalow.hateblo.jp

2016年は19日と、年あたりの素数日としては平均的日数が確保できた年でした(しかも19も素数)が、1月2月12月になると素数日がなくなるという、寒さと素数欠乏症のダブルパンチに耐えねばならない年でした。しかし、双子素数日(ここでは単純に2つの素数日が双子素数を構成している日と定義します)が2組もあって、それに救われた感があります。ついでに双子素数日を探すプログラムをJavaScriptで書いておきましたので、おいておきますね。

双子素数日を探す

では来年はどうでしょうか。2017年、6年ぶりの素数年には、今年と同じく19日の素数日があります。

20170121
20170219
20170223
20170301
20170303
20170331
20170421
20170511
20170519
20170607
20170627
20170807
20170831
20170901
20170903
20171017
20171101
20171201
20171219

来年も双子素数日が2組ありますね…それに加えて、来年8月末から9月頭にかけて、なんと2日続けて素数日という日があるではないですか。これは2002年5~6月以来、実に15年ぶりの出来事です。連続素数日を探すプログラムも置いておきますね。

連続する素数日を探す

そういえば2016年は素数年ではありませんが4で割り切れる年ですから、夏季オリンピックの年でしたね。次の2020年の東京オリンピックパラリンピックを楽しみにしている方も多いと思いますが、2020年は素数日にとっても記念すべき年です。

20200109
20200111
20200121
20200123
20200223
20200309
20200429
20200511
20200529
20200613
20200619
20200703
20200711
20200721
20200723
20200729
20200801
20200813
20200903
20201021
20201029
20201101
20201113
20201227
20201231
20210101

特別に2021年元旦まで加えておきました。御覧のとおり2020年は「毎月素数日がある」「双子素数日が2組3組ある*5」そしてなんといっても「年またぎの連続素数日がある」という大変素数日的には充実した1年になる予定なのです。年またぎ連続素数日は1987年末以来33年ぶりの出来事であり、この次は2029年末とすぐに訪れますが、さらに次となると2161年末までない、そのころにはドラえもんが生まれてる*6というほどの珍事です。さらにその次は2383年末なので、それまでに我々はガミラス*7クリンゴン*8奇居子*9を迎え撃たねばなりません。話が脱線しましたが、このように2020年は特別な年なので、とても楽しみになってきましたね。

素数不足解消のための素数秒の提案

しかし、いくら素数日を愛でていても少し物足りなくなることはないでしょうか。素数は無限にあるのに、なぜ月に1~2度あるかないかの素数日をこんなに待ち焦がれないといけないのでしょうか。そこでそんな素数不足を解消したい人のために、新たな概念を持ち込みましょう。それは「素数秒」です。

素数秒はここでは、年月日時分秒を14桁の数字で表した時に素数となるものとします*10。例えば2016年12月23日0時0分53秒を20161223000053とすると素数になりますので、これが素数秒です。ちなみにこれが本日最初の素数秒ということになります。2017年最初の素数秒は元旦の0時0分1秒、つまり20170101000001です。ちなみにこの日はIT業界の敵、うるう秒がありますね(日本時間で8時59分60秒)。素数秒は幸い、うるう秒対応する必要がありません(うるう秒は必ず非素数秒です)。

この素数秒、1日にどれくらいあるでしょうか。ちょっとプログラムを書いてみました。

素数秒を探す(試し割り版)

…遅い!さすがに14桁は8桁とはわけが違います。私の環境*11では30秒くらいかかりました。しかしその甲斐あって、本日12月23日は素数秒が2871回あることが分かりました。平均的には30秒に1回程度、我々は素数秒を楽しめることになります。

しかし遅いですね。残念ながらこのプログラム、単純に各素数候補素数で試し割りしてるだけ( nまで列挙なら O(n \sqrt{n}))なので、計算量的にはエラトステネスの篩( nまで列挙なら O(n \log{\log{n}}))のほうが有利のはず。実際には区間で求めてるので単純じゃないしどうかなと思いながら、区間エラトステネスのふるい(ナイーブな方法)でも実装してみました。

素数秒を探す区間エラトステネスのふるい版)

…せいぜい倍にしかなりませんね。エラトステネスのふるいの速度は計算量もありますが、コアのループの計算の単純さでも効いてくるので、60秒の区間ずつふるうのではあまり速度効果が出ないのでしょう。実はこの後、John Moyerに倣って11や13以下の素数でふるった後のビット列を使ってやれば少しは速くなるかなと試していたのですが、やはりJavaScriptでは複雑さが効くのか大して高速化できない上に、途中でOrionHubのバグを踏んでしまったらしくソースコードをゴミデータで上書きされてしまいメゲたので、これはもうここまでにしておきます*12

さて、この素数秒を愛でるにはどうすればいいでしょう。まさか時計と素数秒の表を見比べながら次の素数秒を今か今かと待ちわびる、というのはバカバカしいので、こんな時計を作ってみました。名付けて「素数秒時計」です。

f:id:tetsutalow:20161223135302p:plain

…デザインセンスがない点についてはご容赦下さい。機能としては、現在の時刻と共に、次に訪れる素数秒を表示します。素数秒ではない現在時刻については、その非素数秒を素因数分解したものを下に表示するようにしてみました。こうすることにより、素数秒以外の各秒でも、さまざまな素数との出会いが目を愉しませてくれます。これで素数欠乏症も怖くありません。きっと舘ひろしさんも喜んでくれると思います

この素数秒時計をデスクトップに表示してじっと眺めていると、あたかも素数階段を一歩一歩登るような喜びが味わえます。平均的には30秒に1度とはいえ、やはり素数らしくその間隔には不思議なばらつきがあります。不意に訪れる、次の素数秒との長い空白を息を潜めて待つも良いですし、突然目に入る「双子素数秒」との出会いも楽しいものです。皆さんもぜひこの「素数秒時計」で、充実の素数ライフを!!

 さて、明日はいよいよクリスマスイブ。KMC Advent Calender 2016の明日の担当は、kmc-id hakurin(id:hakurin070706)さんです。明後日のKMCお絵かき Advent Calendar 2016ともども、頑張ってください!

www.adventar.org

*1:つまりKMCは来年40周年を迎えます。

*2:現時点でKMCの歴史の75%の期間部費を払っています。その間、部費の値上げはなんと1度しかありませんでした。

*3:KMCは入部に際し所属身分年齢性別国籍宗教その他何の制限もありません。実際、最近はネット部員的な人も増えてきています。まだ人類以外が入部申請してきたことはないようですが、規約上は宇宙人でも大丈夫だと思いますので、個人的には、ツノがあってトラジマビキニを着ていて空を飛べる女性の入部をお待ちしています。

*4:実はWikipediaをよく読むと今年の年次集団はそれほど大きくない群らしいです。ニュースを見かけたので書いちゃいましたがよく調べるべきでしたね。

*5:最初見落としてましたAKさんありがとう

*6:ドラえもんは2112年9月3日生まれ。この日は素数日ではありません。

*7:ガミラスは2192年来襲、2199年には地球防衛軍が敗北しヤマトがイスカンダルへ向かう予定です。

*8:U.S.S.エンタープライズ就航は2245年ですが、2293年にはクリンゴン帝国とキトマー条約を締結します。2383年はボーグとの戦いの最中ですね。

*9:奇居子の地球侵攻は2371年。

*10:コンピュータ屋としてはUNIX timeで定義することもちょっと頭を過ったのですが、2進法の美しさと素数の美しさはベクトルが違うように感じたので止めました。

*11:VAIO S11(Core i5-6200U 2.3GHz)にWindows 10 64bitとChromeバージョン 55.0.2883.87 m (64-bit)

*12:ようやく、Advent Callendarのお題の「KMC」らしい話題になりました。

日本の大学で情報セキュリティを学ぶには

私が何気なく、しかも初めて書いたYahoo!知恵袋への回答が思わぬ広がりを見せるという事件?が起きました。

detail.chiebukuro.yahoo.co.jp

さっと(割と慌てて)書いた私の回答の足りなさや、違った見方を補おうとされてか、色んな皆さんが乗っかって下さって素晴らしい回答を寄せて下さって、 結果としてすごい回答集に。そして、果てはWeb記事化される事態に。

www.itmedia.co.jp

これ、最初は徳丸浩さんが回答に立命館大を挙げて頂いたのを見て、有り難い話なので私も何か書かねばと最初このblogにエントリを書きかけてたのですが、忙しくて書き上がるのに間が空きそうだったので知恵袋に急遽登録して勢いで投稿したものでした(しかも東京出張の新幹線車内で)。中身は概ねいつも言っていることでして、要するに

  • セキュリティを学ぶにはまず情報科学の基礎体力をつけなくてはならない。大学で体系立てて集中して学ぶべき。
  • 情報収集と自学自習が大切なので刺激を受ける機会が必要。そのためにコミュニティへの参加を。

この2つに集約されると思っています。かつてこのblogで書いたことにも重なりますね。

tetsutalow.hateblo.jp

ところで、元の質問主は関西の「私学」を求めておられました。候補に挙げられたのは関大の総合情報学部でしたが、知恵袋にも 回答を寄せられた小林孝史先生(名乗っておられないですがすぐわかりますよね)や、 暗号がご専門の桑門秀典先生を意識されたのでしょうか。 関大を挙げられる程度の学力をお持ちとなれば、多分選択肢は関西だと立命館になるだろうなと思って、知恵袋ではあんな感じの回答を書いたのですが、高2でもう私学に絞るなんて勿体ない、国公立も目指したらいいのにと思ってしまいました。早くから受験を私学に絞りたいという受験生は多くの場合、受験科目数の少なさに魅力を感じてるようですが、そこはなんとか踏ん張って国公立大も受けられるように勉強をしておいた方が後々大きく役立ちますから。

というわけで、実はあの知恵袋への回答を返す前には、国立大も関西以外も含めた日本の大学でセキュリティを学ぶことについてエントリを書き始めていたのですが、収拾が付きそうにないので慌てて知恵袋自体に書いた次第。 でも書きかけのモノがあるので少しだけ掘り起こしてこのエントリを作りました。以下は掘り起こした文章です。高校生とその保護者や進路指導担当の皆さんに向けたものとして。


さて、大学でセキュリティを学ぶにはどういう選択をすればいいんでしょう。そもそも「セキュリティ」関連人材っていっても求められる能力は様々です。最近JNSAがセキュリティ知識分野(SecBoK)人材スキルマップ2016年版を公表しましたが、その作成に私も参加させて頂く中で、改めてこの業界で働く上で必要なスキルの幅広さを感じました。

www.jnsa.org

ここで挙げられるような、技術からマネジメントに渡る広いスキルを身につけられるカリキュラムを持つ大学は、学部レベルでは長崎県立大の情報セキュリティ学科しかなさそうです。このカリキュラムがうまく回れば素晴らしいセキュリティ人材が育成できそうですね。

ただ、個人的にはこのカリキュラムの理想を実現すること、またこのカリキュラムを消化できる能力のある学生を集めるのは、かなり大変だろうと感じています。 正直なところ、うち(立命館)に来る学生さんには、学部レベルからマネジメント関係を教えようという気にはなりません(話としては触れるかもしれませんが)。 学生の消化できる量を考えると広く薄くやっている余裕はないので、まずは情報科学の基礎とセキュリティ関連技術をしっかり身につけてもらう方が良いと感じています。

ということで、セキュリティを大学で学ぶには、学部時代にはカリキュラムを良く見て、計算機の構成、OSなどの基本ソフトウェア、プログラミング、ネットワーク、 暗号技術について学ぶことができるところを選ぶと良いかと思います。特にプログラミングとネットワークに関しては演習があるところがお勧めです。 このようなカリキュラムを持つ大学なら比較的選択肢は広くなると思います。

最近の大学はどこでもカリキュラムやシラバスを公開していますので、どのような講義が開講されておりどのようなことが学べるのか調べるのも簡単になりました。 例えば立命館大学情報理工学部ではカリキュラムこちらに 主な科目名とともに書かれています。この科目名をこちらのシラバスに入力すると、 どのような内容が講義されているのかよく判ります。他の大学も同様になっているので、ちょっと手間ですけど、是非見てみて下さい。

次に、大学院に進むべきか否かですが、これはセキュリティに関しては是非、修士課程に進むことをお勧めします。残念ながらセキュリティは求められるものが 広く、学部だけではとても全てを学びきれません。上記のSecBoKにあるようなスキルの多くについて、 少なくともそれがどのようなものであるか理解するという段階に達するだけでも、 大学院での学びと経験は必要になると思います。大学だけでは技術的セキュリティの基礎で精一杯ですが、大学院まで進むと 人的セキュリティや運用のセキュリティを含むマネジメントについても学べる機会が格段に増えます。 逆に言えば、そういうことを学ばせてくれる先生がいらっしゃる研究室に配属されるよう、進路を選ぶ必要があります。 大学院の場合は(SecCapなどいくつかの特別プログラムを除けば)講義より、研究室(ゼミ)での研究活動を 通じた学びの方が重視されるからです*1

また、大学院は大学とは違うところに行くこともできます。大学院になるとセキュリティを専攻するところが増えますし、そもそも大学院大学が 選択肢に入ってきます。例えば情報セキュリティ大学院大学は教授陣の層が厚く、守備範囲が広いので、 様々なことが学べるでしょう。また、兵庫県立大学の大学院応用情報科学研究科カーネギーメロン大学(CMU)とのダブルディグリープログラム を持っていますので、セキュリティ分野の最高峰の一つであるCMUの教育を受けることも出来ます(授業料が高いですが…)。 そして奈良先端科学技術大学院大学などの大学院が連携して提供しているSecCapというプログラムは 本当に幅広い講義と演習が含まれているので、セキュリティについて大きな力が付くと思います *2

いずれにせよ、大学院は本当にどの研究室に配属されるかでやりたいことが出来るかが変わるので、 目指す大学院にどのような先生がおられてどのような研究をされているかよく調べるべきです。 大学院の各専攻の教員や研究室の一覧はWeb上にありますし、パンフレットなどが整備されている場合もあります (例えば立命館だと学部の研究室がこのように一覧になっていて、簡単な研究紹介があります。 大学院情報理工学研究科が情報理工学部と一体になっているってことが外側から判りにくいのが難ですが…) 他にも先生のお名前でGoogle検索をしたり、CiNiiと呼ばれる論文データベースや、 Google Scholarで英語論文を調べたりするとだいたいの研究内容がわかります。 例えば私の名前で検索するとこんな感じですね。

これで見ればだいたいどんな研究をしているかわかりますが、セキュリティを専門にしておられる先生だけでなく、 セキュリティ「も」やってます、という先生も少なくないので、研究内容をよく調べてみてそういう方も候補にしたら 良いのではないでしょうか。そして実際に連絡を取って、学びたいことややりたい研究についてよく事前に 相談すると、多くの先生はきっと応じて下さいます。


以上が書きかけの文章から起こし直したもの。海外の大学についてはもう書く元気がないのでどなたかに任せちゃいます。

ところで、最後に宣伝を。知恵袋でもちょっと頭出ししましたが、立命館大学情報理工学部は2017年度に改組を予定しています。 学科をコースに再編成するのですが、コースの中に「セキュリティ&ネットワークコース」を設けることになっています。 カリキュラムとしては、情報システムやネットワークの基礎技術に関する講義を中心に、暗号だけではなく セキュリティに関する講義を設けて手厚くします。さらに演習も行います。加えて、現在行っている京都府警との連携は 継続するほか、企業との連携を深めたり、引き続く大学院ではSecCapへの参加なども検討しています。 セキュリティエンジニアやアナリスト、コンサルタントを目指すような学生さんを集められたら良いなと思っています。 追ってちゃんとした広報もしますので、ご期待下さい。

*1:このあたりの感覚が、特に文系学部を卒業された保護者の方々や進路指導の先生方になかなか伝わらないことが…

*2:今の受験生の皆さんが大学院に進まれる頃にはSecCapは別のプログラムになっている可能性がありますので、 直前にまた調べ直す必要がありますが…

2016年の素数日一覧

一連のツイートが思ったよりバズったので…

ついでに2016年の素数日(日付を8桁で表すと素数になる日)を貼ります。

20160319
20160401
20160403
20160529
20160601
20160607
20160611
20160709
20160727
20160809
20160817
20160821
20160923
20161007
20161013
20161019
20161021
20161027
20161103

1月と2月と12月には素数日がありません。4月1日は素数日なので東工大の学長も祝辞のネタには困らないと思います ;-)

ついでに書いたヘボいコード。久々にRuby書いたなぁ…

追記:

もっと美しく書いてる人がいました

qiita.com

ついでにWebで計算できるようにしてる人も。

2016年の素数日

hamukazu.com

Prime Number Days


便利だけど気をつけないと危ないChrome Remote Desktop

Windowsデスクトップに遠隔でアクセスしたくなる事がありますが、皆さんどうされてますか?

昔から定番はVNCを使うことでした。個人的にも昔はRealVNCUltraVNCを使っていましたが、VNCは画質もイマイチですし音声も転送できないのでもう少しマシな方法が欲しいところです。

Windowsの場合、純正のプロトコルであるRDPを用いた「リモートデスクトップ接続」なら音声も転送できますし画質も綺麗です。ですが、これを利用しようとすると、遠隔操作される側が(Homeやwith Bingでなく)Professionalなど上位のエディションである必要がありました。ところが最近、HomeエディションのWindowsでもRDPによるリモートデスクトップ接続を可能にするRDPWrapなんてものが現れました。個人的にも最近は専らこれに頼っています。Windows 8.1 with BingやWindows 10 Homeあたりでも問題なく遠隔操作できるので大変便利です。さらに最近はMicrosoft純正のAndroidで動作するクライアントiPad/iPhoneなどのiOSで動作するクライアントもあるので、時々iPadから接続したりして快適に利用してます。

そんなわけで個人的にはRDPWrapですっかり満足しているのですが、他の選択として、最近GoogleChrome Remote Desktopなるものを出していることに気づいてはいました。

support.google.com

ChromeはChromecastに向かってタブだけじゃなくデスクトップを送信(キャスト)する機能があるので、Chrome Remote Desktopもこの技術の延長で実装されてるのかなと思っていたのですが、先日ちょっと調べる機会があって動作を見てみたらこれがとんでもない勘違いであることに気づきました。確かに便利ではあるのですが、なかなか怖いということもわかったのでまとめておきます。

Chrome Remote Desktopのインストールの方法&使い方

インストール手順や基本的使用法そのものはここに詳しいので譲ってしまいます。

www.atmarkit.co.jp

この手順を見ればわかりますが、サーバPCには、chromeremotedesktophost.msiのインストールを通じて「Chromeリモートデスクトップサービス」なるサービスが登録されます。

f:id:tetsutalow:20160101220815j:plain

この結果、対象となるサーバPCはChromeの起動の有無やログオン状態とは関係なく、電源onであればいつでも遠隔操作可能となります。Chrome Remote DesktopというからにはChrome起動中だけ遠隔操作可能なのかと思ってしまいそうになりますが(私だけ?)実はChromeとは無関係であるというのがミソ。ログオン前でも遠隔で接続してログオン操作から行うことが出来るので、確かに大変便利です(例えば再起動が必要になる状況になっても気軽に遠隔から再起動できます)が、一方で他人が利用中のPCのデスクトップも(許可さえされていれば)いつでも共有できてしまう=操作可能になってしまいます。なお遠隔操作時には、画面中央下に「デスクトップは現在<googleアカウント名>と共有されています」と表示されますので、遠隔操作されていることに気づくことはできます。この機能はどうも、PC操作の遠隔サポートなどを想定しているのでこのような動作になっているようです。

遠隔操作できる条件

調べた範囲では、サーバ側PCのデスクトップが共有可能になる=遠隔操作可能になる条件は以下の場合のようです(間違っていたらご指摘下さい)。

  1. サーバ側PCの管理者権限を持っており(=ローカル管理者権限のあるアカウントを持っている)あらかじめ対象PCを遠隔操作可能なGoogleアカウントを指定してあること。管理者権限はChromeリモートデスクトップサービスのインストール時と、遠隔操作可能なGoogleアカウントの指定時(PIN指定時)の2回必要になります。遠隔操作可能とするためには、対象となるPCのデスクトップでの直接操作が必要になります。また、1台のPCに対して遠隔操作可能なGoogleアカウントは1つしか指定できません。
  2. サーバ側PC、クライアント側PCともにGoogleの特定のサーバへの443/5222TCP接続と、UDPの対外接続が可能であること。NAT配下で構わないようですが、NATルータのUDP Hole punchingについてどんな制限があるかはまだ調べていません。重要なのは、サーバ側PCに外からTCP接続を必要としない、つまり、Port forwardingやUPnPを必要としないことです。UDPが必要なのでProxy配下の端末は操作できませんが、VNCやRDPと違ってTCP接続の穴を外から開ける必要がありません。

ネットワーク的な動作

実際のネットワークトラフィックがどのようになるかは、この辺を読むと推測できます。

(1) サーバ側

Chromeリモートデスクトップサービスを担っているremoting_host.exeから、chromoting-host.talkgadget.google.comのport 5222にTCP接続されています(プロトコルXMPPの模様)。また、実際のリモートデスクトップ接続後はランダム(だいたいは60000番台)なポート番号のUDPトラフィックをクライアントとの間で直接やりとりしますが、ここに書いてある設定によってポート番号の範囲を12400~12409に制限できるようです。

(2) クライアント側

ドキュメント読む限りはchrome.exeからchromoting-oauth.talkgadget.google.comのport 443とchromoting-client.talkgadget.google.comのport 5222にTCP接続するようです。ただ、私が試した範囲ではChrome.exeから5222への接続は確認できませんでした。代わりにport 5228へのそれらしい接続は見つかりました(バージョン47.0.2526.28の場合)。一度接続するとUDPトラフィックをサーバ側PCとの間で直接投げ合います(ポート番号はやはり基本ランダムで、設定により制限可能)。

なお実際にはGoogleのサーバは(現在のところ)3種とも全てwildcard-talkgadget.l.google.comへのaliasになっているようです。

問題となりうる状況

すぐに思いつく問題では、「UDPが通ればFirewall配下でも遠隔操作可能になるので、組織内のPCがセキュリティポリシーなどに反して遠隔操作可能にされているかもしれない(その結果組織のセキュリティに影響する)」という話です。ただ、PCの管理者権限が必要ですし、NAT接続などUDPが通らないとダメという制限がありますので、小企業のように企業内PCの管理者権限がエンドユーザに渡されているようなところでない限りあまり問題にならないかも知れません。

一般利用者にとっては「いつのまにか画面が他の人に覗かれているかも知れない」という問題があります。これはChrome Remote Desktopが現在使用中の画面状態(セッション)のまま他者に共有させるからです。この挙動はVNCと同じですが、純正リモートデスクトップ接続であるRDPとは違います(RDPの場合使用中のセッションを遠隔で奪うには使用者のログオンパスワードが必要)。共有状態になっているかどうかは画面に「共有されています」という表示が出ているかどうかで解りますが、気づかない可能性はあります。例えばログオンした画面をロックせずに離席してたら、覗かれても気づきませんね。

あと細かいことですが、通信プロトコルが全体としてXMPPをベースとしたものだと思われるのですが詳細は分からないので、リモートデスクトップ接続利用に伴ってGoogleにどのような情報が渡っているのかよく判らないのも気になります。これについてはヘルプ中の「Chrome リモート デスクトップの安全とセキュリティ」という節に「ネットワークの待ち時間やセッションの継続時間に関して、データを完全に匿名で収集、保存」とあり、不要な情報は保存していないと宣言されているので、これを信じる限りはそれほど心配要らないと思うのですが。

Google Chrome Desktopの使用を禁止する方法

端末に管理者権限がない利用者が勝手にChrome Remote Desktopの利用を有効にすることはできないので、この点は安心なのですが、ネットワーク管理側で一網打尽にしようとすると少し面倒です。TCP Port 5222による対外接続を塞いでしまうとできますが、他のXMPP使用アプリケーションも(どれくらいあるかわかりませんが)塞がれてしまいます。きちんと管理する方法については、Google自身が下記のような情報を提供してくれています。

リモートでデスクトップを管理する - Chrome for Work ヘルプ

上記URLにはいくつかのGoogleのホストをDNSでブロックせよと書いてあるのですが、これは管理者にとってはちょっと面倒な上、ちゃんと考えておかないと抜け穴が残っちゃいますよね(例えばDNSサーバを管理外のものに変更されてしまうと抜けられてしまう)。まぁ結局ちゃんと端末管理したければNATなんかせずにProxy設置しなさいということなんでしょう。

 

ということで、何かのご参考になれば。