目次
2019-07-14 パスワードの管理方法（令和元年版）
2019-07-12 いきてますよ
2019-06-19 飲み会二つ
2019-06-14 google photos その後
2019-06-12 Google drive バックアップと同期
2019-06-09 新マシンセットアップ中
2019-06-08 新マシン到着
今月の日記
５年も前に書いた記事に、ご意見をいただいた。
記事の間違いを指摘してくれたものだ。
以前からたびたび書いているが、僕は自分の知識が正しいとは思っていない。
５年も前の記事なら状況も変わっているだろうからなおさらで、こうした指摘はありがたい。
しかし、今回に関してはどうもご指摘がおかしいように思えた。
最新の情報では変わっていたりするかも…と念のため調べたが、今でも僕の書いた記事は有効なようだ。
どうも、ご指摘が勘違いからくる誤りのようだが、一人ご指摘をくれたということは、それ以上に多くの人が同じような勘違いをしているように思う。
そのため、過去の記事の内容を解説し、指摘がどう誤っているのかを記しておく。
まず、過去記事の概要。
パスワードは紙に書いてはダメで、すべて記憶するのが正しい、と思っている人が多いことに対して、その間違いを指摘した記事だ。
（これも5年前の話なので、今でもこう思っている人は減っている、と思いたい）
パスワード管理する上で、重要なのは
・サイトごとにすべて変更する。
・ほぼランダムに見える文字列を使う。
・時間的にも時々変更する。
の３点で、これらの決まりを守ろうとすると、パスワードを記憶する、というのは難しくなる。
そのため、20世紀には、「パスワードは紙に書かず、記憶するのが正しい」とされた時代はあるが、現代においては紙に書くのは悪い手段ではない、と解説したものだった。
これに対して、いただいた意見は「時間的な変更」をやってはならない、とするものだった。
時間的に変更することを促すと、パスワード管理が雑になり、セキュリティが弱くなる、という指摘だった。
この指摘は、2017 年に NIST （米国国立標準技術研究所）が勧告したパスワード管理方法を踏まえたものだろう。
僕の記事は 2014 年に書かれたもので、情報が古くなり意味を失った、と捉えることもできる。
NIST は、米国政府関連で求められる認証方法について、時代に合わせて適切なセキュリティ強度を保つための勧告をまとめている。
2017 年の報告では、パスワードを設定する際のユーザーインターフェイスなどについてもまとめている。
ここには「パスワードの変更を強要すべきではない」という趣旨が書かれている。
これを受けて、国内でも総務省が「安全なパスワード管理」という呼びかけページを作成した。
ここに、パスワードの「定期的な変更は不要」と書かれている。
これがちょっと問題ありで、見出しに大きな文字で「定期的な変更は不要」と書かれてしまった。
内容を読むと、変更が不要なのではなく、「パスワードの定期的な変更を要求すべきではない」と書かれている。
この内容自体、 NIST の勧告に基づくものだ、と書かれていて、趣旨も同じだ。
あくまでも「変更の要求」に問題があるとするものだ。
しかし、見出しに「定期的な変更は不要」と書いてしまったために、多くの人が勘違いしてしまった。
新聞報道などでも「パスワードは変更しない方が良い」として広まってしまった。
NIST の勧告はセキュリティのためだけではなく、ユーザーの利便性を考えて「システムによる行き過ぎた規制」を緩和しようとしているものだ。
パスワード変更を強要すべきではない、という文脈には、「異なる文字種の混合を要求したりしてはならない」というものも入っている。
異なる文字種…数字、大文字、小文字、などだ。
この３つを、それぞれ少なくとも１つ以上は使うように求めるシステムは結構多い。
それらを混ぜることで、セキュリティが高まると期待しているのだ。
しかし、NIST はこれを禁じている。
ここにあるのは「ユーザーに不便を強いるな」という意図であり、セキュリティ強度とは無関係の話だ。
（一応、文字を混ぜても期待するほどセキュリティ強度は上がらない、という解説が巻末についているけど）
以上のように、NIST 勧告の「時間的な変更をやってはならない」は、システムに組み込むべきではないという指針だ。
それに対し、僕が過去記事に書いたのは、各ユーザーが自発的にとるべき、パスワード管理の心得を書いたものだ。
これらは全く性質の異なるものだ。
しかし、今回いただいたご指摘は、これを混同したものだった。
異なるものを混同し、「パスワードを変更してはならない」と考えていると、セキュリティ上のリスクを生じてしまう。
なぜ時間的な変化が必要かを示そう。
単純な話、パスワードはいつか破られる。
もちろん、攻撃側にその気があれば、の話だけど。
攻撃者がパスワードを知る方法なんて、いくらでもある。
たとえば、パスワードハッシュファイルの入手。
詳細は５年前の記事を参照してほしいが、攻撃者がパスワードハッシュを入手した場合、比較的「覚えやすい」パスワードなら、解明されてしまうだろう。
覚えにくい…ランダム文字列は、解明を遅らせることができる。
だから、「ほぼランダムに見える文字列を使う」という指針が入ってくる。
その一方で、キーロガーと呼ばれるような手段を使い、あなたが入力するパスワードを「直接」記録する方法もある。
この方法で奪われた場合は、キー入力がそのまま漏れてしまうため、文字列がランダムに見えるかどうかは関係ない。
あとは、パスワードが「漏れた」前提の話となる。
被害を最小限に食い止めるためには、そのパスワードが使える場所を限定しておくことだ。
「サイトごとにすべて変更する」というのは、そのための指針となる。
では、最悪の状況、実際に被害が出たとしよう。
問題は、それがどのような被害だったか、ということだ。
「勝手に買い物」された場合は、身に覚えのない請求が届くので気づくだろう。
しかし、メールなどを覗き見られて生活を丸裸にされている場合には、パスワードが漏れたと気づくだろうか？
時間的に変化させる、というのは、こうした気づかない被害に対する防御策だ。
大規模なパスワード流出があった、というような状況では、世間的にもパスワードの変更が呼び掛けられる。
パスワードが「漏れたかもしれない」と思えば、変更しておくのが良いだろう。
が、ストーカー被害の場合は身近な人によるショルダーハッキング…あなたが会社の PC などを操作しているときに、後ろからパスワードを覗き見ただけ、などの可能性がある。
キーロガーすら使わない。パスワードは、漏れるときは本当に簡単に漏れる。
そうした状況では、自分のパスワードが漏洩した、と気づくのは難しい。
NIST では、「第三者のログインに気づくようなシステム」を構築することも推奨している。
そうしたシステムなら、パスワードが漏洩し、情報を覗き見られていることにも気づくかもしれない。
しかし、残念ながらそうではない WEB サービスが多い。
ここでの自衛策は、時々パスワードを変えることだ。
普段から時々パスワードを変える、という習慣を持っていれば、パスワードが第三者に知られたとしても、被害をある程度の範囲で食い止めることができる。
「時間的にも時々変更する」というのは、そのための指針だ。
ただ、ここでいう「変更すべき」なのは、ユーザー各自の裁量に任されていることに気を付けてほしい。
先に書いた通り、NIST は「変更を強制すべきではない」とするだけで、この件についてあまり触れていない。
しかし、「強制的にパスワード変更を促す」システムは弊害しかない、というのはセキュリティ専門家の多くの意見が一致するところだ。
定期的に変更すべき、と言われて自主的に変更するユーザーは、セキュリティ意識が高い。
当然、変更の際にも妥当なパスワードを設定するだろう。
しかし、特にセキュリティ意識がなく、パスワードを「面倒だけど設定しないといけないもの」程度にしか思っていない人の場合、頻繁に変更を繰り返すと、覚えやすい単純なパスワードに収束していく傾向がみられる。
変更しろ、と言われたから、最初は 1234 に。次は abcd に…という具合に。
最初の設定ではそれなりに強度のあるパスワードを使っていたとしても、より弱いものに変えさせる「強制」は、百害あって一利なしだ。
（ちなみに、NIST の勧告では、abcd や 1234 といった「連続文字」パスワードは設定できないようにしなくてはならない、と示されている。
これらは、ユーザーの利便性を最大限に考慮したうえでも、設定されるべきではないパスワードだ）
過去の記事に指摘をくださった方が「時間的な変更を促すと、パスワード管理が雑になる」と言っているのは、このことだろう。
同じ「時間的な変更」であっても、システムが強制するのと、ユーザーの自発性に任せるのとでは意味が違う。
この二つを混同してはならない。
強制はしてはならないが、時間的な変更はされるのが望ましいのだ。
話はこれで終わりだ。
NIST 勧告の「変更を強制すべきではない」はずいぶんと勘違いされていて、パスワードを変更してはならないのだと思っている人が増えているようだ。
強制すると雑になるから、というのは、ご指摘の通りだと思っていい。
多くの専門家がそう指摘している。
また、NIST 勧告では書かれていないものの、「わざわざ書かないだけ」で、前提にしている気がする。
一方、今回指摘を受けてネットを調査していたら、「パスワード変更の際に、変更しようとしているパスワードがネットワークを流れることになるから危険」と言う主張も見た。
変更自体が危険なのだと思っている人は、こうした話を「裏付け」として信じてしまうかもしれない。
しかし、たいていパスワードは暗号化通信（SSL）を使って通信されるから、覗き見られることはない。
「暗号化も破られるかもしれない」という前提に立つのであれば、ログインするたびに通信されるパスワードのほうが、変更のために１度だけ入れられるパスワードよりも、ずっと危険性が高い。
この危険度を下げるためには、同じパスワードでログインされる回数を減らせばよい。
つまり、時々パスワードを変更すべきだ。
結局、「変更の危険性」を主張しようとして変な前提を持ち出しても、むしろ変更すべきだという話になる。
さて、以下は余談。
わずか2週間前に、セブンイレブンが新しい電子マネーである「7pay」を導入しようとして、大失敗をやらかして、炎上した。
最大の大失敗は、システム側でのパスワード認証が「ざる」だったことだ。
本人の生年月日を答えられれば、任意のメールアドレスに対してパスワードの再発行を要求できる、というシステムがあり、生年月日を設定していない場合の日付初期値が固定だった。
このため、アカウントの ID さえ割り出せれば、高確率でパスワードを奪い取ることができた。
そして、ID は特に秘密ではない情報だった。
記者会見に応じた 7pay 社（セブンイレブンの子会社として電子マネーの会社が作られた）の社長は、報道記者から「なぜ二段階認証を使っていないのか」と質問され、「二段階認証って何ですか？」と基礎知識がないことを衆目にさらした。
パスワード管理の話としてはどこから突っ込んだらよいのかわからないところだが、二段階認証の説明をしたい。
すでに使っている人は多そうだが、これが何を目的としているのかちゃんと認識している人は案外少ないように思う。
二段階認証は、「パスワードは第三者が簡単に盗めるものだ」という前提に立っている。
簡単に盗めるから、 ID とパスワードの組を知っているから本人、とは単純に認証できない。
一方で、現代では、多くの人が携帯電話を持っている。
そして、携帯電話には電話番号がある。この電話番号は、本人と強く結びついたものだ。
そこで、アカウントに対してあらかじめ「連絡手段」としての携帯電話番号を登録しておく。
連絡手段があればよいので、固定電話やメールアドレスが使われる場合もある。
ID とパスワードの組での認証に成功した際、これは「第一段階」を突破しただけで、ログインにはならない。
ここで、「二段階目」として、サーバーから連絡手段を通じて何らかの情報（通常は６桁程度の数字）が伝えられる。
携帯電話番号に対してショートメッセージを送信、というように、この情報は「本人だけが受け取れる」ことが期待される。
そして、受け取った本人が情報をサーバーに伝え、正しい場合にやっとログインが完了する。
この方法は、
・本人にだけ伝えられる情報を利用するため、正しく本人であると確かめられる。
・万が一パスワードが盗まれた場合、本人に通知が行くため、パスワードが盗まれたことを知ることができる。
という2つのメリットがある。
特に後者は重要だ。
先に書いたが、パスワードが漏れて明らかな被害にあえば、パスワードを再設定するなどの対策がとれる。
しかし、通常は「ただログインされて情報を見られただけ」では気づかない。
二段階認証では、認証中に本人に通知を行うことで、第三者によるパスワード盗用が明らかになる。
これにより「見えない被害」を事前に「見る」ことが可能となるだろう。
ただし、大体のシステムにおいて、二段階認証は「オプション」扱いにすぎない。
携帯電話などを持っておらず「設定のしようがない」ユーザーもいるためだ。
そして、オプションを使わなければ、従来どおり、 ID・パスワードの組だけで認証が行われる。
認証自体は問題なく行われるため、二段階認証を使えるシステムであっても、これが何のためにあるのか理解できずに設定していない、という人は多い。
Google や Amzon, Facebook 、Apple、Twitter …etc,etc. 多くの有名サイトが二段階認証に対応している。
認証していないシステムでも、「Google アカウントでログイン」などが使える場合は、Google の二段階認証を「借りる」ことができる。
設定していない人は導入を検討してみてほしい。
しかし、実はこの方法での二段階認証は、強度的に十分ではないことがすでに分かっている。
携帯電話の電話番号というのは、携帯電話デバイスに固有のものではない。
購入してから、後付けで電話番号を「紐づけた」ものだ。
紐づけられるということは、別の人が別の携帯電話に対して、同じ番号を紐づけることも可能となる。
そして、携帯電話の通信網というのは歴史が古く、設計時には十分だと思われていたセキュリティがすでに破られていたりする。
つまりは、電話番号に対して送られたショートメッセージは、第三者によって「奪われる」ことがあるのだ。
奪われれば、本人にしか通知されないはずの情報は第三者にわたり、本人に通知されるはずの「第三者によるログインの可能性」通知も届かなくなる。
（注：海外と国内では通信方式も多少違い、破られているのは海外での話。とはいえ、類似方式で脆弱性が見つかっているのだから、国内でも過信は禁物）
メールアドレスに対する通知でも同じことがいえる。
固定電話は…本当の意味での「固定電話」なら、電話線に対して電話番号が割り振られている。
変更するには電話局内での設定が必要で、通信を盗むことは難しい。
しかし、今は「固定電話」といっても IP 電話であることが多く、これは後から機器に電話番号を割り振っている。
やはり過信は禁物だろう。
サーバーから本人に対して、「安全な通信経路が確保できる」というのが、この方式での二段階認証の前提だ。
安全な通信経路が確保できない場合、安全ではなくなる。
では、通信を行わないで、認証する瞬間にだけ使用可能な、本人だけが知れる情報で、サーバーに侵入されても情報が漏洩しない方法で、サーバーと秘密を共有すればいい。
そんなことできるの？ と思われるかもしれないが、ちゃんとそうした方法は考案されていて、一部の二段階認証では選択できるようになっている。
ワンタイムパスワード、と呼ばれるもので、仕組み自体は結構古い。
2006年…いまから13年も前には、すでにジャパンネット銀行が導入している。
先に「パスワードは時間によって変更したほうが良い」と示したが、それを究極まで突き詰めたものだ。
30～90秒で、自動的にパスワードが変更されてしまう。これなら、万が一パスワードが盗まれても問題ない。
パスワードが変わってしまうと、本人すらログインできなくなりそうだ。
しかし、本人だけが持っているデバイスに、変更されたパスワードが示され続ける。
だから、本人だけはログイン可能だ。
ここで重要なのが、パスワードを示すのに通信などは不要だ、という点だ。
サーバーとデバイスは、お互いに示し合わせることなく、次々とパスワードを変えていく。
しかし、それらは時刻を基にした一定の計算方法で示されるもので、デバイスとサーバーで一致している。
計算で示される…ということはランダムではないのだが、たとえ計算方法を知っていたとしても、「鍵」がなくては同じ計算が行えない。
そしてここが一番肝心なのだけど、計算のための「鍵」は、デバイスの中にしかない。サーバーにもない。
だから、万が一サーバーに侵入され、情報を盗まれてもパスワードを知ることはできない。
この鍵は、公開鍵暗号を応用したものだ。
公開鍵暗号は、「公開鍵」と「秘密鍵」のセットを使い、秘密鍵で暗号化した内容は公開鍵でしか元に戻せない。
だから、デバイスが秘密鍵を持ち、サーバーに公開鍵を預けておくと、デバイスが作り出した暗号が「確かに正しい」ことをサーバーは確認できる。
公開鍵は、秘密鍵を基にして計算で求めることができる。
しかし、公開鍵を基にして秘密鍵を割り出すことは事実上できない。
だから、サーバーに預けた公開鍵を盗まれたとしても、それを基に秘密鍵を求めてワンタイムパスワードを生成する、ということができない。
13年も前に導入されたジャパンネット銀行では、6桁の数値を表示できる専用デバイスを配布してワンタイムパスワードを実現している。
しかし、今は多くの人がスマホを持っているため、スマホ上で同じ仕組みを作り上げたアプリも多数配布されている。
専用デバイスよりは気軽に導入できる。
ただし、専用デバイスの場合、パスワードを盗むことはできないうえ、デバイス自体を盗むと本人に気づかれる、という利点がある。
アプリの場合、スマホ内に格納された「秘密鍵」をコピーすることが可能であれば、同じパスワードを生成できるようになり、本人にも気づかれない。
そのため、アプリはセキュリティ強度が落ちることは知っておいた方が良い。
特に、スマホの買い替え時に「秘密鍵を新しいスマホにコピーできる」機能がある場合、便利だがセキュリティ強度は明らかに落ちる。
第三者に「コピーする」機能を使われれば、本人以外のログインが可能になってしまうためだ。
SMS を使った認証と異なり、本人に通知が行かず、不正ログインに気づくこともできないので、デメリットも大きくなってくる。
こうしたアプリによるワンタイムパスワード生成などで、ワンタイムパスワード導入のコストは下がっている。
どこのサイトでも導入できる状況は整ってきているけど、対応にはそれなりの手間が必要なため、対応していないサイトも多い。
これからは徐々に増えていくだろう。
しかし、現在のところ、こうした「安全な本人確認方法」に対応していないサイトは、まだまだ多い。
その点では、5年前の記事のパスワード管理方法は、依然として有効だ。
パスワードなんて不便なもの、早く不要になってくれればいいのだけど。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先月１９日からだから、３週間ほど日記を書いてなかった。
その前に少し書いていたが、取引先を変えて仕事内容が大きく変わった。
それで忙しくて日記を書いてなかった。
より正確に言えば、「忙しくしていたので特に日記に書きたい面白いネタがなかった」だな。
忙しくても、ネタさえあれば日記を書く暇くらいは捻出する。
これだけだとあまりにも寂しいので、新しくやっている仕事について少し書いておこう。
具体的に何をやっているかは書かない。
別に企業秘密とか守秘義務とかではなくて、「宣伝になるから書いていいよ」と言われているのだけど、なんとなくまだ書く段階にないように思うから。
で、大きく分けて３つの仕事を同時にこなしている。
・WEB ブラウザで動作する、HTML + Javascript クライアントプログラム。素の Javascript だ。
WEB socket で得たリアルタイムデータを SVG でグラフィカルに表示し、同時に WEB Audio で音を出す。
作っていてなかなか楽しい。
・WEB ブラウザで連携動作する、Javascript + Vue.js クライアントプログラム。
まぁ、Vue を使おうが使うまいが、究極的には HTML + Javascript ではある。
しかし、複数ファイルに分けて書いたものをコンパイル・統合して配布ファイルを作る、というような、環境的には全く素の Javascript とは異なるものだ。
上に書いたプログラムとは完全別物だが、同じ大きなシステムの中の一部。
実は前任者が途中まで作り上げたプログラムを引き継いだので、まだ完全把握に至っていない。
しかし、Vue はなかなか興味深いプログラムスタイルだ。自分が一から作っていたら使わなかったと思うが、良い経験をさせてもらっている。
・上に書いた Vue プログラムは、もともとは PHP で書かれていたサーバープログラムを「移植」したもの。
PHP で複数ページにわたっていたプログラムを、Vue.js によって一つにまとめ、ページ遷移をすべてブラウザ側レンダリングで解決するようにしている。
となると、当然 DB とやり取りする部分をサーバー側に作り込む必要があるが、このプログラムは node.js で作成されている。
この部分も、Vue のプログラムを作っていた人が途中まで作っていたのを引き継いだ形。
以前仕事で node.js を使ったことはあって、その時の感想は「仕事で node.js を使うのはリスクが大きい」だった。
その頃は node.js はまだ新しいもので、環境が十分に整っていなかった。
本体やライブラリのバージョンアップのたびに、致命的な非互換が生じていた。
しかし、近頃の node.js は、当時と比べるとずっと安定しているようだ。
というわけで、３つの仕事ではあるが、全部 Javascript。
しかし、使ったことがある人ならわかると思うが、素の Javascript と、Vue などを使った Javascript と、node.js を使った Javascript は、環境的にかなり違う。
中途半端に Javascript という同じ部分を共有しているため、妙に混乱する。
（node.js の Javascript いじったのに、ブラウザリロードするだけで「動かない」と悩んでしまったり。
node.js はサーバーサイドなので、デーモンの再起動が必要）
まぁ、そんな感じのことやってます。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
自宅で仕事していると、会社帰りに同僚と飲むようなこともなく、外で飲む機会がほとんどない。
しかし、飲み会に誘われた。別々の個所から、２日連続で。
月曜日は、セガ時代の元同期が、僕を含めて３人集まった。
それに加えてもう一人年上の方がいたのだけど、その方のお勧めでお洒落なカフェレストランへ。
ワインリストとか出され、リエットとか岩牡蠣だとか、高級感あふれる食事。
こういうお洒落な店は慣れていないので、食事やワインなどお店を紹介してくれた方にお任せした。
とてもおいしかった。
火曜日は、先月まで仕事でご一緒していた方たちに誘われた。
ネットでつながり、ネットで仕事の連絡をしているため、５年も働いていたのにお会いしたことは数度しかない。
同じような立場で働いている人など、仕事上では密接にやり取りしていたりしたのに、初めてお会いした。
やきとん…豚の串焼きを中心とした居酒屋さん。
くだけた雰囲気で前日とは全然違うタイプのお店だが、これもまたおいしい。
直接担当してくださっていた方が、プログラマーではないのだけど、実は古いコンピューターが好きで CPU の命令セットなどもそれなりに詳しい、というのがちょっとした驚きだった。
（プログラマーではないので、個別 CPU の話に詳しいわけではないのだけど、CISC と RISC の違いとか、最近の CPU は複雑化しすぎて、投機的実行が元で脆弱性が生まれたりする、とか、結構突っ込んだ話が分かる人だった）
仕事での付き合い長かったのだから、もっと趣味の話をしていたら楽しかったかもしれない。
普段兼業主夫を標榜しているので、夕方出かけることはあまりない。
夕食作らないといけないし、皿洗わないといけないし。
なによりも、東京近郊まで出ると家から１時間半程度はかかってしまうんだよね。
往復３時間で、飲んでいる時間も３時間程度。
しかし、それがゆえにあまり出かけていなかったのが、久しぶりに出かけたらやっぱり楽しかったと、そういう話です。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
２日前に「Google Photos にバックアップする方法、ノートパソコンだとつらいなー」ってことを書いた。
で、その後調査していて、普通に Linux で動く Google Photos アップローダーを発見した。
なんでも、2018年5月…およそ一年前に Google Photos の API が公開されて、サードパーティ製のソフトも作れるようになったようだ。
で、使ってみたのだけど、満足するものではなかった。
画像を圧縮しないで、元画像のまま送り込むソフトだったのね。
他にも、EXIF がついてない画像…つけようがない動画なんかも、撮影日がアップロード日付になってしまうそうだ。
圧縮はソフトの問題かもしれない。
一応、ある程度送り込んだところで、Google Photos 側で「圧縮」処理してもらい、Google Drive 容量を開ける、ということもできる。
でも、日付は API に指定方法がないためどうしようもない、とのこと。
類似ソフトはほかにも発表されているようなのだけど、API がないのであれば他のソフトでも同じ問題は出るのだろう。
そんなわけで、やっぱり本命は Windows の仮想化か。
１つのソフトのために仮想マシンを用意して Windows インストールするとか、なんか間違っている気がするので、ほかの解決方法があるとありがたいのだけど。
余談。
いつものことだけど、余談のほうが長い。
冒頭にあげたアップロードツール、コマンドラインで動くのだけど、普通は GUIというか、X Window 必須です。
というのも、Google の認証が必要で、その部分は WEB ブラウザでないとできないから。
WEB ブラウザは、普通に考えると GUI がないと動かない。
流れとしては、
1) アップロードツール起動
2) 初回のみ、Google の認証が必要。URL が表示され、ブラウザでアクセスするように指示される。
3) ブラウザでアクセスし、Google の認証を通すと、その結果をツールが受け取って動作できる。
という仕組み。
一度認証を通せば、その認証情報はツールが保持するので以降は認証する必要はない。
僕は家庭内サーバーを完全 CUI で使っていて、Windows 上の Putty …端末ソフトで扱っている。
そこで、まず w3m をインストールしてみた。
文字だけで動作する WEB ブラウザだ。とにかく WEB ブラウザが動けば大丈夫そうだから。
ここで、実は操作を誤った。
文字だけになったら普段見ている画面と違うので、勘違いして別のリンクを押したのだ。
そうしたら reCAPTCHA 入力画面になった。
画像の中にゆがんだ文字が書かれていて、入力を求められるやつだな。
…テキストブラウザでは、画像が見えない。
どうしよう、と考えて、cacaview というソフトの存在を知る。
テキスト端末でもアスキーアートとして画像を表示してくれるソフトで、reCAPCHA の文字が読める程度には再現性もよい。
w3m はテキストブラウザとは言え、画像部分は外部ソフトに渡してみられるようになっている。
X Windows 環境で画像だけ別ソフトで開くことを想定しているのだけど、cacaview で開いたってもちろん構わない。
cacaview は CentOS なら caca-utils というパッケージを入れれば入る。
…で、さんざん苦労して認証を通して（やっぱ reCAPCHA 文字は読みにくく、何度も間違えた）、そのあとで「あ、これ違う画面だ」と気づいた。
本当に進みたかったルートではない。
本来進みたいルートに進んだら、あっさりと「Javascript が動かないので別のブラウザでお試しください」という画面になった。
w3m は Javascript が動かない。ダメだ。
しばらく考えて、サーバーに入っている nginx を使うことにした。
GooglePhotos のアップロードツールでは、localhost に対してアクセスを求められる。
そこで、nginx で適当な名前でサーバー公開して（もちろん家庭内だけ）、バックプロクシとして動作させて localhost にアクセスすればよい。
これで認証は通った。
最後に、GooglePhotos のアップロードツールに情報を渡すため、もう一度 localhost にリダイレクトされるのだけど、この部分で「localhost」ってことで、Windows にアクセスが行ってしまう。
まぁ、URL はわかったので、w3m でアクセスする。
これで認証が通った。
先に書いた通り、GooglePhotos アップロードツールは僕の求めていたものではなかったのだけど、この手順を踏めば、一切 X Window 環境なしに使える、本当のコマンドラインツールになる。
必要な人はお試しあれ。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
新マシンに移行した。
旧マシンはしばらく使わないつもりで置いておく。
引き揚げ忘れたデータとかが眠っているかもしれないから。
でも、たぶん引き揚げ忘れたデータが本当にあったとしたら、それは忘れる程度のデータなので消えても構わないと思う。
実は、半年ほど前に旧マシンに Windows を再インストールしており、その際に「移行しやすいように」データ整理をしていたので、移行はスムーズにいった。
でも、若干の予想外もあった。
我が家では NAS に家族の写真・ビデオをたっぷりとため込んであって、この NAS は重要なので外付けハードディスクに定期バックアップもとっている。
しかし、それとは別に Google Photos にも写真を送ってバックアップしている。
「画質が落とされるのでバックアップにはならない」という人もいるのだけど、上に書いたように十分なバックアップは取った上の話だ。
Google のものは、万が一火事などで機材一切が滅失した際に、思い出写真として見られるのに十分なものがあればよい、という程度と考えている。
で、問題はこの Google に対するバックアップだ。
Google Drive を扱うツールは NAS のプラグインや Linux にもあるのだけど、Google Photos で「無制限」に写真を送るためのツールは Win / Mac 版しか用意されていない。
ここらへんで説明が必要な人も多いだろう。
Google Drive と Google Photos は、シームレスにつながるサービスだ。
Google Drive はネットワーク越しにデータを預かってくれるサービスで、Google Photos は写真を預かってくれるサービス。
でも、Photos の保存領域は、実は Drive のものだ。
ただし、Photos では「十分に小さな写真」は、Drive の容量として計上しないことになっている。
だから、今く使えば容量無制限で写真をバックアップできる。
ここで「十分に小さな」というのは、過去に何度か改定されてきている。
最初は、2048x2048画素以内、とされていた。実際にはバグがあって、ぎりぎりサイズはダメだったのだけど。
Google は、当時は Google Picasa というソフトを Windows 用に配布していて、このソフトからアップロードすると、自動的に 1600px まで縮小してアップロードしてくれた。
（当時は、Google Photos ではなく Picasa Web という名前だった）
のちに、Picasa は開発終了し、写真のバックアップだけを行う Google Photo Uploader が作られた。
そしてさらに、Google Drive バックアップと同期、というソフトに変わった。
同時に、保存できるサイズも大きくなってきている。
現在は「1600万画素、かつ 75MByte」までとなっている。4000x4000 なら、ちょうど 16000万画素なのでそのままアップロードできる。（75MByte の制限はあるのだけど）
ただ、この制限に適合するようにアップロードしてくれるソフト、「バックアップと同期」が、Windows / Mac 版しか作られていないのだ。
今までは、Windows 版のソフトを動かし、NAS をバックアップ元に指定して Google にアップロードさせていた。
今回もそれをやったら…これ、ノートにさせるような作業じゃないね？
今まではデスクトップマシンでイーサネット接続だったので、NAS から写真を取得して、リサイズして再圧縮して Google に送信、というタスクを動かしていても気にならなかった。
でも、WiFi 接続だとイーサより遅いし、WiFi の電波帯域は家族で共有しているので迷惑になりそう。
いや、イーサだって共有なのだけど、WiFi を使う機材とイーサを使う機材で棲み分けていた、という感じ。
（その WiFi はイーサにつながっているのだけど、一番通信量の大きい、僕のマシンと NAS の間、というのと、WiFi ステーションとネットワークルータの間、というのは、スイッチングハブによって切り分けられている）
ひとまず、ノートマシンにイーサケーブルつないで凌いでいるのだけど、どうにかしたい。
Linux サーバーはあるので、Linux から Google Photos にアップロードできればいいのだけど…と調べたのだけど、相変わらずそのためのソフトはない。
じゃぁ、Windows を仮想化してサーバーに入れるか。
幸い、メインマシンの Windows はライセンスを購入したもので、PC 付属の OEM ではない。
＃PC 付属の OEM 版は、別のマシンで使用することは禁じられている。
今まで使っていたメインマシンは、もともと Windows 7 マシンだったのだけど、8 にバージョンアップする際にライセンスを購入し、このライセンスは Windows 10 に無償バージョンアップされた。
Windows には「Hyper-v」という仮想化技術があるのだけど、これは実は Xen が開発したもの。
Xen は Linux で生まれた仮想化技術で、現在は KVM に引き継がれている、と考えて間違いない。
＃Xen 自体はまだあるのだけど、今から使うメリットはあまりない。
うちのサーバーは KVM が入れてあるので、この上に Windows を入れることは可能だ。
実は、Google Drive 同期とバックアップは、外部の NAS のデータを送信する際は、Windows がスリープして NAS との通信が切断するたびに一時停止する、という問題がある。
まぁ、問題というか仕様なのだけど、仮想化サーバーに入れておけばこの問題も解決する。
というわけで、Windows 仮想化が本命だなーと思いつつ、じつはまだサーバーの整備が終わっていないし、旧マシンもしばらく置いておきたいのでライセンスの関係もあってすぐには仮想化できない。
サーバー整備は、去年から少しづつやっているもの。
Xen サーバーの仮想マシンを KVM に移行したいのだけど、この意向を簡単に行うソフトが曲者で、一筋縄ではいかないとわかってきたところ。
「単純だけど本格運用には不満がある」仮想化マシンなら簡単に移行させてくれるのだけど、本格運用を目指した設定のマシンだと移行できないという…
まぁ、本格運用を目指した、というのは標準的でない設定をたくさん使っているという意味であり、仕方がないことでもあるのだけど。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
新マシン…HP Pavilion 15-cs0000 が届き、セットアップ中。
なかなか人気マシンのようだし、まだ「使い勝手」が書けるほど使い込んでもいないのだけど、セットアップ時点で気づいた点を書いておこう。
まず、僕にとっては最悪ともいえる欠点から。
このマシン、タッチパッドに問題がある。
ELAN Clickpad と呼ばれる種別のものらしい。
Windows 10マシンらしく、複数の指を使ったジェスチャにも対応した、それ自体の使い勝手は悪くないものだ。
以前は、タッチパッドの端をなぞるとスクロール、という操作が流行った。
でも、ジェスチャなら2本指で動かせばスクロール。ほかにも指の数や動かす方向で、いろいろな操作が可能。
このジェスチャは Windows 10 標準のものだ。
ただし、ELAN Ckickpad では、細かな設定が一切できない。
不意にズームジェスチャが入ってしまうからいやだとか、タップするとクリック扱いになるのが嫌だとか、普通のタッチパッドではそうした機能を細かく ON / OFF してカスタマイズできるのだが、そういうカスタマイズ性が一切ない。
Windows の設定画面、デバイスから「タッチパッド」を選んでも、設定項目が出てこない。
どうやらここの設定項目はデバイスドライバの責任のようで、使用マシンによって項目が違うらしいのだけど、その設定項目が「感度」以外に何もない。
まぁ、今はセットアップ中なのでタッチパッドを使っているのだけど、常用し始めたら今メインマシンで使っているマウスを奪って新マシンで使う予定。手になじんでいるので。
それまでの辛抱だ、ということで、実は大きな問題ではない。
＃ここから、翌日追記
なんてことだ！
ネットでいろんなところ見ていても、「ELAN は設定できない」みたいな書かれ方がしていたのだけど、プリインストールアプリの中に「ELAN TouchPad Setting」というものがあった。
Windows 標準の設定画面ではなく、このアプリを使うことで細かなセッティングができた。
2本指ジェスチャによるスクロールだけではなく、タッチパッドの端をなぞることによるスクロールにも対応している。
これなら、過去の別のマシンから乗り換えた人でも違和感なく操作できる。
しかし、このソフトでも設定できる「感度」だけは、Windows の設定画面でも設定できるようになっている。
ということは、ほかの設定も同じように「設定」画面で可能にして置き、より細かな設定はソフトで…などもできたはずだ。
非常に分かりにくいが、まぁ気づけば問題ないレベルなので、良しとしておこう。
＃追記ここまで
画面がノングレア処理されていない、というのは思った以上に見づらいものだった。
ノートパソコンなのに、画面がスマホみたいにツルツルなのね。
スマホなら小さいから気にならないのだけど、画面が大きいので自分の顔が映り込んでいるのがよく見える。
これは、あらかじめ気にしていて、公式オプション品のノングレアシートを一緒に買ってあった。
公式だからと言って高いことはなく、同等品をアマゾンなんかで探しても似たような値段。
ならば、画面サイズに適切に合わせて切られている公式品を買った方がよかろう。
そして…そう、このシートは非常によく、画面サイズピッタリに切られている。
画面の端に合わせて綺麗に張ったつもりでも、最後が画面の枠にあたって、シートが浮いてしまうほどにピッタリサイズだ。
多分、0.5mm 程度の誤差しか許されないんじゃないだろうか。
幸いなことに、静電気と空気圧で吸着するようなタイプで、何度でも貼りなおせる。
そこは心配しないでいい。
そして、３回も貼りなおしたらさすがにホコリが入り、シートがピッタリ貼りつかなくなる。
何度でもはがせるので、ホコリの近くをはがし、セロテープでホコリを取ってやれば大丈夫。
苦労したが、最終的には綺麗に貼れた。
このシート、実際には必須だと思うだけど、価格競争のために少しでも安くするためと、生産現場で貼っていると案外手間がかかるのでシートなしで売っているのではないか、と思ってしまうほど。
＃まぁ、最近は画面タッチ可能な機種もあるし、その場合は画面が傷つきやすいので、保護シートを自己責任で貼ってもらう方がよいのだろうとは思う。
キーボード。
感触は悪くない。配置にまだ慣れていないから微妙に打ち間違える、というのは慣れの問題だ。
しかし、キーボード刻印の文字が素晴らしく読みづらい。
キーボードはカッコいいメタリックな仕上げで、バックライト付きだ。
バックライトを点灯すると文字部分が光るやつね。
カッコいいけど、ノートパソコンとして使うには電池を少しでも節約したい、と思ってしまう。
もちろんバックライトは消せるのだけど、消すと先に書いたように読みづらい。
光が透過する部分は、灰色で半透明。半透明ということは、見る状況によって微妙に色が変わるということだ。
ここに、メタリックなキーボード。メタリックということは、見る状況によって微妙に色が変わるということだ。
この、微妙に色が変わる下地に微妙に色が変わる文字、というのが、周囲の明るさによっては致命的に視認性が悪い。
まぁ、キーボード打っているときは手が配列覚えているから、視認性悪くてもそれほど問題ないのだけど。
キーボードついでにもう一つ。
せっかくテンキーがついているのに、num lock のインジケーターランプがない。
なので、数字を入れようとしたカーソルが動いてしまう、なんてこともしばしば。
まぁ、こちらもインジケーターがあったとしても、案外見ていないものなのだけど。
普通は、起動時に num lock を ON / OFF どちらの状態にするかは、BIOS (今時は UEFI か）で設定する。
しかし、Pavilion の BIOS には設定項目がなかった。
（ちなみに、BIOS 起動は昔ながらの F1 や F2 ではなかった。
shift 押しながら Windows を起動して、Windows の起動オプションからトラブルシューティング→詳細オプションを選ぶと、UEFI の設定がある。）
しばらく使っていて分かったが、どうやら「前回使っていた設定」で起動するようだ。
ということは、これは Windows 10 が制御しているのかな？
BIOS を見ていたら、Function キーをどう扱うかの設定もできた。
出荷時設定では、F1～F12 を押そうと思ったら、Fn キーと一緒に押さないといけない。
通常は、音量変更や画面輝度変更キーとして働く。これはまぁ、ノートパソコンなのでそんなものかな、と思っていた。
でも、設定を変更すると、通常は F1～F12 として働き、Fn キー併用で音量変更、のようにできる。
僕としてはこちらの動作が好みなので、設定を変えた。
キーには、音量変更などの絵が大きく書いてあり、F1などの表記は小さめに書いてある。
これが、先に書いたキーの文字が視認しにくい問題と併さり、どれがどのキーかわからない。
基本的には、数字キーの 1 の上にあるのhが F1 、9 の上にあるのが F9 、という認識でよい。
慣れてしまえば何の問題もなさそうだ。
というわけで、細かな文句はあるのだけど、どれも些細な事。
全体的にはよく出ていると思います。色々調べてそう思ったから買ったのだけど。
一応、ここに書いた「些細な事」は、僕が気になって、でもまぁいいか、と思った程度のことなのだけど、人によっては致命的かもしれないので、これから買う人の参考になれば、と思う。
そして、この文章は、新マシンで書いてみた。
セットアップするだけでなく、ちゃんと使ってみた最初の例だ。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
「令和改元記念セール」でＧＷ明けに購入したマシンが、やっと届いた。
５月７日に購入して、６月８日到着。納品まで一か月もかかった。
もっと言えば、６月１０日配達の指定がついていたので、近所の配達店で取り置き状態になっているのに気づき、電話して届けてもらったのだった。
…で、今届いたところで、最初のログインまではできた。
これから環境を整えていかないといけないのだけど、それは時間がある時に少しづつ進めるつもり。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |