無料素材倶楽部は、これまで何度か有害サイト（ウィルスかマルウェアかは知らん）判定されてきました。

ウィルスサイトと誤判定されていた日々-通りがかりのWeb管理者さんへ
http://sozai.7gates.net/blog/docs/virus-alerted/
またもウィルスサイトと誤判定される-Yさんへの感謝状
http://sozai.7gates.net/blog/docs/virus-alert2/

その都度誤検知であったのですが、実は今年1月にはまた誤検知（おそらく）が原因で、人生初のサーバアカウント凍結の憂き目にあってしまいました。
私の場合、リアルタイムではどうしても冷静さを欠いて誤解を招きそうな気がして、常に後日談のような形になってしまうんですが、サイトを運営する上で、こういうケースもあるよ、と参考までに。

今年2013年1月19日、サーバー上にアップロードしたプログラムの脆弱性を突かれる等により不正なファイルをアップロードされた可能性が高い、ということで、ファイルのリストと共に、サーバ会社(Xserver)からアカウント凍結および
「全削除して構築しなおしてね」という意味のメールがきました。
このサーバでは、アカウントが凍結されるとすべてのURLへの応答は403Forbiddenになります。
自サイトでどこまでも続く403を見るのってそこそこ心臓にこたえます。
「ええええええ、不正アクセス～ぅ！？」
「凍結」経験が一度もない我が身にとっては、アカウントともども、自分も凍りついた感じ。調べてみると

• PCについては定期的にウィルスチェックは行っており、感染はしていない（インストールしているソフトを信頼するとすれば）。
• その後、リストアップされたファイルをDLしセキュリティーソフトでスキャンしても何もでない。
• 検知される前のファイルと差分チェックしても特にない。
• さらに、目視でチェックしても、差し込まれたソースは見当たらない。
• DBの変更も特に見当たらない。
• ソース内に変なリンクはないし、該当URLのページをローカルサーバにおいて、ブラウザ表示しても、どこかに勝手に接続して何かを勝手にインストールする等、怪しい動作はしない。

これまでの経緯と、上記の点から、「ひょっとしてまた誤検知？」と疑念が湧きまして、その旨を書き添え、再度、詳細を訊ねるメールをサポートに送ったところ、
「会社で使っている某社外部サービスでウィルス検知したため、社内で精査したところ、同様な検知をしたため今回の凍結となった。ファイル誤検知があったか否かについては自社では特定は難しい状況なので、某社に直接聞いてくれ」
という意味の回答がすごく丁寧な言葉で送られてきました。

その回答内に、某外部サービスのウィルス検知URLと問合せ先（別々のURL)が記載してあったので見てみますと、そのサイトに以下の記載が。

DISCLAIMER
This service is provided “as is” and “free” (and may be cancelled or changed by the provider at any time), without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and non-infringement. In no event shall the provider of this service be liable for any compensation, claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with this service.

上記の英文、要は「免責条項」で、無償・無保証で提供しているサービスなので、不都合があっても責任取れんし、クレーム受け付けません。というような意味です。

これを知った時点で、頭にこなかったかというと嘘になります。
自身がそれを知っていて使用したサービスではなく、契約したサーバ会社の都合だけで使用している（当然、フリーウェア/免責条項も知っているはず）、それを顧客の私に直接問い合わせろ、と言っているわけですから。
しかも、上記の免責については、英語サイトですが、その企業サイトは別ドメインの".de"。そう、ドイツのサイトです。
英語で記述されたページに関する問合せをドイツ人に書け！と言っているわけです。

「免責条項付フリーウェアに誤検知の問合せしても無駄じゃん。逃げの一手を打ちやがったなー！！」
その点に関して、怒りがふつふつ湧いたことを覚えています。

けれども、そこに関してサポートにクレームをつけたか、というと答えは「NO」です。

理由は２つあります。

