もはや国の体をなしていない、国民を虐げる国ほか デジゴトまとめ

「静止画のダウンロード違法化」 被害者であるはずの漫画家たちから猛反発

「海賊サイト対策」として静止画のダウンロードも違法化しようという法案が出ていた。 これに対しては、「被害者」とされる漫画家たちから激しい反対が出た。

だが、この反対を受けて「悲痛でない」あるいは「適切でない」という判断がなされていたわけではない。 漫画家たちの声は基本的に無視された。

結局のところ、これは「フィルタリング」と称した、「海賊版対策」という大義名分のもと行われる検閲の推進であった。 検閲を可能にするために根拠を作ろうとしたわけである。

結果的に断念したようだが、ところが…

日本政府、全国民のウェブ閲覧の検閲を開始。 HTTPSも傍受

「海賊サイトの遮断」を大義名分として、通信を監視し、さらに通信を改竄するという内容で、 しかも「とにかく実施、問題点は後から考える」という強行である。

もはや憲法を遵守する気は微塵もないようだ。 そして、コンテンツブロッキングであれだけ紛糾したことを真摯に受け止めるどころか、「静止画ダウンロードで口実を作ろうとし、それもダメなら強行でやってしまう」という非常に恐ろしい状態になっている。

HTTPSに関しては政府が発行する証明書がブラウザに組み込まれていることから、中間者攻撃によってジャックし、なりすまして検閲・改竄する、ということのようだ。

これは、やっている内容は中国の検閲・監視システムである金盾と同じである。

読売新聞、「消えるSNS」なるタイトルで暗号化を批判

基本的に読売新聞というのは極めて自民党寄りで、およそ政府広報のようなものだと思えばいい。 政府の意向を正式発表前に伝えることも多いし、私が印象的だったこととしては、民主党が大勝した衆議院選挙において、TOKYO FM(読売新聞運営)で街頭インタビューと称して「民主党は信用できない」「民主党に投票する者は愚かだ」といったコメントのみを紹介し、「国民は圧倒的に自民党支持」「民主党を支持している人はほとんどいない」という説明をスタジオでした、ということだ。 (繰り返すが、このとき結果は民主党の大勝であった)

で、その読売新聞が、安全なメールシステムであるプロトンメールを「消えるSNS」と紹介。 「捜査の支障になる」として暗号化は悪であるという論調でいつもの断定を展開していた。

結局この記事はいろいろな問題 (例えば「地下にサーバーを設置」などという言いがかりによるイメージ攻撃を含む) によって炎上したのだが、読売新聞は記事を撤回すると共に 各種まとめや反応などを検索エンジンに掲載されないように工作した という事件である。

前述の通り政府は極めて強力に検閲を推進しており、「暗号化は検閲の支障になる」という話はその意向と一致している。 そして、そのようなことを平然と言う国であれば暗号化は絶対不可欠であると言っていい。 「暗号化がなくても良い国」というのは「国民の秘密やプライバシーは何者であっても、国家であっても決して侵すことのできない聖域である」というのが当たり前の認識として存在する国であって、検閲の支障になるから暗号などけしからんなどと言ってしまう国だからこそ暗号が必要なのだ。

総務省、IoT機器への攻撃

これについては先日の記事に出したので、そちらを参照のこと。

MicrosoftのKenneth Auchenbergさん、「MozillaはChromiumを採用すべき」と主張

私見だ、ということを事前に強調した上で発言したことからも、炎上するネタだということは認識しているようだし、 であれば批判するようなことではないのだが、それでも明らかに間違っている。

Googleが完全に支配する世界にしないためにもFirefoxの存在は重要であり、またChromiumの独占となった場合ウェブは標準というものはなく、単なるベンダーロックインされた技術になるだけである。 そうなればウェブそのものが衰退するだろう。

炎上したのは、単に「内容がひどい」というだけでなく、「知識が甘い」という部分もあったようだ。

Mozilla開発者、「面倒な互換性問題に巻き込まれたくないから」Chromiumのバグを直す

最後はちょっとおもしろいニュースだ。

タイトルの通りで、CSSの@supportのバグを、Chromiumの実装はリファレンスとしてバグであってもそれが正しいように扱われてしまう現状を鑑みて、Firefox側でそれに対応した互換コードを追加するくだらない作業を避けるためにChromiumのバグを直接なおす、という方法に出たようだ。

注意

今回の記事は全体的に裏取りや検証が甘いので、ソースとしては使用しないこと

総務省、IoT機器を抜き打ちチェック

これはやばい

