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.
Mad File Format Science 
What ever happened to .SIT?
With the increasing use of ZIP compression on the Macintosh, the Stuffit or .SIT format has fallen into relative obscurity. But not only is it still around, its publishers claim it’s “the ultimate in compression.” Five to ten years ago, lots of computer products were promoted as “the ultimate.” But when the next revision is the new “ultimate,” and so is the one after that, the claim starts to look ridiculous, and most advertisers have dropped it.
Stuffit’s compression is, according to most studies, about as good as competing technologies. It has no claim on being “the ultimate.” Its ad in the MacConnection catalogue says that “Stuffit Deluxe(R) 2009 can compress files up to 98% of their original size.” This is a nicely ambiguous claim; does that mean that the compressed file is reduced by 98%, or that it’s 98% of its original size? The latter isn’t hard to achieve at all, and hardly worth bragging about. But it’s extremely rare that Stuffit, or any other compression, can reduce a file to 2% of its original size. Perhaps a file of all 1’s would get 98% reduction, but that’s seldom useful.
Stuffit once had the advantage of recognizing the two-fork file format of the Macintosh Classic OS. But now that virtually everyone has gone to OS X, which doesn’t use dual file forks, it’s just one more compression format.
Comments Off on What ever happened to .SIT?
Posted in commentary
Tagged compression