サーバ凍結→自己検証→サポート依頼メール送付→回答を待ちながら、48時間程度経過した頃でしょうか、Googleの検索結果から当サイトのURLが消え始めました（圏外に飛んだというのが多分正しい）。
このまま徒に時間を過ごすのは超まずい。とっとと全削除してクリーンに再構築し、凍結を解いた方が現実的で早いと考えたのがまず一つ。

あともう一つは、サーバ管理者は"組織の一員として"「社内規定」にのっとってマニュアルどおりに処理を行っているわけで、契約者個々の思惑より、サーバ自体の安全な運用が優先するのは当然だからです。

私は仕事であれ、個人使用であれ、レンタルサーバのサポートにメールを送ったことはほとんどありません。
ただ、送る必要がある時は、何故かほとんど週末になって、今回もやっぱり週末、だから、回答は日曜はさんで翌週と思っていました。それが土曜に丁寧に回答をしてくれまして待ち時間が短縮できた分、とても有難かったのです。
これまで、他のサーバ会社で土日回答してくれたことはありませんでしたので。

共用サーバ内で、不正アクセス、ファイル改ざん・設置とか言われて、まず自分が置いたファイル、または使用しているCMS等の脆弱性をつかれて、隣人ユーザにご迷惑をかけてしまったのか、とか、踏み台にされて大量のスパムメールを送られているのか、とか心配しましたが、そこはないと確信できたので一安心してましたし。

誤検知か否か？　という点においては、個人的には現在においても誤検知と判断しています。
けれど、検知したファイルについて全ログをいただけたことで、ソースのどの部分が、ウィルスなりマルウェアなりと検知されてきたのか、ようやく完全に分かりましたし（一行のjavascript)、ほったらかしのテスト用ごみファイルもお片づけできました。

サーバ・セキュリティ管理って基本的に「よくやった」とほめてもらえない仕事です。
ちゃんと運用してて当たり前。不具合・障害でも起こったら、ユーザにぼろかすに言われます。
メンテナンスは基本、夜中仕事、障害起きれば休み返上当たり前なのに、いつも夜中仕事ありがとうね、とかお礼言ったことのあるユーザって皆無に近いのではなかろうか、と思えてきて。

契約以来、このサーバについては、多少重くなる程度のことはあっても、障害知らずでのほほん運営できてます。
この機会に、契約期間分（5年以上分）の「ありがとう」をちゃんと言葉にしておいてもよいのではなかろうか？
というわけで、担当していただいたサポートスタッフの方に精一杯お礼を述べて終了にしました。

当時、免責条項を見た時点で、問合せを送る気は失せましたが、もし同様な目にあった場合、海外に問合せをするなら、以下のような英文で言いたいことは通じるでしょう（多分）

Dear Sirs and Madams

