- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 25 Jan 2010 09:54:14 -0600
- To: Shelley Powers <shelley.just@gmail.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, Lars Gunther <gunther@keryx.se>, "public-html@w3.org WG" <public-html@w3.org>
On Mon, Jan 25, 2010 at 9:28 AM, Shelley Powers <shelley.just@gmail.com> wrote: > When Ian proposed this change, he specifically focused it at weblog > comments. I know comments, and the problems comment systems have. And in > point of fact, there is nothing in Ian's example or discussion that relates > to comment security. > So I am trying to understand the purpose of this change, and who Ian > perceives to be the customer for this change. These are appropriate > questions to ask: we can not determine the technical merit of a solution > unless we have an understanding of all the particulars. > Adam now has stated this change wasn't to do with comments, but ads. Or not > only to do with comments, but also to do with ads. That is an entirely > different thing: different customers, different uses, different concerns, > different technical challenges. I'm hoping he (Adam) will link the relevant > discussions from the WhatWG group here, so we can then look at Ian's > solution in context of how it is to be used, it's customers, their > expectations, and the technical challenges. Adam stated that one major use-case of @sandbox was advertising. Many advertisements are served from completely untrusted and uncontrolled sources, so @sandbox is useful to limit what it can possibly do. Similarly, comments are generally untrusted, though the site owner typically has control over them. @sandbox is at thus at least possibly relevant. Not all issues relevant to comments will be addressed with @sandbox. Some are small enough that leaving it to server-side filtering is appropriate. We want to focus mainly on things that server-side filtering *cannot* replicate. Right now, your choices are either let comments have full scripting ability, or attempt to filter out scripts entirely (and hope you got it right, and nobody's figured out a new way to slip them past your filter). The former is begging for XSS attacks, and the latter is also vulnerable to them - it's a constant arms race. @sandbox lets you have much more fine-grained control over scripting, and it's an absolute level of control - the browser knows precisely when a script is attempting to run, precisely what the origins are of the pages the script is trying to affect, etc. You've brought up some things that an author might reasonably want to prevent in a comment that aren't currently covered by @sandbox. It's possible that this might be a reasonable addition. We can discuss these specifically. For example, <img> in comments, or <audio autoplay>. ~TJ
Received on Monday, 25 January 2010 15:55:07 UTC