[Bug 10068] Suggest making noscript obsolete but conforming

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10068





--- Comment #45 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>  2010-08-23 22:20:24 ---
(In reply to comment #44)
> > > <noscript><meta http-equiv=refresh content="0; URL=/home.php?_fb_noscript=1"
> > > /></noscript>
> > 
> > Adam, would you mind joining the dots for this one? I can see what this does,
> > but what is it for and how is "noscript" helping here?
> 
> <noscript> limits the meta refresh to only those situations when script is
> disabled.

Obviously. But what actual problem does this solve?

> > http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv
> > 
> > But even if it were valid, how does "noscript" help here? Shouldn't
> > "X-Frame-Options" always be sent as a real HTTP header?
> >   
> > http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
> 
> That would apply the directive unconditionally.  The problem Facebook is
> solving here is that they have a script-based clickjacking defense that seems
> to work for them, but they want to be protected even if script is disabled. 
> Consequently, they wish to apply the X-Frame-Options directive only when script
> is disabled, hence the use of <noscript>.

The Microsoft blog post I cited says: "Send the content as an HTTP Header – the
directive is ignored if specified in a META tag". *If* that's accurate (I
haven't tested), then Facebook's directive does not work. (I wouldn't be
surprised by error in either direction.)

But - assuming for the sake of discussion it *does* work - is the purpose of
attempting to limit "X-Frame-Options" to script-less scenarios to enable the
content to be iframed when JS *is* enabled? Are they trying to balance
integrations options with security concerns or what? Is the loss of robustness
acceptable with respect to end-user security, as I've suggested it might be in
the case of tracking?

> All this talk of "progressive enhancement using JavaScript" ignore the actual
> problems folks use <noscript> to solve.

I think it's a reaction to the fact that people often use "noscript" to solve
problems badly that progressive enhancement solves better. I've tried to
explain how the use of "noscript" for tracking purposes might solve that class
of problems better (albeit still with a tradeoff), but without context it's
hard to know how well your examples solve whatever problems they are trying to
solve: a usage example is not the same as a use case.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 23 August 2010 22:20:27 UTC