I'm Hoge Hoge (自分の名前）,the owner(/or a staff） of "xxxx.com（ドメイン名）.
Recently I was notified that some pages(or files) of my site were detected as malicious
by your security tool（セキュリティ・ツール名）.
Detected URLs list：
(検知されたURLの羅列）

But I don't think these urls are malicious after careful investigation by myself.
It might be a kind of misdetection.
I'd appreciate if you could reply whether or not the listed urls were misdetection.

Best Regards

XXXXXXX（名前）
******@xxx.com

意訳

xxxx.comのオーナー（運営スタッフ）をしております、HogeHogeと申します。
最近、私のサイトのページが、御社セキュリティツールで
”有害”検知されたと知らされました。
しかしながら、当方で精査しました結果、有害であるとは思えません。
誤検知かどうかお知らせいただけますと有難いです。

もちろん、免責があれば華麗にスルーされるか、または、それを盾にしてFA（ファイナルアンサー）。
免責なしだとしても、自分自身が直接のユーザでもなし、セキュリティー上、どこがどのように
まずいのか逐一教えてくれる確率は非常に低いと思います。とはいえ、
対応してくれるスタッフによっては誤検知か否か？　Yes/Noくらいは教えてくれるかもしれません。

全サイト403 Forbidden を喰らっているような状態では、相手に
ソース、キャプチャ画像等を一式送る必要があるでしょう。また、
自分が正当なサイトオーナーであるかどうか、という証明も必要かもしれません。
・・・・・思っただけで、超だるいです。

個人の趣味用に借りているサーバスペースなので、しのごの言わずに
公開ディレクトリ全削除・DBリストア・再構築がベストチョイスだと思いながら、同時に
自分はECやビジネスサイトの担当者でオーナーが他人、誤検知・アカウント凍結→
海外に問い合わせろという対応をされた場合、どう対応するのが正解なんだろうと思ってみたり。
ともあれ、二度と「凍結」経験はしたくありません。

最後に、自サイトURLが検索結果から消えていくのを発見した時、
関連検索で「無料素材倶楽部　表示できない」という検索をしている人（というか検索語）を見まして、ちょっと涙する想いでした。
こんな吹けば飛ぶよな、間に合わせ用素材サイトであっても、表示できないのは何で？　と疑問に思って探してくれた人がいたのね、と思うと、維持していく意義はあるのかもしれないなあ、としみじみ。

ネットショップやビジネスサイトの場合、お正月に”謹賀新年”とか"あけましておめでとう"などの新年のご挨拶表示をしたいものですが、いかんせん、一般的には年末年始休業中、社内で更新できません。

クリスマスなどは、クリスマス以前からセールもありますので、クリスマス前から画像だしても違和感ないですが、謹賀新年だけは年末の仕事収めで出してしまうわけには参りません。

というわけで、ネットショップやビジネスサイトの皆様のお正月には便利な簡単スクリプトを置いておきます

期間指定自動表示JavaScript

/*****************************************************/
//指定期間中に画像やメッセージを
//表示させるJavascript
/**設定項目 ******************************************/

//----開始日 YYYY/M/D 形式 半角数字で開始日指定
myStartDate="2009/1/1";
 
//　終了日 YYYY/M/D 形式 半角数字で終了日指定
myEndDate="2009/1/6"; 

//表示するHTML
myHTML="A Happy New Year";

/*説明：上記の場合、2009/1/1～2009/1/5の
期間、指定メッセージを表示します。
1900年以前、2000年問題は
必要なかろうと全然考慮していませんので、
開始日・終了日は2000年以降を指定してください。
終了日＝終了日まで表示しているのではなくて、
表示しなくなる日です。
/******************************************************************/

myDate=new Date(); //現在の日付取得
mySD=new Date(myStartDate);
myED=new Date(myEndDate);
if(myDate.getTime()-mySD.getTime()> 0 && myED.getTime()-myDate.getTime()> 0){
document.write(myHTML);
}	

使用法

１：上記ソースをテキストエディタにコピぺして、適当な名前をつけて、拡張子、.jsで保存。（例：newyear.js　等)

２：WEBページのHTML内でご挨拶を表示したい場所に、

＜script type="text/javascript" src="ファイルまでのパス/あなたのつけた名前.js"＞＜/script＞
＜＞は半角に直してください。

上記一行を差し込んで完了。これで、指定日になったら自動的に、「謹賀新年」（メッセージ、画像等）が表示されます。期間を過ぎたら自動的に表示しなくなりますので、後に時間のある時にでも消してくださればOKかと。

楽天ショップの場合

楽天の場合、scriptタグは基本的に使用できませんが、楽天Gold(無料でもらえるWEBスペース)内ではできます。ので、楽天RMSで編集するページに入れたい場合は、

１：楽天goldのスペース内に上記のｊｓファイルをアップロード。（例：newyear.js　等)

２：楽天ショップページのHTML内でご挨拶を表示したい場所に、下記のようにiframeを挿入します。

＜iframe src="楽天ゴールド内の該当jsまでのパス" width="幅" height=”高さ” scrolling="no" frameborder="0"＞＜/iframe＞
＜＞は半角に直してください。

Yahoo ショッピングの場合

2007年後半に、システムが変わってからは、scriptタグが使用できませんので、無理。

