「クローズド」を含む日記 RSS

はてなキーワード: クローズドとは

2017-02-18

はてな感想雑記ブログをやってた

少し前まではてな感想雑記ブログをやってた

それを嫌気がさして消して、「あーあ、ブログ無かったらもう感想文なんて書かないだろうな」と思ってた

そしたら今ではせっせとファンレターもしくはファンメールを書いて作者に送ってる

書いてるじゃん、書きたいんじゃん

文面をEvernoteに打ち出すところまでは同じ

それを紙に書いて切手貼ってだすか、もしくはアドレス打って送るかどうかの違いだけ

手を変え品を変え「あなた作品のここが好きです。なぜならこうだからです」と言葉を探して当てはめるだけの事がどうしてこんなに楽しいんだろう

ただこれ、作者と私という一対一かつクローズド手段からこんなにも今楽しめているわけで

やっぱり私と作品との感想を、ブログ記事にして不特定多数の人に公開するのは間違ってたよなあなんて思う

少なくとも、私の感覚では長く続けられないことだった

私のブログをいつも読んでる、面白いって言ってくれた人もいたけどさ……なんかそれ思い出す度に申し訳なくなってしま

ネット上で固有の名前を名乗って、居場所を作ろうとするのを諦めただけだから

私はずっと何かの感想文を誰かに対して書いてるから

から、あの時唐突ブログを消してしまってごめんなさい

毎日アクセスしてくれてありがとう、私は何も変わらずにこの世界の片隅で生きてます


あと、はてなブログはやっぱり書きやすかったよ

Amazon画像リンクとか、iTunes試聴音源の挿入とか、そういうのすごく簡単で楽だった

2017-01-04

http://anond.hatelabo.jp/20170104112443

コミュニティの中で気の合う人とLINEグループとかSlackチャットとかクローズドサークル作って、友達の友達ぐらいまでは誘ってOKぐらいにする、たまにそのメンバー飲み会とかする

そういうのがユートピアに近い

ただ、これもだいたい寿命は2年ぐらい、サークラ女が入ってきたりとか、メンバーの中で病む奴が出たりとかでいずれ分裂する

でも、また別のを作ればいい

何にしても固定的にユートピアみたいなことはないので、面白くなくなったコミュニティからは抜けるほうが健全

2016-12-25

同人サークルの糞案件の話

以前見かけた同人界隈の糞案件について書く。

当事者でない自分がいろいろ書くのはどうかと思っていたが、この件についてはだいぶ時間が経っている。流石に時効だろう。

①大まかな経緯

SNS経由で知り合ったらしい創作仲間が、姫的存在の売名を兼ねてイベントに共同名義で作品を出す

サンプルが作品参加者の手元に届く

参加者の一人が公表されていなかった作品の中身を勝手SNS拡散

それを見た中核メンバーSNS上で公開非難

勝手に公開した参加者ネットから消滅

これが発生したのは、とあるイベント開催日の直前だ。

②何が糞か

この案件が糞な点は大まかに分けて二つある。

・非公表のもの勝手に公開しちゃまずいだろ、少しは考えろやっていう点

SNS上で公開内ゲバとか、自分たちの作った作品自分ケチつけてどーすんだよバカっていう点



1つ目は言うまでもない。

単純に作品への敬意がないし、先のことを考える能力もなかったのだろう。

お前の脳味噌中身ただの味噌なの?毎日その味噌味噌汁作ってるからどんどん中身減ってんの?

ちゃんとスーパー味噌補充してから出直してこい。そんなもんでも空っぽよりはマシだ。




問題は2つ目だ。

普通なら、その手の話は直接連絡を取り合うか、SNS上でするにしても極力クローズドな形をとるのが大人のとるべき対応だろう。

しかしこの中核メンバーは、あろうことか誰にでも見える状態で、自分いか不快な思いをしているかをやたら強調しながら相手ボッコボコ非難した。


いか?その作品宣伝していたのと同じアカウント内ゲバを全世界に公開したんだぞ?


たぶんこいつの脳味噌は腐ってる。もともと発酵食品味噌さらに腐っているのだからもはや手の付けようがない。


この手の連中は、口では作品がどうとか常識で考えるとどうとか言いながら、実際に頭の中にあるのは見栄だけだ。

「こんな大変な仕事引き受けてやり遂げちゃう俺様かっこいい!」とか、あわよくば姫的存在を手籠めにしたいなんて妄想欲望が頭の中で糸ひいてネバネバしてる。


その妄想が満たされるためには他人の事などお構い無しだし、邪魔者が現れればふつうじゃ考えられないようなやり方で騒ぎ立てる。要は精神年齢が低い。


本来であればこの手の厄介者は、能力や貢献度にかかわらず排除しないと新規流入者も減るしサークルの活性そのものが弱くなってしまうのだが、なまじ作品の完成に深くコミットしまっただけに周りも何も言えないのか、当時そいつ非難されている様子は全くなかった。

最近の事は詳しく知らないが、今でもそのサークルに居座っているようだ。



というか、ネットから参加者の一人が消えたことにすら皆沈黙を守って、誰も何もコメントしなかった。

結局のところ、誰も厄介事には首を突っ込みたくなかったのだろう。




当時自分作品への参加を誘われた一人だったのだが、サークル雰囲気の胡散臭さがどうしても気になって断ったという経緯があったので、この件を見た時は「こいつらに関わらなくてよかった」ってのが正直な感想だった。

ちなみに、その姫的存在には「売名したいならこんな糞サークル邪魔しかならんから解体した方がよい」とアドバイスしたのだが、結局今現在もそのサークルは存続している。



年末の某行事が近づいてきて、ふと「こんなこともあったなぁ」と思い出して書いてみた。

サークルには関わらないのが1番って話。

2016-12-06

研究室ホワイトボード

Twitterのアレを見ててわかると思うけど理系大の研究室に入ったら周りはオタクだらけで、アニメネタ日常会話になる。

それは良い。一方で、アニメネタを話す人達はほぼ必ずSNSヘイトネタ日常会話で繰り出してくる。

アニメを見ている=SNSヘイトリアルで口に出すことに抵抗がない というのは、少なくともうちの研究室では常に成り立っていた。

