あと私は実装してないので実際どうなのか知らんけど、永続化が拒否されていたら SecurityError 例外が飛ぶようだし、であればやっぱりこの例外を想定/対処していないｳｪｯﾋﾞページ側が甘いという話な気はする
あと私は実装してないので実際どうなのか知らんけど、永続化が拒否されていたら SecurityError 例外が飛ぶようだし、であればやっぱりこの例外を想定/対処していないｳｪｯﾋﾞページ側が甘いという話な気はする
LocalStorageが無効化されたときの挙動について、Webサイト側だけの責に帰すのは無理があるという話を前にもしたのですが、忘れられてるようなので改めて貼りますね
https://m.upsilo.net/users/upsilon/statuses/103300681756592554
localStorageのクソ挙動に関する資料その1:
a brief history of detecting local storage
https://gist.github.com/paulirish/5558557
localStorageのクソ挙動に関する資料その2:
「「この変更は互換性に関する懸念から Firefox 70 で取り消されました。window.localStorage は再度 SecurityError を投げるようになります」」
window.localStorage がプライバシー設定によってブロックされた場合に SecurityError を投げなくなりました | Firefox サイト互換性情報 https://www.fxsitecompat.dev/ja/docs/2019/window-localstorage-no-longer-throws-securityerror-when-blocked-due-to-privacy-settings/
localStorageのクソ挙動に関する資料その3(終):
「localStorage がサポート済みかつ使用可能であるかを検出する関数を、以下に示します」
Web Storage API を使用する - Web API | MDN
https://developer.mozilla.org/ja/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API#Feature-detecting_localStorage
ちなみに、Cookieを含め小容量の永続化ストレージについて全て閲覧者の許可制にすると何が起こるかと言いますと、URLのクエリに ;jsessionid= が復活します
ユーザーに都度許可を求めることでかえって不幸になる例は往々にして存在し、例えば動画の自動再生を不許可にするユーザーが増えたことによって代替として連続したPNG画像をJavaScriptでコマ送り表示する実装が誕生してしまい、フレーム間圧縮が効くH.264動画を普通に再生するよりも結果として通信量が増えてしまった事例がある
ちなみに JSESSIONID= や PHPSESSID= をURLクエリに含まることの問題点として、セッションIDの意味を知らないユーザーが公の場所にセッションIDを含んだURLを貼り付けてしまうという懸念がある。これはCookie導入以前の日本の携帯電話で度々問題になっていた