上記を年末に仕込むと、訪問ユーザー（人間）には「おお、新年早々更新しとる、やる気のあるお店」と好感持ってもらえるかもしれません。

が、検索エンジンロボット君は更新してるとはみなしませんので、「人のやらない時に頑張ることに意義がある」という、気合の入ったサイト担当者は、元旦に0時更新やってみてください。

実務的にもっとも、役に立つと思えるのは、独自ドメイン運営サイトの盆・正月・GW等の大型連休の営業案内表示消しかもしれません。休みボケした頭で、朝一の仕事が、過ぎた連休の営業案内表示削除とか、断固拒否したいじゃございませんか？

キモいゲームばかりを集めたモバイルサイト。キもゲーTownが9月12日に産声を上げた。キモゲータウンじゃなくて、まんなかはひらがなの「も」でタウンは英語のTownでキもゲーTown。やけにタイプしにくい、サイト名だ。運営は、「こえ部」などを運営するカヤック。

モバゲータウンのDeNAからは何もクレームなしなのだろうか？　とちょっと余計な心配しつつ、
キモいを切り口に、という発想が、スゴイではないかと、週末の今日、興味本位にいってみる。

キ、、きもい！！

配布のブログパーツを見れば、傾向はお分かりいただけるのではないかと。

虫をぶちぶちつぶしていく「蟲死」、顔に止まった虫をべろリンと舌で飲み込む「ザ・カメレオン男」など、説明するだけでも、気色悪いっ。でも、操作は単純明快。さらに、ケータイ「キも」小説も用意されている。

あわせて、2008年11月8日〆切りで「キもゲーFlashコンテスト」を開催中。賞金３０万円

提出規定（概略）
・キもイを切り口にした新感覚ゲーム。基本簡単な操作であそべ、キもイこと。
・提出形式：Flash Lite1.1で制作したFlashファイル本体とパブリッシュに必要なファイル
・提出画面サイズ：220×300ピクセル
・提出データサイズ：100K以内

キもゲーTownは、キモ伝導師たちによる、キモさの殿堂となるか？
　

ObjectタグでIEのリンクが親Window内で開かない

昨日の表示確認で大ポカしているワタシの続き。このサイトの右サイドバーにある、ランキングリンクで使用しているObjectタグの話。→現在はIframeに直しました。Object表示サンプルは以下

このOBJECTタグをFlashの埋め込みに利用している人も多いと思います。
OBJECTタグは、様々な形式のデータをページ内に埋め込むことができるタグで、imgタグ、iframeタグ、bgsoundタグ、embedタグ、appletタグの代わりとして汎用的使用ができる、優れもののタグ・・・・のはずなんですが・・・・

現状では、ブラウザの対応がイマイチで使えねータグと化しているわけです。特にIE。
IEでお越しでない方のためにこのサイトの該当部分をキャプチャ。

IEでの表示

Safariでの表示

Safariは、Konquererのレンダリングエンジン、KHTMLを元に開発されているので、未確認ですが、Konquererもご同様にスクロールバーがでるのではないかと。

Firefox2/3 Opera7UPでの表示

↑これが個人的にあらまほしき表示。Opera6ではスクロールバーはでませんが、フレーム枠がでます。

データの埋め込みは
<object data="データへのパス" type="ファイルタイプ" width="幅" height="高さ"></object>

こんな感じで使用するんですが、IEとSafariで、しょぼい感を増幅するスクロールバーがでてますでしょ。
最初ゲゲっと思ったんですが、でも、適度に目立つ気もする（注：参照）ので、そこは100歩譲ることに。
（注：悪目立ちするので、誰かクリックしてくれるかもしれないというさもしい思惑は見事にはずれてますので、真似しないように（笑)）

※Objectタグで外部ファイルを読み込んだ時に出るスクロールバーを消したい人はこちら

問題はここから。

