翻訳に関するあれこれ

今回は翻訳について書いてみる。

公私問わず結構翻訳することがあるのだが、今回はそのことについて書いてみたい。(ただし、翻訳を専業とする翻訳専門家ではないので、そのあたりは少し含んで読んで欲しい。ただ、翻訳をアウトソースすることも多く、このあたりの流れはある程度は掴んでいる。)

翻訳の方法

ベタ翻訳

支援ツール(これらについては後述)などを使わない方法で、そのままテキストファイルなどを翻訳する方法。一番大変な方法だが、画像や、プロテクトされたPDF、果てはOCRできないクオリティの印刷物を翻訳するにはこの方法しかなかったりする。当然手間がかかるので翻訳会社などに頼む場合、支援ツールが使えるか否かにより納品までの時間はより長くなり、高くなる。(逆に翻訳会社に翻訳を頼む場合、元ソースが編集不可のものである場合は一度翻訳元の言語で編集可能なフォーマットに落としたほうが早く安くなる。)

編集できるフォーマットであってもソースコードのコメントを訳してほしい、というような場合など非翻訳部分が多く含まれる場合はやはり翻訳が部分のみを抽出して渡した方が安くなる。(そもそも原文の単語数でコストが決定される場合が多いので・・・・・・。)

検索支援ツールを使用した翻訳

ベタ翻訳は大変で、時間もかかるので、その負担を軽減するために開発されたのが各種の検索支援ツール(CAT — Computer Assisted Translation)ツール。Google Translateみたいな機械翻訳をイメージするかもしれないが別物、とはいえ、機械翻訳は翻訳のベースとして使用することはあるので、関連した技術とも言える。商用ではTRADOSなどが有名。(結構お高い)無料のものではOmegaTなどがある他、Googleもウェブアプリとして、Google Translator Toolkitを提供している。なお、フォーマットなどもタグ化されるので、例えば、太字などの装飾が行われている場合でも翻訳結果にそれを反映させることができる。前述のように機械翻訳を組み合わせて使えるので、その翻訳結果が提示するコンテキストを汲み取り、意味が通るように修正しながら作業を行うことにより、効率が大幅にアップする。対象文書の機密具合で機械翻訳が使用できない場合、時間とコストが上がる。(最近、安く翻訳してくれる翻訳会社が増えた背景にはこういった技術が使用できる、という背景があるように思われる。)

翻訳支援ツールは翻訳文(文節)を翻訳メモリと呼ばれるファイルに保存する。これはデファクトスタンダードがあって、TMXというXMLファイルが広く使われている。翻訳メモリを使用することにより以下の利点が生まれる。

  1. 同じ原文が提示される場合、以前の翻訳結果が再利用できるので、何度も同じ原文を翻訳する必要がなくなる。
  2. 上記に関連して、似た原文がある場合、それも提示されるので、訳文のばらつきを抑えることができる。
  3. 同じ原文の更新版が提供された場合、差分を取る手間を省き、以前の翻訳文を再利用できることができる。
  4. 複数の訳者がいる場合、共有することができる。

翻訳支援ツールには単語集機能が大抵装備されていて、単語が登録されている場合、その訳文を表示してくれる。専門分野で翻訳が必要な場合は、文中に現れる分野で広く使われている対訳があればあらかじめ訳者に提供しておくと翻訳の精度が高くなる。(こちらは共通フォーマットはないので、CSVなどリストとしてオーガナイズした形で準備するとよい。)

翻訳の質について

ほとんどの翻訳会社はいろいろな種類のドキュメントの翻訳をやってくれるが、それをどのような用途に使用するか、ということに関しては留意する必要がある。以下のようなケースでは特に注意。もちろんそれらに特化した翻訳会社もあるので、検討するのが望ましい。(そういった翻訳会社は当然価格が高くなる傾向にある。)

翻訳者は訳者であって文章の創作者ではないので、有能な翻訳者こそ、原文に忠実にあろうとする傾向があるのに注意する必要がある。

文芸作品

文芸作品の翻訳を頼む場合、そのまま出版できるクオリティのものは期待してはいけない。あくまでもあらすじをつかめるもの、ぐらいの認識でないといけない。これは簡単な話、訳者は訳者としての能力はあっても、文筆家であるとは限らないから。こういった作品の出版としての翻訳はそういった専門の知識を持った翻訳家に任せる必要がある。(反対に文芸作品の翻訳ができる人とというのは、翻訳言語で本が一冊書ける能力を持った人であるということ。)

意匠性の高いコピー