SNSの言説が、そのままリアルに流れ込んできても許される空気理系大のクローズドコミュニティではすぐに成り立ってしまう。

「ま〜んはマジで死ね」なんて隣の席で言い合ってる奴らが居るのは、至って普通で、それを咎める言葉なんて無い。

それを咎める文脈は、全然別の世界人達しかもってない。我々特に関係の無い人間は、客観的に見て唾棄すべきであるような、暴言を聞き流すしかない。

あのホワイトボード楽しいお喋りを現実に隣でずっと言っているやつが居たら、というリアリティをぜひ想像してみてほしい。辛かった。

2016-12-01

2016年インターネットが終わった年かもしれない

welq問題を眺めていていろいろ考えた

医療情報に限らず、今のWebゴミ情報が多すぎる

ほとんどのキーワードSEO業者が作ったパクリデマ記事が上位に入ってくる

検索結果の1ページ目が業者で埋め尽くされていて、Wikipediaけが唯一まとも、という状況がほとんど

そしてそのWikipediaも信頼はできない

相対的に見てマシといった程度だ

これはGoogle検索アルゴリズム改善すれば終わる問題か?と言えばそうじゃないと思う

新しいアルゴリズム業者がすぐに解析してゴミで埋め尽くされるだろう

これはもう「検索」という方法オワコンなのだと言わざるを得ない

メールスパムだらけになってLINEなどのメッセンジャーに移行しつつあるのと似ている

若い世代を見ると、もうインターネットに見切りを付けているような気がする

クローズドSNSで仲間内とだけやり取りし、情報収集Instagramでやる

文字を書かずにプリクラみたいな写真しかあげないし、Web記事じゃなくてDマガジン雑誌を見るし、動画じゃなくてテレビの見逃し配信を見る

90年代からインターネットに触れている人間として、時計の針がギューンと戻された気分だ

もうインターネットは終わったのかもしれない

今の新聞が老人しか見ないように、インターネット特定世代しか見ない終わったメディアになっていくのだろうな

2016-11-03

http://anond.hatelabo.jp/20161102235219

リベラルのほうが耳触りのいい言葉が並んでてわかりやすいからな

から右翼的思想匿名性が高いクローズドなところに流れ落ちていく

2016-09-28

http://anond.hatelabo.jp/20160928133223

多様性への理解なんて脳のリソース食うばかりで、自分に益するところが少ないもんな。

建前として理解しておくのは悪くないけど、

実際には人生の大半は身近な人間関係クローズド空気で決まるわけで、

その辺弁えて、「多様な価値観を認める」という理想主義的な思考封印していかんとね。

ギルティ伊藤君、新聞沙汰までの想像

1.休暇申請

伊藤君(A君とする)シルバーウィーク飛び石を繋げれば17(土)~25(日)まで9連休になることに気づいて

20、21の平日パリで行われる架空ゲー大会に参加するためフランスへ渡米すると休暇の申請

市役所は難色を示したと思うが(所属観光課は連休中のイベントなどで忙しいはず)、ハースストーン

日本代表会社休みを取れずに世界大会参加が危ぶまれた件がネットで話題になったことを持ち出して

eスポーツへの理解を求めたのではないか

2.連休

ドイツフランス画像をググってFacebookにてアリバイ作りをしながらまったり過ごす。

9月21日 17:09 さーていっちょとってきますか。世界を → 9月22日 12:41 獲りました。

なんで獲っちゃうかなあ。

3.休暇明け

上司から大会の結果を問われる、または既にFacebook確認済かA君友人などから話を聞いていたかもしれない。

A君臨時職員はいえ長期休暇のために代わりの人員が期間中出勤するなどして対応したので確認するのは当然。

優勝と答えるが優勝賞金300万は副業規定抵触すると聞き、シード権を選んだので金は貰ってない設定に。

観光課長の耳に入り、太田市(O市とする)のアピールにもなるとして地元紙などを読んで記者会見を行うことに。

A君親バレが怖いなどと抵抗するも優勝時にも使った愛用コントローラーを持ち「しぶしぶ」記者会見に望む。

4.新聞報道

小さい記事にしてくださいというA君の願いも虚しく、上毛新聞ではスポーツカラーで大きく報道。eスポーツですしね。

珊瑚報道など実績豊富朝日新聞でも掲載され一躍全国区架空ゲープレイヤーに踊りでる。世界レベルですもんね。

新聞社記者の裏とり不足ではという声があるが、社会面埋め草ほのぼのニュースのようなものは会見側の発表を

そのまま紙面にするのは通常の記事作りの流れであり、政治家役人疑惑の追及と違って、発表内容の事実性まで

疑って裏を取り取材しろというのはなかなか難しいのではないか。会見を開いた市役所側の責任が大きいが

問題発覚後の問い合わせには業務外のことなので本人に聞いてくれと逃げの姿勢

新聞プロゲーマーコメント求めるなどしていれば、大会実在性が怪しいことに気づけたかもしれないが。

5.ネットでの検証とその後

ギルティ格ゲー勢、こんなプレイヤー知らないし大会も知らない、ホントかよ。はいウソー。

朝日怒りの無言記事抹消、上毛新聞お詫びと訂正をして記事取り下げ。

大会のもの存在しないこと、FB写真他人画像パクリであることな検証が進むなかで、

パリでの大会を知らせるチラシが発見され「こんなところにもいらすとや」と混乱を見せる。

BuzzFeedがA君本人にインタビューを敢行。小規模クローズド大会メールで招待されたが携帯壊れたので

メールはないし忙しくて大会写真もないし優勝の賞状トロフィーもないが大会はあった、とのこと。

うーん、ギルティ

増田見解

以上全てあくま増田想像です。

でもあれですね、たかだか10日にも満たない連休なんですよ。フランスでもニュースになってるようですが、

フランスなんかだとまるまる1ヶ月休みを取るのは当然なので、大げさなウソをついてまで休暇をとって

ようやくこの程度、ということに驚いているのではないでしょうか。民間ブラックと違って福利厚生

充実している市役所ですらこの有様なんで、日本ワークライフバランスってなんでしょうね。

