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

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


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

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


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

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

Slashdotで記事にもなっている

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

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

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

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

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

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

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

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

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

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

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

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

Vivaldi Browser

Vivaldi Browserは新しいウェブブラウザであり、現在はまだテスト段階にある。

Vivaldi Browserの生い立ちとしては、もともとOpera Software ASAのCEOだったヨン・スティーブンソン・フォン・テッツナー(テッちゃん)が、My Opera閉鎖に不満を持ち、それに代わるポータルサイトとしてVivaldiを作ったことが最初のようだ。

コミュニティは2014-03に誕生しているが、2015-01-27にOperaに代わる新たなるウェブブラウザ、Vivaldiを誕生させた。

Vivaldiの特徴は次のようなもの。

  • OperaがPrestoからBlinkへ移行する過程で失った機能を復活させる。例えばMUA
  • タブを大量に開くユーザーを対象とする
  • 高速
  • Chromiumベース
  • とてもバグかが多い(既に3件リポート済み)
  • Windows/Mac/Linuxをサポート

驚いたことに、2015-01-31の時点で既にAURにはあり、今日確認したところPCLinuxOSの64bitリポジトリにもあった。Tchnical Previewと言いながら、スクリプト名はvivaldi-stableである。

使ってみて思ったのだが、非常にバグが多く未完成な印象を受ける一方、本当に速い。Opera Developerよりも明らかに速い。ただし、Blinkブラウザ共通の症状として、私のLinuxデスクトップで使っていると高負荷となりプチフリーズを生じやすくなり、非常にストレスあるブラウジングになる。

このバグレポートのためにここ数日英語漬けになっている気がする。

しかし、昔はウェブブラウザとは随分とわくわくしたものだが、久しぶりに未来を夢想してしまうようなソフトウェアが登場した。

某コンテストの投票方式の問題点

先日まで某サイトでwebコンテストが実施されていた。だが、これにかなりの技術的問題点があったので、言及しておく。

会員に対する投票と、一般の投票は、票の重さが違う、という仕様で、一般投票は1日に1票、ということだった。しかし、この重複票排除というのは、現実にはまず不可能である、とされている。

重複票排除については1995年頃から議論されていた。1人1票、と設定しても、どうやってその人が既に投票したかを確認するか?ということだ。方法としては、IP, IP+UA, Cookie, 登録制が一般的だった。

IPはゲートウェイホストによって個々のインターネットホストに与えられるため、同一IPの投票を重複とみなす、という方式だ。だが、この方式は、インターネットカフェやケータイ(これは2000年以降)で問題が生じることと、NATを用いるために同一世帯の家族を「重複票とみなしてしまう」という問題があった。一方、PPPならば「電話をかけ直す」ことでIPアドレスは振られ直すことが多く、この重複を排除できない。

IP+UAは、IPとUAの両方が一致する場合重複とみなす、というもので、会社、ネットカフェなど共有回線がまるごと重複とみなされる問題を回避しようとした。しかし、UAは当時は特にバリエーションがそれほど多くなかった上に、詐称することも可能だったため、会社などそれなりの規模になるとかなりの確率で、環境を揃えているネカフェではほぼ確実に重複とみなされ、一方重複投票したい人は容易に回避できた。

Cookie方式はブラウザに「投票した」という情報をもたせることで管理しようというものだ。比較的単純で効果があったが、手元に複数の、Cookieを共有しないブラウザがあれば回避されてしまうし、単にCookieを削除するだけでいくらでも投票できてしまう。

登録制は、重複登録をいかにして防ぐかが問題となる。また、登録制にすることでハードルが上がり、投票数は劇的に低下する。重複票を防ぐ効果は低く、それでいてむしろ避けられることになるため、よほど自信のある(中身にというよりも、popularityにおいて)プロバイダでなければ採用は逆効果だった。

これらの問題の難しさを諦めて、逆手にとったのがAKB方式といえる。つまり、重複投票はしても構わないが、その票数は買わなければならない口数方式だ。

