If you apply same-origin policy to images in HTML documents by default, then I fail to understand how it would be "fairly rare" for you to encounter a page that's a sea of broken images. For example, Wikipedia (upload.wikimedia.org), Wikia (nocookie.net), Google (gstatic.com), Yahoo! (yimg.com), and eBay (ebaystatic.com) all routinely host images on a separate domain from the HTML document, often to prevent repetition of the user's session cookie in the HTTP headers for each image request.

JavaScript retrieves the RSS or Atom feed from multiple sites that support CORS, parses it, and displays it. This way nothing gets necessarily leaked to the operator of the server on which the reader is hosted, neither the content of the feeds nor the password needed to retrieve each feed. Nor can web servers hosting feeds block the IP address of the server on which the reader is hosted for alleged excessive use.

Then I appear to have applied a definition of "local applications" with which you disagree, which fulfills Layne's Law of Debate. Please define "local applications" before the discussion can continue.

Please explain what you mean by this catchphrase.

Should an RSS reader with 12 feeds present 12 alerts? If not, what user interface do you recommend to make "the decision to allow this sort of behavior [to] be up to the user"?

The difference is that there is no "sandboxing of local applications" at all on the most popular desktop platforms.

Then could you list some things that are executable code and are relevant? These would be executable resources normally restricted by the same-origin policy.

"Executable"? I thought we were talking about CORS, which is intended for things like XML documents, JSON objects, and fonts, none of which are "executable". (Technically, TrueType fonts have interpreted hints, but that's an even more limited sandbox than any JavaScript environment, and renderers have the option to autohint outlines instead.)

If a web site has opted into CORS, it has opted into allowing other sites to include its (non-executable) resources into their sandboxes.

A "Cancel or Allow" pop-up for each domain that each page accesses could get tiring for the user.

Nor is an XML document or JSON object retrieved through a cross-domain request from a web site allowing CORS.

If a web application lacks an offline mode, then the developer is placing the burden not on the user's machine but on the user's (increasingly capped) last-mile Internet connection.

If a web application has a legitimate reason to access resources that are behind more than one domain, what's the non-poor way to design such a web application?

All "blocking external domains" does is cause web applications to show an error message: "The application could not start because either your web browser does not support cross-origin resource sharing or you have blocked external domains. To begin using this application, please upgrade to a web browser that supports cross-origin resource sharing or unblock external domains for this site." I will continue this discussion in replies to your other comment.

Show me a cleaner way without goto to handle cleanup in case a function fails without having to switch from C to C++ and include the C++ exception handling library.

In Firefox for Windows and Firefox for Ubuntu, I can middle-click "Reply to This" and get the plain old form that Slashdot used to use before it went all AJAXy. Other browsers may require right-clicking "Reply to This" and choosing "Open in New Tab".

Because IPv4 addresses are scarce, and because Internet Explorer for Windows XP and Android Browser on Android 2.x lack the "Server Name Indication" SSL extension required for name-based virtual hosting in HTTPS.

The APIs of IE 10, Firefox (unknown version), Chrome (unknown version), and Safari (unknown version) are far more similar than those of Windows, GNU/Linux, Mac OS X iOS, Android, and Windows Phone, and there's no $99 per platform per year certificate fee to sign your code either. In fact, the API of Chrome is identical to the native API of Chrome OS. You can circumvent misconfigured proxies by using HTTPS, something you should be doing anyway to protect users' credentials from Firesheep, provided that users don't have the root certificate of a corporate SSL MITM installed.

A single web page may already include components from a dozen origins, such as an <img> element whose src= attribute references an image from a CDN. How would you design a user interface to give the end user the power to cancel or allow every request made to a different origin without having it become as annoying as the Windows Vista behavior that made "Cancel or Allow" into a punchline?