フットプリントのおはなし

先日フットプリントの話題になったのだが、いまいちピンとこない人が多いようだったので、 情報技術におけるフットプリントについて解説する。

フットプリントとは

フットプリントは匿名の活動記録である。 それ単独の情報が固有である(ID代わりに利用できる)ものはフィンガープリントというが、フットプリントは単独の情報としてはそれほどの意味はない。 もちろん、統計上の価値はあるのだが、フットプリントという場合には、異なるアクティビティをつなげることを前提としている。

典型的なのはユーザーエージェントとアクセス元IPアドレスである。 IPアドレスは場合によっては固有であることもあるが、一般的には(普通のユーザーは)固有ではない。 よって、これらの情報は特にフィンガープリントとしては機能しない。

ただし、私の場合割と珍しい条件を揃えている。 まず、私のUAはMozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.122 Safari/537.36 Vivaldi/2.3.1440.61である。あまり特色がない、と感じるかもしれないが、(X11; Linux x86_64)の記載がある時点でだいぶ絞られる。さらにいえば、UbuntuやFedoraや(Vivaldiの場合どうかはわからないが)ディストリビューション名が入ったりするため、さらに絞られてしまう。

そして、私はIPアドレスも、固有ではないがかなり珍しい。 私の観測範囲においてはこの組み合わせを持つユーザーは他にいない。「観測範囲ではいない=活動範囲ではいない」であるため、逆に私の活動圏においてはこのUAとIPアドレスの組み合わせは私である、ということがわかってしまう。

これは割と珍しい例だ。例えば@NiftyでWindows 10のGoogle Chromeを使っているユーザーなんてたくさんいるだろうし、Softbank mobileのiPhoneユーザーもたくさんいるだろう。 ではこれらは全く特定できないか?というとそんなことはない。

まず、ある瞬間に同じIPアドレスを持つのは、同一のNAT内にあるコンピュータだけである。 ユーザーエージェントは意外と一致しない(ログをソートしても異なるユーザーで全く同一のユーザーエージェントを示すケースはかなり少ない)ので、連続的にアクセスしていた場合、そのユーザーの「特徴」を掴むことで同一人物であることを特定でき、またIPアドレスの変わり際はその「微妙に違うIPアドレスと行動の連続性」によって特定できてしまうので、追跡することができる。

IPアドレスとUA以外にも

  • 通信速度
  • 反応を返すまでの応答時間、ラグ
  • コンテンツ中のロードする内容
  • 滞在時間の傾向
  • 選択するリンクの傾向
  • ページロード中にページを離れる率とタイミング
  • タッチデバイスでの操作か否か
  • 表示領域のドット数とウィンドウのドット数
  • スクロール速度と量
  • スクロールを止める箇所
  • ページをクリックや反転させるクセがあるかどうか
  • ブラウザで有効化されている機能

などなどフットプリントとして機能するものは非常に多く、本気を出せば人物の同定は非常に簡単である。 避けることはできない。

もっとも、現実にはこのようなケースではトラッカーを使うほうがずっと簡単であるため、このような高度な行動分析は行われない。 このような高度な行動分析を必要とするのは、どちらかといえば私のように行動と心理に関する情報を必要としている者だ。

ちなみに、安心してほしい。 私はトラッカーが死ぬほど嫌いなので、私が提供しているサイトにはトラッカーはないし、不要にクッキーを使うようなこともしていない。1 統計的情報としての範囲を越える利用は全くしていない。

横断する恐怖のトラッキング

このようなフットプリントはローカルに持っていて、そこにとどまるのであればそれほど怖いものではない。 だが、横断すると話は全く別である。 横断すればその人がとっている一連の行動がわかる。ずーっとインターネットにおける活動を監視しているのと同じだ。期間が長くなってくれば、次の行動も予測できるようになる。

かなり大きいのは、Tポイントカード、Dポイントカード、楽天カードといったポイントカードの利用と、Suicaなど交通系ICカードの利用である。 これらはかなり利用を避けがたいのだが、ここに残っているフットプリントは結構致命的な内容である。 TポイントやDポイントやSuicaの内容がほいほい第三者に利用されていることについて、人々はもっと強く危機感を持つべきではなかろうか。