そういう休みも取れない公務員自衛隊警察海保国会議員が起立拍手したところでどうなるんですか。

ありがとうさえあれば働けるワタミと同じことしてます安倍さんも。

jizouさんこんなもんでよろしいでしょうか。



追記

探偵ウォッチがA君本人に聞いた話によると、

新聞社から取材は、自身市役所が打診したわけではないという。帰国後に、新聞社が本件を聞きつけて取材に来た模様だ。

とのこと。これは信じていいものなのかな。

さらに追記

【おわび】「格闘ゲーム優勝」は虚偽

http://www.jomo-news.co.jp/ns/1214749890612721/news.html

>この報道男性所属する太田市産業環境から情報提供を受け、26日に太田市役所内で記者会見が開かれました。

男性作成したとみられる記者発表資料には「優勝」と明記され、1時間程度の質疑を経て会見時の写真とともに記事掲載しました。

今朝の段階で経緯の検証記事が出ていたようで、上毛新聞やりますね。

A君新聞報道後の各方面から取材でもウソを上塗りしていたわけで、ギルティですね。

2016-08-21

2chって今後どうなるんだろうな

最近まとめでも似たようなネタループしている印象なので、本家の方は更にクローズド化しているような気がする。

今のティーン達がもう簡単に何かをはじめる場所…では無いのだろうか?

2016-08-11

ノンケ専のゲイアウティングしか防げない

例の件、アウティングをした人が叩かれてるけども、彼の苦悩や恐怖は十分理解できる。

そもそもノンケ専がゲイであることを周囲に隠してノンケアプローチするというのが、卑怯なわけだよね。

だって世の中、異性と同性ってのは各所で扱いが違うけども、それはやっぱり性愛があるからでしょ。

例えばさ、ゼミだったらゼミ旅行とかあるけど、ノンケ専のゲイと同室になったらどうする?って話だよ。

これが異性同士だったら、大規模な雑魚寝みたいなのは別にして、同室にならないような配慮がされる

わけだけど、性癖を隠してるゲイは単なる同性扱いになっちゃうわけでしょ。困るよね。

風呂もさあ、どうする?「皆で入るか!」って流れになっちゃったら。自分のことが好きなゲイがいるのにさ。

ゲイ専のゲイだったら、まあ同性が好きでも関係ないみたいなところはあるけど、ノンケであることが

分かってて告白してくるゲイなんでしょ。恐怖でしかないよね。

で、そういう場面は至るところにあるでしょ。「食事に行こうぜ!」って言われたとして、ただのゼミ仲間と

自分の事が好きなノンケ専のゲイでは違うでしょ。前者はただの人付き合いで、後者デートのお誘いでしょ。

でも、アプローチをかけられてる人にしか、その違いがわからないんだよ。ゲイゲイを隠してるから

ターゲットにされた側はもうアウティングしかないんだよ。アウティングしか逃れられない。

例の件で「なぜ不特定多数にばらしたんだ!」と怒ってる人がいたけど、不特定多数なんかにばらしてないよね。

彼はTwitterFacebookアウティングしたんじゃないよ。ゼミグループラインという極めてクローズド

場でばらしただけ。そこがアプローチの主戦場だったんでしょ。だからこそ、そこでアウティングする必要があった。

他人面白おかしく吹聴するだけなら、適当個人情報をぼかしてネットにでも書けばいいだけなんだけど、

ノンケ専にターゲットにされてる彼はそれじゃあ救われないわけよ。

身近な人に、ゲイに狙われてるということを明らかにして初めて、状況が可視化され助けを求められるわけよ。

彼は被害者だよ。僕は被害者は叩けない。

2016-07-28

底辺職でしょ?君ら

もしくは無職

あ、自分無職だよ!働きたくないからね!

あと大学卒業してない人の方が多そうだね

言葉遣いだけそれっぽくなったけどヤンキーがたむろしてるだけになったなネット

クローズド環境を作ってネトウヨマイルドヤンキー底辺オタク排除した新しい

言論場所必要だなぁ

2016-06-29

疾患や薬剤の作用面白おかしネタにするとは

さきほどツイッターとあるツイートを見かけ、大変驚いたと同時にすごくやるせない気持ちになったので少し書かせてください。

そのツイートというのが、

とある向精神薬(検索避けのため薬品名は伏せます)を服用すると副作用として男性でも母乳が出たり、女性のように胸が膨らんだりします!とても現実味のある方法なので腐女子の皆さんはぜひこのネタで受けにミルクを出させてあげてください!Let's母乳

といった内容でした。

どうでしょうか。正直ドン引きしか言いようがありません。

これをツイートされた方は実際にその薬で治療を行っていてその副作用もご自身経験されたそうですが、

向精神薬というものがどういう状態の人が服用するのか、『副作用』という言葉意味男性の乳汁分泌・女性化乳房がどういう意味を持つのか、この薬を服用していてご自身でその作用を実感されているなら嫌というほどわかっているのではと思うのですがその上でこうしてネタにできるというのは不思議でなりません。

よく創作のための雑学bot~のようなものでも少し医学的な分野に触れた内容は見受けられますが、こういった具体的な疾患や治療、薬剤に関してその作用や症状などを面白おかしく扱うというのはあまりにも倫理観に欠けるのではないでしょうか。

ここでは名前を伏せましたが実際のツイートには薬剤の名前がハッキリと入っており、検索するとその作用や処方状況、服用している方の相談ブログ等も見ることができます

その中でこのようなツイート話題となり、検索結果の上位に上ってきたとしたらどうでしょうか。実際にうつ病等で向精神薬による治療必要となりこの薬を処方された患者さんが、他に使っている人の感想副作用を知りたくて検索をかけてこのツイートに行きついたらどう思うでしょうか。または女性化乳房や突然の乳汁分泌に驚いて、病院に行くのも恥ずかしくてネットで調べようと思った男性がこのツイートを見たら。どう思うでしょうか。

自分病気が、または身体の異常がこのように面白がられてましてや性的コンテンツとして消費されている現実をどう感じるでしょうか。

なにもうつ病向精神薬に限ったことではありません。

いつだか、こちらも女性ツイートで、

