日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

JavaScriptを有効にし、Cookieを受け入れ、以下のブラウザを使うことで完全なコンテンツが楽しめます。
Mozilla Firefox 3.0(Get Firefox)・Opera 9.6・Safari 3.2・Lunascape 4/5(Gecko)・Lunascape 5(WebKit)
Internet Explorer 7/8とそれを使うIEコンポーネントブラウザ(Lunascape・Sleipnirなど)

<< 過去

Google Chromeも可になったが

先日、勤務先の全社で標準アプリケーションとしてGoogle Chromeが追加された。

用途は社外のWebサイトの閲覧のため。

従来は標準アプリケーションのWebブラウザとしては Internet Explorer しかなかったのだが、

社外のWebサイトの閲覧に支障をきたすことがあるという理由で、代替策としてGoogle Chromeが追加されたのだという。

もっともそれ以前から職場単位でGoogle Chromeを使えるようにしているところも多かったようだけど。


社外のWebサイトの閲覧に支障をきたすことがあるというのは、

特定のWebサイトを見るとしばらくフリーズするような問題が発生するから。

どういう条件で発生するのかは調べてないんだけど、特定のWebサイトでは必ず発生するんだよね。

この問題に対する対策として、他のブラウザで社内での利用実績もある Google Chrome を使うことにしたようだ。

確かにChromeを使えばこのような問題は起きない。


一方で 社外のWebサイトの閲覧用となっているのは、社内のWebサイトの一部はInternet Explorerでしか使えないから。

基本的にChromeでの動作は保証されていない。

問題なく使えるページもそれなりにあるし、見た目が多少崩れる程度なら許容できるが、全く機能しないページも多い。

傾向を調べてみると 認証機能が対応していない、JavaScriptがActiveXに依存している、Microsoft製のシステム というところ。

認証機能が対応していないのは、おそらく回避策がありそう。同種の認証でもChromeで使えるページもあるわけだし。

JavaScriptがActiveXに依存しているのは、ActiveXに依存しないJavaScriptへの書き換えは可能だろう。

今後、社内のWebサイトでもChrome対応をすると書かれていたから、このあたりの問題も解決していくのだろう。

一方で、Microsoft製のシステムは、Internet Explorerの使用を前提として、Windowsと調和性の高いものを作ってるんだろうし、代替できないのでは? とも思う。


個人的には Mozilla Firefox をずっとメインで使ってるけど、あまりこだわりがないのならGoogle Chromeは無難でよい選択肢だと思う。

一方で職場で使っている限りにおいては Internet Explorerもそこまで悪くないのでは? とも思っていた。

特定のサイトでフリーズする問題は致命的なので、そこは問題だったのだが、

ただ、Windowsとの親和性という点ではメリットがあったことも確かで、それなりにメリットはあったと思う。

一般的にはOSやブラウザに依存するWebサイトはよくないけど、社内で使う限りにおいては許容できるし。


というわけで、最近はInternet ExplorerとGoogle Chromeで2窓して仕事をしている。

社内の設計資料を見るのはInternet Explorer、メーカーの資料を見るときはGoogle Chromeと言った具合。

本当はこの2つを1つのブラウザで両立できればよいのだが。


Author : hidemaro
Date : 2018/06/07(Thu) 21:49
Linux・Net・Web | Comment | trackback (0)

上位64ビットと下位64ビット

往復のバスで、ネットワークスペシャリスト試験の本を見ながら勉強をしていた。

名前は知ってても中身はよく知らなかった技術、名前も知らなかった技術、いろいろあるんだなぁと。


IPv6のIPアドレスは128ビットと非常に長い。

IPv4ではグローバルIPアドレスを個々のクライアントに割りあてることは難しく、

各クライアントにはプライベートアドレスを割り当て、家で1つのグローバルアドレスを共有するとかやっていたが、

IPv6ではアドレス空間が広いので、全ての機器にグローバルアドレスを割りあてることができる。


ところで、このIPv6のIPアドレスの割り当て方だが、

上位48bitはルーティングプレフィックス、それに続く16bitがサブネットID、最後64bitはインターフェース識別子というのが標準らしい。

ルーティングプレフィックスはIPアドレスの割り当てを受けた会社などを表し、

サブネットIDはその中で細分化されたセグメントを表す。

すなわちA社がIPv6のアドレスの割り当てを受けると、2001:db8:1234::/48 のように割りあてられる。

そして、社内のネットワークセグメントに対して 2001:db8:1234:abcd::/64 のように割りあてていく。

その上で最後の64bitのインターフェース識別子だが、MACアドレスから生成する方法が標準的らしい。

例えばMACアドレスが00:00:5E:00:53:00の機器が、2001:db8:1234:abcd::/64 のネットワークにいる場合は、

