アカウント名:
パスワード:
検閲フレンドリー規格をつくって、標準では無効、特定の国では標準で有効みたいな
あとは、企業向けの検閲フレンドリーな規格もあるほうがいい企業内端末のアクセス監視が出来ない
もしかしたらSigned HTTP Exchangesでそれに近いことができるかもしれない。エンド2エンドの暗号化通信は諦めるが、配信元のオリジナルから改竄されていない保証はあるという状態を実現させる仕組みなので。
SXG（Signed HTTP Exchanges）始めました - Yahoo! JAPAN Tech Blog [yahoo.co.jp]
SXGはHTTPリクエスト・レスポンス丸ごとにデジタル署名したファイルを配信するというもの。ウェブブラウザは、これをどういう経路で（たとえば他ドメインのCDNからの配信で）受信しても、署名をしたドメインのコンテンツとして扱う（たとえばアドレスバーとか）。
SXGのダウンロードにあたって、当局の息がかかったサーバーを通すとかHTTPで通信することとかを強制する仕掛けを作れれば、「httpsのURLのコンテンツだけど、中身は検閲あり（ダメなものはダウンロード丸ごと禁止される）」が実現できるだろう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
むしろ検閲フレンドリーなSSL/TLS規格をつくったほうがいいのでは？ (スコア:0)
検閲フレンドリー規格をつくって、標準では無効、
特定の国では標準で有効みたいな
あとは、企業向けの検閲フレンドリーな規格もあるほうがいい
企業内端末のアクセス監視が出来ない
Re:むしろ検閲フレンドリーなSSL/TLS規格をつくったほうがいいのでは？ (スコア:0)
もしかしたらSigned HTTP Exchangesでそれに近いことができるかもしれない。エンド2エンドの暗号化通信は諦めるが、配信元のオリジナルから改竄されていない保証はあるという状態を実現させる仕組みなので。
SXG（Signed HTTP Exchanges）始めました - Yahoo! JAPAN Tech Blog [yahoo.co.jp]
SXGはHTTPリクエスト・レスポンス丸ごとにデジタル署名したファイルを配信するというもの。ウェブブラウザは、これをどういう経路で（たとえば他ドメインのCDNからの配信で）受信しても、署名をしたドメインのコンテンツとして扱う（たとえばアドレスバーとか）。
SXGのダウンロードにあたって、当局の息がかかったサーバーを通すとかHTTPで通信することとかを強制する仕掛けを作れれば、「httpsのURLのコンテンツだけど、中身は検閲あり（ダメなものはダウンロード丸ごと禁止される）」が実現できるだろう。