2010年03月30日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・中国のインターネット遮断問題[http://www.nantoka.com/~kei/diary/?20100328S1] このエントリーをはてなブックマークに追加

中国の DNS 問題について、発見者である チリの NIC が ステートメントをリリース![http://agilecat.wordpress.com/2010/03/30/%E4%B8%AD%E5%9B%BD%E3%81%AE-dns-%E5%95%8F%E9%A1%8C%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%80%81%E7%99%BA%E8%A6%8B%E8%80%85%E3%81%A7%E3%81%82%E3%82%8B-%E3%83%81%E3%83%AA%E3%81%AE-nic-%E3%81%8C/] の記事。
中国のインターネットが「The Internet」と言えるのかという点については、以前からビミョーな部分はあったのだけれども、これはもう、「イソターネット化」したと言って良いのではないか。
他国(他人の)ドメインを勝手にヨソに向けるという行為は、海賊行為そのものであり、そういう行為が行われる世界は、もはやインターネットでは無い *1
言論の自由とインターネットは密接に関わっているというのは、私は 以前から[http://www.nantoka.com/~kei/diary/?20050627S4] とてもしつこく言っているのだけど、この出来事からは学ぶところが多いと思う。 日本にいても必ずしも他人事ではない。

スウェーデンのIXが中国のDNSルート・サーバを遮断[http://www.computerworld.jp/news/net/177889.html]:

こちらの記事も参照。
*1: 昔は、国内向けDNSと国外向けDNSというのがあって…とか言うのは措いておいて。

■ 関連記事

詳細はこの日の詳細から

2005年03月30日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1個人情報保護とワンストップサービスあるいはCRM[セキュリティ]次の記事 >> このエントリーをはてなブックマークに追加

一度手続をすれば、関連する手続を一気に完了させられるという様なサービスを提供しようというのが ワンストップサービス[http://e-words.jp/w/E383AFE383B3E382B9E38388E38383E38397E382B5E383BCE38393E382B9.html] で、特に行政分野では、例えば引っ越しする時に、何度も色々な窓口で手続をしなきゃいけないという様な問題が顕著で、これをITで解決しようという方向で流行した。
CRM[http://e-words.jp/?w=%82b%82q%82l&headline=%8C%A9%8Fo%82%B5%8C%EA%8C%9F%8D%F5] も一頃流行した概念で、例えば、購買からサポート等の履歴を、ITを活用してマネジメントして、顧客満足度を向上させ、関係を深くしていこうという方向で流行した。
例えば、引っ越しの時に、行政がやっている水道に留まらず、ガスや電話その他の全ての住所変更手続が一回でできれば、確かに便利だ。
ホテルに泊まった時に、前回、そば殻マクラを使っていたら、最初からそば殻マクラがセットされていたりすると、気が利くなと思って評価が上がる。
だけれども、いずれも個人情報保護法と両立させるのが難しい側面を持っている。
実際に、個人情報保護対策で明らかに不便になったサービスもいくつか存在する。簡単なところで言えば、ピザの出前が今まで電話番号で済んでいたものが、毎回、住所を説明しないといけなくなったりしている様だ *1 。 個人情報保護対策特需が一巡したところで、この辺りを上手に解決できるソリューションが再び求められるようになると思う。
*1: こんなのは、初回の配達の時に、登録させてもらっても良いかどうか、サインをもらえば済むと思うんだけど。

■ 関連記事

■2 「プリペイド法案」可決〜違反者には300万円の罰金も[http://www.itmedia.co.jp/mobile/articles/0503/30/news002.html][個人情報]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

罰則を強化すれば解決するというものではない。
プライバシー保護、例えば深刻なドメスティックバイオレンスやストーカー行為を受けている状況で、シェルターを提供する組織が携帯電話を提供する場合もある。
逆に、この法律ができたからと言って、最初から犯罪に使おうという犯罪者に対する抑止力には働きにくい。一つ罪が増えるだけの話だ。
「犯罪に使われる可能性があるから規制」って方向で行くと、橋の上げ下ろしにまで国家が口を出す社会になって、小さな政府は実現できない。

■ 関連記事

■3某提案書[おしごと]<< 前の記事 このエントリーをはてなブックマークに追加

書き上げた!なんとかページ数に収めた!

■ 関連記事

詳細はこの日の詳細から

2002年03月30日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 Re: /etc/make.conf question[http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=370110+0+/usr/local/www/db/text/2002/freebsd-stable/20020317.freebsd-stable][freebsd] このエントリーをはてなブックマークに追加

stableのアーカイブ。
make worldの手順についての議論へのポインタ。 このスレッドの途中から、Remote での make worldの話題が出てくる。
singleユーザーに落とさない手順のアイデア[http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=338326+0+/usr/local/www/db/text/2002/freebsd-stable/20020317.freebsd-stable] っていうのも出てきている。
いずれにせよ、テストボックスでテストするのが重要だと思われます。

■ 関連記事

詳細はこの日の詳細から

2001年03月30日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 逆リンクにGo![http://www.1783.org/diary/?200103c&to=200103302#200103302][hns]次の記事 >> このエントリーをはてなブックマークに追加

導入ありがとうございます。
現在の課題は,同じ個所からのリンクでも読者によってURIがまちまちなので, なると(@)がたくさん表示されることです。
この問題は,帰ってきた「新リンク方式」が実現されたときに解決される予定です。

新リンク方式:

解決しようとする問題は,
  1. Refererでは同じ個所からのリンクが様々な形式で表示されるため未読を探しにくい(識別したい)
  2. 逆リンクを張られた時にどのセクションから張られたのか分からない(リンク元を知りたい)
このために,refテクノロジでは,
  1. 相手方にリンクを張るときに'ref=識別子'の形式によって,こちらのセクション情報を引き渡す
  2. 上記1の'ref=識別子'形式を理解できる日記は,自分自身のセクション(or段落)リンクに,'ref=here'なるキーワードを含める
  3. 'ref=識別子'を生成できる日記では,LINKを張るときに,'ref=here'を'ref=識別子'に置換する
ということを行います。
問題になるのは識別子の決め方です。問題(1)を解決するためには, 識別子は一意であれば何でも構いません。 (2)を解決するためには,refテクノロジを導入する日記間での合意が必要になると思われます。
考えられる識別子として,
  1. hnsでいうところの#nameの内容を使う(hnsではこれは一意になります)。'http://日記パス/?識別子#識別子'でアクセスできることを保証する
  2. URIフルパス表記とする
(2)のフルパスをRefererの情報で補完することによって圧縮する案は,本質的には(2)と等価でしょう。
(1)を採用した場合,例えばhnsでは'http://日記URL/?引数#name'の引数として'200103301S1'等が 受け取れるように改造する必要があります。 また,静的に'200103.html'等を生成している日記では対応が困難だと思われます。
(2)のフルパス表記及びその応用では,恐らくURLエンコーディングをしないといけないので, 生成側・逆リンク解析側ともに負担が増えますし,引数が長くなるのがちょっとイヤです *1 。 引数を縮める方法としては,Refererの最後のスラッシュ以下をエンコーディングするのが有効だと思われます。 例えば,'ref=?20010330#20010330S1'あるいは'ref=200103.html#20010330'(共に実際に引き渡すときはエンコーディングの必要がある)となります。

結局:

'here=ref'を埋め込んだ人は, 自分がどのセクションからリンクされたか知りたい[http://club.h14m.org/kenji/diary/?200103c&to=200103303#200103303] 人なので,置換された後のref=識別子が分かりにくくても長くても,それがあなたの望んだものだから,URIを丸ごとエンコーディングして渡すのが良いような気がしてきました。 また,中途半端に圧縮すると互換性の問題を生じる恐れがあります。
上の記事から辿れる リンク補足機能[http://www.etl.go.jp/~kfujiwar/message/messagehelp.html#link3] もURI丸ごとエンコーディング方式ですし,hnsのlink_logの実装もそれを期待している様です。

refテクノロジ対応日記システムの分類:

こちらにもメモを残します。
  • A. LINKにref=hereを見つけると、そのセクションの一意な識別子を返す
  • B. Aの識別子からその記事のURIが特定できる
  • C. 「ref=識別子」を食べても大丈夫
  • D. 「ref=識別子」を利用した逆リンク解析ができる
  • E. 自分向けリンクに「ref=here」が埋め込まれている
A,Bは、相手の日記に分析結果を提供するための機能。 C,D,Eは、自分が分析をするために必要な機能です。 Eを満たしているものは、C,Dは満たしている筈(ということを期待している)。
Aを満たすけれども、Bを満たさないシステムはあるかも知れない。 C,D,Eを満たすけれども、Aを満たさない残念なシステムもあるかも知れない。 A,Bを満たすけれど、C,D,Eには興味が無いシステムもあるかも知れない。

ref引数を圧縮するなら:

HTTP_REFERERからの相対パス表記を*can*にすれば良いですが、 実際にはこれを保証するのは難しいかも知れない。
ref引数の置換を行う場合、日記に記述したリンクの'ref=here'を、 'ref=識別子'に置換します。
識別子は日記内でユニークでなければなりません。 識別子によってリンク元を明示したい場合、識別子はURIである必要があります。 識別子をURIとする場合、URIは絶対パスあるいは考えられるHTTP_REFERERからの相対パスによって表現することができます。
*1: 圧縮すれば短くはなりますが,見た目として美しくないという問題は残ります。 'ref=%3f20010330%2320010330S1'等。

■ 関連記事

■2ぐるぐるします[ぐる]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

今日は 日記バード[http://www.nantoka.com/~kei/nb/] からのスタートです。

n年日記[http://www.yomogi.sakura.ne.jp/~hiro/diary/?200103c&to=200103291#200103291]:

n年続けようという意欲のためのデフォルト表示ということで。

Sound Engineeringのページ[http://ottotto.com/sound/index.html]:

ねぎ式[http://clotho.KU3G.org/diary/?20010329#200103291] より。
その昔,放送部あたりで活動してた頃を思い出すけれども,はるかにハイレベル。

あなたの超能力測定します[http://members.tripod.co.jp/shakasenz/esp/esp_top.htm]:

INTERNET Watch[http://www.watch.impress.co.jp/internet/www/wtoday/index.htm] より。
透視能力も予知能力もなかったけれど,石を割るのには成功したらしい。

ProjectX 〜 KAMEプロジェクト[http://homepage1.nifty.com/susho/diary/2001/03.html#30]:

必見ですね。

東京ペンクラブ メイド研究会[http://www.geocities.co.jp/WallStreet-Stock/3500/]:

いや、chmoe o+maidとかのビットはたっていないんですが、これはすごいと思ったです。
「おことば」の履歴[http://village.infoweb.ne.jp/~fxba0022/okotoba/0103okotoba.html#20010330] より。 MAID CAFE[http://www.mangazoo.com/news/news.php3?id=561] は行ってみても良いかな。秋葉原というのが狙っていますね。 長崎にもそもそも制服がメイド服な喫茶店があったと思いましたが、 特にその時は意識しなかったですね。

■ 関連記事

■3 Perlメモ[http://www.din.or.jp/~ohzaki/perl.htm][CLIP]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

URIの正規表現,エンコーディング(エスケープ)について。
RFC2396[http://www.csl.sony.co.jp/cgi-bin/hyperrfc?2396] によれば,':'も'/'もエスケープしないといけないんですね。

■ 関連記事

■4 企業ネットワークへの攻撃者は内部にいる可能性が高い[http://www.watch.impress.co.jp/internet/www/article/2001/0330/kpmg.htm][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

内部の教育不足を含めたら,情報漏洩系のセキュリティ問題の大多数は内部に原因ありでしょう。
セキュリティ対策は費用対効果で考えないといけないのですが, コストバランスを考えるときに,内部犯行のコストを考えてみるのは参考になります。
例えば,あるサーバをネットワークからの侵入者(例えば企業スパイ)から守るためにどれくらいコストを掛けるかという問題は, ネットワークを通じて侵入するコストが,内部のスタッフを買収するコストより大きくなれば十分(あるいはそれ以上は無意味)という考え方です。
もちろんリスク回避となるとまた状況は違ってきますが,セキュリティに掛けるべき費用を考える上で, 内部スタッフの教育やモラルのコストに目を向けることは大切だと思います。

■ 関連記事

詳細はこの日の詳細から

以上、10 日分です。

指定日の日記を表示

前月 2019年10月 翌月
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

予定

    ToDo

      link

      keikuma on Twitter

      keikuma Name:前田勝之
      Location:長崎市
      Web:http://www.nantok...
      Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

      サイト内検索

      Google AdSense

      Powered by hns-2.19.9, HyperNikkiSystem Project