2001:db8:1234:abcd:0000:5EFF:FE00:5300 というIPアドレスを使うという具合に。

だから、IPv6の場合はDHCPなしでも自動的にIPアドレスを割りあてられるとされている。(DHCPを使うこともできる)


ここで、あれ? と思った。

それはMACアドレスというだけで世界中で一意なはずなのに、

なんでIPv6は48bitのMACアドレスよりはるかに長い128bitのアドレス空間を持っているのだろうと。

MACアドレスはネットワークの第2層(データリンク層)で重要な役目を果たしている。

このレベルではパケットのあて先をMACアドレスで表している。

その役割からすればMACアドレスは同一セグメント内で被らなければよいが、原則として世界中で被らないようになっている。

なぜ、その48bitでは全く足りないのだろうか?


日常生活に例えてみると、例えば「山田太郎」という名前の人は世界中に1人しかいなかったとする。

世界中で1人しかいないので、職場にも1人しかいない。というわけで、職場で山田太郎さんを呼べば必ず一意に決まる。

これがデータリンク層でのMACアドレスの役割。

とはいえ、世界中で一意だからっていって、世界中どこかにいる山田太郎さんを探すのは現実的にはできない。やはり住所が必要だ。

IPv6のアドレスは、前半64bitが住所相当、後半64bitが名前相当ってことですね。

前半64bitの住所相当でネットワーク上のどこにいるか特定して、あとは後半64bitでネットワーク内の誰か一意に特定するってわけですね。

これがIPv4のときはグローバルアドレスでは上で言うところの住所相当しか表せなかったと考えるとよい。

そこから具体的に誰と通信するかというのは、ネットワークアドレス変換(NAT)任せだった。

IPv6ではどこの誰かというのが全てアドレスに収まるから、全クライアントがグローバルアドレスを持てるってわけ。


ちなみにIPv6ではプロバイダーには原則として/32単位でアドレスを払い出しているそう。

プロバイダーはユーザーに/48単位またはそれより細かい単位で払い出す。

そして各ネットワークセグメントには原則/64単位で割りあてるというわけだ。

別に/64より細かく割り振ってもよいのだろうが、MACアドレスからの自動生成の都合も考えるとこれがよいということらしい。

なんでIPv6は/64が最小単位なんだろ? って思ってたんだけどそういう意味だったんですね。

かなり荒っぽい割り振り方に見えるけど、アドレス空間が非常に広いので問題なしということらしい。


確かにIPv6のアドレス空間が広いことは知ってたけど、具体的なところはあまり知らんもんだなと。

他にもIPv6関係でいろいろな技術が紹介されたけど、いやはや。


Author : hidemaro
Date : 2018/03/06(Tue) 23:50
Linux・Net・Web | Comment | trackback (0)

新gTLDだから取れたドメイン

金曜に出勤したら、勤務先のグループ会社が新しいWebサイトに移行するということが発表されていた。

複数のドメインに分散していた情報を1つに集約するという意図もあるようだ。

そのドメインを見て驚いたんだけど、最近増えたgTLDだったんだよね。


ドメインというのは大きく、generic top-level domain(gTLD) と country code top-level domain(ccTLD) に大別される。

gTLDは .org のように地域によらず(.govのような例外もあるが)使われるドメイン、

ccTLD は .jp のように国・地域ごとに割りあてられたドメインを指している。

伝統的には gTLD というのは .com, .net, .org, .gov, .edu, .mil の6種類だった。

ところが2000年以降、.info, .biz などのgTLDが少しずつ増えてきた。

そんな中で2012年、条件を満たせばgTLDの新設ができるようになった。


具体的にはこういうこと。

いよいよ始まる、東京のドメイン「.tokyo」各ドメイン登録サービス提供事業者で先行登録受付開始~ インターネットを通じて東京を世界へ ~ (GMOインターネット)

トップレベルドメインに「.canon」を採用 本日よりグローバルサイトを刷新  (Canon)

新しいgTLDはドメイン業者が申請して取る場合、業界団体が申請して取る場合、自ら使用するために企業が申請して取る場合などある。

GMOはドメイン業者として.tokyoドメインの新設を申し出ている。目的は .tokyo ドメインを売って儲けることでしょうね。

一方で企業が自ら使うために新gTLDを取得する例もあって、確か .canon はその世界初の事例だったはず。

まだ .canon の使用例はそこまで多くないが、将来的にはグループ内のドメインをここに集約したいんだろうな。


なぜ、新しいWebサイトで新gTLDが選択されたか?

その理由はおそらく3文字のドメインを取りたかったからだろう。

3文字のドメインというのは歴史のあるドメインではまず取れない。そんなに短いのは取り尽くされてるから。

.info や .biz も登場当初はそういうことができたが、今となってはそれも難しい。

そんな中、新gTLDはものすごい数があるから、そんな短いドメインも取れる可能性がかなり高くなった。