前立腺は歳をとると大きくなるって聞いたから、若い人よりもおじさんの○○(キャラクター名)の方がお尻の感度がいいんだ」

といった発言を見かけたことがありますが、こちらも同じですよね。

前立腺は確かに加齢とともに生理的変化として肥大しますがそのせいで排尿に関する問題を抱えて悩む方もたくさんいらっしゃいます

ましてや前立腺癌というもの存在します。おしっこの出が悪いなら前立腺癌ではないかと言われて不安になった方が検索してみてこれが目に入ったらどうでしょうか。

少なくとも私なら、自分病気不安の種をこんな風に面白おかしく書かれ性的コンテンツネタにされていたらいい気分はしません。

今回例として挙げたのはどちらも腐女子男性の体について触れ、ネタとして扱ったものですが、もちろん逆もあるでしょう。

男性女性病気や疾患、体調の変調について興味半分で触れ、性消費のネタとすることも少なくはないと思います

あくまでも今回私が問題と感じたのは『実在する疾患や障害の症状、その治療行為及び薬剤等を面白おかしネタとして扱う』ことに関してです。

信者及び対象となる方の性別や年齢・遍歴・疾患・国籍人種等は問いません。誰が誰のどんな疾患(症状/治療/薬剤…)に対して行っても等しく問題であると思います

自分経験者だから良い、つらさがわかってるから良い、面白がるつもりはなかった…等、どんなことを言っても受け取る患者さんはそうは思いません。

医療者であればこのような発言いか不適切患者の心を傷つけるか、また自身立場を脅かすものであるかわかると思いますが、そうでない方には自分が発する疾患等についての情報の重大性がわからないのも仕方ないのかもしれません。

ですが、他者病気、すなわち困難や苦痛をまるで笑い話のように扱うことが良くないことであるのはわかってほしいと思います

実際に検索をかけてみたところ、当該薬剤の使用経験のある方の「向精神薬飲まなきゃいけないほど精神がまいってる時にこの副作用はつらかった」「かなりうつ病が進行してる状態から性的な欲求は起こらない、それどころではない」といった苦言が見受けられました。ツイートされてからわずか数時間の間に何件もこういった意見が出されています

医療者のように法的な責任を負えとは言いません。教育も受けていなければ免許を持つわけでもないのでその必要はありませんが、ともすればうつ病精神疾患患者団体から訴えられたりしてもおかしくはないと思います

当人は「(疾患や薬剤の効能について)考え方は人ぞれぞれだから仕方ない、私はそう思わなかったからこういうツイートをしてしまったが、自分がこう考えるから他人もこうだというのは無理がある」「私の考えとあなたたちの考えは違う」「文句を言ったりブロックするのは自由だが考えを押し付けるな」と述べられておりますが、この件、すなわち医療に関してばかりはそうもいかないのが難しいところなのだということを、今回このツイートをした御当人にも、そしてこれを読む人にもわかっていただきたいと思います

病気に関しては、当事者の受け取ったことが全てなのです。痛みがその本人にしかからず数値化できないのと同じように、病気障害のつらさやそれをどう受け取るかも確かに人によって違います。ですが、「人によって違うから面白く扱っても許される」ということではないのです。個別性があるなら、大勢に向けて誰か一人の尺度で発信してはいけない、もしするならそれは責任を負わなければならないということです。医療者の常識押し付けるような形となるのは心苦しくもありますが、病気で苦しむ人がいる以上知っておいてほしいとも思います

それがわからないのなら、軽率にこういった医療行為及びそれに関連した物品薬剤企業等に関する発言はしないで頂きたい。責任を取れないのは仕方がないが、だからといって何でも言っていいわけではないということです。

病気は誰でも当事者になる可能性があり、誰にとっても不安苦痛をもたらします。

そのことさえ忘れないで頂ければ、このように疾患や障害治療薬剤やその患者等を面白がって消費するような発言はできないと思います

また、そのような発言拡散する方たちに同じことが言えます。誰かがRTや共有などでその発言を広めることによって、これを不快だと思う方のところに届く確率は間違いなく上昇します。

発信しないことと合わせて、こういった疾患・障害治療に関する不適切発言は広めないこともお願いしたいです。

どうしても発信したい、そういうのが好きな方に教えたいと思うのであれば、せめてアカウントを非公開にするだとか、DMやその他クローズド手段にて個人的にやりとりする程度の配慮はあってもよいのではないでしょうか。

自分発言が誰からアクセス可能ものであるということをきちんと弁えて頂きたく思います

長くなってしまった上、ともすれば特定の一個人を攻撃するような形にはなってしまいましたが、今回あまりにも問題があると思ったため書かせていただきました。

これを機に少しでもそういった発言の減ることをいち医療従事者として切に願っています

いたずらに患者さんの不安を煽ったり、不快にさせるようなことはやめていただきたい。たとえあなた医療者でなく、その疾患に関係がなかったとしても。

病名や障害名、薬剤や治療法が存在する以上、それに苦しめられている方も必ず存在します。そしてインターネットはその患者さんとそれらに関係のないあなたを一瞬で結びつけることのできるツールなのです。どうか、どうかそのことを忘れないで欲しいと思います

ここまでお読みいただきありがとうございました。

2016-06-16

http://anond.hatelabo.jp/20160616155848

身元の割れクローズド空間ならその理屈も成立するんだろうけどね。

不特定多数人間が見る場所で「ツッコむ奴が悪い」は、頭のおかしい人の弁でしょ。

2016-05-27

http://togech.jp/2016/05/27/36354

記事としてはバランスが気に入らないけど、

扱いの大きさから考えると、小野ほりでいさんが言いたいのって

批判する奴らの分類云々よりもやっぱりここじゃないかなと。

ちょっと批判されたくらいで”好き”じゃなくなるなら

あんた一生何も好きになれやしないわよ!!!

これだよね。

意識高い系批判するななんだのとギャーギャーいう人って

そもそもなんで批判されてるかわかってないし、

批判されたからと言ってすぐ萎える程度なのが一番腹立つわけですよ。

無理に反論しろとはまったく思わないけど、もっと本気さ見せろやとは思います



確かに

新参=まだあまり興味を持ってない人」の話だからそんなんもとめるのは酷だよとか、

