On setting, if the
valueAsNumberhttp://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-valueasnumber
attribute
does not apply, as defined for the
On Mon, Jan 25, 2010 at 9:55 AM, TAMURA, Kent tk...@chromium.org wrote:
It seems the current spec doesn't define behavior in a case of setting NaN
or Infinitiy to HTMLInputElement::valueAsNumber.
http://whatwg.org/html5#float-nan : Except where otherwise specified,
if an IDL attribute that is a
On Mon, Jan 25, 2010 at 19:10, Philip Taylor
excors+wha...@gmail.comexcors%2bwha...@gmail.com
wrote:
On Mon, Jan 25, 2010 at 9:55 AM, TAMURA, Kent tk...@chromium.org wrote:
It seems the current spec doesn't define behavior in a case of setting
NaN
or Infinitiy to
On Sat, 23 Jan 2010 11:29:35 +0100, wha...@whatwg.org wrote:
Author: ianh
Date: 2010-01-23 02:29:33 -0800 (Sat, 23 Jan 2010)
New Revision: 4621
Modified:
complete.html
index
source
Log:
[e] (0) Clarify when the drag-and-drop steps run.
Modified: source
On Mon, Jan 25, 2010 at 1:29 AM, Adam Barth wha...@adambarth.com wrote:
That depends what information the attacker encodes in the host name.
Recall that we're imaging the attacker gets to run JavaScript within
the sandbox
If we're assuming that, then yes, it's probably hopeless. But are we
On Mon, Jan 25, 2010 at 5:39 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Mon, Jan 25, 2010 at 1:29 AM, Adam Barth wha...@adambarth.com wrote:
That depends what information the attacker encodes in the host name.
Recall that we're imaging the attacker gets to run JavaScript within
the
I've introduced srcdoc= to largely handle this. There is an example in
the spec showing how it can be used.
Yup, sounds good.
This has been proposed before. The concern is that many authors would be
likely to make mistakes in their selection of random tokens that would
lead to significant
The reason to use a MIME type here is to trick legacy browsers into
not rendering the response as HTML.
Legacy browsers probably will, anyway :-(
/mz
On Mon, Jan 25, 2010 at 1:51 PM, Michal Zalewski lcam...@coredump.cx wrote:
This has been proposed before. The concern is that many authors would be
likely to make mistakes in their selection of random tokens that would
lead to significant flaws in the deployment of the feature.
srcdoc= is
Michal Zalewski brings up several good suggestions for improvements to
@sandbox that would make it more useful for embedding general
untrusted user content. As well, Shelley Powers brought up a few
common uses that I think could fit into this model and prove useful.
1) Prevent cross-origin
On Sat, Jan 23, 2010 at 2:30 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 17 Aug 2009, Jian Li wrote:
In order to download the attachment from an Internet mail application,
the user will have to click the attachment link and a save dialog will
pop up to let the user select the
On Sun, Jan 24, 2010 at 2:52 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Dec 2009, Michal Zalewski wrote:
1) IFRAME semantics make it exceedingly cumbersome to sandbox short
snippets of text, and this task is perhaps the most common and pressing
XSS-related challenge. Unless the document
On Mon, Jan 25, 2010 at 5:45 PM, Alex Russell slightly...@google.com wrote:
Sorry I'm late to this discussion. Would like to add my objection to
using attribute string escaping as a security feature in any way. I
strongly prefer required nonces attached to opening and closing of
sections.
Do
On Sat, Jan 23, 2010 at 2:30 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 12 Jan 2010, Michael Davidson wrote:
The table in section 7.9.3 says that the DataTransfer object should be
empty for dragenter and dragover events.
Clearly this is not the case - the example in 7.9.1 shows that,
AFAICT, the objections fall into several buckets:
1.) Users might pick badly or may re-use nonces when they shouldn't.
2.) Escaping is believed to be more secure because it's likely to
break more often, raising developer awareness
3.) The fix to correct escaping problems is believed to be
On Thu, 10 Dec 2009, Michael A. Puls II wrote:
Also see https://bugzilla.mozilla.org/show_bug.cgi?id=90268#c68.
Should probably add a note in the spec that the css overflow and
position properties don't affect instantiation/destroying etc.
(might as well add visibility too).
16 matches
Mail list logo
