On Sun, 28 Sep 2008, Robert O'Callahan wrote:
I'm not sure what you're talking about here. I'm specifically NOT talking
about Content-Restrictions or Site-Security-Policies or any other policies
for controlling what a page may do once it has loaded.
I'm expressing approval for your option 1,
"X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes", preferably
generalized to "X-I-Do-Not-Want-To-Be-Loaded-Across-Domains: yes" so
that it can be used for scripts and images too.
Well, OK, but that gets us on a slippery slope ;-) If it is just for
IFRAMEs, then it does not reduce complexity - it increases it, because we
already have way too many security-related headers (MSIE8 has
"Content-Type-And-I-Really-Mean-It-So-Do-Not-Second-Guess", headers to
control XSS filters, P3P policies, etc; other browsers are getting
cross-domain XMLHttpRequest headers; there are some more examples to
find), and we are adding a yet another header with a name and syntax that
probably would not add up to a coherent picture, and costs quite a few
bytes for high-traffic sites.
If we, on the other hand, do the "preferred generalization", as you note,
then the next reasonable step would be to integrate all these security
headers into a single, sane syntax that converses space, resources, and
follows common rules.
Now consider that "I-Do-Not-Want-To-Be-Loaded-Across-Domains" is also
inherently incompatible with mashups, content separation, gadgets, etc,
and there is a very vocal group of proponents and promotors for these
technologies (which is why browser vendors are implementing cross-domain
XMLHttpRequest to begin with). So we would probably rather want to say
"I-Want-To-Be-Loaded-Only-By: <list_of_domains>". This still leaves some
attacks (I might want my gadget to be embedded anywhere, just without
being clobbered, which is something we averted our eyes from here), but
let's say for a moment that it's good enough.
If we do that, then we are not far from the (IMO half-baked) site security
policy concept. Some other person then adds several extra checks to
prevent XSRF on top of this, and you have a system indistinguishable from
SSP ;-).
Which is not to say much, just explaining why I made the leap. There would
probably be a temptation to come up with a coherent and unified design,
which may result in some bloat. Or maybe not.
So what? The same goes for all your options --- slow browser migration
delays the uptake of any client-side solution.
Not really; minor versions usually have better uptake rates, thanks to
auto-updates, etc (it's far from perfect, but it's nowhere near the
estimated, if I recall published stats correctly, 20% of people still
using MSIE6 after a year of MSIE7?) - not to mention, not having a change
shelved until the next major version of a browser 2-4 years from now,
means that even with poor uptake, it would be broadly available sooner.
Complex changes often get deferred, so any feature that is easy to smuggle
in a minor version is probably better than a feature that needs to wait
for MSIE 9, Firefox 4 (now, #3 is still considerably cheaper than a
fully-blown SSP).
Cheers,
/mz