私は防衛型のハッカーなので、「まず自分が攻撃することを想定し、次にどのようにすれば防衛できるかを考える」という手順を取る。 これに則って考えれば、情報へのアクセス難易度や行動上の条件によって阻まれない、という前提のもとであれば、その人物が「どこに住み」「どのような生活サイクルで」「どのような手段でどこへ移動し」「どのようなクセを持っていて」「どのような行動を取るか」ということが把握できる。 どこに勤めているか、どのような生活をしているかはもちろんのこと、日用品が足りないのではないか、食料を買いにいかなければならないのではないか、ということも、次にどのタイミングでスマホでどのサイトを開くか…というのも手に取るようにわかるわけだ。 ここまで分かれば煮るなり焼くなりという状態である。ピンポイントにメールを送るも良し、フィッシングサイトで釣り上げるもよし、あるいはエンカウント数分前着程度の滞在時間で人気のないところで待ち伏せるもよし、である。

そんなまさかと思うかもしれないが、諜報機関ではこれくらいやる。 北朝鮮の拉致だって、今ならこのレベルでやるかもしれない。 というか、私で具体的方法を含めぱっと思いつくのがコレなのだから、ガチ勢はもっとやばいと思ったほうがいいだろう。

そして、このような横断してフットプリントを集めるという作業は日常的に行われ、私達は日常的に目にしている。 そう、ターゲティング広告だ。

「目立つフットプリント」は匿名化以上の損失になりうる

個人情報に紐付かないフットプリント の対応として適切なのは「森に入る」であり、なるべく紛れることである。

例えば匿名化ウェブプロキシでアクセスすると、身元が隠蔽されるため安全である、と考えるかもしれないが、実際のところ匿名化プロキシでアクセスしてくる人というのは非常に少ないので、大変に目立つ。 匿名化プロキシの効果でそれが誰であるか完全に特定できなかったとしても、そのようなものを使う人自体が大変少ないので、使っていること自体によってかなり絞り込めてしまう。

そもそもフットプリントから追跡対象を決めるときは「特徴によって決める」のが普通なので、目立つフットプリントはそれだけで目をつけられる可能性が高い。

検閲による効果は、検閲を回避する者にまで及ぶわけである。

特徴的な行動、少数派などは、フットプリントによる追跡からの防衛という観点から言えばなるべく避けたいのだ。

防ぐことの難しさ

正直なところ「祈るしかない」とは言える。

例えばテクノロジーに疎く、ケータイも持っていなくてSuicaも使わない、という人であれば追跡できないかというと、そんなことはないのが現代社会だ。 情報を過剰に収集している上に、あまりにもそれを濫用している。

現代社会においては極めて知悉した上で、細心の注意を払い、非文明的暮らしをすればフットプリントを限定的にできる。 だが、それはそれで「追跡しづらい、謎めいた人物」というフットプリントが浮かび上がってしまい、マークされることになるかもしれない。

このような不躾な追跡は、それが例え私の研究の進展に寄与するとしても、人の平穏な暮らしという観点から到底許されるべきではないと、私は思っている。


  1. WordPressを使っているサイトはWordPressが使っているかもしれない。それには私は関知していない。

認証と権限の根本的な考え方

最近、法人設立における印鑑登録を必須でなくす法案がはんこ業界の反対によって頓挫したのだが、その際に

欧米のサイン制度と違い、代理決済できるという印章の特長が、迅速な意思決定や決裁に繋がり、戦後の日本の急速な発展にも寄与してきたという自負もあります。

と声明を出し、失笑を買った。

根本的に、印鑑が証明として効力を持つのは、「同一の印鑑は本人しか持っていないはずだから、その印鑑を持っているのは本人である」という前提に基づく。 つまり、「本人以外がはんこを押せる」という状態は「hackされた状態」なわけである。

ところが、業界的にそのhackを認めてしまったことで、逆に「印鑑は本人の意思の証明にはならない」ということを主張するという本末転倒な状態である。

予め言っておくが、私は印鑑は 嫌いではない 。もちろん、印鑑文化にまつわる無意味な儀礼的要素や形式などは 唾棄するほど嫌い だが、印鑑自体はそれなりに好きで、私が使っている印鑑はかなり凝ったものである。会社設立のときも私の強い推しによって特殊な印鑑を制作した。

