2018年の抱負の進捗状況 (5月1日時点)

Life

この記事は自分向けの記事です

もうちょっと頻繁にblogを更新する

内容は兎に角、進捗状況報告以外に2本記事を書いたので良しとする、くらいの感じです

もっと内容をとか言っていると書かなくなるので、チラシの裏レベルでもとりあえず更新する癖を付けましょう、位の緩い感じで

体重を60kgまで落とす

の朝が69.4kgでの朝が67.15kgでした

私の身長が165cmなのでBMI が25未満 (67.15/1.652 ≒ 24.7) になり、BMI基準で標準になりました

引き続き60kgを目指しますが、生活習慣を見直して健康になるという目標は今の所、達成できているようです

HTML5.2の仕様書を一通り読む

3月中旬から4月中旬まで忙しくて仕様を読めていなかったのですが、そのまま4月下旬になっても再開できていません

この手の作業はやる気の問題云々ではなく、単に習慣づけて「空いた時間に自然にやる」位の所に持っていくのがベストだと思うので、「暇になったらtwitterみる」ではなく「暇になったらHTML5.2の仕様を読む」位に持っていきたい所

あまり気張ると疲れちゃうので今後ともだらだら続ける心算です

応用情報処理試験に合格する

4月15日に受験しました

合格発表はです

午前、午後とも回答欄を埋めることは出来 (午前はマークシートなので埋められて当たり前なのですが)、それなりの手ごたえはありましたので秋には受かるんじゃないでしょうか (駄目じゃねぇか)

今どきの安全なパスワードについて

Security

2008年にサーヴィスごとに異なるパスワードの生成法と言う記事を書いていたのですが、この内容が (当時から、あるいは現在の基準だと) 間違っている為、内容を更新します

結論: サーヴィスごとに十分な長さのパスワード (パスフレーズ)を使う、漏洩の疑いがある時は迅速に変更し、定期的な変更は不要

パスワード (単語レベル) ではなく、パスフレーズ (単語の集まり) を使い、長い文字列を使うべきです

例えば英数字と記号をランダムに組み合わせた '2v9s!nQ%' よりも 'petbottlecrystalfacility' (PET bottle, Crystal, Facility) の方が安全です

また、サーヴィスごとに異なるパスワード (パスフレーズ) を使うべきです

パスワード (パスフレーズ) が漏れた疑いがある時は迅速に変更する必要がありますが、定期的な変更をするよりも長いパスワード (パスフレーズ) を使った方が安全です

(以降、この記事ではパスワードとパスフレーズを統一してパスワード書きますが、推奨するのはパスフレーズです)

サーヴィスごとに異なるパスワードを使う

サーヴィスごとに異なるパスワードを使うべきなのは今も変わりません

十分複雑なパスワードを使っていても全てのサーヴィスで同じパスワードを使っていれば何かの拍子に漏れた時にあらゆるサーヴィスのパスワードが漏れたのと同じことになってしまいます

サーヴィスごとに別なパスワードにした場合に問題になるのは管理方法ですがサーヴィスからパスフレーズを生成するか、OSやブラウザのパスワード管理機能やパスワード管理ツールを使うのがお勧めです

管理が面倒だからと簡単なパスワードを設定したり、同じパスワードを使いまわすより、普段はOSやブラウザのパスワード管理機能やパスワード管理ツールに任せ、何かの拍子に必要になったが思い出せない時はパスワードの再設定をした方が良いでしょう

長いパスワードを使えば定期的なパスワードの変更は要らない

仮にアルファベット小文字のみ8桁のパスワードが30日で突破される恐れがあるとします

ならばそのパスワードを1桁増やして9桁にすれば26倍の複雑さになり、突破されるまでの期間は 26×30日 = 780日となり、5桁増やせば265×30日 = 3億5644万1280 日、つまり約97万5910年となります

突破されれる恐れがある短いパスワードを定期的に変更するより、突破されにくい長いパスワードを使うべきです

使用する文字の種類を増やすよりも長いパスワードにする

パスワードの組み合わせは使用する文字種のパスワード桁数乗になります

パスワードの桁数の上限が8桁程度と少なかった場合、使用する文字種を増やすとパスワードの組み合わせが増えるため良いことでした