例えば住基カードを使えば1人1票は実現可能だが、厳密性を求めるならなりすましの対策という非常に困難な問題にぶつかることになる。それに、選挙でもなければ同定に住基カードなど使えない。

携帯電話に限る、という方式はお手軽であり、普及している。電話番号を使うことで同定できるためだ。だが、そのような理由でコンテンツを携帯電話に限ることは、アクセシビリティの観点から言っても好ましくないし、やはりアクセスはかなり減少する。それに、そのような目的で電話番号を取得するのはいかがなものか?ということもある。

このほか、TwitterやFacebook, Google+のようなopenIDを使って認証する、という方式もある。電話番号よりはいくらかソフトなやり方だが、その分効果は低下する。

このように非常に難しい重複投票の制限だが、そのコンテストでは、単純にCookieを使う方式だった。CSRF対策か、セッションクッキーを使うようになっていたが、その場合、単純にブラウザのプライベートウィンドウを開いてアクセスし、投票して閉じれば無限投票が可能だ。

もっとあげつないやり方としては、curlなどでセッションクッキーを保存するようにして投票ページを取得したあと、投票するという2回のコネクションを張るだけで投票できる。この間0.1-3.0sec程度なので(私の環境で)、ループすれば1時間で1500票は入れられる。

これはさすがに中止になるか無効になるかするように思う。

もう少し考えて作ってもよかったのではないだろうか。

HTML * CSS 美しいフレームをもつカラムスタイルレイアウトの難しさ

私のサイトをみるとわかるのだが、ボーダーが画像になっている。これをどうやって作るのか、というとごくごく単純で、背景画像を持つdiv要素に入れ子で白背景のdiv要素をおいているだけだ。ちなみに、外側のdiv要素にpaddingを設定するのが正しいやり方だ。

ところが、これで左右カラムを置き、しかもその中にブロック要素をおこうとするとかなり難しい。floatを使って配置すると、内側のブロック要素は親要素のブロックを突き抜けてくっついてしまうのだ。普通なら左右カラムはくっついて配置されて構わないものだから、このような挙動は気にしないのだが、今回の場合、左右カラムの間に空間を作ってボーダーを表示したいため、工夫がいる。

とりあえず、まずは縦に並ぶブロックを分けろ、だ。左右カラムはブロックの中に入れて左右分割すべきだ。でないととても苦労する。

さて、問題の比較的単純な解決策はfloatを使い、左右それぞれにfloatし、かつ重ならないようにwidthを設定する方法だ。だが、私はfloatを使う方法があまり好きでない。なんらかの理由で重なってしまうと後に書いたブロックは後ろにいってしまうという、表示への影響が大きいからだ。

そのため、私がとった方法は

  1. static配置では中のブロックに対してabsoluteが使えないので外のコンテナはrelativeで配置
  2. 右に配置されるサイドバーコンテナを先に書く
  3. サイドバーコンテナはabosluteで配置。widthz-indexを設定
  4. メイン部分コンテナはrelativeで配置。同様にwidthz-indexを設定
  5. サイドバーコンテナ、メイン部分コンテナ共に内側に入れ子のコンテナを配置(白背景)
  6. 外のコンテナのwidthpaddingでボーダーを適切にする。つまりギリギリにしないほうが良い
  7. サイドバーコンテナにmax-height、メイン部分コンテナにmin-heightを設定。サイドバーコンテナはoverflow: auto

簡単な話なのに複雑、と感じただろうか。実はそう簡単ではない。確実に正確な位置に配置しようとすると、floatしないならabsoluteで置くしかない。ところが、そうしようとするとstaticのまま親コンテナが配置されていてはいけない。

サイドバーコンテナを先にするのも理由はあるが、別に好みだとは言える。

widthの設定はもちろんかさならないように、またボーダーのサイズを調整するためで、z-indexは万一重なった時のためだ。

入れ子にするのは白背景とボーダー調整のためだが、この方法ではなくてもできる。