用途に適した新gTLDで空いているかは分からないけどね。そう考えるとうまいこと見つけたなぁと思うんだけど。


ただし、せっかく3文字のドメイン取ってもそこまで短くはないんだけどね。

元々、5文字+.com で計9文字のドメインだったが、新しいドメインは 3文字+6文字のgTLDだから、.入れて計10文字、1文字増えてんだよなぁ。

この会社、もともと3文字の会社で、なんとかそこを生かしたかったんだろう。確かに前より直感的ではある。

でも、旧ドメインも悪くはなかったと思うんだよなぁ。2文字を足して.comを取ってたわけだけど、それはそれで字面よかったしね。

どうしてもこの文字列でドメインを取りたいというなら、新gTLDに飛びつく価値もあるんだろうけど、

多少は変えてもいいよっていうのなら、無難なところから選ぶ方が総合的にはいいような気はするな。


新gTLDが新たな選択肢を増やすことに役立つならよいのだけど、こういう困った話もある。

アダルトサイトからブランド保護 (お名前.com)

.xxxドメインはアダルトサイト向けに2011年に追加されたgTLDだ。(なので一般的に申請でgTLD取れるようになる少し前のこと)

.xxxはアダルトサイト専用なので、ゾーニングに役立つという触れ込みで導入が認められた経緯があったようだが、

アダルトサイトが必ず.xxxを使ってくれる保証はないわけで、実態としては何の役にも立っていない。

その一方で自社の商標が.xxxと組み合わせて使われるのを不都合と考える人のために、保護用にドメインを取るということもできる。

お名前.comは保護用に.xxxなどアダルトサイト向けドメインの取扱を行っている。実用目的で使える.xxxドメインは取り扱っていない。

そんな商売ありかよって思うんだけど、新ドメインには原野商法のような側面もある。


ちなみに新gTLDと国際化ドメインの組み合わせというのもある。

例えば .xn—q9jyb4c 、これを見ても意味不明だが「.みんな」ってことですね。

はじめよう.みんな

なかなか国際化ドメインも使い所が難しいところだが、日本語ドメインならトップレベルまで日本語にしたいという話はあろうと思う。

日本語.jp のように日本語+ローマ字では中途半端じゃないかという話。

そう考えると国際化ドメインの新gTLDというのもニーズがあるのかなとは。

まぁそもそも日本語ドメインってのがどうなのよって話はありますけどね。


Author : hidemaro
Date : 2018/01/06(Sat) 23:55
Linux・Net・Web | Comment | trackback (0)

リモートアクセスのどれを選ぶか

今度、連日出張の予定がある。毎日通うので日帰り出張なんだが。

問題はこの出張期間と月末が被ること。どうしても月末にはやらないといけない処理がいくつかある。

どうしても月末処理ができない場合は課長に代理入力してもらうとか、代替策がなくはないのだが、正直めんどくさい。

これがきっかけになってリモートアクセスの準備をすることにした。


リモートアクセスはもともと出張先から会社にアクセスするという用途で、最近は在宅勤務という用途でも使われている。

在宅勤務向けに機能強化が行われ、現在は3種類のリモートアクセス方式が提供されている。

アプリ画面転送方式、VPN方式、シンクライアント方式の3種類だ。(社内での呼び名はこんな名前じゃないけど)

一体どの方式を選ぶとよいのだろうかと困ってしまった。


アプリ画面転送方式はおそらくこの中では一番利用者が多い方式だ。

もともと社外でのE-mail送受信のために、メーラーの画面を転送して表示する機能があった。

ただ、最近まではメーラーしか使うことが出来ず、添付ファイルの表示すらままならない状況だった。

これが在宅勤務対応として機能強化され、現在はブラウザやオフィススイートも一通り使えるようになった。

在宅勤務で使った人の感想を聞くと、「普通の事務作業ならば社内にいるのとほぼ同じように使える」とのこと。

アプリ画面転送方式は私物のPCでも使えるので、在宅勤務のために会社からPCを持ち帰りとやる必要が無いと。


VPN方式は、社外から社内のネットワークにアクセス出来るようにする方式だ。

この方式はPCが直接社内のネットワークにつながるので、社内のネットワークに接続できるPCであることが前提になる。

会社所有のPCを持ち出して、VPNで社内のネットワークに接続すると、ほとんど社内にいるのと同じようにPCが使えると。

機能的には最強なのだが、必ず会社所有のPCを持ち出す必要があるのが難点だ。

あと、使ったことある人に聞くと、VPNを導入する手順がめんどくさいらしい。確かに説明を見る限りはめんどくさい。


シンクライアント方式は、仮想PCの画面を転送する方式だ。

物理的なPCをレンタルする(基本的には業務用PCはレンタル)のと同じように、仮想PCをレンタルする。

