  |
はてなキーワード: ホスティングとは
事の始まりは6/11、消印もなければ料金後納でもない封書が自宅マンションのポストに入っていた。
曰く、「貴殿はヘイトスピーチサイトを即座に停止し最寄りの警察署に出頭せよ」とのこと。
一目見て変だなと思うと同時に、厄介なことに巻き込まれていることを自覚した。
心当たりはある。
私は、自分で言うのも説得力がないが、至って清貧なWeb屋だった。
全ては独学で、どこの会社に勤めるでもなく、デザイナー・コーダー・プログラマ・エンジニアと出世魚のごとくキャリアを積んできた。
無料ブログサービスで使用するブログパーツやテンプレートの制作。手打ちされたHTMLが無数に存在するサイトのCMS移行。フルスクラッチで何万行というコードで書かれた複雑怪奇な商品比較サイト。ブラウザベースで動作する業務システム他諸々。
フルスタックという名の器用貧乏で、Webに関連することなら一通りのことはやったと思う。
ペアプログラミングのペの字も知らず一人で突き進み、次第に大量のサイト群をメンテしきれなくなり、新規開発との並行によるデスマーチが日常となった。
下手な自営業の典型だったことも災いし、往々にして工数と賃金は釣り合わず（相見積もりからの値切りは日常茶飯事だった）、プライベートを犠牲にしてまで働く虚しさに日々磨り減っていった。
やがて完全に心を病み、後遺症は残らなかったが脳の病気（おそらくは過労が原因だろう）で倒れたことを機に一線から引退した。
鬱の治療をしつつ、近頃はコンサル的な業務か、リアルで付き合いのあるごく一部のクライアントからの受注に絞った。
数年前、インフラエンジニアの知人経由でサーバ関係の相談を受けたことがあった。
その際、「一日〇〇万PV級の某有名CMSで動くサイトの負荷対策」として諸々をレクチャーした。無論、例のサイトとは知らずだ。
依頼についての請求書を出した時、こちらの住所を記載していた。（向こうは個人名ではなく見知らぬ会社名だった）
継続して相談を受けるうち、サーバ上で運用されているサイト名を知って手を引いた。
個人情報が漏れたのであればそこからしか考えられず、しかし何故今なのか不思議だった。
例のサイトについて調べるうち、#ネトウヨサイト裸祭りを知った。
最初に投函されたその『警告』にも、アフィ広告剥がしの運動が行われていることは記載されていた。
さすがに張本人からの物とは思えないが、共感を覚えた誰かしらのうち私の住所を知っている者が（あるいは請求書で住所を知った管理人やインフラエンジニアの知人など、私に極めて近い何者かが）リークしたのだろうと思った。
しかし相手が何者かも分からなければ、私にはサーバ＝サイトを停止する権限もなく、仮に出頭したところで頭の病気を疑われるだろう。
そのため、内心怯えつつも無視し続けるしかなかった。（後ろめたいところはないが）個人的に警察沙汰は嫌だという気持ちもあり、被害届も出さなかった。
そのうち例のサイトの広告が全滅したというBuzzFeedのニュースを目にして、ようやく安心した。
「ああこれで顔も知らない手紙の相手も溜飲を下げることが出来ただろう」「皆も例のサイトへの関心が薄れるだろう」
「ほぼ無関係な私も標的からは外れるだろう」、そんなふうに楽観していた。
そして昨朝になって、前回と同じような差出人不明の封書が届いた。
曰く、「サーバ管理人である貴殿らを近々メディア（文春やハフポ、BuzzFeed等）に告発する。個人情報を匿名掲示板及びWiki上で公開する。
サイト管理人〇〇〇（調べれば出てくるが一応個人名なので伏せる）共々罪を償わせる手筈は整った。これは最後通牒である」とのこと。
嫌な予感が当たった。
例のサイトがさくらインターネットとバリュードメインの利用規約に違反しているという記事をつい先日読んでいた。
はてブでもそれなりに話題になっていたので、他人事ではなくなっていた私は正直戦々恐々としていた。
ただし、「さくらインターネットや（バリュードメイン親会社の）GMOが今回の件で一方的な契約解除などの対処を果たして行うだろうか？」という感覚でいた。
広告の件はまだしも、ホスティングサーバを提供するさくら社が動いたとしても、ドメインもといレジストラであるGMOが「（主に第三者による）クレーム」で動くというのは少し考えづらかった。
例のサイトが最高裁に上告したことも知っていたため、仮に契約が停止されるとしてもその段階ではないかという気がしていた。
一方で、私に手紙を送ってきた者は「最初からサイトの停止を目的としていたのではないか？」と思えてきた。
漫画村問題以降、悪質サイトは広告剥がしによる兵糧攻めが効果的という話が周知の事実となっていたこともあり、広告剥がしの運動はその延長にある気がしていた。
けれど、根本的にサイトを潰したいのであれば、捨て身覚悟でサイトそのものか当事者へ攻撃を行うのが最も有効だろう。
ちょうど今朝だったか、グリーンピースがフランスの原発にドローンをぶつけたというニュースを読んで、なんとなく悟った。
これは「保守速報のサーバ管理人」である（と誤解されてしまった）私へのテロルである、と。
もしかしたら、「本当のサーバ管理人」も同じような手紙を受け取っているかもしれない。
なぜなら手紙には「貴殿ら」と複数形で書かれていたためだ。それに関してはお気の毒だなと感じる一方で、ざまあないねという気分だ。
あくまで私見を述べると、現在裁判所で係争中のヘイトスピーチに係る問題について、私は例のサイトの管理人の肩を持つつもりは一切ないし、法のもとで公平に裁かれることを期待している。
ただ、この一ヶ月弱、ある種の当事者として騒動を見守っていて、やはり「行き過ぎではないか」と感じた。
ネット上で起きた問題であっても、司法のもとで裁かれるべきであって、私刑によって晴らされるべきではないという気持ちがある。
さくらインターネットやGMOへの申告は「被害を受けた当事者たち」が行えばよいのであって、それを承知の上で「押すなよ、絶対押すなよ」と言わんばかりの記事を拡散して「第三者であり不特定多数の善意」を期待するやり方は正直に言って寒気がした。
例のサイトの肩を持つつもりはないと言いつつも、実害を受けている立場上どうしても公平性を欠く見方をしている自覚はある。
元々オタクであり、事ある毎に表現規制絡みのセンシティブな話題を目にしてきたことで、常日頃から肩身の狭さを感じる身ゆえに中立とは呼べない「寛容さ」を持ってしまった可能性もあるだろう。
それでも、第三者を巻き込んだ運動や行動（手紙の件は私には脅迫としか思えなかったが）によって社会が良くなるのならば、という思想は反面で危険をはらんでいるように感じる。
他人から何かを剥奪する時、それがたとえ社会的に真っ当な仕打ちと思える処分でも、本来その権限を持たぬ者たちによって軽重が左右されることには本能的な恐怖がある。
なんの利害関係もない、「純粋な義憤による裁き」は、その正当性が担保されなくなった瞬間に理不尽ないじめの構図と変わらなくなる。
ならば「誤っていたと認めなければよい」という方向に流れて、一度始めると引っ込みが付かなくなり、時に際限なく激化する辺りもよく似ている。
「いじめられる方にも責任がある」という言い分も心情としては理解できる。かと言って、少なくとも私が受けたそれらは、あくまで私自身の範疇で「当然の報い」として飲み込める程度のものではなかった。
第一、私を告発しても（例のサイトへの攻撃としては）まったく意味がないのだから尚更だ。多少の犠牲もやむを得ないということならもう知らないが。
私が今後どのような処遇を受けるか考えたくもないが、社会的な死に陥る可能性は五分五分だろうと思う。
「少しでも関わった時点で同罪」「被害者面すんな氏ね」「増田の住所を特定して晒し上げにしろ」とブクマで罵詈雑言を浴びる可能性を覚悟した上で、それでも今回は書くことにした。
なぜなら、私は手紙に対して直接返事を書くことが出来ないからだ。
せめて差出人がこのエントリを読んで、もしも人違いであると気付いたのならば、文字通り命乞いで情けないが思い留まってほしい。
断っておくが、お先が真っ暗だからと言って、私は低能先生のように自棄になって破滅的な行動を起こす気力がない。
それ以前に、今回のことがなくとも、もうボロボロに病んでいる。義憤に駆られたり誰かに恨みを持つのはそれだけで体力を使う。そういう持ち合わせはもうない。
だから、ある日朝起きて、ネットの海に漂う自分の住所を目にした時には、全てを諦めようと思う。
それは明日かもしれないし、幸運にも一生やって来ないのかもしれない。
何事もなかったところで、怯えて日々を暮らすうち、悲観に飲まれて気の迷いを起こすのも人間だと知っている。
たとえ私がいなくなったところで、この国ではよくある、珍しくもなんともない瑣末事として処理されるだろう。
これが遺書にならず、怪文書やポエムの類いとして笑い話になれば幸いだが、念には念をというやつだ。最後はこの言葉で〆ようと思う。
グッド・バイ。
fladdictさんのtweeetが気になったので試してみた。
https://twitter.com/fladdict/status/1002911130715451393
ETH送る詐欺とはこういうやつだ
http://virtualmoney.jp/I0003205
ちなみにデータベース化もされている。
https://etherscamdb.info/scams/
リプするtwitterアカウントは多くあるがとび先URLは同じ。
ほかの人、たとえば大石さん（@bigstonebtc）のところに貼られたものと同じだった。
ほかの外国の人についてるリプはまた別だったりする。ただ、とび先のURLも複数あるがデザインはほぼ同じだった。
■海外の方
http://ethereumdrop[.]info
https://ethpromo[.]io/
ホスティング会社：→https://ifastnet.com/
■国内の方
https://promotoeth[.]org
→CloudFlareで隠ぺい
→ごにょごにょすると実サーバが出てきた→https://www.digitalocean.com/ IPアドレスは159.65.95.146
基本的に何ら通信をしていないのに新着の入出金が表示されるUI
ドメインによってホスティング会社もCDNの利用もバラバラなので、たぶんテンプレをコピペして悪いことしている奴が複数いる可能性も。
Google Analyticsとdoubleclickが埋め込まれているケースもある
→リタゲしてこういうのに引っかかりやすい人にターゲティング広告うつってことか！
■というわけで、これら見つかった会社にabuse報告を行う
https://www.cloudflare.com/abuse/
abuse@digitalocean.com
abuse@ifastnet.com
基本的にはURLと迷惑行為の種類（今回はフィッシングでよい）を書けばOK。
同人作家の方々なら珍しくない話なんだろうけど、自分としては初めての経験だったので、メモも兼ねて残しておきます。
一年前から同人活動を始めて、エロ同人誌を描いてた。つい先日、3冊目を出したばかり。
続き物のフルカラー漫画で、1巻は500部、2巻は400部。そして3巻が発売1週間で150部出たところだった。
DMMやDlsiteで委託販売している。二次創作だけど、版権元のガイドラインには従っているのでそのあたりは大丈夫なはず。
1,2巻の時も、無断転載が無いかアンテナを張ってたんだけど一向に転載がなくて肩透かしを食らってた。
しかし3巻の発売1週間でついに海外のサイト2箇所で発見する。
一瞬頭が真っ白になって、その後ふつふつと怒りが湧いてくる。ついに来たか、と。
丁寧に転載元まで記載されていて、元凶はとある日本の同人誌転載サイトだった。即、DMMおよびDlsiteの通報窓口から3つのサイトを通報。
翌日、海外2つのサイトから消えたのを確認した。思ったより早かったのと、本当に消えるのだとわかって安心した。
そうこうしているうちに、さらに5つのサイトに転載される。5つまとめて通報した上、元凶のサイトにはさらにホスティング会社と管理人にも直接メールで削除要請をかけた。
通報から3日目、ついに元凶と思われるサイトから消えた。ご丁寧にサイト運営者からもメールがあった。削除が完了しましたというような素っ気ないメールだったけど。怒りをぶつけたい気持ちをぐっと抑え、確かに画面の向こうに人が居る手応えを感じる。
最初の転載から5日後の今日、これまで23箇所のサイトを通報した。
モグラ叩きとはこのことで、あっちを叩けばそっちで、こっちでと無限に増えていく感じがする。というかここまで転載サイトが沢山あるとは知らなかった。
幸いにも、半数以上のサイトからは消えている。大手と思われるサイトから消えてからは、転載のスピードが鈍化したような気もする。
しかしtorrentらしきリンクも発見した。これはさすがに止められなさそうだ……。
販売数100件突破おめでとー！と喜んでいるところに、各転載サイトのDL数が3000件とかなっているのを見ると、心臓がギュッとなる感覚がする。雑な推計だが、少なくとも2万冊は違法ダウンロードされたはずだ。
今回転載されたのは3巻だけなので、ひょっとするとこれで1,2巻の販売が伸びるんじゃないかと期待したりもした。しかし特に数値が上向きに変化することもなく。
むしろ3巻は転載後に売上が鈍化し、1日の販売数がほぼゼロにまで落ち込んだ。
これに関しては作品そのものの評価もあるかもしれないが、少なくとも転載がプラスには働かない事はわかった。
ちょうど漫画を転載する某村が話題になっていた時なので、タイムリーに感じた。漫画家の無念さを僅かながらにも体感できた。
1度転載されるともう止まらないし、1度タダで手に入ると思ったものには、人はわざわざ金を払おうとは思わない。同人屋の端くれが偉そうなことは言えないけど、無断転載サイト許すまじ！という気持ちが強まる。
最近はむしろ通報を楽しんでる節すらある。無断転載しているところを見つけると、汚物は消毒だー！とばかりに通報をかける。すると翌日あたりには消えているのだ。これ、案外楽しいかもしれない。
海外のアップローダ系はかなり削除が早い。日本の同人誌転載サイトも時間はかかるが全て消してくれた。海外のhentaiサイトは無反応な所も多い。
CloudFlareのサイトにAbuse通報フォームあるしね。https://www.cloudflare.com/abuse/
さっき踏んだ範囲だと「imgon.spimg.ch」なるサイトに画像コンテンツが載ってるっぽかった。
IPひろば先生曰く、これもCloudFlareにホスティングされているから権利者なら通報できないこともないとは思うんだが、出版社はちゃんと把握できているんだろうか。
漫画村はCloudflare のCDN を使っているので、残念ながら漫画村にアクセスしてもら漫画村の実体であるサーバーIPアドレスを調べられない。
なので、まずはCloudflare にDMCA abuse report を送ってCloudflare CDN を剥がすことが第一である。
https://www.cloudflare.com/abuse/
善良な一市民としての通報を、Cloudflare は受け付けていない。著作権者自身かその代理人でなければ、対処してくれない。
漫画村にご自身の作品を不当に掲載されている漫画家の皆さん。一人一人が立ち上がってください。Cloudflare に申し立てを行なってください。異議申し立てによりCloudflare が漫画村の著作権違反を確認し、Cloudflare CDN が外された次が勝負です。
Cloudflare CDN が外れた後は、ホスティング会社へのabuse report、ネットワーク管理者へのabuse report していきます。
一つの手続きは地道ですが、一歩一歩確実に犯罪者を追い込んでいけます。
漫画家の皆さん、まずはCloudflare に異議申し立てを行ってください。
昔読んだ美味しんぼに、駆けずり回って手間隙をかけたものだから漢字でご馳走と書くとあった。でも飯と味噌汁と目刺しがごちそうってのはあんまりだ。
鯛の尾頭付きやローストビーフがごちそうとされていたということは、動物性たんぱく質を丸ごと塊ごと提供することが世界的に見てごちそうだったのだろうか。手に入りにくいものをホスティングすることがごちそうだったのだろうか。でも今はスーパーで十分まかなえる。
ハレとケがくっきりとしていたころは、日ごろ食べられないものがごちそうだった。でも今はファミレスでスーパーでコンビニで手軽に楽しめる時代だ。毎日が王公貴族の生活だ。でも「ごちそうばっかり食べている」とはみな思ってはいないだろう。便利さとともに私たちは旧来のごちそう感覚を失ったのだ。誰が見てもごちそうと思えるものはもうないのだ。
ブログだとライブドアにFC2にアメーバにはてなに、と有名どこで安定してるのがいろいろある。
無料でも十分に使えて、急にサービスやめますとか言われる心配もほとんどない。
最近、ブログだと流れていくから日記みたいのじゃなくて情報まとめるようなページはホームページ形式にしたいと思ってる。
ただ、ホームページ公開する無料サービスってブログほど安定してるのがぱっと出てこない。
求めてる条件はこのあたり
質を求めるとレンタルサーバとかになってきて、お金がけっこうかかる。
ブログでアフィもやってるが、アフィのためのブログじゃなくて隙間の寂しさを埋める程度においてるから年間5000円も稼ぎない。
広告がコンテンツの邪魔するレベルに主張するのは無料でもNG。
ライブドアブログだと500MBのFTP領域あるからそこを使うこともありだけどちょっと容量小さい。
最近CMでみるWIXみたいなマウス操作でかんたんデザインとかは要らなくて、1からHTML/CSS/JavaScriptで好きに作れるのがいい。
github などのホスティングも基本はいいけど、バージョン管理は不要だし、フォークしたりみんなで作っていくものじゃないから求めてるのとは違う感じがする。
実際に10年使うかはわからないけど、それくらいは大丈夫そうって思うところがいい。
最初にあげたブログたちのサービスからすれば無理ってほどじゃないと思うけど、ホームページだと同等程度のが全然ない気がする。
web hosting の比較系を見ていると日本と違って、GB/月とか無制限はみかけるけど信頼性がわからないのが問題。
使っていてここおすすめと思えるところあったら教えてください。
さきほど、フリーブックスが閉鎖した。
フリーブックスとドロップブックスの運営者が同じ可能性が高いという指摘は既になされているが、その2サイト以外にも同じグループによって今現在も運営されている違法サイトは複数あり、過去に運営していた無数のサイトも含めれば、巨大な違法エロシンジケートとでも言うべきものを形成しているといえる。
ここでは彼ら全てが滅びることを願い、調べることができた限りの情報を提供する。
フリーブックスに関しては前もって以下の記事を読んでおいてほしい。
http://anond.hatelabo.jp/20170501041533
上で挙げた無能ブログ(0chiaki)の記事で指摘されているように、フリーブックスの運営元はドロップブックス含め複数のサイトを運営している。
いずれもエロコンテンツを違法かつ大量に転載しているサイトだが、それぞれ住み分けがなされている。
(adultcity.toが同グループ運営という情報もあるが根拠が確認できなかった)
(5/3 17:15訂正：同グループと断定してよさそう。詳しくは末尾に追記)
これだけでも驚くべき規模だが、このエロシンジケートが過去に運営して既に閉鎖したサイトは少なくとも数十はある。
たとえば以下は16年5月～11月に存在したピュアラブ purelove.infoという、女性向けAVを違法に転載していたサイトである。
ベースはドロップブックスなど男性向けサイトと共通だが、デザインやライティングなど需要に合わせて高度にカスタマイズされていることがわかる。
ピュアラブは胸キュンなアダルト動画が楽しめる女性のためのアダルトサイトです♥
だけどエッチなものを見たり、リアルな友達とエッチな話しをするのは恥ずかしい…。
そんな恥ずかしがり屋な女性がこっそりアダルト動画を見て楽しんだり、
みんなのちょっとエッチな憩い（？）の場になるといいなと思うので
ぜひどんどん利用してくださいね♥(´ε｀*)
https://web-beta.archive.org/web/20161014030014/purelove.info
彼らの出発点はどこにあるのか。
調べた限りでは彼らは2011年から複数のアダルト動画サイトを運営していた形跡がある。
現在運営されているSHAREMOVIEは15年2月ごろに登場したようだが、15年から16年に渡って複数のアダルト動画サイトが、以下のような告知を残して閉鎖している。
当サイトは閉鎖をさせていただくことになりました。
ご利用ありがとうございました。
これだけでは別の運営者からサイトを買収し誘導しただけとも考えられるが、
しかしデザインやサーバーなどを見る限りいずれも以前から彼らエロシンジケートが運営していたと思われる。
詳しく見てみよう。
https://web-beta.archive.org/web/20120208010840/okujuku.jp
調べた中ではこのサイトが一番古くからの記録をInternet Archiveに残している。
当初は他の管理者による量産型エロサイトだったが、11年11月にエロシンジケートが買収したようだ。
管理者変更の告知や、投稿ボタンの追加などデザインの変更などからそう推測できる。
.jpドメイン+国内サーバーでは匿名性に不安があったのか、12年11月に.tvドメイン+海外サーバーへと移転する。
Internet Archiveによると、15年8月2日から3日の間に、上述のSHAREMOVIEへの誘導を残して閉鎖した。
以下、その他同様にSHAREMOVIEへの誘導を残して閉鎖したサイトを列挙する。
これらのサイトについての記録から、彼らについての情報を得ることが可能かもしれない。
これを書いている最中にフリーブックスが閉鎖したが、以上のようにフリーブックスは氷山の一角に過ぎない。全てを叩き潰す必要がある。
しかし既に指摘されているように、彼らは防弾ホスティングによって守られているので、サーバー所有者に対処を望むことは期待できない。
たとえばdropbooks.tvについての申し立てをCloudflareに行い、もしCloudflareがサーバー情報を開示したとしても、おそらく本体のサーバーはオランダあたりにあり、ホスティング業者は苦情を黙殺するか、開示するとしても業者はそもそも利用者のビットコインのアドレスくらいしか知らないだろう。
したがって資金源（広告）を断つことが一番有効な方法となる。こうした場合はしばしば「不適切なサイトに広告を出すな」という苦情申し立てが広告主に対して行われるが、今回はもっとよい方法がある。
SHAREMOVIE（3次元AV）にはmaist.jp、aspm.jpを経由してDMMの同人作品のアフィリエイトが表示されている。
ドロップブックス（同人）にはプレステージなどのブランドを持つMGS www.mgstage.comのアフィリエイトが表示されている。
当然のことながら、DMMのコンテンツはフリーブックス・ドロップブックスに転載され、MGSのコンテンツはSHAREMOVIEに転載されている。
違法コピーを間接的に助長するどころの話ではなく、自分の商品を盗んでいる本人に金を払っているのである。
このことにDMM、MGSなどの広告主側を気付かせさえすれば、広告を減らすことができるはずだ。
（他にワンクリック詐欺業者の広告もあるが、これについてはどうしようもない）
以下では今回調べている最中に気がついた細々したことを書いていく。詳しく追いたい人向け。
フリーブックスのベータ版のようなサイト、fpc.isには次のように書いてあった。
https://web-beta.archive.org/web/20161203115444/fpc.is
フルピースは月額900円〜であらゆるコミック・雑誌・小説・動画が見放題になるサービスです。
話題の新作も過去の名作もより取り見取りで見放題。月額見放題制だから手間なく見れて、本屋やレンタルショップに行くよりも断然手軽でお得です♪ぜひ下記ページよりご登録ください♪
お支払いにはVISA/MasterCard/JCB/AMEX/DINNERS/DISCOVERがご利用いただけます。「Vプリカ」でもご登録可能。
DINERSやDISCOVERが取り扱いに入っていることから予定していた決済代行業者がある程度絞れるかもしれない。
16年5月から開始されたANIMELEAXにも前身と思われるサイトが存在する。
https://web-beta.archive.org/web/20160422140541/2anime.net
一見してエロシンジケートではなく2DBOOK系列のデザインである。
しかし16年6月～7月、同一のGoogle Analyticsのトラッキングコードが使用され、16年10月にはanimeleax.comへの301リダイレクトが設定されている。
これだけだと16年に2DBOOK系列がエロシンジケートにサイトを売却しただけのように思えるのだが
それ以前に2015年の一時期、上記のokujuku.tv、中出しeyezなどとIPアドレスを共有している。
このあたり関係がはっきりしない。
いずれにせよドロップブックスと2DBOOK運営者の間に何らかの関係があるのは確かだと思われる。
フリーブックスの運営についてこのようなことを書いている人もいる。
http://anond.hatelabo.jp/20170502045025
しかし「奥様は熟女」などの発生がHやその周辺サイトよりも古いこと、ホスティング業者やWhoisプロテクト業者の選定が異なることなどから、フリーブックスの運営をHと同じ人間が行っているわけではないと思う。
とはいえ2DBOOK系列との関係が疑われるように、トップより下のレベルでの交流はあってもおかしくない（というかあるだろう）
id:ssig33などのTorrentに無い→自炊、という推測が不正確だという指摘は正しい。
動画・エロゲ・ソフトウェア以外、要するに本や音楽など、違法コピーのために技術も太い回線も必要ないものの一次放流元は現在圧倒的にWebである。
既に書いたとおり彼らは防弾ホスティングを利用しているのだが、それも完璧ではない。
dropbooks.tvでnslookupを行うと当然CloudflareのIPアドレスが返ってくるのだが、mail.dropbooks.tvでnslookupを行うと192.249.79.248というIPアドレスが返される。
このIPアドレスはCloudflareのものではなくGMO-Z.com USA, INC.すなわちGMOのグループ会社のものである。
アメリカの会社ではあるが、彼らが普段使う業者と比べてこのサーバーの「防弾性」は格段に落ちる。このサーバーの情報はミスによって公開されてしまっている、隠しておきたいはずのものだと思う。
したがって、GMOインターネット株式会社はドロップブックス運営者の情報を握っている可能性が高い。
アダルトシティ・投稿シティもエロシンジケート系列と断定して良さそう。
192.249.79.248に以下のメールサーバーが同居している。
mail.dropbooks.tv mail.examplekanai.com mail.lecielblue.net mail.toukoucity.to mailserver.smv.to smtp.lecielblue.net mail.noah-i.net
@Mnowben にもいくつか根拠が挙げられている。
同系列なのはわかったけど随分毛色が違うのでこれはこれでふしぎ。
(2021/2/7追記)書きました anond:20210207093448
オーナーチェンジを装って削除依頼フォームを英文にしたりしている違法エロマンガアップロードサイトのdropbooksだが、同じものがホスティングされているbestreams.netは、WaybackMachineだと2016/9/11付のアーカイブからdropbooksになっているがその前2016/07/02までは英語でXVIDEO動画あたりを流しているBESTREAMS（ロシア語と英語）となっているので、間は開いているものの、同一グループの可能性が大きいと思う。空白の２カ月の間にドメイン譲渡でもない限りは外国人グループに日本人が加わっていると見るのが適切か。
利益を削り株主配当も minne の投資に回しているため、市場には嫌われている(ように見える)が、事業の柱を育てるには仕方がない投資ではないかと思う。
上場企業ではない Creema との戦いが落ち着いたらまた株主配当を開始して問題ないだろう。
そもそも GMO ペパボは技術メンバーが素晴らしいと思っている。
CTO の kentaro さんをはじめ柴田さん、ペパボ研究所の方々その他諸々の方々。
そんなメンツが揃っているのに、市場は反応しないのは不思議だ。
ハンドメイド事業だけではなく、ホスティング事業も今年・来年と成長を期待。
株主総会でちらと書かれていたが、lolipop に新たなサービスを追加予定とされていた。
おそらくそれは、ペパボ研究所の "なめらかなシステム" についてではないだろうかと推測。
もしそうだとすると、ホスティングの集積率向上 (つまり利益率の改善) 、他社との差別化がされるのではないだろうかと期待。
脈略もない話になってしまったが、
インプレスが発行・運営する専門媒体「データセンター完全ガイド」
[Part 1] ラック料金 ～ スペースの料金で選ぶなら
■1/4ラック
1位 エムアンドシーシステム（丸井グループ） 19,440円～
3位 DCNデータセンターハウジングサービス（渋谷） 21,600円
同3位 鈴与シンワート 21,600円～
■1/2ラック
2位 DCNデータセンターハウジングサービス（渋谷） 32,400円
同2位 鈴与シンワート 32,400円～
同2位 エムアンドシーシステム（丸井グループ） 32,400円～
■1ラック
2位 伊藤忠テクノソリューションズ 54,000円～
同2位 DCNデータセンターハウジングサービス（渋谷） 54,000円
同2位 鈴与シンワート 54,000円～
───────────────────────────────
[Part 2] 回線料金 ～ リーズナブルな回線を使うなら
同1位 鈴与シンワート 5,400円～
同1位 シーイーシー 5,400円～
3位 バリューコア 27,000円
同3位 シーイーシー 27,000円～
1位 TIS 81,000円
2位 KAGOYA DC+ 140,400円
同2位 鈴与シンワート 140,400円～
───────────────────────────────
■総床面積
1位 アット東京 202,400平米
3位 TIS 110,000平米
同3位 富士通 110,000平米
※上位3位までを抜粋。
───────────────────────────────
2位 アルテリア・ネットワークス 750Gbps
3位 さくらインターネット 722Gbps
※上位3位までを抜粋。
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
http://anond.hatelabo.jp/20160422184218
↑これの続き。
-----------------------------------------
こういうことを書き捨てていくと老害がいなくなっただけだって思われるかもしれないんですけど、このセグメント問題ってのはサービス運営の側に立って考えるととても難しいものじゃないかって考えているんですよ。
これについてはきっと中の人も葛藤があるだろうなーってのは思います。なんだかんだ生え抜きの技術者がいるだろうし、自分の知っているユーザー層とは違うサービスになりつつあるという思いがある人はいるんじゃないかな、と想像します。でも、ビジネスとして、商売として考えるならば、敷居を下げて、大衆的な（むしろ衆愚的な）話題のコミュニティであっても、ライトユーザーに拡大できて、キチンと定額課金と広告料を取っていかなければならない。短期的に見れば、これはむしろ最重要課題です。
散々書きましたが、個人の思いを割りきって仕事人間の立場として考えるならば、はてなブログPROの月1,000円（2年契約でも600円）っていうモデルはよく踏み切ったなーって思ってるんです。ネット系ベンチャーのご多分に漏れず、マネタイズで苦労してたはずですからね。
自分でいじれる人にとっては、システムの機能だけ見ればこの有料サービスはほぼ魅力がないです。安いホスティングのレン鯖やクラウドにWordpressを入れたほうが安いし、写真なんてGoogle PhotoだってFlickrだって使えるのに。実際のところは、「好きなアフィリエイトが設定できる」「あれやこれやを堂々とやれる『市民権』を得られる」というメリットが大きいですよね。はてなのユーザコミュニティを活用できて、ブクマとスターが近くて、初心者でも扱える。つまり、あの界隈って、ネットサービスのビジネスモデルとしては私のような厄介なユーザーよりずっと適切なターゲットユーザーなんですよね。
でもね。でも。あくまでも「短期的」は「短期的」でしかないんですよ。
運営している人も絶対わかってると思うんですけど、サービスにはコアが必要なんですよ。ストーリーがあって、そこから生まれたコアユーザーがいて、インフルエンサーになって規模を大きくしていく。特に、はてなみたいなコミュニティは、ユーザーによって育てられてきたサービスでしょう。
古い考えかもしれませんが、ブランドっていうのは一朝一夕ではないんですよ。「ブランドは作れる」なんていう広告代理店の言葉もありますけど、勘違いしちゃいけないのは、その作るってのは買ってすぐできるっていうことではないっていうことですよね。理念があって、コアユーザーがいて、クチコミで広がっていくものでしょ？だから、仮にイメージの転換が急務だったとしても、ユーザー層がガラッと入れ替わっちゃうと、後が続かないんじゃないかなって思うんです。
私自身も仕事で広告出稿したりすることもあります。ECをやってるんで、検索流入や、導線や、コンバージョンも気になります。
だから、アフィリエイトを貼ってくれるようなブロガーさんとはお仕事的にはパートナーだったり、お客さんだったりとありがたい存在でもあります。誤解のないようにはっきりさせておきますと、私はアフィリエイト広告自体は（PV稼ぎのモラル問題とかは別として）全然否定していないです。PVが増えて嬉しい気持ちだってわかりますよ。自分だって嬉しいから。
でも、ネットコミュニティを扱ってきた人間の端くれとしてつくづく実感しているのは、人は思いのこもった言葉で動く、コピペじゃ人は動かない、ってことだったりもします。
本当に好きなものを好きだからとブログを書きたい人は、ポイントがつこうがつくまいが、アフィが貼れようが貼れまいが、とても面白い記事を書いてたくさんの人を連れてきます。上手い下手はありますが、全てではないです。逆に……って、書かなくてもこれは言わずもがな。
アフィで炎上芸をやって、PVガー流入ガーって言う人を見るとちょっと寂しくなります。それが社会の現実だからしゃーない、っていうのもわかるんですけど、世の中には本気で知ってもらいたいと思う情報を見てもらうためにタイトルを一文字変えるとかバナーをA/Bテストするとか、本気でサイトを便利にしたいと思ってボタンを1ピクセルずらすとか何ミリ秒レスポンスを早く返すとかやってる人がたくさんいるわけじゃないですか。どうせなら、そこに乗っかるコンテンツも良いものであって欲しいじゃないですか。
そんな業者やオタクの言うこと知るか、って言ってきた人もいるんだけど、でも、本気で自分が作ったサービスや、あるいは自分が書いた記事で便利に使ってもらいたい、喜んでもらいたいと思っている人間としても、あるいはユーザーとして本当に面白いコンテンツにめぐりあいたい、って思っている人間としても、皆にとってそれぞれ満足できる「界隈」があるといいな、って思うのです。データマイニングを駆使した個人別最適化によってコンテンツが出しわけられているのでも良いのですが、はてなのような個性のあるWebサービスは、できればユーザーが体験を共有できる「オープンなはてな村」であってほしいものです。
最近はじめてブログを書こうと思った学生だって、ITにそれほど強くなくて、お友達とブログを書きたい、ついでにお小遣いももらえたらラッキー、っていう純粋な気持ちでやっている主婦だって、古参から「最近の奴らは……」なんて言われて恐縮する必要なんてないと思うし、共存できると思うんですよ。
ただ、アフィリエイトだけが目的で確信的にやってる層は同じ「素敵ですね！ありがとうございます！」でも、なんとなくわかっちゃうんですよね。そういう記事ばかりが眼に入るようになると、正直ちょっとうんざりします。
また脱線しましたけど何を言いたいかっていうと、要するに、「長期的に見た場合」としては、コアユーザーとサービスの特色がキチンと育っていて、他のユーザーの共益を阻害しない、っていう状態じゃなきゃいけないんじゃないか、っていうことですね。
この特色付けにしても、はてなブログはもうちょっとうまくやれたんじゃないかなあ、って余計なお世話なことを思ったりするところはあります。もっとも、まったく小洒落ていて気が利いた広告戦略やマーケティングとかできるようなキラキラな会社じゃなくて、それとは真逆の非モテ野郎どもだった（勝手な想像）、っていうところがはてなの好きなイメージだったわけではあるのですが。
※ほら、何年か前に、2chで「Webサービスを擬人化したったwww」っていうネタ流行ったじゃないですか。hagexさんがまとめてたと思いますが。あれのね、はてなの擬人化イラスト、皮肉じゃなくてわりと悪くないんじゃね？って思ってたわけです。ミサワがドヤ顔してるやつ。少なくとも、mixiモバゲーがウェーイしてるのとかよりかずっといいですよ。
同じ大衆化の道を辿るにしても変なミニマリスト界隈とか、アフィ軍団とかに捕まるくらいなら、もっと有益なカルチャーを形成できる仕掛けってなんとかならなかったものかなあって。いや、外野が1秒で思いつくこんなことはいくらでも考えつく人がいるだろうし、プラットフォームとコンテンツの話は別だろとも思うし、既にブログMediaで提供されているみんなのごはんとか気に入って見てるんですけど、ジャンルはともかくとして、そういう書き手を集める営業はやっぱキラキラ系のところのほうが上手いんですかねぇ。
お前誰だよ、なんでそんな熱く語ってんだよ、と誰しもに思われると思うんですが、実際のところ私は自分用にブクマを使っていただけのユーザーですし、ブログサイトを作っていじる側が中心だった人間なもんで、自分自身が上げたコンテンツはそれほど無いです。すみません。
最近ちょっとだけはてなブログを個人用日記に使っていたんですけど、今改めてMTでもWPでもないブログポータルを使ってみたらどんな感じでどんなことを思うんだろう、ってことに興味を持ったためです。この文章は、その結果として書いています。
はてなブログ自体は便利で書きやすくてとっても気に入ってます。βテストの時はカテゴリすらなく本当にシンプルで大丈夫か？って思いましたが、特にGoogleフォトやTwitterなどの外部サービスからの貼り付けが気に入っています。確実にダイアリーより使いやすいです。今後もますますの発展をお祈り申し上げますです。
なんだかんだ書きましたけど、要するにですね、私は単なる無名ユーザーですけど、こういう熱心なファンもいるんですよってことなんです。今までたくさんの発見と感動をもらったことに本気で感謝してます。興味深い！参考になる！感謝！とかそういうのではなくて。
距離を置く、と書きましたが、自分の情報クリップの習慣として、はてブ⇒Evernote連携の流れが便利で染み付きまくっているので、引き続き淡々とブクマは利用させていただきたいと思います。今まったくお金を落としていないことに罪悪感すら感じていますので、お礼の気持ちを込めてちょっとスターでも買って、ホソボソやっていきたいなと思います。
古参物書きも、ギークも、ステキ主婦も、手斧軍団も、お小遣い稼ぎの人も、みんながワイワイ楽しくヒャッハーできるやさしい世界ができるといいですね。
草々んじゃーね。
まずは、大変遅ればせながらはてな上場おめでとうございます。2ヶ月遅れですが。
先にお断りしますと、この文章は長いです。12,000文字近くあります。そう言えば最近「長すぎて読めない」ってタグ見なくなりましたね。
元々は数日前に自分のブログに投稿したのですが、アイコンを見てもIDを見ても誰にも認識されていないであろう私がこんなことを書いているのも気持ち悪いような気がして、衝動的に消してしまいました。そんな文章ですが、せっかく書いたので思い返して増田に投下します。それでも交流のある僅かな方からは、「あ、あいつだ」とすぐバレると思いますが、全く構いません。
大げさな振りをしてしまいましたが、この、はてなの世界からゆるやかに距離を置こうと思いまして。
ハイコンテクストな話題で、関係者でも有名ユーザーでもない私が語るには随分と分不相応であろうことは承知しているのですが、私は人知れず長年このはてなという会社とそのサービスの利用者でした。たぶん、相当熱心なファンのほうだと思います。
しかしこのはてなという界隈、おそらく長年世間一般的には「俺ははてなが大好きなんだー！！」とはなかなか言い出しづらい雰囲気と言いますか、一部一種のギーク（ナードか？）臭さみたいなものから逃れられないセグメント感があったために、公の場であまりそれを声を大にして語る機会が無かったという状況があったような気はしています。
勝手な想像ですが、よく言われるとおり先日上場した株式会社はてなとしてはきっと、そういった閉鎖的なカルチャーからの脱却を図る必要があるのは事実なのであろうと考えています。
私は「はてな界隈」という自然発生的な、「インターネット好き」が作ったプラットフォームとコンシューマージェネレイテッドなコンテンツが組み合わさってできた若干マニアックな文化がとても好きで、かつてインターネットに期待していたワクワク感のようなものを自分の感性ともっとも近い形で目指している会社だなと思っていたので、はてなを好んで使っていた理由も、今これを書いている理由も、サービスが向かう方向性とのギャップが発生したということで仕方ないのかな、と考えてはいます。
回りくどい書き方ですが、つまり、ここ最近（数年）の急激な利用者層の変化、人気ブログやホッテントリに上がってくる記事とその使われ方の変化、新たな利用者層との精神的摩擦に疲れて消耗するのが嫌になった、ということです。
私は自分の楽しみのために自分が面白いこと書き、読むっていうスタンスで自分のスペースを使ってきたので特定のユーザー群を非難するのはその趣旨とズレるし、メタな「ブログ論」を書くつもりは無いんです。なのでわかりやすいバズワードは書きませんけど、要は、そういうことです。お察し。
ここまで書いておいてから自己ツッコミを入れますが、私がここでこんなことを書いていても、おそらくそれほどの価値は無いのでしょう。
私は長年使っているとは言いながらも、所謂「はてな村」と言われるような有名ユーザー層に所属するようなアカウントではないし、特別人に見られるコンテンツを上げていたわけでもコミュニケーションを取っていたわけでもないし、こんなことをグダグダ書いていても「知らない人。気持ち悪い。」で片付けられてしまうような気はします。
コンテンツもお金も落としてもいないアカウントですので、ある意味運営側の立場から見れば、「うるさいことだけごちゃごちゃ言って全くサービスに貢献しない面倒くさいアカウント」あるいは「フリーライダー」と言われても仕方がない気がします。
これは別に被害妄想を語っているわけではなくて、自分がサービスを利用して得たメリットと、お客さんとしての価値を第三者的に見た時、そういう風に判断されてしまっても仕方ないかな、と冷静に思っただけです。
最近、はてなブログやブクマを見ていて、「これは自分には合わないな」と思ってケチを付けたくなる機会が多くなってきたことと、でも、ケチを付ける発言力（あるいは権利）のバランスを天秤に掛けて、ああ、もう自分が楽しく見ていられる場所ではないのかな、と感じることが増えてきたことと、単なる1ユーザなのにそんなことを考えてしまうこと、考えさせられてしまうことが嫌になってきてしまったということがあって、こりゃ、私の居場所はもう無いのかもしれないな、と思いつつあるということです。
かつての掲示板サービス群から始まってブログランキングやら、SNSやら、インターネットのサービスではいろんなところでこのような文化の変遷みたいな場面は見てきたはずなのだけれども、思ったより自分の生活の大きな部分にはてブが入り込んで浸透していたことに自分でもかなり驚いていますね。
前提としてなぜ、こんなマイナーキャラの私がそこまで一、ネットサービスに入れ込んでいたのかについてちょっと語らせてください。長くてすみません。
私のはてな歴は12年くらいです。長かったらどうだというわけでは無いのですが、はてなを知ったのはまだ人力検索しか無かったころで、自分が実際にユーザーになったのは例の「日本人にはブログより日記」のちょっと後、「はてなダイアリーをはてなブログに名称変更」とかエイプリルフールネタでやっていたころです。最古参ではなくて、ブログブームの頃に「はてな界隈」を意識するようになったので第2世代くらい、ということになるのでしょうか。
その後アカウントが一回変わっていて今のIDは5、6年くらい前に取りなおしたものなので、おそらく古参ぽさは無いですね。
はてなには他社のサービスと比べてとりわけIT系ユーザーの比率が高いと思いますが、私もそうです。一貫してネット関連ですが完全な同業というわけではなく、何度か変遷を経て今は流通系事業会社のインターネット事業担当になったというキャリアです。
はてなのサービスを認識した時はちょうどMovableTypeの2.6あたりが日本でも流行りだした頃で、「Web日記がhtml無しでこんなに簡単にできるなんて！」「コメントとかトラバとかすげー！コミュニティ作れまくり！」とかっていう話題で日々興奮していたのを覚えています。90年代後半からネットは見ていたけれど、これからいよいよ「普通の人」にもオープンに普及していくんだなー、と夢描きながら仕事で、あるいはプライベートでどう活用しようか考えていたんですよ。「Web2.0」より2年前くらいのことですね。
その頃、ちょうどあるECサイトのコミュニティサービスの担当をしていたんですね。いろいろやりましたよ。掲示板サービスが炎上して閉鎖に追い込まれたり、画像著作権で揉めたり、ブログが使えるようになってからは、「ブログに商品の宣伝を書いてリンクを貼ってくれたら100ポイント！！」とかいう現代であればGoogle警察が1日でぶっ飛ばしにくるようなプロモキャンペーンもせっせこ考えては公開してました。更にその後はOpenPNEベースのmixiっぽいSNSをやったりとか。
今考えるとうわーっていう企画も多かったのですが、おおらかながら大真面目にやってたんですよ。まじめに、ライトユーザーに使ってもらうにはどうしたらいいかとか、コアユーザーがどう伝搬してくれるかとか考えてました。その頃は（ネット上のマーケティングにおいては）セグメントの乖離とかそういう問題も今ほどは研究されていなかったし、たぶん自分でもまだ十分理解できてなかったんですよね。私はそんな感じの人間です。
自分語り方面に脱線したので話を戻しますが、ブログブームちょい前の頃、世の中で出始めたブログのアカウントを片っ端から取っては試すということをやっていたんですよ。ココログ、はてダから始まって、livedoor、goo、Excite、Seesaa、Jugem、FC2、楽天、MSN、ドリコム、ウェブリブログ、ドブログ、Yahoo、ヤプログ、アメなんたら……
でですね、そのときにはてなの特異性に気付いたわけです。
なんだこりゃ、殺風景なサイトだなぁ、なんか研究室みたいだなぁ、システム屋くさいなぁ、ってのが当時の正直な印象です。まったく間違ってないと思いますが。
ダイアリー以外の他のブログサービスはだいたい大手キャリア系か、大手ポータル系か、大手ホスティング系のいずれかじゃないですか。実際仕事で関わることがあったのはそういった会社さん達だったわけだったんですけど、私個人的にはこのはてなダイアリーってやつにとても興味を持ったんですよね。
純粋にIT系オタク集団（失礼）がコミュニティで勝負するっていう構図のサービスがすごく面白いなって思いまして、当時から実際にIT系のギークな技術記事とか、濃厚なネットのいざこざとかそういうのがぐちゃぐちゃと集積されつつあって、うわぁ危険と思いながらもはてなだけは明確に識別して見に行く感じになってたんですよね。
人力検索もそうですが、アンテナとか、キーワードとか。私はネットコミュニティをやりたくてこの世界に入ってきた人間なので、人と人をつなげるサービス、というコンセプトに対して面白いことをやろうとしている人達がいるんだなーって思ってたんです。こんな殺風景な非コミュ論壇だらけのサイトなのに。なんだかそのギャップがまたすごく居心地が良くてね。よく閉鎖的って揶揄されるはてなですけど、私はそんな風に思ったことなかったな。
そう、私は村感というよりは、僻地の秘境だけどここは自由でオープンだ、っていうように感じていたんです。
今はなおさら顕著ですけど、その頃って既にインターネットサービスが外来の大手サービスに集約されつつあったじゃないですか。ブログにしたってMovableTypeもWordpressも外から来たものだし、MySpaceとか、Facebookもそうだし、その後の流れって周知のとおりって感じじゃないですか。強いて言えばmixi……はやっぱべつにいいや。
そんな中、日本のドメスティックな小さなネットベンチャーが純粋なコミュニケーションの仕組みだけで世界観を醸成して、しかも生き残るっていうことに夢を感じたんですよ。まあ、ドメスティックっていう部分について言えば、jkondoさんが渡米した時期とかあったなぁ、とかあるんですけども。
はっきり告白しますけど、私のような自分で新しいプラットフォームを開発するほどの実力が無い中途半端なネット屋にとって、超恥ずかしながら彼らはヒーローだったんですよ。jkondoさんやnaoyaさんは私とほぼ同い年ですけど、勝手に同世代のヒーローだと思ってたんですよ。
はてなブックマークでソーシャル・ブックマークという概念を身近に体験した時は「単なる『お気に入り』じゃなくて、興味を持ったものについて何時でも語り合える世界が作れるんだなあ」ってリアルに衝撃を受けたし、スターが登場した時は（FacebookやTwitterより前に）これ、シンプルだけどもしかして世界を幸せにする機能じゃね？って感動したりしましたよ。
だいたい、jkondoさんはすごいんですよ。私など勝てる要素が無いですよ。スプリントでもロングでもヒルクライムでも絶対勝てないですよ。山も強いし、みんな山手線一周1時間48分てできます？？サラッと書かれてたけど、メチャクチャ速いよ！！俺も何度もやってるけど、大真面目にやっても3時間切るのだって大変だよ。明治通りや中央通りはともかく、田端駒込あたりの裏路地とかどうしてたんでしょうね。メッチャ危ないよ！！つか、あの頃の自転車クラスタみんなどこ行っちゃったんでしょうね……
何の話でしたっけ。そうそう、趣味が合いそうな人達が集ってるっていう話でしたね。
私の文章は、テキストサイトからアルファブロガーあたりまでの文章にめちゃくちゃ影響を受けていると思います。ちょっと極端なことを書いたら「フロムダ先生の真似か」とツッコまれてドキッとしたり、写真クラスタの真似をしてやたらでかい写真を並べてみたり。最近は年に一回お正月だけに現れるmk2さんの文章を見ると涙が出そうになります。長文には慣れています。必死に調べないとついていけないような技術論議や、内蔵をさらけ出して書いたような、編集が入った本では読めないようなブログを読みたいし、そういう記事でみんなが共感していく世界が見たかったんです。
はてなブログの目次記法は便利だと思うんですけど、他所のニュースサイトに貼られた記事を引っ張って目次を並べていかがでしたか？なんていう記事を、私は単純に面白く読めないんですよ。「参考になりました！」じゃねーよ！！ならねーよ！！残念すぎるだろ！！なんて思ってたんですよ。
ここまでで既に5,000文字を超えてしまいましたが、話が飛んでしまったので一旦元に戻します。
つまり、そういった「自分の好きなものを好きと言う」「好きなものを選んで、好きなものを見て共感する」という、人の本能的なコミュニケーションの楽しみの源泉のようなものを、私は求めていたんだと思います。自分の背中に正直な、泥だらけのスニーカーで追い越すような体験を期待していたんです。
もちろん、どんな時代にだって人と人のコミュニケーションにはいろいろあって、変わらないものがたくさんあるんだとは思いますよ。パソ通の時代だって、BBSの時代だって、初期のブログにだって、「読みました。記念カキコ☆」はあったし、コメント欄で交流が繋がって新たな友達ができるという興奮だってあったし。
最近のはてなだって、今、その興奮を新たに体験して純粋に喜びを感じている人達がいるはずだしそれはもちろん喜ばしいことなんですけど、さすがにこの情報過多なご時世なので、ツールと場所の管理と運営をしっかりやっていかないと、純粋な喜びを埋もれさせず、コンテンツの品質を保つのは相当に厳しいなという実感はありますね。
一般化、大衆化、というものはだいたいそうで、単純に「この村も昔は良かったのに」っておじいさんが言っているっていうような話ではないと思うんですよ。
こんなことを話している私自身が既にネット上では「古い側」の人間になっているのかもしれませんが、個人的には、「はてな村」とかって言われている界隈にそれほどイライラするような内輪感を感じたことは無いんですよね。実際にひどい攻撃的な言葉が飛んできて嫌な思いをしたことだってありますし、慣れ合いとかってのは昔も今もあるわけなんですけど、だいたいは好きなことを好きなように書いた、っていうモチベーションによって書かれた記事は、面白ければ当たるし、面白くなければ流行らないわけじゃないですか。読む側だって気に入ったら読めばいいし、気に入らなかったらスルーすればいい。だいたい、広い世界で見ればごく一部のできごとだっていう側面もあったわけじゃないですか。
だから、一定の、嘘を嘘と見抜ける程度のネットリテラシーさえあれば、海水浴場の中に浮かぶ邪魔な漂着物があっても、農耕地が石だらけで荒地になっていても、単に避ければいいだけだって思ってたんです。
むしろ、良い記事にフォローが集まったり、ひどい記事はひどい記事でそれに集まった批判が有益だったり、そうやってやり取りを応酬する中で集合知として収斂されていくという光景は、みんなで海を掃除したり、畑を耕していくような感覚を覚えていつもネットの醍醐味であり爽快ですらありました。
……でもね。最近の例の動向はちょっと様相が違っていて、私のようなユーザーにとってはもうちょっと見ているのが厳しいな、というのが本音です。商業的なまとめサイトが場を汚染している、というような話であればユーザー側コミュニティによるチェックと自浄作用が働きます。はてブはうまいことそういう機能を果たしてきたと思うんですよね。
でも、ユーザー側のほうで「良いと思ったから良いと言った」というお気に入りによるキュレーション機能が働かず、返報性の原理によるコミュニケーションが中心の場になってしまったら、今のままのはてブでは、（コメントツールとしてはともかく）少なくとも情報ツールとしての価値は大きく毀損されます。これは、ユーザーのモラルもありますが、サービスの構造上の問題として避けられなかったことだと思うんですよね。
海や畑が全部「あれ」になったら、もうどうしようもないでしょう。もう去るしかない。
この問題についてはさんっざんぱらたくさんの人に書き尽くされているのでここでは書くつもりないんですけど、小遣い目的で面白くない記事が量産される、共有のヘッドラインが専有されて他のユーザーに影響を及ぼす、内容に関係なく相互フォローする、これらは本人の意識あるなしに関わらず、関係ない人から見たら無益です。
これについてルール違反がないのならば、サービス品質を維持するための運営／システム側の構造課題を疑ったほうが良いし、ユーザー側についても、一部の炎上チャリーンで喜ぶようなやつは単なるスパムなのでこれは単純な絶対悪ですよ。
別に、ネットの世界で今始まったことじゃないんですよ。むしろはてブは牧歌的で今まで性善説でよくやってこれたなっていうレベルじゃないかと思います。Twitterでも「相互フォロー推進委員会」とかあったなあ。一方的に何百人単位でフォローしてきて、ふぁぼりまくって、こっちが反応しないと砂をかけて去っていくようなのが……
ただそういう人達がごにょごにょ楽しくやってるだけならどうだっていいんですけど、今はホッテントリが明らかに使いづらくなっていたり、更には他のSNS経由でこの界隈の記事が流れてきて反応したらおかしなことになったり、実際にそういうことが発生しだしているんですよね。これが結構精神的にくるものがあるんですよね。
というわけで、そういう一団がこのサービスのほんの数%、もしかしたら0.数%の人達であり、ほとんどの普通の人は何も気にせず普通に自分の日記を書いているんだ、てことはわかっていても、でももう気持ち的にこの界隈と一緒の世界でブログを書くのは無理かもしれない。既に古参と言われる人達がかなり去っていっているし、生き残っている人達も読者層が急激に変わっていたりとかして、なんていうか、見ててつらい。
※最近、ある有名人気ブロガーのブログを読んでいて、半年前にも同じテーマで書かれたことがある記事がホッテントリに入っていたのを見たんですけど、ふとブコメを見てみたら、半年前の記事と反応のコメントが全然違くてびっくりしたことがあったんですよ。よく見ると、並んでいるアイコンがガラリと変わっていることに気づきました。読者層が急激に入れ替わっているんですね。
この人はムラ社会に寄る人では（読者から見たイメージでは）無いし、長い人とも新しい人ともバランスのいい関係を築けていてすごいなあ、と思っていたのですが、図らずも急激に「有名人」として新規層の神輿に乗せられているように見える状態になってしまって、一方で彼自身は広告収入で儲けているようなブロガーではないし、内心複雑な気持ちなんじゃないかな、とか勝手な心配をしていたりします。そういう人、何人かいますよね。余計なお世話すぎるとは思うのですが。
------------------
いま、どんどん新しい「パクリ疑惑」のデザインがネットユーザーによって見つけられてきていますが、デザインの歴史が深くなり文脈が形成されていくと、そこには明らかな引用や模倣も増えていきます。それはどんな文化でも同じで、音楽なんかもそうです。デザインもスタイルであり、継承されていくものなのです。だから、造形的な面でなんでもかんでも「パクリ」と決めつけられてしまうと、デザインの歴史が続いていくことそれ自体を否定することと同じになってしまいます。なにかから影響を受け、文脈が形成されていくことを「パクリ」の一言で否定しないでください。
海外の元ネタの方のデザイナーや権利者から批判されてる理由について、元増田の見解を聞きたいな。
中には法的措置まで言い出す人もいるんだけど、彼らは「デザインの知識や歴史を知らない素人」だから怒ってるのか？
・佐野研二郎さんはじめ、今回の件でなくてもあらゆる人が「在日」だとか「売国」だとか決めつけられ、それが批判のいち要素になる社会に疑問を抱きます・・・。
在日ネタの発端は、佐野の事務所するサイトのネームサーバーが「zyappu.com」で、ホスティングサーバーがNHNの子会社というのが元ネタだろ。
そしてそれが騒がれ始めた直後に「お名前.com」に変更されてる。
是非はさておき一応の火元はあるんだよ。
http://webbingstudio.com/weblog/cms/entry-773.html
小規模の商用サイトでは、フォームを暗号化する際には、共有SSLを利用するのが当たり前となっています。独自ドメインのSSL証明書を取得すると、フォームを通して得られる収益よりも、維持費の方がはるかに高くなってしまうからです。
とこの記事では書かれていますが、一体どこで「当たり前」なんでしょうか？
SSL証明書の取得費用は、サーバーホスティングによって額がまちまちなのは確かですけれども、
安く独自SSL証明書を取得して利用できるサーバーホスティングは山ほどあります。
WEB制作者として「自分が良く知っているだけ」のサーバーのレンタルをクライアントに押し付けてはいませんか？
また、小規模商用サイトにしても、仮に年額35,000円のSSL証明書をつけ、かつ、月額3,000円のサーバーを借りていたとすると
月額でいえば6,000円くらいの負担ですが、
いくら小規模とはいえ、広報活動の中核をなすWEBサイトであるならば、
月額6,000円をペイできないとすると、
（というか、効果測定をしていないだけ？）
共用SSLのリスクに関して言えば、この記事が引用している、高木浩光氏の書かれている通りではあります。
cookieが取得できてしまう結果として、一番最初に狙われるのは、管理画面へのログイン。
いわゆるセッションハイジャックです。
ログイン状態を乗っ取られた時点で、どんなCMSでも、WEBサイトの改ざんは可能です。
なぜか。
そのコンテンツは多くの場合MySQLに代表されるDBに保存してあります。
したがって、ファイルの改ざんなどを行わずとも、WEBサイトの内容は書き換えることが可能なのです。
「なるほど」と思ってしまうかもしれないので、
早々に訂正していただきたい。
また、この記事にある a-blog cmsというCMSについてはよく知りませんが、
多くのモダンなCMSでは、ほとんどの管理画面ログインにおいて、
セッションハイジャックに対する防衛は行われていますので、
cookieの取得が、即WEBページの改ざんに繋がるような書き方も、
ここも早々に訂正していただきたい。
この筆者さんは、a-blog cmsというCMSを利用されているようだ。
このCMSはどうやら、PHP製ながらPHPのソースを暗号化しているようだ。
こう言ってはなんですが、攻撃者にしてみれば、a-blog cmsを攻略するくらいならMovable TypeやWordPressを攻めた方が楽というものです。
この記述はむちゃくちゃである。攻撃者にしてみれば、誰でも手に入れられるCMSであれば、
a-blog cmsの公式サイトを拝見すると、MySQLを利用しているようで、
ファイルの暗号化はなされていようとも、DBの中身の仕様は丸見えだ。
前提条件として「知っている」「知らない」の差はあれど、攻撃に関して「ラク」というのは
どう考えても楽観的に過ぎる考えだ。
どうも「SSLで確保される安全の領域」について、かなり認識が甘いようだ。
SSLはあくまで、TCP/IPネットワークにおいて通信経路を暗号化するための技術だ。
通信する際に、通信先のサーバーが正しく認証されているかどうか？に必要なのはSSL証明書。
で、ここに書いたとおり、SSLはあくまでサーバーと利用者の通信においての暗号化だ。
この記事に書かれていることは「メールフォームについて」のことのようだが、
サーバーに到達したあとのメールについては安全性をかんがえていますか？
メールは全く暗号化されず平文で送信されるとても脆弱な通信手段だ。
いくらSSLで通信を暗号化しようとも、問い合わせフォームの送信がメールだったとすると…
とこの記事ではかかれていますが、そもそもHTTPやHTTPSの通信を傍受するより遥かに
メールを傍受したほうがラクとも考えられるはず。
CMSの機能に甘んじて、こういったベーシックな問題に考えが及んでいないとすると、
とおもう。
記事に対するつっこみではないですが、
正しくは「TLS」でっせ。
第一に、発端となった元ツイートには「非エンジニア新卒女子」とはっきり書いてあるのに
《旧式言語を学ばずに関数型言語一本槍でエキスパートを目指すような感じの方》
《「まず軽く触れてみよう」とか「趣味でやってみるか」といった程度ならいいのですが》
《実際には肝心なことを何も知らないのに、なんか知っていると思い込んでいる状態が、私いわく「脳味噌膿んでる」》
ひどい書きっぷりだよね。
もし自分が当事者だったら「見ず知らずの人になんでここまで言われなきゃいけないの」と傷つくと思う。
第二に、下位層のレイヤーについて知っていなければ上位層のことをちゃんとやる資格がない
という態度が明らかに本人のダブルスタンダードっぷりを示している点
と言いたいのだと思うけど、最近のCPUはマシン語に書かれていある命令をそのまま実行しない。
インテルの場合もCISCの命令セットで記述されたコードをRISC的なマイクロコードに分解・解釈して実行する。
さらに内部はパイプライン化されているため、単純に「１命令ずつ逐次実行」されてもいない。
外側から観察するとあたかもマシン語の命令列をひとつずつ逐次実行しているかのように振る舞っているだけだ。
マシン語のコードで記述されたプログラムが、命令通り入力と出力を繰り返すなら、内部でどのような先読みや予測分岐を繰り返していても問題ない？マシン語の忠実な実行装置とみなしてよい？もちろん回路の設計ミスで誤動作するかも知れないけど、それがプログラマの「根本的な過ち」になる？
OCamlの世界で記述されているロジックが、OCamlの仕様通りにちゃんと動作すれば、その下位層にあるマシン語がどういうパラダイムで記述されていても関係ないと考えていいと俺は思う。
余談１
くだんの女子について、周辺のツイートを見てみると（完全に部外者の憶測だけど）Railsを主力とするソフトウェア企業に非エンジニアとして新卒で入社した新人がプログラミングに興味を持ったのに対して上司がOCamlの本を教科書として渡したのでそれを学んでプログラミング考え方を身につけた。その後Railsについても学んでみようとしたが、考え方のギャップに強い違和感を覚えた。…という経緯みたいだ。
余談２
https://twitter.com/camloeba/status/611051620877537281
https://twitter.com/sessoh/status/611052396161183744
このやりとり、拙僧さんが「肝心なこと」と思ってることを卯之助さんは「重要でない」と言ってるんじゃないですかね。
