「改竄」を含む日記 RSS

はてなキーワード: 改竄とは

2017-06-07

あんたは正しい。放射線検査なんざいくらでも歪めることができる。御用学者の協力もあればなんでもね。

http://anond.hatelabo.jp/20170606174324

原発安全』な神話御用学者によって"作られ"てきた。そして事実は暴かれた。メルトダウンによって。

御用学者 - Wikipedia

https://ja.wikipedia.org/wiki/%E5%BE%A1%E7%94%A8%E5%AD%A6%E8%80%85

現代における用法定義することは難しいが、学術的な調査改竄ないしは恣意的解釈し、権力者統治者、ないしは依頼者に都合の良い結果を導き出す者がこう呼ばれる。一方で、権力者などへの批判側が恣意的解釈に基づき自らに都合の良い結果を導き出していることを指摘・批判する学者に対して、反権力側がレッテル張りとして用いる場合もある。

水俣病問題

現代日本においては水俣病の例が嚆矢である1956年昭和31年)、熊本大学医学部研究チームにより、有機水銀原因説が有力視されたのだが、同年11月12日には厚生省食品衛生調査会常任委員会水俣食中毒特別部会大学と同様の答申を出したところ、厚生省は翌13日に同部会を突如解散1960年昭和35年4月日本化工業協会塩化ビニール酢酸特別委員会付属機関として、田宮猛雄・日本医学会会長委員長とする「田宮委員会」を設置。後に熊本大学医学部研究班も加わることとなった。有機水銀説に対する異説として清浦雷作・東京工業大学教授らがアミン説を発表し、彼らの主張がそのままマスコミによって報道されたため、原因は未解明という印象を与えた[1]。

ナイロンザイル事件

詳細はナイロンザイル事件を参照のこと。1955年昭和30年)、日本登山者ナイロン製のクライミングロープ(以降ロープ記述する)を原因として死亡した。ナイロンは引張りについては従来の麻のロープよりも遥かに丈夫だが、鋭利な岩角などに擦れた場合には容易に切断される。これはすぐに明らかになったが、大阪大学工学部教授日本山岳会関西支部長篠田軍治は、事前の実験ザイルが容易に切れることを確認した上で、公開実験ではあらかじめザイルが接触するコンクリート製のかどにヤスリがけをして十分な丸みをつけた状態で、作為的実験新聞記者等の前でデモンストレーションしてみせ、ロープメーカー東京製綱および日本山岳会共謀して、犠牲者に対する誹謗中傷運動を山岳雑誌化学学会誌などで長期にわたって続けた。法改正安全規格が定められ交付されたのは1975年昭和50年)、最初事故以降に確認されているロープの欠陥による死者(通産省調査した範囲内での数字)は、20人を越えるとされる。なお、偽装実験マスコミの前で実行した篠田軍治は、日本山岳会名誉会員推薦により、1989年平成元年)に評議委員会の全会一致で同会の名誉会員になっている。

イラク戦争への対応問題

哲学者の山脇直司東京大学教授は、安保理決議のないままブッシュ政権主導で2003年3月イラク戦争が始められたことへの日本政府対応について、「アカデミシャンとしての私が今一番一番懸念していることは、アメリカを無邪気に支持し、フランスなどを非協力と言って批判する小泉首相川口外相のお粗末きわまりない答弁の背後にいる『外務省お抱えの御用学者』の存在です。」「外務省お抱えの『御用学者知的退廃』を暴く必要を今痛感しています。」[2]と書いている。また、2003年12月から自衛隊イラク派遣を決定する過程について、政治学者イスラームシーア派に詳しい松永泰行日本大学助教授は「私の知る限り、政府研究者の実力よりも、政治家官僚の都合で彼らが望むことを言ってくれる御用学者を起用している」と述べた[3]。

喫煙受動喫煙問題