もう、多くを語る必要はない。

  • 「国全体での安全性」を掲げれば不正アクセスや不正利用が許されるのか
  • 遠隔システム上の正当な権限を得た者による盗撮事件などは結構事例があったりするのだが、委託した事業者、及びその実施者が悪用しないということをどうやって保証するのか
  • これを前例にして大義名分を掲げれば侵入・盗聴・盗撮などを認めることになる可能性が高いのではないか

堂々と国民の所有する機器に不正アクセスとか、どこの国だよ…

宅ふぁいる便の個人情報漏洩、一般向けに軽く解説

480万件という数字から「国内史上最悪」とも言われる個人情報漏洩事件だが、問題がいまひとつわからないという人もいるかもしれない。過去には「500円配布で済ませた」という案件もあったからだ。

特に問題である点を軽く解説しよう。

「パスワードの暗号化」

お知らせメールに「パスワードを暗号化していませんでした」という記述があり、これが問題の中心になっている。

まず、「暗号化」という言葉にいささかの問題をはらんでいる。 暗号化が意味するところ、というのは難しい話になるのだが、コンピュータの文脈においては普通は特定の条件下でのみ元に戻せる(復号化できる)ものを暗号化という場合が多い。 暗号化を行うメソッドが暗号であり、暗号を暗号たらしめるのが暗号鍵だ。

ここでいう「暗号化」はこのような暗号の話ではなく、一方向関数の話である。

一方向関数(ハッシュ関数)はAという値からBという値を算出することができるが、Bという値からAという値は算出できない関数である。

一方向関数で有名なのはMD5である。例えばpasswordという文字列をMD5にかけると286755fad04869ca523320acce0dc6a4という値が得られる。 だが、この得られた値からpasswordという文字列を得ることはできない。

サービス側ではユーザーのパスワードをデータベース上に保存するのだが、これを平文のパスワードに代えてハッシュ化された値を保存しておく。実際に認証する際にはユーザーはもちろん平文のパスワードを送信するのだが、サービス側で認証する際にハッシュ化してからハッシュ化して保存してある値と一致するかをチェックするのである。

なんのためか、というと、「パスワードそのものを持っている状態にしないため」だ。

その節の以下は付加知識で、次の節まで飛ばしてもらっても構わない。

まず、MD5に関しては「ハッシュ化した結果を同一にする手法」が見つかっており、パスワードにおいては「正しくないパスワードで突破されてしまう」リスクがあり、不十分なものとなっている。 現在十分とされているのはSHA256だ。SHA256でpasswordをハッシュ化すると6b3a55e0261b0304143f805a24924d0c1c44524821305f31d9277843b8a10f4eが得られる。

また、単にハッシュ化しただけでは、一発で特定されるわけではないものの、複数の(同一ユーザーの)パスワードリストを手に入れたときに、「同じパスワードを使っている」ということは一発でわかってしまい、かつ法則性などを推測して突破するのも可能性として生まれてくる。

そのため、基本的には“salt”と呼ばれる値を付加してハッシュ化する。 例えばsaltとしてCを使い、passwordCとしてからハッシュ化するとSHA256では57f99e20c1e9f0f7355c3afd44715bda1dc0bd01db08509c4026c56d63bced3dとなり、全く異なる値が得られる。 こうすることでより安全にすることができる。

その必要性

なぜパスワードそのものを持っているといけないのだろうか。

答は、「パスワードが保存されているデータベースを見るのはかなり簡単である」ということがある。 もちろん、漏洩時のリスクを低減するというのもあるが、「内部犯による流出、あるいは悪用」を防ぐという意味もある。

また、第一に漏洩したときに平文で保存されていると、漏洩した情報を手に入れた人は直ちに不正利用可能な状態になってしまう。 ハッシュ化されているとなんらかの突破口を見つけて解き明かさないと不正利用できない。

また、あなたはすべてのサービスでパスワードを異なるものを使っているだろうか? 恐らくそんなことをしているのはセキュリティの専門家くらいのものだろう(私はやっているけれども)。 だから、平文で保存されていると他のサービスまで巻き込んで大きな被害が出やすい。

絶対に漏洩しないようにする、というのは多人数が関わるシステムでは現実的に不可能である。 そのため、「もし漏洩したとしてもなるべく被害が小さいように設計しなければならない」のであり、480万件もの個人情報を扱いながらそのような意識を持っていなかったことが批判されているのだ。

それだけでは終わらない

メールで「漏洩があったのでパスワードを変更するように」と呼びかけていながら、システムをロックし、パスワードが変更できないようにしているという矛盾した対応にも批判が集まっている。

また、「不正利用を確認していない」というが、実際不正アクセスがあったとして、それが「宅ふぁいる便のユーザー情報 に由来して発生したものか」ということを検証するのは極めて難しく、そもそも検証しようにも誰もがそのデータを入手できるわけではないから、宅ふぁいる便が拒否して否定すればそれ以上は追求しようがない。

