修理よりは交換のほうがお好きか

夏休み明け、いない間に動いていた話はいろいろあるけど、

さほど慌ただしい話もなく、でも別のことでバタバタしていた。

それが故障した業務用PCが交換になったことの対応で、

データの移行・ソフトウェアのインストールなどやっていた。


以前も書いたことがあるけど、勤務先の業務用PCは基本的にレンタルなんですよね。

レンタルの良いところはいくつかあると思うが、

故障時にレンタル業者で代品・修理などの対応をしてくれることと、

あとは使用後のPCを回収してデータ消去・再利用など適切に対応してくれること。

これはなかなか代えがたいものがあるんじゃないかと思う。


故障ということでは過去に1度あったのだが、これはマウスの故障だったので、

レンタル業者がメーカーにマウスの代品を手配して終わりだった。

そういうのもちゃんと対応してくれるんだなと思ったけど。

(もっとも一部機種ではマウスが買い切りになるような話もあるようだけど)


今回は本体に取り付けられたキーボードの故障なのでそういうわけにはいかない。

とはいえ修理というのもあるだろうかなと思っていたら、

まもなく代品交換を手配するということになった。

ちょうどこの納品タイミングが夏休みに被ったんですね。

交換ということは従来のPCはもう帰ってこないということである。

なので必要なデータは忘れずにコピーしなきゃだめなわけですね。


回収したPCをどうするのかは知らないけど。

そこから修理して在庫にするのかもしれないし、もう廃棄するのかも知れない。

レンタル開始から一定期間経過後は修理・交換などはしないというルールがあって、

ライフサイクルからしてもう廃棄ということなのかなと思う。

(あえて修理してまで中古市場に流すとも思えないし)

今回はどっちでしょうね? 修理して在庫にするには年数が経ってる気もするけど。


故障部位からして、その部分だけ修理というのも現実的だった気はするし、

もし会社所有のPCだったら、メーカーに修理依頼することになったような気がする。

ただ、そうすると修理中はPCが使えないという問題があり、

じゃあその代品はどうするのかという話になる。

これに対してレンタル業者の交換対応は修理中に使えない期間はない。

ただし前後でPCが代わるので移行に手間がかかるのが難点である。

使えない期間を許容するなら修理対応の方が楽ということである。


いろいろありましたが今日1日で当座は不便がない程度にインストールもできたので。

ただ、あれやるならこれもいるなというのはまだいくつかありますね。

面倒だなぁとは思うからとりあえずは先延ばし。

電話番号がわかるとYahoo!が危ない?

ちょっと話題になっていたのだけど。

取引相手の情報表示の仕様変更について (ヤフオク)

従来、匿名配送以外の場合に表示されていた、出品者・落札者の電話番号が非表示になるということ。

どうしても電話番号の記載が必要な場合は、メッセージで別途聞くなどの対応ができるが、

宅急便・ゆうパックでは電話番号の記載は任意なので、問題ないのではとのこと。

ヤマト運輸の一部のシステム(法人向け)では電話番号を記載しないと送れないが、

仮に00-0000-0000とでも登録すれば進めるので問題はないのではとのこと。


まぁスムーズな配達を考えると電話番号書いた方がよいとは思うし、

前に住んでいた社宅みたいに、電話番号がないと不便だということであれば、

落札者側から伝達して書いてもらうということも可能だろう。

書留でも電話番号があると呼び出してもらえた

これはオークションで購入した商品を簡易書留で送ってもらったときの話で、

書留で電話番号を記載していることは少ないが、任意で記載することは可能で、

どうしても記載して欲しいと依頼して対応してもらったと。


それにしてもなぜこんなことになったのか。

原因はYahoo!のパスワード無効化時のログイン方式にある。

【再掲】弊社サービスや宅配業者を装う偽SMSや電話にご注意ください (ヤフオク)

現在のYahoo!の推奨のログイン方式はパスワードを使わず、

携帯電話回線と紐付けた上でパスワード無効化することを推奨している。

SoftBank回線を使っている場合は電話回線を使った認証が出来たり、

あるいは登録した端末であれば、FIDOによる生体認証という方法がある。

しかし、それにあたらない場合はSMS認証に頼っているのが実情である。

PCでは時々SMS認証が要求されるし、スマートフォン・タブレットでもFIDOと連携できないアプリではSMS認証だし、FIDO登録の前にはSMS認証がある。


もちろん、それでもSMSに書かれている確認コードをYahoo!以外に入力しなければ問題ない。

ただ「配送業者を装うなどしてSMS認証コードを巧妙に聞き出し、Yahoo! JAPAN IDを乗っ取る手口が発生」というのが実情だという。

おそらくこういう話があるのは、運送会社が電話番号を使って配送時刻の指定や配送状況の通知を行うことが増えているというのもあるんだと思う。

確かに運送業者自身がSMS認証を要求してくるケースは覚えがないけど、

運送会社も使っている「LINE通知メッセージ」を受け取るには、電話番号のSMS認証が要求されるというようなことはある。(SMS認証の主体はLINE)

利用者の錯誤により、本来Yahoo!以外のサイトに入力してはいけないYahoo!の確認コードを他人に教えるということが実際に起きているのは確か。

そこに利用者の落ち度があることは確かだが、被害軽減のためにはやむなしとのことか。


このような問題はヤフオク以外にもあるかもしれないが、

ログインに必要なIDまたは電話番号が入手できることが多いこと。

その上、電話番号があれば運送業者へのなりすましがやりやすいことがある。