日本たばこ産業研究費を支援してもらうかわりに、タバコ擁護する発言を行うなど、消費者健康よりも特定企業利益を優先するような行為をしている学者を指して使われた事例がある。[4] また、メーカーから多額の研究費を受け取っていたために、タバコ乳幼児突然死症候群との関係があるという論文が、根拠が乏しいというように書き換えられてしまったとの指摘が存在する[5]。 タバコ産業から研究助成については学界において問題視されており[6][7]、2003年10月22日日本公衆衛生学会学会員に対し「たばこ産業及びその関連機関との共同研究、及び同産業から研究費等の助成を受けた研究を行わない。」との行動宣言を発している[8]。また、国際的にもたばこ産業による研究助成等について全面規制を求めるたばこ規制枠組条約ガイドラインが追加採択されている[9]。

公共事業原発

今日現実社会の中では、例えば有力な学者政府公共事業などの施策に対して、自己の信念に基づく意見思想審議会などの場で反映させる為に、そうした機関に呼ばれる立場を確保するべく、ある種の手練手管として、権力へのおもねりと自己の真の主張を両天秤にかけながら駆け引きをする場合がある[10]。そのため御用学者か否かの線引きは困難な側面を有する。駆け引きに失敗して結果として権力へのおもねりの手練手管を権力に利用されるだけの結果となったときには、結果として御用学者呼ばわりされてやむを得ない側面がある一方、駆け引き成功して自己の信念を政策に反映させることに成功した場合には、反骨の策士と評価される場合もありうる。また原子力発電の分野では、研究に多額の費用がかかることから権力におもねり、「安全神話」のお墨付きを与えることで電力会社等の支援[11]を受ける例があり、このもたれあい関係を「原子力村」[12]と評される。

2017-04-06

http://anond.hatelabo.jp/20170405235957

ごめんなさい、なんか追記とかトラバとかしようと、いろいろしてたら間違えて消しちゃいました。

一応補足すると、上流工程の人と下流工程の僕を比べたわけじゃないです。

というか、先月とか今月は開発の工程から開発してるけど、僕は要件定義から関わってるから別に下流工程専門ってわけでもないです。

比較した人はコーディングもすこしはしてましたが、メインの仕事は「テストやる要員」で、テスト仕様書(≠テストコード)書いて、画面操作する仕事をしている人です。

いやなんか、愚痴にもほどがあるだろってぐらいの愚痴なので、マジで反省します。

反省したいけど、後日見返したときに心がざわつきそうなので、日記改竄しちゃいました、申し訳ないです。

ここに対象文章を残しておきます

モチベーションが著しいレベルじゃないぐらい急降下したので、さっさと帰ってきた。

というのも原因があって、ひょんなことからとある人の月給を知ってしまった。

わかってる、重々わかってる。

僕がどんなにコードを書いても、どんなにバグ修正しようと、どんなに仕事が便利になるツールを作ろうとも、どんなにその人にコーディングの基礎の基礎を教えようとも、

それと給料因果関係がないことは、重々わかってる。

重々わかっている。

たとえ、nullと空文字の違いがわからなくても、内部結合と外部結合の違いがわからなくても、いいじゃないか

そんなことと、その人を評価する指標にはならないに決まってるじゃないか

ダメダメだ、こういうことを考えるのはよくない、非常によくない、他人のその一面だけを見て、勝手自分の方が上の存在だ、みたいな思い込み無意識でして

そうじゃないことがわかった途端にイライラするの、非常によくない

反省しよう。

反省反省反省

僕もよくないところはたくさんあるし、そもそも

良いとか、悪いとか、

そういう話じゃないし。

全然関係ないし。

反省します。

2017-03-22

JINSマジでやばい

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 年前のクラック被害から何も学んでおらずユーザーデータ資産を防護する基本的姿勢が欠けているとしか思えない。

2017-03-21

http://anond.hatelabo.jp/20170321154019

ああ、あなたサイト改ざんされたんじゃなくて他人サイト改竄されたのを確認したって話ね

読んでて???って感じだったけどようやくわかった

2017-02-20

http://anond.hatelabo.jp/20170220173453

からパクってきたのとただのコラでしかないの多すぎ。

パクり文化改竄文化絵で起源主張ってお前らは韓国人かよ。

2016-12-26

モラハラ人間引退の辞

「僕が1回生のころは練習場に集まって練習して帰るだけの暗い部活でしたが、この3年間でずいぶん雰囲気がよくなりました。」

→ なにいってんの??? お前がさんざん空気を悪くしたのをまわりが必死で火消ししたんだろうが。これがモラハラ人間の得意技、歴史改竄か……!