だから、「不正利用を確認していない」という発表は何の役にも立たない。

これはそういう問題である。

本人だけの影響ではない

「そのサービスは使っていないから自分は関係ない」と考えるのは早計だ。

不正ログインの試行において使用するパスワードは、まず過去に使われたことのあるパスワードを使うリスト型攻撃が鉄板である。 さらにいえば、使われたことのあるパスワードがわかっていれば、AI流行りの今の御時世、「法則から人がつけそうなパスワードを類推して試みる」のがいかに容易かというのは想像に固くないだろう。

つまり、パスワードの流出は悪意ある攻撃者の辞書を分厚くし、関係ない人のパスワードが破られる可能性も向上するのである。

バリュードメインの移管乗っ取り事件

どういう事情なのかわからないが、 この事件に関して裏付ける情報が検索で出ないため、今回の記述には裏付けがなく信憑性には疑問があることを初めに申し添えておく

事の次第としては次のようなものだ

  • アミューズクラフトのウェブサイトがアクセス不能になる
  • 新規に作られたTwitterアカウントから 「アミューズクラフトがドメイン移管を受諾し正式に譲り受けたものである」 というリプライをアミューズクラフトが受け取る
  • 同アカウントのスクリーンショットには他にも多数の著名ドメインに対して移管を申請し、却下された様が映っている

これでわかる人にはわかると思うのだが、順に説明していこう。

まず、アミューズクラフトとは株式会社ソフパルの運営するゲームソフト開発事業部の名称である。 アミューズクラフトはアダルトゲームを制作しており、特にユニゾンシフトブランドから販売しているものが有名。 ユニゾンシフトブランドの著名の理由としては、電撃文庫から販売されている人気ライトノベル作品である「灼眼のシャナ」シリーズの挿絵を務めるいとうのいぢさんが所属していることが大きいだろう。

次にドメイン移管とはなにか、というと、舞台になったのはamusecraft.jpドメインだが、ドメイン移管とはそもそも「自分が所有するドメインを別の業者に管理してもらうために行うもの」であり、他者が譲り受けることを申請するものではない。この時点で乗っ取りを狙ったものは明らか、ということになる。

この一連の話はNAVERまとめにちょっとだけ載っている

だが、「ついOK押してしまったのか」などという言い方をしていることから多くの人は知らないのだと思われるが、 そもそも「移管申請の告知を受け取って10日間アクションを起こさないと承諾となる」というルールである。 つまり、「担当者が気付かなかった、あるいは無視した」という問題なのだ。

これを受けてバリュードメインは「10日間アクションがなければ拒否する」に仕様を変更した。 これについて徳丸浩さんは

このリリース、自社(バリュードメイン)は悪くないけどメール読まない利用者がいるから安全方向に倒すと言わんばかりで、「お客様には大変ご不便をお掛けいたしますが」というのも意味不明(自動承認がなくなるから?)だけど、元の仕様は脆弱性だと思います

発言している

だが、そもそもこの仕様(バリュードメインで管理されているjpドメインは簡単に乗っ取れる)は知られた脆弱性であったという話もある。 検索でも出てこないため隠蔽されている可能性もあるが、バリュードメインの責任も無視できないのではないか。

また、当該Twitterアカウントは犯行声明のようにアミューズクラフト傘下のアカウントに乗っ取ったことと正当性を繰り返し発言していることから、金銭目的か(当人は否定しているが)、もしくは犯罪によって注目を浴びたいがためだと思われる。

ドメイン乗っ取りのツイート

ドメイン乗っ取りのツイート

当人は犯罪には該当するはずがないと主張しているが、偽計業務妨害とは

虚偽の風説を流布し,または偽計を用いて人の業務を妨害する罪 (刑法 233) 。流布とは,犯人自身が公然と文書,口頭で伝達するほか,口伝えに噂として流す行為も含む。偽計とは人を欺罔,誘惑し,あるいは人の錯誤,不知を利用する違法な手段をいう。たとえば被害者の商標と酷似したものを使用して粗悪品を売出したり,漁場の海底にひそかに障害物を沈めておいて漁網を破損させる行為などである。

とコトバンクにある通りであり、当たる可能性は高いのではないだろうか。

昨今のブラウザ事情

ウェブブラウザとウェブテクノロジー

今やウェブブラウザは中核的ソフトウェアといって過言ではないだろう。 世界はウェブを中心に回っているのが現実だ。

だが、それは問題をふたつもたらしている。

ひとつは、過当競争だ。