アルファベット小文字のみ8桁の場合の組み合わせ
268 = 2088億2706万4576通り
アルファベット大文字小文字、数字、記号10種の (計72) の8桁の場合の組み合わせ
728 = 722兆2041億3630万8736通り

しかし、パスワードの桁数を増やせば使用する文字種が少なくても十分複雑なパスワードを作ることが出来ます

アルファベット小文字のみ11桁の場合の組み合わせ
2611 = 3670兆3444億8698万7776通り

アルファベット小文字のみ文字26種類のパスワードでも11桁あれば文字72種8桁のパスワードの約5倍複雑なパスワードを作ることが出来ます

ですので8文字のパスワード、例えば 'babymaze' を8文字のまま 'a' を '@' に 'e' を '3' にして 'b@bym@z3' と言うもパスワードを作るよりも、覚えやすい単語、例えば "fish" を足して "babymazefish" にした方が、より複雑で人間にも覚えやすいものになります

なお、前述の 'a' を '@' に変えるような変換や、キィボードを隣にずらすようなノウハウは攻撃者側も十分の承知しているため、安全性を高めることになりません

ありがちなパスワードは駄目

一般的にパスワードは入力を受ける側はハッシュ値で保存しています

ハッシュ値とはある値を別の値に不可逆的に変換した値で、例えば 'cat' が 'WNS'、'dog' が 'HYB' になったりします (あくまで例です)

暗号化と違ってハッシュ値は変換後の値から変換前の値に復号するのが非常に困難ですが (基本的に総当たりで計算することになる)、予め 'cat' が 'WNS'、'dog' が 'HYB' になることが分かっていれば逆引き辞書を作り、'WNS' なら 'cat'、'dog' なら 'HYB' と知ることが出来ます

このような攻撃者の逆引き辞書でパスワードが突破されないために「辞書に載っている文字をパスワードにしてはいけない」と言われています

この場合の「辞書」とは攻撃者が用意する逆引き用の辞書の事なので、一般の辞書には乗っていなくても 'aaaaaaaa' や 'p@ssw0rd '、'abcd1234 '、'qwertyui' あるいは日付になる様な8桁の数字などありがちなパスワードは使ってはいけません

そして前述のように 'Password' のようなありがちな単語を 'a' を '@' に変えて 'P@ssword' にしてもパスワードとしてやはりありがちな単語のままであり、安全性を高めることになりません

部分的に辞書に載っている単語でも問題ない (全体はだめ)

前述のように一般的にパスワードは入力を受ける側はハッシュ値で保存しています

しかし、先の例のように 'cat' が 'WNS'、'dog' が 'HYB' になる場合でも 'cat' と 'dog' を連結した 'catdog' は 'WNS' と 'HYB' を連結した 'WNSHYB' にはならず、全く別な値になります

このため、パスワードの一部分が辞書に載っている単語でも全体として辞書には載っておらず十分複雑なパスワードなら問題ありません

(パスワードの一部が予め攻撃者に知られてしまっているのは話が別です、念のため)

NHK受信料ゥァア゛ーッ (NHKは悪くないです)

Life

NHKは悪くなく、この記事は私が踏ん切りをつけるために書かれました

私は2012年9月に結婚の為に実家を離れ今の住居に引越しし、世帯も独立させ、電気ガス水道などと共にNHKとも新規に契約しました

地上契約のみで

しかし、私の入居している集合住宅は衛星放送も受信できており、(入居直後の契約申し込み時点の認識は覚えていないのですが) その後NHKのBS1やBSプレミアムも見てました

契約してないので、契約を促すメッセージでますが

メッセージは出ていますが、なぜか自分は契約しているものと誤認した上で「メッセージの消し方わからないけど、面倒だからまあいいや」と思って放置してました

今に至るまで5年7か月

衛星契約への変更に伴う契約変更差額
月数 1か月分 2か月分 3か月分 4か月分 5か月分 6か月分
契約変更差額 970円 1,940円 2,910円 3,880円 4,850円 5,540円
月数 7か月分 8か月分 9か月分 10か月分 11か月分 12か月分
契約変更差額 6,510円 7,480円 8,450円 9,420円 10,390円 10,775円
※口座・クレジット払いの場合10,780円
(沖縄県を除く)

NHK受信料の窓口-衛星契約への変更のお手続き