さて、なぜ両方absoluteにしないかというと、そうするとこのブロックは高さ0であるとみなされ、下側のボーダーが出ない(下にフッターを配置した場合、それも出ない)。そのため無限に長くなるメインのほうをrelativeにしているのだが、そうすると本文よりもサイドバーが長くなるときに支障が出る。そこで、サイドバーの最大長を制限すると共に、本文の最低長を要求することで、サイドバーのほうが長くならないようにしている。

別に「すごく難しい」という話ではないのだが、これはなかなか出てこない話だ。というのは、かなり技術的なことをしているが、それは構造的、意味的なものではなく、完全にデザインのための記述だ。デザインのための技法というのは技術者にはなかなか身につかない。そして、デザイナーがデザインを実現するための技術もそうそう思いつかない。ボーダーに画像を使いたいと言われた時、エンジニアがそのような機能はないのでできない、と言ってしまう可能性もある。今回やっていることはどちらかというとデザイナー主体のことで、デザイナーがそれを実現するための技術的知識があるか?というところが問われる。

このようなデザインは非常に個人サイト的で、商業サイトではトレンドもあるためこのようなデザインを採用することはない。というよりも今は非常にDHTML流行りなので、そもそもアクセシビリティ自体がナンセンスのように言われることも少なくないし、こうした指向がないために見かけないのかもしれないが、アクセシビリティとデザインを両立し、独自性があり、かつ習慣に基づくなじみやすさを満たす、というこうした技法は、そうしたサイトをみないだけに抜け落ちるポイントになっているのではないか?と思う。

今回は他の方法もあるにはあるのだが、これが最もアクセシビリティが高い方法だと思う。個人的には、最新のウェブブラウザでなければ見られないようなサイトは好きでない。

なお、現状公開しているサイトはこの仕様になっていない。現在テンプレートを修正したところだからだ。恐らく、本体ウェブサイトではなく、商業ページのほうが先にこのレイアウトを採用するだろう。現在の本体ウェブサイトは類似のデザインを採用しているが、バグがある。


/* Skin CSS for general essay.
* This is used by essays independent from the site.
*/

/* Top definition */
body {
background: #fff url("//reasonset.net/img/wp/heartline.gif") repeat-y 15% 0% scroll;
font-size: 10pt;
color: #39f;

}


/* Main Container. Over all container. */
#MainContainer {
width : 950;
margin : 0 auto;
background: #e0f0ff url("//reasonset.net/img/wp/check_bp.png") repeat scroll;
font-family: "Rounded-X M+ 2c","Migu 1C","M+IPA+2VM circle","Gen Jyuu Gothic Normal","VL P Gothic", "Hiragino Maru Gothic", "Meiryo",sans-serif; /* define Japanese Font */
position: relative;
padding: 45px;
}

/* For overwrite font-family for English document. */
#MainContainer {

font-family: serif;

}

/* Top banner */
#TopBan {
margin : 0px 0px 18px 0px;
font-size: 300%;
padding: 1.3em;
position: relative;
}

#UnderContainer {
position: relative;
}

/* Main content container */
#LeftPage {
position: relative;
top: 0px;
left: 0px;
z-index: 1000;
/*   margin: 30px; */
padding: 0;
background-color: transparent;
/*   border: blue 1px solid; */
width: 650px;
}

#SideBar {
padding: 0;
/*   border: blue 1px solid; */
position: absolute;
right: 0px;
top: 0px;
width: 250px;
z-index: 200;
}

/* Any container. */
.container {
background-color: #fff;
padding : 4em;
/*   border: red 1px solid; */
margin: 0;

}

/* paragraph */
p:first-letter {
text-indent: 1em;
}

p {
line-height: 1.2;
letter-spacing: 0.25em;
}

/* headline to left */
h1,h2,h3,h4,h5,h6 { text-indent: -1.3em; }



<html>
<head>
<link rel="stylesheet" type="text/css" href="./puredoc.css" />
<link rel="stylesheet" type="text/css" href="./puredoc_skin.css" />
<link rel="stylesheet" type="text/css" href="./gen-essay-skin.css" />