あまりにもウェブに依存しすぎているがために、ウェブが高度技術化し、開発コストも増大しとてもついていくのが困難になっている。 現状ウェブ開発をリードしているのはGoogleであり、ChromiumによるBlink/V8エンジンが最も進んでいる状態だ。 これに対抗するのはMozillaのGecko/SpiderMonkeyで、Chromiumよりも進んだ実装を行うこともないではないものの、現実にはFirefoxに実装されChromiumに実装されない機能は大概標準化されないのが現実だ。 (ただし、標準化においてはある程度Mozillaが主導権を握る展開が続いている)

MicrosoftによるEdgeHTMLはこれと比べて明確に遅れをとっている。 これはちょっとした理由がある。 そもそもEdgeHTMLはWebKitをターゲットとしているのだが、WebKitは現代ではとてもではないが使い物にならない。

WebKitを開発しているのはAppleだし、そもそもWebKitはSafariのものなのだが、WebKit自体はオープンソースだし、他のソフトウェアも利用することができる。 とはいえqtwebkitに関しては既に廃止となっており、WebKitのバージョンも古い。

WebKitとBlinkを比べる良い手段はMidoriとFalkonを使用することだろう。 MidoriはAppleがcommitするWebKitGtk+を使用しており、一方Falkon(かつてのQupzilla)はBlinkを使用するQtWebEngineを使用している。 そして、Falkonで表示に困ることはないのだが、Midoriでは普通に「表示できないサイト」や「利用できないサイト」が存在するのだ。

根本的にWebKitはカジュアルでライトなウェブブラウジングに的を絞っていると考えて良い。 つまり、ちょっとした調べ物などであり、完全に表示できることよりも軽快であることを望むためのものであり、実際Safariは機能的にかなり限定的である。 最小限の機能を搭載することからも「ちょっとした行為」であり、目を尖らせてに向き合うものではないと考えているのがわかる。

実際、Microsoft Edgeもそのような考え方であり、機能的に貧弱だったInternet Explorerと比べても機能はさらに削られており、メニューは実に寂しい。

生殺与奪を握られたウェブエンジン

だが、この問題はなかなか複雑だ。

AppleとGoogleはこれらウェブエンジンを「自由に使わせなければならない」呪縛にとらわれている。

これはもともと、Appleが既にある程度成熟していたウェブエンジンに参入するにあたり、スクラッチから開発することをよしとせず、KHTML/KJS Softwareをベースにすることを選択したことある。 当時のKHTMLはLGPLだったので、ここから派生するためにはLGPLを継承せざるをえなかった。 もちろん、そのWebKitから派生したBlinkにしても同様にLGPLを継承するしかない。これにより望む望まざるに関わらず「開発したものは配布するためには公開し自由を保証しなければならない」ということになったのだ。

そのため均衡が保たれているのだが、実際技術標準というか、「ウェブの世界」そのものは主にはGoogle、そしてAppleの意向は完全に反映されるのであり、 世界をウェブが支配している以上世界の支配者として君臨する状況を許してしまっている。

これは、GoogleやAppleが「採用する」と決めた方針に反する方法がないという問題だ。 LGPLである以上、ウェブブラウザを「秘密」にしてしまったり、伏せられた邪悪な機能を搭載するのは難しい。 だが、正式にプライバシーを侵害するような機能、仕様を採用すると決定したとして(既にそのようなものがなくもないが)、それを覆すことができない。 もちろん、フォークするという選択肢はあるが、ウェブブラウザの規模と進歩を考えるとGoogle並の開発力で追従するということは現実的ではない。 結局のところ誰もがGoogle, Mozilla, Apple, Microsoftの少なくともいずれかには従わなければならないという状況にあるのだ。

実際、Chromeユーザーでも「Google及びChromeに対する信頼度」はかなり低いというアンケート結果がある。

唯一の良心といえるのがMozillaだが、Mozillaの体制や行動がプライバシー上の理由で批判されたことは一度や二度ではない。

結果的に我々の生殺与奪は彼らに握られているというのが現実であり、 そして現状においてはそれを覆すほどのリソースはどこにもないのだ。 これはOperaのような老舗ブラウザ屋がBlinkを採用し、WebKitの祖先であるKDE ProjectがQtWebEngineを採用していることからも明らかだろう。

セキュリティとプライバシー

もうひとつの問題はウェブを侵食するプライバシーの問題だ。

セキュリティについて昔と比べることは意味がない。

昔はセキュリティを脅かすものは見るからに怪しげな「悪人」であり、「怪しげなものを遠ざければ良い」というものだった。 また、そのようなセキュリティ上の問題は「プライバシーの問題」ではなかったのだ。

ところが現代においてはサービスを利用する上でプライバシーを侵害されることは前提であり、 それどころかウェブブラウザを利用することによってもプライバシーが侵害されるという状況にある。