するとその仮想PCは自分でカスタマイズでき、一定の範囲でアプリをインストールすることもできる。

画面を転送すること、私物のPCでも利用可なところはアプリ画面転送方式と同じなのだが、

カスタマイズ性が高く、社内でも社外でも仮想PCを使うことにすれば、全く社内・社外で使い勝手が変わらないことになる。

ただし、この方式は仮想PCをレンタルするという都合、他の方式よりもお金がかかる方式とされている。


今回はPCを持ち出す前提で考えたので、アプリ画面転送方式かVPN方式のどちらかだろう。

在宅勤務向けの機能強化が行われる以前だと、VPN方式にならざるを得なかったのだが、今はどちらでもやりたいことはできる。

持ち出し前提ならばVPN方式が一番高機能だが、導入手順がめんどくさいのが難点。

今回の用途はアプリ画面転送方式で対応でき、なおかつこちらは導入手順がとても簡単。

他の用途として、在宅勤務(といっても今は新人扱いで在宅勤務の対象外だが)などを想定しても、アプリ画面転送方式の方が好都合そう。


というわけでアプリ画面転送方式でリモートアクセスを使いたいと課長に言うと、

よろしいということで手続きが進み、即日利用できる状態になった。

シンクライアント方式は仮想PCのレンタルと言うことで重いけど、あとの2方式は部署負担が安いか無料かなのであまり気にしないようで。

初期設定も多少あるが、それもパスワードの設定ぐらいで、クライアント側はほぼ準備いらずだった。


あと、さっき試してたんだけど、実は自分のノートPCでも問題なく使えた。

もう最近はタブレットばっかり使ってノートPCを使う機会も減ってはいたが、久々に掘りだしてきた。

意外とサクサクと動くので、これならあえて会社のPCを持ち出さなくてもよいのでは? と思った。

このPCって今となってみればあまり性能がよくないんだけど(cf. Windows 10にしたかった)、それが想像以上に影響しない仕組みのようだ。

画面転送方式ってことは、このPC自体の性能にはあまり依存しない。その一方でオーバーヘッドもそう大きくない。

PC持ち出しのための手続きを進めて、承認はもらったけど、結局、必要なかったのかもね。

あんな腐ったノートPCで仕事にならんだろと思ったんだけど、意外とそうでもなさそうだった。


Author : hidemaro
Date : 2017/11/22(Wed) 23:33
Linux・Net・Web | Comment | trackback (0)

チェックを入れるだけで人間判定?

GoogleからreCAPTCHAのAPIのバージョンアップをしないと使えなくなるぞという連絡が来た。

reCAPTCHAはこのBlogでトラックバックスパム対策に使っている。

reCAPTCHAを使ってスパムよけ

画像の文字を打ち込むことでBotでないことを確認すると。


APIが変わるとどうなるんだろうということで見てみると驚きの変貌を遂げていた。

What is reCAPTCHA? (Google)

I’m not a robot(私はロボットではありません)というチェックボックスにチェックを入れるだけで、判定できるようになるらしい。

えっ、それで人間かBOTか判定が付くの? と思ったかも知れないが、別にこの行為だけで判定しているわけではない。

GoogleではreCAPTCHAにアクセスするユーザーの挙動を観察して、人間っぽいかBOTっぽいか調べているのよね。

ここで人間っぽいと判断されればチェックを入れるだけだが、BOTっぽいと判断されれば画像などを使った認証が必要となる。

デバッグ中にreCAPTCHAへのアクセスを繰り返したら、BOTっぽいと判断されてしまい、

「私はロボットではありません」にチェックを入れると、写真を使った認証画面が出てきた。

ここで正解すればチェックが入るという仕組みになっている。


以前からreCAPTCHAではユーザーの挙動を解析するということをやっていた。

人間っぽいと判断されれば簡単に読める文字が、BOTっぽいと判断されれば読みにくい文字が表示されていた。

これをさらに推し進めてreCAPTCHA v2では、人間っぽいと判断されればチェックを入れるだけでOKとすることにした。

さらにこれを推し進めたものとして Invisible reCAPTCHA というモードがある。チェックを付けなくても認証が完了するモードだそうで。

一方で、BOTっぽいと判断されたときの問題も文字を打たせるではなく、写真を選ばせるという問題に変わっている。

これはスマートフォン・タブレットでの使い勝手を考慮してのことらしい。

人間にとっては易しく、BOTにとっては難しく、ということを考えると文字認識という問題はやめた方がよいと考えたようだ。


導入法だが、まず、上記WebサイトでAPIキーを入手する。

そして、認証を必要とするページのHTMLにコードを貼り付ける。

最低限、script要素とdiv要素を1行ずつ貼るだけで完了する。

その上で、認証結果を受け取ったら、APIのURLにシークレットキー・認証結果・ユーザーのIPアドレスを投げると、

