 
|
はてなキーワード: 暗号とは
====
http://www.wanichan.com/pc/word/2007/toc/
http://www.eurus.dti.ne.jp/yoneyama/Word2007/word2007-mokuji.html
Word 2007、Excel 2007、PowerPoint 2007 で既定の暗号化プロバイダを変更する方法
http://support.microsoft.com/kb/937914/ja
ハッカーvs米政府、サイバー戦争に突入か | ビジネス | 最新記事 | ...
http://www.newsweekjapan.jp/stories/business/2012/02/vs-6.php
PCでの複数コアの主な使い方というのは、まるで違う用途のタスクをそれぞれのコアに割り振って、一番負荷のかかるメインのタスクを停止させないことでキャッシュメモリのフラッシュ回数を激減させることにより、システム全体のスループットを若干上げるためにあるのだと考えてた。
たとえばにAコアでメイングラフィック、Bコアで音声処理/ネットワークでOS(ディスクや入力I/O)みたいな。
セマフォだの同期処理だのまったく考えずにマルチコアの恩恵をそれなりに受けることができる手法って、ほかにないですよね。
ちょっと前に話題になったヘテロジニアスマルチコアなんて、モロ的にそういう発想ですよね。
動画デコードに特化したコアとか、アフィン変換に特化した不動少数SIMDコアとか、AESなど暗号専用のコアとか、それらをまとめる一般整数コアなどまとめて、今までより速いのを安く低消費電力で作って、車載ナビで地デジもネットもゲームもokにしちまおうぜみたいな。
最近のPCは、それとはまた違うアプローチで、CPUコア同様のGPUコアももうすこし自由に使えるような仕組みを増やして、性能稼ごうって方向みたいですが。
ビジネス書を呼んだり、一般メディア向けの経営者の話を聞くときに大事なのは、
彼らがその言葉によって、本当は何を言っているのかをつかむ。
言葉ではなくて、彼らの人格そのものを掴みに行く。これが大事だ。
自分たちの言語感覚で文章を読むと、実質と全く違う理解をしてしまうので注意。
おあつらえ向きの例がホッテントリしたので紹介する。
以下の3タイプの人材を、管理職としてふさわしい順に並べるとどうなるだろうか。
A 人格がよくて、実績のある人
B 人格が悪くて、実績のある人
C 人格がよくて、実績のない人
しかし実際はB＞＞＞＞＞A（越えられない壁）C であるとする。
その答えがこちら（※）
http://president.jp/articles/-/5483
「がむしゃらに熱狂して寝食を忘れるほど働く」＝人格者という定義にすれば、AとBが入れ替わる。
・見えない基準を設定してCとAを接近させる
実績より人格と言ってるが実績の「足切りライン」を相当高く設定する。
そうすれば実質的にはCでもAと同じということになる。
よく考えない読者はCのような人間は最初から想定されていないことを自覚したときにはもう手遅れ。
（足切りラインの話さえしなければ「ウソはついていない。本当のことは言わなかっただけだ」ということにできる）
他にも
・質問者の質問の意図をあえて誤解して、言葉面だけは相手の要望通りにする
などのテクニックを使えば、B＞＞＞＞＞A（越えられない壁）Cな会社でも、A>C>Bと胸を張って応えることができる。
そして、実際そういうテクニックを駆使する企業経営者はたくさんいるので注意。
これらの暗号化された文章をDecryptせずに、圧縮されたままで読むと
実際に言ってることと全く逆の理解をしてしまうことになるだろう。
わぁ、なんてアットホームで人間性を大事にする職場なんだろうって理解してしまうかもしれない。
実際かなりの学生がテンプレ化された「アットホームな職場です」などは釣りだとわかっても、
ちょっと工夫しただけで簡単に騙される。
綺麗な言葉で粉飾してはいるが、現実は厳しいぞってちゃんと書いてる就活情報を
自分の都合の良い用に勘違いして「騙された」と喚く見苦しい学生たちは毎年の風物詩だ。
オレオレ詐欺がいつまでたっても減らないのは、ターゲットがじーちゃんばーちゃんだからという理由だけはない。
彼らが簡単に騙されるのは、言葉だけで相手を理解しようとするからだ。
ちゃんと相手の人を見極める訓練ができてないのだ。
こういう言語運用ゲームの経験がない人は、是非「悪魔の辞典」を購入して３回通読することをおすすめする。
（※）私はこの文章がB＞＞＞＞＞A（越えられない壁）Cな会社の社長でも同じ事を言えるということが主張したいのであり
決してサイバーエージェントそのものがこういう会社であると指摘しているわけではありません。
そう、しいて言えば「サイバーエージェント的なるもの」の病理を指摘しているに過ぎません。
直接経営していない人が経営者をしったかぶって批判することは有意義であり、
サイバーエージェントのような会社を指示している民衆を批判しているのであって
私はサイバーエージェントに個人攻撃などしていない（キリッ
真面目な話昔はサイバーエージェントはブラック企業だったらしいけど、最近はすごく良くなったらしいです。これはホント。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
ブコメには「Googleが勝手に盗んだのにこっちがオプトアウトしなきゃいかんとは何事だ」というものが多いが、それらは問題を根本的に誤解している。
(もしかすると総務省、ストリートビュー車の無線LAN傍受でGoogleに指導。再発防止策と日本語で周知を要求 -- Engadget Japaneseの件と混同している人がいるのかもしれない。これはビーコン信号ではなく通信内容そのものを傍受していたという話で、基本的には別件である――但し、法解釈によっては同じ問題ともなり得るし、根底に共通している部分はある。これは論点がズレるので、ここでは完全に別件として扱う)
そもそもの問題は、Wi-Fiの仕様において、Wi-Fi機器のMACアドレスが強制タレ流しになっていることにある。これは例えばSSIDステルスの設定でも止めることはできない。
つまり、あくまでGoogleは垂れ流されている情報を集めたに過ぎないということである。垂れ流されているものなら勝手に集めてもいいのかという論点はあり得るが、その点についてはGoogleだけを責めても全く意味がない。誰であれ収集は可能だからだ。「しかし、他の誰がそんなことをするのか？」との反駁には「はい、PlaceEngineがしています」が答えになる。仕組みは全く同じだ。PlaceEngineは、Googleのような巨大企業でなくてもこの技術を商用レベルにまで持って行けるということを既に証明している。
つまり、この問題は「GoogleのDBから削除してもらう」だけでは全く解決しない。
(追記: どうもこの節の表現は誤解を招いたようだ。「できるからやってもいい、Googleは悪くない」という意味ではない。その議論があること、今後も必要なことは承知の上で、そもそも「できる」こと自体が根本的な問題であり、しかも各国の現行法において確実に違法な行為ではないということが重要だ。何度でも言うが、Googleを憎んでも問題は全く解決しない。あくまでここでは問題の本質を理解することと、現実的で効果的な解決方法について考えたい――もちろん、GoogleやAppleやMSなどを相手取って世界中で訴訟を起こす、というのも一つの手だろう。今のところ強制力を持ちたいなら勝訴の判例を作るしかないし、勝訴すれば抑止力を備えた最強の解決手段になる。どうぞ。)
(a) 「申し出のあったMACアドレスは削除し、今後も登録しないようにする」という対応
技術的にはすぐにでも対応可能。ただし、本人以外の手によって無差別に大量のアクセスポイントを削除するという妨害行為を防止できないかもしれない。
PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して、そのような手段が用意されていることを周知しなくては問題は解決したといえず、十分な周知は困難と思われる。
新たなアクセスポイントを購入するごとに削除手続きをする必要があることについて納得しない者が、「私のものは登録するな」という主張で争ってきたら対応できない。
(b) 「SSIDステルス設定にしているアクセスポイントは、登録拒否の意思があるとみなして、登録しない仕組みとし、また、既に登録されているものは次回検出時に自動的に削除されるようにする」という対応
技術的には容易に可能。しかし、そのような仕様であることを周知しなくてはならない。PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して周知しなくては問題は解決したといえない。
(c) 「暗号化設定されているアクセスポイントは登録せず、他は削除する」という対応
暗号化していないアクセスポイントは特定の相手方に対してのものではないとみなすことで、電波法59条の問題をクリアできるかもしれない。
しかし、これを採用すると登録アクセスポイント数が減ってしまい、位置の測定制度が低下する。
(d) 所有者の同意を得たアクセスポイントしか登録せず、他は削除する」という対応
まず、ブコメで要求されているような「オプトイン」の仕組みは(d)だが、これは実現性に乏しいと考えられる。どうやってオプトインするんだという問題もあるわけだが、そもそも「誰でも収集できる」のだから、個別にオプトインなど根本的に不可能であるし、無意味でもある。例えGoogleが独自にオプトイン方法を用意したとしても本質的な問題は全く解決しないばかりか、ユーザに「Googleでオプトインしなければ安心」という誤解を与えかねないという懸念もある。
(b)や(c)についてはサービスプロバイダ側の設計の問題であり、ユーザは関与することができない。
今回Googleが提案した方法は、(a)の改良型(あるいは(a)～(c)のハイブリッド)というべきものである。再掲。
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
オプトアウトという意味では、(b)のSSIDステルス法も同様である。それよりも_nomapが優れているのは、これが「うちのAPをマッピングしないでくれ」という明確な意思表示となるからだ。
SSIDステルスや暗号化をオプトアウトフラグとして扱うかどうかは単に実装に期待するしかないが、_nomapがデファクトになれば、万一オプトアウトが実装されずにマッピングされた際「俺は一般的に合意されている方法でマッピング拒否の意思表示をしていたぞ！」と法的に主張できる可能性がある。Wi-Fiの規格に変更を加えるものでもなく、この用途以外に意味を持たないことから、デファクトとして広まりやすいだろう。確かにSSID変更が困難なケースは考え得るが、しかしこれ以上に簡単な代案は私には考えられない。
解決しない。
ここに挙げたどの方法を採ろうとも、原理的に「サービスプロバイダのマナー」程度にしかなりようがないからだ。オプトインですら、である。robots.txtを無視するクローラを根絶することができないことにも似ている。そしてそれは、Googleの責任ではないし、Googleに責を負わせても全く意味がない。
最初に述べた通り、そもそもの問題は「Wi-Fi機器がMACアドレスをタレ流しにしている」ことであり、これはWi-Fiの仕様改訂で対応しないとどうしようもない。また、対応したとして、新方式へ完全に置き換わるまでには気が遠くなるほどの長い時間が必要だろう。WEPすら未だに根絶できないというのに。
また、Wi-FiはMACアドレスをタレ流しているぞ、これは防げないぞ、という啓蒙ももっと必要だろう。一般ユーザには何のことやらさっぱりわからないと思うが、それでも啓蒙しないよりはマシである。
一つ付け加えるなら、個人的には、デファクトとなり得るオプトアウト方法を提示したGoogleさんはもうちょっと褒められてもいいと思う。これはAppleやPlaceEngineが今までしてこなかったことだ。
ちなみに、Google Location Serverでは既に「2つ以上のMACアドレスがDBとマッチしないと位置情報を返さない」などの様々な対策を実施済のようである。これにより、もしMACアドレスやSSIDが漏れたとしても、その所在地をこんな方法で正確に掴むことは困難になっている。PlaceEngineは知らない。
もう一つ。この問題は、Wi-Fiだけに起こりうる問題ではない。ひろみちゅ先生は本来この問題をRFIDの普及によって起こりうる問題として予測していたそうである。この辺りもっと知りたい方はgoogle:高木浩光 PlaceEngineとかして勝手に読んでください。
PlaceEngineより、Googleの提唱する_nomap方式のオプトアウトに準拠する旨のリリースが出た。
PlaceEngineデータベースにおける無線LANアクセスポイント(AP)情報の取り扱いについて
Google社から、Google Location Service のWi-Fi位置情報データベースから無線LANアクセスポイント情報を削除するためのオプトアウト方法（SSIDに"_nomap"文字列を追記する方法）が公開されました。
PlaceEngine サービスにおいても、Google社のオプトアウト方法に準拠する形でPlaceEngine位置推定データベースから該当するAP情報を削除する運用を実施する予定です。具体的な実施時期や運用方法については、別途お知らせします。
また、PlaceEngineサービスにおいては、以前より、主にモバイルルーターなどに対応するため、オプトアウト(削除)したいMACアドレスをサポート窓口へ送付して頂く方法などをとっておりましたが、こちらについても引き続き運用していきます。（「位置推定の改善」をご参照ください）
これこそがまさにGoogleの狙った効果だ。素早くデファクトになり得る。すると次の段階として、Wi-Fi機器の製造者が設定画面に「☑位置情報サービスからオプトアウトする(SSID末尾に_nomapを付加する)」のような項目を用意することが標準化する、などといった流れに進むことも期待できそうだ。これには一層の啓蒙活動が必要になるが、十分に現実的な範囲だ。
そして、「Wi-Fiだけの問題ではない」と書いた通り、あっさり同種の別問題が持ち上がってきた。今後、この手の問題はゴロゴロ出てくるだろう。そもそもどこまでが許される範囲でどこからが許されないのかといった大枠の議論も含め、どんどん問題にして世界中で合意やルールを形成してゆく必要がある。先は長い。
http://www.chibanippo.co.jp/cn/news/national/64485
警視庁と愛知、千葉など１６道府県警は８日までに、ファイル共有ソフトを使ってインターネット上で児童ポルノ動画を配ったとして、児童買春・ポルノ禁止法違反などの疑いで２３都道府県の６１カ所を一斉に家宅捜索・・・１９人を逮捕した。ほかに１９人を近く書類送検する。
警察の面子をかけた全国一斉家宅捜索で6割ちょっとの検挙率というのははっきり言って杜撰ではないか。（いや優秀な方だと言われるとあれだけど）
何の罪にもならないにもかかわらず家宅捜索された者は誤認捜査、冤罪と感じるだろうし、一般的な市民感覚から言っても冤罪の語は大げさではない。
市民の基本的人権擁護のために捜査機関は謙抑的でなければならないという謙抑性の観点からも問題だ。
また、4割も外れが出る当てずっぽう捜査だとわかってしまえば、違法アップロード者も対策を立ててしまうだろう。
おそらく警察は児童ポルノをアップロードしたIPからプロバイダに住所を開示させ、家宅捜索していると思うが、警察側からはそのIPが使われたことはわかっても誰が使ったかまでかはわからないから、家宅捜索の目的のひとつは容疑者が当該IPを使って違法アップロードした証拠を得ることだろう。
そうすると、違法アップロード者としては、当該IPを使える者が他にもいたことにするため、HDDをtruecryptなどでまるごと暗号化して証拠を出さないようにした上で、兄弟や親子のうち誰がアップロードしたかわからないようにしたり、友人と回線を共有したり、わざと野良AP化したりすることが考えられる。
この記事は中立として書かれてないのが非常に残念。Pixiv攻撃側（実際は攻撃してない）を攻撃する立場を常に取ってるので、擁護と取られても仕方がない書き方をしている。
私的な意見だが、これを見て安心したり、馬鹿が騒いでるだけかと思った人は少し考えるようにして欲しい。あまりに短絡的ではないだろうか。
問題を整理するが、「今回危ないと騒いだ人」＝「喚起サイド」（上記Pixivを攻撃した側と同じグループ）とし、「大丈夫だよと返した技術者及びそれに同調した人」＝「安全サイド」とする。
これは以前から騒がれていた。これに対してPixiv公式は対応すると発表しているが、公表した時期が過ぎてもいまだに対策がなされていない。
この問題が再び取り上げられたのだろう。
こちらは新しい問題。管理者権限のためのページがほぼ一般公開されているというものだ。
普段こういうものは見えないようになっていたり、特定IP以外は弾くような仕組みになっている。
それが一般人でも見えるようになってしまっていることが今回の問題である。
これらの問題に対して技術者たちも勿論反論している。
ここでは私なりの考えを述べる。
「全数探索攻撃」「ブルートフォースアタック」はその必要オーダー（計算時間）の大きさから攻撃はされないだろうという意見があった。
これは先の喚起サイドも承知していることだった。安全サイドも知っていることである。
わかりやすい攻撃例としてこの攻撃が挙げられたのであって、実際様々な攻撃手段が存在することは両サイドも理解している筈である。
問題は「IDが丸見え」に対して、「適当にパスワードを入れて試すにはいくらでも試せる」ことである。攻撃の成功失敗は問わず、攻撃の可否を問題視している。
TwitterやGmailを例に挙げて「ID丸見えでしょ？」という人がいるが、ずっと前から攻撃の可否を抑えるために誤入力が続くとアカウントにロックをかけてログイン制限を設けてるようにしている。
実際この騒動を受けてPixivは誤入力が続くとログインの制限を行うようにした。現在もこの仕様（IPアドレスによるログイン制限のようだ）は続いており、これは評価されるべきである。
ただ個人的な意見を言えば、何故IPアドレスによるログイン制限なのかが不明である。多目的による複数アカウントを許可しているPixivならばアカウントにロックが定石ではないだろうか。
管理者権限IDとパスワードがわからなければ攻撃されない。両者を当てることは非常に困難という意見があった。
これは正論である。そしてこれが安全サイドの誤解を招いたと考えている。
喚起サイドは常に「危険があるかもしれないから、パスワードを変えてしばらくログインしない方がいい」という「危険性を提示していた」に過ぎないのだ。
しかしTwitterなどでは「ハッキングされたの？されてないの？」という悪魔の存在証明の答えを聞きたがっていた。
そこに先述の安全性を証明する意見が来た。これにより安全サイドは安心した。勿論これは「経験則上は安心していいこと」である。現在使われてる通信暗号も「経験則上は安全が証明されてる」ので。
ただその後の動きが不穏だった。喚起サイドを「Pixivを攻撃したいだけの連中が騒いでた」と非難し始めたことである。
とある人のTogetterが発端となったが、これは後述する。
ソニーコンピュータエンターテイメントの個人情報流出事件とは性質が違うが、「発覚してからでは遅いから予防策を行う」のが定石である。
特に今回の問題は外からでは何もわからないため、喚起サイドは提示することしかできなかったのだ。南京錠で戸締りされた誰もいない豪邸の中から物音がすれば、怪しいと思わないだろうか。
ある人のTogetterが安全サイドを悪魔の存在証明にシフトさせていったと考えられる。
先述しているが、「結果的には経験則上は安全である」ためこの人のTogetterが間違っているというわけではない。
しかしどちらにもならない、観測されて初めて成立する量子論的な考えに、観測される以前から成立している古典力学的な考えを適用することがナンセンスである。
古典力学的な考えの方が大勢にわかりやすく受け入れやすいのは確かであるだけに、悪魔の存在証明にシフトする非常に残念な動きが見られた。
まとめとして、
・喚起サイドは情報の強化を行ってこそ成り立ったが、それが出来なかったことに落ち度がある。もっと情報を強化し、慎重に動くべきだった。
・安全サイドは経験則上安全であっても、危険性の提示であったことを理解するべきである。もしかしたら？を考えるのが技術者の常ではないだろうか。
・安全サイドの同調組はもう少し自分で調べるクセを付けた方がいいだろう。どこが発信源か、その場所の性質を調べるだけでも損ではないはずである。
以上が挙げられる。
http://gigazine.net/news/20110707_pyrit/
http://d.hatena.ne.jp/sen-u/20110629/p1
わざわざ再計算しているわけだけども。
saltとか考えるとまぁアリかな。
WPA2も、PMKと呼ばれる512bitのマスターキーを秒間8万9000個
解析可能だそうな。
Zipもあった。
レインボーテーブル方式が使えないのでブルートフォース一択のはずだが、
http://www.youtube.com/watch?v=3dEN9JQ3R0U
秒間6億3千万？
ひたすらクラックしているんだろうけど、
GPUってすごい。。
試しにPIKAZIPでやってみるとCorei7で秒間600万ちょいなので約100倍。
うーん。
なんか他の使い方ねーのかな。。
■音声入力ソフトを通して、テキスト化。蓄積することで検索が可能に
■声紋分析して「他人の声」も自動で個体識別し、テキスト化の際に色分け表示する。
■心拍計と万歩計、体温計も付けて、消費カロリーを推測する（睡眠時無呼吸症などの、病気を診断できれば尚良し）
■録画装置（超広角or魚眼レンズ）で、「見た物、聴いたこと、話したこと、居た場所」を全部記録し蓄積する
■暗号化して改ざん防止することで、裁判における証拠能力を持つ
22世紀、世界大戦でも起こらない限り、ほとんどの視聴覚情報、行動履歴は生涯分の蓄積が可能になっている。
ログを取っている方が多数派だから、ログの残っていない人間は、社会的に信用されず、
全社会人のログがクラウド化されることで、個人情報の海が形成されている。
（youtubeが全世界の地上波TVの全記録を収容することが可能なように）
もちろん、その個人情報を観測するアクセス権は、本人以外、誰にも与えられない。
学者に研究され、プロモーションのネタになり、市場操作の材料や、時に軍事利用される（今のテレビがそうであるように）。
プライバシーは、生データへのアクセス権、削除権と、限りなく同義になる。
或いは、葬儀のセレモニーの一部に、「生涯データの全削除」が追加されるのかもしれないし、
ホスピスで、ニッコリ笑った看護師さんに「全削除になさいますか、それとも全凍結で50年後公開にいたしましょうか？」と訊かれるかもしれない。
まぁ、そんなわけは、無いんだけどね。
HTMLはわかるけど、サーバーサイドはお遊びでphpを触ったぐらいだったので、会員制でデータをためこむサイト作りに初めて挑戦した。
今回重視したのは、「いかに個人情報をお漏らししないようにして、万が一漏らしても被害を少なくするか」ということ。
世の中、有償サービスでもパスワードを平文で保存してるサービスが意外と多いらしいので、流出した時のリスクを少しでも減らせる対策として書きます。
サーバー：ロケットネットのキャンペーンにでレンタルサーバ年１０００円ポッキリプラン クライアント側の処理：HTML+CSS+jQuery（とプラグインもろもろ） サーバ側の処理：PHP Webサーバー：Apache データベース：MySQL
俺も巻き込まれたところでは、サミータウンがメールアドレスとパスワードセットでお漏らししてお詫びに１ヶ月無料なにそれこわい。
サミータウンだけならまだいいけど、メアドとパスワードを他のサービスで共通化して使ってる情弱なので、
共通化してメアドとパスワードをどこかのサービスが一箇所でも漏らすと、ヤフオクID乗っ取り事件みたいなことになる。
http://internet.watch.impress.co.jp/cda/news/2008/09/26/20967.html
俺だってできれば人様のメールアドレスとパスワードとか預かりたくない。
万が一、肉親のメールドレスを発見してパスワードにrapemeとか入ってたら明日からどういう顔すればいいかわからない。
ググってみてもどこにも情報のってない。うーん困った。ダメもとで「個人情報ってどうやって保存したらいいんだろう。。。」
って、twitterでつぶやいたら、「住所とかは可逆暗号化でいいけど、パスワードはハッシュで不可逆化しないとだめだよ！」
「住所とかは可逆暗号化でいいけど、パスワードはハッシュで不可逆化しないとだめだよ！」
何のことかわからなったので、調べてみると、
・ハッシュ＝ハッシュ値を使った、元のデータに戻せない暗号化方式
うーん。。。よくわからん。。。
電話番号とか住所は、第三者が使用する情報なので、可逆が必要。パスワードは、認証にしか使わないので、
ハッシュ値の結果が一致すれば元のデータがわからなくてもOK、という方式なのでこういった暗号の使い分けをする。
●可逆暗号のイメージ（もとにもどせる） 暗号化キーは開発者が指定する。 090-xxxx-xxxx →（暗号化）→ !'&amp;%($% →（復号化）→ 090-xxxx-xxxx ●ハッシュのイメージ（もとにもどせない） 登録password（DBに保存）→（ハッシュ値抽出）→!"$#'$#=" ログインpassword →（ハッシュ値抽出）→!"$#'$#=" ※二つのハッシュ値が合っていれば、パスワード一致として認証する。
今回はMySQLの関数で実現した。encode関数で暗号化して、decode関数でもとに戻す。
例えばtel_noという項目だけあるテーブルがあるとすると、
//データベースに保存する時 insert into テーブル名 (tel_no) values (encode(tel_no,'暗号化キー')); //データベースから取得する時 select decode(tel_no,'暗号化キー') from テーブル名;
これで、データベース格納時は暗号化（バイナリ化）されて、データベースから取り出してHTML表示する時に復号化はされる。
＜ユーザ登録時＞
$password=（フォームから取得） $hash=hash('sha512',$password) //ユーザ登録時は、ここで生成した$hashをデータベースにぶっこむ。
ユーザ認証時は、入力されたパスワードと、データベースのパスワードが一致するかチェック。
//フォームから入力されたパスワード $input_password=（フォームから取得） $input_hash=hash('sha512',$input_password); //MySQLに保存されたパスワードを取得（略） $db_hash==（データベースから取得） //判定 if($input_hash==$db_hash) echo 'ログインしますよ！'; //ここにログイン処理を書く else die('メアドとパスワードがあってないよ！');
これでもしSQLインジェクションとかでデータが流出しても、ハッシュ暗号のパスワードに関してはまず解析されないはず。。。
可逆暗号のデータもphp側の暗号化キーが盗まれない限りバレない。。。はず。。。
何でもかんでも暗号化するとコードが煩雑になるし、パフォーマンスにも影響でそうなので、
住所データの都道府県とか、漏れても良いような情報は暗号化しませんでした！！
個人情報保護法 2条による定義 「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）をいう。
これで、もし漏れても、俺、ウンコ漏らして臭いけど、パンツから出てないからいいよね？というレベルにはなった。はず。
万が一漏れても大丈夫！と書いたけど、そもそも漏らすなというお話になる。色々調べた結果、以下の対策をほどこした。
・当初jQuery側でSQL組み立ててPHPに渡してたので、これだと任意のSQLが実行できて漏らし放題なのでやめる。
・GETとかPOSTでDBに渡すパラメータを扱ってる場合、ちゃんとエスケープする。
例えばログイン認証するPHPで、GETメソッドでフォームからデータを取得するような場合、
$id=$_GET['id'] $pwd=$_GET['pwd'] $sql="select * from ユーザーテーブル where uid='$id' and pwd='$pwd'
とかやってると、login.php?id=admin'&pwd=' OR '1'='1とかパラメータを渡されるとあら不思議！
select *from ユーザテーブル where uid='root' and pwd='' or 1=1
で、誰でもログイン出来ちゃう！ので、mysql_real_escape_stringでエスケープしたり、渡されたパラメータが想定した値かどうか（例えば数値かどうか、とか）のチェックをいれたりする。
・保存するデータにタグやJavascriptを埋め込まれないように、保存されたデータを出力する場合はPHP側でhtmlspecialchars関数使ってエスケープするようにする。
こんな感じでお漏らし対策をした。間違いがあったら教えて欲しい。
ちなみに出来上がったサイトはこれ。
上司の挑戦状
http://d.hatena.ne.jp/Delete_All/20110322#1300804667
なんか気が向いたので作成。
部長の暗号と、その辺から拾ってきた防災マニュアルの落とし所を見つけてサクッと作成したもの。
詳細化と詰めで、この変をきちんと参考にされたほうがよいかと思います。
事業所のための「防災マニュアル」(愛知県防災局防災課防災支援チーム)
www.pref.aichi.jp/bousai/jigyousyo_manual.doc
で、ここから下が折衷案的な叩き台。見づらいのは勘弁。
地震についてのみなので、家事とかについては追記が必要。でも文章長くすると部長が読まなくなるか･･･
==============================================
1：普段の心がけ・準備
2：緊急時に実施すること
3：危機を脱してから気をつけること
4: 救急措置
1：普段の心がけ・準備
a)非常用具をあらかじめ会社・自宅に準備しておく。用意するべき品は下記6種類で、リュック等に入れて取り出しやすい場所に保管しておく。※定期的に賞味期限等を確認すること
【防災用品】・携帯ラジオ ・懐中電灯 ・ヘルメット ・防災ずきん ・ロープ ・非常用のトイレ ・手動の携帯充電器 ・紐つき笛 ・乾電池 ・ヘルメット
【貴重品・身分証明】・現金（小銭も必要） ・預金通帳や有価証券の写し ・健康保険証の写し ・認印 ・年金手帳 ・家の鍵 ・免許証
【食料品関係】・飲料水（１人最低１日３リットル） ・乾パンやクラッカー ・レトルト食品 ・ビタミン剤 ・缶詰（缶きりや栓抜きも忘れずに） ・粉ミルク、哺乳瓶（赤ちゃんがいる家庭は必需品） ・嗜好品
【衣類関係】・下着（家族分） ・衣類（長袖も忘れずに） ・雨具 ・タオル ・マスク10枚 ・メガネ(衛生不安からコンタクトは難あり）
【医療用品】・ばんそうこう ・包帯、ガーゼ ・消毒薬 ・常備薬 ・鎮痛剤、胃腸薬等 ・紙おむつ
【その他】・ティッシュペーパー ・ウエットティッシュ ・生理用品 ・軍手 ・マッチ、ライター ・洗面具 ・ローソク ・スリッパ（スニーカー） ・筆記用具とメモ用紙 ・軍手・ポリ袋
b)家や会社の中を安全に保つ
・本棚が崩れ落ちないように整理し、テレビ・箪笥・食器棚などを固定金具で固定しておく。
・ベッドの周り・上に倒れてくる・落ちてくるようなものを置かず、安眠できるようにする。
・日々の生活の中で、災害が発生した際にすぐに対応できるよう、時間や心に余裕を持った行動を行い、また事前の情報収集を心がけること。
・ワークライフバランスを保ち、イザという時に動けるように疲労やストレスをためないでくこと。睡眠や趣味や運動を十分に行うこと。
・自宅・通勤途中・仕事場・家族の勤務先・子供の学校の5箇所について、緊急時に非難する、避難所の確認を行う。
2：緊急時に実施すること
a)地震が発生した際は、丈夫なテーブルや机などの下に避難する。ビル街では、ビルの外の広い場所(看板が落ちてこない場所)に非難する。
テレビ等を押さえることは危険なので注意すること。室内の場合、ドアを開けて非常脱出口を確保する。
b)海の近くにいた場合、津波に備えて揺れが収まり次第すぐさま高台・コンクリート製の丈夫な建物の3階以上に避難すること。
3：危機を脱してから気をつけること
被災後は、電気・ガス・水道がとまり、それによって交通機関がマヒを起こす場合がある。
交通機関のマヒが食料・毛布・薬品・ガソリンなどの物資の不足を引き起こすので、皆で分け合い、節約をして過ごすこと。
冬場に暖を取る際は、ストーブ等の一酸化炭素中毒に気をつけること。
b)不安と付き合う
被災後は、被災の恐怖と共に、日常とはかけ離れた環境に身をおくことになる。肩の力を抜いて、軽く体を動かしてリラックスするよう心がける。
十分な睡眠をとれる環境を早くつくりあげ、体温・体力・気力を維持できるようにする。
他の被災者は運命共同体であるので、冷静さと思いやりを忘れずに、相互に助け合って行動すること。
被災の恐怖を克服するために、希望のあることを考えたり、今までの生活について考えてみる。震災で受けた痛みを、正しく癒す方法や気持ちを大事にする。
4: 救急措置
被災の際に、救命処置や、応急手当を行う必要になる場合がある。
あらかじめ講習等できちんとやり方を学んでおき、非常用具に必要な道具を入れておくこと。※会社での講習実施が良い
a)救命処置
・人工呼吸
・AEDの使い方
b)応急手当
・応急手当マニュアル(メルクマニュアルや、iPhoneアプリ「家庭の医学」など)の準備
・骨折
======================================
いまこのタイミングで謎の絡み方してくる人ほんとう勘弁して欲しい。
ウソキに絡まれてたら横からエイプマンが「文句があるならおれにいえ」って口挟んできて
意味不明だからスルーしてたら「伝わってないのか」ってリプライきたから
「伝わってるけど意味わかりまん」って返したら「へえ。ばっくれるのか。じゃあもういいや」
ってなんなの。なんかの暗号？？？？？
http://h.hatena.ne.jp/Francesco3/189941257636400946
めがねおーやそらのがこれでもかとつぶされてお猿がのうのうとしてる理由がマジわかんねー
http://anond.hatelabo.jp/20110103095256
元増田の懸念はRFIDが実用化されはじめた頃に海外で議論され、実際導入を断念した企業があります。
http://wiredvision.jp/archives/200304/2003041102.html
日本でも2003年に高木浩光さんの問題提起を発端とした論争がありました。
http://www.hyuki.com/yukiwiki/wiki.cgi?RFID%C8%BF%B1%FE%A5%EA%A5%F3%A5%AF%BD%B8
この事実によって、教師の言う、
「これは君だけの意見だ」
「アンケートを取って、みんなが悪いと思うって、言ったわけじゃないだろ」
のあたりには反論できると思います。
元増田の言う懸念、
については上述の論争で主に検討されたような安価なRFIDタグ(固定IDを返すもの)がもたらすプライバシーの問題については上述の論争の中でも現実的な問題として認識されています。
何が問題なのかはネットで「固有ID問題」で検索してみてください。固有ID問題はRFIDに限らず携帯電話の「かんたんログイン」のプライバシー問題とも繋がる大きな問題です。
ただし、比較的高価なRFIDタグ(暗号技術を使用して任意の機器からはIDを特定できないもの)を使う場合は、固有ID問題は回避できます(運用次第ですが)。
教師の言う、
というのはこのことを指しているのかもしれません。実際の導入事例で本当にそうなのか確認する必要はあると思いますが。
しかし、そもそもの目的である個人の行動監視がどこまで許されるのかという問題はあります。ネットや図書館で「監視社会」で検索して、社会学や政治学の分野で様々な議論があることを確認してみてください。
また、監視されるのが子供で本人の同意がない(親の同意に基づく)場合は人権上問題が大きいと考えられます。「自己決定権」「パターナリズム」あたりのキーワードで倫理学や社会学の本を探して読んでみるとよいでしょう(このあたりはネットで検索してもノイズが多くて効率が悪いと思います)。
教師の発言の残りの論点について簡単に。
「誘拐？それなら校門の前で待ってた方がずっと早い」
今時校門の前で張ってるだけで通報されかねませんね。こういうのは誘拐する側に立って考えないと的外れになりがちです。
多数決でも間違いがあるから繰り返し選挙が行われるわけで、かなり無茶な主張だと思います。
この教師が不勉強なのか元増田がナメられて子供騙しな言葉で適当にあしらわれているのかわかりませんが、いずれにせよ教育的に問題ありの発言の多い教師だな、という印象を持ちました…
普段コンサートの類はクラッシックやイージーリスニングのにしかいかないので、相変わらず、声優さんのライブのノリについていけないのであるが、それは別の話。
その声優さんに出会ったのはいつの事だっただろうか。まだ卵だったと思う。ある喫茶店で思いがけず、そのウェイトレスさんが声優の卵である事を知った。私もオタクであるから、喫茶店で話も出来た。多分、当時は私が知っている限り、何の役もやっていなかったと思う（もちろん、別名でエロゲとかやっていた可能性はあるがそれは完全に自分の憶測）。
その声優さんが店を辞める時、私と握手をした。声優さんは泣いていた。目の前で女の子に泣かれるのは結構来るわ。
でも不思議と完全に縁は切れなかった。かろうじて、ほんとにかろうじてつながっていた。ネットの掲示板に「今度ここでバイトするから来てね」とか書かれていたんだ。端から見ればそれは暗号だった。多分、俺しか分からない。
もちろん、俺は行った。まるでストーカーと言われるかもしれないけど。でも、実際、その新しいお店に行っても、嫌な顔はされなかった（営業スマイルである可能性はある）。
その後、しばらく音信不通になる。
数年経った時、出張帰りにある喫茶店に入ったら、叫び声が聞こえてきた。その声の主は、その声優さんだった。俺はびっくりした。その声優さんもびっくりしたんだろう。なんという偶然。
覚えていてくれたんだ、そう思うと嬉しかった。久しぶりに会話をした。声優業界の話を聞かせもらったりして、とても楽しかった。
何度かその喫茶店に足を運んだ時、「今度この役を演るんです」と嬉しそうに話してくれた。今見ると、Wikipediaにも出ているね。ちゃくちゃくと進んで行っているのはすごいな、と思った。
でもよくよくインターネットで見てみると、ラジオや映画吹き替えなど、仕事が増えている事が分かった。喜ばしい事である。
もうその頃になると、名前も知れてきて、固定ファンも出てきたみたいだし。
今ではある有名アニメの役を演じていた。このままビッグになってもらいたいと思う。CDも出しているようだし。
井上喜久子さん、田村ゆかりさんのライブに行った事がある。どちらも大きな会場で、声優さんは米粒だった。オペラグラス必須。でもこの声優さんのライブでは、距離はわずかに数ｍ。観客席にいる俺からも、ステージで歌っている声優さんからもお互いが認識出来る。ライブ後、声優さん自らお見送りがあって、直接話す事も触れる事も出来る。
そう、否定してしまうのはここだ。
確かに、ビッグになって欲しいとは思う。あたりまえだ、成功を願うのだから。でもビッグになればなるほど、距離が開いてしまうのも確実。イベントもどんどん商業的になっていくだろう。それが寂しい。
その感覚がおかしい、狂っているのも分かっている。考えなくても分かる。最初のきっかけは「客」と「店員」の関係だ。そして今は「ファン」と「声優」の関係。決して「お友達」の関係では無い。贅沢を言えば、古くからお互い知っているのだから、お友達になりたい。だがそれは今となってはもう無理な話だ。手が届かないという点では2次元嫁と同じだね。それに、自分から見れば、ただ1人の声優さんではあるが、その声優さんから見れば、俺など、多数のファンの中の1人でしかない。つまり1:nの関係である。でもありがたい事に、まだ俺の事を個人認識はしてくれているみたいだ。
有名人と特別な関係になりたい、そう願う人も多いと思うが、それが狂ってる、理解出来ないという人も多いと思う。多分、有名になってから知った人だったら、そうは思わなかったと思う。でもデビュー前から知っているという点で、「特別な関係」になりたいと願っているのかもしれない。例えそれが幻想・妄想であれ。
実のところ、俺は同人作品を作っている。いつの日か、自分の作品にこの声優さんに声を当ててもらいたいという、叶うはずの無い願いを持ちつつ、ストーリーを練っている。
http://alfalfalfa.com/archives/1616061.html
思うのだけど、どうせ娯楽に割ける時間なんて労働時間の半分もあるかどうかなんだから、思い切って質はいいけど保存性は悪くして、回転率を上げてしまえばいいんじゃないかと。
つまり、保管させない。勿体無いなんて言わせない。
で、Winnyとかそういうのにある違法配信は全摘発。アップローダーやストレージもダメ。
それと、こういう話題になると必ず「まずは中国から」とか言う人いるけど、どんなにグローバルになろうと国外は国外だよ。海賊版がーなんてのは建前で、ぶっちゃけ彼らを取り締まることなんて微塵も考えてない（考えるわけがない）んだから、文句あれば中国へどうぞ＾＾ってことになるんじゃないかな