Android版Instagramがリリースされ、早速多数ダウンロードされているようです。私もリリース直後にインストールしようと思ったのですが、不審なパーミッションがついているため断念しました。
Android版Instagramは以下のパーミッションを要求します。
連絡先データも怖いですがそこはSNSということで目をつぶります。一番最後の「実行中のアプリの取得」はいったい何のためでしょう。説明もありません。
「実行中のアプリの取得」といえば、かの「ミログAppLog事件」を思い出しますが、Instagramがなぜこのパーミッションを要求するのか疑問視する声はほとんど見ません。IT系メディアや著名レビューサイトをいくつかチェックしましたが、全く触れられていません。*1
これを見ると、不審なパーミッションを要求するアプリを避けるという意識が全く浸透しておらず、Andoriodのパーミッションによるセキュリティモデルは全く機能していないと言わざるを得ません。
また歩道(の自転車レーン)にのぼりを出していたので、警察に通報しました。翌日にもまた出していたので、改めて通報したうえで、警察官を交えて話をしました。相手の主張はこうでした
では、自分たちが車を止めるのは何なのだというと、「そんな事はしていない」と言います。なので警察官に写真を見せて状況を説明したところ、車の出し入れのために短時間とめただけだ、と言います。洗車していたじゃないかというと、いやそれも短時間だ、と。こういう具合です。
現に妨害になっていたから苦情を言っているのにそれに対して「避けて通ればいいだろう」というのが「配慮」なのかと聞けば、今度は「自転車は本来車道を走るものだ、ロードレーサーなら車道を走れ」だそうです。
＃暑い中100kmほど走ってきた後でクールダウンも終え自転車通行不可のアンダーパスを回避するため地下道を歩いて通ったあと、すぐそこの信号で反対側に渡るために「自転車レーン」を「徐行」していたのです。道幅が狭く交通量が多いために自転車レーンがあるような道です。
本来というなら車を歩道にとめる方が間違いだろうと言えば、「車道に路駐すると通行の邪魔になるから」と言いますし、じゃあ歩道の通行は妨害してもいいのかと言えば「避けて通ればすむ」だそう。
上に書いたとおり、他人の迷惑なぞ一切考えていないし、平気で嘘をつく人間でした。
ところで、上の写真のトラックの運転手、クビになったそうです。他人事のように話していましたが「自分が歩道とめろと指示したことが元で一人の人間が職を失った」ことをどう考えているんでしょうね。自分が売った自転車で事故が起きても他人事なんでしょうか？
]]>PiTaPa会員番号はセットになったクレジットカード番号と同じ(こともある)そうです。
これはヒドイ。PiTaPa倶楽部はアカウント乗っ取りを公式に推奨中 - ブックマクロ開発に
これを、「クレジットカード番号だから扱いに慎重になるだろう」ととるか、「独自情報じゃないじゃん」ととるか。
しかし、「PiTaPa会員番号を収集する」＝「クレジットカード番号を収集する」であるなら、加盟店が会員番号を収集するのは非常に危険ではないだろうか。
]]>これは真実なのですが、ではPASMOが優れている、PiTaPaがひどい、と言えるでしょうか。
私はこれは方向性の違う問題であって単純に比較できるものでは無いと思います。
PASMOが「マイページ停止センター」を用意したのは、氏名、生年月日、電話番号、カード番号を知りうる立場にある人であれば登録出来るという認識があったうえで、「登録出来なくすることも出来ますよ」と言うためです。
対してPiTaPaは、先のやりとりの限りでは登録情報を容易に知りうるような立場の人が不正に登録することはそもそも想定していなかったとしか思えません。「わざわざ近親者の履歴を見ようとは思わないだろう」とでも思ったのでしょうか。PiTaPaの想定では「停止センター」の必要性がないのです。
もしPASMOが、不正登録を防ぐ手段を十分に講じた上で上でさらに「停止センター」を用意し広報していたのであればPASMOの方が優れているといえます。しかし現実には「停止センター」の存在が積極的に広報されていたとは言えません。PASMOは問題を認識しながらそのことを利用者に公表していなかったとも言えます。まだ「そんなことは思いつかなかった」PiTaPaのほうがましです。
また「停止センター」の存在は、問題が大きく取り上げられたからこそ対策として機能するのであって、最初から対策として機能していたわけではありません。話題にならなければいつまでも不正登録が可能な状態は続いていたでしょう。
話題になった今だからこそ自衛が出来るかどうかは重要、という視点もあるかと思いますが、それであれば「PiTaPaが今回の問題にたいして対応するどころか反応すらしていない」という点こそが問題視されるべきだと思います。そもそも「利用者が自衛しなければならない」のがおかしいのです。
「停止センター」の存在のみをもって優劣を議論することは「オプトアウトの手段を用意すれば認証は不十分でもよい」という誤った方向に進みかねず、その点からも適切では無いと思います。
]]>PiTaPaの話のまとめ。
要するにPiTaPaの言っていることは「社会通念上問題のある方法で情報が取得されたり目的外利用され、その結果不正に登録が可能だとしてもシステムの問題ではない」ということです。通常考えられる不正には対策していると言いますが、システムを利用を認められたものが正規の方法で使う事以外はすべて「社会通念上問題がある」と言えるのですから、不正行為の一切が「システムの問題ではない」事になるでしょう。
つまるところこれはサイバーノーガード戦法そのものです。
よそで現に問題が起きているのに対策する気はないと言うのもサイバーノーガードが基本にあるからでしょう。
不正登録についてはある程度自衛できるのですが、セキュリティホールがらみ、例えばSQLインジェクションがあってデータをごっそり抜かれました、とかいうのは自衛しようがないので困ったものです。もちろん、こういうことがあっても「社会通念上問題のある行為なのでシステムの問題ではない」と言うでしょう。
まぁ私はもうやめることにしたのでいいです。実は今日の電話の中で、「このような事をを聞くのは何か目的があるのですか」などと言われてしまいました。利用者が自分の情報を心配するのは当然だと思うのですが、PiTaPaとしてはこういうことを言ってくるのは「何か意図があるからだ」としか思えないようです。そういう会社が利用者の保護を真剣に考えるとは思えませんし、事実サイバーノーガード宣言をしています。PiTaPaは他のカードに比べて漏れる情報も多いですし、ポストペイなので金銭的にも「最悪チャージした分がパー」では済みません。不思議なことに京阪がPiTaPa定期に乗っからずにJRと組んでICOCA定期にしたのでPiTaPaなくなってもそんな困らないのです、というわけでさようならPiTaPa。感謝はしません。
]]>カード詐取出来る「大穴」の件、書きました。要は紛失手続きの時に引っ越したとか言えばカードの送り先を任意に指定できるということです。
あともう一度PiTaPaに確認したこと。
最後はまともに対応していただけなくなりました。
少なくとも、止めるつもりも対策するつもりもないことだけははっきり明言されましたので、PiTaPa利用者各位におかれましては自衛におつとめください。
]]>PiTaPaにカード詐取出来る「大穴」があると書いた件。PiTaPaだけでなく、他のクレジットカードでも同様の事が出来るようです。
大穴とは、カードの紛失再発行の手続きの際に、本人確認を突破すれば任意の住所にカードを送付することができ、本人確認無しに受け取ることが出来るというものです。
少なくともPiTaPaとUFJカードについては、紛失手続きの際に申し出があれば、住所変更の手続きを行うそうです。また、送付も前者はヤマトのセキュリティパッケージ、後者は簡易書留なので、誰でも受け取れます。
問題は「本人確認」がどの程度の強度を持っているか、ですが、使える情報は
ぐらいでしょうか。
ちなみに銀行のキャッシュカードは、調べた限りでは住所が変更されている場合は店頭手続きです。
]]>PiTaPa倶楽部で住所変更ができない場合があるようです。この場合、カード詐取のリスクは低いと思います。提携カードでは不可のようですが、カードの種類にかかわらず、住所変更が可能かどうか確認した方がよいでしょう。
]]>要点
PiTaPa倶楽部に第三者が登録するのを防ぐため、以下の点は必ず守りましょう
理由
PiTaPa倶楽部に登録するには
が必要です。逆に言えば、これだけの情報があれば、誰でも会員になりすまして登録可能です。
PiTaPaで決裁した際のレシートにはカードIDが記載されている場合があるので必ず回収しましょう。また、会員番号やカードIDを入力するサービスは絶対に使用してはいけません。PiTaPaは、カード裏面の情報は秘密にしなければならない、本人しか知り得ないはずである、と説明しています。一方で、加盟店が独自にカードIDや会員番号を収集することを認めています。このように、PiTaPa自身も裏面情報の扱いについて曖昧な認識であることから、PiTaPaや加盟店において不用意な扱いがされていることは十分考えられます。もちろん、最初からカード情報の収集を目的としたサイトがある可能性もあります。
PiTaPa倶楽部は一度登録済みであっても、上記の情報があれば任意のID、パスワードで再登録が可能です。したがって、第三者が不正にPiTaPa倶楽部に登録してないか発見するためには、頻繁に自分のID/パスワードでログインできるか確認するしかないのです。
注意が必要なのは、不正に登録されることを防ぐことは出来ず、不正に登録されたことを発見することしか出来ないことです。自分のIDでログインできないということは第三者が不正に登録したと言うことであり、
の被害にあう/あったことになります。
利用履歴については、高木氏が指摘しているPASMOの問題と同じです。PiTaPaの場合はそれに加えて、会員情報が閲覧出来るため、個人情報漏洩になります。
問題はカードの詐取です。PiTaPa倶楽部では会員情報が閲覧出来るだけでなく、住所が変更できます。したがって、PiTaPa倶楽部に不正にログインされた場合、住所を変更した上で紛失の手続きを行えば、任意の住所にカードを送付できます。PiTaPaはこれについて、「住所を変更するにはカードIDを入力する必要があるから問題ない」と説明していますが、不正に登録できる攻撃者はカードIDを知っていますから何のチェックにもなっていません。
紛失手続きが伴いますので、カードを毎日利用している場合は利用停止になったことで気づくことが出来ます。しかし、カードを頻繁に利用しない場合、詐取されたカードが悪用された結果(利用履歴に載る、請求が来る)でしか判断できません。そして、PiTaPa倶楽部では利用履歴が確認出来るため、「利用頻度が低い人」を簡単に見分けることが出来ます。*1
運用管理の視点から。
これ問題は、人によって言っていることが違うことです。
| 目的 | 対象 | |
|---|---|---|
| 市長 | 職員による組合・政治活動の解明 | 全職員23,000人 |
| 市特別顧問 | 内部告発による職務専念義務違反の調査。組合は関係ない | 150人。全員を調査するつもりはない |
| 市 | 労使関係の調査 | 全員分の提出を指示された。時間がかかるというとリストで150人を指定された。残りは順次提出 |
電子メールには外部の人の個人情報が含まれる恐れがあり、取り扱いには注意が必要です。システム担当部門以外に提供する場合、
要求したかは記録しておくべきです。。また、提供を受けた側は目的外に用いることは絶対にあってはなりません。ところがその利用目的が人によってバラバラなのです。
もう一つ重大なポイントは、データを要求する人が確かに権限を持っているかどうか、です。
市特別顧問の野村修也弁護士は説明の食い違いについて、中立性確保のため市長にも詳細を説明していないからだとしています。
この「市特別顧問」って何者なのでしょう。大阪市の要綱によれば、特別顧問は「市長に対し政策的または専門的事項に関し指導または助言を行うもので職員の身分を有しない」そうです。これだけでは特別顧問が市長にも詳細を報告せずフリーハンドで調査を行えるほど強力な権限があるとは思えません。報酬を見ても、会議1回あたりで最大\55,000という扱いの仕事です。
報道によっては「第三者」とされている場合もありますので、ひょっとすると別の形でそのような権限が与えられているのかもしれませんが、大阪市のサイトでは特別顧問以外の情報はありませんでした。
要するに、対外的にはそのような権限を持っているような職務には見えない、ということです。そういう人が不確かな理由でメールデータを要求し、市はそれを是正しないままデータを提出したということで、運用管理上は大変よろしくない対応ということになります。
]]>こんなの届いた。
中身はHDチューナーをタダであげますというご案内。半年ほど前にHDチューナーを\100/月で貸してあげるけどどう？というお誘いが来てたので、しばらく待ってたらタダになるかなと思ったら本当に来ました。
web見ると、SDチューナーレンタル契約約款変更のお知らせというのが出ていて、中身はサービス終了条項の追加でした。
要するに、SD巻き取りたいからとっととHD契約に変更しろや、という事ですね。
変えてもいいけど録画がなぁ、と思っていたらタダでもらえるチューナーはなんとUSBでHDDつなげると録画も出来るとか。(ダブルチューナーのHDDレコーダー \9,800というのもあるけどいらない)
録画の問題も解消できるのであればこの機会に変更しましょう。
ところでHD契約に移行した月の料金はどうなるのだろうか。SDのチャンネル契約はテメーで解約しろと案内に書いてあるけど、1ヶ月分はSDの料金とHDの料金が両方かかる？16日間無料があるのでうまく月をまたぐようにしますかね。
]]>ActiveRecordでhas_manyなリレーションシップを定義した時に使えるメソッドのうち、少なくとも#createと#buildについてRails3.0以降で挙動が変わっています。次のコード
class Blog < ActiveRecord::Base has_many Entry end class Entry < ActiveRecord::Base;end blog = Blog.find(1) e1 = blog.entries.build(:blog_id => 999) e2 = blog.entries.create(:blog_id => 999)
を実行した後の、e1.blog_id, e2.blog_idの値はこうなります。
| e1.blog_id | e2.blog_id | |
|---|---|---|
| Rails2.3.11 | 1 | 1 |
| Rails3.0 | 1 | 999 |
| Rails3.1.3/3.2.1 | 999 | 1 |
したがって、Rails3.0以降では、collection.buildやcreateにはリレーションシップの外部キーになっているカラム明示的に削除して与えなければいけません。
]]>CanCanはRailsに認可機能を提供するプラグインです。これの紹介をしているblogが同じ間違いをしているので注意喚起です。
CanCanそのものの機能は公式のドキュメントを読んでいただくとして、よくある間違いというのは、controllerでload_and_authorize_resourceやload_resourceを使っているにもかかわらず、自分でリソースをロードし直しているというものです。
load_and_authorize_resourceやload_resourceはその名の通り権限にしたがってリソースをロードして適切なインスタンス変数にぶち込んでくれるものです。ですので、これらを使うときはscaffoldで生成されたリソースをロードするコード
@resources = Resource.all @resource = Resource.find(params[:id]) @resource = Resource.new
こんなのは削除しなければなりません。
例えば、
can :read, Book, :private => false
こんな権限を定議していると、BooksController#indexでは勝手に
@books = Books.where(:private => false)
をやってくれます。逆にいうと、scaffoldで生成されたコードが残っていると、いくら権限を定義していても@booksにはprivate=trueなレコードが含まれてしまいます。
ログを見てみると一発でわかります
Started GET "/books" for 172.16.1.100 at 2012-02-19 22:42:42 +0900 Processing by BooksController#index as HTML Book Load (0.3ms) SELECT "books".* FROM "books" Rendered books/index.html.erb within layouts/application (9.8ms) Completed 200 OK in 159ms (Views: 85.5ms | ActiveRecord: 0.3ms) Started GET "/books" for 172.16.1.100 at 2012-02-19 22:44:01 +0900 Processing by BooksController#index as HTML Book Load (0.3ms) SELECT "books".* FROM "books" WHERE "books"."private" = 'f' Rendered books/index.html.erb within layouts/application (12.8ms) Completed 200 OK in 149ms (Views: 88.0ms | ActiveRecord: 0.3ms)
前半がscaffoldでつくられた@books=Book.allを残したままのもの、後半が削除したものです。Abilityの定義が検索条件に含まれているのがわかります。
これは#indexの例ですが、他のアクションでもprivate=trueになっているレコードのidを指定して呼びだすととちゃんとCanCan::AccessDeniedがraiseされます。
Controller Authorization Exampleにはload_and_authorize_resourceを使った時に行われていることが書かれています。
なお、リソースのロードは自分でやる、権限のチェックだけしてほしい、という場合はauthorize_resourceという宣言があります。
]]>おはようございます。
最終日は浦上周辺を観光します。最後は空港バスに乗るのは決まっているので、新地バスターミナルのコインロッカーに荷物を放り込んで身軽になってから出発します。
まずは平和公園。松山町の電停を降りると入口があります。
平和祈念像ってなんか誰か(何か)に似ている…
デザインの一部かと思ったら当時の長崎刑務所浦上刑務支所の壁の跡だそう。
次は浦上天主堂へ。建物は戦後建て直されていますが被爆当時の遺構が保存されています。
中入ったんだっけな?大浦天主堂とごっちゃになってる…
原爆資料館…は説明するまでもないとして、その隣に「国立長崎原爆死没者追悼平和記念館」なる建物が。追悼施設だそうなのですがどうなんだろうこれは。良い悪いではなく、知らずにいくと非常に違和感(場違い感)を感じる施設です。地元の方はどう思ってるんでしょうね。
入口の水盤。
夜はこんなになるそうです。
お昼。「チャンポンはどこで食べるべきか」でおいしいと紹介されていた宝来軒別館の鶏皿うどん。平日昼前でしたがほぼ満席。
見た目焼きそばだけどちゃんぽんスープの味がする。うまい。
一度座ると動きたくなくなるのですが疲れた体にむち打って原爆公園です。正式名称がよくわからなかったのですが市のサイトでは「原爆落下中心地公園」になってるようです。
浦上天主堂の壁が保存されています。
浦上天主堂にもいましたけどなんなんですかねこれ？
爆心地碑を見上げてみました。
電車から見えた「長崎西洋館」という建物。いってみたらショッピングモールでした。線路またいでいるのはわざとなのかしょうがなくなのか。
全然知らずに行ったのですが、3Fに長崎路面電車資料館がありました。タダでした。小さいけど。
最後。もう限界。山王神社です。有名な1本足鳥居のあるところ。
境内には大きなクスノキが立っています。原爆で一度丸焦げになった木が緑になってるんだからすごいものです。
右側のクスノキにはこんな
階段が付いて、ガラス越しにうろの中が覗けるようになっています。うろの中には爆風で突き刺さった石や瓦礫が…
件の鳥居は参道をちょっと下がったところにあります。
驚いたことに倒れた部分が残ってるんですね。
石なので雨ざらしにしておいてもそうそう劣化するものではないのですがもう少しこうどうにかしてあげてもいいのではないかと。
以上で観光は終了。時間的にはまだもう少し余裕はありましたがもう体が限界なので帰ります。空港まではバスで1時間弱。
とっとと荷物を預けて身軽になろうと思ったら早すぎてチェックインできませんでした。展望デッキで休憩。なんで鐘が？
SNAの飛行機は見慣れないので楽しい。
長崎空港特製ちゃんぽん。
小腹が減ったのですがさりとてちゃんぽんを1杯食べるほどは減っていない。なんか食べるもの無いかなと空港をうろうろしてたら「ハトシロール」なるものを発見したので所望。
食パンで魚のすり身を巻いて揚げたもの…多分。このあたりカマボコ文化なのでその発展ですかね。ビールのおつまみにもピッタリ。
ぼちぼちいい時間なのでゲートをくぐって
飛行機の写真撮って、
飛行機乗って
空から別府を眺めて
日が暮れて
神戸空港について
ちょっとだけ空港見物して
おしまい。
]]>ZFSの調べ物をしていたらRAID-Z/mirror hybrid allocatorという見慣れない言葉を発見してそれについて調べていたら見つけた資料より。dedupについてこんなことが書かれていました。
dedup属性値をデータセット(スナップショット除く)単位で指定
スコープはプール単位
・dedup=onの全データセットで共通のブロックを共有
これはびっくり。設定がデータセット単位なので、重複判定も当然データセット内で行われるとばかり思っていました。
データセット単位だとZFSのsnapshot&cloneトリックとも共存できないので悩ましかったのですが、プール単位であれば逆にsnapshot&cloneの欠点を補えるので使い勝手がいよいよよくなります。
snapshot&cloneの欠点とは何かというと、snapshot&cloneを使うことで領域を節約しても、その後個々のファイルシステムに変更を加えると、例え全く同じ変更でも変更した分だけディスク容量を消費すると言うことです。
こんな例
これでVM1個分の領域で大量のVMを作ることが出来るのですが、たとえばこの後各VMでOSのアップデートをかけてしまうと、VMの数だけディスク容量を消費してしまうのです。なので、個々のVMで共通部分を変更しないよう配慮する必要がありました。dedupを使えばこの問題を解決できます。VMは好きにOSをアップデートできるので特殊な管理をする必要が無くなります。
ZFS便利ですね。
]]>