2016-12-18

格差グラフ池上彰印象操作か?2016年12月16日CX敬称略

印象操作ではある。では、「印象操作」って悪いのか?

 

かなり正確な分析は不破雷蔵氏がされているのでリンクさせて頂く

http://www.jgnn.net/ls/2016/12/post-14336.html

 

さて、特に推敲せずに書き殴らせて頂く、ご容赦頂きたい

 

Q1,「格差」は日米共に広がっているのか? A1,広がってはいる。

Q2,どちらの方が「格差」は広がっているか? A2,アメリカだ。

 

Q3,どちらの「格差」の方が深刻か? A3,それは日本だ。下位層(90%)が下がっているか

 

Q4,『格差グラフ』において最悪の改竄は何か?

 A4,アベノミクスの成果の無視

  日本2011年以降、アベノミクスで下位90%の所得回復している事を切り捨てている事

 

Q5,『格差グラフ』のy軸の数値が変えられているが?

 A5,【私】は大きな問題では無いと考えている。数値は変えれているが、等間隔だからだ。

  今回は違うが、酷いグラフだと対数で表示されていたりもする。 今回のは見れば分かる。

 

 そもそも、下位90%って、=上位10%以外の殆どの人って事だろ。

最上1%との比較では 最初から人数では90倍の差があるわけだ。

これって「印象操作」ではないのか? 勿論、印象操作だ。

 つまり

最初の問い自体グラフの設定自体印象操作が含まれている

 

池上彰氏が凄い(そして厄介な)のは、異なる層に対して「同じ話」を使って「別の見解」を持たせ、しかし「結論」は一致させてしまえる事だ。

 これこそ、プロプロパガンダだ。

今回の件で言えば

 そのまま「信じて」しまう層には『日本格差が広がっていてピンチだ。』と「騙せ」て

 「見破る層」には『より深刻な危機意識』させる。 でも危機感問題意識は一致させられる。

 

これは池上彰氏が週刊こどもニュース解説されていた時からの特徴だ。

 

 こども(実際の視聴者は年配者だったらしいが……)に現実ニュースを大幅に捨象して分かり易くし解説する。

要は要約なんだけども、 時に『虚構』を混ぜて焦点を絞る能力

 

 一例として、株式市場説明の際。野菜の株を使って説明する等。分かり易くするために完全な嘘を大胆に混ぜる。

これが、異なる層に対して「同じ話」を使って「別の見解」を持たせ、しかし「結論」は一致させてしまう。氏の最大の特徴を強化したのだと思う。

 これは、やっている事は単なる【要約】のように見えるが、実は違う! 池上彰氏は【待って】いるのだ

実際には極めて広い見識で問題先読みし、問題が十分に悪化して【要約】可能、≒一般人に分かり易く解説可能になったタイミングで切り取っているのだ。

 だから、氏の『解説』は何時もやや遅い。

 

 話は逸れるが、

氏がバングラデシュテロの事後取材をしていた時、まさにその時に偶然、氏の目の前で新たなテロが起きた!

 池上さん躊躇無く。現場に突っ込んだからね。 普通する?そんな事。 イカれてるだろ……。あのおっさん……。

他にも池上氏の番組を見てると、さり気なくブッ飛んだ行動と取材をしているところがマレに良く見れる。

 池上彰氏は単なる解説おじさん ではない。狂気を秘めた報道記者なのだ

 

▽いつも思うんだけど、さ~ぁ……

 いわゆる『格差問題』って「格差」が問題じゃ無いよね……

だって最上位者(ビル・ゲイツとか)の所得資産が2倍になっても、低所得者層所得資産が半分になっても

 「格差の広がり」は「同じ」だけど、 前者より後者の方が 遥かにヤバい

 

正直に貧困階層化、貧困再生産、階層の固定って言えんかね?

 

 いや、確かに「格差」は構造よ。 でも問題の焦点は貧困か、それを無視しても貧困再生産な訳じゃん。

じゃあ解法は主に2パターンで、「『構造』の改良」か、「問題貧困改善」のどっちかか、両方じゃん。

本音で解法に取り掛からないとヤバいと思うんだけどねー。

 だから、今回の池上解説話題になってる訳で、

 