スローガンや、商品のキャッチコピー等。以前アップルの日本語キャッチコピーが直訳すぎると話題になったことがあったが、まさにあんな感じ。訳者はコピーライターではないのでどうしても直訳っぽくなってしまう。コピーライターがちゃんと書きなおせば、と思うだろうけど、そもそもコピーライターに原文を読解する能力があるとは限らないという問題もあり、特に異なる言語での一意性にこだわる会社(多分アップルもそう)だとジレンマになってしまうのではないかと思う。(まあ、これは会社のポリシーにも問題があるんだろうけど。)

契約書、法文書など、法的な文書の翻訳

契約書などの翻訳は一般的な翻訳の場合、その有効性・対応性に疑義が生じる可能性があるので注意。これは原文の地域と翻訳言語を使用する地域の法律が当然ながら違ってくるので、双方の法知識が必要になるため。

最後に

他のどのような仕事と同じように、納期、価格と品質のうち優先度を選べるのは2つまでであるので注意すること。安くて納期が速くかつ品質が高い仕事などというものはない。(良心的な翻訳家は品質を低くするような仕事は受けないのでここでは価格と納期のどちらかを選ぶ決断になる。ただし、無理な仕事を押し付けたり、不当に催促したりすると、当然の話、チェック時間などに取れる時間が短くなるので品質は低下することになる。)翻訳に関しては具体的に言うと、一日に捌ける仕事量というのは決まっているので、例えば、その限界に近い仕事を依頼すると他の仕事を止めたり、私用の時間を割いたりする必要が出てくるので当然価格が高くなる。なので、余裕を持ったスケジュールで臨むのが翻訳料を下げる方法の一つとなる。

LINEのE2EE実装「Letter Sealing」初見

LINE 5.3で追加された機能として、超音波による友達追加の他に、Letter Sealingという機能が追加されているということです。

Letter Sealingの説明は以下のようになってます。

より安全にトークを楽しむためのLetter Sealing機能を追加 (この機能は特定の国や地域でのみ利用可能です)

尚、LINE Engineer’s Blogの記事によると

LINE 5.3.0からは、さらに強化された暗号化方式のE2EE(end-to-end encryption)として「Letter Sealing」機能をご利用いただけます。次回の記事では、「Letter Sealing」について詳しくご紹介します。

とのことですので、そのうち詳細の解説がなされると思うので、この記事はあくまでも現時点で見える範囲で話を進めていることにご留意ください。(公式情報が投稿され次第、加筆などはする予定です。)

この機能、説明が全くなされずに登場した機能でGoogleで検索してみるとベータ版のヘルプらしきものがヒットし、その内容として「Letter Sealingとは」という項目があります。

Letter Sealingとは、トークルームのメッセージにエンドツーエンド暗号化を適用したサービスです。
※エンドツーエンド暗号化(End to End Encryption)とは、サーバー上でもメッセージの内容が暗号化された状態で保存されており、送信者と受信者以外には対話内容を判読できないように設計された通信方式です。

トーク送信者と受信者が互いにLetter Sealingをオンに設定している場合、よりセキュリティが強化されたメッセージを送受信することになりますが、トークルームでは通常どおりトークの閲覧ができます。

なお、Letter Sealingをオンに設定後、WindowsやMAC OSなどPCでLINEを利用する場合は本人確認が必要となります。

End to End Encryptionというのは発信者と受信者の間で暗号化を行う手法のことで、正しく実装されている限り、第三者による監視が困難になる通信方式です。前にタイマートークというのが実装されましたが、方式的にはそれと類似しているようです。(ただし、タイマートークは日本、中国では使用できないようです。)

Letter Sealingの設定は、トーク設定画面から行えるようになっていました。(いつの間にか行えるようになっていました。尚、「特定の国や地域」がどこを意味しているのかはわかりません。)

Letter Sealing設定
Letter Sealing設定

説明には「メッセージは高度な暗号化により保護されます。Letter Sealingは友達がその機能を有効にしている場合に限りトークで利用できます」とあります。この説明によると、トークで何らかのオプションが有効になるかと思ったのですが、双方でこの二つをオンにした状態でメッセージを送信すると、普通に送受信されます。(暗号化のオプションなどは見当たらず、ただ単に通常のメッセージとして表示される。)

ところが、Chrome版のLINEでログオンすると警告が表示されます。

Chrome版LINEでの表示
Chrome版LINEでの表示

Letter Sealingが有効になっていると、一部のメッセージが表示されない場合があります。
この機能を無効にするには、携帯電話版LINEで[設定]>[トーク]>[Letter Sealing]に進んでください。

つまり、Chromeアプリ側では暗号を復号化する鍵を持ち合わせていないので開けないということでしょう。これはタイマートークでもそうなので想定内でした。反対にこれで開ける作りになっていると実装を疑わざるを得なくなります。(なぜなら、もしChromeアプリ側で復号が可能である場合、サーバを経由して秘密鍵を転送していることになるので、結果としてサーバ側がメッセージを読むことができてしまうわけです。)