また、この話はセキュリティ的な認証と権限の話であり、 はんこの話ではない

認証

はんこやサインがどのような意味を持っているかということを考えてみれば、それは「以上の行為が本人であることを証す」ものである。 それは契約であったり、取引であったりといったことだが、このうちの「何者が」というのを担っている。 日本式の「自著+印鑑」というのはかなり無意味に思えるが、まぁ単純に多重化されている(どちらも単独では信頼できないとみなしている)と考えられる。

当たり前だが、認証時に他者を騙ることは許されないし、それが許されてしまってはそもそも認証としての機能を成していないということになる。

代理決裁が必要なのであれば、決裁権を他の者にも付与すれば良い。 Mimir Yokohamaではサポートサービスが福利厚生として利用できるようになっており、このとき決裁者を決めることができるが、 Any ofだけでなく、Orderedも可能になっている。つまり、上位から決裁可能な状態になければ次のものに決裁権を与える方式である。

他者を騙ることが許される認証というのはないのと同じである。

私としては、はんこもサインも「認証」としての機能は極めて脆弱であり、機能しないと考えている。

まず、照合されない、というのが大きい。 印影照合システムがあるのは知っているが、どれだけ導入されていて、どれだけ実際に使われているというのか。 ほとんどの場合、単に「押されている」だけで通過してしまう。

さらにいえば、最近の印鑑は基本的に機械的なフォントなので、実物に触れることさえできれば比較的簡単に模造できる。 もしかしたら陰影照合システムはそれを判別するのかもしれないが、欠けたりしても結構平気なので、それを考えると工業レベルの差は吸収されてしまうのではないだろうか。

署名はもっといい加減で、クレジットカードの署名なんて、私はペン次第でまるで形が変わってしまう。 私はクレジットカードに楷書ではなく、いわゆる「サイン」を使っているのだけど、「何語を操る人物にも模倣しにくい」という点を意識した特殊なサインを使っている。これは、通常の「サイン」に使っているものとも異なる。異なる理由はセキュリティ的な意識があることがひとつ、そしてクレジットカード裏の署名欄が横長であるのがひとつ。 だが、ペン次第で線の交差位置すら変わってしまうので、サインとしては認証できないことがかなり多いと思うのだけど、これで困ったことは一度もない。

いずれもどちらかといえば、裁判にまでなったときに「本人によるものかどうか」を焦点にして真贋が争われるものだと思うのだけど、この時点で「認証」ではできていない。「鑑定」できるに過ぎない。

そして、「本人でない者が勝手に押した印鑑に効力があるか」は法的に不明なのである。 まぁ、この声明の直後に役人が勝手に100度に渡り無断で決裁印を押したとして咎められたのは笑い話でもあったが。

共有される認証という愚

共有される認証ということでいえは「グループパスワード」というものがある。 Unixシステムにも導入されているが、これが有効になっていることはまずない。

その理由は、「共有される秘密は必ず漏洩する」ということからである。

認証の要件は「当人だけが持ちうるものである」ことなのだが、共有されている秘密というのは帰属が曖昧になるため、他に誰も知りえない状態にはなりえない。 暗号としては、「他の人に触れるチャンスのあった秘密」というのは「無効な秘密」とみなす。

グループパスワードをかけるのではなく、個別に認証される個々のアカウントに対するパスワードをグループに所属させるべきである。

この意味では、SSH鍵をマシン外に持ち出してしまうのもアウトである。 Inflatonでは異なるホストまたは異なるユーザーで鍵を使いまわしたことが発覚すると、アカウント停止を含む処置をとる場合があり、極めて厳しい処置をとることになっている。 そうする理由は、機密度の高い情報が取り扱われる非公開のサーバーへのアクセスを外部に晒すことは、他者の秘密情報にアクセスする踏み台を提供するのと同義であるためだ。

ちなみに、Mimir YokohamaでもInflatonでも、同一鍵の異なるアカウントへの使い回しも警告することにしている。