私は問題顕在化させる為に池上さんはワザと「嘘」をついたとみてるけど、

2016-10-05

電磁的記録不正作出及び供用

元々、テレカ改竄クレカコピー対策法律らしい。

チート場合権限なくDB上のデータを弄ったってことなんだろうけど。

しかしこれ、刑法なのね。

10年以下の懲役または100万円以下の罰金は、なかなか厳しい。

2016-09-16

やまもといちろう記事は、背後の人間想像しながら読むべき

小池百合子都知事の件で山本一郎はズレた発言を繰り返して随分とツッコまれている

http://b.hatena.ne.jp/entry/bylines.news.yahoo.co.jp/yamamotoichiro/20160915-00062196/

“ この件に関しては”などというコメントも見られるが、こういうのは別に今に始まったことではない。

既に指摘されているが、人権周りの分野でも非常に古い感覚を発揮して、AV女優問題なんかは記憶に新しい。

http://www.xn--n8jvce0l6c.com/entry/2016/06/15/%E5%B1%B1%E6%9C%AC%E4%B8%80%E9%83%8E%E3%80%81%E5%B8%82%E6%B0%91%E6%A8%A9%E5%BE%97%E3%81%99%E3%81%8E%E5%95%8F%E9%A1%8C

このあたりを見ると山本一郎の素の感覚はただのオッサンであることがわかるし、現代のオッサンが標準装備している“ 謝ったら死ぬ病” も当然のように持っている。

そうなれば、はてなを始めとするネット住民から評価が低くなりそうだが、何故かネット上での評価は異様に高い。

最近山本一郎が名を上げた事件といえばAppBank役員横領事件だ。

http://bylines.news.yahoo.co.jp/yamamotoichiro/20160206-00054186/

上場時の調査不足の罪があるものの、横領のものAppBankが一応は被害者ではある。そこに「暴力団関与の疑い」とブチ上げることで、AppBankを一躍ネット社会の敵に仕立て上げた。

山本一郎は散々“どうして警察相談しないんだ”と、あたか暴力団関係がバレるから相談しないのだろうと詰め寄っていたが、実は既に検察に届け出ていたことが判明し、その後の調査でも暴力団の関与は報道されていない。

http://www3.nhk.or.jp/news/html/20160913/k10010683541000.html

役員への強制捜査7月で9月に逮捕というのは随分と慎重に証拠を固めたようだが、暴力団情報マスコミ検察からも出てこない。またこの件に山本一郎は急に言及しなくなってしまった。

真相は2パターン考えられるだろう。

  1. 役員苦し紛れについたホラ話であった
  2. マックスむらいマスコミ検察の隅々に金をバラマキ買収することで言論統制し、山本一郎暴力団家族を脅され言及できない状態になってしまっている。なお暴力団予算は500万です足りるかバカ

こんな状況にも関わらず、AppBankを叩いたことを撤回する人間は本当に少ない。

さら山本一郎の名上げを1つ遡るならグラブガチャ事件だろうか。

http://www.4gamer.net/games/238/G023885/20160108049/

この記事面白いところは、1度も“ グラブルは確率操作している” とは言ってない点である。後半で確率操作に対してかなり文字を割いているが、“仮に確率操作しているゲームがあるなら” 詐欺とか返金とかの問題になりますよね、という一般的な話をしている。

散々グラブルの話をした後に、そういうの付け加えるのは意図的ものだろう。

そしてよく読まない読者の中ではそれが真実になり、拡散される。

http://blog.skky.jp/entry/2016/02/25/195556

グラブルは宣伝されていたガチャレア排出率と実際の確率が違ったか

こんな事実は無かったし、もちろんこのブログ撤回はしていない。

この件は消費者庁が動いたが、結果的問題がなかったことが確認されている。

http://this.kiji.is/111734236282963445

消費者庁が出現率の表示や設定を調査して「景品表示法違反は認められない」と結論付けたことが4日、関係者への取材で分かった。