</head>
<body>
<div id="MainContainer">

<div id="TopBan" class="container">
Site title.
</div>
<div id="UnderContainer">

<div id="SideBar">
<div class="container">Sometext</div>
</div>
<div id="LeftPage">
<div class="container">
<h1>H1 title</h1>
<h2>h2 title</h2>
<p> p1</p>
<p>p2</p>
</div>

</div>
</div>
</div>



</body>
</html>

DeleGateでHTTPSリバースプロキシ

私のサイトはずっとhttpsで接続できなかったのだけれど、ようやく手を入れることにした。

HTTPSによる接続自体はできるのでサーバーは動いているし、ファイアウォールも阻害していない。証明書関連の問題だと判断できる。

DeleGate + SSLについての情報は大概が古く、SSLwayについてしか言及されていない。DeleGateの最新マニュアルを見ると、STLSというビルトインTLSフィルタを持ち、またビルトイン匿名証明書を持つため証明書も不要であるように思える。ではどう使うのか??

jfuruyaのブログに答があった。DelegateのパラメータとしてSTLS=”fcl,fsv:https”を渡す必要があるのだ。しかしこれだとHTTPでアクセスするとはじかれる。ちなみに、SERVER=httpではhttpsで接続しろと言われる。マニュアルを確認、どうもSTLS=”-fcl,-fsv:https”であるべきであるということが分かった。

しかしそのままでいくとスタイルシートが表示されない。どうやら、httpsでページを表示しているのにhttpでスタイルシートをロードしているのが問題らしい。つまり、リンクはhref=”http://…”ではなく、一般には説明されない書式でスキームを維持するhref=”//…”形式にしなくてはいけないようだ。

とりあえずこのような特殊な接続をする人はいないと思うので、全体は修正していないが、ビルド時にテンプレートを変更するので、サイト全体をビルドする時には直る、はずである。

Microsoft迷走中?

windows 10が発表された。Windows 8から9をとばして10にしたらしい。

おもなトピックスは、スタートメニューの復活、タイルをスタートメニューに統合、UIの統一をやめた、恐ろしく原始的だったコマンドプロンプトを多少改善した、というあたりだ。

だが、このちぐはぐ感がすごい。まず、タイルを使うタブレットスタイルがこれからの標準であり、これからはタッチデバイスの時代だとしてWindows8は従来型のUIを切り捨て、今後フェードアウトさせていくことを示した。今回はタイルやWindows StoreといったWindows 8で導入されたフィーチャーの主従関係が逆転しており、Windows 8で打ち出した価値観の誤りを認識し、軌道修正した形だろう。

Windows 8の使いにくさは尋常でないのでそれは正しいと歓迎するとする。しかし、タイルというのは、全面に機能を大きく表示するからタッチ端末にとって有意なのであり、スタートメニューの中に組み込んでも表示にスタートメニューをおさねばならないのではありがたみが全くない。ウィジットの代わりをさせようという部分もあったはずだが、内容をみるにはスタートメニューを開いたまま操作できないのではやはり意味がない。Windows 8の失敗をばっさり切るのではなく、中途半端にそれっぽく残した結果、ものすごくちぐはぐなものができあがっている。

そもそもタイルはシングルウィンドウを前提とした構造であり、全画面表示を標準とするなどシングルウィンドウ設計を推し進めてきたWindowsだが、マルチウィンドウ型の能率的インターフェイス(シングルウィンドウはいわば簡便型といえる)に戻すのであれば、わざわざスタートメニューを開いてまでタイルを欲するということはない、ということになぜ気がつかないのだろう?

また、WPSに続いてコマンドプロンプトの強化でパワーユーザーに応える、ということなのかもしれない。けれど、それが尋常じゃなく貧弱なものを非常識な程度に貧弱にしたというもので、あまりにも謎の改修だ。見捨てているのでなければいちから作り直して然るべきしろものなのにだ。

