Re: [whatwg] Handling of collapsed whitespace in contenteditable
Le 21/06/11 00:00, Aryeh Gregor a écrit : On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgarieh...@mozilla.com wrote: There's a very good reason why existing browser engines have to resort to nbsp; hacks. It's the only practical way to make sure that foo__bar (s/_/ /) entered into an editable element would appear the intended way when the innerHTML of the editable area is submitted to a server and later displayed in another documents. Is that really such a problem? At worst, there will be annoying mismatches between the same content when it's editable and not editable. Yes it is. At least for HTML-based email and forms used to composer emails. Also for blog entries composed directly in HTML through an in-page wysiwyg editor. Forcing 'white-space: pre-wrap' on the editor would require to force it too on the final rendering element... /Daniel
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, 20 Jun 2011 13:14:54 +0200, Jonas Sicking jo...@sicking.cc wrote: Though possibly a safer way to think about it is that the Content-Type header should always be inspected to see if a preflight is needed, no matter if the header is set by the page or by the implementation. I think I like the latter approach more since it seems safer. Bah, Content-Type sucks. I created a new thread on public-weba...@w3.org to further discuss this (as well as something else I noticed): http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1222.html (I already renamed custom request headers to author request headers. I hope that will reduce some of the confusion I and others had with respect to Last-Event-ID and Cache-Control. I should probably add a note too at some point, once I find an appropriate location.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Hashing Passwords Client-side
Hi All, I believe there are three major discussions: 1. Is the security gain using client-side hashing worth the cost of implementation and education? 2. How would you implement client-side hashing? 3. How will incorrect deployment of client-side hashing affect security? I would like provide an updated solution to #2, which leads me to a follow-up question at the end of my e-mail. In the original proposal, I suggested adding an attribute @hash to input type=password tags. I now think this is ultimately a bad decision, because it doesn't provide a clear path for transition. I have attached a basic demo of a more robust implementation. The code of interest is: Username: input type=text name=fuserbr Password: input type=text name=fpass (intentionally a text field)br input type=hidden name=fpass.hash value=sha1,salt The JavaScript surrounding it simply implements what you would expect. Upon form submission, the JavaScript will read through all form names, and detect if there is a name.hash equivalent. If there is, it parses out the value field to extract the hashing algorithm, and salt (if no salt exists, it defaults to the origin). In the above example, the hash is sha1, and the salt is salt. It then performs the hash on the form value. Basically: form['fpass.hash'].value = sha1(form['fpass'].value + ':' + salt); Then it clears out the original value: form['fpass'].value = ''; The reason I chose this format was to enable a server-side framework to be able to detect all necessary information to perform the hashing itself if the client-side failed. If the client-side fails, all parameters are submitted to the server (input name to hash, hash function, and salt). If the salt is omitted, the server SHOULD be able to calculate its origin string. As an added benefit, the hash can now be applied to any form element. --- With that said, I think this brings up a follow-up question: Does this functionality need to be a part of the standard? I think at this point, it might make sense to leave it at the JavaScript level, and browsers do not need the functionality built into them. Thanks again for any comments. The attached code was written by me (including the sha1 implementation), and I hereby release it in the public domain. ~Sean On Mon, Jun 20, 2011 at 6:38 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Jun 20, 2011 at 4:40 AM, James Graham jgra...@opera.com wrote: FWIW I disagree. The same argument could be used against client-side form validation since some authors might stop doing proper server-side validation. I agree, HTML5 forms provide a minor net security loss. However, the loss is fairly small and is easily outweighed by the non-security advantages. Here we have a proposal that only has security benefits, so if it's a net security loss by even a small margin, or even if it's only a small security gain, it's not worth it.
[whatwg] What it means for attributes of input to apply or not apply
Hi, When adding[1] the placeholder= attribute to input type=number, one of our engineers asked me about the behavior of content attributes that don't apply to certain input types. Consider for example input type=range. The spec says[2] [t]he following content attributes *must not be specified* and *do not apply* to the element: […] placeholder[…] (emphasis mine). The first bit (must not be specified) is clear: it's an authoring conformance requirement. The second bit (does not apply to the element), however, isn't clear. Is it a UA conformance requirement? What does it mean? I *think* it means that the placeholder= attribute has no effect on the rendering of input type=range. Does it also mean that the placeholder= content attribute shouldn't be reflected as an IDL attribute on input elements of type=range? In Safari 5, Firefox 4, and Opera 11, placeholder= gets reflected as an IDL attribute, regardless of the value of type=. Thanks, Ted 1. https://bugs.webkit.org/show_bug.cgi?id=61095 2. http://www.whatwg.org/specs/web-apps/current-work/complete/number-state.html#range-state
Re: [whatwg] comment on a part of the script execution spec, regarding not fully active documents
On Tue, 21 Jun 2011 23:42:32 +0900, Boris Zbarsky bzbar...@mit.edu wrote: On 6/21/11 5:21 AM, Hallvord R. M. Steen wrote: Another issue I noticed is in the text under the heading the javascript: URL scheme - specifically the last otherwise part of the text. This is about trying to navigate a window from a different origin to a javascript: URL. Don't we expect a security exception here? I don't think so, no. In particular, this check needs to happen right before running the script, which happens asynchronously, right? Opera actually does a check earlier - there is an origin check if a script attempts to set location / location.href to a string that starts with javascript:. (This model is of course safe if the javascript: URL executes immediately. If there is any way to insert a predictable delay between the security check and the actual execution, a timing-sensitive XSS attack might be possible.) So at that point throwing a security exception doesn't make much sense... Well, I somewhat disagree with the doesn't make much sense claim here ;). It made sense to me to inform either the setting script or the script inside the javascript: URL itself of the problem by throwing an exception. However, I guess the latter is somewhat murky security-wise for little gain, and the former would mean throwing a new exception when most engines apparently haven't done so traditionally, so we should avoid that. Summing up, I think HTML5 spec is OK as-is, and will report a bug to get us to align.. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: [whatwg] Hashing Passwords Client-side
On Mon, Jun 20, 2011 at 6:38 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Jun 20, 2011 at 4:40 AM, James Graham jgra...@opera.com wrote: FWIW I disagree. The same argument could be used against client-side form validation since some authors might stop doing proper server-side validation. I agree, HTML5 forms provide a minor net security loss. However, the loss is fairly small and is easily outweighed by the non-security advantages. Here we have a proposal that only has security benefits, so if it's a net security loss by even a small margin, or even if it's only a small security gain, it's not worth it. On 22 Jun 2011, at 16:35, Sean Connelly wrote: Hi All, I believe there are three major discussions: 1. Is the security gain using client-side hashing worth the cost of implementation and education? 2. How would you implement client-side hashing? 3. How will incorrect deployment of client-side hashing affect security? I'm going to avoid repeating my existing concerns that I've raised already, but I prepose the addition of questions 0 and 4: 0. Are there security gains from using client-side hash? 4. Will client-side hashing encourage some developers out of server-side hashing solutions? e.g. Is implementing this on the client-side going to imply that it's safe/sensible to do on the client-side? Since my comments I had researched the old WHATWG thread in which Maciej Stachowiak goes through some very well reasoned points which I feel stand in this discussion. See: Username: input type=text name=fuserbr Password: input type=text name=fpass (intentionally a text field)br input type=hidden name=fpass.hash value=sha1,salt The legacy-browser user will in this example be asked to enter a password in a text input, not a password input... intentional or typo? As an added benefit, the hash can now be applied to any form element. Is there a use-case for this? I am still very much of the opinion that client-side hashing is not useful nor beneficial to any site which runs SSL for personal/secure data and hashes on the serverside - anyone not doing this should be encouraged to do so, not offered an alternative which in my opinion (and Maciej's) is not a real security enhancement. I'm happy to answer more specifically but feel I'd be repeating what I said before, which wouldn't help anyone. Mat Carey
Re: [whatwg] Hashing Passwords Client-side
Hi Mat, The legacy-browser user will in this example be asked to enter a password in a text input, not a password input... intentional or typo? Intentional for the demo (as marked after the field). I forgot to mention as well: The demo is not production-level code. It incorrectly handles characters outside of the ASCII range, and has only been tested on Chrome 12. It likely has many bugs, and was written as a basic demonstration of the concept. I am still very much of the opinion that client-side hashing is not useful nor beneficial to any site which runs SSL for personal/secure data and hashes on the serverside - anyone not doing this should be encouraged to do so, not offered an alternative which in my opinion (and Maciej's) is not a real security enhancement. I'm happy to answer more specifically but feel I'd be repeating what I said before, which wouldn't help anyone. I agree. Client-side hashing has no security gain for a server running SSL and correctly performing server-side hashing. However, server-side hashing cannot be verified by the user. The user must take it on faith that the administrators have robust security procedures. Unfortunately, this is not the case on all servers. A benefit of using client-side hashing is that a user can verify that a server cannot insecurely store their password because the server never has access to the password. This can be circumvented using additional scripting, but the circumvented scripting would also need to be sent to the client, and could be inspected by impartial developers. Honest websites can implement client-side hashing. This is something that can be verified by third parties for a website. This ensures that the server CANNOT compromise plain-text passwords. The user still needs to take it on faith that the server implements additional server-side hashing, but that is the same state we are in right now. The benefit is that the user can verify that the server can never compromise their plain-text password. ~Sean On Wed, Jun 22, 2011 at 12:01 PM, Mat Carey m...@matcarey.co.uk wrote: On Mon, Jun 20, 2011 at 6:38 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Jun 20, 2011 at 4:40 AM, James Graham jgra...@opera.com wrote: FWIW I disagree. The same argument could be used against client-side form validation since some authors might stop doing proper server-side validation. I agree, HTML5 forms provide a minor net security loss. However, the loss is fairly small and is easily outweighed by the non-security advantages. Here we have a proposal that only has security benefits, so if it's a net security loss by even a small margin, or even if it's only a small security gain, it's not worth it. On 22 Jun 2011, at 16:35, Sean Connelly wrote: Hi All, I believe there are three major discussions: 1. Is the security gain using client-side hashing worth the cost of implementation and education? 2. How would you implement client-side hashing? 3. How will incorrect deployment of client-side hashing affect security? I'm going to avoid repeating my existing concerns that I've raised already, but I prepose the addition of questions 0 and 4: 0. Are there security gains from using client-side hash? 4. Will client-side hashing encourage some developers out of server-side hashing solutions? e.g. Is implementing this on the client-side going to imply that it's safe/sensible to do on the client-side? Since my comments I had researched the old WHATWG thread in which Maciej Stachowiak goes through some very well reasoned points which I feel stand in this discussion. See: Username: input type=text name=fuserbr Password: input type=text name=fpass (intentionally a text field)br input type=hidden name=fpass.hash value=sha1,salt The legacy-browser user will in this example be asked to enter a password in a text input, not a password input... intentional or typo? As an added benefit, the hash can now be applied to any form element. Is there a use-case for this? I am still very much of the opinion that client-side hashing is not useful nor beneficial to any site which runs SSL for personal/secure data and hashes on the serverside - anyone not doing this should be encouraged to do so, not offered an alternative which in my opinion (and Maciej's) is not a real security enhancement. I'm happy to answer more specifically but feel I'd be repeating what I said before, which wouldn't help anyone. Mat Carey
Re: [whatwg] comment on a part of the script execution spec, regarding not fully active documents
On 6/22/11 11:51 AM, Hallvord R. M. Steen wrote: Opera actually does a check earlier - there is an origin check if a script attempts to set location / location.href to a string that starts with javascript:. That's fine, as long as there is _also_ a check right before the script runs. (This model is of course safe if the javascript: URL executes immediately. Indeed, which is not the case in many UAs and not the case in the spec last I checked... unless that's changed? Well, I somewhat disagree with the doesn't make much sense claim here ;). Throwing an exception from the async attempt to execute would do ... what exactly? It made sense to me to inform either the setting script Which isn't on the stack anymore by the time the exception is thrown? or the script inside the javascript: URL itself Which isn't getting run? -Boris
Re: [whatwg] File API Streaming Blobs
Greetings Adam, Ian, I wish I knew that earlier when I originally posted the idea, there was lots of discussion and good ideas but then it suddenly dropped of the face of the earth. Essentially I am fowarding this suggestion to public-weba...@w3.org on the basis as apparently most discussion of File API specs happen there, and would like to know how to move forward with this suggestion. The original suggestion and following comments are on the whatwg list archive, starting with http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029973.html Summing up, the problem with the current implementation of Blobs is that once a URI has been generated for them, by design changes are no longer reflected in the object URL. In a streaming scenario, this is not what is needed, rather a long-living Blob that can be appended is needed and 'streamed' to other parts of the browser, e.g. thevideo oraudio element. The original use case was: make an application which will download media files from a server and cache them locally, as well as playing them without making the user wait for the entire file to be downloaded, converted to a blob, then saved and played, however such an API covers many other use cases such as on-the-fly on-device decryption of streamed media content (ie live streams either without end or static large files that to download completely would be a waste when only the first couple of seconds need to be buffered and decrypted before playback can begin) Some suggestions were to modify or create a new type of Blob, the StreamingBlob which can be changed without its object url changing and appended to as new data is downloaded or decoded, and using a similar process to how large files may start to be decoded/played by a browser before they are fully downloaded. Other suggestions suggested using a pull API on the Blob so browsers can request for new data asynchronously, such as in http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029998.html Some problems however that a browser may face is what to do with urls which are opened twice, and whether the object url should start from the beginning (which would be needed for decoding encrypted, on-demand audio) or start from the end (similar to `tail`, for live streaming events that need decryption, etc.). Thanks, P.S. Sorry if I've not done this the right way by forwarding like this, I'm not usually active on mailing lists. I actually think moving to a streaming mode for file reads in general is desirable, but I'm not entirely sure extending Blobs is the way to go for *that* use case, which honestly is the main use case I'm interested in. We may improve upon ideas after this API goes to Last Call for streaming file reads; hopefully we'll do a better job than other non-JavaScript APIs out there :) [1]. Blob objects as they are currently specified live in memory and represent in memory File objects as well. A change to the underlying file isn't captured in the Blob snapshot; moreover, if the file moves or is no longer present at time of read, an error event is fired while processing a read operation. The object URL may be dereferenced, but will result in a 404. The Streaming API explored by WHATWG uses the Object URL scheme for videoconferencing use cases [2], and so the scheme itself is suitable for resources that are more dynamic than memory-resident Blob objects. Segment-plays/segment dereferencing in general can be handled through media fragments; the scheme can naturally be accompanied by fragment identifiers. I agree that it may be desirable to extend Blobs to do a few other things in general, maybe independent of better file reads. You've Cc'd the right listserv :) I'd be interested in what Eric has to say, since BlobBuilder evolves under his watch. -- A* [1] http://download.oracle.com/javase/1.4.2/docs/api/java/io/FileInputStream.html [2] http://www.whatwg.org/specs/web-apps/current-work/#stream-api
Re: [whatwg] What it means for attributes of input to apply or not apply
On Wed, Jun 22, 2011 at 11:50 AM, Edward O'Connor eocon...@apple.com wrote: The second bit (does not apply to the element), however, isn't clear. Is it a UA conformance requirement? What does it mean? I *think* it means that the placeholder= attribute has no effect on the rendering of input type=range. Does it also mean that the placeholder= content attribute shouldn't be reflected as an IDL attribute on input elements of type=range? In Safari 5, Firefox 4, and Opera 11, placeholder= gets reflected as an IDL attribute, regardless of the value of type=. It's reflected regardless of the type: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#dom-input-placeholder does not apply to the element could use clarification, though.
Re: [whatwg] What it means for attributes of input to apply or not apply
On Wed, 22 Jun 2011, Edward O'Connor wrote: The second bit (does not apply to the element), however, isn't clear. It's a hook used here: http://www.whatwg.org/specs/web-apps/current-work/complete.html#common-input-element-attributes I'll add a hyperlink or something to make it clearer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