認証結果がJSONで返ってくるから、successがtrueかfalseか確認する。

サンプルコードを探してきて貼ってもいいけど、自分で書いても高々知れているので、今回は自力で書いた。


というわけでトラックバックURL作成ページを見てみると、

「私はロボットではありません」のチェックボックスが表示される形式に変わっているはず。

実態としては使用実績はごく少ないんだけど、今後も安心ということで。


そしてもう1つ、reCAPTCHA使ってるところあったな。

メールアドレスを隠すのに、Mailhideを使ってるんだよね。

Mailhideは古いreCAPTCHAのAPIを未だに使ってるので、大丈夫かなぁと。

Mailhide側で新しいAPIに移行してくれれば対応不要なんだけど、そもそもメンテナンスされてるんかいって話。

reCAPTCHA v2を使ってE-mailを隠すものを自作しますかね?


Author : hidemaro
Date : 2017/10/20(Fri) 23:40
Linux・Net・Web | Comment | trackback (0)

無料で自動の認証局

明日から徳島に出かける。

今日はえらく涼しかったけど、明日からは暑いんだそうで。

徳島にいると、外にいる時間が長いだろうから、なおさらねぇ。


だいぶ前から気づいてたんだけど、StartSSLの証明書がGoogle Chromeで安全ではないと表示されるようになった。

これは、StartSSLがポリシーに反する証明書の発行を行っていたことに対する対抗措置だ。

グーグル、中国の認証局WoSignの証明書を拒否へ--「Chrome 61」から (CNET Japan)

そもそもの問題を引き起こしたのは中国のWoSignという認証局なのだが、

WoSignはStartSSLを買収して傘下に収めていて、なおかつWoSignの中間証明書をStartSSLに署名させていたので、巻き添えを食らうことになった。


有効期限が切れて、新しい証明書に変えるときに別のところに乗り換えようとは思っていたのだが、

どうせ自分しか使わないんだし、エラーを無視してアクセスして、当面は使い続けようと考えた。

ところが最近、エラーを回避してアクセスすることができなくなってしまったので、早急に対策が必要となった。

他の認証局で無料で使えるところはないんかと調べていたら、Let’s Encrypt という認証局があることがわかった。

ドメイン認証による自動・無料の証明書発行システムが特徴で、

すでに多くのブラウザで導入されているIdenTrust社の署名を受けているので、無料で入手できるSSL証明書としては十分なものだ。


無料はともかく自動ってどういうことよってこういうこと。

Certbot

ドメインを持っているのが前提だけど

ここから certbot-auto というスクリプトをダウンロードして、

# ./certbot-auto certonly

として、多少の必要事項を入力するだけで、自動的にドメイン認証を行って証明書が発行される。

さらに、オプション次第ではApacheへの設定まで自動でやってくれる。

# ./certbot-auto –-apache

ただし、有効期間が3ヶ月とやや短いので、更新の頻度が高くなる。

でも、そもそも証明書の発行が自動化されているので、更新も自動的にやらせればよく、

cronとかで定期的にコマンドを実行すればよいと書かれている。

40 2 * * 0 certbot-auto renew 2>&1 | grep Congratulations
44 2 * * 0 service httpd reload >/dev/null 2>&1
45 2 * * 0 service postfix reload >/dev/null 2>&1
46 2 * * 0 service dovecot reload >/dev/null 2>&1

毎週日曜日の早朝にcertbotを実行して、自動的に更新を試みてもらう。

有効期間が1ヶ月以上残っている場合はそのまま、1ヶ月を切ったら更新をするということになるようで。

その後、Apache・Postfix・Dovecotに更新後の秘密鍵・証明書を読み込んでもらう。

おそらくこれでいけると思うんだけどね。


僕がStartSSLの証明書を使っていたのは無料だからということに尽きる。

オレオレじゃないSSL証明書を作りにいった

それ以前はオレオレ証明書だったんだが、やっぱり認証局証明書をインストールするのは手間ですから。

一方でStartSSLは有料での証明書発行も行っており、大手よりも割安ということをウリにしていた。

商売としての肝はこっちなのだが、せっかくお金を出したのに、ブラウザに弾かれてはたまったもんではない。


これだけ見れば安かろう悪かろうという話だろうと捉えることも出来るが、そうでもなさそう。

グーグルが無効化を発表、シマンテックのサーバー証明書にダメ出し? (ITPro)

Symantecの認証局ってもともとはVerisignのもので、いわば認証局の名門とも言えるところ。

とんでもない大ごとなのだが、さすがにSymantecはそのまま投げ出すようなことはしないよう。

どうするのかというと、Symantecは認証局事業をDigiCertという既存の認証局に譲渡してしまう。