IEの場合、このOBJECTタグ内で読み込んだデータ内にある普通にHTMLで書いたリンクをクリックしても、Parent（親であるこのページ）で開かず、子オブジェクト（子フレーム）内で開くのですよ。
子ページの　aタグのtarget属性 に_top,_parent　どちらを書いてもだめ。javascript等で処理したくない場合、かろうじて、_blank　で新規窓立てるしかないんです。そういうわけで、このリンク群は、ターゲット属性が_top、_blank の２種あって、IEでお越しのみなさんがリンクをクリックすると、新規窓が開いたり、子オブジェクト内で開いたり、という情けないことになります。

何でほったらかしになっとったかといいますとね、ハイ！
「忘れてた」
んです。target属性を混在させてみて、「やっぱダメねえ」とか思ったとこで、多分、仕事で急な直しかなんか、入ったんですね。
ワタシは仕事以外でIEを使用しない人で、過去、年間傘を10本以上置き忘れしたことがある程度には忘れっぽいです。（だから、大事なことは目立つとこにメモ貼りします）
ついでに、別のことに集中してる時は、他のことに全然目がいかない、よく言えば一点集中型、普通に言えば、シングルタスクのぶきっちょです。
かくして、このサイドバーのリンク処理は、もずのハヤニエ状態になった、、と。単直に「アホ」ですな。

この件は、IEのバグという意見もありますが、IE5.5、IE6、IE7すべてそうなります。
メジャーVerUPを２回繰り返してもfixされないようなものは、バグというより、もはや仕様では？　と個人的には思います。
IE8ではどうなのよ、なんですが、β版のIE８、まだダウンロードしてません。8を早く試したい好奇心限りなくゼロでして。
正式リリースになってからでいいや状態。

このページのDoctypeは、XHTML 1.0 Transitional なので、フツーにiframeを使えるのに、そうしたくなかったのね。
(※XHTML 1.0 StrictやXHTML 1.1では、iframeは廃止)。

そういうわけで、gdgd云ってる間に、とっとと直せよ、おまえ、というのが正しい対処法なんですが、この際、このままにしようかと。
ここが直ったからといって特に影響もなし、ネットでは既出感たっぷりとはいえ、ブログでネタとして使えたことが何より収穫。
IEでObject使うとこーなるのよ、というサンプルとして、このまま置いておきます。
（仕事の関係者がこのサイトを見る確率は低い。ノープロブレムじゃ）

→追記：javascriptでのこの不具合解決法を記載するとともに、問題のサイドバーはiframe化しましたので、サンプルはこのページでご覧下さい。

他にも、実はモズのハヤニエ状態なことはあるんですが。

追記：
Objectタグ使用の際に出現するスクロールバーを消すには、読み込ませる外部ページがHTMLなら、その子ページのBODYに以下のスタイルを適用すると消えます。
body{
margin:0;
padding:0;
overflow:hidden;
border:none
}

グーグルが独自ブラウザ「グーグル・クロム」を発表した。

米国時間で、2008/9/2から、世界１００カ国、４３言語を対象としたβ版も提供する。Google Crome（グーグル・クロム）はネット閲覧をより高速化するとともに、安全性や安定性も高めたブラウザとのことである。

スピードベンチマーク

5種類のJavaScriptベンチマーク

Google Cromeが制作者に与える影響

早くて使い勝手のよいブラウザの登場は一般ユーザーとしては、大歓迎である。が、一方、WEB制作者にとっては、頭痛の種がまた１つ増えるともいえまいか？　つまり、表示対策しなければならない仕様の異なるブラウザがまた１つ増えるわけだ。

制作者のみなさん、これまで、バグのないブラウザって見たことある？（バグでなくて、それが仕様と云う名であってもね）

クロスブラウザは、IEとネスケがほぼ一騎打ちのガチでシェア争いしている頃から、WEBデザイナーをはじめ、制作に携わる人の頭痛の種であり、CSSを始め多くのHackを生み出してきた。個人的にはまりにはまって、何とかやりとげた後の達成感というものも確かにあった。

