Re: [whatwg] Type Date
On Thu, 06 May 2010 23:36:00 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: My suggestion was to fall back to using a standard text input field and use JavaScript to add the date picker which will allow the user to enter the date manually if so desired. Are there any current plans to add this ability to type=date or is the fallback the best option? That's a browser UI issue, then. File a bug on Opera suggesting that. FYI, confirming I've filed a bug on that already. -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel Pre-order my HTML5 book www.introducinghtml5.com
Re: [whatwg] Type Date
On Fri, May 7, 2010 at 5:58 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: | # a date-fullyear is defined as four or more digits | representing a number greater than 0 I read that as to . Is there a different interpretation of that? Surely is not greater than 0?
[whatwg] WebSocket handshake: 0x0D in first line
establish a WebSocket connection [[ 28. Read bytes from the server until either the connection closes, or a 0x0A byte is read. Let field be these bytes, including the 0x0A byte. If field is not at least seven bytes long, or if the last two bytes aren't 0x0D and 0x0A respectively, or if it does not contain at least two 0x20 bytes, then fail the WebSocket connection and abort these steps. User agents may apply a timeout to this step, failing the WebSocket connection if the server does not send back data in a suitable time period. 29. Let code be the substring of field that starts from the byte after the first 0x20 byte, and ends with the byte before the second 0x20 byte. ]] This makes it possible for servers to include 0x0D bytes before and after the status code, and potentially trick broken clients that aren't so fuzzy with new lines to misinterpret the handshake. Maybe we should read ahead to the first 0x0D byte and check if the next byte is 0x0A instead. -- Simon Pieters Opera Software
Re: [whatwg] RFC: input type=username
I think using the role attribute is the best solution here: input type=text role=username input type=email role=username This way we're using the type attribute to indicate what sort of data is being entered, and the role attribute to indicate how it will be used. I think the separation of these is sensible, although it's not entirely consistent across the spec (in my model, search would be a role on a type=text). It's also backwards compatible with HTML4 and with current implementations of HTML5, and could tie in with the rest of ARIA's roles model. The same concept could, for instance, also be applied to a signup form where there is a check box for opting in to marketing: input type=checkbox role=optin You'd need to use a role attribute of login or signup on the form as well to give context to things like role=username so the browser would know what behaviour is appropriate. As someone pointed out, the form element isn't always available if you're working with ASP.NET, so it would seem right to make the roles legal for fieldset, section and div as well. In fact, it would seem right anyway because you could have something like an ecommerce site where there's a single form to place an order which deals with payment for the current order as well as signup for the account. David Goss
Re: [whatwg] Type Date
Am 07.05.2010 00:30 schrieb Schalk Neethling: Just to rectify any misunderstanding, I love the date picker that Opera provides and others will hopefully do in turn but, my question is that currently using type=date only provides the option of selecting a date using the date picker. In a recent talk I gave on HTML 5 the question arose that well, what if the user wants to have both options on the same field? My suggestion was to fall back to using a standard text input field and use JavaScript to add the date picker which will allow the user to enter the date manually if so desired. Are there any current plans to add this ability to type=date or is the fallback the best option? If I understand your task correctly, I assume that changing the appearance of the date field via CSS would be the appropriate way: http://www.w3.org/TR/2004/CR-css3-ui-20040511/#appearance0 Of course, this can't be done before the CSS appearance property is broadly supported, and the new HTML5 input types are reflected as possible values of this property. Meanwhile, it might be easier to switch field types (and maybe patterns) via JS, than implementing a custom JS date picker.
[whatwg] WebSocket set-cookie
establish a WebSocket connection [[ 41. ... If the entry's name is set-cookie or set-cookie2 or another cookie-related field name If the relevant specification is supported by the user agent, handle the cookie as defined by the appropriate specification, with the resource being the one with the host host, the port port, the path (and possibly query parameters) resource name, and the scheme http if secure is false and https if secure is true. [COOKIES] If the relevant specification is not supported by the user agent, then the field must be ignored. ]] At this point, the handshake can still fail. It seems bad to set cookies if the handshake fails. We want to process set-cookie when the handshake has succeeded (but before changing readyState and firing 'open'). -- Simon Pieters Opera Software
Re: [whatwg] meta=encrypt tag is needed
On Thu, May 6, 2010 at 8:44 AM, juuso_ht...@tele3d.net wrote: meta=encrypt pubkey=ABABAEFEF2626EFEFEF pubtool=EC256-AES|RSA2048-AES passsalt=no|domainname auth=verisign I see a few shortcomings in this approach: a) each document is encrypted asymmetrically, affecting performance. b) there is no management of keys (expiration, revocation, trust, etc). c) the values for the pubtool attribute (encryption algorithm) will need to be spec'd, slowing the deployment of new encryption algorithms (or better techniques altogether). d) how to handle XMLHttpRequests? how to handle XHRs receiving JSON or text? e) information from the UA to the server is plaintext (e.g., logon/passwords). If, instead, authentication relies only on possession of the user's private key; then, any human can sit at the user's console and automatically authenticate to all HTTP servers. I'd prefer a radically different approach (TLS = out of scope). Frank Migacz Technical Instructor
Re: [whatwg] meta=encrypt tag is needed
I was expecting criticism; as is unavoidable with all crypto issues. You asked many questions, and unfortunately all you missed the auth=verisign argument, which _is_ enough to prevent all practical (,even if they are all theoretical!,) man-in-the-middle attacks. html head meta encrypt pubkey=ABABAEFEF2626EFEFEF pubtool=EC256-AES passsalt=colordev.com auth=verisign/ /head body form method=post action=?php echo $_SERVER['PHP_SELF']; ? Username: input type=text name=user /br / Password: input type=password name=password / input type=submit value=Submit /br / /form /body /html the above 'page' using the meta-encrypt tag, which is enough for a client browser to submit to site a) a salted password b) and a user name transported in encrypted form; over the internet Maybe someone can show a _complete_ alternative Javascript https solution about how those can be achieved in a computer or PDA-device without javascript support. I am not suggesting replacing https with anything, government and business sites can and should keep on using it. I am suggesting a small easy to use mini-encryption which would be enough for those 90% of sites should salt their passwords and encrypt sensitive data and but who currently aren't. question 1: The server has to read and correctly parse each HTML page to decide whether to encrypt it? (And how does the browser know that the page is encrypted, vs. a legacy server that doesn't encrypt?) answer 1: Most servers are already configured to read the requested pages before submitting those over the internet. For example my above form-page has a small php-script inside which the server program must notice; as the PHP-program needs to compile the script. Client never sees the ?php echo $_SERVER['PHP_SELF']; ? part but is instead shown an URL. To implement meta-encrypt tag would just require (on/off) configuring server program to read the header of requested page and see if there is a meta-encrypt tag in there the server calls a program which decrypts! the client submitted data. Obviously you people will keep complaining, so what do you want to complain next 1) Man-in-the-middle problem; which doesn't exists because a) those are just academic mind games b) if auth=verisign is used as external CA 2) HTTPS = good (even if it is typically NOT used with forms 3) password salting = webmasters duty to do it (which 50% forget), after using the HTTPS (which 90% forget) 4) Declaring encrypt action doesn't fit into HTML (; then why is there a form method get/post) Juuso Hukkanen www.colordev.com
Re: [whatwg] meta=encrypt tag is needed
On Fri, 2010-05-07 at 17:06 +, Juuso Hukkanen wrote: answer 1: Most servers are already configured to read the requested pages before submitting those over the internet. What do you base this on? I can't say I've ever seen a server set up to parse HTML content For example my above form-page has a small php-script inside which the server program must notice; as the PHP-program needs to compile the script. Client never sees the ?php echo $_SERVER['PHP_SELF']; ? part but is instead shown an URL. PHP is a server language, parsed by the PHP program not the server software (i.e. Apache or IIS) and as such, only parse PHP code within PHP tags, not the HTML. To implement meta-encrypt tag would just require (on/off) configuring server program to read the header of requested page and see if there is a meta-encrypt tag in there the server calls a program which decrypts! the client submitted data. What you're suggesting is that web servers be set up to parse HTML pages, or an extra server module (like PHP) to parse HTML content. Not only would this impact on the speed of some sites, but it's likely going to be harder to convince web hosting companies to update their web server software than it is to convince offices to upgrade a browser (and anyone who's ever worked in an office will know how hard it is to get updates and new software installed) Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Type Date
On Thu, May 6, 2010 at 2:19 PM, Schalk Neethling sch...@ossreleasefeed.com wrote: Greetings, Are there any talks at the moment whether the type=date input will allow a user to enter a date manually or use the date picker or, should developers fall back to using a standard input field and add the date picker via JavaScript? The purpose of input type=date is to allow the browser to supply the user with a datepicker. Opera, for example, already does this. If you would like to show a datepicker to users of all browsers, use feature detection (such as through the Modernizr script) to detect whether or not the browser support date inputs, and if not, supply the js version. Hey TJ, I understand what type=date is supposed to offer the user and agree that using Modernizr to detect whether the element is supported and provide a fallback but my more direct question is, would HTML 5 offer the ability to allow a user to use either the date picker or enter the date manually if the type=date attribute is specified. Something like for example input type=date editable=true / Thanks, Schalk
Re: [whatwg] Type Date
On Fri, May 7, 2010 at 11:26 AM, Schalk Neethling sch...@ossreleasefeed.com wrote: Hey TJ, I understand what type=date is supposed to offer the user and agree that using Modernizr to detect whether the element is supported and provide a fallback but my more direct question is, would HTML 5 offer the ability to allow a user to use either the date picker or enter the date manually if the type=date attribute is specified. Something like for example input type=date editable=true / HTML5 doesn't specify anything about how the date input is presented. It's entirely up to the browser to decide if they want to allow the user to type a date in, or just use a datepicker, or what. ~TJ
Re: [whatwg] meta=encrypt tag is needed
On Fri, May 7, 2010 at 1:06 PM, Juuso Hukkanen juuso_ht...@tele3d.net wrote: You asked many questions, and unfortunately all you missed the auth=verisign argument, which _is_ enough to prevent all practical (,even if they are all theoretical!,) man-in-the-middle attacks. You haven't explained what it does. Did you mean that the meta tag should include a certificate as well as a public key? If so, how is that better than HTTPS? Maybe someone can show a _complete_ alternative Javascript https solution about how those can be achieved in a computer or PDA-device without javascript support. Just serve the page using HTTPS, and have a normal HTML form. It will transmit the username, and the password. The server can salt and hash the password. (You could also easily have the client salt and hash the password using JavaScript before submission, but this doesn't improve security once you're using HTTPS.) I am not suggesting replacing https with anything, government and business sites can and should keep on using it. I am suggesting a small easy to use mini-encryption which would be enough for those 90% of sites should salt their passwords and encrypt sensitive data and but who currently aren't. It is not sufficient, because it's trivially circumventable by a man-in-the-middle attack. It therefore provides no security against any attacker. It also provides no greater assurance of security on the server side, because anyone who's competent enough to include this meta tag will probably also be competent enough to hash and salt passwords on their own. Most servers are already configured to read the requested pages before submitting those over the internet. I'm not aware of any HTTP server that attempts to parse outgoing HTML content. Could you provide a specific example? In particular, I'm rather certain that neither Apache, nor IIS, nor lighttpd parse outgoing HTML pages, and that accounts for most servers already. For example my above form-page has a small php-script inside which the server program must notice; as the PHP-program needs to compile the script. Client never sees the ?php echo $_SERVER['PHP_SELF']; ? part but is instead shown an URL. To implement meta-encrypt tag would just require (on/off) configuring server program to read the header of requested page and see if there is a meta-encrypt tag in there the server calls a program which decrypts! the client submitted data. This requires HTTP servers to implement an HTML parser, and to run it every time a page is submitted. They don't actually do this right now. HTML parsing is actually very complicated and slow -- have you looked at the HTML parsing algorithm http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#parsing? 1) Man-in-the-middle problem; which doesn't exists because a) those are just academic mind games If so, there's no reason for encryption at all. You can just send the content unencrypted if no one is going to intercept it. b) if auth=verisign is used as external CA Saying who the CA is is not enough to certify it. You need to provide the actual certificate, e.g., in X.509 format http://en.wikipedia.org/wiki/X.509. To get a certificate, you will typically have to pay a CA some sum of money, making it prohibitive for casual sites. What's the advantage over HTTPS at this point? 2) HTTPS = good (even if it is typically NOT used with forms Many sites use HTTPS for everything, including login. Most sites don't, but that's mainly because 1) it's hard to get a certificate (you don't solve this), and 2) it doesn't work well with shared hosting (there are better solutions to this in progress). 3) password salting = webmasters duty to do it (which 50% forget), after Then why will they remember to add the meta tag you suggest? They'll just forget both. This is a problem, but the only solution is to have the browser act more securely by default, regardless of what the webmaster does. 4) Declaring encrypt action doesn't fit into HTML (; then why is there a form method get/post) HTML is the wrong place to do encryption, because once you receive the page, it might have already been tampered with. The entire connection needs to be specified as secure-only from the beginning, such that the client will abort if it receives unencrypted/unauthenticated content. This is what HTTPS does. By the time you get to the actual contents of the document, it's impossible to know whether it's been secured. You haven't explained yourself very clearly, but in summary, this is what I think you're trying to do and why it doesn't work: 1) You're trying to provide protection against MITM attacks that's easier to use than HTTPS. This fails, because a) you still need a certificate (the most annoying part of HTTPS), and b) an MITM could just alter the outgoing HTTP request to remove the encryption request, get the plaintext reply, and encrypt that itself, with the client none the
Re: [whatwg] meta=encrypt tag is needed
On Fri, May 7, 2010 at 10:06 AM, Juuso Hukkanen juuso_ht...@tele3d.net wrote: 1) Man-in-the-middle problem; which doesn't exists because a) those are just academic mind games You don't get to talk about security anymore. ~TJ
Re: [whatwg] Expanding the cite element
On May 6, 2010, at 11:14 AM, Edward O'Connor wrote: Consider how the above would work in legacy browsers, and then consider how this would work in them: pAs Ashley Crandall Amos says in citea href=http://example.com/books/crandall/linguisticmeans;Linguistic Means of Determining the Dates of Old English Literary Texts/a/cite ... Amos also mentions in citea href=http://example.com/books/crandall/linguisticmeans;Linguistic Means/a/cite/p Ted, I'm almost satisfied with your approach except for three things: 1. Referencing something in the href attributed of an a tag implies that the URI will resolve to a URL, that is, that it will be accessible on the web at that address. Not every URI is a URL, though. That's what I was trying to do with a uri attribute for the cite tag is to identify the resource, not necessarily link to it. 2. We would have to formally define what a within cite means, otherwise we would leave the pairing up for interpretation. 3. Are there instances where tags that can be used separately take on a different meaning in relation to one another? I know what li means in relation to ol and ul, but then again, I can't really use li outside of either of those two. Best, Grant
Re: [whatwg] meta=encrypt tag is needed
On Fri, 2010-05-07 at 13:21 -0700, Tab Atkins Jr. wrote: On Fri, May 7, 2010 at 10:06 AM, Juuso Hukkanen juuso_ht...@tele3d.net wrote: 1) Man-in-the-middle problem; which doesn't exists because a) those are just academic mind games You don't get to talk about security anymore. ~TJ +1 You only have to read a few XKCD comics to realise that man-in-the-middle attacks are pretty easy to pull off! Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] meta=encrypt tag is needed
On Fri, May 7, 2010 at 4:21 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, May 7, 2010 at 10:06 AM, Juuso Hukkanen juuso_ht...@tele3d.net wrote: 1) Man-in-the-middle problem; which doesn't exists because a) those are just academic mind games You don't get to talk about security anymore. I don't think academic is an *entirely* unfair characterization of MITM on the web, actually. MITM is hard enough to pull off on the open web that unless you're a bank or PayPal or something, it's unlikely anyone would bother. In practice, most web developers don't have to worry about MITM. By contrast, something like XSS or SQL injection is often so easy to exploit when it exists that any site is at risk, from botnet operators targeting their outdated software or from script kiddies feeling bored or spiteful. In fact, do you know of *any* examples of MITM attacks being successfully used against a public website? It's not that I doubt that it's happened, but I don't actually know of any specific cases. In principle, you should be able to harvest lots of passwords by dropping some free wireless routers in strategic locations. (There's still an entirely different fatal problem with what you quoted, though: if you aren't worried about MITM, then encryption is pointless to begin with. I don't dispute your conclusion. :) )