上記ですでに送信していたメッセージは次のような表示に置き換えられていました。

ChromeでのLetter Sealingメッセージ表示
ChromeでのLetter Sealingメッセージ表示

[Letter Sealing]

ご利用の端末では[Letter Sealing]に対応していないため、このメッセージを表示できません。
モバイル端末の[設定]>[トーク・通話]で[Letter Sealing]の設定を変更してください。

つまり、先に送ったメッセージは暗号化されて送られていたわけです。つまり、本質的にはLetter SealingはOpportunistic Encryption(日和見的暗号化)ということになるようです。(暗号化できる場合は暗号化する方式、この方式自体はメールサーバ同士の通信などにも使われています。)ただいくつかの疑問というか問題点が……。

  1. ユーザーはどうやって暗号化された、ということを確認するのか? 方式的に双方が有効にしていないと作動しない機構であることもあり、暗号化されるのであればその旨が通知されなければ使い物にならないのではないか。。(鍵マークなどを表示した上で、暗号化が有効になった時点、無効になった時点でユーザーに告知すべき。これをしないと全く意味がない。)
  2. どのようなペイロードが暗号化されるのか。当該のメッセージが暗号化されていることを確認する少し前に送ったスタンプや写真はChromeアプリからも読み取ることができた。(つまりスタンプや写真に関しては暗号化されていない。)このあたりも全くユーザーに告知されていない。
  3. 複数人のトークの場合は暗号化されるのか。またはその場合はどのような方式になるのか。こちらはちょっと機構的に複雑な部分。でもTextSecureでは実現できてるけど……。

詳細については公式の解説を待ちたいところですが、ぱっと見たところではちょっと疑問が残るシステムでした。特にユーザーにそのステータス(状態)の表示がないのはまずいです。タイマートークであればタイマートークを使っていることが一目瞭然にわかりますが、今回のLetter Sealingでは、何が、いつ暗号化されているかという表示が全くないですし、そういったことが明示されないのが致命的です。また、設定方法に関しても、設定画面以外のところから有効にできるようにしないと、わざわざトーク設定まで行って、Letter Sealingをオンにするユーザーはまずいないのではないかと思います。

LINEの超音波による友だち追加を分析

LINE 5.3で超音波やBluetoothにより友だちを追加できる機能が装備されました。どのような仕組みになっているのかを検証してみました。

先ずは、信号を可視化するため、スペクトラルグラム及び、スペクトルを取ってみました。

LINE友だち追加信号のスペクトルグラム
LINE友だち追加信号のスペクトルグラム
LINE友だち追加信号のスペクトル分布
LINE友だち追加信号のスペクトル分布

音声出力を直結して信号を採ろうかと考えたのですが、ヘッドフォン端子が使用されているとこの機能が有効にならないようです。(そのため、マイクを近づけて録音しました。)

調べると、18976Hz、19576Hz、20199Hz、20799Hzにピークが現れているようです。全て、可聴音ではないので、聞こえない音ですが、耳のいい人はかすかに聞こえるかもしれません。

そこでこれを可聴域に変換したものを作成してみました。

複数の信号が重ねられており、内容に関しては判明していませんが、恐らく、FSKで信号をコーディングしているものと考えられます。同様の技術は「JR東日本アプリ」や「ぐるなびタッチ」などのアプリで使用されており、これらは「Air Stamp」という技術を使っているようですが、Air Stampは事業者が信号を発生させ、それをスマートフォンなどで読み取らせ「チェックイン」するスタイルのシステムであるようで、少し違ってそうです。どちらかというと、システムとしては双方向通信が行われているものではなさそうですが、超音波によるネットワーキングが近い感じです。(これらに関してはGigazineさんがカバーされています。)