やる気をくじくようなことを批判するのはどうかって提言自体には一定正当性があると思います





でもさ。

最近新参らしくない新参」っていますよね。「新参って扱われたいと思ってないよね」って感じの人。

最初からフルの権利を主張したり、あげくほかの人ですらやらないような方法で目立とうとする。

そこまでして出してくるアウトプットが極端にずさんだったり、他人に対して攻撃的だったり、なんかいろいろと「いい加減にしろ」って言いたくなる要素がある。

こういう人って、周りの人としては「いやもうちょっと頑張れよ」って思いますよね。



そういう状態なのに、そこで本人が「新参叩くな」ってお題目を唱えたり、周りの人がそうやって保護したところで誰が幸せになるの?

これって会社部活で言ったら態度だけでかくて仕事できない新人を一切否定せず甘やかして何でも好きにやらせてやればいいじゃんって主張してるようなもんですよね。

その「保護」が働かない場所では一秒だって生き延びられない希少生物をみんなで無責任飼育してるだけですよね。

99.5%の人は好きにすればいいと思って放置しますが、0.5%の人が違和感感じてツッコみいれるのは当然ですよね。




なんというかね。

ただ内輪でキャッキャウフフやりたいというだけなら、クローズドSNSでやるか、目立たないように工夫するじゃないですか。

まらないもの、視界に入らなければ別に誰もなんも言わないですよ。

でも、なんでそこではてブつけあって目立つようにして、わざわざ視界に入ってくるようなところに出ようとするの?

あげく、粘着されてるだの、村批判だの、バカじゃないの? まず自分の行動をかえりみるって発想がないの?

それがほんとに理解不能なんですよ。





互助会だって批判された人のうち

「やり取りに使ってるだけで目立つ意図はなかった」とほんとに思ってる人は、

仕組みを理解した後はあんまり目立たないようになってる。

でも、一部の人間はそうじゃないよね。 あれこれ言ってるけどまだやってるよね。

あい不思議な生き物に対して、ひはんするなってそりゃ筋が通らんでしょ。




存在としていびつすぎるもん。

ネットなんだからブログなんだからかいても自由だろって主張もアホすぎる。

他人の最大幸福マイナス効果をもたらしてまで自由を追及することは許容されてねえよ。

そこで「自分アウトプットを気を付けよう」じゃなくて「批判してくる奴らのせいでまともに書けない」とかって。

どんなワンダーランド想像してるんですか。




プリントアウトして病院いってまず社会復帰しろボケ

2016-05-20

男性痴漢の怖さを伝えるたとえ話を考えた

冬頃だったか、『男性痴漢の怖さを伝えるたとえ話』として、『女性男性をいつでも咬みつく世界』っていうのを見た。

 

 

それは、わたしとしてはイマイチぴん、と来なかったし、

実際、『美女に咬まれるならご褒美です』と言う男性も見かけたりしたので

わたしとしても同じくたとえ話を考えたのだった。

 

  

一般的エロ』と『BL』の立場が逆転した世界

 

あなたは、17歳の健康優良男子である趣味野球とかサッカーで、太陽の下で爽やかに汗をかく。最近クラスに気になる女の子なんかもいる。

 

 

あなたはふとコンビニに立ち寄った。若い女性が笑みを浮かべて、雑誌コーナーの角に常設されたBLコーナーで18禁BL立ち読みしている。

それは日常にありふれた当たり前の風景なのだが、エロBLの表紙に浮かぶ『健康野球少年鬼畜コーチにゆっくり脱がされて……?』なんて見出しを目にしてしまった時は

ああ、俺はなんて失敗をしてしまったんだろうと自分を責めた。

胸に感じる不快感は、自分がうっかりあのコーナーを見てしまったせいだ。あれは見てみぬふりをしなければならない。

そもそも、何でコンビニ18禁BLコーナーがあるのか、という問題提起をすることはなかった。生まれた時からある、当たり前だからだ。

 

 

 

あなたには仲の良い友達がいる。それは、クラスメイトかもしれないし、部活仲間かもしれない。

あなた電車通学だ。友達と一緒に電車に乗り、他愛もない話をしながら下校している。

ある日、あまり友達の話が面白かったから、少し過剰にスキンシップをした。それは、頭を撫でたりとか、胸を叩いたりとか、そこまで派手ではないアクションだ。

しかし、瞬間近くにたまたま居た女性が、鼻息荒く傍らに居た、彼女の友人らしい友達に話しかけた。

「ネェ、あの子たちどっちが攻めかしら!」

「えーわたしは髪が短い子かなぁ」

そこから先は、あなた友達の濡れ場が、さも楽しそうな猥談として展開された。近場に居る人はそこそこ耳にしているはずなのに、誰も彼女達を咎めない。

それどころか

「ちっ……公衆面前でイチャつくからこうなるんだよ」

と、あなた友達を責めるような声まで聞こえた。あなたはたまらなく恥ずかしくなって、急いで次の駅で降りた。

 

 

降りた駅で、友達と話した。

「一緒に下校するのやめようか」

「ええ、俺はなにもわるいことしてねぇよ! おかしいのあの腐れた女たちだろ!!」

あなたはそう抗議したが、友達はその日以降一緒に帰ってくれなくなった。

 

 

悔しくなったあなたは、いくつか上の兄に相談をした。

「あのなぁ、人様の見えるところで過剰なスキンシップを取るお前が悪い。俺だって課長に目を付けられないように注意して……」

しかし、兄の職場愚痴に変わってしまった。

兄は兄で、仲の良い同僚と一緒に居ると、セクハラ上司として名高い課長に「やっぱり兄くんはそういうところが受けなんだよ~~」とからかわれるらしい。

それは、昔からよくあることで、デフォルメされて何回もドラマ漫画に登場している、本当にありきれた話だ。

ありきれた話なのに、いざ自分当事者となると、あなたは悔しくて悲しくてしょうがない。

ついには匿名掲示板でそのうっぷんを晴らそうとするが、帰ってくる反応は

イケメン自慢乙」「つーか自分に自信がなきゃそんなこといえないよねwww」

「女だってブサメンイチャイチャしてるのはイヤだし」「本当はそう言う気があったんじゃないのwww」

