Re: Issue 100 Zero-Edits Counter Proposal

On Tue, Apr 13, 2010 at 6:54 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> But your answer also demonstrates the problem:
>
> "Note: I'm not sure how many, if any, of these additional characters
> are necessary to escape for  security purposes, and how many just need
> to be escaped to ensure  adequate display of the content."
>
> If you don't know, a member of the team designing the next version of
> HTML, including XHTML, how can we ask the average developer to use
> this attribute, correctly?

Why should I know?  I'm fundamentally a web author, contributing to
this group for the purpose of making my job easier.  I'm not part of
any "team", any more so than the other thousand or people subscribed
to the HTMLWG or WHATWG lists.  I now happen to represent a browser
developer as well, but that doesn't change my level of knowledge.

XML is complicated for silly reasons.  Shrug.  Not my fault, or
problem.  I write HTML, and care about HTML.  I *am* an average
developer.


> I think it would be better to avoid encouraging people to add in "You
> need to use a browser that can do this", as much as possible.

If the alternative is "Your browser is now being pwned by a hacker's
carefully-constructed attack inserted into a seemingly-innocuous
comment", shrug.  Seems like a better alternative.  Killing a page
because it can't be displayed properly is bad.  Killing a page because
it's unsafe to show it is acceptable.


> I believe the problems inherent with escaping data: urls are also the
> same problems that can happen with srcdoc. At least with data: urls we
> won't be introducing this level of cruft into attributes.

I spent that section explaining precisely why the statement you just
made is wrong.  @srcdoc's escaping requirements are fundamentally
simpler than those of data: urls, with only a single character needing
to be escaped for security reasons, and it fails very obviously and
quickly if you accidentally forget to escape that character.

I am not able rightly to apprehend the kind of confusion of ideas that
could provoke someone to think that data: urls are any less "markup in
attributes" than @srcdoc is.


> No, it is actually the strongest argument of all.
>
> We should not be adding new elements or attributes to this
> specification unless there is a strong and demonstrated need, and
> demand, from the community to which it is targeted. I asked Ian the
> use case for this new attribute and he specifically said weblog
> comments, and gave no other use case.
>
> I brought in an _expert_ on weblogging and asked him about this form
> of security. As he said, as exists as state-of-the-art, we have
> superior options today. Superior options that not only prevent the one
> form of exploit supposedly addressed with srcdoc, but many other forms
> as well. We, as a group, should never recommend an inferior solution,
> particularly as it relates to security.
>
> We should never incorporate anything into the spec that is not only
> inferior to what exists now, but must, because of the nature of HTML
> release cycles, become increasingly inferior, perhaps even harmful, in
> the future.
>
> We can't incorporate every last aspect of the web into HTML. We have
> to leave the pieces of the web that are best managed by other
> technologies to those technologies. To do otherwise is to make of HTML
> an anvil that holds us back, rather than a tool that helps us move
> forward.

Then file a bug against @sandbox itself, and argue for the change or
removal of @sandbox.  You are arguing that the sandbox security model
itself is inadequate protection, and we shouldn't offer it to authors.
 If @sandbox disappears, @srcdoc becomes irrelevant and will disappear
as well.  @srcdoc is simply a way for authors to push content into the
sandbox without incurring a network request.  You can possibly argue
that avoiding the network request isn't important, or that there are
better ways to avoid the network request, but you cannot validly argue
that the idea of sandboxing in general is wrong in a change proposal
that doesn't suggest any change to sandboxing.

The "strongest argument" in your Change Proposal is completely
irrelevant to the matter at hand.  It may be useful in a different
bug, concerning the sandbox security model directly.  But it is
meaningless in the current Issue we are discussing.

~TJ

Received on Tuesday, 13 April 2010 15:46:42 UTC