1年を超えた場合はどうなるかわかっていませんが、単純に前述の表から12か月分×5+7か月分とすると10,780円×5+6,510円で未払いの残額は60,410円になるようです

NHK受信料については思うところは色々ありますが、それはそれとしてこの金額は本来払うべきものであるため、ちゃんと申告して払いますけどね

払いますけど、6万円あったら、PC用のゲーミング4Kモニターとかその他色々買える訳じゃないですか、払いますけどね

NHK受信料ゥァア゛ーッ (NHKは悪くないです)

2018年の抱負の進捗状況 (4月1日時点)

Life

この記事は自分向けの記事です

もうちょっと頻繁にblogを更新する

書くことないのに更新を目的にして書いてもしょうがないので3月の更新はなしかな、と思っていたらHTML4.01が正式に終了となったので飛び込みで3月31日に記事を一本書きました

そんな感じでまったりと

体重を60kgまで落とす

の朝が71.3kgでの朝が69.4kgでした

1か月で1.9kgとなかなかの減り具合ですが、時点の体重が便秘気味でたまたま重かっただけなので、グラフで見ると余り減っていません

むしろ直近1週間くらい69.3kgから69.9kgの間で減らずに停滞している状態なのでそろそろ新しい減量法が必要かと思案を始めている所です

に68.0kgくらいになっていると嬉しいのですがどうなりますやら

HTML5.2の仕様書を一通り読む

元々色々多忙になるので3月中旬から4月中旬はいったんお休みとしておりました

4月中旬あたりからまた読み始めて5月の連休前後で記事にできればいいな、と思っています

あと、無職になりでもしないとHTML5.3の勧告に間に合わないのが確実なので、HTML5.3勧告後の方針も決めておかないといけません

うーん

応用情報技術者試験に合格する

秋にご期待ください (今やれ)

さようなら、HTML 4.01

HTML

最新版以外のHTMLをすべて廃止しようという提案がなされていましたが (Proposal to Republish Previous Versions of HTML and XHTML as Obsolete Recommendations (Wide Review until 2017-09-07) from Xueyuan on 2017-08-11 (public-review-announce@w3.org from August 2017) ) これが実行され、最新のHTML5.2以外のW3CのHTMLはSuperseded Specificationと明示されました

私のような未だにHTML4.01やXHTML1.1を書いている人からするとこれはHTML5への移行猶予期間の終了のお知らせで、待ったなしの状況です

今後は単にHTMLまたはXHTMLと言った場合、それは最新のHTML5.xを意味することに成るでしょう

さようなら、HTML 4.01

所で、Superseded Specification (直訳すると、代替された仕様) って何よと言う事なのですが、これは World Wide Web Consortium Process Documentの2018年2月1日改訂版で追加された物です

An Obsolete Recommendation is a specification that the W3C has determined lacks sufficient market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded. If an Obsolete specification gains sufficient market relevance, the W3C may decide to restore it to Recommendation status.

A Superseded Recommendation is a specification that has been replaced by a newer version that the W3C recommends for new adoption. An Obsolete or Superseded Specification has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy.

従来から存在した廃止された勧告仕様 (Obsolete Recommendation) は実装のための推奨を辞めるのに対し、代替された勧告仕様 (Superseded Recommendation) は新しい仕様があるのでそちらの実装をしてくださいと言う事のようです

Web上には過去に書かれて更新されていない前世代のHTML文書が多量にあり今回superseded recommendationになったからと言って一斉にHTML5にはならないでしょうから、各ブラウザが直ちにサポート対象外にするとは思っていないのですが、今後とも参照されることを望む文書のオーナーは最新のHTML5.xへ変換するのが望ましいでしょう (私はやる気があんまりありませんが)

それでは最後に今回Superseded Specificationになった仕様の一覧です (私の知る限り)

ちなみに、HTML4.01を参照しているISO-HTMLも実質終了かと思われます (実質の話をするなら始まってもないような……)

また、それぞれの仕様の最新でないバージョン (例えばHTML4.0、HTML5、HTML5.1、HTML5.1 2nd) はSuperseded Specificationとは明示されていませんが、恐らくこれは前提として Latest version を見ろと言う事かと思います