と、からかわれるばかりで、あなた心配してくれたのは少ない人数だった。

 

 

 

本屋でもDVD屋でも、基本的にはキラキラとしたイケメン揃いのものばかりだった。

男性ターゲットとしたかわいい女の子商品は、『殿方向け』と固有ジャンルとして呼ばれ定着していた。

最近は『殿方向け』もその数を増やしていたが「最近は『殿方向け』ばかりが多くなってアニメ自体面白くなくなった」「『殿方』は文化衰退の敵」と

過激な事を言う女性も少なくなかった。

『殿方向け』愛好家は、ひっそりと愛好家同士で繋がりをもち、自慢のエロ披露していた。

それは本当にクローズドものだったが、昨今のSNSの発達でその存在感を示し、その存在認知されはじめた。

はいえ、テレビではBL的なものはあたりまえに流れるにも限らず、『殿方向け』に限ってはNHKなどで特集され、やや特殊オタク、として扱われていた。

まだまだ、BL一般エロの間には溝があるのだ。

 

 

こんな問題もあった。ある時期、性悪な男が「今、この人俺に向かってひどいことをいいました」などと女性に吹っかけて、名誉棄損罪で訴えたり、金銭要求したりしたのだ。

時にはグループで行ったりもしたこの『クサレ冤罪』は社会現象となり、それ以降、冤罪に怯えて女性たちは電車に乗った。

いつ、目の前の男性自分を指さして名誉棄損で訴えて来るかわからない。『絶対に声がでないマスク』が流行し、女性たちはそれをつけて電車に乗った。

いわく、このマスクをつけていたから、彼に対してBL妄想など口走ってません、というモノである

 

 

しかし、冤罪の恐怖は本当におびえている被害者さえも萎縮させてしまった。

あなたいくら自分の身に起きた悔しい思いを訴えても「大げさ」「冤罪目的なんじゃない?」とフタをされてしまったのである

あなた高校生のうちに、何度か同じような目にあった。スポーツマンタイプ高校生腐女子の好物なのだろうか、数えれば一週間に一度は『自分対象としたエロ妄想』を耳にした。

ひどいと写真を撮られたりもした。ひとりで居ても、妄想を話されることもあった。3人で居たら3P妄想だった。

男子高生のあなたは、酷い性的暴力の嵐の中に居た。

でもあなたは諦めていた。これはそういうもので、逆に商品価値さえあるんだ。自分は貴重なんだよ、うん…………

そう思うことで自尊心を保ち、生きづらい世の中を、あなた今日電車通学していくのである


 

 

読んでイヤな気分になったのは

書いていて思ったが、読んでイヤな気分になったのは、男性自身よりもむしろ腐女子のみなさんではないかと思う。

一般エロBLを逆転してみた結果、そもそもの目的が『男性痴漢の怖さを伝える』っていうのもあり、BLが完全に悪者になってしまった。

しかし、性的なモノを扱うって言うのは時に酷く対象を傷つけると思うのだ。

腐女子には古来より『隠れる』『当て字』『専門用語』と身を隠す忍者の様な文化があるが、それはきっとその為だろう。

SNSの発達により、そういったものが廃れつつあるが、わたしとしてはある程度の『隠れ』は必要だと思う。

 

 

そして、男性のみなさんも、もしこちらを『腐女子ってサイテーだな!』と思ったのならそれはお門違いだ。

ほとんどの腐女子公衆面前で、聞こえるところで萌え話はしない(まぁ、一部のキチガイは除いて)

本人に無理矢理干渉し、自分妄想リビドーを果たす、それが痴漢なのだ

もし、『腐女子ってサイテーだな!』って思ったのなら、それが女性が日頃思っている『痴漢死ね』の気持ちである

2016-05-13

http://anond.hatelabo.jp/20160513221545

解るわー。気持ちがとてもわかる。



増田文体に慣れたものは、

ブログみたいな書き手整合性を問われる場は

少し厳しい。明らかに創作とわかりきってる

経験談は興ざめされてしまうからなー。



俺はFacebookクローズドな人たちに

自分の書いた増田を何度か紹介してたら

最近は俺の作品だとわかられるようになった。

元増田もやってみては如何だろう?

無駄炎上避けつつ、自己承認満たせるよ。



あと、余談だけど年間ランキング10位以内とかに

入るようになると、いろんな迷いも消えてくる。

増田から有名にはならないし、

書籍化の話とかも来ないけど、

作品自分の手を離れる感覚って悪くないものよ。



ある程度ホットエントリ連発できるようになったなら

1000ブックマーク目指してみては?

2016-04-26

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、アプリ認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げますさらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。

セキュアでないトークン

トークンベース認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなもの設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分プラットフォーム自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。

トークンベースシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的スクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。

もし生成されるトークン予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまます。筆者は、fortune 500 クラス大企業による OAuth ベースサービス一種の単調増加 ID (おそらくデータベースフィールド?) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在トークン ID を見て、その後の ID を予測すれば、続く任意ユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。

このクラス攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意OAuth ベースサービスが外部レビューセキュリティを証明してもらえる可能性はあまり高くありません。

本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通実装における」OAuth がよくやる使い方ではサーバ信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。

一方、一部の OAuth ベース実装乱数必要性クライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。

クロスサイトリクエストフォージェリ (CSRF)

本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ CSRF トークン指定するようにと、オプショナルな state パラメータ定義していますしかしながら、OAuth ベースサービス一般的state の長さや文字種を制限し、要求どおりそのままでさないことがあるようです。そこで、おかし互換性問題が起こるため、多くの OAuth ベースサービス利用者リダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されていますstate パラメータの別の懸念は、EVS 側で stateアクセスのある人はだれでも、リクエスト改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。

OAuth ベース API の利用者は、自分アプリサービス登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的危険の伴うアイディア姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効パラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険ものstate パラメータに詰めこもうとし始めたり、浅薄システムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザ不適切なページに誘導する危険性が出てきます。これは「10.15. オープンリダイレクト」に分類されます

こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザ大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通実装における」OAuth の低品質設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベース利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています

ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります

章のまとめ

