There are so many reasons why the web would be awful with granular prefs (and I say this as someone who has wanted it for JS in particular). First off, it depe

There are so many reasons why the web would be awful with granular prefs (and I say this as someone who has wanted it for JS in particular). First off, it depends on how you define your block/allow list. Are they run-time prefs that can be toggled? There is UI/UX overhead, and related attack surface. If they are run-time prefs, are they loaded when the browser is run, or on each page load/content type load? Do you have to maintain a list of prefs by domain? etc, etc, etc. If they are compile time, then is it even worth doing for dramatic increase in complexity trying to support users with unusual configuration (e.g. THAT user that decides that preffing off JSON support is a good idea.) How granular do you allow user prefs on this, and how do you account for the fact that a user may pref off an api/feature that you use as a part of exploit mitigation? Do you want to log entries that are pref'd off so that users know what is making their favorite app fail? What are the abuse cases for pref'd features? How much attack surface is introduced by allowing pref'ing of features? Does doing this actually contribute to usability on the web, or will it simply lead to a proliferation of "Please ensure that all features are pref'd on" pages, similar to the Javascript pages you often see when browsing without javascript.