Subject: アナタはコチラの女性とSEXをして頂きます。強制かい。
いまさらですが、0.8.0が正式にリリースされてますね。RC2と比べて何か大きく変わったということはありませんが、相変わらず「考具」としてかなり極まっている感があります。
おとといの事故の影響で次々と欠航便がでている模様。同型機の総点検ということなら良いんだけど、機体のやりくりが出来ないということだといやだなぁ。年末に乗る予定なので、ちょっとドキドキ。
ニュースサイトやBlogで配信されているRSSの購読支援ツール(サイト?)。RSSを単純に表示するだけでなく、エントリ毎の既読管理が出来るのが非常に便利。また、サーバ型なので、自宅や職場で既読情報の共有もできる。残念ながら、RSSを配信していないサイトの更新チェックは出来ない模様。これが出来れば理想的な巡回補助ツールになるのに。既読管理が出来るアンテナ系ソフトを知らないので、今だにNemubarを捨てられない現状をどうにかしたいんですが。
Webで電報が申し込めるサービス。住所の入力が県→市町村→字と絞り込み式なのは良いのですが、選択メニューが50音順になっていない(おそらく漢字コード順な)ので、入力が面倒なことこの上なし。NTTには、他の申し込み(確かフレッツ)でも同じだったのですが、このおばかな作りは何とかして欲しいものです。さらに、式斎場ガイダンスで電話番号を入力すると、一発で住所が出て「この住所に置き換えます」と来た。さっきの苦労はなんだったの。
ひょんなことから初体験。今回使ったシステムはその辺で数千円で売っているUSBカメラとヘッドセットがあれば、あとはサーバに接続するだけというタイプ(って他のタイプがあるかどうかは知りませんが)。海外の方も含めた打ち合わせで、しかも無線LANということで、プチプチと切れがちでしたが、有線で繋がっている人の間はきわめて順調でした。付属しているログの管理面にちょっと不安があり、呼びかけ人の方には指摘しておきましたが、なかなか興味深い体験でした。
いわゆるアンテナソフトの出す更新情報のデファクトスタンダードの一つである、hina.di形式のファイルからrdfファイルを生成するスクリプトを発見。50件以上ある巡回先の設定をやり直す気力はないので、Nemubarの設定ファイル(XML形式)をWDBの設定ファイルに変換するスクリプトをまず書いて、上記のhina.di→rdf変換スクリプトを修正。生成されたrdfファイルのURLをFEEDBRINGERに登録。完璧。更新されたページのエントリだけが表示され、いったん開く(ページを読む)と、次に更新されるまでは表示されないという、理想的な振る舞いが実現できました。これでやっと開発が終わって久しいソフトのお世話にならずにすむようになりました。
最初からアンテナの設定をするなら、いよかん+というアンテナプログラムが標準でRSS出力に対応しているようです。私がわざわざ遠回りをしたのは、リハビリというか、純然たる趣味です(現実逃避という噂もありますが)。
余談:テストのために複数の場所から頻繁にアクセスしていたら、昨日の日間の人気フィードで堂々ランクインしてしまいました。ちょっとドキドキ。
だそうです。一方で、弾丸が発射されたことを示唆するようなテレメトリーデータもあるようで、発射されていることを祈るばかりです。ちょっと行って診てくるというのができない世界なので、苦労が伺えます。個人的には
(キセノンガスによる姿勢制御は)想定していなかった。これは、 12月2日にスラスターが動かなかった時、イオンエンジンチームから提案を受けた。というくだりにぐっと来てしまいました。このあたり、自分の手で作ったもののありがたみというのが非常に良くでています。批判もあるかもしれませんが、応援しています。
私自身は、イオンエンジンを動作させて姿勢を制御しようと考えていた。
ところがイオンエンジンチームはノズルの向きの可動範囲をよく理解しており、中和機の中性ガス噴射で姿勢を変更できると提案してくれた。
この時、探査機姿勢は毎日1度ずつずれていっており、そのままでは探査機が死ぬのを見守るだけということになるところだった。
復習あり、新しい話ありで充実した内容でした。ただ、時間配分が…Cookie固定の話題については、高木さんの発表とは別に、某言語の標準ライブラリで、サーバがセッションIDを発行する前にクライアントからセッションIDを渡されると、それを採用してしまうという問題があったのを思い出しました。
あと、まぎらわしくないドメイン名を使うという指摘もありましたが、業者が自分のドメインに対してそうするのは当然として、悪意のある第3者がまぎらわしいドメインを勝手に取得することについては防ぎようがないよなあと思ったり。さらにそのドメインで、夜のBoFで星澤さんが発表したような、警告の出ない証明書を取得されたらどうするのかというのは、前にも指摘しましたが、大きな問題だよなあと改めて感じました。
これは今の仕事と見事に絡んでいて、非常にためになるセッションでした。法律の話から始まり、個人情報の漏洩が起きてしまったときの対処の話、著作権の話、ECサイトと法律の話と続き、メインとして、いわゆるプロバイダにおいて、自社のユーザーが違法情報を公開している可能性があるときに、どういうリスクがありどういった対処をすべきかという話でした。最後のやつは違法情報媒介というそうです。
セキュリティホールmemo のBoF。
1発目はオライリーの方による技術系出版の現状について。オライリーから萌え本を出すことを一瞬だけ考えたが、提案する勇気はなかったというお話に妙に納得。
2発目は星澤さんのフィッシングにかんするプレゼン。さまざまな方法の紹介の中に、高木さんの項で触れた正規の証明書を取得したフィッシングサイトの話もありましたが、会場では特に反応なし。星澤さんも認証局側の問題だと思うと言っただけで流していましたが、例えば、QuickSSLとかは、admin@【ドメイン名】にメールが届きさえすれば、証明書を発行しますということを堂々と書いています。本当にそれ以外に確認作業があるのかどうかは、実際に証明書を入手してみないと分かりませんが、ほとんど確認なしで証明書を乱発する認証局が存在すると、今のWebセキュリティの枠組みが根本から崩れかねないと思うのですが、みんなスルーしているところを見ると、私が何か勘違いしてるのかなぁ。
3発目はアンプの話。だと何も分かりませんね。ある手法を使うと、パケットを増幅することができ、サーバへの攻撃に応用できるというお話。帰ったら自分のところの設定を見直さないと。
会場には無線LANがあり、今いるホテルも無料で有線LANがあるので、いつもと変わらない状態です。Web巡回に関しても、FEEDBRINGERの設定が終わった後だったのが幸いして、自宅にいる時とまったく同じ状態で使えるのが非常に嬉しい。
まさに狙ったかのように、CNET JAPANに389万件のドメイン名が虚偽または不完全な情報を使って登録されていたというニュースが。記事の中には
登録ドメイン名全体の5.14%に相当する231万件のドメイン名が、「明らかに、そして意図的に」虚偽の情報のもとで登録されていたというという記述もあります。
今日は終日上記カンファレンスに出席。テーマを要約すると、通信の秘密と被害者保護のバランスについて、といった感じでした。
◆ 事業者における通信の秘密
題が変わって「通信の秘密・通信の自由」に。前半は電気通信事業法第4条で定められている通信の秘密を侵してはならない、という条文があって、これが結果的に名誉毀損などの加害者や迷惑通信の発信者を守る形になってしまっているという話。後半は通信の自由は表現の自由を守るために不可欠であり、事業法では「提供義務」と「利用の公平」が規定されているが、これが迷惑業者の利用停止措置を阻んでいる(大げさかも)という話。いずれも一般市民を守るために作られたものが、犯罪者追跡の壁になってて歯がゆいということでした。あと逆に、郵便や電話の場合、それを使った犯罪行為があっても郵政公社や事業者が責任を負うことは無いのに、インターネットだけ通信事業者は訴えられるリスクを抱えているという嘆きもありました。難しいところです。
◆ ネットワークの監視・観測と法律上の問題
これも題が変わって「「通信の秘密」は、一般保護違反」という分かりにくいタイトルに。内容は憲法の制定過程にさかのぼって「通信の秘密」とはそもそも当時の人たちがどういうつもりで作ったものか、とか、そこからさらにいろいろな法律が後から積み重なって、ぐちゃぐちゃになっているといった内容。で、ネットワークの監視・観測(を行うこと)と法律上の問題、の話はすっ飛ばして、プロバイダどうしが情報交換して、犯罪者に立ち向かうジャスティスネットを作るべきだ、という提言で終了。ちょっと期待はずれでした。
◆ インターネットユーザー側から見た通信の秘密
被害救済するために、違法情報を媒介しているプロバイダに発信者情報開示を依頼すると、いろいろ障害があってなかなか公開してくれないというお話。一番分かりやすかったです。
パネラーとして、午前中に発表した3方にBlogシステムの開発業者とプロバイダの方2名が加わった形でディスカッション。面白かったのは、匿名の投稿フォームが準備され、会場内のPCから司会者に対して自由に意見が言えるようになっていた点。けっこう投稿があり、それなりに盛り上がっていました。基本的には午前の流れを受けて、被害者救済のためにも情報開示請求には積極的に応じていこうという方向で盛り上がっていたのが、最後のほうになって、「動的IPについてはログを取ること自体が通信の秘密を侵すことになるのではないか」という、冷や水を浴びせるようなコメントが出たり、悪者扱いされていた某お役所の方が手を挙げて、「プロバイダーはお客様からお金をもらって大切な通信を中継しているのに、安易に警察(国家権力)を信じてほいほいと情報をだすのか?」という質問に対して、パネラー全員が答えに詰まった末、弁明に走ったりして、なかなか面白かったです。最終的には、明らかに反社会的な犯罪の捜査協力については、ある程度の情報開示をしても良いんじゃないの、という方向でまとまったような、まとまらなかったような。
いずれにせよ、自分の会社ではどういう対処をするのかについては、日ごろから考えとかないとなぁ、と思った次第です。
最寄の駅からは160円で巡回バスが出ていて、行きはそれを使ったのですが、適当に帰ったら大失敗。ついた時間は7:50。バスは7:40の次は8:50で最終。結局30分かけて歩いて帰る羽目に。出席できなかったセッションの資料を何冊か買ったりしたので、重くて辛かった。
まず気になるのが、「売り値を指定する」という仕様。株なんて時価で売れるものだと思っていたし、現に57万円とかで売れたそうなので、そもそも売り値の指定に意味があるのかと。意味があるとすれば、最低売買価格の指定、つまり、この値段以下なら売らないよという値段の設定ということになりますが、確かにこれだと1円でもはじくわけにはいかなさそう。経営破たんした会社が1円2円で取引されていたのを見たことがあるので。
株数の上限については、空売りが可能な時点で、保有株数で上限を決めることは無理でしょうし、発行済み株数で上限を縛ろうとすると、増資などによる株数の変動への対応とか大変そうですし、なにより、今の取り引き数で、売り注文に対していちいち株数のチェックを入れていたら処理が間に合わないでしょう。
それより個人的に一番問題たと思うのは、キャンセルが効かなかった原因である、売値の指定方法。売り注文を行った際に指定した額(1円)ではなく、実際に売った額である57万2千円と指定しないと、キャンセルできないという仕様は、1円と指定した人の人為的なミスというにはあまりに酷で、むしろシステムの瑕疵と言っても良いぐらいではないかと個人的には思います。そもそも注文番号等で管理していれば良い話ですし、注文内容を間違いなく記述させることによる認証の意味があるのであれば、注文時にオペレータが入力した値と異なる値が実際に採用されるような項目(売り値)を、そうした認証用の項目に入れては駄目でしょう。
そもそも論はそうだとして、そういう仕様のものを受け入れ、今まで使い続けて十分に慣れていたということであれば、その会社やオペレータにも問題ありということになるとは思いますが。ただ、あれだけの誤発注をやっちゃった人に、いくら慣れていたとしても、そこまで冷静になれるかという話もあります。発注担当と、キャンセル担当を分けるとか、運用面での工夫もしないといけないでしょうね。
追記:東証が自社のシステムに不具合があったと認めたようです。内容が分かりませんが、上記の仕様の話でしょうか?
短波ラジオや電波望遠鏡、医療現場などで悪影響を及ぼすということで、あちこちで反対コメントの投稿呼びかけがあったわけですが、結局は変わらなかったようで。パブリックコメントを集める意味はあったのでしょうか。「集まった意見の数に改めて電力線通信への関心の高さを感じた」というコメントもなかなかすごいです。
今回募集されたパブリックコメントの趣旨とは違いますが、電力線通信って非現実的な気がしています。まず、短波ラジオの受信者からすると漏洩電波は単なるノイズですが、ある種の人達にしてみれば、それは遠距離で傍受可能な情報ということになります。そうすると、信号の暗号化は必須となるのですが、ネット家電のチップに通信暗号化機能を入れようとすると、コスト的にあわないんじゃないでしょうか。あと、集合住宅の場合、隣の部屋から自分の部屋の家電を操作されないようにするためには、ブレーカーのあたりにフィルタが必要になってくるでしょう。また、引込み線の先の電柱にモデムがつながれ、そこから先は光ファイバーみたいなモデル図を見ましたが、引き込み線って裸ないし裸に近い状態に見えるので、そこに針金を引っ掛けていたずらをするみたいなこともできそうです。
といった具合に、セキュリティを考えると、特に火気を扱う電化製品などとても怖くて使えないと思ってます。もし実用化されたら「電気ストーブで一酸化炭素中毒、隣人が不正操作」とか、「コンピュータウィルスが原因で部屋中水浸し」とかいう見出しが紙面を飾るようになったりして。
asahi.comの記事によると、新規上場した会社の株式の場合、どんな値を入力しても発注の取り消しができないようになっていたとの事。これはメーカーまで行くんじゃないでしょうか。
コルツ13連勝と聞いて、強烈な違和感を感じる私はかなりじじい?
ままならないものです。
久々のクイックハック。openssh付属のsftp-serverのchroot対応パッチ。FreeBSDの/usr/srcで当てることを前提としていますが、Makefile以外のパッチは通常のopensshにあたるはず。sftpchrootというファイルを、sshの他の設定ファイルと同じ場所に置き、ユーザー名を列挙するとそのユーザーがホームディレクトリにchrootされます。拡張書式もあり、FreeBSDのftpchrootと完全互換。というか、私が実際に書いたコードは4行だけで、後はftpのソースのパクリなんですが…
ペン型コンピュータ。デモがすごいです。ちょっと使ってみたいかも。
現在はみそすり運動中で通信できない状態だそうで、1ヶ月もするとこれが収束するので、それを待っている状態なんだとか。重心の配分とかでそういう風になるように設計されているんでしょうが、なんかもうただただ感心するばかりです。ぜひ川口プロマネに、「こんなこともあろうかと」と言って欲しいです。
ようやく発売のようです。問題は、ココは関東扱いなのかということと、今私が結んでいる契約が、エル・プランという、いまや影も形も無いものということ。WILLCOMとのダブル・ホルダーになるので、できれば今の契約で続けたいのですが、果たしてどうなるか。
今日、明日となぜか連荘で忘年会。今日はお寿司屋。お通しは卵豆腐に明太と葱をのせたもので、上品な味。刺身の盛り合わせは脂ののったブリ、トロが特に良し。白身魚(たぶんアラだと思うが自信なし)の照り焼きは絶品。これまた上品な味の茶碗蒸しで舌を休め、天ぷらは海老を中心にかぼちゃ、茄子。チャップリンよろしく海老を食らう(うそ、3本ぐらい)。海老、トロ、アナゴの寿司盛りはどれもおいしゅうございました。最後に蜆のお味噌汁で締め。あがりを頂いてお開き。
2次会はン年ぶりのカラオケ。せっかくなのでご同席させてもらう。「世界で一つだけの花」のサビの部分の振りを、まわりと一緒に手だけ踊ったところ、妙に受ける。甥っ子がなぜか気に入っており、去年(おととし?)の暮れに覚えさせられたんですが、人生何が役に立つか分からないものです。
pop3sでアクセスしているサーバで通信に失敗するようになった。のは良いのですが(良くない)、エラーメッセージの中で「設定→アカウント毎の設定から、「SSL接続で、証明書を検証しない」にチェックを入れると問題が回避される可能性があります」というアドバイスをするのは非常にいただけない。期限切れならまだしも、SSL-MITMを仕掛けられた場合に、せっかくの保護が台無しです。
で、上記サーバは期限切れでもなく、証明書を見る限りエラーが生じる要素は無い。試しに証明書を検証しない、にチェックを入れるとアラ不思議、通信エラーが消える。もう一度チェックを外すと、まあ不思議、エラーが出ない。えーと、なんだったんでしょうか。エラーが出なくなってしまったので、証拠画面をキャプチャ出来ず。もしかすると再起動でもエラーは治っていたのかもしれません。で、「検証しない」にチェックを入れるというアドバイスを信じた人が、そのまま放置すると非常にまずい設定で動き続けることになるんですが、もうちょっとエラー時のコメントに注意を払って欲しいところです。
金曜から緊急修羅場に入り、忘年会にも行けず。ぶっ続けで仕事をして朦朧とした状態で仮眠に入ってみた夢は…
夢の中で私は女性と付き合っていることになっているらしいのだが、その彼女からいきなり別れ話を切り出される。曰く「私、この人と結婚することにしたから」。彼女の横ではレイザーラモンHGがフォーの体勢で腰を振っている。なんじゃそりゃー、と突っ込んだところで自分が布団の上で腕立て伏せ状態になっていることに気づく。生まれて初めての突っ込み起き体験でした。
だれか夢占いして下さい。
修羅場のあいまを縫って週末に入手済み。が、全然触っている暇が無い。とりあえず明日までは何もできなさそう。
ちなみに、DP-145(1998年製)からの電話帳コピーは無理でした。
高木浩光さんの日記の12月24日のエントリでPhishing対策についての良くまとまった記述が公開されました。IEの標準機能を使った対策が載っていて、参考になります。以前からの心配事が杞憂ではなかったらしいと分かり、ちょっと複雑。
さて、上記エントリの中で高木さんは、「phishing対策ビジネス会社に1千万円払って自分のサイトの証明書を登録してもらう」という大胆な案を出していますが、その方法では、まっとうな中小企業やベンチャーがインターネットを利用したサービスを始められなくなってしまいます。小企業に身をおくものとしてそれでは困るので、他の方法を考えてみます。高木さんの書いた
「お前には売らない」という判断基準を、どうやって設けるかという問題の答えを見つけるのは確かに非常に難しいです。しかし、がらっと視点を変えて「まっとうな企業ならまったく問題ないが、犯罪者にとってはリスクが高く、手間もかかる枠組みを作る」のなら何とかなりそうです。
もったいぶって書きましたが、手法的には非常に単純です。ずばり、「訪問による実在性確認」。
つまり、証明書の発行時には申請を受けた機関が、社員を依頼者の住所に赴かせて、会社の存在と役員級の人間の確認を行うだけです。その際、(指紋はさすがに嫌がられるかもしれないので)身分証明書のコピーと顔写真ぐらいは撮らせてもらいます。さらに、日付を固定しない、月1,2回の訪問も付ける。で、これらの経費を価格に上乗せしたとしても、年1千万よりははるかに安くサービスを提供できそうです。訪問回数と価格については検討の余地があるでしょうが、あくまでサンプルということで。これで、詐欺師は証明書を入手するために場所と人間を用意して、さらにそれを常に維持しなければならなくなります。銀行の引き落とし詐欺のように、無職の人を使うことも考えられますが、偽造身分証明書の手配とか、何より本人に対して訪問時に「もしあなたが詐欺に加担しているとしたら、顔写真も撮っていますので、少なくともあなたは確実に捕まりますよ」とやさしく言い聞かせればかなりの抑止力になることが期待されます。
運用面では、訪問員と監査役のサボりが課題となります。まず、訪問員のサボり対策としては、訪問時に必ず会社の様子を写真に取らせるようにする。監査役については、担当する訪問員を固定としない、かつ、常に過去3回分の訪問についてチェックさせ、(他の監査役のサボりも含む)異常の発見に対して報奨金を付ける。とか。
ベリサインあたりが、宅配業者(郵便局とかオンサイトサポート業者でも可)と提携すれば、すぐにでもサービスインできそうですが、現時点ではまだ市場が無いかな。
上で取り上げた問題については、専門家の間では少なくとも3年前には認識されていて、解決方法についても提案されていたのをご存知でしょうか。2年前のINTERNET WEEK 2003で「PKI 〜基礎と応用〜」というセッションを受講した際に、私は
ちょっと以外というか,驚いたのは認証局のAssurance Lebelとして,Rudimentaryと言う「身元確認のために要求はない」というクラスが存在していたこと.という書き込みをしました。この時、ありがたくも講師の松本さんからこの書き込みに対してのコメントをメールで頂きました。その中で、紹介していただいたのが、Internet week 2002における、以下の2枚のスライドです。
「証明書ポリシーとは何か」、「証明書ポリシとX.509v3証明書の証明書ポリシ拡張」
2枚目のスライドで紹介されている「証明書ポリシ拡張」が重要です。このスライドの右下にいる男性の吹き出しには
これは、高額な取引だから、High証明書の署名じゃなきゃだめ!!とあります。これに対してALICEさんが署名を受けた証明書は「OID = ABC.3」であるため、スライドにある状況では、男性は警告を受けるなどすることができるという仕組みとなるはずだったのだと思います。ところが、ここを読んでいらっしゃる方は身を持って知っていると思いますが、この拡張、結局実装されていません。松本さんも頂いたメールの中で受け入れポリシー OID = ABC.4
受け入れポリシは実装の問題もあり、なかなか理解されていません。と嘆いておられました。さらにその後には
「標準のTrusted CA List」に対して、ポリシ付きの信頼リストと、悲しい当時の現状が綴られていました。この拡張の必要性が理解され、ちゃんと実装されていれば、認証局の信頼性を保証する機関などというものはそもそも必要なく、現状は違っていたのでしょう。もしかすると、今が「証明書ポリシ拡張」と「受け入れポリシ」を復活させることにより、インターネットを正常な状態に戻す最後のチャンスなのかもしれません。
http://www.e-government.govt.nz/docs/see-pki-paper-4/chapter3.html (リンク切れ)
3.6 Policy Trust list model
なども提案されていますが、そもそも、認証局のAssurance Lebelの必要性自体が、ちゃんと認識されていません。
P.S.
2枚目のスライドを改めてじっくり見ると、非常に示唆に富んだ内容になっています。左側のHigh証明書の発行ポリシーが「本人確認の方法、対面で手渡す」となっていたり。前のエントリを書いたときには意識していませんでしたが、このスライドの内容が私の意識下に根付いていたんだと思います。
蛍光灯の電気を交換しておしまい。
帰省の計画を立てていて、つくばエクスプレスのおかげで、羽田発の早朝の便にぎりぎり間に合いそうになっていることに気付きました。明日はいよいよ本番です。
飛行機は7:20発なので、ジョルダンの計画通り(6:55着)に行った場合は空港で歩く時間を考えると間に合いません。秋葉原での乗り換え時間が15分と妙に長いので、これを圧縮できないかとえきねっとの時刻表で調べたところ、6:05発の京浜東北線を発見。これに乗れさえすれば、最終的に10分ぐらいは余裕ができそうです。で、先日INTERNET WEEKに行った際、帰省を想定してエスカレータでは歩かずに、秋葉原駅での乗り換え時間を計ったところ、電車を降りてから京浜東北線のホームまで7分。間に合ってません。というわけで、勝負は秋葉原駅。結果は明日。乞うご期待。
ぼちぼちといじってますが、とりあえずDataSlim2の引退は決まりました。Oh!X を読みながら X68000をいじっていた頃のわくわく感みたいなものがあります。参考書は2chやまとめサイトに変わりましたが。
◆ パスワードロック
PDAとして使う場合には必須の機能。NK IIにも標準でついていました。5桁の数字というのは今のご時勢ではちょっと不安ですが、DataSlim2は4桁だったし。
◆ スケジューラ
Lotus Organizer 2000では同期ができなかったので、仕方なく暫定的にOutlookに転向。702NK IIを介して自宅のデスクトップとノートのスケジュールを同期できるようになったのは嬉しい副産物でした。ところが、Outlook では現在、起動をパスワードで保護したり、ロックをかけたりはできません。といわれて愕然。なんか良いPIM無いですかね。いくつか試してみたのですが、Outlookと同期が取れるソフトを見つけられませんでした。EssentialPIMはできるかなと思ったら、Outlookにエクスポートすると無条件にエントリを追記してしまい、ToDoや連絡先が2倍に_| ̄|○。
◆ 秘密情報管理
標準のウォレットが機能的には十分に使えそうなんですが、PCでの編集はおろか、PCへのバックアップすら取れないということで、却下。Handy Safe というサードパーティ製のソフトを購入して使用中。このソフトには、デスクトップ版も付属していて、PCで編集して電話と同期が可能。なはずが、702NK II(6680)との同期がうまくいかず、問い合わせたところ
Hi, Hideki.だそうで。データファイルを電話にコピーすることにより共有はできるので、来月まではそれで我慢することに。その他、デスクトップ版では日本語の表示が一部おかしかったりと、ちょっと難ありなソフトですが、他に良さそうなものも無いので使っています。なぜだか分かりませんが、Nokia版だけ$5.20と安いし。
the synchronization for 6680 will be supported in the new version that we plan to release in the end of the January 2006
◆ ヘッドホン
日本の端末では当たり前の、ヘッドホンジャックが無い!!代わりにお尻のコネクタに取り付けるヘッドホンマイクが標準でついているのですが、見るからに耳が痛くなりそうな無骨な作り。一般的なピンジャックに変換するアダプタがあるようですが、日本では売っていないようで、本体価格より送料のほうが高いという馬鹿らしい状態。さらに、このアダプタを使うと会話ができないので、電話がかかってきたときにアダプタを引っこ抜いて通話しなければならないそうです。で、おそらく通話を切った瞬間にそれまで聞いていた音楽が流れ出すという間抜けなことになるそうな。一瞬Bluetoothも考えましたが、電話機もヘッドホン側もすぐに電池が切れそう。これについては今後の課題です。
- taru_k [それって通風?]
- taru_k [あぁ…痛風だった.]
- hs [ちっが〜う。たぶん。]