Yahoo!のログインには、ID・携帯電話番号・メールアドレスが使える。

まず、IDは原則公開の文字列で、ヤフオク出品者・落札者のIDは公開される。

ただし、シークレットID機能によりログインに使うIDは別のものにすることはできる。

電話番号は回線認証を使っている人の場合はログインに使える。

メールアドレスはあえて登録した場合のみ使える。

ヤフオクでの落札者・出品者の関係においては、IDと電話番号が問題で、

いずれにせよシークレットIDの設定をすれば問題はないと思うが、使っている人はあまり多くないと思う。


こういう話、わりと最近にあったようなと思ったらSBI証券だ。

他の証券会社ではIDをユーザーが自由に決めることが出来ないので、

他サービスから流出したID・パスワードを単純に適用できないので、そこに困難さがあるが、

SBI証券ではユーザーが任意にIDを決められるため狙われたのではないかということである。

(SBI証券が狙われたわけ)

もっとも問題だったのはログインパスワードと取引用パスワードを分離しているにもかかわらず、同じ内容を設定している人がいたことが問題である。

ただ、他の証券会社ではログインに行きつくまでに困難があって、

なぜならばログインIDが割りあてられた数字だったり、GMOクリック証券ではIDの末尾2文字は自分では決められないなど、他のIDと一致しないことが多いのである。


他人から知れるIDであることが本質的にダメなわけではないと思うが、

IDがわからなければログインに行きつくこともできないので、

まずはここを公開されているIDや、公開されうる電話番号を使うのをやめるというのは意味があることだと思う。

その上で一番重要なのはパスワードであったり、認証コードを漏らさないということになると思う。

これらのデータを手入力するということがなくなればいいんですけど、

現実的には難しい面もあり、そこに付けいる隙があるのが実情である。


パスワードとSMS認証の2要素認証にするというのも考えられるけど、

そもそもパスワードを無効化するのはパスワードを忘れることへの懸念もある。

パスワードを付けたとしても、使い回しや忘れたときのことを考えればあまり効果は無いというのも判断としてあったんだと思う。

今回のようなケースならないよりはマシでは? とも思いますけど、どうでしょうね。


とりあえずシークレットIDの設定はしておいた。

これでログインへの到達が難しくなることは確かなので。

ワークアラウンドもちゃんとあるので、どうしても忘れたときはなんとかなる。

まぁログインできる端末が残ってればそういう心配も無いんだけど。

あと今までできなかったPCでのFIDO設定ができるようになってたのでやっておいた。

今後はPCでSMS認証が要求されることは大きく減るということである。

利便性も高くなるし、SMS認証の頻度が減れば、錯誤により確認コードを漏らしてしまう可能性も経るんじゃないか。

実は同じ会社のニュースサイト

最近、Yahoo!を開くと「Merkmal」が提供元のニュースが目立つ気がする。

なんやねんと調べるとどうもこういうことらしい。