そして、以前からのSymantecのお客さんにはDigiCertの証明書を発行する。これで無効化の影響は抑えられると判断したようだ。

さすが大手とも言えるが、一方で大手の認証局すらも1つ問題を起こすだけで弾かれてしまう世界でもある。


ちょっと話が脱線してしまったが、StartSSLは商売として認証局をやっていた。

一方、Let’s Encryptは無料・自動というコンセプトでやっているので、完全に非営利の認証局だ。

SSL対応を後押しするため、最低限、安全性を確保できる認証局ということでやっているのだろう。

確かにこういう認証局があれば、安心してSSLを導入できるという考えになれるだろうな。

一方で、組織の実在性とかそういうことを証明するものではないので、そこで他の認証局とのすみ分けがある。

あくまでもSSL通信の安全性を担保することだけが目的ということだ。ただし、その用途では最適な認証局だろう。

そうそう、これが欲しかったんだって話ですね。


Author : hidemaro
Date : 2017/10/07(Sat) 23:51
Linux・Net・Web | Comment | trackback (0)

投票ボタンを送る

あまり一般的に使える機能でもないんだけど……

Microsoft Outlookでは投票ボタンという機能がある。

E-mailに投票ボタンを付けられる機能で、Exchangeサーバーに参加しているユーザー間に限って使える。

電子メール メッセージで調査を実施して結果を確認する (Microsoft)


この機能、そんなに使用頻度は高くないが、確実に出番がある機能ではある。

用途としては、

  • 部内全員に対して行われる調査(該当・非該当の確認)
  • 飲み会の参加・不参加の確認
  • 労働組合の採決事項の賛否の確認

最初に挙げたのは業務だけど、あとは業務外だね。

というか最初に挙げた調査って年1回しか行われないのよね。

業務で使ってるの年1回だけって言うと存在意義を疑われるが、業務外では役立ってるので。


この機能は回答者にとっても、回答を求める側にとってもメリットが大きい。

回答者にとってのメリットは、投票ボタンをクリック→コメントを任意で付ける で回答が完了すること。

回答を求める側にとってのメリットは、投票結果が表形式で見られること。

E-mailで任意に返信してもらう方式だと、集計は手で行う必要がある。

その手間が省けるというのは大きなメリットで、回答を求める側としては積極的に使っていきたい機能だ。

とはいえ、最初に書いたようにExchangeサーバーに参加しているユーザー間に限って使える機能なので、誰でも使えるもんではないんだけどね。


OutlookのE-mailは拡張機能がいくつかある。

1つが、会議の出席依頼を送って、それに対して出席・欠席・保留というのを選べる機能。

これも便利だよね。クリック1つで出席と回答できるし。

逆に返答不要の場合は、返信を要求しないを選らんで送ればいいんだけどね。そこはどちらも選べるのがポイント。

もう1つ、フラグという機能がある。E-mailに対して、アラームを付けたりできる機能で、通常は受信者が必要に応じて付ける機能だ。

ただ、送信者から受信者に対してフラグを付けることができるんだよね。

この機能を使うと、回答期限の直前にアラームを鳴らして催促させたりできる。

今まで何度かこの機能を使われたことがある。けっこうマニアックだが、確かに効果的な方法かなと。


なかなか一般的に使える機能かというと難しいんだけどね。

会議の出席依頼はThunderbirdでも対応してるように見えるけど、Outlookと相互に使ったことはないからよくわからん。

ただ、社内ではメールクライアントとか統一されているから、使えるものは使うでいいでしょう。

業務ではほとんど使わない機能だって、業務外で使い道があればそれはそれでよいだろうと。


Author : hidemaro
Date : 2017/08/24(Thu) 22:52
Linux・Net・Web | Comment | trackback (0)

なぜ常時SSL化をするか

最近、常時SSL化という流れがあるらしい。

BASEが独自ドメインも常時SSL化、グーグルの「SSL推し」に対応 (ITpro)

確かに、いろんなWebサイトでHTTPS使ってるよなぁ。


これまでも、パスワードや個人情報をやりとりするWebサイトではHTTPSを使うことは一般的だった。

HTTPSはHTTPの通信内容をSSLで暗号化してやりとりするもの。

この仕組みによれば、他に知られると困るような情報を安全にやりとりすることができる。

自分のサーバーでも、パスワードをやりとりするところ、プライベートなコンテンツはHTTPSを使っている。

クライアント証明書で通す

これはHTTPSのちょっと変わった使い方だけど、必要なところでピンポイントで使うという発想に違いはない。


それに対して常時SSL化というのは、必ずしも秘密にする必要が無い内容でも暗号化すると。

一般的に知られてるような内容をわざわざ暗号化するのは無意味と思うかも知れないが、

SSLには盗聴を防ぐ以外の目的もあって、そこに期待しているという話である。


