日記帳だ! 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など)

<< 過去

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

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

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

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

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


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

在宅勤務向けに機能強化が行われ、現在は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)

いろんな周波数帯を持っていた

昨日、SoftBankとEMOBILEが合併直前から互いのネットワークに依存し、

合併してから3G網の集約を行っているということを少し書いた。

Y!mobileに帰ってきた

調べてみると、現在のソフトバンクはいろんな会社が獲得した周波数帯を使っていることがわかった。


現在のソフトバンクが使う周波数帯で一番古くから使ってるのが1.5GHz帯、

これは1991年からデジタルホン・デジタルツーカーがPDCサービス(2G)のために割り当てを受けたものである。

デジタルホンは後にJ-Phoneとなった会社である。

もう大昔のことだから忘れている方も多いだろうけど、かつてツーカーはJ-Phoneのネットワークにローミングを行っていた。

その都合、スカイメールは同一のシステムで、父の携帯電話がJ-Phone、母の携帯電話がツーカーだったときも相互にスカイメールが使えた。

デジタルツーカーというのはJ-Phoneとツーカーの合弁会社のような位置づけだったが、後に完全にJ-Phoneになっている。

その後、J-PhoneはイギリスのVodafoneに買収され、Vodafoneブランドに改め、国際標準の3G方式、W-CDMAによる3Gサービスを始めた。

2.1GHz帯はこのときに割り当てを受けたものだった。(なお、NTT DoCoMoのW-CDMAサービス、FOMAも2.1GHz帯である)

2.1GHz帯での3Gネットワーク充実には時間がかかったが、僕がVodafoneと契約した2006年頃には2Gサービスを上回るカバレッジとなった。

2010年の2Gサービス廃止後は、この跡地を3Gに転用して2011年にDC-HSDPAによるULTRA SPEEDを始めた。


2012年に2.5GHz帯でWireless City Planning社がAXGPサービスを開始したので、これをSoftBank 4GとしてAndroid端末で展開し始めた。

AXGPはかつてWILLCOMが開発してきたXGPが元になっている。Wireless City Planning社はWILLCOMからXGP事業を譲り受けてスタートした。

国際標準ということになっていたTD-LTEに準拠した方式なのだが、当時TD-LTEはほとんど普及しておらず、

これほど大規模なTD-LTEネットワークを構築したのはこれが初めてだったらしい。

一方で2012年、2.1GHz帯の一部でiPhone5用にFDD-LTEサービス、SoftBank 4G LTEのサービスを開始した。

FDD-LTEってNTT DoCoMoが2010年にサービス開始していたXiと同じ方式で、すでに世界的に普及していた。

iPhone5はTD-LTEには対応していなかったので、iPhone用にわざわざ3Gを削ってまでFDD-LTEサービスを開始させるという荒技に出たわけだ。

さらに2012年には、900MHz帯の割り当てを受けて、プラチナバンドと銘打って3Gサービスの充実を進めた。

NTT DoCoMoとauはアナログ時代から800MHz帯を持っており、3GではauはCDMA2000方式導入時から、NTT DoCoMoはPDC廃止後から使っていた。

SoftBankは過去の経緯からこの帯域を持っていなかったのだが、これは不利だと言ってなんとか900MHz帯の割り当てを受けた。

この結果、郊外を中心にカバレッジが上がったので、これをきっかけに僕も携帯電話を買い換えている。(cf. PANTONE 4が欲しいと言いますが)


ここまではJ-Phone→Vodafone→SoftBankが獲得した周波数帯を取り上げてきた。(AXGPは別会社ではあるが)

次にEMOBILEだが、こちらは2007年の参入時に1.7GHz帯の割り当てを受けて、3Gの高速データ通信方式HSDPAを導入してスタートした。

1.7GHz帯は当時の新規参入事業者向けの周波数帯で、実はソフトバンク’傘下のBBモバイルも一時は割り当てを受けていた。

ただ、ソフトバンクはVodafoneの買収で携帯電話参入することにしたので、結局はこれを返上している。

この返上したものは結果的にEMOBILEに割りあてられ、2010年から3Gの高速データ通信方式DC-HSDPAに使われ、

さらに2012年からのFDD-LTEサービスにも使われた。

このEMOBILEのFDD-LTEサービスに目を付けたのがSoftBankで、2012年にiPhone用LTE網としての活用のために提携を強化した。

当時のSoftBankではiPhoneで使えるLTEは2.1GHz帯のFDD-LTEしかなかったので、iPhoneユーザーが増えると対応できないぞとなった。