なぜこのような状況になるのか。

まず、Facebookを筆頭にして、現在はプライバシーが主要な商品となりすぎていて、 どこもかしこもプライバシーを欲しがるという現状がある。 これはウェブの技術如何に依らず根本的な問題である。 「プライバシーを侵害したいと思う人がいなければプライバシーを侵害するものが作られることはない」のだから。

だが、彼らウェブブラウザデベロッパー達はこれらの「プライバシーを侵害したい」という要求に応えているし、 また彼ら自身がプライバシーの侵害を望んでもいる。GoogleやAppleが過剰かつ積極的に個人情報を収集している状況を忘れてはいけない。

我々は日々普通に使っているだけでも著しくプライバシーを侵害され続けている状況にあるのだ。

プライバシーを取り返せ

中には完全にプライバシーを保護するブラウザもなくはないが、代償は大きい。 そうではなく、普通は求めているのは「与えて良いと判断して選択し許可した以外のプライバシー侵害は認めない」というものだろう。

だが、これはなかなか難しい。 ウェブブラウザの根本的な機能として既にプライバシー侵害を可能にする機能が組み込まれているからだ。 例えばComodo Dragonはプライバシーを重視しているということだが(PrivDog事件もあったが)、トラッキングなどは普通に行えてしまう。

また、Vivaldiもプライバシーを重視しているが、それでも問題になっているプライバシーはあまり解決しない。 裏側で悪意ある行動をとっていないというだけで、知られないうちに何かが行われることを防いでくれるわけではないからだ。

ある程度、そして確実に効果がある方法は「セッションを残さない」ことだ。 トラッキングが最も驚異なのは、「アクティビティが同定でき」「蓄積されるから」だ。 蓄積されなければ同一人物なのか否かを特定することは困難になるし、取得可能な状況はある程度限定的になる。

Chromiumならば次のようにすれば最初からプライベートモードになるし、使うたびに情報はクリアされ、ある程度安心だ。

chromium --incognito

もちろん、これでTwitterとGoogleとFacebookに同時にログインしたら台無しである。 そんなことはせず、他のサービスを利用するときは必ずブラウザを閉じて行うべきだ。 これは、ログインしなくても、サイトごとにセッションを切るべきである

Vivaldiも--incognitoオプションを受け付けるため、Vivaldiを使えばさらに(いくらか)安全になる。 Linuxにおいてはデフォルトブラウザとして--incognitoつきでVivaldiを起動するようにしてしまうといい。 以下は私が使用している$HOME/.local/share/applications/incogvivaldi.desktopファイルだ。

[Desktop Entry]
Version=1.0
Name=Vivaldi Incognito
# Only KDE 4 seems to use GenericName, so we reuse the KDE strings.
GenericName=Web Browser (with Incongnito)
GenericName[ja]=ウェブブラウザ (with Incongnito)
Comment=Access the Internet (with safety)
Comment[ja]=インターネットに安全にアクセス
Exec=/usr/bin/vivaldi-stable --incognito %U
Terminal=false
Icon=vivaldi
Type=Application
Categories=Network;WebBrowser;
MimeType=text/html;text/xml;application/xhtml_xml;image/webp;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;
Actions=new-private-window;

[Desktop Action new-private-window]
Name=New Incognito Window
Name[ja]=新しいシークレット ウィンドウ
Exec=/usr/bin/vivaldi-stable --incognito

デフォルトの.desktopファイルとの違いは以下の通り

  • 起動時に--incognitoオプションを付加
  • 日本語と英語のみにし、翻訳を排除(どうせ読めないし、ローカル設定だし)
  • new-windowアクションを除去し、デスクトップの右クリックメニューもIncognito限定に

これで開くアプリケーションの選択肢としてVivaldi Incongnitoが追加される。

プライバシーを強化する設定やプラグインを追加すればより万全だろう。

いちいちセッションを切るのは面倒だ、というまっとうな意見のために、私はMy Browser Chooserというソフトウェアを開発している。 サービスごとにプロファイルをわけてしまえば、サービス側がプロファイルを横断しての情報収集はできない。 運用ポリシーさえ守ればだいぶ楽になる。Zshスクリプトなので、Unix的な環境においてのみ機能する。

危ういスマートフォンブラウザのプライバシー

パソコンなら(特にLinuxならば)このようにいくらかの解決策を提示できる。 だが、本当に厄介なのはスマートフォンだ。

スマートフォンの場合ブラウザが握ることができる情報はパソコンの比ではない。 だが、にもかかわらずユーザーに与えられるコントロールは極めて少ない。