盗聴を防ぐ以外のSSLの役割、それは改ざん防止という役割である。

SSLではサーバー証明書で相手が信頼できるか確認してから、End to Endで暗号化通信を行う。

以前、TwitterがEV証明書を使ってるって話を取り上げたことがあるけど(cf. そこでEV証明書がくるとは)、

TwitterにHTTPSでアクセスすると、ブラウザ上に「Twitter, Inc (US)」と表示され、相手が確かにTwitterであることを確認出来る。

そして、その内容はTwitterのサーバーを出てから、改ざんも盗聴もされていないことが保証されているわけである。

TwitterのWebサイトの内容が改ざんされていないということに価値を感じるかと言われると、それは微妙だが、

これがもし銀行のWebサイトだったり、行政機関のWebサイトだったら、改ざんされていないというのは重要な気がする。


常時SSL化の難点としては、通信のオーバーヘッドが増えることがある。

その一方でHTTPS限定の高速化技術もあるので、レスポンスが悪くなるとも限らないらしいのだが。

常時SSL化しても割が合うという算段は十分なり立つようだが、注意は必要だよと。


End to Endでの暗号化というのはけっこうメリットがあるという話を書いたわけだが、

逆に暗号化されていないからこそできることというのもある。

それがGoogle Chromeのデータセーバー機能である。

これはWebサイトのアクセス時、中間にGoogleのサーバーを介して、データを圧縮することで通信量を削減する仕組みだ。

Googleのサーバーが中間に入り、データの圧縮(ある種の改ざん)を行うということで、中間者攻撃と同じ仕組みである。

なので、この機能はEnd to Endでの暗号化を行う、HTTPSでのアクセス時は無効化されることになっている。

End to Endでデータの完全性を保証するということは、途中にデータセーバーの入る隙はないということである。


SSLを使わないと、データセーバーの恩恵は受けられるが、データセーバーと同様に中間者攻撃が入る隙がある。

逆に常時SSLを使うことで、盗聴防止・改ざん防止に強い効果があるが、その一方でデータセーバーのような存在は認められない。

常時SSL化の意味を理解するには、これがいい説明なんじゃないかなぁ。

その上でどっちがよいかというのは各自考えるべきということである。

世の中はGoogleの方針もあって、常時SSL化に傾いているようだけど。


Author : hidemaro
Date : 2017/03/24(Fri) 23:27
Linux・Net・Web | Comment | trackback (0)

3Gと4Gと4G+

Androidもバージョンによるんだろうけど、僕が使っている端末では、

携帯電話の電波表示に「4G」とか「4G+」と表示される。

今使っている通信方式が表示されるんだね。


ここで言う「4G」というのはLTEという意味で、FDD-LTEでもTD-LTE(AXGP)でも該当する。

このあたりの用語の使い方はわりといい加減である。

特にNTT docomoは真の4G、LTE-Advancedまで4Gという言葉を使うのを見合わせてきた経緯があるのだけど。

そもそもLTEを4Gと言えるか言えないかは通信速度の差だけなので、全部4Gと呼ぼうというのがSoftBank・auの考えだったのだろう。

Androidの解釈もLTE=4Gという解釈のようだが、通信会社の間で見解に差があるというのが気になるところである。

なお「3G」という表示もあるそうだが、HSPA+を含めた3Gネットワークだけに接続しているときはこの表示になる。

このあたりだとあんまり見ないかもねぇ。FDD-LTEのカバーエリアを見ると山間部の一部で入るぐらいかも。


問題は「4G+」という表示である。

これ調べてみたんだけど、キャリアアグリゲーションが適用されているということを表しているみたいね。

キャリアアグリゲーションは複数の周波数帯でLTE通信をして通信速度を上げる技術である。

実はSoftBankとY!mobileの合併を後押ししたのはキャリアアグリゲーション技術という話があって、

同じ会社になってれば、2.1GHz帯・900MHz帯(旧SoftBank)と1.7GHz帯(旧EMOBILE)のFDD-LTEを組み合わせることができると。(cf. “ついに来た”ソフトバンク合併でワイモバイルの運命は?(石川温氏寄稿) (週アスPLUS))

一方でAXGPも2.5GHz帯の中で2つの電波を束ねるという形でキャリアアグリケーションをやっていて、確かこっちの方が先行してたはず。

AXGPとFDD-LTEの組み合わせはやらないらしい。(AXGP網を提供するWireless City Planning社は別会社だから)

FDD-LTEの組み合わせで4G+になってるのか、AXGPの組み合わせで4G+になってるのかはわからないが、

1波だけ使う場合よりも速いスピードで通信できるって話らしい。


本当に速いんですかね?

理論上の最高速度は足し算だから速くなるんだけど、本当にその通りに行くのって?

キャリアアグリケーション対応・非対応の比較をした事例も見あたらないし、さっぱりわからんよね。