この意味ではホスト間で共有されるGnuPG鍵というのは非常に問題がある気がする。 だから私はOpenSSH鍵は場合によっては暗号化しないが(それでも少なくとも暗号化ファイルシステムもしくは暗号化ブロックデバイス上にはあるが)、GnuPG鍵は必ず暗号化するようにしている。そして、GnuPG鍵の暗号という秘密を漏洩することはない。

だから、決裁権を持つ人が複数いるのであれば複数人の有効な承認を用意すべきで、少なくとも共有されるべきではない。 共有したら、もはや認証としての価値はない。

有効性

認証要素の有効性、というのは簡単に見えて実は非常に難しい。

前述のように、印鑑や署名には認証要素として不十分である。 そもそも、複製が可能ではいけないのだ。本人しか知りえない秘密でなくてはならない。

その意味では頭の中にだけあるパスワードというのは非常に強い。が、実はこれも「本人しか知りえない秘密」かと言うと微妙だったりする。 典型的にはメモを残してしまえば終わりだし、ショルダーハッキングという方法もある。 私は外に持ち出す端末は他と共有されていないパスフレーズを使っているし、誰かの前で繰り返し使うもの(例えばクライアントが使っているサーバーのOpenSSH鍵のパスフレーズ)はその人に固有のものにしている。 実際、私は過去には「彼女によるショルダーハッキング」を食らったことがある。もちろん、そのときも十分に複雑で使い回されないパスフレーズによって防衛に成功したが。

だから実は複雑なパスフレーズを使い回すという方法はあまりよくない。 可能であれば「知りうる手段によって知りうる内容で攻略できない方法」である必要がある。 例えば、生体認証+PINまたはパスフレーズのようにだ。

この意味では、Windowsの「PINのほうが安全」という理屈はわからないではない。 使い回される可能性のあるパスフレーズを人前で打たせるよりは、PINを使ったほうが、「パスフレーズを使った覚えられてオンラインサービスに不正ログインされる」というコンボを防ぐことができる。 しかし、これに関してはそもそもパスフレーズを使い回すようなことを避けるべきで、正直PINのほうがショルダーハッキングによる攻略性は向上する。実際に私にもPINを攻略した経験はある。

私のラップトップの場合は前述のような複雑なパスフレーズ認証に加えて、LUKSによる暗号化を伴っている。 確実とは言えないが、シャットダウンしてしまえばLUKSパスフレーズを外で打つことは基本的にないので、アンロック不可能な状態にできる。 もっとも、これに関してはログインパスフレーズ変更ほどLUKSパスフレーズ変更は容易ではないので、LUKSパスフレーズの取り扱いに細心の注意を払う必要があるが。

同様に、スマートフォンの生体認証というのは脆弱な認証である。 確かに「本人しか持ちえない情報」ではあるのだが、「複製可能」であり、しかも「不正利用可能な」生体情報なので、ロングPINやパスフレーズよりもはるかに脆弱である。もちろん、4桁PINなんかよりはマシだが。

だが、これも考え方次第で、普段生体認証を使っているとパスフレーズを打つ機会が減り、ショルダーハッキングが難しくなる。 Androidスマートフォンは再起動すると生体認証が無効になるので、端末から離れるときや、端末を奪われそうなときなどは再起動すれば防衛することができる。

安全性では生体認証と秘密を用いた複要素認証を行うことが望ましいが、秘匿性、「秘密を秘密たらしめるもの」という観点からいえばそれは最善ではない。

認証を追求するコンピュータ技術

私が知る限り最も合理的で適切な認証と権限を持っているのはSSHだと思う。 もちろん、Unixシステムの認証と権限の設定が十分に堅固であることを前提としてではあるが。 あまり知られていないが、OpenSSHはPKI鍵の利用も可能である。

鍵の共有という問題はあるが、PGPも大変に強力である。 もちろん、隙なしというわけではないことは知っているが、基本的には非対称暗号というのは非常に強力なものであり、「秘密鍵が強固な対称暗号によって暗号化された非対称暗号」はほとんど本人以外は認証できないだろう。

考えられる方法としては、コンピュータと本人を奪った上で、尋問して対称暗号鍵を聞き出すことだが、そこまですれば大概の認証は無効化できるだろう。 これに加えて静脈認証のような強めの生体認証を組み合わせた多要素認証にすれば完璧なのだが、残念ながらそこまで強力な多要素認証を現実的に利用可能なシステムというものがない。