「Merkmal」の母体は、2014年に開設し、乗りもの全般の話題で月間3600万PVを獲得している「乗りものニュース」(https://trafficnews.jp/)、および、2018年に開設し、月間2億2000万PVと日本最大級の自動車メディアへと成長した「くるまのニュース」(https://kuruma-news.jp/)です。

両メディアが主に個人消費者(サービスの利用者)の方々に向けたニュースを取り扱うのに対し、「Merkmal」では交通・運輸・モビリティ産業の事業者(サービスの提供者)や、この業界に進出したい人々に向けて情報を発信します。

((交通・運輸・モビリティ産業のビジネスニュースメディア「Merkmal」誕生 (株式会社メディア・ヴァーグ))

2021年1月開設だから最近開設というわけではないんですけどね。


ここに限った話でもなく、大手の新聞社ですらそうだけど、

Yahoo!ニュースで記事を読ませることで得られる収入は大きいのだろう。

ただ、そうすると同じ会社で複数の提供元を使い分ける意味はあまりなさそう。

その点で、この会社が目論んだ既存のサイトとの使い分けはうまく行ってるのかはよくわからない。

ただ、どうしてこういうサイトを別に作ったのかという意図を考えると、

ターゲットが業界関係者であり、この会社の収益源が広告であるということ。

すなわちは広告のターゲットが既存のサイトと違うということである。

既存のサイトはどっちかというと趣味の人を対象としていたわけですから。

出すべき広告は全く違うというのはわかりますよね。


それにしてもこの会社は一体どういう事業を営んでいるのか。

その実態を探るべく「社員紹介」を読んでいると、編集長の紹介があった。

朝は記事にする情報のチェックから始まります。記事の配信はある程度、事前の計画に沿ったものですが、編集部員やライターから上がってきた記事に速報すべきものや重要なニュースがあれば、臨機応変に対応しています。

午後は各社のプレスリリース(メディア向け情報の文書)が、おおむね14時頃をピークに届きますので、編集部全体で臨戦態勢に入ります。

(社員インタビュー / 見てくれている人を身近に感じられることが、やりがいにつながっています。)

概ね3タイプの記事があることがここから読み取れる。

1つ目は社外のライターから寄稿される記事、踏み込んだ内容はこれが多いんかな。

2つ目は社内の編集者が自主的に書いた記事、分野によってはちらほらある。

3つ目はプレスリリースを元に社内で書かれた記事。

このタイプはあまり踏み込んだ内容はなく単に転記しただけというような印象だが、

その内容の取捨には、自動車・鉄道・航空などの知見を要するということで、

そういう人を社内に置きながら、2つ目のタイプの記事も書きつつ、

主にはプレスリリースを選定して記事化する仕事を担っているということだろう。


こうしてYahoo!ニュースで目を引くのは速報性の高さもあるのだろう。

ただ、その内容の浅さというのは気になるところがある。

これはYahoo!ニュースの選定の問題かも知れないが、

新聞社の記事の場合、取材活動などで掘り下げられた記事を重点的に並べている。

そういうのに比べると、ただ書き写しただけとか、うさんくさいライターが書いた記事だなというような印象がある。

速報性があること自体が悪い話ではなく、知るきっかけにはなるんだけど。

しかし、それは自社サイトにアクセスしてくれる読者を増やすことに役立っているのかはよくわからない。


改めて見てみると、社内で書かれた記事の割合自体はそれなりに高く、

社外のライターに頼りっきりという感じではないと思った。

多くはプレスリリースなどの形で社外からもたらされた情報をもとにしたもので、

足を使って取材活動して書いたという印象はあまりないけど、

それでも一定の専門性のある記事を社内で書いたり選定できる体制は強みなのだろう。


少し前にさかのぼるのだけど、こういう事件があった。

DeNA南場会長「WELQを検索して愕然とした」–キュレーション事業に関して謝罪 (CNET Japan)

DeNAが手がけていた各種のキュレーションプラットフォームの記事の正確性や著作権上の問題が散見されたということである。

特にやり玉に挙げられたのがWELQという医療分野をターゲットにしたもので、

ほとんどが偽情報といった具合だったらしい。

病気の治療・予防といった分野は興味を引きやすいので、とにかく記事数を増やしたいがあまりに社外のライターに頼ったが、その内容は散々なものだった。

クラウドソーシングということで、素人に他の記事の盗用含め、いい加減な記事を書かせまくったのもある。品質はともかく単価は安い。

そして、とにかく記事数が欲しかったので記事を吟味して取捨選択することもしなかった。

内容に問題があっても、それはライターの責任に転嫁すればよいという考えもあったのかもしれない。

結局はこのWELQの問題をきっかけとして、キュレーションメディアは縮小していくことになる。

縮小したといっても未だにたくさんありますがね。SmartNewsとか有名ですが。


果たしてメディア・ヴァーグ社の事業がこの手のキュレーションメディアに近いのか、あるいは伝統的な出版社・新聞社に近いのかというのはよくわからない。

そこはあまり明確にしないようにしているのかもしれない。

従来、紙の新聞や雑誌というのは、紙面には限りがあり、発行タイミングも1日2回とか週1回とか限られていた。

インターネットではその制約がどちらもなくなったので、多種多様な情報が発信できるようになった。

ただ、広告収入が主体となり、アクセス数を重視するがあまりに、過激で中身のない記事が多くなり、それに行き着くところがWELQであったと。

ここもアクセス数重視というところに抗っていきたい思いは見えるが、現実は広告収入あっての事業であるという葛藤も見える。

弊社は、インターネットの持つ“スピード感”と、従来のメディアが持っている“質”の両面を備えたメディア運営を目指していきます。
またそれと同時に、ネットメディアの常識であった広告モデルからの脱却も、進めていきたいと考えています。

(代表メッセージ (株式会社メディア・ヴァーグ))

伝統的な新聞社でさえ見出しの付け方はアクセス数を意識してるのかな? と思うほどですから、

社内で専門性を持って記事を書いたり選定できる体制があるだけマシとしましょう。

簡単に疑似乱数を作る方法は難しい

職場で作っている検証用システムでこういうことをやりたかった。

出力値の候補を16個用意しておいて、これを一定時間ごとに切り替える。

この16個の値をいろいろな順番で出力したい。

16個の順番を並べる全パターンは16!=2.1×1013個もあるから、

全切替パターンをプログラムに記載するのは不可能である。


ということで乱数を使いたかったのだが、乱数ライブラリなんてないんだよな。

自分で疑似乱数生成器を作ろうということで、まず思いついたのはメルセンヌツイスター。

しかしどんな実装なのだろうと調べたが、概要を見て無理だと思った。

というのも624個もの32bit整数を内部状態として持つ必要があるからである。

周期が長くランダム性が高い疑似乱数が生成できる方法だが、

そのためには内部状態としてそこそこ巨大なものを持たないといけない。


だからといって線形合同法はわりと規則性が見えてしまうよなぁ。

デジタル回路でよく使われるLFSRはビットシフトが主体なので、これもほとんど規則性のある変化しかしない。

もうちょっと実装が容易で質の良い方法がないかと思ったら、Lagged Fibonacci法というのを見つけた。

疑似乱数列 Sn を Sn=Sn-j + Sn-k(mod m)という形で計算するというもの。

過去の乱数を2つ取り出して足すという簡単な計算ですね。

足し算以外の演算子、例えばXORでもLagged Fibonacciではあるようだが、普通は別の名前が付いている。


ただ、いろいろ調べてわかったのは、この成否を決めるのはk,jの数字で、

この最大値がある程度大きくて、初期値としてそこそこ質の良い乱数が用意できるかどうかが決め手になるようだ。

最初、k=1,j=7で試していたのだが、下位ビットの質がよくない。

それで典型例として書いてあったk=31,j=63でやると下位ビットまで質がよさそう。

質の良い乱数を作るには内部状態を大きくしなければならないと。単純にはそういう話らしい。

メルセンヌツイスターほどではないし、バッファさえ持てればよいので実現性はあるが。


しかし線形合同法だって下位ビットを捨てればそこそこ質がよいという話もあるんだよな。

線形合同法の欠点として、2個の乱数をペアにすると偏るというのがあって、

それを今回の目的に適用すると、出力値の遷移が偏ってしまうということになる。

ただ、下位ビットを捨てればその影響は減るという話があって、それは繰り上がりがあるからなんだと思うけど。

線形合同法 Xn=A×Xn-1 + B (mod m) で、A=214013,B=2531011,m=232(Visual Studioで使われている数字らしい)を適用して、

この結果を4bitごとに区切って2つペアにすると、下位12ビットまでの組み合わせは発生回数0回というのが存在する。

しかし、15~12bitでは発生回数が最大・最小の回数差がほとんどなくなる。

実際、Visual Studioでは下位16ビットを捨てているらしい。


32bitで計算して下位16bitを捨てても、16bit残って、これは16個の出力値選択を同時に4つ操作出来るということである。

それで実用上十分なランダム性が得られるように見えるので、これでよいのでは?

ただ、この下位ビットをいくつ捨てるとうまくいくのかというのもようわからん話ですがね。

疑似乱数の評価も理論的なところとそうでもないところがあるからなんとも。


というわけで最初は線形合同法を忌避してLagged Fibonacci法を選ぼうとしたが、

それはそれで乱数を63個置いておかないといけないのでけっこう大変だと。

線形合同法はなんやかんやシンプルなのが魅力である。

それで下位ビットを捨てればある程度いけるやろというのも知見であろう。

シミュレーションで露骨に偏らないことが確認出来たら、それでもいいのかもね。

今回の用途で求められるのはその程度のランダム性だし。


というわけでランダムに切り替わるというのもそれはそれで難しいという話ですね。

このシステムで他に乱数的に使えるものがないか考えてみたけど、

どうにも難しそうと言うことで、乱数を自分で用意しなければならなくなったと。

ところがこの疑似乱数というのは本当に難しい。

真の乱数発生器を取り付けたいぐらいめんどくさいが、真の乱数もそれはそれで難しいらしい。

キーボード触ってもスリープ解除してくれるな

デスクトップPCをスリープ状態にしてたはずなのに解除されてて、

なんでかなと思ったのだが、そういえばキーボードを交換したんですよね。

で、Windowsでキーボードにやっていた設定が吹き飛んでいたようだ。

というわけで再度同じ設定をするも、キーボードに触れると起動してしまう。

なぜだろうか。


そもそも、スリープモード解除をキーボード・マウスなどの操作でやるかどうかは、

Windowsのデバイスマネージャで行うというのがちょっとした驚きである。

デバイスマネージャでキーボード・マウスなどのプロパティを開くと、「電源の管理」というタブがある。

そこに「このデバイスで、コンピュータのスタンバイ状態を解除できるようにする」というチェックボックスがある。

標準ではONなのでこれを外すとキーボード・マウスを触ってもスリープ解除されなくなる。

新しいキーボードに取り替えたら別のデバイスとして扱われるようになり、

この設定が飛んでしまったんですね。そこまではすぐに理解できた。


しかし、これを無効にしても起動してしまうのでおかしいと調べたところ、

コマンドプロンプトで下記入力するとスリープ解除できるデバイスが表示されるという。

>powercfg /devicequery wake_armed

これで表示されたデバイスは……なんと指紋認証器だった。

いやいや、指紋認証器を触ったわけじゃないんだけどなぁと。

特に指紋認証器でスリープ解除できる必要はないのでこちらも同じ設定をして解除。

再度同じコマンドで確認すると「NONE」の表示。

こうするとキーボードを触ってもスリープは解除されなくなった。


というわけで誤爆だったわけですね。

マウスとキーボードのどちらかを封じたのに、封じた方のデバイスで解除できてしまうとか、そういうことはあるらしいから、それと同じかね。

デスクトップPCの場合、電源ボタンを唯一の解除手段にしたいことが多いと思うので。

ノートPCでもフタ以外の解除手段は使いたくないことはあるでしょうし。


このデスクトップPCのスリープを使う理由というのが、

不意にキーボードなど触れてしまってもなにも起きないようにという目的が大きい。

このPCは電源ボタンをスリープに割りあててあるから、テレビを見るとき(PCのディスプレイと共用)など、ワンタッチでスリープに入れてしまえば手軽で、

それで元に戻るときは電源ボタンを押せば、すぐにもとの状態に戻せる。

省エネというよりは誤操作防止という意味が大きいのはそういうことである。

だから勝手に復帰してもらっては本末転倒なのだが、標準設定はそうではないから戸惑う。

というかキーボード交換で変わってしまうのも、なかなか困るのだが。

msg形式ってなんで使ってるんだ?

今日、仕事で過去のE-mailデータを何らかの方法でアーカイブ化することに迫られ、

結局はMicrosoft Outlookからドラッグ&ドロップでmsg形式として保存することになった。

Outlookがないと中身が見られないなどの課題はあるのだが、

この方法を選ばざるを得なかったこともmsg形式のためである。


msg形式はOutlookの独自形式である。

メールデータをファイルとして出力する方法としてはeml形式がある。

eml形式はMozilla FirefoxもOutlookも対応している標準的な形式である。

でもOutlookでeml形式の保存はできなかった気がするな。読めたとは思うけど。

この形式はシンプルにメールデータをテキストで書き出しただけ。

Base64やQuoted-printableで変換されたデータもあるから、テキストファイルで開いてそのまま読めるとも限らないが、だいたい読めるんじゃないか。

それに対してmsg形式はOutlook以外で読むのは至難の業で、調べると困っている人が見つかる。


正直どうかと思う形式なのだが、他のメールの引用をmsgファイルの添付でやってくる人というのが社内にはけっこういる。

というか、多分うちだけの問題でもなく、Outlookの機能として「添付ファイルとして転送」というのがあるので、そうするとこうなる。

受け取った側がOutlookがないと使い物にならないのだけど……

社内なら問題にならんでしょうけどね。


どうしてこんな機能が使われるのかという話だけど、

複数のメールをまとめて転送したいというニーズがまず1つあると思う。

実際、複数のmsgファイルが添付されたメールというのはけっこうあった。

あとは添付ファイルとかHTMLメールの装飾とかもまとめて転送したいとか。

まぁ転送まで意識されていないメールというのはあると思うけど。


もちろんテキストで済むならばそっちの方が汎用性が高い。

別件ではQ&Aのメールをアーカイブ化するために、テキストで保存している。

OutlookでTXT形式で出力するだけで、それなりのテキストにはなる。

それをアップロードすれば、検索も容易である。

でも、メールを忠実に残せるわけではないので補助的なものではある。

実際、これじゃあさっぱりわからんなと思ったことはある。


というわけでmsg形式のせいでmsg形式を選ばざるを得ないのだった。

まぁ勤務先がOutlookをやめるということはないでしょう。

あれだけMicrosoft製品にズブズブなんだから。日本企業ではありがちでしょうけど。

実際、良いところはたくさんありますからね。Outlookも良く出来たソフトである。

ただ、このmsg形式がOutlook独自形式であるというのは、どうかと思うポイントで、Outlookを使わない人にとっては非常に不便な形式である。


なんでE-mailなんて古典的なもので、独自形式なんてあるんだよと思っちゃうけどね。

msg形式のファイルで保存するのも課題はあるけど、ここでは後からファイルを確認する頻度はそこまで高くないはずなので。

IPv6だけにできるとうれしい

先日、NTTドコモで通信障害があったが、そのきっかけになったのがIPv6シングルスタック方式の導入に伴う構成変更の影響だったという。

「IPv6シングルスタック方式」の提供を開始-IPv4アドレス枯渇問題へ通信事業者として対応- (NTTドコモ)

各端末にIPv6アドレスのみを付与する方式である。

日本では初めてだが、世界的に見ればモバイルインターネットでは普及しつつあるらしい。


従来、NTTドコモではIPv4とIPv6のデュアルスタックをやってきた。

IPv6対応のサイトへはIPv6で、IPv4のみ対応のサイトにはIPv4で通信すると。

この方式の欠点はIPv6とIPv4のパケットが混在することで機器への負荷が大きいこと。

そこで流れるパケットをIPv6に一本化したいということがある。

こういう考えは珍しいことでは無く、NTTのNGN網はIPv6しか流せないのもこのため。

ゆえにフレッツ光でIPoE方式を使う場合は、IPv6を使うことが必須になっている。

IPoEにしてみた


とはいえ、これだけだと、このサイトを含むIPv4のみ対応のサイトにアクセス出来なくなる。

うちのフレッツ光の場合、契約しているBB.exciteはDS-Lite方式でIPv4への接続をサポートしている。

IPv4の通信はルーターでIPv6のパケットにカプセル化され、プロバイダーのIPv4接続装置に送られて、ここでIPv4のNATが行われてインターネットに通じる。

家庭のインターネットではこうしてIPv6への一本化を図っている。

しかし、家庭内のLANではIPv6とIPv4が混在しており、ルーターがIPv6に一本化しているという状況である。


一方でモバイルインターネットのIPv6シングルスタックというのは、

各端末からの通信をIPv6に一本化するということである。

どうやってそういうことができるのか?

NTTドコモの資料には「NAT64/DNS64方式」「464XLAT方式」というキーワードがある。


NAT64/DNS64方式というのは、IPv4のアドレスにプリフィックスを付けたIPv6アドレスをIPv4宛の通信に使う方法である。

テクログ|「誰でも使える サーバーサイド Open NAT64実証実験」のご紹介 (A10)

IPv6のアドレスは128bit、IPv4のアドレスは32bitだから、96bitのプリフィックスを付ければすっぽり収まる。

まず、DNSのAレコードにあるIPv4アドレスを、プリフィックス付きのIPv6アドレスに変換して、AAAAレコードとしてクライアントに回答する。

これにより、IPv4しか対応していないサイトもIPv6のサイトのように見える。

そのIPv6アドレスに通信をすれば、変換装置でIPv4に変換されるというわけである。

こうすると、端末~変換装置の間はIPv6に一本化できるというわけである。


しかし、ブラウザみたいなのはこれでいいかもしれんが、

IPv4アドレスに直接通信しようとしたり、IPv6に対応しないアプリもあるだろう。

そこで補完的に使われるのが 464XLAT方式である。

Androidはあるバージョンからこの方式に対応していて、

NTTドコモはこれに対応した端末に限ってIPv6シングルスタックを導入している。

IPv4の通信を、IPv4のアドレスにプリフィックスを付けたアドレスへのIPv6の通信に変換する。

やってることはシンプルで、NAT64/DNS64方式とは補完的な技術と言える。


NTTドコモは「IPv4アドレス枯渇問題へ通信事業者として対応」と書いてあるが、

当然のことながら、各端末に振られたIPv4アドレスはプライベートアドレスであり、

IPv4では限られたグローバルアドレスを使い回すことでやっている。

NAT64/DNS64方式にしても、結局はIPv4の通信にはIPv4アドレスが必要で、

これもIPv4アドレスの使い回しを行うという点では同じ技術である。

ゆえにIPv6シングルスタックそのものはIPv4アドレス枯渇問題の対策というわけではないと思われる。

とはいえ、IPv6の導入自体は不可避であって、デュアルスタックよりシングルスタックの方が効率が良いということは事実である。


ちなみにWindowsも464XLAT方式に対応してるらしいですよ。

モバイルインターネットに直接接続する用途に限定されているけど。

もしかしたら固定回線でも普通に使われる技術になるかもね。


ちなみにBIGLOBEは固定回線にNAT64/DNS64方式を選択的に導入しているという。

世界初への挑戦!インターネットを快適にするNAT64/DNS64とは? (BIGLOBE Style)

これはMAP-E方式(これもIPv4をIPv6でカプセル化する技術)に対応したルーターがなくても、IPoE方式の恩恵を受けられるように考えられたものだという。

IPv6のパケットをそのままNGN網に出せるルーターさえあれば、

IPv4のみのサイトでも、DNSからIPv6アドレスを得て、変換装置までIPv6で通信できるのでIPoEの恩恵を受けられるということ。

しかしながら、ゲームなどでNAT64/DNS64方式ではうまく動かないものがあり、

そういうものは従来通りPPPoEで接続してもらうという形で回避する必要がある。

だからIPv6シングルスタックというわけではない。


まぁそんなこんなでIPv4とIPv6の共存技術にはいろいろあるんですね。

できるならどちらかに一本化したいが、一本化するにはそれなりの方法が必要ということである。

すでにNTTのNGN網の仕様とDS-Lite方式でこのあたりに少し触れていたから、

この話を調べて、なるほどなと納得したのだった。

Adblock用ブラウザがある

Webサイトの広告にも度が過ぎたものが多いので、

従来からPCではAdblock Plusの拡張機能をChromeに入れて対応してきた。

あんまり意識してないけど、ちゃんと効いてるみたいですね。

全画面表示の広告とかちゃんとブロックできてるみたいだし。


スマートフォン・タブレットは画面サイズに限りがある中で、

画面がほとんど広告に覆われてしまうこともしばしばある。

特に最近はGoogleがページ遷移時に全画面表示でブロックする広告を多用している。

Googleの全画面広告を表示しないように設定する方法 (サイト運営者の設定) (ぱらめでぃうす)

サイト管理者もこれはあんまりだと無効化していることもあるようだが、

こういう広告が出ることでサイトを去る人も多いという悪影響もあるからだ。

しかし意図せずに導入してそのままというサイトも多い。


しかしAndroidのChromeはPCのChromeと同じ拡張機能は入らないのである。

Adblockのためのアプリがあるが導入方法が複雑なこともしばしば。

それで諦めていたのだが、さすがにあまりにひどいだろうと思い調べたら、

Adblock機能が組み込まれたブラウザというのがあるんですね。

Adblockブラウザー (Google Play)

開くとABPというアイコンが表示されている以外はChromeとうり二つの見た目。

それもそのはず。Chromiumベースのブラウザに最小限のカスタマイズをしたものだからだ。


標準のフィルタだといろいろ足りなかったので調べてあれこれ追加。

それでこのブラウザで今まであまりにひどいと思ってたサイトをいくつか見てみたが、

画面の大半が広告で占拠されたり、全画面広告が出てくるようなことはなくなった。

早く導入しとけばよかったと後悔するほどに快適だった。

広告ブロックするとコンテンツが見られないような対抗措置にあうかと思ったが、

今まで煩わしいと思っていたサイトではあまり問題にならないようだ。


ただし、このブラウザはChromeの代わりになるものではないと考えている。

というのもパスワード管理がGoogleとは独立したものが備わっているためである。

アプリによってはGoogleや他のアプリのパスワード入力機能が使えることがあるが、

ブラウザ系のアプリはだいたいダメみたいですね。

なので、ログインが絡むところはChromeを使うのが基本になりそうだ。

広告が煩わしいのと、会員制サイトというのはだいたい両立しないので。

そのため今後も主たるブラウザはChromeである。


こういう機能を備えたAndroid用のブラウザはけっこういろいろあるらしい。

Vivaldiもそうなんですね。この名前を見て気付くかわからないが前身はOperaである。

そういえば昔はOpera使ってる人もちらほらいたよね。

結局のところ、これもChromiumベースであって、付加価値としてAdblockがあると。

しかし、どれを使っても結局はパスワード管理はそれぞれのブラウザで行われる。

そこがGoogleに連動するのがChromeであり、連動しないことが他のブラウザの長所だから。


Adblockが普及することによって広告収入を失うことはサイトの運営者にとっては問題である。

そこで自衛策として、広告が読み込まれなければ、ページを読ませないというような対策が取られることがある。

時々そういうサイトに遭遇しますけどね。でも昔より減った気がするな。

Adblockを有効化してると見られないようにするより、Adblockが普及している現状を受け入れた上で、

Adblockがあっても異常な動作とならないが、できるだけAdblockを回避して広告を出せるようにするという設計が求められているのかも知れない。

確かに取り除けない広告はけっこうある。Adblock Plusの機能不足というのもあるっぽいが。

しかし、目的のコンテンツと巧妙に混ぜられると除去できないのも道理とは思う。


とはいえ、今回の目的としてはこれでとりあえず満足。

あの全画面広告とか何タイプかの広告が除去できればとりあえずはいいや。

Power Appsの難しいところ

MicrosoftがOffice365の一部としてPower AppsというWebアプリを作れる機能を提供していて、勤務先でも一般の従業員が使えるようになった。

それで最近、既存の文書管理システムがSharePointに移転して、

どうにも使いにくい気がしたので、検索・表示機能をPower Appsで作れるか試してみた。

SharePointのリストを抽出するような処理はわりと簡単だった。


しかし、わりと簡単とは言ったものの制約が多いのも実情である。

Power Appsではリストの抽出処理をサーバー側に委任することができる。

このようにすれば大量のデータから必要なものだけを探してクライアントで取得できる。

1操作でクライアントが取得できるデータは500レコードとかに制限されているそう。

なので、もし委任機能がないとドキュメント番号が”XYZ-C1234”のドキュメントを1つ抽出するという処理すら実現できない可能性がある。

しかしサーバー上で処理できる操作にはいろいろ制限があるのもまた実情。


キャンバス アプリでの委任について (Microsoft)

わりと嘘も混ざっているのだけど。

SharePointに限ればこちらの方が詳細だがちょっとわかりにくい表記もある。

Power Apps は SharePoint の機能と操作を委任できます

データテーブルの入力を

Search(Docs,"DocNumber","DocTitle",SearchText.Text)

のようにすればSharePointリストのDocsからDocNumberとDocTitle列にSearchTextテキストボックスに入力された文字が含まれるものを抽出できる。

この処理はDocsのデータ数が多い場合でも、抽出後のデータが500レコード以下であれば期待通りに動くはず。

これはとてもシンプルで、こういう例を見せられるとPower Apps簡単だなと思うのだけど。


ここで作成者の情報で検索したいという話が出てくるが、これが容易ではなかった。

このシステムではドキュメントの作成者はAuthor列にPerson型で格納されている。

Person型は文字列ではないので、Search関数の検索対象にはできない。

さらに言えば、Filter関数での文字列比較に部分一致は使えない。

文字列の比較関数として委任可能なのは = と StartWith しかない。

このため、作成者名での検索は別に入力枠を設けて、

Filter(Docs,StartsWith(Author.DisplayName,AuthorSearch.Text))

のようにしなければならなかった。実際にはSearchの中にFilterを入れ子にしている。

しかし前方一致なんで “Tanaka, Haruki”のようなDisplayNameに対して”Haruki”で検索してもひっかからないんですよね。

何人も同じ名字の人がいると、名前の方が特徴的ならそっちの方が検索しやすいわけじゃないですか。

こういうのSharePointのデータ構造を決めるときに考慮されてるとよかったが。

まだ前方一致で名字の方からマッチするだけマシかもしれないけど。


あと、こういうのも委任できないというのが、○○が空白ではないデータを抽出するというもの。

IsBlank関数は委任不可だが、=Blank()という比較は委任できるという記載はあるが、

では、その逆はどうかという話である。

SharePointリストでは<>演算子、Not演算子は委任不可となっている。

このため、空白ではないデータだけを抽出するという処理は委任できない。

結果的にはこの問題は他の抽出処理で代替出来たのだが、なんでそれができないとなる。


このあたりのデータ処理は切実な問題で、Microsoftには改善を期待したいが。

それに比べればしょうもない話で、ダブルクリック(ダブルタップ)のイベントがないというのがある。

リストからリンクを開くというのをダブルクリックでできると便利だと思ったが。

リストを選択する処理とリンクを開くボタンを別に用意すれば、開くボタンではリストで選択されているデータのURLにLaunch関数で飛ばせばよいからとてもシンプルだが。

これについて調べたら、onselectイベントでボタンをクリックされた時刻差を測定して、条件分岐すればよいという案があった。

If(And(TappedUrl=Filelist.Selected.Link,

DateDiff(TappedTime,Now(),"Milliseconds")<1000 ),

Launch(TappedUrl);UpdateContext{TappedUrl:""}),

UpdateContext({TappedUrl:Filelist.Selected.Link, TappedTime:Now()}))

onselectイベント発生時にTappedUrlにジャンプ先とTappedTimeに現在時刻を保存し、

次のイベント発生時にジャンプ先が一致し、時間差が一定時刻以内なら飛ぶと。

なお、これをやる場合は、リストボックスの複数選択を切らないとうまくいかない。

複数選択可能だと、選択→選択解除になっちゃうからね。

まぁこの目的でリストボックスを使うなら複数選択にはしないでしょう。


Power Appsはデータを抽出して表示・編集するような用途がメインなんでしょうね。

SharePointリストってようわからん機能だなと思ってはいたけど、この用途ではかなり強力ではある。

整形表示しないとさっぱり使いにくいが、整形表示はPower Appsでできる。

Power AppsもWebページと同じように扱えるので、利便性はそこそこ高いのでは?

ただページを最初に開くときちょっと時間がかかりますけどね。

あと、処理するデータ数が増えると、サーバーに委任するにしても、サーバーから転送するにしても遅くなってしまう。

それがどれぐらいなのかな? というのは気になるところである。

画像保存を困難化してはいるが……

とあるサイトで画像が保存できなくて、一体どんな仕掛けなのかと気になって、

それでGoogle Chromeの開発者ツール(F12)で調べてみたのだが、

実はソースコードにimg要素がべた書きされていて、

それをJavascript・CSSで触れなくしてあっただけだった。


Javascriptで画像のダウンロードを困難化する話は聞いたことがあったが、

CSSも使われていたようである。

Javascriptでの対策としては、oncontextmenu, onselectstart, onmousedownの各イベントにreturn false;を設定するというもの。

oncontextmenuは右クリックや長押しなどでメニューを出すときのイベント、

onselectstartはテキストなどを選択開始する操作を開始するときのイベント、

onmousedownは左右問わずクリックするときに発生するイベントである。

いずれも発生時にreturn false;とすることで当該操作を無効化できるらしい。

主はoncontextmenuの無効化ですね。onselectstartはテキストのコピペ対策に使われることが多いようだが、画像にも併用されるようである。


このあたりはよく聞く対策なのだが、スタイルシートで pointer-events: none; というのが設定されていた。

これはポインタセットの対象としないというスタイルらしい。

通常はautoに設定されていて、要素に応じて適切に振る舞う。

どうも調べると、SVGで塗りつぶし部分は選択対象に含むか含まないかとか、そういう設定に使うことが予定されているスタイルらしい。

pointer-events (MDN Web Docs)


あとこのサイトでは使われてなかったけど、よくある対策として透明な画像を重ねるというものがあるらしい。

CSSで透明な画像を背景とした要素を前面に置くとかそんな形らしい。

このあたりから必要なものを選択して使っているのが実情らしい。


また、直リンク対策として、画像ファイルへのアクセス時のrefferを確認するというのがあり、

ソースコード見ればimg要素が丸見えだって言っても、そのURLに直接飛んでも保存できないようになっていた。

これはアクセス時のrefferをそのサイトのURLにすればよいのだが、

しかし、そのような操作ができない場合は確かに保存できない。


いろいろな対策はあるが、障害となるものを取り除き続ければ、結局は保存できてしまうものである。

特にこのサイトはimg要素へのイベント設定・スタイル設定が全てなので、

全要素のイベント設定・スタイル設定を無害なものに変更するJavascriptを作って、ブラウザで実行すれば普通に保存できてしまう。

そういうブックマークレットはそこら辺に転がってるので調べればいくらでも。


あと、開発者ツールはWebページがアクセスしたデータを確認する機能があり、

この機能を使えばJavascriptで動的に開かれた画像としても確認出来る。

今回の場合は画像の読み込みはimg要素でシンプルに実現されているが、

当然その場合もF12で開発者ツールを開き、アクセスしたデータを見れば当該画像データはある。

そこから保存してしまえば当然保存はできる。

一般の人は開発者ツールなんて使わないのが前提であろうけど。

(直リンク対策でrefferを確認する対策もそうだが、一般の人には回避困難な対策であろう)


おそらく一般の人にとってもっとも突破しやすい方法はスクリーンショットである。

スクリーンショットをWebページから回避・検出する方法はほとんどない。

考えようによっては最強の回避手段である。

どれだけ困難化してもスクリーンショットで保存されてしまうなら、

あまり手の込んだ画像保存対策を行う意味はないかもしれない。


どれだけ複雑でもブラウザはHTMLを解析・表示することと、CSSを当てはめること、Javascriptを実行することしかできない。

Javascriptは複雑な操作を行うことができるが、しかしどのような操作をしてるかはソースコードから判明する。

Instagramの画像はそれこそもっと複雑な保存回避が行われているが、

しかしInstagramのURLを投げれば、そこから画像のURLを抽出するサービスは世の中にたくさんある。

どれだけ複雑でも手間さえ掛ければ回避でき、Instagramは利用者が多いからそのような手間を掛けたとしても報われてしまうという、そういうことですね。

そもそもInstagramだってスクリーンショットを撮れば何も複雑なことは考えなくてよいのである。

この時点でどうしょうもない話じゃないかなと思う。


以前、集英社の電子書籍アプリでスクリーンショットをPC・Androidでは禁止、iOSでは検出して警告・アカウント停止を行っているという話を紹介した。

iOSではスクリーンショットできるんですか

iOSでは禁止ではなく警告→アカウント停止という対策になるとか、

PCの外側(HDCP非対応デバイス)やAndroidエミュレータBlueStacksで外側からキャプチャするという方法で回避できてしまうということを紹介した。

しかし、iOSでの警告も十分に効果的であり、回避手段はかなり特殊な方法である。

このぐらいの対策がなされていれば、それは実質困難といってよいでしょう。


しかし、このような回避手段が適用できる前提としては、閲覧にあたって専用のアプリをインストールする必要があり、Webサイトより作成者も閲覧者も手間がかかる。

それだけの手間をかける価値があるかは考えないといけない。

集英社のこのアプリは期間限定のコンテンツがあり、それは自社アプリでの閲覧に限っているので、これだけの手間をかけさせてもよいと考えているのだろう。

集英社という出版業界のガリバーだからこそとれる手段ということで。


それに比べればブラウザの画像保存対策はずいぶんいい加減なものである。

ここまで見てもわかるけど、技術的にはしょうもないものだらけである。

そういう中途半端な対策ならやらない方がよいという考えもあると思う。

しかしやはり時々は見ますね。なんやかんややってしまうんでしょうんね。

作成者も保存を完全回避できるとは思っていないとは思いますけどね。

Webサイトで容易に閲覧できるものは、保存できないわけがない。それに尽きるでしょう。