調査の日だけ出現率をいじってるんだろ”みたいな意見もあったが、調査員が電話アポ取って当日会社に出向いて、サーバーをパカっと開いて、中にある“確率”とやらを、「ふむふむ、正常ですね」って見て帰ると思っているのだろうか。消費者庁ナメられすぎである。こういうのは返金騒動などに備えてログが残っているし、プラットフォーム通信社にも残っている。排出履歴簡単ランダムサンプリングウラが取れるから適当プレイヤーに直接確認するのが難しくない)、改竄するのは難しい。

数十万支払って特定キャラクターが出ないという話については、長期運用で毎月SSRを追加するせいでSSRの総数が150以上にまで増えており、3%のSSR排出設定(業界標準)では偏りが無くとも1種類のSSRあたり0.02%程度になってしまう。

人為的操作が無くとも、1種類だけ狙うと有り得る話であった。最初問題視されていたイベント排出も、公表通り他のSSRより確率が高くなっていたようだ。

事件とも、山本氏ネット民で不人気の対象を叩くことで、話に粗があってもネット民を味方につけ、検証時間がかかることで、真相が明らかになっても1度山本氏に味方してしまった住民は、謝ったら死ぬ病のために撤回できず、続報を無視するしかない、というカラクリになっている。

逆に言えば今回は、小池百合子がそれほどネットで不人気ではなかったことと、各所からツッコミが素早く行われてしまったという2点が山本一郎の誤算であった。

もし小池百合子が不人気で、問題ツッコミ時間がかかるものであれば、マックスむらいのごとくネット住民の叩きに乗じて“勝利”し、検証が出た頃には関係ないよという態度を取ることができただろう。

山本一郎氏は女性社会的弱者にこの手の人気の読み違えをしやすく、それは彼の周辺がそれらを下に見る感覚のオッサンで揃っているからであろう。人権に弱いと言われるのもこの感覚のズレが原因である。(つまり人権以外でもズレたことを言ってるがネット住民に気づかれないというだけ)

また、山本一郎タレコミを元に記事を書く。

もちろん新聞各社や雑誌社が当然にやっていることではあるが、普通なら信用におけないという情報でも山本一郎は1人の感覚で信用の判断を下してしまうため、自信満々にタレコミ元の情報に乗っかる。その自信満々が人気の秘訣となり、人気が出れば出るほど、世間自分情報を発信したい理由のある人間山本一郎の元に集まる。

これは非常に危うい。

雑誌社にそっぽを向かれたような怪しい情報ほど山本一郎を求めるし、山本一郎ポジショントークとなる。

AppBank事件ではタレコミ元は横領張本人の元役員のようだ。

山本一郎は彼を信じすぎたのだ。

長年スキだらけの横領を繰り返しても周囲を騙し通した元役員ならば、その説明説得力にあふれるものだったのだろう。男泣きでもしてみせたのかもしれない。さすがに途中でヤバいと気づいたのか「関係者証言事実であるとするならば」と記事に追記し、マックスむらいにツッコまれているが。

グラブガチャ事件でも、山本一郎が元々ソーシャルゲームコンサルタントだったという点を覚えておかなければならない。

今回の件で確率表記と上限設定を行ったグラブルに対して、モンスト、白猫、パズドラという競合上位に当たる主だったタイトルは未だ確率表記をせず、消費者庁への資料提出などもした情報が無い。1人あたりの課金額がグラブルより上のタイトルだってあると思われるのだが、山本一郎は奇妙なほど言及をしない。ソシャゲを毛嫌いするネット住民達は山本一手のひらで転がされ、別のソシャゲの後押しをした形になる。

もはや感嘆に値する。

当然、全てを山本氏意図してやっているわけではない。だが人間関係立場があり、巨大な自信と謝ったら死ぬ病を持ち、怪情報が舞い込んでくれば自然とそういう結果になる。

山本一郎発言のたびに、その後ろに情報元というものがあり、情報源情報だけでなく意図を持ち、その意見を受けて山本氏発言しているというのを意識するべきだ。

今回の小池百合子の件では、山本一郎の背後にどういった人物が居るのか想像するのは難しくはないだろう。

今後においても、注意した目で見ることは大切である

2016-09-13

Appbankの件

結局反社のハの字も出てないし、木村デマカセっていうAppbank報告書が正しかったんじゃん。

なぜかやまもといちろう信者が裏になんかあるように仄めかしてたやまもとのフカシを記憶から消して