ここでiPhone5のハードウェアそのままで対応できる、1.7GHz帯FDD-LTEサービスを提供しているEMOBILEに頼ったわけだ。

今にして見ればLTE黎明期ゆえの奇策だったような気もするが、EMOBILEとしても悪い話ではなかったのは確かか。


ここからは3GからLTEの転換という形で話が進んでいく。

900MHz帯によるFDD-LTEサービス、プラチナバンドLTEを2014年にスタートさせ、FDD-LTEのカバレッジが上がった。

同時期、TD-LTEに対応したiPhone6が出て、これまでFDD-LTEを使ってこなかったAndroid端末でもFDD-LTEを使うようになった。

こうしてiPhone・Androidいずれも始まった、AXGP(TD-LTE)とFDD-LTEの両対応のサービスをHybrid 4G LTEとして宣伝している。

確かプラチナバンドLTE開始前でもFDD-LTEの方がエリアが広かったはずなので、Androidユーザーにとってはメリット大だったはず。

iPhoneもAXGPを使うようになるから、それでFDD-LTEにも余裕が出るでしょうという判断があったんだと思う。

次に1.5GHz帯・1.7GHz帯の3GサービスをFDD-LTEに転換する計画を立てている。

旧SoftBankにとっては1.5GHz帯は3Gの高速データ通信用のものだから、LTE時代となってはもはや過去のもの。

旧EMOBILEにとっては1.7GHz帯は唯一の3Gサービスだったから廃止になるとLTE以前の端末は使えなくなっちゃうのでそれなりに影響はある。

とはいえ、ほとんどデータ通信端末ですからね。LTEに移行するメリットも大きいので、そんなに移行には困らないだろうと。

これが完了すると、3Gは2.1GHz帯と900MHz帯に集約される。歴史の長い2.1GHz帯とプラチナバンドの900MHz帯さえ残しとけばいいよね。


今後は、かつてY!mobileが獲得していた700MHzでのFDD-LTEサービスの拡大(一部スタートしているが、基地局も対応端末も少ない)、

旧SoftBankが獲得していた3.5GHz帯でのTD-LTEサービスの開始が予定されている。

もはやLTEまみれの状況でさらにLTEが増えるということで、なんのこっちゃという話だが。

iPhone用のLTEがないからとEMOBILEに頼ったときとはかなり状況が変わってしまったなと。(合併があったからこそできたことも多いが)

本当に初期はAXGPが唯一のLTE網だったのに、気づけばFDD-LTEもかなり増えたな。


ところでなんでSoftBankは当初、LTE方式としてAXGP(TD-LTE)を採用したんでしょうね?

そもそもTD-LTEというのは上り・下りを時分割で使い分ける方式である。

上り・下りを周波数帯で使い分ける方式がFDD-LTEで、こっちが先行していた。

TD-LTEの方が周波数の利用効率がよいということで、そこがメリットになると考えていたのかな。

一方でAXGPはWILLCOMの開発していたXGPの技術が使われていて、そこで重要だったのがマイクロセル化である。

サービス紹介 (Wireless City Planning)

32kbpsのPHSがスタート地点に書かれているが、下の方にクラウド基地局という話が書かれている。これが特徴だと。

そういう性格から、混雑している地域での通信改善に有利で、SoftBankが宣伝する通信品質を作る上で重要な役割を担っているとのこと。

ただし、現在はAXGPもFDD-LTEも自動的に切り替えて使うから、AXGPを感じるのはPocket WiFiぐらいでしょうかね。(AXGPは通信量規制が緩和されることがある)


Author : hidemaro
Date : 2017/01/07(Sat) 14:31
Linux・Net・Web | Comment | trackback (0)

うるう秒で1秒ズレてる!

みなさま明けましておめでとうございます。

正月の朝起きて、雑煮を作って、あらかじめ作っておいた料理を出して、とやるのはいいけど、餅を買いすぎたことに気づく。

雑煮にぜんざいと食べた程度ではまだまだたくさん残ってる。3日を過ぎてもしばらく正月は続きそうだ。


今日の9時を迎える前にうるう秒が挿入されたということで、この地域では少し話題になった。

というのも日本標準時を作っている情報通信研究機構(NICT)が小金井市にあるから。

以前、武蔵小金井駅で降りたときに標準時を作っていることをアピールする時計が置かれていたから、そうかと気づいたんだけど。

NICT本部や小金井駅でうるう秒の挿入を見守る人たちがいたそうである。