翻って現実では、「はんこを押すだけ」「サインするだけ」「物を持っていればよし」といった非常に雑な認証が行われており、実際のところ本人かどうかなどというのは全く認証できていない。 クレジットカードですら、その認証は極めて脆弱である。

これらの認証を支えているのは、運用であるが、実際のところ私は荷物をかすめ取られたり、勝手に契約されたり解約されたり…とかいろいろ大変な目にあっている。つまり、十分に運用でカバーできていない。 根本的に「本人であることを証明する」ということが社会的に非常に軽視されているのだ。

では、なぜコンピュータ上ではそこまで厳密な認証技術が発達しているのか…というと、real worldと比べて「詐称するのが簡単だから」である。 6文字英数字だの8文字英数字だのといった脆弱そのもののパスワードを採用しているところはreal world同様認証に対する意識が甘いのだと思うが、その程度のものを突破することは全く難しくなく、効力はない。

現実にはPGPは非常に強力で便利である。 PGPの話をすると大抵は暗号化の話になってしまうのだが、現実にはほとんどの場合署名として使用する。つまり、それを書いたのが本人であるということを証明するのが主な用途なわけだ。

実はその気になればPGPはメールのような限られたメディアでのみ利用できるわけでなく、例えば掲示板の書き込みなどでも利用できる。 当たり前に日常的に使いたいのだが、徳丸さんですら「今までに使ったのは1, 2度」というのが現実らしい。 ちなみに、私はメーリングリストなどでつけられる署名と、私が使うように迫った場合を除くと一度もない。 そんなものだ。

ちなみに、本気で本人認証するのであれば、マイナンバーカードには2kb長のRSA鍵が入っているため、これを使えばよいのだけれど、これは必要以上に情報を結びつけてしまうので、好ましいとは思わない。

本人認証というのは基本的にその人がある条件を満たす人と同一人物であることを認証できれば良いのであり、この定義が全て集約されなければならないわけではない。 これは、「しなければいけない」の話であって、情報がほしいかどうかは別の話だ。

例えば企業の決裁であれば、その人が決裁権を持つ人物と同一の人物であることが検証できれば良いのであり、それ以上にその人が何者であるかを知る必要は はない。

これはハンドルネームも同じ話で、「本名至上主義」は根本的に認証というものを理解していない。 ハンドルネームを「偽名」として扱うのも間違っている。ハンドルネームは「公開するための名前」であり、偽名や匿名(自身が何者であるかを隠す行為)とは同じではない。偽名ハンドルネームや匿名ハンドルネームというものが別に存在するのだ。 これは、例えば俳優の名前が芸名であってもそれが誰なのかわからなくなるわけではないのと等しい。

実際、私はもう何年もこの名前(本名)でhacker活動をしているが、別にこれが本名でなかったときに何者であるか不明だったということもない。 また、私が文筆家としてなんという名前で、声優として何という名前かということは知らない人が多いと思うが、それをつなげる必要があることは稀だろうからそれで困るということもないだろう。

本質的に認証というのはその人がある一定の条件を満たすことを証明する行為である。 その意味ではパスワード認証が通ることは認証側からすれば「本人であることを証明している」のではなく、「パスワードを知っていることを証明している」のであり、「パスワードを知っている時点で正当な利用権限を持っているとみなしている」のである。 はんこも同様に、「このはんこが押せる時点で権限を持っているとみなす」わけだが、それが適切かどうかは、また別の話である。

不安定なホスト(非固定IPアドレス, 非常時稼働)をサーバーにする

需要があるらしいので、この話。

不安定なホスト(非固定IPアドレス―浮動IPアドレス, ステートフルIPアドレス, あるいは間違っているけれど可変IPアドレス― または 非常時稼働システム)をサーバーにする、というテーマで、 方法はたくさんあるのだが、私の結論は「商業レベルでやることではない」である。

待ち受ける

DDNS

最も普通の方法だが、実際にはかなり制約が多い。

SFPレコードは効かないし、DNSレコードは反映をコントロールできない1ので逆引きが効かなかったりでサーバーとしては結構痛いことになる。

リバースフォワーディング

