blog.鶯梭庵

二〇一八年 弥生 卅一日 土曜日

パスワードについてのあなたの常識はもはや非常識かもしれない・その1 [/links]

日本経済新聞の電子版に「パスワード『頻繁に変更はNG』 総務省が方針転換」という記事が掲載されたことが話題になっている。その記事によると、パスワードは定期的に変更すべしという「従来の"常識"」を総務省が否定したという。

しかし、セキュリティ業界ではとっくの昔に、パスワードを定期的に変更するべきでないというのが「常識」になっている。件の総務省のページでも、2017年に米国国立標準技術研究所(NIST)や日本の内閣サイバーセキュリティセンター(NISC)から、パスワードを定期的に変更すべきでないという旨が示されたと指摘されている。

そもそもパスワードというものは、他人に推測されてはいけない一方で、本人が忘れてもいけない。そのような矛盾する条件を満たすパスワードを考え出すのも覚えておくのも、ユーザーにとって負担が大きい。加えて、1つのパスワードを複数のシステムで使い回すのは極めて危険なので、システムごとに異なるパスワードを使わなければならない。ましてそれを定期的に変更しろなどと言われたら、普通の人は、覚えやすいが他人に推測されやすいパスワードを使うか、パスワードを紙に書く。どちらにせよ、かえって安全性が損なわれる。

もちろん、サーバーが攻撃を受けたりしてパスワードが漏れた可能性がある場合は、速やかにパスワードを変えなければならない。しかし、何もないのに定期的にパスワードの変更を要求することは、害のほうが大きい。推測されにくいが覚えやすいパスワードを1度だけ考えて、それをずっと使うのがよい。

その2に続く。

[この記事だけを読む。] [この記事にコメントを書く。] [最新の記事を読む。]

二〇一七年 霜月 卅日 木曜日

HTTPS 対応 [/links]

www.ousaan.com 以下のベージをリニューアルした。ついでに、このブログを含めサイト全体を HTTPS 化した。

もう何年も前から、すべてのウェブサイトは「常時 SSL 化」すべしと言われている。SSL とはデータを暗号化して通信するプロトコルであり、常時 SSL とは、ウェブサイトの全てを暗号化することだ。実際のところ、SSL には脆弱性が見つかっていて、今では TSL が使われているのだが、それでもウェブの暗号化通信を「SSL」と言うことが多い。

従来は、ユーザーが情報を入力して送信する画面のみ暗号化することが多かったが、ウェブサイトに対する攻撃が巧妙になり、それでは安全が確保できなくなった。Google は、常時 SSL 化を促進するため、常時 SSL 化されていないウェブサイトのランクを下げているし、Chrome で暗号化されていないページにデータを入力しようとすると警告を出すようになった。

かつては、SSL の導入には少なからぬ費用がかかったので、個人のウェブサイトを SSL 化するのは敷居が高かった。しかし、昨年から Let's Encrypt が無料で SSL の提供を始め、SSL 化しない理由がなくなった。

私はウェブサーバーを引越ししたいと考えていて(メールサーバーはすでに FastMail に引っ越した)、そのタイミングで SSL 化しようと思っていたが、引越しのスケジュールが延び延びになっていた。そんな折り、現在使っている Lolipop では数回のクリックだけで Let's Encrypt による SSL 化ができることに気がついて、勢いで設定した。常時 SSL 化のためには、サイト自体の暗号化に加えて、HTTP へのアクセスを HTTPS へリダイレクトする設定が必要だが、これはそれほど難しくない。

しかし、画像の読み込みなどで参照先の URL を変更する必要がある。これはなかなか骨が折れるが、いずれにせよサーバーを引っ越すためにすべてのデータを変換する必要があるので、それに合わせて変更することにする。

[この記事だけを読む。] [この記事にコメントを書く。] [最新の記事を読む。]

二〇一七年 神無月 廿九日 日曜日

ひらがな・カタカナ学習ウェブアプリ [/links]

私の娘はいま3歳なのだが、ひらがながだいぶ読めるようになった。こういうのは、何歳になったら始めるとかではなくて、本人が関心を持ったタイミングで進めるのがよい。私の娘は今が文字を読みたい時期のようなので、このタイミングを逃してなるものかといろいろ試しているなかで、ひらがなとカタカナを学習するためのウェブアプリを作った。

なにを よむ?

まだ五十音の全てをカバーできていないので、今後問題の数を増やすつもりだが、ひとまず人様に見せられる段階になったと思うので、公開する。小さい子供がいる親御さんに活用していただけたらと思う。

[この記事だけを読む。] [この記事にコメントを書く。] [最新の記事を読む。]

二〇一七年 皐月 十八日 木曜日

改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その6 [/links]

その5から続く

まとめ。

まず、ウェブページの一部または全部でコンテンツの幅が固定されている場合(パソコン向けに 800px とか 1024px とか、あるいはモバイル向けに 320px とか)、2通りの指定がある。

幅が固定されているコンテンツが画面にぴったり収まるよう拡大または縮小して表示する場合、meta タグの記述は、例えばコンテンツの幅を 800 ピクセルとしたとき、


<meta name="viewport" content="width=800">


