[whatwg] HTMLInputElement::valueAsNumber and NaN Infinity
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 inputhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element element's typehttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type attribute's current state, then throw anINVALID_STATE_ERRhttp://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#invalid_state_err exception. Otherwise, if the valueAsDatehttp://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-valueasdate attribute applies, run the algorithm to convert a Date object to a stringhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-value-date-string defined for that state, passing it a Date object whose time value is the new value, and set the valuehttp://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-fe-value of the element to resulting string. Otherwise, run the algorithm to convert a number to a stringhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-value-number-string, as defined for that state, on the new value, and set the valuehttp://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-fe-value of the element to resulting string. It seems the current spec doesn't define behavior in a case of setting NaN or Infinitiy to HTMLInputElement::valueAsNumber. Because 'input.valueAsDate = null' makes the value empty, I think 'input.valueAsNumber = Number.NaN' also makes the value empty. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] HTMLInputElement::valueAsNumber and NaN Infinity
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 floating point number type (float) is assigned an Infinity or Not-a-Number (NaN) value, a NOT_SUPPORTED_ERR exception must be raised. This case seems to apply for valueAsNumber. -- Philip Taylor exc...@gmail.com
Re: [whatwg] HTMLInputElement::valueAsNumber and NaN Infinity
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 HTMLInputElement::valueAsNumber. http://whatwg.org/html5#float-nan : Except where otherwise specified, if an IDL attribute that is a floating point number type (float) is assigned an Infinity or Not-a-Number (NaN) value, a NOT_SUPPORTED_ERR exception must be raised. This case seems to apply for valueAsNumber. Oh, that's right. I overlooked it. Thanks! -- TAMURA Kent Software Engineer, Google
[whatwg] skipping timeupdate (was: Re: [html5] r4621 - [e] (0) Clarify when the drag-and-drop steps run.)
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 === --- source 2010-01-23 00:14:19 UTC (rev 4620) +++ source 2010-01-23 10:29:33 UTC (rev 4621) @@ -20949,7 +20949,7 @@ div class=example - p class=xxxexample for srcdoc here/p + p class=XXXexample for srcdoc here/p /div @@ -71486,27 +71486,33 @@ Initially, it has the value none. It is updated by the user agent as described in the steps below./p - pUser agents must, every 350ms (#xB1;200ms), perform the - following steps in sequence. (If the user agent is still performing - the previous iteration of the sequence when the next iteration - becomes due, the user agent must not execute the overdue iteration, - effectively skipping missed frames of the drag-and-drop - operation.)/p + pUser agents must, as soon as the drag operation is initiated and + every 350ms (#xB1;200ms) thereafter for as long as the drag + operation is ongoing, spanqueue a task/span to perform the + following steps in sequence:/p ol li -pFirst, the user agent must fire a code -title=event-dragdrag/code event at the spansource -node/span. If this event is canceled, the user agent must set -the spancurrent drag operation/span to none (no drag -operation)./p +pIf the user agent is still performing the previous iteration of +the sequence (if any) when the next iteration becomes due, the +user agent must not execute the overdue iteration, effectively +skipping missed frames of the drag-and-drop operation./p Should timeupdate also skip missed frames? (I think Firefox does as a consequence of skipping frames while script is running and firing timeupdate for each frame. Opera currently queues up the events, IIRC.) /li li +pThe user agent must fire a code title=event-dragdrag/code +event at the spansource node/span. If this event is canceled, +the user agent must set the spancurrent drag operation/span to +none (no drag operation)./p + + /li + + li + pNext, if the code title=event-dragdrag/code event was not canceled and the user has not ended the drag-and-drop operation, the user agent must check the state of the drag-and-drop ___ Commit-Watchers mailing list commit-watch...@lists.whatwg.org http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org -- Simon Pieters Opera Software
Re: [whatwg] some thoughts on sandboxed IFRAMEs
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 assuming that? The given use-case was webmail -- that would be expected to disable scripts in the sandbox, no? The point is that stopping exfiltration is a losing battle that we shouldn't bother to play. Even if scripting is disabled?
Re: [whatwg] some thoughts on sandboxed IFRAMEs
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 sandbox If we're assuming that, then yes, it's probably hopeless. But are we assuming that? The given use-case was webmail -- that would be expected to disable scripts in the sandbox, no? The point is that stopping exfiltration is a losing battle that we shouldn't bother to play. Even if scripting is disabled? Blocking exfiltration has a long history on the web. In fact, the first security model for the web, before the same-origin policy, was based on stopping exfiltration. Ultimately, Netscape gave up on that approach and tried the same-origin policy, which is what we're still using today. More recently, there have been some academic papers studying the idea of preventing exfiltration after XSS attacks, including some prototype implementations. None of the implementations I'm aware of have had their security claims stand up to close scrutiny. Of course, none of that means it would be impossible to add a security feature to the web based on blocking exfiltration. If that's something you're passionate about, I'd encourage you to build a prototype system by modifying one of the open source browsers. If you find a clever way of doing that, there are a number of folks in the academic would who would love to hear how. In particular, the Web 2.0 Security Privacy Workshop might be a good venue to share your findings: http://w2spconf.com/2010/ That venue is particularly inviting to papers written by non-academics. You can see some of the papers from previous years to get a feel for the style, etc. Adam
Re: [whatwg] some thoughts on sandboxed IFRAMEs
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 flaws in the deployment of the feature. srcdoc= is less prone to errors. Only and characters need to be escaped. If the character is not escaped, then a single character in the input will cause the comment to break. My counterargument, as stated later in the thread, is quite simple: the former *forces* you to implement a security mechanism, else the functionality will break. You can still use a bad token, but you are required to make the effort. In that regard, the comparison to XSRF is probably not valid; a vast majority of XSRF bugs occurs not because people pick poor tokens (in fact, that's really a majority), but because they don't use them at all. From that perspectiv, srcdoc=... is very similar to XSRF - people will mess it up simply by not thinking about the correct escaping. That said, I am not really arguing against srcdoc=...; I think it's an OK feature. My point is simply that I would love to see less fragmentation when it comes to XSS defenses and the granularity of security controls. The initial proposal of iframe sandboxes solved a very narrow use case, and other, unrelated designs started to spring up elsewhere. This wouldn't be bad by itself, but while the security controls on iframes were pretty great (with some tweaks, such as text/html-sandboxed), they would not be reflected in other APIs, which I thought is unfortunate. If we extend sandboxed iframes with srcdoc, seamless frames, text/html-sandboxed, and iframe rendering performance improvements, it actually becomes close to a comprehensive solution, and I am happy with this (other than a vague feeling that we just repurposed iframe to be some sort of a span ;-). I've introduced text/html-sandboxed for this purpose. Yup, I noticed. Looks great. It does make me wonder about two things, though: 1) Some other security mechanisms (CORS, anti-clickjacking controls, XSS filter controls) rely on separate HTTP headers instead. Is there a compelling reason not to follow that lead - or better yet, to unify all security headers to conserve space? 2) People may conceivably want to sandbox other document types (e.g., SVG, RSS, or other XML-based formats rendered natively, and offering scripting capabilities). Do we want to create -sandboxed MIME types for each? The header approach would fix this, too. 2.1) The ability to disable loading of external resources (images, scripts, etc) in the sandboxed document. The common usage scenario is when you do not want the displayed document to phone home for privacy reasons, for example in a web mail system. Good point. Should we make sandbox= disable off-origin network requests? That would be great. I think Adam proposed we have a separate sandbox=... toggle for this. Whether it's on or off by default probably doesn't matter much. 2.2) The ability to disable HTML parsing. On IFRAMEs, this can actually be approximated with the excommunicated plaintext tag, or with Content-Type: text/plain / data:text/plain,. On token-guarded SPANs or DIVs, however, it would be pretty damn useful for displaying text content without the need to escape , , , etc. Pure security benefit is limited, but as a phishing prevention and display correctness measure, it makes sense. I don't really understand the use case here; could you elaborate? One use case is a web forum or a web mail interface where you want to display a message, but specifically don't want HTML formatting. Or, performance permitting, the same could be used for any text-only entry fields displayed on a page. These are common XSS vectors, and they are not readily addressed by sandboxed iframe + srcdoc=..., because this will not render as expected: User's favorite smiley face is: iframe srcdoc=lt;Ogt;_lt;Ogt;/iframe Having a drop-in solution for this would be pretty nice, and very easy to implement, too: just force text/plain, do not sniff. Do people get CSRF right more often than simply escaping characters? It seems implausible that authors get complex cryptographic properties right more often than a simple set of substitutions, but I suppose stranger things are true on the Web. Keep in mind that pretty much every web application already needs to safely generate unique, unpredictable tokens - for session identifiers that guard authenticated sessions. If they can't get it right, they are hosed anyway - but problems here are not horribly common, in my experience at least, and web app frameworks do a decent job of helping developers by providing token-generating facilities. As noted earlier, the vast majority of issues with XSS and XSRF defenses is that you explicitly need to think about them, and a failure to do so has no obvious side
Re: [whatwg] some thoughts on sandboxed IFRAMEs
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
Re: [whatwg] some thoughts on sandboxed IFRAMEs
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 less prone to errors. Only and characters need to be escaped. If the character is not escaped, then a single character in the input will cause the comment to break. My counterargument, as stated later in the thread, is quite simple: the former *forces* you to implement a security mechanism, else the functionality will break. You can still use a bad token, but you are required to make the effort. Ah, but the devil is in the details. Of the two escaping requirements for @srcdoc, only escaping is required for security reasons. (Forgetting to escape will just result in spurious entities sometimes, but no security issues.) However, use of in comments should be reasonably common, and if it is left unescaped, will immediately truncate the content there (the rest of the comment will attempt to be interpreted as attributes or other elements). Thus, if you fail to escape your s, it should fail *quickly* and *obviously* on *innocuous* content. As well, as soon as it happens, the obvious fix is the correct one. On the other hand, getting your token-generation wrong will only fail when someone guesses your guard token and attacks your site. Ordinary comments will still work just fine. If we extend sandboxed iframes with srcdoc, seamless frames, text/html-sandboxed, and iframe rendering performance improvements, it actually becomes close to a comprehensive solution, and I am happy with this (other than a vague feeling that we just repurposed iframe to be some sort of a span ;-). In the end that's sorta what we're doing. ^_^ 1) Some other security mechanisms (CORS, anti-clickjacking controls, XSS filter controls) rely on separate HTTP headers instead. Is there a compelling reason not to follow that lead - or better yet, to unify all security headers to conserve space? HTTP headers won't cause the content to fail in browsers that don't understand them. Mimetypes will in at least *some* legacy browsers. I know that some versions of IE do content-sniffing for HTML-like content. 2) People may conceivably want to sandbox other document types (e.g., SVG, RSS, or other XML-based formats rendered natively, and offering scripting capabilities). Do we want to create -sandboxed MIME types for each? The header approach would fix this, too. Possibly. Are those document types going to be rendered in any way? SVG can be sent with an HTML mimetype now, at least. 2.1) The ability to disable loading of external resources (images, scripts, etc) in the sandboxed document. The common usage scenario is when you do not want the displayed document to phone home for privacy reasons, for example in a web mail system. Good point. Should we make sandbox= disable off-origin network requests? That would be great. I think Adam proposed we have a separate sandbox=... toggle for this. Whether it's on or off by default probably doesn't matter much. I think this is a good idea. Adam argues against it being effective for preventing exfiltration, but it's also useful for the common use-case of disabling images in comments. This would also prevent people using video or audio in comments. It would still allow the site author to allow self-hosted files to be used with any of these tags, but it would protect from, say, goatse trolls. 2.2) The ability to disable HTML parsing. On IFRAMEs, this can actually be approximated with the excommunicated plaintext tag, or with Content-Type: text/plain / data:text/plain,. On token-guarded SPANs or DIVs, however, it would be pretty damn useful for displaying text content without the need to escape , , , etc. Pure security benefit is limited, but as a phishing prevention and display correctness measure, it makes sense. I don't really understand the use case here; could you elaborate? One use case is a web forum or a web mail interface where you want to display a message, but specifically don't want HTML formatting. Or, performance permitting, the same could be used for any text-only entry fields displayed on a page. These are common XSS vectors, and they are not readily addressed by sandboxed iframe + srcdoc=..., because this will not render as expected: User's favorite smiley face is: iframe srcdoc=lt;Ogt;_lt;Ogt;/iframe Having a drop-in solution for this would be pretty nice, and very easy to implement, too: just force text/plain, do not sniff. I agree with this as well. I very commonly have inputs that should take plaintext only, not html. span[server-sanitized string]/span iframe srcdoc=[server-escaped string]/iframe span guard=[token][any string]/span guard=[token] The first two options will not immediately fail if you forget about or mess up
Re: [whatwg] some thoughts on sandboxed IFRAMEs
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 resource loads -- Adam Barth rightfully points out that this only stops certain classes of data exfiltration attacks, and so probably isn't worthwhile as a solution to that matter. However, I think this would also be very useful for general comments, to prevent, for example, shock trolls from putting goatse images in your comment threads. It would also prevent video and audio embeds from working. However, it would still allow the site owner to allow particular files to be embedded with img, audio, or video, if they just host them on their own origin and set allow-same-origin in the sandbox flags. This is already a relatively normal practice, but it's accomplished through attempts at filtering. Note that this would also prevent resource embeds using data urls, as they have a unique origin. 2) Prevent all HTML parsing (rendering as text/plain) - I think it's pretty common for certain areas of a comment form, such as username, email, or title, to be meant as ordinary plaintext without any special formatting allowed. Right now that means you have to run html escapes over the content, which isn't difficult. Would it be appropriate to move this into sandbox as well, though, to make it even easier? 3) Prevent no-input actions --- Sorry, the title is unclear - I mainly intend this as preventing audio autoplay and the like. Any sort of action that could be both annoying and would take place without the user's consent. This is inherently ill-defined, which may be a problem, but it could be tightened up to say precisely which features should be shut down. It might need to be revised as new features get added, though. 4) Stricter resource limits --- Shelley Powers states that she disallows SVG in the comments on her blog because of the risk of someone DOSing her users by writing highly resource-intensive SVG. This could be fixed in a general sense by having the ability to opt into very strict resource limits per iframe - it the limit is exceeded, the browser would simply bail and end processing in that iframe. I'm not certain how practical this is from an engineering standpoint, however. There's no need to set precise limits on this - each browser should understand the platform it's running on well enough to know what an 'appropriate' resource amount is for this sort of thing. Phones would cut off iframes much sooner than a desktop, a browser might take advantage of system load information to dynamically alter its cutoff point, etc. Are there other reasonable improvements that could be made to iframe sandbox to make it more suitable for wrapping things such as blog comments? Ideally, production-level sites with relatively normal requirements should be able to use *solely* iframe sandbox to protect their users from untrusted content. (Though, of course, it would be only a part of the site's defenses until the userbase with non-supporting browsers drops low enough to ignore.) Do others believe this is an achievable goal, or conversely believe it is not? ~TJ
Re: [whatwg] Drag-and-drop feedback
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 destination folder. This will normally
involves multiple clicks. Native application, like Outlook, can let the
user drag attachments directly into the destination place, i.e. desktop,
which is really convenient.
We propose adding a specific format string to the DataTransfer object:
DownloadURL. The data associated with the DownloadURL format should
be parsed similar to the URL format. When the drag ends in another
application, the remote file described in the associated data URL should
be downloaded and provided to the target application.
How would this be exposed to other apps? Is it possible in Windows to drop
something and then have the application that received the drop wait for a
download (which could take hours) to complete? How does that work?
If we can rely on the download happening before the drag, then we could
add something to the DataTransfer object to add File objects.
We cannot do the download before the drag because the drop target might not
accept the drag or the user might press ESC to cancel the drag-and-drop. We
do not want to do any unnecessary download before we know for sure that the
user really wants it.
It could be possible that the target application could be blocked for long
time if we do not provide the drag-and-drop information in a nice way. On
Windows, we could provide a download file in two ways: file path or file
stream. For the former way, a file has to be downloaded first before the
target application can consume it and thus the target application will be
blocked until the download completes. For the latter way, we use the file
stream to transfer the data between the source application and the target
application and thus the target application will not be blocked if it uses a
background thread (this is what Windows Shell does). On MacOSX, a file
stream is also used for such purpose.
However, we need to provide more metadata about the download when we call
DataTransfer.setData(DownloadURL, ...). This is because on Windows we need
to know about the file name and size when the drag is initiated. We can wait
till we get the headers to extract the file name and size but this is
blocking. Even more, if the http chunk mode is used, we cannot get the size
from the headers. On MacOSX, we need to provide the mime type and file name.
Could we consider adding mime type, file name and size information into the
data value parameter of setData method? For example,
dataTransfer.setData(DownloadURL, text/plain:1000:
http://example.com/download.txt;);
On Fri, 4 Sep 2009, Jens Alfke wrote:
On Sep 3, 2009, at 6:05 PM, Francisco Tolmasky wrote:
However, I think the addition of the deferred setData methods could be
added today in a way that is completely backwards compatible with
current implementations and would still be of great benefit.
Specifically, my request for deferring the calling of toString on
non-string objects as such:
event.dataTransfer.setData(something, { toString: function() {
return expensiveFunctionCall(); } });
This would allow me to submit patches to Firefox and WebKit that would
solve the current performance issues which are literally blocking my
ability to switch from fake drag and drop to native drag and drop.
At the same time, this should still work today in all browsers that
implement setData because the object is coerced into a string
immediately for you, thus not requiring immediate action on their part
to change anything.
+1. A real drag-n-drop API has to support promised data.
I agree with this in principle, but I think we should wait for DND to be
properly implemented in current browsers before adding this.
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, at the
very least, the DataTransfer object needs to have a 'types' attribute so
that the drag handler can determine if it can accept the drag.
I've tried to clarify what empty is supposed to mean here.
The issue that I'm having is that if the DataTransfer object says that
it has Files, I have no way to determine what type those files are. (In
this case, I only want to accept image files.) I understand that the
DataTransfer shouldn't have the content of the files for security
reasons, but it would be helpful if it did contain the file names and/or
MIME types.
I could provide a second attribute with the types of the files, would that
work? I suppose if we did this, we should remove the Files fake type.
That might not be a bad idea
Re: [whatwg] some thoughts on sandboxed IFRAMEs
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 is constructed on client side by JavaScript, sites would need to use opaque data: URLs, or put up with a lot of additional HTTP roundtrips, to utilize sandboxed IFRAMEs for this purpose. [ There is also the problem of formatting and positioning IFRAME content, although the seamless attribute would fix this. ] I've introduced srcdoc= to largely handle this. There is an example in the spec showing how it can be used. The ability to sandbox SPANs or DIVs using a token-guarded approach (span sandbox=random_token/span sandbox=same_token) is, on the other hand, considerably easier on the developer, and probably has a very similar implementation complexity. 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 less prone to errors. Only and characters need to be escaped. If the character is not escaped, then a single character in the input will cause the comment to break. This is likely to be caught early. If the character is not escaped, correctness and fidelity will suffer, but it will not lead to security errors. 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. 2) Renderers suck dealing with IFRAMEs, and will probably continue to do so for time being. This means that a typical, moderately complex application (say, as a discussion forum or a social site), where hundreds of user-controlled strings may need to be present to display user content - the mechanism would have an unacceptable load time and memory footprint. In fact, people are already coming up with lightweight alternatives with a significant functionality overlap (and different security controls). Microsoft has toStaticHTML(), while a standardized implementation is being discussed here right now in a separate thread. I agree that we should investigate other options too (iframe boxes aren't suitable for everything), but I don't think that current implementation problems with iframe should necessarily prevent us from investigating sandboxed iframes too. In certain contexts, e.g. reddit comments, it may be the case that instead of one sandboxed iframe per comment, the best way to do things is instead one sandboxed iframe for all the comments, with scripts disabled and allow-same-origin enabled, so that scripts can poke into the page and set event handlers on all the relevant links. Isn't the benefit of keeping the design slightly simpler (and realistically, limited to relatively few usage scenarios) negated by the fact that alternative solutions to other narrow problems would need to emerge elsewhere? The browser coming with several different script sanitizers with completely different APIs and security controls does not strike me as a desirable outcome (all the flavors of SOP are a testament to this). If the anser is not a strong no, maybe the token-guarded DIV / SPAN approach is a better alternative? I agree in principle that fewer features are better than more features, but we have to take into account that many of the people deploying these features know nothing about security. We have to ensure that the security aspects of features like this (like what to escape, what security tokens need to be generated) are aligned with the practical aspects of features like this (like what results in the page appearing to work, regardless of the state of security). Now, that aside - on a more pragmatic level, I have two extra comments: 1) The utility of the SOP sandboxing behavior outlined in the spec is diminished if we have no way to actually *enforce* that the IFRAMEd resource would only be rendered in such a context. If I am serving user-supplied, unsanitized HTML, it is obviously safe to do iframe sandbox src=show.cgi?id=1234/iframe - but where do we prevent the attacker from calling http://my_site/show.cgi?id=1234 directly, and bypassing the filter? I've introduced text/html-sandboxed for this purpose. 2.1) The ability to disable loading of external resources (images, scripts, etc) in the sandboxed document. The common usage scenario is when you do not want the displayed document to phone home for privacy reasons, for example in a web mail system. Good point. Should we make sandbox= disable off-origin network requests? 2.2) The ability to disable HTML parsing. On IFRAMEs, this can actually be approximated with the excommunicated plaintext tag, or with
Re: [whatwg] some thoughts on sandboxed IFRAMEs
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 you have any suggestions on how to fix the issues that have already been raised against that? ~TJ
Re: [whatwg] Drag-and-drop feedback
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, at the very least, the DataTransfer object needs to have a 'types' attribute so that the drag handler can determine if it can accept the drag. I've tried to clarify what empty is supposed to mean here. Thanks, that makes sense for the status quo. The issue that I'm having is that if the DataTransfer object says that it has Files, I have no way to determine what type those files are. (In this case, I only want to accept image files.) I understand that the DataTransfer shouldn't have the content of the files for security reasons, but it would be helpful if it did contain the file names and/or MIME types. I could provide a second attribute with the types of the files, would that work? I suppose if we did this, we should remove the Files fake type. That might not be a bad idea in general, it's kind of a hack. I'm not sure how I feel about having multiple different ways of representing the data in a DataTransfer object... It would give a clean precedent for adding other features, though, like promises, which some people have requested. Multiple different ways to get the same info doesn't seem great, but it doesn't matter to me as long as the information is available. Another option is to throw an error if developers try to access forbidden attributes during dragenter/dragover. Michael On Fri, 22 Jan 2010, Daniel Cheng wrote: Two more questions about implementation details: Cut/copy: Does it make sense to fire a drag event at all? The spec says that drag events should be fired at the source node every 350ms (presumably to allow the source node to cancel a drag after it started), but a cut/copy takes place instantaneously. I've clarified the spec to say that the loop has to happen immediately and then only repeat every 350ms if it's still active. If drag events should be fired during cut/copy, should the clipboard be restored to its original state if the drag event is cancelled? It would make sense, but might make implementations more complicated. The idea is for the cut/copy to be done exactly as if it was a drag to a hypothetical clipboard window, meaning everything happens in the drop part, so yes. Paste: It seems like there is no time a dragleave event would ever fire. A paste essentially goes through the drag and drop loop once; the only possible transition is for the current target element to go from null to non-null. The 'dragleave' event can fire during a paste if the drag is canceled. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] some thoughts on sandboxed IFRAMEs
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 more reliable I'm interested in 2 and 3. Users will do dumb things, and both 2 and 3 assumes a similar baseline scenario as 1; a developer did something dumb. Nonces need not be cryptographically strong for most apps, so the big problem is re-use. UA's have broad leeway here to prevent re-use on origins and deny sandboxing to containers that re-use the same nonces on a single page. They can even help by keeping a list of recently used nonces and denying reuse. What concerns me about the escaping option is that it's harder to implement by default. Perhaps you see that as a benefit, but if part of the goal is to raise the average, then allowing markup that can surround existing DOM structures and secure them easily surely beats trying to help every web developer understand that stuffing semantic content into an attribute sausage casing (but don't do it wrong!) is a good thing. I'm also looking at this problem from the perspective of ways to help speed up pages. Iframes have the useful and desirable quality that they don't load and execute resources synchronously with the parent document's DOM. For most sorts of ads, widgets, and embedded x-domain 3rd party content, the synchronous nature of mashup content creates enormous performance problems. Google ads, Facebook Connect badges and login containers...it's all much slower than it needs to be. Along with Steve Souders, Adam Barth, and a few others I've been discussing options for retrofitting content to make an iframe-like container that participates inline in the current document but which loads and executes content asynchronously from the perspective of the main document's content. Getting users to use -- and then secure -- such a container seems to me to be significantly easier sell if the opening discussion doesn't begin with first, take your document fragment and do the moral equiavlent of base64 encoding. In fact, I'd argue that base64 with a length header might be a simpler and easier way to handle arbitrary content in attributes. Violations of the length would make parsing problems even more visible than in the escaped case while the default amount of work to do it right would remain unchanged. If the security of the system depends on users correctly pre-processing their content, then I'd like to suggest that we should be more explicit about it and not accept the -escaping half measure. The other option (which I favor) is to not pretend that we can have it both ways and give users who explictly opt into security features enough credit to have thought about their use for even a moment. Regards On Mon, Jan 25, 2010 at 3:47 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: 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 you have any suggestions on how to fix the issues that have already been raised against that? ~TJ
Re: [whatwg] object behavior
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). And, after that, it'd probably be best to note that css in general doesn't affect instantiation/destroying (to avoid having to keep on adding CSS properties to the list) Something like this: Note: The above algorithm is independent of CSS. For example, it runs even if the element is hidden or out-of-view because of the 'display', 'position', 'visibility' and 'overflow' properties. Further, changing the value of any CSS property does not cause the above algorithm to run again on the element. For example, changing the element's 'display' property from 'inline-block' to 'none' does not destroy the loaded resource. Fair enough. Done something like the above. That'll work. Could you make the change for embed and applet too when you have time? It appears I have already done so. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
