I'm sorry, but I don't understand the argument you're making here. I've already explained that we plan to provide a portable mechanism for private and localhost opt in. It's just not going to be the mechanism you propose, since that mechanism doesn't address the vulnerabilities that we're concerned about.

To reiterate the issues with your proposal: Public DNS pointing to private/localhost is in fact a component of many of the attacks we're concerned about. HTTPS on localhost doesn't do anything because the transport is already secure (which should be simplified in a future change in Chrome's content handling). And given that the major concern is weak/permissive servers, we can't rely on the WS(S) server implicitly protecting itself by enforcing the origin header.