プロパティと個人データ — 旧メイン・ブログ | Baldanders.info
前回の続き。 っていうか， 実は書きたかったのは今回のほうで， 前回のはただの前振りだったり。 essa さんの記事をだしに使ってしまって申し訳ありません。 @nifty がプロフィールサービス「about me」をリリースした。 自分でコンテンツを立ち上げるのは正直しんどいのだが， あちこちのサービスにコンテンツが分散している状態にもウンザリしている人にとっては， こういう「自分まとめページ」とか「自分ポータル」といったサービスはありがたい。 逆に（「nowaとアバウトミー」でも指摘されているが） nowa のような全部入り（っていうか全部二番煎じ）みたいなものには全く食指が動かない。 膨大なコンテンツを引っさげて似たり寄ったりのサービスの間を放浪するのではなく， 折角 feed があるのだから， feed を集約してひとつのコンテンツとして見せるほうがスケールしやすい。 （まぁ今はその
[鏡] 入門 JSON 3 -- JSONP とコールバック関数 -- 戯れ言
最近 JSONP というのが話題になっているようですので， ここで簡単に紹介します。 JSONP （JSON with Padding）というのは JSON のデータフォーマットにちょっとした記述を加えて JavaScript の関数として呼び出せるようにしたものです。 JSONP については以下の記事に簡単な説明があります。（多分この記事が初出だろうという話です） Remote JSON - JSONP 例えば以下のような JSON データがあるとします。 { "name" : "Yasuhiro ARAKAWA" } JSONP ではこのデータに記述を加えて JavaScript 関数のようにしたものです。 分かりにくいですね。 具体的にはこのように記述します。 callback( { "name" : "Yasuhiro ARAKAWA" } ); "callback" の部分は関数
暗号の危殆化と新しいアルゴリズム — 旧メイン・ブログ | Baldanders.info
L が鍵長で N が被署名データのサイズです。 FIPS186-3 ドラフト案ではこの組み合わせの中から選択して使うべきとしています。 ところで署名・暗号に使う鍵の長さはどの程度が適当でしょうか。 確かに長ければ長いほど安全といえますが， 長すぎる鍵はとりまわしが不便です。 この件については IPA/ISEC による 「将来の暗号技術に関する安全性要件調査」 が参考になります。 詳しい内容はそちらを読んでいただくとして， 結論としては， 今後10年のスパンで考えるなら共通鍵暗号の鍵で128ビット程度で十分なようです。 128ビットの共通鍵暗号鍵を公開鍵暗号鍵に換算するとどの程度になるかは難しいですが（先ほど紹介した調査報告書では参考値としながらもかなり大きい鍵を要求しているように読めましたが）， これについては RSA Security による 「A Cost-Based Security
OpenID を導入しました — 旧メイン・ブログ | Baldanders.info
これまでこの Weblog へのコメントには TypeKey ID が必要でしたが， 新たに OpenID でもコメントできるようになりました。 コメント時のサイン・インで TypeKey のサイン・イン画面へ遷移するか OpenID の URL を入力すればコメントが可能になります。 変更作業にあたっては以下の記事を参考にしました。 OpenIDを、MovableTypeプラグインで使ってみる なお OpenID Comment Plugin は「OpenID Comments for Movable Type」にある最新版（1.6.1）を導入しました。 このバージョンでは OpenID の URL から FoaF の名前情報等を取得します。 ついでに OpenID 認証サーバも導入しました。 Movable Type と連動して動作します。 導入作業にあたっては以下の記事を参考にしまし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
