今更ながらcoderwall に登録したんだけど、ソーシャル連携ボタンのそばに、記事タイトルの言葉が書いてある。
つまり、
許可無くつぶやいたりしませんよ
と。
いいですね、安心して連携できる。
もうログインしただけでシェアするサービスとか、OAuthのキー＆シークレットを無効にしてくれないかな、FacebookとTwitterさん。
（確かに認可ダイアログで許可はしてるんだけど、つぶやくタイミングは教えてくれるべきだよね。）
しかし、このcoderwallのバッヂ、思ったよりテンションあがりますね。
今までこのachievementな仕組みの効果を疑ってたけど、少なくとも僕には効果あった。
（Node.js関連でかなりもらえた^^ ）
というわけで、さっそくこのブログのサイドバーに貼ってみました。
ただこれ、ちゃんと活動してる人にとってはいいけど、
僕みたいな中途半端なやつだと、途中で放置してきた歴史みたいになってしまって逆に恥ずかしいのかも…。
iOS用のzipライブラリの使い方を漁ってたら、[Mac][iOS]ZipArchive ファイルの圧縮と解凍｜Cocoa練習帳 に出会って、そこでDropletsという言葉を知った。
アイコンにファイルをドラッグドロップして起動できる簡単なツールを指す言葉のようだ。
（元々はAppleScriptとかをラップしたものをそう呼んでらしい）
これいいな。
こういう小規模なアプリならブックマークレット感覚でどんどん作れそう。
ところで皆さん、iOSのアプリを作ってる時とか、画像の元サイズを知りたい時結構ありませんか？
僕はとてもあります。
デザイナさんに聞けば早いのですが、僕ら引きこもりは他人と喋るのに結構なエネルギーを消費します。
機械が知っていることはできれば機械に教えて欲しい。
Finderには元々サイズ表示機能があるのですが、僕の環境ではPNGファイルはなぜかうまく働かないことが多いのです。きっとFireworksがPNGを拡張なんかするからだ。そうに違いない。
というわけでそれだけのアプリ作りました。
こんな感じです。
Targetを10.6にしたので、おそらくSnow Leopardでも動くんではないかと思います。
ソースコードはGithubに上げてます。
tnantoka/ImageDrop
ちなみに作成手順は以下の通りです。超簡単。
もっとここ詳しく説明して欲しいとかあればどうぞ。
画像サイズの取得は、My First iMac: 画像サイズの取得: NSImageのサイズがおかしい を参考にしました。
NSImageのsizeは解像度を考慮しているため、単純にピクセルを返してくれないようです。
いやぁ、それにしてもMacアプリは作成も配布も手軽でいいですね。
iPhoneアプリの審査待ちフラストレーションの解消にちょうどいいです。
あとはアドネットワークさえ充実すればなぁ。
1日遅れの話題ですが。
Linkedinのパスワードが流出、650万件がハッカーフォーラムで公開との報道
今時そんな、漏れたぐらいですぐ問題になるような保存の仕方はしないでしょう、と思ってたら
6.5 Million LinkedIn Passwords Reportedly Leaked, LinkedIn Is “Looking Into” It | TechCrunch に、
The passwords are stored as unsalted SHA-1 hashes
って書いてあった。事実なら確かに脆弱。
NISTの2010年問題で、生SHA-1はパスワード保存に使っちゃダメって言われてたはず。
Linkedinは米国政府と取引なかったのかしら。
（なかったら脆弱でもいいというわけではもちろんないけど。）
SNS嫌いの僕は幸いLinkedinのアカウントを持ってなかったのでスルーで良かったんだけど、
一つ疑問が。
SHA-1は確かに脆弱と言われてるけど、短時間で30万件も衝突させれるほどだっけ？
いかんなぁ。金融システムを離れてセキュリティに暗くなっていく一方だ。
恥を忍んでハッシュ関数についておさらいしておこう。
あるデータから固定長のユニークな値を生成する仕組み。
base64などのエンコード（デコードできる）と違い、一方方向の変換のみで、元に戻せない。
パスワードみたいに、元データを持たずに後から入力値が同じかを確認したい時に使える。
つまり、送られてきたパスワードをハッシュ化して、登録時にハッシュ化したものと比較すれば良い。
改ざん防止にも使える。オープンソースプロダクトのダウンロードリンクの横にたまに書いてあるあるやつがそう。ダウンロードした後にハッシュ化してそれと一致すれば改ざんされてない。
（まぁサイト自体が改ざんされてた場合は、ハッシュ値も書き換えちゃうだろうけど）
「ハッシュ関数による暗号化」とかよく言われるけど、暗号でもない。
暗号は復号できるから、一方方向じゃない。
（今回の件でも多くの記事が暗号と書いてて悲しいかぎり）
（強・弱）衝突耐性だとか、現像攻撃とか似たような定義でわかりづらいけど、wikipediaさんがうまくまとめてくれてた。
原像計算困難性 (preimage resistance)
ハッシュ値 h が与えられたとき、そこから h = hash(m) となるような任意のメッセージ m を探すことが困難でなければならない。これは一方向性関数の原像計算困難性に関連している。この特性がない関数は原像攻撃に対して脆弱である。第2原像計算困難性 (second preimage resistance)
入力 m1 が与えられたとき、hash(m1) = hash(m2) となるようなもう1つの入力 m2（m1とは異なる入力）を見つけることが困難でなければならない。これを「弱衝突困難性 (weak collision resistance)」ともいう。この特性がない関数は第2原像攻撃に対して脆弱である。衝突困難性 (collision resistance)
hash(m1) = hash(m2) となるような2つの異なるメッセージ m1 と m2 を探すことが困難でなければならない。このような組を衝突と呼び、この特性を「強衝突困難性 (strong collision resistance)」ともいう。原像計算困難性を持つハッシュ値よりも少なくとも2倍の長さのハッシュ値を必要とし、さもなくば誕生日攻撃によって衝突を探し当てられる可能性がある。
1つ目が破られたらもはやハッシュとして意味がないので置いておくとして、問題になってくるのは下2つ。
元々ハッシュ関数というのは、これらの衝突が不可能というわけではなく、総当りだと天文学的な時間がかかることで安全とされている。
そのため、ある攻撃手法によって、 総当りよりも少ない計算量で衝突が発見出来れば、そのハッシュ関数の脆弱性が発見された、ということになる。
今回のように漏洩したハッシュ化パスワードを元に認証を不正に突破するためには、
弱衝突耐性を突破しなければいけない。
パスワードのハッシュ値がわかってるので、それと同じハッシュ値になる入力値を探すわけだ。
（元のパスワードと同じじゃなくても良い。ハッシュ値が同じであれば認証は突破できる。）
で、今回のSHA-1はというと、
●2004年に衝突耐性に対する脆弱性が発見されて依頼、様々な攻撃法が考え出されてきましたが、2008年10月現在で具体的に衝突が起こる例が求まったわけではない状態です。
2008年でこの状態だったらしい。
それ以降日本語情報ではあんまりアップデートがなくてよくわからなかった。（英語で調べるほど元気はなかった、ごめんなさい）
4年もたてばもっと進んでるんだろうけど、数日とかのオーダーで30万件も解読できるほどではなさそうだけど、どうなんだろう？？
この前mysqlのパスワード（md5）忘れちゃった時、試しに攻撃ツール使ってみたけど死ぬほど時間かかってたしなぁ。
と、ここまで考えて、数学的な攻撃じゃなく、リンクトインで使われそうなパスワードをもとにやっていけば、30万件ぐらい軽く行くのかもと思った。（簡単なパスワード使ってる人いっぱいいそうだし。password1とか。）
そうだとしたら弱いパスワードを許容してた設定の問題だなぁ。
とか書いてたら続報が来てた。
LinkedIn、侵入および「一部」ユーザーのパスワード漏洩を認める
これを見るとアルファベットだけのパスワードを許容してたみたい。
そしてなんと、改めて最初にあげたTechCrunchの記事を見返したら辞書使ったって書いてあったというオチでした。
でもブログ書いてみて、いかに自分がセキュリティに対して疎くなっているか、改めて実感できたので良かったです。徳丸先生の本
理解が誤っている部分とか多々あると思うので、突っ込み大歓迎です。
ちなみにリンクドインじゃなくリンクトインらしいです。
あと関係ないけど、百度もバイドゥ↓ではなくバイドゥ↑（ドゥがあがる）なんですって。
それでは。
allWebクリエイター塾 ブログ: 「レスポンシブ・ウェブ・デザイン」だよ、「レスポンシブル」じゃないよ。
レスポンシブ・ウェブ・デザイン（CSS NITE Vol.59） – asa nisi masa
かなり前から指摘されてるけど、とどまるところを知らないようなので。
「responsible web design」 とGoogle検索すると「もしかして：responsive web design」ってなるのに、
「レスポンシブルウェブデザイン」だとスルーされちゃう程。
（日本語と英語でGoogleの精度が違うっていうのもあるんだろうけど）
まぁ一般人が間違うのは仕方ないと思う。
その人が参照したソースが間違ってたんでしょう。
レスポンシブとレスポンシブル、英語の意味を考えずにカタカナとして捉えたら同じように見えるし、間違って覚えちゃうのもわかる気がする。
ただ、輸入記事とか書いてる人は、英語読めるんでしょう？それに原文読んでるんでしょう？？
ちゃんと読んでれば、responsiveと、responsibleは見間違えないんじゃないかと思うんですがどうでしょう？
元記事がresponsiveなのにわざわざ「ル」をつけてんじゃないわよ！
こんな事言ってるから、プログラマは正式名称にこだわってキモイって言われるんでしょうね^^
あ、僕は、「タイピングなんて無意識でやるものだから、常に正式名称で打っとくほうが楽でしょ」派です。
それでは。
わーい！！
おぉ、本格的。
さっそく貼る。
ドットインストールは、気持ちのいいサービスですよね。
みんなの役に立つのはもちろん、このサービスによって不快な思いをする人がいない、素晴らしい。
是非これからも頑張って欲しいです。
『動画をちょろっと見ただけでプログラミング出来るようになると思うなよ？』っていう硬派なみなさん。
そうですよね、僕もそう思います。
HTTPの仕様を理解せずにWebサービスを作ればどこかおかしなものができるし、C言語を知らずにiPhoneアプリを作れば不安定にもなるでしょう。
深く理解するためには、書籍なり何なりで体系的に、そして能動的に学ぶ必要がある。
しかし、それはドットインストールの方々もわかってらっしゃるんですよね。
3分動画でマスターする初心者向けプログラミング学習サイト『ドットインストール』を始めます | IDEA*IDEA にちゃんと書いてあります。
■ このサービスが目指すところ
すごく正直にいうとこのサイトでコードが書けるようになるとは思っていません。そうではなくて、「プログラミングに興味をもってもらうこと」「だいたいの仕組みをわかってもらえること」が大事だと思っています。
そう、ここが一番大事で、そして難しいんですよね。
そして、「短い動画レッスン」というのがドットインストールさんの出した答え。
僕にとっても、いかに初心者に楽しく教えるかというのはずっと課題なので、自分なりの答えを出したいと思っています。
他人の応援ばかりしてられる程余裕もないので、僕も頑張らないと！
最後に、日本にも訪れつつある教育サービスバブルが、ソーシャルバブルのようなマネーゲームにならないことを祈るばかりです。
最近のコメント