W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: Issue 100 Zero-Edits Counter Proposal

From: Shelley Powers <shelley.just@gmail.com>
Date: Tue, 13 Apr 2010 12:05:09 -0500
Message-ID: <s2p643cc0271004131005yd9b071e1x6c135e242543b94b@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: public-html@w3.org
On Tue, Apr 13, 2010 at 10:45 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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

I would rather let others determine what is or is not a strong
argument. You can express your opinion, of course, but it's an
opinion. In my opinion, srcdoc is one of the ugliest things I've seen
in markup, and I've seen some pretty ugly markup.

Julian has hit on other potential problems, I'm focused on the one and
only use case that Ian provided. I believe I effectively demonstrated
that there isn't interest in this capability for weblog comments in
the weblogging community--with users or developers.

Will be interested in hearing other views, too.

Received on Tuesday, 13 April 2010 17:05:43 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:01 UTC