尚、超音波ではなく、可聴音を使用した符号化に関してはアマチュア無線などで、RTTYPSK31などのデジタル変調として日常的に使用されています。(尚、これらの変調を聞くと、上記の可聴音に変換したようなものに似た音声が聞こえます。

追記:パターンを見ると変調方式は恐らくFSK。それぞれ2つずつの周波数を使用して、2つの信号が出ているようです。なぜ信号が複数出ているのかはわかりませんがその送出パターンが途中で反転していることを考えると干渉による影響を軽減させるために行われているのではないかと考えます。

日本でのT-mobileローミング体験談

(本投稿は英語版、T-mobile Roaming in Japanに加筆修正を行い、日本語訳したものです。)

3月の終わり、3月23日から3月30日まで訪日し、今回、日本国内でのローミングを初体験しました。今回、前回の訪日より7年1ヶ月と24日ぶりの訪日となり、前回はいくつかの理由でローミングを行いませんでした。一つは値段の問題。過去に訪日した際にはローミング価格が非常に高く、とても許容できるようなものではありませんでした。もうひとつは、ローミング可能な機種ではなかったこと。当時、使用していた機種はT-mobile MDAというHTC Wizardと呼ばれる機種で、対応していた通信方式はGSM系であるEDGEであり、日本国内では使用できるものではありませんでした。

7年1ヶ月24日後、使用しているのはNexus 5であり、こちらはLTEW-CDMA方式を使用しているわけで、今回初めてローミング環境が使用できる準備が整いました。もうひとつの点として現在契約しているT-mobileはそのUn-Carrierの施策として、無料ローミングを打ち出しており、追加の契約でなしに無料で国際ローミングが使用できるようになりました。制限としては128Kbps相当への通信速度の低下であり、今回テストするのはその使用可能性が主になります。尚、通話に関しては毎分20セントということで、日本と違い、着信にも課金されますが、通常日本国内に置いてもソフトバンクのホワイトプランなどで30秒毎に20円、DOCOMOでも11〜15円程度になることを考えると悪くはない金額なのかもしれません。

飛行機を下りてからしばらくするとすぐに電波を受信し、Android 5.1の問題からか、一度再起動が入ってしまいましたがそれ以後は非常に快適に使用できていました。最初に表示されたキャリア表示はJP DOCOMOとなっていました。その後すぐに、SMSで156から以下のようなメッセージが受信しました。

Free T-Mobile Msg: Welcome to Japan. Unlimited text incl with your global coverage. Talk $0.20/min. More info http://t-mo.co/tc

Free T-Mobile Msg: Unlimited web included as part of your global coverage. To purchase high speed data please visit: http://t-mo.co/4G-Data

またその後しばらくしてから883番号より、以下のメッセージを受信しました。

Free T-mobile Msg: For faster web browsing, you can purchase a high speed data pass at: http://t-mo.co/4G-Data

これは追加で使用できる高速通信パッケージの案内で、15ドルで100MB(有効期限1日)、25ドルで200MB(有効期限1週間)、50ドルで500MB(有効期限2週間)の高速通信を行うパッケージが提供されています。これらは追加しませんでしたが、以前は1MBごとに15ドルが課金されていたことを考えると安いといえば安いです。尚、日本での通信においてはUTMSと表示されていたため、LTEではなくW-CDMAが使用されていたことになります。上記のパッケージを購入することでLTEに接続になるのかは分かりません。

割り当てIPアドレスを確認してみたところ、T-mobile USAのIPアドレスが表示されましたが、これはアクセスポイントがT-mobile USAのものになっているため、当然の結果となりました。通信経路に関しては前述のように128Kbpsに制限がかかるということで、心配がありましたが、特に写真などのバックグラウンド通信に対して制限をかけることで問題なく使用することができました。

キャリアをまたぐローミング(例えばドコモからソフトバンク)などが発生した場合、しばらくの間圏外になってしまう現象がみられました。発生した場合、少しイライラしましたが、ほとんどの場合は特に問題となるレベルではありませんでした。

メッセージ系のアプリは全く問題なく、また東京の複雑な交通機関を利用する際にはGoogle Mapsが役に立ちましたし、また、ブラウザの使用に関してもデータ圧縮が効いていることもあるのか快適に行うことが可能でした。

ソフトバンクとDOCOMOの可搬式アンテナ局。今回のローミングでは両方のネットワークを使用していたため、どちらの車両も経由したと思われます。
ソフトバンクとドコモの可搬式アンテナ局。今回のローミングでは両方のネットワークを使用していたため、どちらの車両も経由したと思われます。

今回の体験によって、何らかの接続手段があることはかなりの差が出ることが実感出来ました。

Trelloでゆるい情報管理

Trelloというサービスがあります。このサービス、2011年ごろからあるらしいのですが、全然気が付かなかった。(Org-modeを中心に使っていた、というのもありますが。)

これに気がついたのは最近、Hacker NewsのOrg-trelloへのリンクから。

どういう使い方ができるかというと使い方が決まっていないのがTrelloの特徴です。実際、新しいボードを作ると以下のような感じです。

Trelloの初期画面
Trelloの初期画面

普通、この手のサービスだと予めいろいろとプリセットがお膳立てされているのが多いのですが、Trelloの場合は必要に応じて自分で作ります。

Trelloでリストを作成
Trelloでリストを作成

各リストの中にはカードが含まれていて、その中にはかんばん方式みたいに進捗工程を並べるのもよし、トピックごとに情報を整理するもよし、と必要に応じて自由に設定できます。(いろいろな例がinspirating boardのページに記載されています。)

リストの中にカードを作るとこのような画面が表示され、その中にチェックリスト、ファイルなどを添付することができます。(説明やコメントなどはマークダウン記法が利用できます。)

空カード
空カード

このリストに期限、説明、コメントなどを追加するとこのような感じです。

記入済みカード
記入済みカード

もちろんこれはグループで共有したり一般公開することも可能で、変更履歴などを参照することもできます。

カードをリスト間で動かす場合はドラッグアンドドロップ可能で、これにより、進捗を更新時に「作業中」から「完了」などに動かす場合はその項目を動かすだけですみます。

このようにシンプルな構成となっているものの、非常に簡単に使用することができ、個人的には作業管理などに使用しています。モバイルアプリもあり、また各カードがメールアドレスを持っているため、そこに送信することで項目を追加できたりします。(例えば、メールの返信時にそのアドレスをBCCすることで備忘録的な使い方も考えられるかと思います。

ちなみに、基本機能は無料で、ビジネス向けや個人向けの有料版があり、それらは添付できるファイルの容量が増えたり、背景の種類が増えたりします。

Google Chrome、Linux下での速度問題のまとめと回避方法

(2016年2月22日更新)この問題を修正する変更が開発者により行われ、すでにソースコードに取り込まれています。この変更が実際のリリースに適応されるのにはしばらく時間がかかりますが、近いうちに修正が入るものと思われます。

最近のGoogle Chromeに、すでに何件か報告されている問題で最近原因が解明されたものがあり、その問題と取り敢えずの対処法に関してまとめます。

どういう問題なのか

Google Chromeのアドレスバー(Omnibox)の入力レスポンスがものすごく遅くなります。スペックにもよりますが、具体的には一文字入れるとそれが出てくるまでに数秒を要する、といった具合です。極端な場合には多大な遅延のせいで、入力される文字の順番が入れ替わってしまう場合もあります。(例えば、google.comと入力したつもりがgogole.cmoとなるなど)

また、インターフェース自体の再描画も全体的にもっさりとするため、メニューを開くのに遅延が出るなどの問題が発生し、全体的にGoogle Chromeメインプロセスが消費するCPUが高くなる傾向にあります。

原因は?

バグが報告されていたものの最近までその原因は特定はされていませんでした。1月6日にChromiumプロジェクトのKochi氏がこの問題がフォントのキャッシュがフォントのフォントファミリー名による参照によりキャッシュされていないとみなされ、再キャッシュプロセスが発生してしまうのが原因で発生しているということが報告されました。

つまり、まとめると以下のようになります。(Kochi氏が指摘する源ノ角ゴシック JPを使用した場合)

  • Google Chromeが源ノ角ゴシック JPを使用してフォントをレンダリングしようとする
  • Google Chromeが源ノ角ゴシック JPを使用しようと、そのフォントファミリー名のSource Han Sans JPで参照しようとするが、キャッシュされていないと見做し、キャッシュ動作(非常に重い)が発生する

というようなプロセスが発生し、これが一文字入力されるごとに発生していた、という問題のようです。

尚、上記に併せ、同氏によりコードの修正レビューが提出されていますが、すでにこの修正を含む、書き換え自体が予定されていることもあるようで、パッチとしての適応はされないようです。そのため、根本的な解決にはしばらく時間を要すると予想されます。

回避策

根本的な解決はコードに対処が入るまで行わられないものの、取り敢えず回避することは可能です。基本的にフォントのファミリー名が問題にならないフォントを使用すればいいわけです。尚、こちらで実験したところ、IPAフォントとその亜種ではこの問題が発生してしまうようです。(日本語環境ではこれらが指定されていることも多いでしょうから、この問題にあたってしまう人も多いかもしれません。)

回避方法

前述のように、この問題の影響の受けないフォントに置きかえてやるのが回避する方法になります。Gnomeを使用している場合、gnome-tweak-toolを使用し、UIが使用するフォントを問題のないものに置きかえる必要があります。gnome-tweak-toolは標準ではインストールされていないので別途インストールが必要です。

KDEの場合kde-config-gtk-styleをインストールした上で、外観設定の中のGTK設定のフォントを変えることで対応できます。

KDE GTK Config

フォント設定を例えば、Noto Sans CJK JPなどに置き換えることで対応可能です。

フォント設定

この変更を行い、右下の適応ボタンを押すことで変更が保存されます。尚、Google Chromeに対し、この変更を有効にするためには変更した後に、Google Chromeを再起動する必要があります。

Rhodanthe CA設置について

ホスティング会社が最近SNIながらもSSL/TLSに対応しました。ということで、管理中のサイト群も暗号化に対応するのですが、一つ問題としては証明書の管理が非常に大変なことでした。現状、HidekiSaitoCom PKI情報にも記載しているようにいくつかのサイトにおいてはStartSSLより無料で入手した証明書を使用しています。しかしながら、StartSSLは証明書の発行に制限がついており、また、破棄証明の作成に費用がかかるシステムになっています。そのため、全てのサイトに対してこの証明書を入手するのは破棄が必要になった場合の費用及び、破棄を行わない限り、代わりの証明書を得ることができないという関係上、何らかの不都合が生じた場合、非常に問題が発生する可能性があります。かと言って、ほぼ収益が0のサイトで証明書の費用を捻出するのは大変です。将来的にはLet’s Encryptプロジェクトが解決しうる問題であるかも知れませんが、一般公開が始まった後でもホスティング側での対応も必要であり、使用できるまでにそれなりの時間がかかるものと思われます。

そこで、現状の打開策としては自己証明書(いわゆるオレオレ証明書)を使用する方法もあるのですが、ここはGnuPGをプロモートしている者として、外部的にも検証が可能である方法を考えたすえ、実験的にRhodanthe CAを設置しました。(要はオレオレ証明書ならぬ、オレオレ認証局とOpenPGPの合わせ技です。ちなみに高木氏の区分でいくと第二種オレオレ証明書+ぐらいのものになるかも知れません。)

Rhodanthe CAの構成図
Rhodanthe CAの構成図

通常の認証局と違い、ルート証明書の別途導入が必要であるなど、サイトの正当性を保証する性質のものではありませんが、オポチュニスティックな暗号化を使用できるように今回、この設定を行いました。機能としてはルート認証及び中間認証、及び証明書破棄リスト(CRL)の利用ができるようになっています。尚、Let’s Encryptにおいてもフリーで自動的に証明書が得られる形になるようですから、サイトの認証などはほぼないものの、恐らく正当な(素の状態で警告が出ない)証明書を使用するシステムとなるかと思いますが、正当性証明に関してはドメイン名以上のものは行われないと思われますので、その正当性の信頼性は恐らくRhodanthe CAよりも少し良いぐらいになるかと思われます。ともあれ、恐らく、今後はネット上の暗号化された通信の割合を増やす、ということが主な課題になってくることから、これまで通常の証明書が担ってきた、サイトの正当性の証明はExtended Validation証明書が主流になってくると思われます。

ちなみにGoogleなど、大手の会社は自社で認証局を持っています。この場合は、正当なルート認証局より認証局自体を認証してもらう(つまり、ルート認証局の下に属する中間認証局になる)方式になっています。これはもちろん非常に高価であり、またこのような形で、正式な認証局として設置するには証明局運用規定を設置するなど、個人じゃ到底無理なレベルですので素直に諦めました。(確か、州によっては免許も必要だったと思います。ワシントン州は必要みたい。)

Blenderを使用したNDVI画像の処理

この記事はBlender Advent Calendar向けに作成しました。本稿は元々Analyzing NDVI Imagery Using Blenderとして投稿していたものに加筆修正を加えたものです。

Blenderの本領である3D作成とは違った趣向ですが、レンダリングノードがどのくらい汎用性があるか、ということに関して示すことができましたら嬉しいです。

先ずはNDVIに関して軽く解説。NDVIはNormalized Difference Vegetation Indexの略で、正規化植生指標という植物の量や活力を表す値です。具体的には赤の可視光と近赤外線を測定することにより得る値となります。

国土環境モニタリングのページにその計算方法などが掲載されています。

どのようにして撮影するのか

一般的なカメラの素子は赤外線を捉えることができますが内部にそれを遮断するフィルタが入っており、そのまま撮影しても必要な光成分はほとんど撮影されません。Public Labはそれを分光するためのフィルタを販売しており、それを使用し、カメラを改造するか、改造済みのカメラを入手することができます。このカメラでは赤外線成分を赤チャンネル、可視光線を青チャンネルに記録します。

基本的原理は同じなので、衛星などの元データなどのデータも流用可能かとは思いますが、データ構成により調整を行う必要があるかもしれません。

Blenderを使用しての処理

ここで使用する画像はInfragramカメラに付属のサンプル画像を使用します。このカメラで撮影すると、以下のような画像が撮影できます。

撮影画像

NDVI画像を抽出するのにはノードでNDVI変換を定義しました。

NDVI変換ノード

このノードグループからは以下のような出力が得られます。この画像をColor Rampなどと合成することにより擬似色画像を構成することができます。

NDVI出力画像

以下はColor Rampを当てはめた例です。活性度に応じて白や緑に表示されています。

NDVI擬似色画像

Public Labでは撮影した画像を処理するサービスがありますが、Blenderで処理することにより同様の画像をローカルに処理することができます。

Infragram.org的 その1

Infragram的 その2

Blenderではノードを設定し、組み合わせることで、目的に応じた映像を出力することができます。

ノード設定

例えば以下は白黒の可視光線画像にNDVI画像を合成した画像です。

活性を示したオーバレイ画像

この画像では植物が活発と思われる部分がはっきりとハイライトされるため、存在する植物などを表示することができます。

以下、使用したBLENDファイルです。

infragram-2014082702.blend.zip

BlenderでNDVI処理する利点

  1. 柔軟性のある加工を施すことができる。
  2. Packすることにより、共同作業者などと単一のファイルをやりとりすることができる。
  3. NDVI動画画像も静止画と同じぐらい簡単に加工可能。(タイムラプス映像や気球映像などの加工も容易)ただし動画を使用した場合現状Packされないことにご留意下さい。
  4. 非破壊的に処理を加えることができるため、処理の切り替えができるほか、またどのようにして最終画像に至ったかということがファイルに含まれるため、いわば自己ドキュメンティングなファイルを配布することができる。

応用

同様のプロセスを使用して、その他の分野の加工でも、光成分に関する加工を行うことができます。カラーランプは色を一定の色のスケールに割り当てることができるため、例えば犬から見た景色、などもシミュレートしてみることが可能です。

犬が見る街

明日はnecoganeさんのテクスチャ作成方法(自己流)について、ということです。

メールをGnusに移行

(この文書はI Transitioned Local E-mail Management to Gnusの和訳版です。

これまでメールはGmailやGoogle Apps(最近はGoogle Apps for Workに変わったんでしたけ)を公私ともに使用しているため、ほとんどGmailのインターフェースで使用していたのですが、ローカルなメール環境に関しては結構模索を行っていました。Mozilla Thunderbirdなども使うことはあったのですが、結構重いのが欠点でした。

個人的には以下のような要件を満たす必要があります。

  1. 大量のメール(数百件/日)を処理できること。全て深く読むわけではないですが、ML内のメールを高速に走査できることが重要。
  2. 一般的なプレーンテキストのメールを処理し送信できる機能(詳細後述)
  3. MacとLinuxを中心に使っている関係上、これらのプラットフォームをサポートしていること。(Microsoft Outlookが絶対に候補に上がらないのはこの理由の他にも過去の苦い経験もあります。上記1番の使用に耐えうるものでもないですし……。
  4. OpenPGPをサポートすること
  5. 複数アカウントをサポートすること(個人・仕事)

基本的には3番目のポイントで選択がかなり狭まりました。それで考えたのは、どうせマルチプラットフォームでEmacsを毎日のように使っているんだからこれで内蔵のものを使っちゃおうということでした。

「こうして越前康介はGnusを手に入れた」

ということ(?)で、個人的にはGnusを使う利点としては以下のようなものでした。

  • 上記の要項を全て満たした。
  • テキスト編集はテキストエディタである関係上、非常に強力な機能を備えている。
  • 隠し事が少ない分、細かい部分まで制御できる。(反対にいうとそれだけ操作性が粗い、ってことですが。)
  • それなりにEmacs Lispをいじったことがあるのでそこそこの改良を加えることができる。
  • Org-modeと連携できる!(リンク設定などが可能。)

今回の検討で考慮に入れなかったのは以下の通り:

  • 検索能力……どうせGmail系なんだから、餅は餅屋に任せるやりかた。結局はある程度の自動タグのほかはフラットに時系列に行っているので数週間前のメールは検索に頼った方が速いので。反対にいうと一覧表示で見つからないほど古いメールは古すぎて役に立たないか、それ以降一度もタッチしないことがほとんどなので、その管理に労力は使ってません。一応残してはいますが。
  • 通知機能……スマフォやスマートウォッチが知らせてくれるので使ってません。一応Gnus内でこれを設定することは可能のようですがあまり意味はなさそうなのでやってません。
  • リッチテキスト編集機能……HTMLやリッチテキストを送ることはないので。自分をよく知っている人ならわかるかも知れませんが、このようなマークアップでのメールは基本的に送信しません。あっても時々シンプルなマークダウンを行うぐらい。自分からのHTMLメールが届いた、という人はそれはほぼ100%、Gmail for Androidがそのように送信してしまったからです。あのアプリ、プレーンテキストしか送れないくせにHTMLメールで送信するんですよね。閲覧はブラウザを通してすることは可能です。普通はHTMLメールは互換形式としてプレーンテキストとしてついてくるので、それを閲覧しますが、プレーンテキスト版がついてくるので時々行儀が悪い(もしくは設定が不完全)なメーラーがHTMLだけで送ってくることがあります。ちなみにそういうメールは無視されるか、良くても閲覧順の最後尾に容赦なく持っていきます。

なので、上記のような機能に興味がある人は多分この記事は面白くないので、さっさとご退場をおすすめします。

さて、複数のGmail/Google Appsのアカウントを使用しているため、SMTPの使い分けが必要になってきます。この実現には
emacs 30 Day Challengeのusing ‘gnus’ to read mailという記事が参考になりました。ここでは自動的にSMTPアカウントを切り替える方法が書かれていますが、送信の規則性が非常に複雑なこともあり、ここは手動処理の余地を個人的には残しています。つまり、X-Message-SMTP-MethodやFromの変更をする方式になっています。このサイトに含まれるコードは誤って存在しないアカウントなどからメールを送信しないような対策として使用しています。この設定は以下のような感じです。

(defun gnus-set-mail ()
  (interactive)
  (message-goto-from)
  (kill-whole-line)
  (insert "X-Message-SMTP-Method: smtp smtp.googlemail.com 587 example@gmail.com.com\nFrom: Example \n\n")
  (message-goto-body)
  )

ちなみに、KDEを使っていますが、Ctrl-Alt-TはUnityみたいにターミナルを起動する設定になっていますので、Gnusでのスレッド表示切り替えはC-M-tからC-c C-tに置き換えています。ちなみにこの設定は簡単……。

(define-key gnus-summary-mode-map "\C-c\C-t" 'gnus-summary-toggle-threads)

GnusにはMMLという書式が組み込まれているため、MIME構造を柔軟にいじることができます。例えばMIMEパートを自由に入れたりといったようなことが可能ですが、基本的には添付ファイルの扱いを細かく制御するために使っています。

MIMEパートを設定してみる
MIMEパートを設定してみる

とりあえずはうまく動いていますが、今後は必要に応じて細かい挙動をカスタマイズしていく予定。

LINEのタイマートークで思うこと

LINEに新しく、タイマートークという機能が追加されました。

現在、「日本、中国以外でご登録いただいているお客さま」以外にしか使用可能になっていないそうですが、そのうちオープンになるんじゃないでしょうか。(中国では永遠に使用できないかも知れませんが)

どういう機能かというとSnapchatのように制限時間をつけたメッセージを送れるということです。(当然、両環境が最近のバージョンかつ上記の地域制限に引っかかっていない地域のユーザーである必要があります。)

使用を試みると以下のような表示がでます。

Screenshot_2014-07-31-21-24-22

これを見るとエンドツーエンドで暗号化しているようです。メニューにも暗号化キーを表示できるようになっています。見ると128ビット長のユーザー固有の鍵が使用されているです。

Screenshot_2014-07-31-21-24-36

タイマートークのメッセージを受信すると以下のようにタイマーメッセージであることが表示されます。メッセージの内容を通知する設定になっている場合もタイマーメッセージの場合、内容は表示されません。

Screenshot_2014-07-31-21-25-33

メッセージをタップすると双方でカウントダウンが表示されるのが確認できます。この長さは2秒から1週間まで選択できるようになっているようです。

Screenshot_2014-07-31-21-25-45

さて、この機能なのですが、一応エンドツーエンドをLINEで実現しようという機能は評価できるのですがいくつか思いつく問題や懸念としては……。

  1. 暗号が正しく使用されているか、また運営会社や当事者以外の機関(政府機関を含む)の鍵に対して勝手に暗号化を行っていないか
  2. 暗号鍵が変更できない使用になっているが、乱数などでちゃんと生成されたものなのか
  3. メッセージはきちんとソルトされているか

1に関してはこれはクローズドソースの宿命なので、回避のしようのない問題と言えます。これは別にLINEに限らずWindowsなどのOSを含め、どのようなソフトでも当てはまります。
2に関しては、いくら暗号を使用していたとしても暗号鍵が予想できる情報から推測できるものが生成されるような仕様になっていると無駄になってしまいます。また、正しく実装された乱数から取り出されたものであっても、変更が行われない仕様になっていると暗号鍵が漏洩した場合、役に立たなくなってしまいます。これに関しては手動で鍵を再生成し拡散できるような仕組みが欲しいところです。どちらにしても署名目的には使用していない仕様と思われますので、鍵を定期的に再生成するぐらい仕組みでもいいかと思います。
3に関しては特にLINEの場合、既知のスタンプなどパターン化されたメッセージが頻繁に使用されるシステムのため、ソルトがきちんとなされていないとリプレイ攻撃などが容易に行われてしまいます。そのため、他のソリューション以上にソルトが重要であるかと思われます。

尚、評価できる点としてはスクリーンショットの防止・通知など幻想のセキュリティが想起されるような実装を行っていないところです。Snapchatではこれが行われていますが、実際のところその通知がないからと言ってスクリーンショットが撮られていない、という保証はありませんし、基本的に他のユーザーに送られた場合、送られた情報はそのユーザーがどうとでもできる、という前提に使われるべきです。将来的にこれらが実装されるのかは分かりませんが、現時点で敢えてそれらに関して対策を行っていないのはある意味まともとも言えるかも知れません。ただ、ヘルプなどでスクリーンショットなどの撮影が可能なので、タイマーメッセージで送付先ユーザーがそのメッセージを受け取った後は必ずしも安全でない、ということは示されるべきであると考えます。