I should say then that OSes should be designed so that applications can take on security responsibilities. Indeed my proposed architecture makes the secure application the easiest to write, and is by default not a burden on the application. Only applications that need to communicate with other agents need express and implement a security policy.

Today (2005, June 7) I read about a browser mis-feature in the Mozilla line of browsers. Suppose that the browser is displaying two windows. In A there are frames and one of those frames is named thus <FRAME name=kickMe ... >. In B there is a link <a href=bogus.html target=fraRightFrame>click here</a>. If the link is clicked in window B then the frame in window A is replaced with content from bogus.html.

This can plausibly be exploited to cause harm, but this not the point here. The point is that the producer of window A was not on control of his window, but instead was vulnerable to logic in a unrelated window. I suggest that the flaw is not in the browser but in the html specifications that allow the author of window A no way to specify the scope of the name “kickMe”. There are browsers where window A is not thus vulnerable, but they have a variety of behaviors that indicate ad-hoc policies in such cases.

Languages have limited the scope of identifiers mainly by requiring declarations within a hierarchical syntax. If the scope of the frame name were explicit the window author could not then be vague about the scope. The author is unlikely to produce a page that any other page can disfigure. That might be difficult or impossible.

I suppose there is no one charged with fixing bugs in html specs and I suppose that the Mozilla folks will try to figure out how other browsers hobble this behavior and then do likewise. They will probably not document their decision. Where would the document it? This is not a good path towards security.