なお、NICTの最寄り駅は小金井駅のお隣、国分寺駅である。

小金井市・小平市・国分寺市の市境が交錯しているところにあるのでこうなる。


うるう秒のことはこのBlogでも8年前の正月に取り上げているな。

お正月だというので時計を見てみた

地球の自転が厳密に24時間ではないので、それを調整するために1秒挿入するのがうるう秒だと。

ゆえに今日は1秒だけ長い1日ということになる。


あまりうるう秒挿入の実感がないかもしれないが、PCの時計を調べてみると気づくかも。

JST Clock

厳密な時間合わせができるわけではないが、1秒ぐらいの精度は十分出そう。

確かに昨日見たときには0.1秒進んでいるとの表示だったが、今見ると1.2秒進んでいるとなる。

1秒進んでいるというのは、標準時は8時59分60秒を数えているけど、PCの時計はこれを数える9時00分00秒になったという意味。

電波時計の腕時計の秒針を見てみると、これもちょうど1秒ズレている。

一方で、電波時計の置き時計、これは普段は窓から離れたところに置いてるから、標準電波を拾うことはないのだけど

今、窓際において手動で合わせに行ったら、PCの時計や腕時計より1秒遅い時間にセットされた。

こちらはうるう秒反映後の標準時を拾ったから、こちらは正確にセットされたわけである。


普通の時計はうるう秒に対応していないので、このようなズレが発生する。

とはいえ、普通の時計はそんなに精度が出ないから、定期的に時刻合わせをするので、そこで吸収すれば実用上の問題はないと考えられる。

腕時計は今晩、電波を拾えれば時刻合わせができるし、PCも1週間以内にNICTのNTPサーバーに時刻合わせに行くから大丈夫と。

でも世の中にはうるう秒に対応したシステムってのもある。

例えばLinuxのntpd、NTPサーバーからうるう秒情報を取得して、それに応じて時刻を調整している。

logを見てみるとこんなのが残ってた。

Jan  1 08:59:59 gmo kernel: Clock: inserting leap second 23:59:60 UTC
Jan  1 09:00:00 gmo ntpd[1482]: 0.0.0.0 061b 0b leap_event
Jan  1 09:06:54 gmo ntpd[1482]: kernel reports leap second has occurred

8時59分59秒にleap second挿入ということで、59秒を2回数え、9時00分00秒を迎えていると。

あら、あまり考えてなかったけど、この方式だったのか。

一応、うるう秒には対応しているが、8時59分60秒の存在は認められないので、59秒を2回数えるという方法で対応している。


よく使われるのは1秒の長さを伸ばして少しずつ吸収する方式だと聞いてたのだが、

標準設定ではドカンと1秒戻して対応するという方式になってたんだな。

時計合わせにおいて、ドカンと指定した時間に合わせる方式をstepモード、少しずつ調整する方式はslewモードと言うそう。

slewモードであれば時間が飛んだり重複したりしないので、他への影響は小さく抑えられるが、少しずつ合わせるから時間がかかる。

というわけで、調整する時間の長短で使い分けているのだが、この閾値は標準では128msなので、うるう秒ではこれを超えてしまうわけである。

だからstepモードで調整されちゃったわけだけど、うるう秒ぐらいはslewモードで対処してよというのが一般的な考え方。

というわけでこれはntpdの起動オプションまたはntpd.confで設定すればよい。

ntpd.confで設定する場合だと、例えばこう。

tinker step 1200

これで1200msまでの時刻合わせはslewモードで、それ以上はstepモードでって意味になる。

0にしておくと必ずslewモードで合わせるという意味になる。

なお、slewモードは1秒あたり0.5ms延長・短縮することで調整する方式で、1秒のズレを吸収するには33分かかる。

このケースにおいては9時00分00秒に1秒進んだと認識して、そこから33分間かけて1秒のズレを吸収すると。こっちの方がいいよね。


まさかうるう秒にこんなことが起きてたとは気づかず。とはいえ、特に問題はなかったけど。

1月のうるう秒は正月休み中だからトラブルが起きないように回避できるかどうかが全てを決めることになる。

まぁ1回設定してしまえばなんとでもなるんですけどね。

うるう秒がゆえに平穏な元日が訪れなかった技術者も世の中にはいるのだろう。残念な事だ。


Author : hidemaro
Date : 2017/01/01(Sun) 18:28
Linux・Net・Web | Comment | trackback (0)

Googleが言う安全性の高い方法