となる。この場合、ウェブページは幅 800 ピクセルの viewport 上にレイアウトされ、画面の幅が 800 ピクセルより広ければ拡大して、画面の幅が狭ければ縮小して表示される。拡大縮小の比率はデバイスに依存するから、HTML では指定しない。すなわち、initial-scale は指定しない。

一方、拡大縮小をせず等倍で表示する場合、次のように指定する。


<meta name="viewport" content="width=device-width,initial-scale=1,shrink-to-fit=no">


ただし、initial-scale=1 がなくてもよい。この場合、画面の幅がコンテンツの幅より広ければ、左右に余白ができる。逆に画面の幅が狭ければ、収まらない部分が画面の右にはみ出る。それをユーザーが見るには、横スクロールする必要がある。

次に、コンテンツの幅を固定せず、画面の幅に合わせて変化させる場合(つまりレスポンシブな場合)、viewport の幅を画面の幅と同じにする。そのための指定は次の通り。


<meta name="viewport" content="width=device-width,initial-scale=1">


この場合でも、initial-scale=1 はなくてもよい。

いずれの場合でも、minimum-scalemaximum-scaleuser-scalable は指定しない。これらの指定はユーザビリティを損ねる。

initial-scale も原則として指定しないが、width=device-width と指定したときに限り、initial-scale=1 をあわせて指定してもよい(initial-scale=1.0 でもよい)。

[この記事だけを読む。] [この記事にコメントを書く。] [最新の記事を読む。]

二〇一七年 皐月 十四日 日曜日

改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その5 [/links]

その4から続く

これまで長々と説明してきたが、まとめの前に、他によく使われる(しかし通常は使うべきでない)指定について見ておきたい。

まず、minimum-scalemaximum-scaleuser-scalable について。これらは、ほとんどすべての場合、ユーザーがウェブページをズームできないようにするために指定する。が、すべてのウェブページはユーザーがズームできるべきだ。したがって、ほとんどすべての場合、これらの指定はするべきでない。

するべきでない指定をする人が多いものだから、Safari はバージョン 10.0 から maximum-scale=1user-scalable=no の指定を無視するようになった。繰り返す。ほとんどすべての場合、minimum-scalemaximum-scaleuser-scalable は指定しない。

比較的最近導入された属性に shrink-to-fit がある。Apple の説明によれば、width=device-width が指定してあるウェブページで、iPad で画面を2分割したときコンテンツが viewport からはみ出した場合に、デフォルトではコンテンツが収まるように viewport が広くなり、縮小して画面に表示されるが、shrink-to-fit=no と指定すれば viewport の幅もスケールも変わらず、viewport からはみ出た部分は画面からもはみ出る。

しかし、width=device-width と指定するならば、viewport の幅がいくつになるかわからないのだから、viewport からはみ出る部分がないようにデザインするべきだ。viewport の幅が狭いときにコンテンツが viewport からはみ出すとしたら、そもそもウェブページの作りが悪い可能性が高い。もし shrink-to-fit=no と指定したくなったら、その前に width=device-width の指定が適切かどうか検討した方がよい。width=device-width と指定したウェブページが適切にデザインされていれば、viewport の幅が狭くなるとコンテンツ領域の幅もそれに応じて狭くなり、コンテンツがはみ出ることはないはずだ。

しかし、viewport が狭いときに、意図的にコンテンツを viewport の外にはみ出させることがあるかもしれない。その場合、viewport からはみ出た部分が画面からもはみ出るのが正しい挙動だ。それならどうして、Safari はコンテンツを画面に収めるように動作することがあるのだろうか。Safari の開発者によれば、それは多数の人が width=device-widthinitial-scale=1 を正しく使用していないからだ。

コンテンツの一部または全部の幅がたとえば 800px で固定されており、画面の幅がそれより狭いとき、ほとんどの人はコンテンツを縮小して画面に収めたいと思うだろう。そのときの適切な viewport の設定は、既に述べたように width=800 だ。width=device-width(または initial-scale=1)とすると、画面の幅に収まらない部分が右にはみ出る。本当にそのような表示を意図しているなら、iPad の Split View モードでも右にはみ出させるために width=device-width,initial-scale=1,shrink-to-fit=no と指定する。

その6に続く。

[この記事だけを読む。] [この記事にコメントを書く。] [最新の記事を読む。]

[もっと古い 5 件の記事を読む]

RSS feed

カテゴリ

[/language] (98)
[/links] (254)
[/mac] (114)
[/music] (36)
[/origami] (406)
[/this_blog/ajax] (7)
[/this_blog/blosxom] (4)
[/this_blog/history] (12)
[/this_blog/perl] (9)

最新記事

パスワードについてのあなたの常識はもはや非常識かもしれない・その1 [/links]
ニューラルネットワークとディープラーニングで翻訳はどうなる・その5 [/language]
ニューラルネットワークとディープラーニングで翻訳はどうなる・その4 [/language]
HTTPS 対応 [/links]
ひらがな・カタカナ学習ウェブアプリ [/links]
日本語の「た」と英語の過去形 [/language]
ORI-REVO で回転楕円体を折る・その2 [/origami]
ORI-REVO で回転楕円体を折る・その1 [/origami]
折り紙建築 [/origami]
折鶴に松図小柄 [/origami]
改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その6 [/links]
改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その5 [/links]
改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その4 [/links]
改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その3 [/links]
改訂版・たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる・その2 [/links]

羽鳥 公士郎