どこからどう見ても「これは使いにくそうだ!」としか思わないWindows 10。Windows Vistaあたりから「UIがちょっと不自由すぎないか」という感じになっていたが(内部的にはWindows XPはひどかったので、もちろんその意味では歓迎すべきところなのだが)、Windows 8から「見方によってはよくなった」要素を見出せなくなっている。パソコン離れはどう考えてもWindowsが使いにくい、という理由がかなりの部分を占めるように思えてならない。実際、AndroidもそのUIは相当に使いにくいと思うが、Windowsと比べたらだいぶマシだ。

また、「モバイルファースト、クラウドファースト」というスローガンをみると、Windows 8で示したタッチデバイス重視の設計を推し進めたかのように見える。だが、実際はそこに特化した設計には見えない、というよりもむしろ「どのデバイスでも扱いにくいようにした」ようにしか見えない。UIの統一をやめたのだから、モバイルデバイスならば従来のタイルUIを使う、ということだろうか?もしそうだとしたら、「Windows 8が不評だったからとりあえず前っぽくしとくね」という極めて雑なやり方に見える。そもそも、モバイルやクラウドが万能でないこと、わざわざPCを使うユーザーはもっとパワフルな環境を求めていることが理解できないあたりが、Microsoftは一体何をみているのだろう?と思う。

これであればLinuxデスクトップの使いやすさ、なじみやすさ、能率は圧倒的なものがあると思うのだが、やはり一般の人が触れることがあまりにないこと、導入部分の困難さ、情報の雑さや風潮などが邪魔をするのだろう。機能的なLinuxの圧倒的優位が反映されないのはなんとももどかしい。というよりも、Microsoftに、独占的地位における責任(パワーユーザーやデスクトップユーザーを切り捨てて強制的にコモディティ化を進めることの誤り)を理解させるためにも、LinuxがWindowsを明確に侵食する状況は起こるべきであると思う。

Microsoftはまた、Internet Explorerを改名する計画であるという。そもそもInternet Explorerが不人気なのは、標準に準拠しておらず開発側に余計な負担ばかりを強いて低機能であることや、ユーザーからみてもそのことがもたらすレンダリングの不備、機能の不完全性なのであり、私のもとにこのブログが以前のテーマではIEで見られないという意見が寄せられた。その実態のダメさを覆い隠すために「改名してごまかそう」というのは、Microsoftは一体何を見ているのかと思う。もはやまっとうな製品を作る力がないのだろうか?

Linuxで最新のFlash player pluginを使う

LinuxのFlash PlayerはAdobeがサポートを終了し、11.2が最終バージョンになっている。もうだいぶ古くなって、最近は様々なサイトで動画が見られないなどの不具合がでている。いや、動画のようなコンテンツだけならいい。保険サイトのようなところが見られない、という事態すらある。

Flash PlayerはGoogleのメンテナンスに移行し、案の定、Googleが抱え込んでChromeに同梱している。そう、Flash Player単体のリリースはしていないのだ。当然ながら、Chromiumや、その派生であるSRWare ironにはFLash Player pluginが含まれていない。

MozillaはChromeが利用するPepperプラグインには「興味がない」と言っているため、このままいくとFirefoxでFlash Playerは利用できなくなる。既に11.2までしか利用できずに様々なサイトが見られなくなってきている。だが、chromiumやironはPepperプラグインが利用できるため、術はある。

どうしてもGoogle Chromeが受け入れられなかったため、Chrome x84_64 rpmをダウンロードし、それをarkでPepperFlashのみ展開。あとは

iron --ppapi-flash-path=/opt/google/chrome/PepperFlash/libpepflashplayer.so --ppapi-flash-version=15.0.0.152

のようにすればよい。バージョンはmanifest.jsonファイルを参照する。

のだが、これでうまくいかずに随分悩んでしまった。理由は、自分で書いたiron起動用スクリプトが引数を渡すようになっていなかった、という実にくだらない理由。スクリプトを書き換え、デフォルトでプラグインをロードするようにするとともに引数を渡すようにした。