20世紀末頃、JavaScriptを使用して、いかにブラウザ（Flashのバージョンも）を判別し、振り分けるか、一生懸命に情報を探しながら、自力でスクリプトを書いていたことを思い出す。何とか思い通りに動くと、嬉しかったし、１つ知識が増える喜びも感じた。

しかし、今、本音のところで、

「いいかげん、ブラウザ１つに統一しない？」

無理とは知りつつ、言ってみる。かなりの制作者が、感涙にむせぶ、と思うんだけどな。いったい、いくつ確認用のブラウザをインストールさせるつもりなんだろう？　（ブラウザにはメジャーバージョンだけじゃなくて、マイナーなコンマなんぼのアップデートがあるし、携帯サイト作る人は携帯用エミュレータだっているでしょ）

ともあれ、ダウンロードして、試してみよ。

Google Crome ダウンロード

現在は、Win Vista/XP版のみ　Linux,Mac版もリリース予定

ITMedia
「Googleの全ビジネスはブラウザから始まる」――「Chrome」開発の理由

cssのfont-family 指定で色々頭を悩ませる。確実にこれは、非WEBサイト制作者（見るだけのユーザー)、または、複数の環境下で表示確認をしない方々が気づかない苦労の一つだろうと思います。

比較的あたらしめのところでは
WinVistaのメイリオ,MacOSXのヒラギノ。
ヒラギノとＭＳ Ｐゴシックとメイリオの悩ましい関係
ヒラギノをWindowsに入れた日から、貴方の苦悩は始まるのですよ。

この辺をよむと、その苦労がよくわかるってものです。
で、現在私はどうしているかというと。

よほどのことがない限り、font-familyは指定しません。

上記、ヒラギノとＭＳ Ｐゴシックとメイリオの悩ましい関係、という記事のコメントの中にある

結論。何も指定しない。ありのまま、見る人に任せる。それが自然。だと信じて、font-familyは指定ナシで制作しております。

と同意見。

悩んで色々やってた頃もあるんです。IE、ネスケがシェア争いしてた（お互い変な独自拡張ばっかしてた）頃ですんで、いつの時代な話なんですが。
UA(UserAgent)とOSを判別して、別ファイルを読み込ませるとか。
その後、Alternate CSS　を複数用意して、文字サイズを切替させるとか。

で、結局たどりついた個人的な結論が、シンプルイズベスト、よほどのことがない限り、何も指定しない。です。どのFontで表示されるかより、「文字化け」のほうを重点的に考慮しとこ、になってます。

母数は少ないですけど、私の周囲の非制作ユーザーに聞いてみますと、ブラウザを複数切り替えたりする人は0。ほとんどがIE固定。インストールしたまんまのデフォルトで素直に使ってます。fontの種類など考えとる奴おらんのです。文字化けしない限り・・・・・。

それを、ブラウザの種類（マイナーバージョンも含め）・OSごとのバグ、または仕様に合わせて苦悩する私って何なんだろう？　（で、このバグなり仕様なりは、ブラウザがバージョンアップするたびに増えるわけです）　例えば、環境変数取得してjsで切替、だったら、javascript　offのユーザーはどうすんの？　とか、考え出すときりがない。
数は少数派としても、自前スキン、スタイル作って見ちゃうような環境の人もいるわけです。
結局、100％の対応なんて、私にゃ、無理無理。ユーザーのみなさまに全部おまかせいたします路線に。

font-family指定される、皆さんの苦労や工夫に敬意を表しつつ、
やっぱり私は、今後も、指定しない派でしょう。
フォントファミリー指定するよほどのケースは、文字化けが発生する環境を発見して、それが、font-family指定で何故か回避できる、という場合のみ（実際にあった）

「ヒラギノをWindowsに入れた日から、貴方の苦悩は始まるのですよ」
確かに。

font-familyバッチリ指定派のみなさん、特にヒラギノ筆頭指定派のみなさん。
ユーザーにおまかせすることにすると、精神的に楽よーーーーっ。
ダメかしら？