ニコニコ実況の BS 民は解放された感じ

f:id:asannou:20201215052628p:plain

Flash Player サポート終了で、従来の ニコニコ実況 はクローズし、ニコニコ生放送 に移行されるようです。

blog.nicovideo.jp

継続されるのは、地上波 8 局と BS11 のみで、それ以外のチャンネルおよびラジオは提供終了とのことです。すでに、生放送の枠が用意されていました。

ch.nicovideo.jp ch.nicovideo.jp ch.nicovideo.jp ch.nicovideo.jp ch.nicovideo.jp ch.nicovideo.jp ch.nicovideo.jp ch.nicovideo.jp ch.nicovideo.jp

従来のニコニコ実況用のツールは使用できなくなるため、生放送のコメントのプロトコルニコニコ実況に変換するプロキシサーバを作りました。現状ではリアルタイムの閲覧機能のみ対応(過去ログと投稿は未対応)しています。

github.com

以下のいずれかの設定で、ニコニコ実況へのアクセスが、プロキシサーバのテスト環境に向けられるようになります。

  • DNS サーバとして 3.113.121.119 を設定
  • hosts ファイルに次の行を追加
59.106.13.23 jk.nicovideo.jp

下記のツールで動作を確認しました。

生放送が開始された後、これらのツールを使用してコメントを閲覧できるはずです。もしかすると torne でも表示できるかもしれません。

追加機能として、公式、非公式にかかわらず、特定のタグが付けられた生放送のコメントを、対応するチャンネルに流れるようにしました。

つまり、"ニコニコ実況" タグと "jk101" タグの両方が付けられた生放送のコメントが NHKBS-1 として流れます。これを利用することで、公式に提供されていないチャンネルで実況するための生放送枠を作成できます。チャンネルについては http://3.113.121.119/api/v2/getchannels の video タグを参考にしてください。

前述の DNS サーバか hosts ファイルを設定した状態で、各チャンネルのページ(テレ玉であれば http://jk.nicovideo.jp/watch/jk10)にアクセスすると、そのチャンネルに今つながっている生放送へのリンク一覧が表示されます。したがって、リンク先の生放送に投稿すれば、プロキシサーバにもコメントが反映されるはずです。

現在、試験的に、テレ玉 (jk10) に "niconews24" タグ、tvk (jk11) に "ウェザーニュースLiVE" タグ、チバテレビ (jk12) に "北朝鮮" "朝鮮中央テレビ" タグが付けられた生放送のコメントを流しています。 生放送が開始され、正常に機能しているようなので、停止しました。

NicoJK - Rutice からフォークされた GitHub - xtne6f/NicoJK: TVTestのニコニコ実況プラグイン #Releaseに非公式バイナリRelease dev-201218 · xtne6f/NicoJK · GitHub では、NicoJK.ini ファイルを以下のように修正することで、前述の DNS サーバ等の設定をしなくても、プロキシに接続できるようになっていました。

; サーバを指定する (デフォルトは↓)
; customJKHostName=jk.nicovideo.jp
customJKHostName=3.113.121.119

; サーバが"jk.nicovideo.jp"でないときにもクッキーを送信するか (デフォルトは 0 = しない)
; # クロスサイトへの送信となる可能性があるので変更は慎重に
sendCookieToCustomJKHost=0

さらに、クッキーの送信が無効になるため、不要な情報を送らずに利用することが可能です。 最新バージョンでは プロキシなしで使用可能 です。

UserCSP

  • 目を醒ませ僕らのなんちゃら〜


  • CSP 導入準備のため、実際に Content-Security-Policy ヘッダが出力されたときに、ウェブブラウザがどのような挙動になるかを調べていた
    • ウェブサーバの設定を変えながら試行錯誤するのは、いかにも面倒くさい
  • ブラウザ側で HTTP レスポンスに含まれるヘッダを変更できないか
    • できるが、標準機能ではない
  • レスポンスに任意のヘッダを追加したり変更できる、ブラウザのアドオンや拡張機能が存在する
    • 単純な機能なので、安心のために自作する




  • 拡張機能の上記設定画面で、Content-Security-Policy ヘッダと Content-Security-Policy-Report-Only ヘッダを設定すると、出力されるようになる
    • Content-Security-Policy-Report-Only: default-src 'self' で はてな にアクセスすると、ウェブコンソールに、設定されたポリシーに従ってリソースを拒否することがレポートされる
The Content Security Policy 'default-src 'self'' was delivered in report-only mode, but does not specify a 'report-uri'; the policy will have no effect. Please either add a 'report-uri' directive, or deliver the policy via the 'Content-Security-Policy' header.
Navigated to http://www.hatena.ne.jp/
(index):1 [Report Only] Refused to load the script 'https://cdn.ad-hatena.com/js/river.js' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
(index):27 [Report Only] Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-xYOawB5vZJsporgKCEyYks2LJ5r/svEP1UgyihxaEAg='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.
(index):30 [Report Only] Refused to load the script 'http://www.googletagmanager.com/gtm.js?id=GTM-WPVF7X' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
(index):39 [Report Only] Refused to load the image 'http://n.hatena.ne.jp/my/profile/image?size=16&type=icon' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.
...
  • Content-Security-Policy-Report-Only ではなく Content-Security-Policy: default-src 'self' とすると、レポートだけではなく、本当にいくつかのリソースが拒否され、ページが機能不全になった
  • ページが完全に機能し、かつ、ある程度セキュアな Content-Security-Policy は下記のようなものだろうか(見やすさのため適宜改行)
script-src 'unsafe-inline' 'unsafe-eval'
http://*.hatena.ne.jp/
http://img.ak.impact-ad.jp/
http://pagead2.googlesyndication.com/
http://platform.twitter.com/widgets.js
http://static.criteo.net/js/ld/publishertag.prebid.js
http://www.googletagmanager.com/gtm.js
http://www.googletagservices.com/activeview/js/current/osd.js
http://www.hatena.com/
http://y.one.impact-ad.jp/imp
https://adservice.google.co.jp/adsid/integrator.js
https://adservice.google.com/adsid/integrator.js
https://c.amazon-adsystem.com/aax2/apstag.js
https://cdn.ad-hatena.com/
https://*.st-hatena.com/
https://platform.twitter.com/js/
https://securepubads.g.doubleclick.net/gpt/
https://static.xx.fbcdn.net/rsrc.php/
https://tpc.googlesyndication.com/
https://www.googletagservices.com/activeview/js/current/osd_listener.js
https://www.googletagservices.com/tag/js/gpt.js
stats.g.doubleclick.net/dc.js
www.google-analytics.com/analytics.js
  • だが、ユーザとしては、これらすべてのリソースを信頼できるか判断するのは難しい
    • ページ機能の一部が失われるが、信頼できそうなリソースのみを許可するポリシーを考える
script-src 'unsafe-inline' 'unsafe-eval'
http://*.hatena.ne.jp/
http://www.hatena.com/
https://cdn.ad-hatena.com/
https://*.st-hatena.com/
http://www.googletagmanager.com/gtm.js
  • こうしておけば、マルバタイジングを始めとした何者かの侵略を、食い止めることができる
    • あらゆるページのために、このようなポリシーを作成するのは現実的ではないが
  • ウェブブラウザには、ページに埋め込まれたスタイルシートスクリプトを、ユーザが任意に上書きできる手段がある
    • それらはユーザスタイルシートやユーザスクリプトと呼ばれ、平成中期によく利用されていた
    • 同様に、ユーザの立場でページに独自のポリシーを定義できても、CSP の目的からそれほど離れないと思う