スマートフォン的な設計思想として、「可能な限りコントロール部品を減らす」というものがある。 例えばMicrosoft Edgeはメニューボタンがハンバーガーメニューになっておりドロワー式だ。これはタッチデバイス向けの設計であり、GNOME3もまた同様の設計になっている。 ドロワーに含まれるメニューも少なく、ここまでメニューを減らしているのは当然に相応に機能自体を削っているということである。 機能が多ければそれだけなんらかの煩雑さを持たざるをえないからだ。

このような設計にしている理由はふたつある。

ひとつはスマートフォンの狭い画面での煩雑性が操作性の低下に直結するためだ。 そして、もうひとつはユーザーが馬鹿でいられるようにである。

私はこのような考え方は好きではない。 なぜパソコン用のソフトウェアが低機能なスマートフォン設計を採用せねばならないのか?

このコントロールの少なさがプライバシーの問題にも直結している。 現在では必須ともいえるプライベートモードがひどく軽視されているし、ページを開く時点でプライベートモードで開く選択肢を与えられない。 スマートフォンはパソコンよりもアプリからリンクを開く機会が多いにもかかわらずだ。

もちろん、プロファイルの切り替えもサポートされていない。 結果的にスマートフォンに蓄積された情報が簡単に抜き取られてしまう状況である。 なお、ブラウザを使い分けたところでAndroidならば多くのブラウザはAndroidのWebEngineを使用しているため、中身はひとつ、結局は使い分けに意味などない。 iOSについてはあまり知らないが、おそらくは似たようなものだろう。自前でのウェブエンジン実装はあまりに困難だからだ。

ひどい話だと思う。 だがAndroid WebEngineとはつまるところBlinkであり、なかなか太刀打ちできるものではない。

使い分けるのであれば、Mozilla FirefoxとMicrosoft Edge、そしてBlink系ブラウザ(Chrome, Operaなどだ)を使い分けるという方法だ。 数が少ないのであまりリスク軽減はできないが、いくらかマシな方法だろう。

元は表現力も機能も安定性もひどいものだったAndroid Firefoxだが、現在はかなり改善されており、十分実用になる。 Quantam(Firefox 57以降)をもてはやす記事ほど素晴らしいものだとは思わないが、「Firefoxが実用になる」しいうのは極めて喜ばしいことだ。

それよりも推奨できるのはFirefox Focusを使用することだ。 Firefox Focusは常時プライベートモードのFirefoxである。firefox --private-window相当ということではなく、プライバシー保護のためにかなりenhanceされている。 ほとんどのブラウジングにおいてはFirefoxで困ることはなく、またアクティビティを保存する必要もない。 そして、Mozillaによって提供されるFirefox FocusはCM Security Browseなどを使うよりもよっぽど信用できると言える。

そう、ブラウザは重大なプライバシー資源となっているために「信用できるか」が極めて重要なのだ。 ましてスマートフォンブラウザならなおさらで、プライバシーの塊であるスマートフォンを狙ったアプリなど数知れずある。 言ってしまえば大部分は怪しいし、よほど信用できない限りは使えないのが現実である。 ブラウザはその基本的な動作においてほぼ全権を要求するという点も大きい。正常に動作させるために権限を与える必要があるためにリスクが高いソフトウェアなのだ。

言い換えれば、悪意ある人からすれば「これはブラウザです」というふうに言っておけば

スマートフォンブラウザの機能にも不満

典型的なのはOperaで、Operaは以前はかなり高機能なブラウザであった。 PCブラウジングやページ保存、印刷機能も備えていたのだ。

ところがそれらの機能は現在はもうない。スマートフォンには必要ないと判断されたのだろう。 だが、実際はOperaはもはや必要な機能が削除されてしまって使い物にならない。 このような「スマートフォンだから」という言い訳は、一体スマートフォンだからなんだというのかと思うほどに理由になっていない。

表示の難しいinspectionなどはまだしも、印刷、ページの保存、文字エンコーディングの選択、プラグイン、ページ検索、 ローカルファイルの取り扱いなどがスマートフォンにおいて欠けている必要があるのだろうか? それ以外にもウェブブラウザが様々に豊富な機能を備えているにもかかわらず、スマートフォン版ではない、あるいはコントロールする手段が与えられていない。 なぜスマートフォンではユーザーからコントロールを剥奪するのか。理解し難い。

Vivaldiのようなブラウザをスマートフォンに最適化させたようなものは出ないのだろうか。 一応、Vivaldiのスマートフォンバージョンの開発は行われていはいるようだが。

Lenovoのコンピュータに搭載されているVisualDiscovery(通称Superfish)が、極めて悪質かつ危険なソフトウェアであったことがわかり、問題となっている。


Gigazineの記事
が分かりやすいだろう。

極めて危険なので、該当するユーザーの方は直ちに削除したほうが良い。