それぞれの仕様の最新でないバージョン (例えば[HTML4.0](http://www.w3.org/TR/REC-html40-971218/)、[HTML5](http://www.w3.org/TR/2014/REC-html5-20141028/)、[HTML5.1](https://www.w3.org/TR/2016/REC-html51-20161101/)、[HTML5.1 2nd](http://www.w3.org/TR/2017/REC-html51-20171003/)) はSuperseded Specificationとは明示されていませんが

と書いていましたが、従来とは別アドレスでSupersededと書かれた文書がありました

HTMLの5.1のSupersededと明示されたアドレスを未だ見つけられていませんが、見つけたら後日追記します

2018年の抱負の進捗状況 (3月1日時点)

Life

この記事は自分向けの記事です

もうちょっと頻繁にblogを更新する

個人的にはもうちょっと更新したいのですが、更新自体を目的として書くこともないのに記事を書くと碌なことがないので書くことが出来たら、と言う事で

体重を60kgまで落とす

の朝が72.5kgでの朝が71.30kgでした

一応年内に60kgに到達可能な状況ですが、もう少し速度を上げたい所

HTML5.2の仕様書を一通り読む

自分の覚書を2.6. Fetching resourcesまで公開

下読みなら2章は全部終わっているのですが、3月と4月は他の事を優先したいので今以上に進捗は落ちる見込みです

年内に読み切るのは絶望的ですが、仮に2年がかりになってもとりあえず読み切る心算なので無理して速度は上げずにちまちまやっていきたい所存です

応用情報技術者試験に合格する

Bridge Constructor Portalの60面はどうしても解けなくてにYoutubeで解法を検索してクリアしました

そのあとStellarisに手を出したのですが、これが本気で数百時間平気で持っていく4X strategyゲームで流石に封印して、いまはMinecraftをメインに遊んでます

さてはお前合格する気ないな

HTML5.2の見出し毎の内容を雑にまとめる、2.6. Fetching resources (リソースの取得)

HTML

2. Common infrastructure (共通基盤) の中の 2.6. Fetching resources (リソースの取得) について

もし、HTML5をWeb Applicationの為でなく、単なる文書 (form要素やJavaScriptによる従来のXMLHttpRequestのような処理、あるいはCookieなどを一切使わない文書) を書くために勉強するなら、恐らく「こういう章が存在する」以上のことを覚えておく必要はない

ただし、そのような単なる文書であっても真にスタンダロンな文書でなければ、例えばimg要素のようなリソースの埋め込みや、link要素で指定されたスタイルシートの取得などもUAはfetchで定められた仕様に従って動いており、この章の内容は無関係ではない

また、もし、HTML5を (User Agentを実装する為でなく) Web Applicationを作成するために勉強するなら、恐らくこの章で定義されている用語や概念は知っておくべきであろう

ただし、そのような Web Application開発者であっても、例えばFetch 概説 - Web API インターフェイス | MDNなどで十分足りる場合が多いであろう

Fetchを全く知らない場合、予備知識なくこの章を読むより、先にLiving StandardのFatch Standardを読んだ方が理解が早いと思われる (非公式版ではあるがFetch Standard （日本語訳）も存在する)

更に併せて読んでおくと良いかもしれない文書を以下に列挙する (なお、筆者は読めていない)

なお、内容についてはあくまで初学者の覚書ですので、正式な仕様はW3CのHTML5.2を確認してください

また、勉強のため、各仕様の邦訳文書、解説文書を読まずに自分で翻訳して覚書を書き終わってから答え合わせとして邦訳文書を参照するようにしています

このため、多くの訳語が一般的な訳と異なっていますのでご注意ください

2.6. Fetching resources (リソースの取得)
2.6.1. Terminology (用語)

ユーザーエージェントは様々な転送プロトコルを実装しているが、この仕様ではもっぱらHTTPに関する動きを定義する

HTTP取得メソッド (HTTP GET method) はプロトコルのデフォルトの検索動作 (例えばFTPのRETR) と同じであり、HTTP用語において安全かつ等冪 (複数回の実行を行っても結果が同じ演算) である

FTPのRETRとは、FTPのリモートファイルをダウンロード（Retrieve）するコマンド、RFC 959参照

HTTP応答コード (HTTP response codes)は他のプロトコルの持つ同様の基本的な意味のステータスと同等である。

例えば "ファイルが見つからない" エラーは 404 コードと同様で、サーバーエラーは500番台のエラーと同様など、と言う事です。

HTTPヘッダー (HTTP heade) 他のプロトコルの分野と基本に同じ意味を持っている

例えばHTTP認証ヘッダー (HTTP authentication headers) は、FTPプロトコルの認証と同じである

参照元ソース (referrer source) はDocumentまたはURLである

ほか、潜在的CORS要求の作成 (create a potential-CORS request) についての記述がある (が、自分は輪をかけて理解できていない)

2.6.2. Processing model (処理モデル)

ユーザーエージェントが基点からURLやリソースを取得する場合の処理

iframe内の場合や、data:URL、about:blankなどの場合の処理が記述されており、更にCookie更新についてフラグ処理、リダイレクトの場合 (HTTPのステータス301/302/303/307の場合)、などユーザーエージェントが実装すべき処理について記述されている

ユーザーエージェントの実装者やWebApplication製作者は把握すべき内容だと思われるが、単にHTMLで文章をマーク付けしたいだけの自分には荷が重くフレーズレベルで単語を眺め、内容は把握していない

2.6.3. Encrypted HTTP and related security concerns (暗号化HTTPとそれに関するセキュリティ上の懸念)

この仕様でHTTPを参照する場合、HTTPsプロトコルで表現されるHTTP-over-TLSにも適用される

ユーザーエージェントは証明書にエラーがあった場合ユーザーに報告し、併せてリソースのダウンロードを拒否するか、又は暗号化なしの時と同様の挙動にしなければならない

ユーザーエージェントはユーザーが以前訪問したサイトに再び訪問した時に暗号化が使用されていなければ、訪問する度に潜在的な問題があることを警告しなければならない

そうしなければユーザーは中間者攻撃に気付くことが出来ない

ほか、デジタル証明書が自己署名、期限切れ、あるいは以前CA署名付きのデジタル証明書だったサイトが自己署名のデジタル証明書に切り替えた場合のユーザーエージェントの振る舞いについて

2.6.4. Determining the type of a resource (リソースタイプの決定)

コンテンツ型メタ情報 (Content-Type metadata) はMIMEスニッフィング仕様 (MIME Sniffing Standard) に従って取得しされ、解釈されなければならない

計算されたリソースの型 (computed type of a resource) 関連した連続する8bitの計算されたメディアタイプを見つけるためのMIME Sniffing Standardで与えられた一貫した方法に基づかねばならない (7. Determining the computed MIME type of a resource - MIME Sniffing Standard 参照)

画像をスニッフィングするための規則 (rules for sniffing images specifically) とリソースがテキストかバイナリィかを区別するための規則 (rules for distinguishing if a resource is text or binary) はMIMEスニッフィング仕様でも定義されており、両方のルールセットはMIMEタイプを返却する

MIMEスニッフィング仕様を厳密に守らない場合、セキュリティ上の問題が生じる可能性がある

2.6.5. Extracting character encodings from <meta> elements (meta要素による文字エンコーディングの抽出)

文字列sを与えられた場合のmeta要素からの文字エンコーディングを抽出するアルゴリズムについて

このアルゴリズムは文字エンコーディングを返却するか、何も返却しない

HTTPの仕様とは異なることに注意すること

2.6.6. CORS settings attributes (CORS設定属性)

CORS設定属性は列挙型の属性となる

CORSモードで資格がsame-originとなる匿名 (Anonymous)または空文字列と、CORSモードで資格がincludeとなる資格情報を使用する (Use Credentials) と、属性が省略された場合のNo CORSモードが存在する

詳細は仕様参照

2.6.7. Referrer policy attributes (リファラーポリシィ方針属性)

リファラーポリシィ属性は、列挙型の属性である

空文字列を含め、リファラーポリシィはこの属性へのキィワードであり、同じ名前の状態にマッピングされる

属性の無効な値のデフォルト値と属性がない場合のデフォルト値は空文字列の状態となる

これらの値による処理への影響の詳細は、この仕様、Fetch Standard仕様、Referrer Policy仕様に定められている

幾つかの信号がFetchの処理モデルに寄与でき、リファラーポリシィ属性はその一つである

一般にこれらの信号が処理される順序は以下のとおりである

  1. リファラーのない (noreferrer) リンクタイプ
  2. リファラーポリシー属性の値
  3. name属性がreferrerに設定されたmeta要素
  4. HTTPヘッダーのリファラーポリシィ