セキュリティに関して言えば、「普通実装における」OAuth仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースサービスの中には、種々の攻撃に対して無防備でいることを利用者公然要求するものがありますサービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要セキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質プログラミング習慣を招いていますOAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティ提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。

この記事についていえば、個人的蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所OAuth に使っているのを見たまま開発者コピーした結果というものもあります

OAuth ベースサービス開発者もその利用者側の開発者も、OAuth ベースプラットフォーム実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラス攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装仕様書セキュリティガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルセキュリティを実現することはできません。

真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます

ユーザビリティ関連

(略: ふつう実装では、サービス側がプラグを引き抜くようにして自由利用者出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)

(略: サービスからは API 利用者という大きすぎる単位しか見えないので、たとえばビデオカメラアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位対策としてユーザ開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)

(略: ふつう実装SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリcURL 的なもので API を叩こうとしても、JavaScript必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新メタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバlocalhostで立てるとかアホか。)

(略: オープンソースしづらい)

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (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 のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

  • 必要以上のアクセス権をサードパーティに与えることになる。
  • 認証情報を格納する場所が増えるということは、盗まれる危険が増える。
  • パスワード等を変更したときに API 利用者側でも更新が必要になる。
  • ひとつアプリだけでアクセス権を破棄することが難しく、全アプリで破棄することになりやすい。
  • 特別な認証要素を使っていると、制限が多すぎる。

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、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 に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の 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 がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

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 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、Permalink | トラックバック(3) | 12:44

2016-04-24

ネカフェにいるんだけど、ホモカップルフェラしてて引いた

なんでそんなに大きい音でしゃぶるんですか

なんでイキそうとか大声で聞くんですか

何でもっとクローズドな部屋があるのに上が空いてて聞こえる部屋でやってるんですか

開き直ってるのはいいけど、周りへの配慮くらいはよろしく頼むよ

2016-04-21

ネットモラル低下はやっぱり低年齢化が問題だった

googleマップとある地点のレビューに、☆1という最低評価が付いている。

私も伺ったことがあるが、注意点はあるものの概ね良い評価を述べることができる場所だ。

現に不自然な☆1評価以外を見ると、しっかりとしたコメントとともにまあまあ平均以上の評価が付けられている。

その☆1評価には、短くコメントが付けられていた。

「まだ行ったことがないから

評価をつけるに値しない人間評価をしているという事がここでわかった。この人間は、訪れたことがないのに評価をつけているのだ。

そして、自分体験にない=評価なし=☆1だと判断しているのだった。

さて、このレビュアーだが、少ないながらも他に評価を残している。

先に断っておくが、こういったレビューレーティングは、一般的に誰でも利用できる施設商店に対して評価をするもので、公に開かれていない場所に対して評価をすることは事実上意味が無い。

企業クローズド社員食堂評価など需要が無い上に個人情報漏洩に繋がるのだ。

話は戻り、この不自然な低評価をつけたレビュアーの他の投稿を見ると、小学校評価をつけていた。☆5の最高評価と共に、ご丁寧に「楽しいよ♪」というコメント付きだった。

前述の(言っては角が立つが)無教養な振る舞いとこの小学校への評価コメント鑑みるに、無自覚小学生レーティング荒らしているのだ。

ネットの低年齢化は盛んに取り沙汰されてきたが、コミュニティを越えて開かれた場所に現れたのを見て恐ろしくなった。子供には社会常識モラルも通用しない。

パブリックサービス年齢制限必要になる時代がやって来たのだと実感した。

2016-03-21

http://anond.hatelabo.jp/20160319153759

まじめなトラバついててびっくりしたありがとね。

でも僕は「二十歳〜」が「倫理的にこれってどうなのか?」って議論が成立するような物だとは思ってないし

そんな風に書いたつもりもなかったんですよね。なんかごめんなさい。

描写がすごいってところを誤解されているような気がして歯痒かったかトラバつけることにしました。

僕は、「エロ同人は”ただ人が性的に消費される様を描いただけ”だという枠の中からは出られない」という前提が当然あって

それは常識的ものとして共有された認識だと思っていました。

なのであくま増田がいうように「添加物」というのか、

ムードを作るため、話に厚みを出すための肉付けの一つとして描写のことをだしただけなんですよね。

じめじめした樹海たまたまくっさい銀杏の木みつけてなんか銀杏いっぱい採れた、糞みたいな体験でしたけど銀杏はおいしかったです、みたいな。

ちがうか。

やっぱり僕からすると、クジラックスさん含め作者や愛好家は

この手の同人は如何わしく非倫理的ものと扱われて当然だと思っていて、

なのであまり表立って展開される活動ではないと認識しているように見えるんだよね。

性的搾取(あえてこの言葉を使う)の対象として主人公が出てきてなぶられる。」

そのことを吟味してただ楽しむだけに制作され売り買いされるのがエロ同人界隈であり、

内輪の外からは見られることはないという暗黙の了解を掲げることで成り立っている世界なのかなと思っている。

「『泣けるエロ漫画』として紹介されている」というけど、それはアフィリエイトブログの類で

クローズドされた集団の様子を外から面白がってパブリック空間晒しているのではないのかな。

(まあ僕もそういうの経由して流れてきた情報しかクジラックス漫画を知らないんだけども)

問題集団構成員がそういったネットの流れを黙殺しているところでしょう。

当人たちがコントロールできないところでああいった漫画なりイラストが公開されているって現在も知らないなんてことはさすがにないはずだから

クジラックスさんは「わんぴーす」って漫画ツイッター児童ポルノに絡んだ描写入れてたみたいだし。

公共ネットスペースに筒抜けの状態でそれでも背徳的な描写を描き続け持ち上げ続けてるわけで、

彼らは愚かにも、一時話題になったバカッターと変わらない精神構造をしているのではないかとすら思えてくる。

大勢いるロリコンエロ同人作者のなかでクジラックスさんがある種突出した存在であるのは、

ということを感じさせる、犯す側の人間が抱える劣等感孤独感を軸にしたストーリー展開なんだと思う。

興味本位で調べただけだから言い切れないところはあるけど、

クジラックス作品(といっていいのかな)は性癖を介することで犯す側の人間が人との繋がりが見つけ出すか

女児が傷つき孤独に苛まれる(犯す側のフィールドに引きずり込む)かのどちらかだけなんだよな。

駄目なことだとわかっているといいながらそれを排除できない自分本位な心情があって、

それを必然的ものだとでもいうように自らの孤独さを強調する言動というものロリコンたちは共感しているのかもね。(でもこんな危ない感覚を持った奴がごろごろいるのか?)

クジラックス作品に限らず多くのエロ同人にいえることだと思うけど、

どの作品も犯す側の自己完結した思考ベースになっていて、

それは表に存在が知られないように内輪で読んでる分には問題なかったけど、

それが一旦外部に広く知れ渡ってしまった以上人々の不快感や恐怖心は拭い去れないわけで、

やはり未だに”今の環境で”作品を発表し続けているということの有害性をもっと真剣に捉えてほしいな。

2016-02-14

http://anond.hatelabo.jp/20160214182147

リア充LINEツイッタープラ垢やその他諸々のSNSクローズド世界つくるためにネット使っていて

そこから閉めだされてる負け犬匿名から助長している世界はてなだったり2ちゃんだったりする

小賢しい奴らは負け犬の扱いに長けていて負け犬が反応しそうな文句を並べて俺らを踊らせている

内輪で楽しく和気あいあいとしているリア充がそんなしみったれたところに首つっこむわけもない

そんな2層社会NIPPON

2016-01-23

SIはやめておけ

20代の数年間SIで働いた。1年以上前退職して今は別業界にいる。

今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくり暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。

一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。

以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。

工数至上主義

受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積おかしくても顧客と対等な関係が築けていないから追加請求もできない。時間(工数)をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。

まり、どう頑張っても売上は同じなのだから、良いもの価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。

これが諸問題の根源で、いかに述べるような組織プロジェクトが出来上がっていく。

作業効率化しない

マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。

私は定型作業効率化しようとjsやrubyスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。

あるとき上司に肩越しに自分作業を覗かれて「何やってるの?」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの?工数に乗ってないよね?」「スクリプトテストもちゃんとしないと結果が正しいって保証できなくない?」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分作業工数内で完結する。むしろ工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず(読めないので)1時間無駄にした。

技術力いらない

前述したようなビジネスモデルから営業力と、予定工数で無難プロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者人材派遣系の企業や下請けにいっぱいいるから。

社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術=技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。

そういう人が集まっているor残っている組織なので開発者ほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム部長お気に入り課長になり、部門長のお気に入り部長になる。その繰り返し。

開発案件でのBP(ビジネスパートナー委託先、派遣下請け比率自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い=マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。

私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。

意識の低い開発者メンバー

上述の通り、案件で接する開発者基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。

まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度(この場合顧客は私が所属する企業)、請負場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズド世界で生きている。

そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルール説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステム課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループ疲弊の一因だ。

static BP

ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパー技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。

だが、拍子抜けした。あまりにも仕事が雑なのだコミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分ブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。

また、彼はJavaの有名なフレームワークであるStruts拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークバージョンを上げると壊れるというのが残念な点で負債になりかけていた。

私は異動したが、彼は今でもそこにいると聞いた。

技術の話

テストコード書けない

(最低限のものしか作らないから)安くて早い!という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何?」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの?』って問われるから絶対言うなよ」と拒否された。

保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。

リファクタできない

先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコード顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。

レビューない

私がいたどの案件にもコードレビューがなかった。リーダー開発者数人という構成場合、まず開発者は全員下請けリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステム挙動実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解齟齬が頻発していた。特に入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。

そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。

新規技術試せない

無難プロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業マネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術(言語フレームワーク)がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらラッキーぐらいの考えでいる。

常に横に倣えのアーキテクチャは私にとって面白くはなかった。

横に倣え

また横に倣えが加速してさらに悪い事に、同じアーキテクチャネットワーク再利用するために既存のサーバに新システム相乗りすればよいという発想も珍しくない。「資産再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックオンプレミスサーバ上で複数アプリケーションサーバ運用した結果、予想通り耐障害性が下がった。

また、Oracleライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システム共倒れになったこともあったがOracleのバグとして報告していた。

static Perlおじさん

新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。

まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか?」と聞いたら「Perlクラスなんて必要ない。構造プログラミング研修でならってないのか」と返ってきた。「俺が前に書いたPerlバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。

また、そのプロジェクトのメイン言語Javaで、Eclipseを使っていたのでPerlプラグインを入れてコーディングデバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグイン品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタしろと言っただろ!」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。

待遇・制度

給与

SI業界の中では高いのかもしれないが決してよくはない。4年目(たぶん25歳)ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。

個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。

マシン

会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者基本的デスクトップ使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。

組織問題

とにかくクローズド組織

つの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから

情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメール添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダ権限を持った人間しか見られない。何で他の部や課が行った過去の見積提案資料自由に見られないんだよ。

ソースコードリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。

会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。

意思決定の遅さ

どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクト利害関係者ならまだわかるものの、まったく関わっていない上長(課長部長、時には部門長)を通さないと進まないという異常さ。

コスト削減

利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自ノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員デスクトップを使っている。ITとは。

本当に無駄しか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員派遣で雇うべきという提案が何度もされたが、課の予算オーバーするから無理だという回答しか返ってこない。

残業削減

表向きは社員健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システム監視し、削減できていない組織や人間評価を下げるようになった。

その結果、サービス残業が復活した。30時間を超えると部長説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員残業時間を管理するとかい無駄な仕事を増やしたし、管理される社員ストレスサービス残業に繋がったので下策だと思う。

他人残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。

そもそも無駄作業や工数至上主義作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。

辞め方

2016-01-07

http://anond.hatelabo.jp/20160107122613

ほんとわるいんだけど、mixiクローズドから始まったことなんて今更書いてなんか得でもあんのかと言いたい。

知ってるに決まってるでしょ。文節上きまりが悪いからまとめてるだけで。

マウントしたつもりかもしれないけど滑ってるよ?

ログイン ユーザー登録
ようこそ ゲスト さん