これはかなり簡単な方法で、例えば次のようにする。

# ssh -g -R 80:localhost:80 serverhost

これによってインターネットから安定して接続できるホストに代理ホストとして公開してもらう。

不安定なホストの非稼働時は代理ホストが応答する。

フロントエンドプロキシ

リバースフォワーディングと同様に代理ホストに公開してもらうのだが、不安定なホストに通信を転送させるのではなく、中継させるという方法。

まずなんらかの方法で代理ホストと不安定なホストを接続する。 例えばVPNで接続する。

# pppd updetach noauth silent nodeflate pty "ssh root@remote-gw /usr/sbin/pppd nodetach notty noauth" ipparam vpn 10.0.8.1:10.0.8.2

あるいはSSHによる転送を行う。

$ ssh -R 8080:localhost:80

そして、代理ホスト上でリバースプロキシを動作させる。例えばSquidやNginxをプロキシとして、ローカルネットワークホストとして、あるいはローカルホストの別ポートとして転送する。

VPNで接続している場合、代理ホストからは不安定なホストは不安定なグローバルIPアドレスではなくローカルなIPアドレス10.0.8.1として認識される。

不安定なホストの非稼働時は代理ホストが応答する。

逆接続モデル

利用可能なサーバーが限定されてしまうが、サーバーからクライアントに接続するモデルがとれるのであれば、不安定なホストであることはあまり問題にならない。 あるいはサーバーリレーするタイプ(送信専用メールサーバーなど)でも機能する。

VPNで接続する

インターネット公開しているのでないのならば、代理ホストを経由するなどしてVPNで接続し、ローカルなアドレスを代わりに使うという方法が効く。

非IP

「IPアドレスが固定でない」ことはIPアドレスを用いる場合にのみ問題として発生する。 だったらIP以外で通信すれば良い。

ただし、この場合はほとんどローカルなIPアドレスで運用する方法も適用できる(VPNで接続するなど)ことになるし、 リンクローカルな通信であることがほとんどだから、これを転送するハードルを考えるとあまり易しくはない。

例えばセキュリティの都合上でIP接続を許可していないAoEサーバー、なんていうのはアリだ。

Zeroconf

リンクローカルでIPアドレスが固定でないことを考慮しなければならないケースはあまり見当たらないが、 リンクローカルなのであればZeroconfが使える。

IPアドレス制限されたホストに接続する

レンジで許可する

ステートフルに割り振られるIPアドレスのレンジが十分に制限されているのであれば範囲で許可すれば良い。

ゲートウェイ経由

固定IPアドレスを持つホストを経由して接続する。

SSHならば割と簡単にできる。

$ ssh -L 10000:destination.example.com:10000 proxyhost

VPNで代理ホストを経由しても良い。

別の方法で接続する

例えばSSHやVPNなど特定のポートだけIPアドレス制限の対象外とした上で、これらのセキュアトンネルを通じて接続する。

MySQLサーバー等、認証が強力でないサービスのためにIPアドレス制限がなされているのであれば、SSHのように認証が強力な方法についてはIPアドレス制限から除外し、これを経由することを許す、というわけである。

許可されているホストに依頼する

ゲートウェイ接続はできないまでも融通の効くホストで接続が許可されているホストがあるのであれば、これをプロキシとして接続する。

このような場合普通はアプリケーションプロキシとして使うか、SOCKSプロキシとして使うものだ。 このプロキシに対する接続に認証を求めるべきで、異なる方法で安全性を担保させるわけである。

ちなみに、以前紹介したSSHフォワーディングの場合

  1. ローカルなポートフォワーディングにより代理ホストから不安定なホストに通信を中継するようにする。 (これ自体は公開されていない)
  2. プロキシコマンドとして外部ホストから代理ホストに対して接続を行う
  3. これによって確立された経路を使って代理ホストのlocalhost(lo)に対してSSHを通す (これがダイナミックポートフォワーディングによって不安定なホストに転送される)

という方法で、計3本のトンネルが通されることになる。


  1. 「TTLに従う」と信じているなら、ちょっとハッピーすぎる。

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

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

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

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

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

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

日本政府、全国民のウェブ閲覧の検閲を開始。 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の正木と申します。

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

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

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

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