当サイトがウィルスバスターにブロックされる件について

当サイトがウィルスバスターによってブロックされる、という話は去年にもう聞き及んでいたのだが、その時点ではSSL証明書がルート認証局の署名をとっていないのが原因だろうと判断し、HTTPSでのアクセスをできないようにした。だが、2/16に依然としてブロックされるという情報が入り、調査したところ、どうやらウィルスバスターの「よくある誤検知」であるらしい。


同様に誤検知された方のブログ

このサイトはまだ、iPhoneのJailBreak(自身のiPhoneに標準でかけられている操作上の制約を解除し、iPhoneの管理者権限を取得する)に関する話題を取り扱っているのでわかるといえばわかるが、まっさらなサイトがターゲットにされることも。


新しく取得したドメインに初めてアクセスしたら、ウイルスバスターに「安全ではない」と警告された!

ウィルスバイターの(トレンドマイクロの)暴挙は有名で、

Slashdotで記事にもなっている

そもそも、スパムとウィルスの配布を行っているサイトだと言うのだが、当サイトはメールマガジンの配布すらしておらず、ドメインはスタッフのみが所有する。また、当サイトは何らソフトウェアの配布を行っていない。極めて言いがかりだ。

トレンドマイクロは頻繁に政治的圧力をかける。例えば2014年秋にはキュレーションサービス(2chやTwitterなどの発言をまとめたサイト)を一斉に有害なコンテンツのサイトと認定、そのほかWindowsの詳細設定を変更するツールをウィルスとみなし、最も危険なソフトウェアはCRPM解除ツールだと言う。

ちなみに、CRPM解除ツールを説明すると、いわゆるcopybreak、コピー防止機能を無効化するためのものである。日本においてはその配布、使用共に違法だが、本来私的複製は認められるべきものであり(日本ではデジタルデータの私的複製自体を禁止している)、これを禁止している先進国は日本くらいのものである。そして、トレンドマイクロは決して日本ローカルな企業ではない。

仮に倫理的側面で反対するという立場をとるにしても、それが「セキュリティ上脅威である」という判定は著しく不当である。「あいつのやり方は嫌いだ」という理由で「あいつは詐欺をしている」と社会的信用を背景として吹聴しているのだから。

風評被害を振りまいた上で「やめてほしければ金を払え」というやり方はひどいものだと思う。この「金を払え」はトレンドマイクロに直接支払うものではないが、かなりの金額である。当然ながらそのようなことができるのは大手だけであり、

そもそも風評被害を振りまいて、やめてほしければ金を払えというのは「反社会敵勢力のやり方」ではなかったのか?

まずは異議申し立てを行った。改善がみられなければ、訴訟しかあるまい。

HARUKA Sound/Aki SI&Eの正木と申します。

当サイトが危険である、との判定によって業務に多大な支障が出ております。

当サイトは所有するドメインによるメールアドレスは現在すべてスタッフ所有のものであり、メールマガジン、メーリングリストを含むマルチキャスティングは一切行っておりません。

また、サイト上でプログラムの配信を行っている事実もなく、技術的な内容の記載、業務のご案内を行っているものです。

早急に修正されますようお願い申し上げます。

Mail Virtual Alias @ CentOS 6

メールサーバーの本運用は通常virtualであるはずだ。メールアカウントの数だけユーザーアカウントがあるというのは考えられない。

ただし、私の場合はサブドメインをバーチャルエイリアスにするため、バーチャルドメインが必要になる。

新しいDovecotに関する情報がなく苦労したが、http://vogel.at.webry.info/201312/article_10.htmlの通りにやってみた。大体これでうまくいったのだが、私の場合はいくつかひっかかった点があった。

まず、hown -R mailuser ~mailuserをちゃんと実行しておかなくてはいけないこと。vmailboxファイルは最後に/をつけ忘れるとmbox形式になってしまうこと。

しかしこれではPOPの認証がfailedとなる。調べてみると、このサイトにはデフォルトでコメントアウトしているauth-passwdfile.conf.extのロードをしていない。

[root@server ~]# grep -R auth-passwd /etc/dovecot
/etc/dovecot/conf.d/10-auth.conf:#!include auth-passwdfile.conf.ext

さらに、パスワードファイル認証も無効化されている。

[root@server ~]# grep disable /etc/dovecot/conf.d/10-auth.conf
#disable_plaintext_auth = no
# Authentication cache size (e.g. 10M). 0 means it’s disabled. Note that
# 0 disables caching them completely.
# NOTE: See also disable_plaintext_auth setting.

この2点を修正したが、それでもエラーになる。原因はパスワードファイルのファイル名(設定ではなくファイル自体)が間違っていたためのNo such file or directoryだった。

