・「Windows 10 19H1」、「Spectre Variant 2」対策にグーグルの「Retpoline」を採用へ - CNET Japan
「Microsoftが「Spectre Variant 2」への対処にGoogleによる緩和策である「Retpoline」を取り入れ、「Windows 10」の次期大型アップデート「Windows 10 19H1」で実装するという。」
海賊版サイト対策検討会は会議を無期延期とした
半数がブロッキングに反対
この日、激論は３時間半にわたって続いた。前半戦のクライマックスは、全委員の半分を占める９人が提出した意見書の扱いだった。
９委員は意見書で、とりまとめの結論部分を以下のように修正することを求めていた。
「ブロッキングの法制化は現状では違憲の疑いがある」「ブロッキングの法制化については一旦見送った上で、民間の協力においてブロッキングを除く対策を総合的に推進するべきであると考える」
共同で意見書を提出したのは、宍戸常寿・東大教授や丸橋透・明大教授、森亮二弁護士のほか、電気通信事業者やインターネット関係の団体代表や消費者団体代表などだ。中には、水面下で出版社と通信事業者の協力の枠組みづくりを進めていた委員もいる。ブロッキング法制化を棚上げにしても、それ以外の協力によって海賊版サイト被害を収束させるという強い意思を示すためだ。
ほかに有効策はない？
実は、この直前には、ブロッキング反対派を後押しするような新事実も相次いで判明していた。一つが、米国の司法制度を活用することで、米国のＣＤＮ（コンテンツ配信ネットワーク）事業者、クラウドフレア社から、同社のサービスを使っていた「漫画村」運営者の情報を開示させた事例。もう一つは、日本の裁判所が、クラウドフレア社のサービスを使うサイトについて肖像権などの人格権侵害を認め、差し止めと発信者情報開示の仮処分命令を決定したことだ。
いずれの手法も海賊版サイト被害を止めるための突破口となる可能性があり、「ブロッキング以外に有効な対策がない」としてきた推進派の主張に大きな疑問を投げかけるものだった。
「漫画村」運営者、特定に成功
米国の司法制度を活用し、漫画村運営者の特定に成功した山口貴士弁護士によれば、その手法は簡便でスピーディー、しかも、これまで想像されていたよりはるかに低コストで済むという。
まず、「漫画村」に作品を勝手に掲載されていた漫画家を原告として、米国の連邦地方裁判所で、漫画村運営者を氏名不詳のまま被告とし、著作権侵害による損害賠償請求訴訟を提起。そして、裁判所から被告を特定するためのディスカバリー（証拠開示手続き）を行う許可を求め、漫画村にサービスを提供していたクラウドフレア社に対し、漫画村に対する課金関係の資料を提出させたのである。
「６月１２日に提訴し、クラウドフレア社から運営者の情報が届くまで１７日間しかかからなかった。費用も、「億」より０が二つほど少ない金額」。入手した情報をもとに国内で運営者の居場所を調査して突き止め、現在、刑事告訴や損害賠償請求の準備を進めているという。
こうした法的な措置が成功したという事実は、ブロッキング立法が違憲となる疑いをより深めることにつながる。ブロッキングは憲法の保障する通信の秘密を侵すため、それを可能とする法律は、表のような違憲審査基準をクリアしなければ違憲となる疑いがある。
このうち、（１）の立法事実とは、どうしてその法律が必要なのか、法律を作るための根拠となる事実のことだ。そもそも、検討会設置の目的は、「昨今、運営管理者の特定が困難であり、侵害コンテンツの削除要請すらできないマンガを中心とする巨大海賊版サイトが出現」（検討会資料より）したため、その対策を検討することだった。だが、工夫次第で運営者の特定も、侵害コンテンツの削除要請も実現可能であるとすれば、「そもそも立法事実はない」（山口弁護士）というのだ。（４）の「他の実効的な手段が存在しない」という条件も満たされないとみるべきだろう。それでも推し進めたい？事務局
しかし、１５日に事務局が検討会に出してきた中間とりまとめ案では、この二つの事実については、脚注に小さく付記されただけだった。一方で、「ＣＤＮ事業者に対する執行の可能性」という約４ページにわたる項目の本文には、執行の難しさ、実効性の不透明さを指摘する文言が数多く並んでいる。
「アンフェアだ」。とりまとめ案を知った山口弁護士は「事務局は何としてもブロッキング法制化を進めたくて、ブロッキングの正当性を疑わしくする方策があることを認めたくないのだろう」と批判した。
もはや、海賊版サイトの被害を減らすために、なんとか様々な対策を模索しようという検討会の当初の趣旨は忘れられ、ブロッキング法制化を実現するために、なんとか別の対策の有効性を否定することが目的になってしまったかのようだ。
こうして、９人の意見書は採用されることはなく、「賛成と反対の両論を併記すれば公平だろう」という賛成派の意見で押し切られた形となった。
議論取りまとめ」巡る攻防
最後の攻防は、その賛否両論の報告書を、検討会としてとりまとめるかどうかだった。
一見、賛否両論であれば公平な扱いにも感じられるが、そこが争点になるのは理由がある。
「賛否両論であっても、何らかのとりまとめを検討会として出せば、議論を経たことをを理由に、検討会の外で法制化を進めることが可能」――。それが賛成派も反対派も、双方が抱く見立てだった。だからこそ、反対派は必死にとりまとめを拒み、賛成派は両論併記でのとりまとめを強く主張するという対立の構図となったわけだ。
この日はとりわけ、何とかしてとりまとめを出したい座長と、反対派の森委員との激しい議論が目を引いた。
まず、共同座長の１人、村井純・慶応大教授が、ブロッキング法制化については「まとまらなかった」と明記した報告書を出すことなどを提案。もう１人の共同座長、中村伊知哉・同大教授も、「まとまらなかったという報告を出すのは大変重要な政治的メッセージではないか」と反対派に合意を促した。だが、反対派の委員は、検討会として何らかの報告を出すこと自体に抵抗する。
なし崩しの法制化への危惧
森委員「検討会としては、何もとりまとめず、報告せず、検討会は無期限延期にしてください。その間にブロッキング以外の手段が講じられ、その効果を検証することができます。その結果、（他に実効的な手段が存在しないなどの事実が判明すれば）違憲の疑いがなくなる可能性もあるんです」
村井座長「座長として、何も報告をしないのは無責任だと思っている」
森委員「議事録でいいじゃないですか。全部、政府のホームページに公表されている。事務局の修正は、反対派の意見をきちんと反映してくれない。そのようなものが出ることに不安がある」
村井座長「事務局が強引に法制化を進めるというのは邪推。報告をしたくないというなら、あなたはなぜここに来たんですか。会議を開催するのに、どれだけコストがかかっていると思うんです？」
森委員「我々の使命は、報告書をまとめることじゃなく、国民のためにいいと思うことを考えて、行動することのはず。いい報告書だと思えば出すし、悪いと思えば出さない。村井先生こそ、なぜ、まとめを出さなきゃいけないと思うのですか」
激論の末、押し切ったのは森委員だった。村井座長は議事録のみを公表し、検討会としては「とりまとめ」も「審議状況の報告」も一切の報告はしないとして、検討会を無期延期とした。ただ、検討会議の終了後、中村座長は、「座長の立場から何らかの文書を残す可能性もある」と話した。
「政策形成の歪が表出した」
９回におよぶ議論を、検討会の外から第三者としてみてきた曽我部真裕・京都大教授（憲法）は、「政策形成のあり方について、歪みが表出した」と振り返る。
事務局が最初に結論を決め、自分たちの思惑通りに発言する委員を選び、政策に「お墨付き」を得ようとするやり方は「審議会行政」などと呼ばれてきた。曽我部教授は「今回も、事務局は最初からブロッキング法制化というゴールを設定して進めようとしたが、委員の半分に反対派を入れたこと、検討会が注目を集めたこともあって紛糾が表面化した」と指摘する。
海賊版サイト対策としてブロッキングが急浮上したのは今年２月１６日、知的財産戦略本部の検証・評価・企画委員会の第３回コンテンツ分野会合での議論だったとされる。同会合は基本的に公開されているが、第３回は非公開で行われ、いまだ議事録が公開されていない。メンバーは出版社や権利者団体の代表、著作権法を専門とする学者などが中心で、消費者代表や憲法学者、電気通信事業者も含まれていなかった。
しかし、４月に政府が緊急対策としてブロッキングを打ち出し、大きな注目を集めるようになると、電気通信分野の専門家以外では、あまり知られていなかった様々な問題点が、次第に明らかになっていく。ネットワーク技術者や、違法有害情報の削除や発信者情報開示の手続きに精通した弁護士など、様々な分野の専門家が議論に加わり、問題解決のための知恵も集まっていったが、それでもなお、事務局はブロッキングに固執した。そこに問題をこじれさせた原因がなかっただろうか。
議論の終盤では、一部の出版社や、権利者に近い弁護士からも「ブロッキング以外の有効策をまず実施してほしい」「現状では憲法違反の疑いがあるのは事実なのだから、まず別の対策を実施して、効果を検証した後にまた検討してはどうか」といった声も出ていた。ある出版社の幹部は、「本当に私たちやクリエーターのために、ブロッキングをしようとしているのだろうか」と不満を漏らしていた。
なぜ事務局はこれほど固執したのか。「通常なら、こんなに批判のあるものを、事務局が無理やり進めるとは思えない。背景に政治的な事情があるのではないかと想像してしまうが、一方で、政治の動きは見えず、確認もできない。不透明な政策形成に怖さを感じる」と曽我部教授は危惧する。
ネット時代の諸課題、取り組む好機に
ブロッキング法制化を巡って対立が続く中、今回の問題で浮き彫りになりながら、十分に議論を深められなかったテーマも少なくない。曽我部教授が例に挙げるのが、インターネットによって急増したグローバルな紛争に対する司法制度の課題だ。
今回の問題を巡っては、海外のホスティングサーバーやＣＤＮサービスを利用する海賊版サイトに対して著作権者が権利行使しにくい点が繰り返し指摘されてきた。日本国内に事業所がない海外事業者に対しても、日本向けサービスを提供している場合、国内での裁判が認められる傾向にあるが、例えば、裁判の資料を送る「送達」には数か月かかるのが一般的だ。仮処分であれば発令前の送達は不要で、比較的早く決定が出るが、処分が発令されてから決定文が相手に届くまでに、やはり数か月かかるという。最新のコンテンツを無断掲載され、１日でも早く状況を打開したい権利者にとっては、使い勝手の悪い制度だろう。
だが、曽我部教授は「こうした問題は海賊版サイトに限らず、名誉毀損やプライバシー侵害などでも長年、指摘されながら、なかなか議論が深まらなかった分野でもある」と指摘する。
検討会の空中分解で、今後の先行きは見通せない状況だが、各分野の専門家が一同に会して議論し、論点が洗い出された面もある。ネット時代の諸課題に分野横断的に取り組む好機とできないものだろうか。
ソ－ス：空中分解…海賊版サイト対策検討会はなぜ迷走したか : 深読みチャンネル : 読売新聞（YOMIURI ONLINE） 1/4
関連：
・海賊版サイトをブロッキングするための5つの手法（その仕組みと限界および問題点） - INTERNET Watch
エプソンが格安の互換インクカートリッジを排除する
プリンターメーカーのエプソンが、サードパーティーによる格安のインクカートリッジを使えないようにするために、セキュリティのアップグレードと称して実質的なダウングレードを行っていたことが判明しました。調査を行った電子フロンティア財団はセキュリティアップグレードを装ったダウングレードを強く批判しています。
Mozilla、Symantec発行のTLS証明書無効化を延期
協定世界時の10月11日16時に実施される「ルートゾーンKSKロールオーバー」
一般のネットユーザーは、「10月12日朝」というタイミングだけ意識を
一方、一般のインターネットユーザーにとって気になるのは、自分自身が加入しているISPやモバイル通信サービス、もしくは企業・組織内で提供されているキャッシュDNSサーバーの対応状況であろう。
JPRSの米谷嘉朗氏によると、DNSOPS.jpにおいて、DNSSEC検証を行っているキャッシュDNSサーバーの運用者に対してアンケートを実施した結果、「国内の主だったプロバイダーなどではすでに対応を済ませており、必要に応じて必要な体制を取る予定であることが確認された」ということである。また、広く公開されている「Google Public DNS」「Quad9」「1.1.1.1」といった主なパブリックDNSサービスも対応済みであることから、「大きな問題は発生しないと考えられる」とした。
米谷氏は、今回のルートゾーンKSKロールオーバーについて、ISPや携帯キャリアなど加入者向けのインターネット接続サービスを提供している事業者においてはきちんと対応がなされ、トラブルが発生する可能性はほぼないとみており、「一般のネットユーザーの方々は、特に何かをする必要はない」という。
ただし、企業・組織内LANを経由してインターネットに接続している場合は、企業・組織内のキャッシュDNSサーバーが対応していない可能性も残されているとし、以下のようにアドバイスする。
「もし、10月12日朝になって、PCからアクセスしようとしたときにうまく接続できないサイトがあったら、手持ちのスマホでW-iFiを切り、モバイル回線経由で、そのサイトにアクセスしてください。もしアクセスできるようなら、ネットワーク管理者にその旨を伝えてください。」
すなわち、10月12日朝のタイミングで、モバイル接続プロバイダー経由で正常にアクセスできるサイトが、社内LAN経由からはアクセスできなくなっているとすれば、それは社内向けに設置されているキャッシュDNSサーバーにおいて今回のルートゾーンKSKロールオーバーへの対応がなされていない可能性が高いというわけだ。
ソ－ス：今夜25時に迫った「DNSの世界的な運用変更」、ネット史上初の「ルートゾーンKSKロールオーバー」による利用者への影響は？ - INTERNET Watch
・ルートゾーンKSKロールオーバーが実施されました - JPNIC
関連：
・サイズの大きなDNS応答を正しく受け取れるかの確認
ルートゾーンKSKロールオーバーに対応するためには、少なくとも1424バイトのDNS応答を正しく受け取れる必要がある。この確認には、Verisign Labsが公開している確認用のサイト「DNSSEC Key Size Test」が使用できる。
これは、ウェブブラウザーから同サイトにアクセスするだけという手軽さで診断してくれる（本サイトでテストされるDNS応答サイズは1424バイトよりも大きい）。診断結果は1から4までの4項目が緑で「PASS」となっていることを確認すればよい。5が赤で「FAIL」と表示されるが、こちらは失敗表示の確認用であるため、気にしなくてよい。
もしも1から4までの結果に「FAIL」が出た場合には、何らかの理由により大きなサイズのDNS応答を受け取れなかったことを示している。この場合、使っているフルリゾルバーが古かったり、フルリゾルバーから外部ネットワークまでに経由するネットワーク機器に問題があったりする可能性がある。
HTML5から意味の変わる要素（再確認）
タグ（要素） HTML4.01 の定義 HTML5 の定義 <b> 太字
文書内のキーワードや製品名など、他と区別したいテキストを表します。
一般的に印刷される際に太字となるようなテキストです。その箇所が重要であるという意味や強調する役割はありません。<i> イタリック体
声や心の中で思ったことなど、他と区別したいテキストを表します。
一般的に印刷される際にイタリック体となるようなテキストです。その箇所が重要であるという意味や強調する役割はありません。<em> 強調
強勢する（アクセントを付ける）箇所を表します。同じ文でもどの個所を強勢するかでニュアンスが異なってくるでしょう。
例えば、「猫はかわいい」という文を、「<em>猫</em> はかわいい」とすれば、（犬などの他の動物じゃなくて…）というニュアンスが出せるかもしれません。
また、「猫は<em> かわいい</em> 」とすれば、（猫はかわいくないという意見への反論）というニュアンスが出せるかもしれません。<strong> 強い強調
強い重要性を表します。
HTML4.01 の定義とほぼ同じですが、<strong> ～ </strong> の中の一部を、さらに <strong> ～ </strong> で囲むことで、重要性の強さの程度を指定し分けることができるようになっています。<small> テキストを小さくする
免責、警告、著作権などの注釈や細目を表します。
その箇所が重要であるという意味や強調する役割、反対に重要性を弱める意味などはありません。
メインコンテンツではなく、あくまで注釈・細目となる箇所に使用する要素です。
例えば、利用規約がメインコンテンツとなるページで、全体を <small> ～ </small> で囲むような使い方は適切ではありません。<hr> 水平線
段落と段落の間などのテキストブロック間におけるテーマの区切り、セクション内における話題の区切りを表します。
セクション同士の区切りとなる </section>と<section> の間については、すでにそれ自体でテーマの区切りを表しているので、 <hr> を挿入する必要はありません。
米グーグル:Google+の消費者版サービスを終了すると発表
uBO Myフィルタ−
Myフィルタ−
! google google.co.jp##.gb_fa ! wikipedia ja.wikipedia.org##.frb-main ja.wikipedia.org###frb-inline ja.wikipedia.org###frb-nag ! NHK www3.nhk.or.jp##.pause
Firefox 62.0 設定
user.js
// 機能停止
user_pref("reader.parse-on-load.enabled", false); // リーダーモードを無効にする
user_pref("extensions.pocket.enabled", false); // Pocketを無効にする
// セキュリティ
user_pref("browser.urlbar.trimURLs", false); // (http|https)を表示する
user_pref("geo.enabled", false); // 位置情報通知機能を無効にする
user_pref("network.IDN_show_punycode", true); //「homograph attack(ホモグラフ攻撃)」を進化させた手法対策する
// 操作
user_pref("browser.tabs.closeWindowWithLastTab", false); // 最後のタブを閉じたときに終了しない
user_pref("general.smoothScroll.msdPhysics.enabled", true); // スムーズスクロールの加速度をアップするuserChrome.css
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
.tabbrowser-tab[selected]:not([pinned])[fadein] {
min-width: 250px !important;
}
#urlbar {
font-family: Consolas !important;
}userContent.css
@namespace url("http://www.w3.org/1999/xhtml");
@-moz-document url-prefix(view-source:) {
#viewsource {
font-family: Consolas !important;
}
}
IT人材サービス企業「Triplebyte」がとったWi-Fi問題
・オフィス内で混雑しているWi-Fi問題を解消するためにIT人材サービス企業「Triplebyte」がとった手法とは？ - GIGAZINE
◆04：「DFS機能」はオフにすべき
5GHz帯の電波を屋外で使用する際に問題となりがちなのが、気象レーダーに使われている電波との干渉です。この問題を避けるために、5GHz帯対応のWi-FiルーターにはDFS(Dynamic Frequency Selection)機能が搭載されています。DFS機能では、気象レーダーの電波との干渉を検知すると自動的に新しいチャンネルを探すモードに入り、通信が一時的にストップします。これを避けるためにTriplebyteはルーターのDFS機能をオフにし、そのかわりにレーダーと干渉する5GHz帯の52チャンネルから144チャンネルを使用不可にしておくべきとしています。
（注）
CloudflareのDNS(1.1.1.1/1.0.0.1)で引けないとこあるから使うのやめた。
「登記統一文字」とはなにか
私の記事によく出てくる「戸籍統一文字」の他に、同じ法務省関連で「登記統一文字」というものもあります。こちらに関しては詳細な資料が見当たらず、「たぶん登記情報システムで使われている文字であろう」ということ以上の情報がない状況でした。
ところが、平成20年度に経済産業省の委託で、財団法人日本規格協会、独立行政法人国立国語研究所、社団法人情報処理学会の三者が行った「汎用電子情報交換環境整備プログラム フェーズ2」の調査検討対象に「登記統一文字」があがっており、成り立ち等について成果報告書(注1)で詳しく解説されていることに先日気付きました。そこで今回はこの資料から「登記統一文字とは何か」についてまとめてみます。
・平成20年から切り替えが始まった法務省の新登記情報システムで使われている。(現行のシステム)
・同じ法務省の戸籍統一文字を拡張したもの。
・拡張部分は「登記固有文字」といい、各登記所で制作・保有している外字から成る。
・文字数は戸籍統一文字56040字＋登記固有文字12027字の合計68067字。
・戸籍統一文字コード(6桁)の先頭に00を追加して8桁に拡張する。
・登記固有文字は先頭01以降のコードとして追加されている。（推定）
・登記固有文字のうち1092文字は住基統一文字と共通している。
・登記固有文字の多くは異体字（誤字・俗字）である。
・登記固有文字には日本以外の地域で使われている漢字が含まれている。（漢字文化圏出身の在留者・居住者の氏名等）
・登記固有文字には符号・記号等、平仮名・片仮名・仮名合字、変体仮名などの「非漢字」が1697字含まれている。
つまり、登記情報システム用の「登記統一文字」は、「戸籍統一文字」の拡張で、登記固有文字12027字が加えられた合計68067字の文字のセット、ということです。これには他の文字セットには含まれていないと思われる文字が約1万字ほどあります。
関連：
・「⿺辶鳥」はISO/IEC 10646:2017に収録されたのか | yasuokaの日記 | スラド
・「⿺辶鳥」は“ナベ”の異体字なのか | yasuokaの日記 | スラド
・ISO/IEC 10646:2017に収録されていない『新潮日本語漢字辞典』の漢字 | yasuokaの日記 | スラド
CDNがパブリックDNSを使っても最寄りサーバーを判断できる理由
CDN（Content Delivery Network）サービスでは、ユーザーからのアクセスをどうやって最寄りのサーバーに振り分けているのだろうか。実は、DNSサーバーの名前解決を利用している。DNSサーバーは、問い合わせがあったドメイン名に対して、WebサーバーのIPアドレスを返す。この仕組みを使っているのだ。
例えば、ユーザーがWebブラウザーでドメイン名を含むURLを指定して、CDNを利用したWebサーバーにアクセスしようとしたとする。パソコンのTCP/IP処理プログラム（スタック）によって、名前解決を要求するパケットが送信され、契約するインターネット接続事業者（ISP）のDNSサーバーに要求パケットが届く。
ISPのDNSサーバーは通常、反復的問い合わせを行い、指定したURLのIPアドレスを回答できる権威DNSサーバーに名前解決の要求パケットを送る。権威DNSサーバーでは、要求パケットの送信元IPアドレス、つまりISPのDNSサーバーのIPアドレスを参照して最寄りの配信サーバーを判断し、そのIPアドレスを応答することになっている。
DNSサーバーを使って最寄りのサーバーを割り当てる
Webサーバーの権威DNSサーバーが、問い合わせしてきた送信元のIPアドレスやASなどから割り当て先を指定するテーブル情報を基に、最寄りの配信サーバーのIPアドレスを応答する。[画像のクリックで拡大表示]
このDNSを使った最寄りの配信サーバーへの誘導は、ISPのDNSサーバーを使わないケースでは正しく動作しない。例えば、パブリックDNSサービスの一つである「Google Public DNS」（IPアドレスは8.8.8.8）を使うと、DNSサーバーは台湾あるいは香港にあるため、海外にある配信サーバーを指定されてしまう恐れがある。そこでアカマイやクラウドフレア、Amazon CloudFrontといった多くのCDNサービスでは、「EDNS-Client-Subnet」（ECS）というDNSの拡張機能を使って対応している。
ECSに対応したパブリックDNSに要求パケットが届くと、元の要求パケットに記述された送信元IPアドレスの一部を埋め込んで別のDNSサーバーに要求パケットを送る。ECSに対応したCDNサービスでは、埋め込まれたIPアドレスの一部を使って、最適な「最寄りの配信サーバー」を指定する。
サービスごとに実装は異なる
ここまでCDNサービスの主な仕組みを解説したが、その実装方法はCDNサービス事業者によって大きく異なる。
世界最大の配信サーバーを抱えるアカマイは、日本国内だけでも145のネットワークに1万2000台のサーバーを設置している。これらのサーバーは、ISPのネットワーク内に設置していることが多く、よりユーザーに近い位置に配信サーバーが設置されている。
一方、アカマイ以外のCDNサービスのほとんどは、国内で東京と大阪といった大都市に配信サーバーをまとめて設置する。アカマイより全体の配信サーバーの台数は少ないが、大都市の配信サーバーの設置台数が多い。多くのユーザーで配信サーバーを効率的に使えるようになっている。
出典：日経NETWORK 2017年4月号 pp.54-55
記事は執筆時の情報に基づいており、現在では異なる場合があります。
Ubuntu標準コマンドでWiFiの状態を確認
$ nmcli dev wifi