あと、同じ場所でも「4G」であるか「4G+」であるかはその時々で変わっちゃう。

複数の電波を使う都合、不安定になってるというのもあるのかもしれないし、利用状況に応じて使い分けさせたりしてるのかもしれない。

どちらにしてもBB.exciteモバイルLTEの頃よりは速くなってるしいいやって。

あれは端末の問題でLTEにありつけないことすら多かったから。本当のNTT docomo向け端末はそんなことないと思うけど。


「3G」と「4G」と「4G+」の表示があるAndroidだが、これまで使ってた電話も「3G」という表示があった。

「3G」以外の表示があるのかって? 海外ローミング向けにGSM(2G方式の一種)に対応してたから、そのときは「G」と表示されてたらしい。

日本以外では3G(W-CDMAまたはCDMA2000)と2G(GSM)併用の端末が多かったから、こういうのが重要だったんだよな。

VoLTEの時代がやってきたら、3Gと4Gの識別もしなくなるのかもなぁと、

2Gサービスを終えてしまった日本で表示されない「G」マークを思い出したのだった。


Author : hidemaro
Date : 2017/01/11(Wed) 23:20
Linux・Net・Web | Comment | trackback (0)

世界標準の絵文字たち

「PCでも絵文字打ったり表示したりできるんだね」って言ってる人がいたけど、

確かに最近はPCでも絵文字見るよねぇ。

Thunderbirdでメールを見てると時々絵文字が入ってたりするしね。文字化けしないし、ちゃんと表示される。


ご存じの方もおられるかと思うが、日本の携帯電話の絵文字はUnicodeに収録されている。

Unicode6.0の携帯電話の絵文字の一覧 (Wikipedia)

例えば自転車の絵文字は U+1F6B2 に登録されていて、それをUTF-8でエンコードすれば「🚲」と表示できる。

フォントが対応してるか知らんけど、たいていの環境ではなんかそれっぽいのが表示されるでしょう。


なぜ、Unicodeに絵文字が収録されたのか。理由はiPhoneとAndroidのスマートフォンが日本市場に乗り込むために必要だったからである。

日本では以前より携帯電話のメールで絵文字が使われていた。

当初は通信会社ごとに独自の絵文字体系を持っていたが、メールのシステムも閉じていたから問題は無かった。

後にPCや他の通信会社とメールのやりとりができるようになったが、互換性がないから「〓」に変換するなどの対応を取っていた。

2005年以降、通信会社間で絵文字の置き換えを行う仕組みができたので、携帯電話間では一定の互換性が得られるようになった。

ボーダフォン、3G端末から他社宛に絵文字入りメールを送信可能に (ケータイWatch)

ただし、PCは相変わらず絵文字対応ではないですから、「〓」への変換が続いていた。


スマートフォン時代となり、通信会社ごとに異なる絵文字体系をどうやって吸収するかということが問題となったのだろう。

その答えがUnicodeへの絵文字の収録で、AppleとGoogleの提案により絵文字がUnicodeに登録されたのだという。

iPhone3Gのときは、絵文字を使う通信会社はSoftBankしか想定されないので、SoftBankの絵文字だけに対応したのだそうだが、

iPhone4からはUnicodeの絵文字体系で処理するようになったとのこと。

各社独自の絵文字体系とUnicodeの絵文字体系が並立するという状況は続いているものの、

その一方でUnicodeに登録されたことで、Gmailを筆頭に携帯電話以外でも絵文字を使うことができるようになったし、

あと日本以外でも日本発祥の絵文字を活用するという動きが生まれた。日本向けに対応したが日本以外でも使えるようになっちゃったと。


そして気づいてみればPCでも絵文字が使われることがちょっとずつ増えていると。

Twitterではけっこう絵文字使ってる人を見るんだけど、Web上の画面では絵文字を選択して入力できるようになってるのよね。

Unicodeで選んで打ち込んでもよくて、ATOKパレットで探して打ち込めば、それでちゃんと表示される。

独自の絵文字体系ではなく、Unicode準拠であることの表れである。


このBlogの文字エンコーディングはUTF-8だから、上に書いたように絵文字を織り交ぜることは技術的には問題ないのだが、

PC用のATOKでは絵文字が打ち込みにくいですから。(Android用のATOKは簡単に打ち込める)

一方でこのBlogシステムは独自の絵文字システムがあって、Web上ではその絵文字は選んで打ち込めるのよね。使ったことないけど。

今だとUnicode準拠の絵文字を選んで入力できるUIにするんだろうなぁ。

僕は絵文字を使う習慣はずっとないんだけど、世の人々が使っているのを見るとアクセントにはいいのかもしれない。


Author : hidemaro
Date : 2017/01/09(Mon) 21:59
Linux・Net・Web | Comment | trackback (0)

Tools