さらにPostfixからのDovecot認証の利用は情報が錯綜してよくわからない状態だったが、結局のところ/etc/dovecot/conf.d/10-master.confのPostfixから利用するコメントアウトをはずすだけでエラーは出なくなった。しかしながら、認証自体がうまくいかない。userとgroupの設定を追加したが、元々666なのだから、効果はなかった。明らかに問題はPostfixにあり、Dovecotはこれでいいだろう。

telnetを打ってみると25番ポートが反応しない。ここでOP25Bによるものだと気付いた。

submissionの設定を探してみると、master.cfにsubmissionの項目があり、このコメントアウトをはずせばsubmissionは機能する。しかしながら

submission inet n – n – – smtpd
# -o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING

TLSを強制するとTLSが機能しない。とりあえず、TLSは要求しないことにした(encryptでなくmayにしておく)。

しかし、それでも544 host access deniedという応答で送ることができない。調べてみると、さらに別のパラメータを設定する必要があるようだ。main.cfに記述する。

smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_relay_restricions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
broken_sasl_auth_clients = yes

さらにスペルミスにもひっかかってしまったが、これでうまく通った。TLSが上手く動かない以外は正常だ。

TLSについて調べてみると、どうも鍵にパスフレーズがかかっていると使えない、ということだ。そこで、次のようにして問題の解決を図る。

[root@sesrver]# openssl genrsa -aes128 1024 server.key
Generating RSA private key, 1024 bit long modulus
.++++++
…………………….++++++
e is 65537 (0x10001)
Enter pass phrase: #ここでは普通にパスフレーズを入力する
Verifying – Enter pass phrase:
[root@dti-vps-srv71 certs]# openssl rsa -in server.key -out server.key #これによってパスフレーズを消滅させる
Enter pass phrase for server.key:
writing RSA key
[root@dti-vps-srv71 certs]# openssl req -new -x509 -key server.key -days 3650 -out server.crt # certファイルを作る
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [XX]:JP #カントリーコード
State or Province Name (full name) []:Kanagawa #神奈川
Locality Name (eg, city) [Default City]:Yokohama #横浜
p {[
“さらにスペルミスにもひっかかってしまったが、これでうまく通った。TLSが上手く動かない以外は正常だ。”,
“TLSについて調べてみると、どうも鍵にパスフレーズがかかっていると使えない、ということだ。そこで、次のようにして問題の解決を図る。”
]}

sb { -END
[root@sesrver]# openssl genrsa -aes128 1024 server.key
Organization Name (eg, company) [Default Company Ltd]:HarukaSound #組織名
Organizational Unit Name (eg, section) []: #部署はない
Common Name (eg, your name or your server’s hostname) []:reasonset.net #FQDN
Email Address []:master@reasonset.net #メールアドレス
[root@dti-vps-srv71 certs]# openssl x509 -in server.crt -outform der -out server.der # derファイルの生成

これで鍵の生成は完了。ファイル名が若干変わったので、main.cfを修正。さらに、DovecotのSSLが設定されていなかったので、/etc/dovecot/conf.d/10-ssl.confを修正(ssl = yesのコメントアウトをはずし、ファイル名を修正)。

そしてmaster.cfencryptに戻して完了。STARTTLSが正しく働くようになった。

セキュリティインシデントの顛末

先日、Mageiaで生じたトッププロセスからのfork bombだが、そのあとシステムを再構築したあとAgrusのログを参照して漏洩確認をするなどかなり大変な作業だった。

しかし、システムを構築した段階で再びnepomukの名が復活してきた。ケーブルを抜いて他のPCで調べてみると、どうもKDEのコアが利用しているらしいのだ。nepomukを持っているのはnepomuk, nepomuk-coreだが、kde-coreにも含まれている。KDE PIM、特にKmailがこれを必要とする。

nepomukを邪魔者と考える人もいて、停止するというやり方もあるようだが、私はとりあえずnepomukとnepomuk-coreをアンインストールして対処した。害がないとしてもこんなにトップを走りつづけるようなプロセスは困る。もっとも、このトップを走り続けることはbugらしいのだが。

さらに、fork bombは別件で、kblankscrn.kssというプロセスが大量にforkされる。これはどうやらブランクスクリーンのスクリーンセイバーに起因するらしく、これで検索すると非常に多くのbug報告があがる。

結局ふたつのbugが重なって勘違いした。システムがすぐに必要で調査のために停止させられなかったためシステムを再構築という方法をとったが、結果としてそれは失敗だった。調査を先にしていれば早く問題ないと分かり、復旧できただろう。

随分と苦労したのだが、顛末はこんなもの。漏洩がなくよかったのだが、なきたくもある。