This past weekend, at a singing gathering, someone was trying to remember the words to “Flow Gently, Sweet Afton.” Trying to help, I did a search on my MacBook and found lots of matches. When I clicked on the first likely-looking one, it started playing the song, to my great embarrassment. This was in spite of the fact that I use NoScript to disable JavaScript, Java, and Flash on unfamiliar sites. (Here’s the offending page; it seems harmless in other respects, but I’ve added rel="nofollow"
to the link anyway, so as not to give it any aid with search engines.)
The page uses a non-standard (in HTML 4 and earlier) but widely supported tag called embed
. With the parameter autostart=true
, this tag will immediately start up a plugin, which could be a sound or audio file or anything else, depending on what plugins are installed with your browser. The only way to prevent this with NoScript is to disable plugins across the board.
In HTML 5, the embed
tag gains official status but there’s a standard way to disable the functionality:
When the sandboxed plugins browsing context flag is set on the browsing context for which the embed element’s document is the active document, then the user agent must render the embed element in a manner that conveys that the plugin was disabled. The user agent may offer the user the option to override the sandbox and instantiate the plugin anyway; if the user invokes such an option, the user agent must act as if the sandboxed plugins browsing context flag was not set for the purposes of this element.
A sandbox can be set for a frame, window, or tab. For a frame, it can be specified in the HTML, letting a page incorporate not fully trusted HTML from another site. The window or tab sandbox settings are evidently intended to be controlled by user preferences.
There’s no longer an autostart
parameter. I think this means that the behavior is whatever the plugin creator wants; it could start up immediately or could provide a user interface with start, stop, and pause controls.
If future browsers let users control the plugin sandbox through preferences, that will mean one less way that web page authors can get around the user’s desire not to be annoyed.
Like this:
Like Loading...
Related
The most annoying HTML tag
This past weekend, at a singing gathering, someone was trying to remember the words to “Flow Gently, Sweet Afton.” Trying to help, I did a search on my MacBook and found lots of matches. When I clicked on the first likely-looking one, it started playing the song, to my great embarrassment. This was in spite of the fact that I use NoScript to disable JavaScript, Java, and Flash on unfamiliar sites. (Here’s the offending page; it seems harmless in other respects, but I’ve added
rel="nofollow"
to the link anyway, so as not to give it any aid with search engines.)The page uses a non-standard (in HTML 4 and earlier) but widely supported tag called
embed
. With the parameterautostart=true
, this tag will immediately start up a plugin, which could be a sound or audio file or anything else, depending on what plugins are installed with your browser. The only way to prevent this with NoScript is to disable plugins across the board.In HTML 5, the
embed
tag gains official status but there’s a standard way to disable the functionality:A sandbox can be set for a frame, window, or tab. For a frame, it can be specified in the HTML, letting a page incorporate not fully trusted HTML from another site. The window or tab sandbox settings are evidently intended to be controlled by user preferences.
There’s no longer an
autostart
parameter. I think this means that the behavior is whatever the plugin creator wants; it could start up immediately or could provide a user interface with start, stop, and pause controls.If future browsers let users control the plugin sandbox through preferences, that will mean one less way that web page authors can get around the user’s desire not to be annoyed.
Share this:
Like this:
Related