2日ほど前に、 現在、犯罪の捜査でよく見られる光景の一つは、家宅捜索が行われて段ボールに入った書類やパソコンが押収されるというものだが、今後「クラウド」が発達・普及すると、そうした捜査に支障を来するケースも増えるんじゃないだろうか? と考えて、ツイッターでつぶやいてみた。 今回は、そこで議論させてもらったことを踏まえて、「クラウド」時代のビジネスや、情報に対する国家権力の行使の一端について考えてみたい。 注: クラウド・コンピューティングまたはクラウドという用語はバズワード化しており、人によってイメージする内容が異なる恐れがあるので、ここでは「ネット上のサーバーにあるデータやソフトウエアなどを、手元の端末と同等かそれ以上に便利に使えるサービス」という程度の意味で、カッコ付きの「クラウド」という用語を用いることにする。 ■今後「クラウド」優勢の時代が来るのか? クラウドという用語が出て来る前
SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。 単にプリペアドステートメントを使え 絶対に文字列結合でSQLを構築しようとしてはいけない IPAの「安全なSQLの呼び出し方」を読むこと なんでこんなことを書くかというと、同僚が献本されてた「プロになるためのWeb技術入門」なる本のSQLインジェクションの項で、SQLインジェクションの対策として以下のように書いてあったからです*1。 a) 値をバリデーションする b) プリペアドステートメントを使う ダメです。間違っています。単に間違っているだけでなく救いがたく間違っています。正しいSQLインジェクション対策はこう書くべきです。 単にプリペアドステートメントを使え 文字列結合でSQLを構築するな イケてない本を書く人はなんで値のバリデーションをプリペアドステートメントよりも先に書くんですか?値のバリデーション
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
ここは、管理人yamagataが方針未定のまま、何となーく思いついたことを思いついたままにだらだらと書き付ける日記帳です。ふんわりほんわかな感じでお願いします。
近年、サービスの垣根を超えて、利用者情報を相互利用する標準API(Application Program Interface)の各種サービスが提供されています。それらの目的は「SecuTect」にも共通していますが、大きな違いは「SecuTect」とこれらの標準APIや各種サービスは“競合ではなく協調しながら”新たなサービスを実現する可能性を秘めていることです。たとえば、標準APIである「OAuth」は、「Gmail」「Twitter」と「SecuTect」との連携においてすでに使われています。 OpenIDとOauthについて 「OpenID」とは、ひとつのIDで様々なインターネットサービスにログイン(いわゆるシングルサインオン)することを目的とした、認証のための標準API仕様です。「Yahoo!」、「livedoor」、「ミクシィ」といったサービスが「OpenID」に対応しています。
ソフトウェア開発のリプレックス(東京都渋谷区)は10月29日、相手のメールアドレスやTwitterアカウントを知っていれば、住所や本名を知らなくても年賀状を送れるサービス「ウェブポ」をスタートした。 日本郵政グループの郵便事業会社と連携し、Webブラウザ上の操作だけでお年玉付き年賀はがきを届けるサービス。「ミクシィ年賀状」と似たサービスだが、外部サービスと連携し、同社が個人情報に直接アクセスできない仕様にした。 メアド分かればOK TwitterやGmailとAPI連携 相手の住所が分かっていれば、直接入力して年賀状を届けることができ、分からなければ、メールやTwitterのダイレクトメッセージを通じ、相手に送り先住所を入力してもらうことになる。 送信相手は、メールアドレスを直接入力したり、Outlookなど連携しているメーラーから取り込んで選ぶことが可能だ。GmailとはAPIで連携。I
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
会員限定サービスです 会員の方はこちら ログイン 有料会員(月額プラン)は初月無料! お申し込み 日経クロステック TOPページ
はてなブックマークモバイル版の脆弱性 昨日、はてなブックマークモバイル版の脆弱性に関する報告が公開されました。 「はてなブックマーク モバイル版」の脆弱性を利用した不正アクセスに関するご報告 - はてなブックマーク日記 - 機能変更、お知らせなど キャッシュ機構の不備により、セッションID付きのURLを含むコンテンツページがキャッシュされてしまい、悪意のあるユーザが他人になりすます(セッションハイジャック)ことができたというものです。 セッションIDのみの認証なんてありえない? 報告記事に対する下記のブックマークコメントを目にしたとき、私は違和感を覚えました。 セッションIDのみの認証なんてありえない。そもそもセッションIDは認証に使うべきではない。せめて各種完了処理のときくらいはUID(NULLGWDOCOMO)もしくはFOMAカードor端末の製造番号(icc〜、ser〜)を使って認証し
先日OAuth1.0に対応したgooホームガジェットですが、このたび、1.0aにも対応しました。 OAuth1.0aとは OAuth1.0で発見された脆弱性(Session Fixation)に対処するために定義された仕様です。 Request Token取得時にoauth_callbackでコールバック先URLを予め指定し、Authorize後に返ってくるoauth_verifier値を使ってAccess Token取得を行うことで、認証だけさせてセッションが乗っ取られるという1.0の脆弱性の対処が行われています。 既存のガジェットをOAuth1.0aに対応させるには 特に何も変更する必要はありません。サービスプロバイダが1.0aに対応していれば、1.0aとして動作します。 OAuthリクエストを使ったガジェットを開発するには、こちらのドキュメントをご覧ください
忘れたころに追記 API で _twitter_sess は発行されているようですが、web の UI にアクセスはできなくなったみたいです(つまり豪快さは解消されてます) OAuth コンシューマが twitter API にアクセスすると、ブラウザでログインしたときと同様のセッションクッキーが発行されている模様です GET https://twitter.com/account/verify_credentials.xml Authorization: OAuth realm="", oauth_consumer_key="***", oauth_nonce="***", oauth_signature="***", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1253358338", oauth_token="***",
■ エコポイント申請画面が共用SSLサイト上にある件 「エコポイント」の情報システムがわずか3週間で完成した理由, 有賀貞一, NIKKEI NET, 2009年8月26日 こうした問題を解決するために、エコポイント事務局と関係省庁が選択したのが、米セールスフォース・ドットコムの基盤サービス「Force.com」だった。セールスフォースはこのForce.comを「クラウドコンピューティングプラットフォーム」と表現している。利用者はサーバーなどのインフラを持つことなく、この基盤上で独自のシステムを構築できる。 という記事を読んで、「エコポイント」のサイトを初めて訪れたのだが、これはまずい。 「エコポイント」公式サイトの運営者は、「グリーン家電エコポイント事務局」となっていて、プライバシーポリシーでも個人情報取扱責任者が「グリーン家電エコポイント事務局」として書かれている。しかし、国民の視点か
信頼できない相手に仕事を任せられるのか?について、以下、思いついたことをならべてみた。思いつきが拡散していったら、追記するかもしれない。望み薄だけど。 (2009/6/30追記:Gentry暗号の件で検索で来られた方には、Gentry暗号の簡単な解説 - 186 @ hatenablogをご覧になることをお薦めいたします。 これまで、それで成功した例ってあるのだろうか? SETI@Home 暗号cracking 冗長化と検算による整合性の検証は成されてきたに違いない。でも、仕事の目的・内容を秘匿してはいなかった。そして、データそのものを秘匿する必要も無かった。 これが、SaaSを利用する上では丸投げになってしまう可能性がある。(相手がcloudである必然性はないが、サービスを運営する側からは、flexibilityやscalability,robustness,設備投資のrisk mana
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く