ちょっと前にThunderbirdからGmailにログインできなくなるという問題が発生した。

理由はGoogleに言われるがままに「安全性の低いアプリの許可」を無効化したからだった。

けっこうGoogleの要求は厳しいのだ。


Googleはなにをもって安全性を低いと判断しているのかというと、

共通のユーザー名・パスワードを使って認証する方式か否かというところだそうだ。

これまでThunderbirdでGmailにログインするときは、IMAPSでユーザー名・パスワードそのものを暗号化した上で送っていた。

暗号化しているので経路中で盗まれる可能性は低いが、その一方でThunderbirdにはユーザー名とパスワードそのものを記録している。

なのでここからユーザー名・パスワードが漏れるという心配がある。

さらにこのユーザー名・パスワードでGoogleカレンダーもGoogle PlayもYouTubeにもアクセス出来てしまう。

これがGoogleが安全性を低いと考える理由である。


この点について、Googleはいくつかの選択肢を用意しているが、

もっとも推奨されているのはOAuth 2.0で認証するという方法である。

ThunderbirdはOAuthでの認証に対応しているので、この方法で対応することにした。

アカウント設定で認証方式を「通常のパスワード認証」から「OAuth2」に切り替えると、

初回アクセス時にGoogleの認証画面がポップアップで出てきて、ここにユーザー名・パスワードを打ち込んで、

Thunderbirdに与える権限(Gmail)を確認した上で、承認とすれば、あとは普通に使える。


OAuthはWebアプリケーション間の認証手段として作られた仕組みで、Twitterとかでもおなじみの方式である。

OAuthで使うTwitter API

Twitterとそれを利用するアプリを例に取ると、このような流れで認証が行われる。

  1. アプリからTwitterにリクエストトークンを要求する
  2. アプリはユーザーをTwitterの認証画面に飛ばす(このときリクエストトークンを添える)
  3. 認証が完了するとアプリにアクセストークンが返される
  4. アプリはリクエストトークン・アクセストークンの組み合わせでTwitter APIを叩く

この仕組みではユーザーはユーザー名・パスワードをTwitterの認証画面に直接入力し、アプリ自体には入力しない。

アプリはリクエストトークン・アクセストークンを保持するが、これはこのアプリ限りのものであり、権限は限定される。

もし問題があると考えれば、ユーザーはアプリごとに許可を取り消すことができるようになっている。

OAuth 2.0ではメールプロトコルに取り込むことができるようになった。

これを受けて、GoogleはIMAPでのアクセス時にもOAuth認証を使って欲しいと言っているのだ。


ただし、当初の目的を達成する方法は他にも考えられる。

アプリごとに違うパスワードを使っておけばよいのだ。というわけでアプリパスワードという方式を用意している。

利用できる条件は2段階認証プロセスを有効にしてあること。

2段階認証プロセスはパスワードを使った認証をするたびにSMS等でワンタイムパスワードを使って認証も要求する方式である。

2段階認証プロセスの対象になるのはOAuthの認証を含めたWeb上での認証に限られるので、OAuth非対応のメーラーでは使えない。

その補完としてアプリパスワードという仕組みを用意しているという理屈らしい。

このパスワードは後から取り消せることと、パスワード変更など重要な認証には使えないという特徴がある。

これで安全性が保たれるという理屈だ。


そもそもOAuthが生まれたのは、ユーザーに代わってAPIを叩くWebアプリにパスワードを預けるのは危険だという考えがあったように思う。

だから自分のPCにあるメーラーからパスワードが漏れることを恐れるというのは新しい考え方に思える。

ただ、確かにその危険って昔からあったんだよね。

その答えは全知全能のパスワードを持たせないということなんだろう。

OAuthは権限を限定したアプリ専用のアクセストークンを与えるという方法で解決しており、

アプリパスワードは目的別のパスワードで、後から無効化できて、なおかつパスワード変更など重要な認証には使えないという制約がある。

2段階認証プロセスは本来のパスワードが全知全能にならないようにするための手段で、本当のパスワード+ワンタイムパスワードを要求すると。


Gmailのパスワードを起点に芋づる式にパスワードが漏れるような例も世の中にはあるそうだ。

それだけにGoogleも対策を取らざるを得なかったのだろう。(とはいえ既存ユーザーはあえて変更しない限り変わらないのだが)

とりあえず、OAuthはお手軽なので使える環境の人はぜひどうぞ。


Author : hidemaro
Date : 2016/12/21(Wed) 21:45
Linux・Net・Web | Comment | trackback (0)

Tools