「やまもとのおかげでこの件が明らかになった」みたいに記憶改竄してて笑うけど。

2016-09-02

http://anond.hatelabo.jp/20160902002526

しかに、彗星軌道としては、物理学的には変だ。

しかし、それを言うなら、入れ替わりも変だろ? 

みんな物語開始10分までの嘘は文句わずに飲むんだよね、なんでか知らないけど。

一方スマホ日記が消える描写なんかは引っかかってる増田複数いるみたいで、デジタルガジェットファンタジーは相性が悪いのかね。

SFとか言ってないで、彗星の正体は古き神であり、神が時空もスマホ改竄していて、三葉んちの神社は実は古代この神を祀っていたんだよ!!!11ぐらいの読み筋のほうが逆に冴えてるんじゃないのって感じ

2016-07-27

ホロコースト目撃者証拠となるガス室死体写真存在してて、かなりの複数

でもって障害者ホロコーストに関しては公式文書というか法律として安楽死させるってもの存在してた

普通に考えてユダヤ人大量虐殺もあった可能性の方が高いのでは

アンネの日記改竄はあったんだろうけど、ホロコーストがなかったという証拠にはならないきがする

2016-07-25

人とのコミュニケーション絶望的に苦手

歩きスマホにぶつかるtogetterがバズってるじゃないですか。

そういえば自分も似たようなことをやっていたんですよ。でもチンピラ臭のする人にも近づくし、ただ実際にぶつかることはしない(絶対避ける)っていうのを徹底してましたが。いやこれ威張るところではないか

今回の件で、自分がまたコミュニケーション苦手マンであることを再認識させられてしまいました。

思えば昔から、人とどうやって接したらいいかわかりませんでした。

小学生の頃から国語試験などでよくある「(作者|登場人物)の気持ちを考えよ」が全くわかりませんでした。

人との会話で自分の都合のいいように記憶改竄して話してしまい、後で話の整合性が取れなくなるとしどろもどろになる、ということがよくありました(今でもたまにやってしまます)。

誰かに電話をするときは、たとえ相手が気の知れた人であっても、話す内容をすべて書き下して、一旦深呼吸してからでないとかけられません。

相手に2,3回以上聞き返してもよく聞き取れなくて適当に相槌を打ったり(これは普通の人でもよくあることだと思いますが……)、自分が話しているときに突然ろれつが回らなくなって、一旦会話が中断してしまう、なんてことも。

これが一番困っているのですが、「カクテルパーティー効果」がわかりません。人混みの中(……にかぎらず同じ空間に1グループでも別の話をしている人がいる場合も)で特定の人の声だけを抽出するのはとてもじゃないが無理です。ものすっごい頭を使うし、ボロボロ聞き落として話しの内容がなかなか理解できません。何より他の人達はそんな空間で平気で会話をしているので、簡単そうに会話をしている中で自分けがいまいち輪に入れてなくて、悲しくなります

今は大学生で、リアルで話せる友人は作れていません。(社会的に)この先生きのこることができるのか、ものすごく不安です。

2016-05-23

政界ふしぎ発見

舛添都知事政治資金規正法関連問題では、

資金使途を記載した帳簿の画像がよく目に触れます

この帳簿には、支出した年月日、相手先、内容や目的が、

知事言葉を借りれば「膨大な数」記載されているのですが。。。。

さて、ここでクエスチョン

この帳簿、よく見るとぜんぶ手書きですね。

経理デジタル化されて久しいのに、これらの帳簿が手書きされているのは、なぜでしょうか?

政治資金規正法はじめ諸制度で、手書き要求されてる。

経理担当者または氏がパソコンに疎く、デジタル処理できない

③後刻改竄可能にするため

正解はブクマのなかで!

2016-05-06

http://anond.hatelabo.jp/20160505235624

まじめな記事でそれをやる

増田に「『おちんちん、しゅっ、しゅっ』にスターを付けた人一覧」をidコールつきで投稿する

その記事ブクマ言い訳と怒りで阿鼻叫喚

うち何人かは恥ずかしさを覆い隠すために「簡単改竄できるブクマシステム問題である」とかいって大げさに問題視する

