You may want to set up arbitrary criteria. For example, something I would like to do is enable web fonts for SVG, but not for HTML. Prompts do help, but the pr

You may want to set up arbitrary criteria. For example, something I would like to do is enable web fonts for SVG, but not for HTML. Prompts do help, but the prompt should allow the user to allow or block once or always, and to override settings too (e.g. for location, the user can optionally specify a location to use, or specify a command-line of a program that provides the location; for camera, the user can specify the path to the device or to a picture or video file, or a command-line of a program that will produce the picture). The user can then specify whether or not to always make this selection in the future, and in what scope. If the site uses TLS, or is a local file which has been digitally signed, then the user can optionally specify certificate pinning too, in which case the automatic selection will be ignored if the certificate does not match. I also have other ideas, about meta-CSS, presentation mode, table of contents window, animation skipping, capability of loading animated GIF and PNG files as videos (so that you can rewind and pause it), better keyboard controls, save form data to local files, regular expression search, full cookie editor, SQL access to HTML tables, Xaw-style scrollbars, relative location bar, ARIA view, etc. Most of this is configured and/or activated only by the end user, not by the document. Although, some are capable in the document too, such as, a HTML document with a <video> referencing a GIF or PNG will work; such a file can be loaded with <img> or <video> and either way would work. No "do not track" setting is needed. My idea is the user could set up request headers arbitrarily, as well as overriding response headers (including some "protected" ones, which are stripped if received from a remote site, so are only effective if set up by the user). For example, to enable "do not track", you can add the rule which adds the request header "DNT:1" with the criteria specified as "always". I would also ensure that all timing APIs can be spoofed (including the JavaScript core Date object; in my opinion this is an I/O function so it shouldn't belong in the core). This is probably useful for testing, as well as for the end user to get rid of annoyances too.