はてなキーワード: ドメインとは
ブログ記事のネタを探すためにさっきはてブで検索してみたんだけど、USERS数が3前後で無駄に長文で数記事しか無い、サテライトサイトだと思われるサイトが多数ヒットした。
自己ブクマでキーワード詰め込んだサイト作ればSEO効果あるとか思ってるんだろうけど、いい加減、これをやるやつ(依頼するやつ)は無駄だって気付こうよ・・・。
わざわざ日本語ドメイン取ってドメイン別にサイト作ってるけど、そのドメイン代も稼ぐことができないって。
中途半端にサーバ環境整える割には、記事内の文章は改行してないし、画像も全くない。ただテンプレートに文字をぶっ込んでるだけ。
別にDeNA並に頑張れとは言わないけど、さすがにこんなやり方は無意味だし金の無駄って気づくだろ。少なくともちょっと検索したりSEO本でも読んでたら。
それすら気づかずに業者の言いなりになって無駄金使うって、あまりにも考えてなさすぎる。はてなもこんなクソサイトを検索結果に表示しないでほしい
大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。
悪く言えば自分の能力に絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。
相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。
本来の業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。
せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。
プログラミングの経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドでVBAから、Rやら自社製品の解析用環境の割と珍しいタイプのスクリプト言語など(特定されそうだからぼかすけど。)
とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手に作ってみたりして提案していた。
物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。
この辺で気付いたことだが、製造業のITリテラシーは驚くほど低い。製造業と一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。
なんせまともにプログラムを書いたことが無い新人が半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。
ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。
(そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。)
2年目に気付いたのは、弊社エンジニアのITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。
製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。
無骨だが使いやすいイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。
だから逆に言えば下々の人間はコピペでなんとか恰好を整えられるのだった。
彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。
私はそれに感動した。なんせWebスクレイピングみたいな方法で他人が社内プラットフォームや社内WIKIに上げた報告をまとめたり、製造時データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。
それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。
何にせよそういったものを一気通貫、自動化できるポテンシャルがあると感じられた。
SQLもjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しかも管理はIT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。
ところがその「ビッグデータ」プロジェクトは人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。(あとで聞いた話、外部コンサルで外れを引いたらしい)
自分もドメインの知識からの助言とか想定される使い方についての意見を伝えていったし(有難迷惑だった可能性は否定できないが)、もう少し待てばモノになると信じていたし、実際そうなった。
具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果の確認の為に数十億行のデータが活用された。彼らの力が無ければ常識的な時間では終わらなかった仕事だった。
残念だったのは彼らの優秀さの割に一般のエンジニアのスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。
そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。
もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社(厳密にはその親会社に)に買われることになった。
そういう時に起ることは不要な冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署が相手側にも存在するということだ。
つまりどちらにもある部署は統合するか一方を無くすかという戦争が始まるのだ。ITも例外ではない。(ITインフラ部署の無い会社はさすがに無いはずだ)
一方で製造業の本懐である「製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存の顧客への説明が必要だからだ。
そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか。
(ここで簡単のために旧弊社を(旧)A社、買収した側の競合他社を(旧)B社と呼ぶことにする。)
今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である。
旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフが簡単に表示され、A社側のお偉いさんからも好評を得ていた。
だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。
そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉だ
「増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ?」
もちろんhtmlもjavascriptもphpもRoRも一行も書いたことが無いのが当時の私である。
果たして旧A社のプラットフォームはB社のプラットフォームのデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。
そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。
クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベルで筆舌に尽くしがたいものがあるが、
反面教師だと思って耐える日々だ。
最近分かったことは旧B社のバックエンドスクリプトがデータを引っ張るついでに意図的に旧A社のプラットフォームを攻撃しているということだ。DDoSとまでは言わないが、悪意100%である。
いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。(つまり旧A社プラットフォームが不安定かつ重くなることを意図しているらしい)
旧A社から継続されてる業務はまだそこ使ってるんですけど・・・
それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。
旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える(私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングのレベルが二回りぐらい違うように見える)
と http://anond.hatelabo.jp/20170402213435 の元ネタの基礎的な数字を将来ググってたどり着く人のために
カテゴリ | ユニークページ数 | 延べページ数 | 公開ブクマユーザー数 | 総ブックマーク数 | 公開ブックマーク数 | 公開ブックマーク率 | コメント人数 | コメント数 | コメント率 | 平均ブクマ数/人 |
---|---|---|---|---|---|---|---|---|---|---|
世の中 | 1,181 | 1,372 | 15,367(38%) | 140,849 | 115,450 | 82% | 7,486 | 53,547 | 38% | 7.5 |
政治と経済 | 1,053 | 1,298 | 12,871(32%) | 89,430 | 72,334 | 81% | 5,613 | 28,893 | 32% | 5.6 |
暮らし | 1,155 | 1,372 | 23,120(57%) | 152,296 | 121,042 | 79% | 9,368 | 51,520 | 34% | 5.2 |
学び | 698 | 910 | 15,998(40%) | 69,583 | 53,234 | 77% | 5,173 | 14,356 | 21% | 3.3 |
テクノロジー | 1,107 | 1,372 | 23,152(58%) | 190,227 | 148,808 | 78% | 8,191 | 32,195 | 17% | 6.4 |
おもしろ | 433 | 531 | 7,376(18%) | 27,011 | 21,935 | 81% | 3,540 | 9,997 | 37% | 3.0 |
エンタメ | 709 | 874 | 12,464(31%) | 63,786 | 50,961 | 80% | 5,690 | 20,693 | 32% | 4.1 |
アニメとゲーム | 900 | 1,137 | 12,705(32%) | 79,822 | 65,237 | 82% | 5,882 | 25,755 | 32% | 5.1 |
合計 | 7,236 | 8,866 | 40,240(100%) | 813,004 | 649,001 | 80% | 16,156 | 236,956 | 29% | 16.1 |
おまけ
カテゴリ | ユニークページ数 | 延べページ数 | 公開ブクマユーザー数 | 総ブックマーク数 | 公開ブックマーク数 | 公開ブックマーク率 | コメント人数 | コメント数 | コメント率 | 平均ブクマ数/人 |
---|---|---|---|---|---|---|---|---|---|---|
はてなブログドメイン | 636 | 786 | 19,128(48%) | 82,585 | 65,261 | 79% | 6,992 | 21,637 | 26% | 3.4 |
2010年3月5日、シストロムはベースライン・ヴェンチャーズとアンドリーセン・ホロウィッツの2社からの元手資本としての財政支援、50万ドルの資金調達を終えた。(Wikipedia)
2010年8月22日 08:44:06 ファーストブックマークを獲得 http://b.hatena.ne.jp/entry/instagr.am/
2010年10月6日 アプリの初版がアップルのApp Storeに登場した。(Wikipedia)
2010年10月6日 21:36:56 おそらく2番めのブックマーク獲得
2010年10月10日 17:41:49 おそらく3番めのブックマーク獲得。初のコメント「ただの馴れ合いの空間になっていて残念。」
2010年10月14日 11時頃からブックマーク急増。同日15ブクマを集める。
2010/10/16 21:36 instagram.comへのファーストブックマーク http://b.hatena.ne.jp/entry/instagram.com/
2010年10月24日 写真コンテンツへの初めてのブックマーク。3ブクマを集める。削除済み。
2010年11月 写真コンテンツへのブックマークが盛んに行われるがどれも3ブクマで止まる。
2011年1月 TechCrunchの2010年ベスト・モバイル・アプリに選定(Wikipedia)
2011年2月8日 API公開。ブログと開発ページがそれぞれ50ブクマくらいづつ集める。
2011/02/25 10:30 stagram APIサイトへのファーストブックマーク
2011/03/17 21:24 instagram.comドメインの写真コンテンツへのファーストブックマーク http://b.hatena.ne.jp/entry/instagram.com/p/CTW2m/
2012年3月19日 257ブクマを集める写真が出現。史上唯一の100ブクマ超えインスタグラム。http://b.hatena.ne.jp/entry/instagr.am/p/IWrF0rCp62/
2012年6月 instagr.amドメイントップページへの最後のブックマーク
2012年秋 instagr.amドメインへのブクマが激減、instagram.comドメインにブクマする人が増える
instagram.comドメイン以降16万以上の写真がブクマされるが、3ブクマ以上された写真は180に満たないようだ。3ブクマ以上は旧ドメイン、新ドメイン同じくらいの数。
本来伏せ字にでもしたほうがいいのかもしれませんが最早そんな意味もないくらいに広まってしまっているので普通にフリーブックスと書いていきます
更に一応書いておきますが日本の漫画市場を潰しかねない悪質なサイトです、利用するのは絶対に辞めましょう
と言ってもそんな綺麗事を書いた所でもうどうにもならないくらいに多くの人が利用しているようなのでここからフリーブックスとは一体何なのか?なぜこんなサイトが存在出来るのかなどについて書いていきます
「自作の漫画コミック・雑誌・同人誌・小説を自由に投稿し皆で共有&読み放題にできるファイル投稿共有サイト 」
とのことです
まずフリーブックスには自作ポエムのような作品は一切ありません
理由は簡単でアップロード機能がないからです、アップロードというページはありますがこれはただのハリボテです、実際に自作ポエムをアップロード出来た人間は存在しません
つまり投稿共有サイトというのはただの建前で完全に一方通行、作品をアップロードしているのは全て運営です
そこから違法にアイテム(作品)数を増やし続け2016年の終わりには2万5千件ほど、現在は5万2千件ほどになっています
アップロードされている書籍の種類は漫画コミックス・漫画雑誌・一般雑誌・小説・その他書籍・主に18禁の同人誌、同人作品で、全体の7割以上は漫画のコミックスです
ネット上では「品揃えがスゴイ」という声がありますが、こういう言い方が正しいかは分かりませんが違法な割れサイトとしては別に凄くはありません
残念なことに現在web上では多くの書籍が違法に流通しておりフリーブックスにアップロードされている作品も全てそういった違法サイトからの2次利用です、おそらくフリーブックスが1次流通元となっている作品はありません
他に「雑誌まであるのがスゴイ」「発売日にはもう上がってる」「マイナーな書籍まである」という声もありますがこれらも全てフリーブックスに特有のことではありません
他の違法サイトにも雑誌はありますし、発売日には違法アップロードされています
マイナー書籍はおそらくamazonの読み放題サービス「Kindle Unlimited」から流用しているものと思われます
フリーブックスは今までの海賊版サイトとは違い非常にカジュアルな見た目です
UIもよく出来ていて、レスポンスは速く、モバイルにも最適化されているのでスマホ世代にとっては非常に使いやすいでしょう
加えて本屋大賞作品特集などの特設ページまであり、トップページを一見しただけでは違法サイトだと分からないくらいのデザインです
漫画の閲覧に対してダウンロードなどの行為を挟まないため罪悪感が薄くある意味お手軽に漫画が読めてしまいます
フリーブックスの利用者には違法サイトであることを認識していない人さえいるかもしれません
フリーブックスは2017年に入るまでは殆ど無名のサイトでした
今年の1月頃からポツポツと話題になりはじめ、3月の中頃から現在にかけて一気に普及している感じです
1/02 知恵袋でサイトの合法性について質問された(現在質問の閲覧数は260万)
1/15 twitterでつぶやかれた(以降つぶやきは増え続けています)
3/12 2ch(なんJ)でフリーブックスを話題に扱ったスレッドが建てられた(以降スレッドは頻繁に建っています)
4/28 NAVERまとめでまとめられた
4/30 はてな匿名ダイアリーで話題にのぼった(この記事ではありません)
webサイトのトラフィック量(閲覧数と考えて下さい)を監視している企業Alexaによれば現在フリーブックスのトラフィック量は世界9286位、日本342位です
116位 読売新聞
180位 ピクシブ
342位 フリーブックス
但しフリーブックスは今年1月に世界ランク100万程度だったものがたった3ヶ月で99万ほどもランクを上げトラフィックが増大しています
本当にタケノコの成長のようなごぼう抜きです、こんな増え方はサービスとしては日本で言うなら黎明期のニコニコ動画くらいでしょう
このまま同程度の伸びを示せばあと1ヶ月ほどで読売やNHK(日本80位)のニュースサイトよりも日本人がよく見るよく使うサイトになる可能性があります
しかし増えているとはいえトラフィック量に対してtwitterやweb上の反応が少ないのも事実です
これはおそらくですが、さながら90年台のポケモンやドラクエの裏技のように友人から友人へ口伝にてフリーブックス伝説が広まっており見た目以上に全国のお友達が使っているのだと考えられます
twitterでつぶやかれる「学校のみんなで使ってる」「大学のみんな知ってた」などのつぶやきからもそう推測されます
同じような形態で成年コミックや同人誌を違法アップロードしている「ドロップブックス」というサイトと同じ運営者であり他にもいくつか日本人向けのアダルトサイトを運営しているということです
同一人格が保持していると思われる他のドメインのWhois登録情報によればヴァージン諸島に存在する、おそらくペーパーカンパニーによって運営されていることになっています
但し、当初のフリーブックスのIP割当地はブルガリアでしたが現在のフリーブックスは増大するトラフィックに対応するため4月中頃からアメリカのCDNサービスであるCloudFlareを使っており直接は分からなくなっています
運営者の個人情報について国籍や住所はまったく分かりません、日本語の巧みさから日本人もしくは日本語ネイティブである可能性が高いですが、もちろんそうでない可能性もあります
ちなみに(.is)はアイスランドのドメインですがおそらく特に関係ありません
運営者を逮捕するのは非常に難しいと思います
まず運営者の実態が分かりません、更に世界にはタックスヘイブンならぬコピーライトヘイブンなるものがあり、そういった著作権の曖昧な場所で
"外国在住"の"外国国籍者"が"外国のサーバー"に対してアップロードを行っている場合、論理としては外国に建てられたでっかい図書館の中を大量の日本人が双眼鏡で覗いてるだけともいえます
これでは逮捕理由がないとまではいいませんが、積極的に動くのが非常に難しいといえます
但し前述の通り海外サーバや海外法人を経由し身元を隠しているだけの日本人である可能性も高くなんともいえません
一応運営者が外国国籍者でもその身元さえ判明すればカリビアンコム方式をとる方法もありますが、これは賛否両論かつ別の問題があり後述します
ちなみにフリーブックスを紹介しているサイトの紹介文にはYouTubeと同じような形態だから逮捕出来ないと書いてある所もありますが
最初に書いた通りフリーブックスのアップロードシステムは見せ筋みたいなものでその実態はないですし、削除フォームもまず間違いなく機能していません
少なくとも3月以降はフリーブックスにアップロードされ著作権者の申請によって削除された作品は存在しないと思われます
つまりフリーブックスに対してバカ真面目に削除申請するのは電話線の切れた受話器にむかってもしもしとつぶやき続けるようなものです、意味がないので推奨出来ません
「なぜそういい切れるのか、お前は漫画の作者で申請したのか?」と思われるでしょうが
根拠としてはweb上で見れる出版各社や著作権者のDMCA侵害申し立ての山があります
ややこしい説明は省きますが、現在web上で著作権者が海賊版を見つけた時に最もよく行われるアクションが上記のグーグルに対するDMCA侵害申し立てです
これを行うことによってグーグルが該当ページを検索結果から村八分してくれます
実際フリーブックスに対しては出版社も既にその問題を認識しているようで
小学館集英社講談社の御三家をはじめ大手出版社や海賊版対策を業務とする一般社団法人コンテンツ海外流通促進機構がDMCA報告を連発しています
他にも同人誌の著作権者などがDMCA報告しているようですが、その全ての作品が3月以降一つの例外もなく一切フリーブックスから消えていません
誰か一人くらいは削除フォームから申請してみた人がいるはずですので、これが消えていないということはやはりそういういことなのだと思います
但し勘違いの可能性もあるので「俺はフリーブックスに削除申請したら消えたよ」という方がいれば教えてください
カリビアンコムとはアダルト動画サイトです、明らかに日本人向けのサイトで中身も日本人女優が出演していたのですが
「"外国在住"の"外国国籍者"が"外国のサーバー"に対してアップロードを行っているため合法です」と公式サイトで堂々と主張し運営されていました
しかし紆余曲折あり運営者の一人が逮捕されました、紆余曲折については調べて下さい
問題は逮捕された場所が沖縄だということです、カリビアンコムの運営者は外国国籍で外国在住だったのですが何の用事か沖縄へノコノコやってきてそこで捕まりました
ちなみに他の運営者については捕まっていません、つまりフリーブックスについても運営者が外国国籍者だった場合、外国にいる限り逮捕は難しいと思われます
更にカリビアンコムはその性質上、コンテンツの制作に場所が必要でそのコンテンツ制作者(つまりスタッフや監督)からサイトの運営者まで金銭授受なりの線を伝って特定すること可能でした
しかしフリーブックスはweb上に散らばっている違法アップロード作品を収集して自サイトで公開しているだけなため身元の特定が容易ではないと思われます
加えてカリビアンコムの逮捕劇については日本の法曹関係者からもその正統性について疑問の声が出ています
警察管轄のアダルト案件についてさえこれですから著作権という、より曖昧な案件でどこまで出来るのかは大いに謎です
「サーバー運営者とか中間業者に公開をやめさればいいのでは?」という声もあると思いますが
これはある意味その通りで現在先程出てきたアメリカ企業のCloudFlareは
「違法サイトの運営者がCloudFlareのサービスを利用することを積極的に断らなかった」つまり海賊版サイトの運営を間接的に助けているという理由で複数の企業から訴えられています
但しCloudFlareを使えなくなったからといって即閉鎖されるかというとそんなことはないでしょうからやはり難しい問題ではあります
長い年月で見れば、運営者の居住地や身元が完全に割れ金銭の動きが分かり現地行政や警察権力の協力が得られれば可能だとも思います
しかし現実的には難しいでしょう、世界最強のコンテンツ団体であるハリウッドでさえこういった問題に対しては根本的解決は出来ず正規の配信ビジネスを発展させるなど別方向で対応していきました
ハリウッドに出来ないことを日本の出版業界にやれというのも酷な話だと思います
「え、じゃあ本当にこんな違法サイトがずっと存在するの?」と思われる方も多いと思いますが
そこは運営者のモチベーション次第、つまりフリーブックスというサイトで儲けられるか?というところに尽きると思います、これは後述します
ただそうは言っても運営者がまったく儲けを考えることなく運営を続けた場合でも取れる対策があるにはあります
一つには国内プロバイダと協力してフリーブックスのドメイン自体を遮断してしまう方法です
そんな馬鹿なと思うかもしれませんが、この方法は実際にイギリスで運用されており非現実的とまではいえません
抜け道はいくらでもあり根本解決にはなりませんがPCに疎いライトユーザーを筆頭にかなりに利用者を遠ざけることが出来ると思われます
ちなみに目には目を方式でDDos攻撃なりを仕掛ければいいのでは?と思う方もいるでしょうがCloudFlareはDDos耐性が強いのが売りですしそもそもそういった行為は違法です
違法サイトを潰すために違法なことをして人生を棒に振りましたというのはまったく笑えない話なので絶対に辞めておきましょう
フリーブックスには現在、広告がありませんがこのまま何の見返りもなく運営が続けられるとも思えません
似た形態で同じ企業によって運営されているドロップブックスについては広告により運営されていますので、いずれ広告がつくかもしれません
事実フリーブックスにはごく短期間にではありますが、ビューアーの読み終わり部分に広告がついていたことがあるようです
広告が付けば金銭の流れがわかりますし、広告を出稿している企業に対してクレームを入れることも出来ます
ただドロップブックスには誰でも知っている有名企業の広告もあるのでそれが有効かどうかまでは実際の所分かりません
そもそもドロップブックス自体がいつまで経っても潰れないという問題もあります
フリーブックスは今年の3/16に突如、短い時間ではありますが有料会員サービス化したことがあります
その時のプランは以下の通りです
この時は数時間で元の無料サイトに戻ってしまったのでこれが何だったのかについてはよく分かりませんが
但し全ては推測であり、もしかしたら有料化以前に数時間後にはドメインごと消えているかもしれません
最初に書いた通り最早、臭いものには蓋方式で隠しても意味がないくらいに広まってしまっているので記事を書きました
いっそ逆にもっと広まって社会問題化してそうそうに潰れてくれればいいのにとさえ個人的には思います
「ライター」という立場からアフィリエイトを揶揄にするのはズルいと思う
http://pepera.hatenablog.com/entry/2017/03/31/222954
これを要約すると。
単純に金が欲しくて勧めているアフィカスが嫌われる理由はわかる。
でもそれってクライアントからお金(広告費)貰ってる立場の人ならみんな一緒じゃん?
そもそもクライアントがPR記事依頼する理由はSEOのためだよね?
アフィメディアにPR記事書いたら間接的にアフィに加担してることになると思うんだけど。
↑ここまでは分かる
↓ここから飛んでない?
>だけど、アフィリエイトだったり広告で食べてる会社から、グーグル対策としてそれなりのお金をもらっておいて、「僕の記事はアフィリエイトリンクじゃないので安心してください!」と聖人ぶるのはズルいことだと思うんですよ。
>笑えるのは、そのPR記事を執筆したメディアの運営元がアフィリエイトサービスプロバイダ(通称ASP)を運営する会社だというw
ここで言うメディアってSPOTの事なんだろうけど、今回のクライアントはタイムズだよね?
ヨッピーに執筆依頼したのも、SPOTに記事広告出稿したのもタイムズなのに、SPOTからヨッピーに依頼があるように読めるのは俺だけ?
これが幽霊脱毛やナース素材みたいに自ドメインのSEO優遇のために依頼されてるならこの言い分は分かるけど、今回ヨッピーが担当したのって記事だけでしょ?
すごいモヤモヤする。
http://xn--e--0g4awc3c1451cnh5a.com/yuurei/
スキマナース
AeGate株式会社
株式会社ジーニー
スペシャリストがいるからこそ可能になる自作によるデータセンター。
また臨機応変な対応から、弊社独自のプランもたくさんご用意しております。
お仕事内容 弊社運営ポータルサイトの簡単な作業をお願いします
≪未経験者でも歓迎≫「IT業界に興味があるけど専門知識も技術もないから…」
「やりたいことはあるけど、未経験者で採用してくれるところはどこもないし…」と応募を諦めている。
当社はそのような仕事の経験がある・ないは問いません必要なのはアナタの「インターネットが好きだ」
「何かサイトを作りたいからいろいろ勉強したい」という気持ち!⇒そんな気持ちを持っていれば大歓迎!
https://twitter.com/piyokango/status/844361226767380481
http://www.freezepage.com/1490165400GAZZVSXBDT
である。キャッシュの freezepage ですまんが、まあいいだろ。
これ自体はハセカラ界隈のスクリプトキディが show tables かなんかを実行する jsp 一枚仕込んだというだけの話なのだと思うが、問題は JINS の対応だ。
t_jins_gmo_brandtoken_cancel_if_rireki
t_jins_gmo_brandtoken_change_if_rireki
t_jins_gmo_brandtoken_entry_if_rireki
t_jins_gmo_brandtoken_exec_if_rireki
などといったテーブル名から、おそらく GMO ペイメントトークン決済を利用しているものと思われる。これはクレジットカード番号を一切 JINS 側のサーバーに通過させなくていいような構成になっており、今回のこの事例から JINS 側が保存していたクレジットカード情報が流出した可能性は、恐らくない。
しかしながら今回攻撃されたドメイン https://www.jins.com/ にはクレジットカードの入力ページが存在している( http://s.ssig33.com/gyazo/d09c0f5915f84eab8c8712eb0d23150d )。
この為、こうしたページも不正に改造されていた場合、攻撃を受けていた期間に入力されていたクレジットカード番号が不正に流出している可能性がある。
ところで JINS 側はこうした問題を認識して今朝未明にメンテナンスを行なっていたようである( https://www.jins.com/jp/news/2017/03/322.html )。
推測するに、調査をしたところクレジットカード番号入力ページの jsp なりなんなりが改竄されていた事実はとりあえず確認できなかったので、特になんの発表もしていないのであろう。ところで JINS は 4 年前にもサイトをクラックされクレジットカード番号を流出させた経験がある( https://www.jins.com/jp/illegal-access/info.pdf )。にも関わらずこの対応はちょっとおざなりすぎではないだろうか。
現実に可能性は低いと思うが、例えば以下のような可能性が考えられる。
1. ハセカラ関係者っぽく見せかけた低レベルのクラック ↑ を行なう。
2. その裏でクレジットカード番号入力ページに本気のクラックを仕掛ける
3. 1. でしかけたハセカラクラックが露見する前に 2. のクラックについては撤収して 1. の証拠だけを残しつつ 2. の証拠を消す
このようにすることで、クレジットカード情報を収集していたという事実を関係各位に認識させる時間を可能な限り遅らせ、不正な買い物などをする時間の余裕を稼ぐことができる、かもしれない。もちろんこんなことが行なわれた可能性はほとんどなくて、事実はバカなスクリプトキディが適当に遊んでいただけなのだと思う。しかしこの可能性を無視していいとは思えない。
こうした可能性について調査するには 7 時間では全く足りないし、あるいは一度外部に大々的に告知をしてサービスを停止するなどの対処も必要ではないか。
JINS は 4 年前のクラック被害から何も学んでおらずユーザーデータや資産を防護する基本的な姿勢が欠けているとしか思えない。
オーナーチェンジを装って削除依頼フォームを英文にしたりしている違法エロマンガアップロードサイトのdropbooksだが、同じものがホスティングされているbestreams.netは、WaybackMachineだと2016/9/11付のアーカイブからdropbooksになっているがその前2016/07/02までは英語でXVIDEO動画あたりを流しているBESTREAMS(ロシア語と英語)となっているので、間は開いているものの、同一グループの可能性が大きいと思う。空白の2カ月の間にドメイン譲渡でもない限りは外国人グループに日本人が加わっていると見るのが適切か。
ライブドアブログの一部ドメイン(http://blog.livedoor.jp/)がはてなからペナルティ扱いにされたっぽい。
http://b.hatena.ne.jp/entrylist?url=http%3A%2F%2Fblog.livedoor.jp%2F
はてなはペナルティ扱いにすると、ブクマがいくつつこうがエントリーには表示させないし、サムネも取得しなくなる。
痛いニュースもホットエントリー、新着に出てこなくなった。小飼弾までペナされてるっぽいな。
はてなはトップドメインでペナルティを管理してるんだな。ブログサービスを使ってる人は巻き込みペナルティに気をつけたほうがいいかもね
追記
運用なので実装や開発ということもなく、何かシステムに修正があればテスト、というような感じ。
先輩はいい人で色々教えてくれるので、勉強になるからその点はうれしいのだけれど、
やっぱり運用プロジェクトというせいかモチベーションが上がらない。
最近は毎朝起きるのも遅い。
以前は出勤時間の3〜4時間前に起床して、好きなプログラミングをしたり
会社に入ったばかりでやることはどれも新鮮。
少し難しい仕事も任されるようになってきてモチベーションもあったと思う。
それが今では不思議と朝起きたくないのだ。
起きるのがつらいというか億劫。
別に疲れが溜まっているわけではない。
目覚めは悪いどころかいつも目はぱっちりしている。
でも起きれない。ぎりぎりまで布団の中。
そして時間ぎりぎりになると焦燥感を感じつつのっそり布団から起き上がる。
この状況を打破するにはたぶん運用プロジェクトをやめるしかないのだろう。
今ではどうせ朝早く起きれないなら深夜までずっと起きていようか、なんて考えている。
会社をやめていく同僚にも言われたが、運用やってるとだれてくるらしい、私生活が。
今では職場でも私生活でもいきいきしている。うらやましい限りだ。
自分はフリーランスにはなろうとは思わないけども、少なくとも今のプロジェクトは半年が限度かなーとは思ってる。
それに自分の市場価値はどんどん上げたいと思っているし、会社だけでなく会社の外でも評価される人間になりたい。
そういう意味でも今の運用プロジェクトに長く関わるのは、正しい選択ではないように思う。
運用プロジェクトの残念なところは、仕事の大半が顧客対応のコミュニケーションコストでつぶれること。
特にお硬いお客さんだと本番作業をする度に、申請書類を書いて作業日の何日か前に提出しなければならないだとか。
障害対応であれば書類に発生日時や発生事象、発生原因、顧客影響、業務影響、対応策、横展開対応、再発防止策、etc..
なんてことをつらつら書かなければいけなかったり。
なにより障害が発生したらものによっては休日にも出勤しなければならないこと。
まぁ自分はその経験はまだ一度もないけども。ただ障害が起きて帰りが遅くなった時は本当に疲れる。
体力には自身があるけども精神的にはわりときます。人によるのかな?
つらつらと運用プロジェクトについてネガティブな事を書いたけども、悪いことばかりではない。
運用プロジェクトでは顧客対応が必須だ。なので顧客との話し合いは上手くなる。
例えばフレームワークの脆弱性が発表されれば、どの程度影響があるのか、どのような対策を取れば十分か、そもそもどんな対策がとれるのか、とか。
ハードウェア、ミドルウェアに障害が起きればそれに対する知識を駆使して対応を行う必要があるし、
ドメインが変わった、IPアドレスが変わった、となればシステムの運用や保守作業で影響がないか調査する必要がある。
他にも必要な知識として、プログラミング言語とSQLはそこそこかけて、DBクライアントやLinuxの操作、その他ミドルウェアの知識も必要になる。
なので現時点では自分のスキルはそこそこ伸びてはいるのかなーとは感じている。
理想は運用プロジェクトで吸収できるものは吸収していって、早めに別プロジェクトに移っていきたいですね。
https://hyper-text.org/archives/2014/07/gmail_alias.shtml
エイリアスを受け付けてくれるサービスであれば、普通は(精確には100%)そのまま宛先として送ってくれます。その場合は、必ず受信トレイに振り分けます。そうでないサービスであれば、特に何もせず普通に受け入れます。すると、ブログ主さんのような考えを催したスパマーさんは、わざわざ迷惑メールフィルターが有効で、送ってくる人がごく限られている宛先(ゼロエイリアス)に送ってくれることになります。
そのように思ってしています。当然、スパマーさんが必ずそのような神経質な処理をするとは限らないですし、こう考えますと、流出元の特定につながる可能性は、五分五分なのではないでしょうか?
エイリアスを勝手に置き換えられるということも考えられますが、乱数ならそういうわけにはいかないでしょうし、個人を標的にするのでもなければ、そのようなことをするということも考えられません。
また、もし本当にRFCを知らないのではなくエイリアス対策として行っているのであれば、なぜそのようなエラーメッセージを返さないのでしょうか?
普通のメールアドレスが既に登録されている場合は、既に登録されているアドレスですと表示されるのが普通ですから、プライバシーやセキュリティー上も問題は起きないはずです。
実際にそのような使い方をしているわけではないのですが、流出元が明らかなスパムメールが届き始めて以来、何となくそうしています。少なくとも精神衛生上有意義なことで、ブログ主さんがこのような批判記事を書かれるのも、そういう人間に対する純粋なトローリングなのかなと勘繰ってしまいます。冒頭も、「知識」というよりは推論の問題ですので、人を挑発する気満々の野卑なワーディングに感じます。
ヤフーのことは知っていてもOutlookのことは知りませんでしたし、四種類くらいあるドメイン名を統一できるというのは興味深いです。
が、ヤフーはベースネームが一つしか設定できないのでしたら、ベースネームが本物のメールアドレスと同等の価値を持ってしまうのではないでしょうか。「ある程度固定される」というレベルは超えていると思います。
名前の部分が自由に取得できてしかもどのサービスにもドメインごと弾かれることのない、1GB程度は無料で使える優良のウェブメールがどこかにあればよいのですが。
……って書きこもうと思ったけど投稿できなかったのでここに保存しておく。
この話は、途中で「危ない」の意味がすり替わっているので混乱してるんじゃないかな?
これが許可された場合に攻撃の危険性にさらされるのは「リクエストを受ける側」のサーバだ。
この場合、攻撃者である可能性を持つ「リクエストを投げる側」は不特定多数である。
2. <script src="">なら他ドメインも取れるよ ← まあわかる
3. じゃあここを動的に変えて、実体はスクリプトファイル(JSONP)で関数呼んでデータ貰おう ←!?
関数実行しちゃってんだぜ?
これが許可された場合に攻撃の危険性にさらされるのは「リクエストを投げる側」であり、先ほどとは攻撃者と被攻撃者が逆転している。
この場合、攻撃者である可能性を持つ「リクエストを受ける側」は、「リクエストを投げる側」が明示的に指定したサーバだ。
この問題は信用できないドメインに対して自分側からリクエストを送らないようにする、という明確な対策が可能である。
JSONPは、「リクエストを受ける側」にとってXMLHttpRequestでWebAPIを叩かれるよりも安全だからドメインを超えた通信が出来るわけ。
つまりこういうことね。
【XMLHttpRequestの危険性 (実際にはこの動作は禁止されている)】 ブラウザ←ーーー「攻撃者WEBサーバ」(悪意あるリクエストを投げるコードをブラウザに渡す) ーーー→「被攻撃者WEBサーバ」 (悪意あるリクエストに答えてしまう) 【JSONPの危険性】 ブラウザ←ーーー「WEBサーバ」(攻撃者WEBサーバへリクエストを投げるコードをブラウザに渡す。※このサーバは、攻撃者WEBサーバに悪意があることを知らない) ーーー→「攻撃者WEBサーバ」(レスポンスとして悪意あるコードをブラウザに渡す) ブラウザ←ーーー (悪意あるコードを実行してしまう)