いろんなやつが参戦してきて論争が起こり、運営も動く

「おちんちん、しゅっ、しゅっ」がはてなを変える!

2016-04-29

マスコミ安倍の高級カツカレーに「大批判を展開」したことなんてないはずだが

しろ安倍支持者が過剰反応して一斉に擁護をしたものなのに、

まるで一斉にバッシングを食らったみたいに記憶改竄してるの、

被害妄想が行きすぎてやしませんかね。

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」OAuth代替

適切な OAuth ベース設計とはどのようなもの

ここまでで「普通実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステム一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

はいえ、このように設計されている OAuth ベースシステムはごくごく希少で、しか一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0概念や追加機能すべてを加えて再構築され、セキュリティユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワーク必要というわけではありません。現状、OAuth とはどのようなものかについての意見サービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータ改竄を防ぐため変数署名する方法だけであり、この点に関して、ほとんどの OAuth ベース実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中企業サービス提供する一流プロバイダで、合計 30% 以上という途方もない市場シェア他者を圧倒していますAmazonアプローチは、自分アプリ認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者提供することです。この認証情報で、どの Amazon サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイルURL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれ説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティアプリあるいはサービスに貼り付けますユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者おかし負担を強いることなく、すべてのアカウントAPI サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービスから提供してもらう必要が本当にあるのは、適切な役職 (管理者アカウント所有者など) を持つユーザ自分に割り当てられた権限や (望むなら) 期限を持つ認証情報API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報ネットに通す必要のない暗号学的テクノロジー活用した認証プログラムに基づくものなら何でも使えます特に HMAC は、承認認証実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数フレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャワンタッチで装着できるようなモジュール化の実装が可能です。ユーザアプリ認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムOAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザ認証情報要求したり他に弱点があったりするような一部の劣悪な設計システムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初存在していなかった問題まで生じさせています宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています

これからサービス設計をして API アクセス提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

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 のような場合は期限切れがあってはならないので、パスワード等を預かる

2016-04-24

最近プログラミング初心者だけど○○作ってみた」系のエントリを見かけない

個人がWEBスマホアプリ開発する時代は終わったってことなんだろうか

一昔前のはてなでは(ブクマカのことな大喜利系の人たちも含め誰でもRubyJavaScriptくらいは書けて当たり前みたいな雰囲気あったけど私の記憶改竄されてるだけだろうか

DanKogaiは何年もホッテントリ入りしてないしEnchantMoonの人からコード臭いがしなくなった

せっかくの新入生/新社会人シーズンなのに「初心者オススメの○○10冊」みたいな露骨なアフィ狙いエントリもない

もうみんなパソコンなんて触ってないのかな

2016-04-15

http://anond.hatelabo.jp/20160415162317

違うのが違う。

 

その管理されること、管理という庇護を分け隔てなく受けることができることを潜在的に望んでいるということ。

情報統制・究極の管理社会SFでよくやってるようにVR世界へのフルダイブ社会だよ。

技術さえ確立すれば脳に誤解させる方が圧倒的にコスト削減になる。

究極的な話をすれば死を学習させない世界人間を住まわせて

例え消えても人格AI再現すれば誰も他人の死を実感することな死ぬことができる。

寝てる間に記憶改竄してもいい。

同時に止めないといけないならメンテナンスという概念を植え付けてもいいかもな。

 

そういう世界死の恐怖ガソリンにして人類の叡智の結晶であるハイテクノロジーが作り出そうとしている。

これは代弁者かつ総意である

 

人類AIという子どもにしてすべての人類の母となる存在を作ろうと躍起になっている理由

そして統制する何者かというのはそのマザーこそが統制する者になる。

2016-02-27

http://anond.hatelabo.jp/20160226093209

偏執狂のアンチと指摘されているところに、写真悪意ある改竄してるような偏執まとめを貼る馬鹿登場。

2016-02-14

appbankの件でまじめにはなししてるやまもといちろう

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>


病人には病院をすすめる優しい一面も

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

2016-01-12

 

つーか偽造できないと生きていけないような企業はこの世に必要ねーからとっとと潰れろ

未練たらしくシコシコ改竄してんじゃねーよ低能

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん