Re: [whatwg] Issues relating to the syntax of dates and times
- Original Message - From: Ian Hickson [EMAIL PROTECTED] To: Pentasis [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Sent: Wednesday, November 26, 2008 12:32 AM Subject: Re: [whatwg] Issues relating to the syntax of dates and times On Tue, 25 Nov 2008, Pentasis wrote: But the way it is described now still creates a difference in *possible* markup between: The battle of waterloo was fought on time datetime=1815-06-18Sunday 18 June 1815/time and: Julius Ceasar was assassinated on the ides of march in the year 44BC. The spec allows us to use the time-element in the first case but not in the second, while the type of information and semantics of the sentence are the same in both cases and both dates are known dates and agreed upon to be true. I can imagine this to be confusing for authors/users. Could you, for both cases, give the precise number of seconds from the day of the event in question until now? My impression is that we would not be able to give the precise number of seconds since a date on the Roman calendar. For example, were the years after 44BC regular or intercalary? As I said before, I think before we start supporting other calendars (like the Roman calendar, or even the more recent Julian calendar), we should support non-Gregorian calendars that are in active use today. But I don't propose to do this at this time, as that is an inordinately complicated problem and we don't yet know if time is going to be widely used or not. No, I understand. That was not the point I was making. I mean it the other way around. I am *not* saying that the second example (44BC) should be able to be marked-up like this, but that -because we can't mark that one up- neither shoudl we mark up the second example. In other words the spec should be clear on the fact that it is not intended for this kind of use either. Perhaps it should be more of a time-stamp? (like the address-element is actually only used for the author of the article/page/site so this element is like that?) I hope I make myself clear? Bert
Re: [whatwg] Issues relating to the syntax of dates and times
On Wed, 26 Nov 2008, Pentasis wrote: Like I said, I completely understand the issues here. It just seems a bit strange to me to choose one specific calendar and promote that one to exact. Well it's the calendar in use by a large part of the world. It's not just any random calendar. :-) thereby not only limiting the use of the time-element in regard to *any* time/date but even within its own calendrical base (1582 as you correctly point out, but also to any leap-stuff that came after it). Indeed, at some future point we'll have to add more (contemporary) calendar systems. in the end it is up to the author to use this element and I strongly suspect it will be misused and abused because of it's illogical limitations (this is no critisism, just an observation of the element itself) If it is misused, we will be able to use that information to design the next version to address the cases that authors in fact need. So in a way, that's all part of the natural evolution of the language. Indeed, time itself was originally added because abbr was being abused in a similar way (though almost exclusively for modern ISO8601 dates). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Solving the login/logout problem in HTML
Martin Atkins wrote: This idea has promise, but is it compatible with existing browsers? The case where the only challenge included is HTML is probably okay, since browsers will at this point likely determine that they don't support any of the given schemes and just display the entity body. The only concern in this case is browser-provided default error pages for the 401 response, which can hopefully be suppressed in much the same way as sites suppress IE's default 404 error page by padding the response to take it above a certain filesize. More bothersome is this case: HTTP/1.1 401 Unauthorized ... WWW-Authenticate: HTML form=login WWW-Authenticate: Basic realm=... ... Is that case relevant? Today, those sites do not support Basic (or Digest) at all, or only send the 401 for certain user agents and/or methods. So I wouldn't expect them to start adding the non-HTMLL auth challenge... ... BR, Julian
Re: [whatwg] Solving the login/logout problem in HTML
On Nov 26, 2008, at 13:19, Julian Reschke wrote: So wouldn't it make sense to address the common use case so that it doesn't require the bot (the non-HTML UA) to parse the response body? That seems like a bad optimization. Adding an off-the-shelf HTML parser to a bot is much easier than tuning the general crawling functionality and task-specific functionality of a bot. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Solving the login/logout problem in HTML
Henri Sivonen wrote: That seems like a bad optimization. Adding an off-the-shelf HTML parser to a bot is much easier than tuning the general crawling functionality and task-specific functionality of a bot. I'll be convinced when I see support for this being integrated into the MacOsX and Microsoft Windows WebDAV clients. BR, Julian
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson schrieb: ...and there must be a form element with name=login, which represents the form that must be submitted to log in. Forgive me if this is a stupid question... but anyway: Are there other cases where values of the name attribute have special functionalities? Otherwise, I'd suggest to rather use the type attribute or introduce an empty attribute such as loginform.
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: ... I don't understand why it makes a difference what the form is like. It should apply whatever credentials it has been given -- whatever those might be, username/password, certificate, fake addressa and phone number, whatever, and submit the form. Just like a user. ... If the form is more complex than two fields (identity/secret), then I don't see how authentication is going to work except by displaying the form -- just extracting the field names certainly wouldn't be sufficient, even if they would be reasonable self-describing. So, in the current form, this proposal only helps in marking the server's response as *being* a login form, but not really in making it more usable for a non-HTML client... BR, Julian
Re: [whatwg] Solving the login/logout problem in HTML
On Wed, 26 Nov 2008, Thomas Broyer wrote: I came to the same conclusion and already implemented it (with a custom application-specific scheme) in an Enterprise app (the custom scheme accepts both HTML form, i.e. cookie, and an Authorization request-header –we're using it for XMLHttpRequests to bypass any cookie and therefore allow more than one user session in the same browser session). Cool! challenge = HTML [ form ] form = form = form-name form-name = quoted-string RFC2617 states that The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. I didn't really understand how the realm would work here, which is why I didn't include it. Is this a case where we should violate RFC2617? (Note that we're in a rather unusual case here because the challenge never gets a reply in the traditional sense.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: On Wed, 26 Nov 2008, Julian Reschke wrote: Ian Hickson wrote: ... As can be seen in the feedback below, there is interest in improving the So when you get to a page that expects you to be logged in, it return a 401 with: WWW-Authenticate: HTML form=login ...and there must be a form element with name=login, which represents the form that must be submitted to log in. ... For security reasons, I'd prefer that to be the form element, instead of a form element -- having multiple copies of the name in the same document should be considered a fatal error. Having multiple form elements with the same name is already an error. Yes. I'm not sure what you mean by fatal error. The spec precisely defines which form should be used in the case of multiple forms with the same name. Could you describe the attack scenario you are considering? If everybody UA is going to run an HTML5 parser as specified, then a problem is unlikely. I just don't believe this is going to happen. In *that* case, ambiguous login information is a problem, and a simple ans safe way to avoid this issue is to tell clients to abort when they detect the problem. Yes, that's a simpler option. :-) (Provided that current browsers still ask for authentication even when given a 200 OK.) I don't think they do now, but it's something we can move towards. I think asking for credentials when the status is 200 would be a bug. Even in the asynchronous way mpt suggested? I think it would go a long way towards addressing the limitations of HTTP authentication. One of the great benefits of HTML authentication forms is that they can be made available in the equivalent of a 200 OK situation as opposed to only in the equivalent of a 401 situation. You can already handle the case of content that's available unauthenticated, but would potentially differ in case of being authenticated by adding Vary: Authorization to a response. BR, Julian
Re: [whatwg] Solving the login/logout problem in HTML
On Wed, 26 Nov 2008, Julian Reschke wrote: Ian Hickson wrote: Anyway, if it's out of sync, authentication is not going to work, so it should be noticed quickly. On the contrary, authentication is going to work fine for 99% of users and it's only when a lone user tries using a bot that it'll break. Yes, that's what I meant: it will not work for the bot. We apparently disagree how frequently this is going to be used. Yes. On Wed, 26 Nov 2008, Julian Reschke wrote: Do you have a concrete example where the login form is complex in a manner where the fields can't be identified and there is reason to believe that a bot will want to authenticate but won't have been given enough information to do so? Well, it was you stating that the form could be arbitrarily complex. It can, yes. HTML allows arbitrarily complex forms, and we don't want to limit login forms to just two fields and a button. (I regularly log in to systems where the login forms are two text fields and a checkbox, or two text fields and a drop down, or five or so text fields. But in none of these cases would I personally expect a bot to ever have my credentials.) If it's just two text fields, one of which of type password, then no, it wouldn't be hard. Ok. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: ... On Wed, 26 Nov 2008, Julian Reschke wrote: Do you have a concrete example where the login form is complex in a manner where the fields can't be identified and there is reason to believe that a bot will want to authenticate but won't have been given enough information to do so? Well, it was you stating that the form could be arbitrarily complex. It can, yes. HTML allows arbitrarily complex forms, and we don't want to limit login forms to just two fields and a button. (I regularly log in to systems where the login forms are two text fields and a checkbox, or two text fields and a drop down, or five or so text fields. But in none of these cases would I personally expect a bot to ever have my credentials.) ... Yes. So wouldn't it make sense to address the common use case so that it doesn't require the bot (the non-HTML UA) to parse the response body? BR, Julian
Re: [whatwg] Issues relating to the syntax of dates and times
- Original Message - From: Ian Hickson [EMAIL PROTECTED] To: Pentasis [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Sent: Wednesday, November 26, 2008 12:09 PM Subject: Re: [whatwg] Issues relating to the syntax of dates and times On Wed, 26 Nov 2008, Pentasis wrote: No, I understand. That was not the point I was making. I mean it the other way around. I am *not* saying that the second example (44BC) should be able to be marked-up like this, but that -because we can't mark that one up- neither shoudl we mark up the second example. In other words the spec should be clear on the fact that it is not intended for this kind of use either. Perhaps it should be more of a time-stamp? (like the address-element is actually only used for the author of the article/page/site so this element is like that?) I hope I make myself clear? The spec draws the line already -- it says that the date has to be in the proleptic Gregorian calendar, and that the year has to be greater than zero. Now admittedly even down near the bottom of that the dates get a bit unspecific, but I'm not sure what we can really do about that. Drawing the line around 1582 seems somewhat arbitrary as well. At least 0001 is a neat place to draw the line, since it is the place at which the syntax would have to change in some way. Like I said, I completely understand the issues here. It just seems a bit strange to me to choose one specific calendar and promote that one to exact. thereby not only limiting the use of the time-element in regard to *any* time/date but even within its own calendrical base (1582 as you correctly point out, but also to any leap-stuff that came after it). I still think it would be better to simply let go of the we want the time/date to be exact (in relation to our current calendar/clocks) and use a more relative construct. But only because I find it illogical from a semantical point of view. I can accept the technical limitations. So I will concede ;-) in the end it is up to the author to use this element and I strongly suspect it will be misused and abused because of it's illogical limitations (this is no critisism, just an observation of the element itself) Bert
[whatwg] Database feedback
There's a question at the bottom about how best to make transactions be free of concurrency problems. Input welcome. On Fri, 23 May 2008, Aaron Boodman wrote: I noticed one unfortunate thing about the new Database API. Because the executeSql() callback holds open the transaction, it is easy to accidentally do intensive work inside there and hold open the transaction too long. A common mistake might be to do a big select and then hold open the transaction while the UI is updated. This could hold open the tx maybe an extra couple hundred ms. A bigger problem would be to do synchronous XHR (for example, in workers). This could hold open the tx for seconds. The right place to do work like this is in transaction()'s success callback. But because the resultsets aren't easily accessible there, I think authors are more likely to do work in executeSql()'s success callback and use transaction()'s success callback less frequently. Off hand about the best solution I can think of to this problem is to have some sort of state on the transaction object that gathers the results. This is not very satisfying though. Does anyone have a better idea? Or think this is not a big enough concern to worry about? I agree that this might be a problem. I'm not sure how to address it. On Tue, 27 May 2008, Scott Hess wrote: I think the only way you can really make it better is to put something like an executeSql() function directly on Database objects, which could shift the success callback entirely outside the transaction scope. I think that would reasonably match server-side SQL use (you either send a bare SELECT with implicit transaction, or use explicit BEGIN/END to group things which must be consistent). I don't want to add this yet, in case it turns out we don't really need it, but implementation experience will definitely tell us whether this is needed or not and if it is we will have to add it in v2. On Mon, 26 May 2008, Aaron Boodman wrote: Quick thing. I don't think the spec makes it clear whether it is allowed to do this: var db1 = window.openDatabase(foo, , , ); var db2 = window.openDatabase(foo, 1, , ); I think the answer should be no. Thoughts? If so, perhaps edit this sentence: If the database version provided is not the empty string, and the database already exists but has a different version, then the method must raise an INVALID_STATE_ERR exception. To read like this: If the database version provided is not the empty string, and the database already exists but has a different version, or no version, then the method must raise an INVALID_STATE_ERR exception. Fixed. On Mon, 26 May 2008, Chris Prince wrote: I think the spec is technically correct. What's confusing is that the same line can mean two different things: // Start with no databases. // On the 1st call, this line means create a database, // and set the version string to the empty string. var db1 = window.openDatabase(foo, , , ); // On the 2nd call, the meaning has changed to // open the 'foo' database, regardless of the version string. var db2 = window.openDatabase(foo, , , ); Yeah, that's a bit confusing. Not sure what to do about it. On Mon, 4 Aug 2008, Aaron Boodman wrote: It seems like you need a way to abort an in-progress transaction. An easy way to do this would be to add an abort() method to SQLTransaction. What's the use case? Can we wait until v2 to add this, or is it critical? On Mon, 4 Aug 2008, Aaron Boodman wrote: Currently, the database API has an error code for the situation where you open a transaction for read, then try to write but the database is locked. I think that the spec should at least suggest, but perhaps require, implementors to serialize access to a single database to prevent this from happening. Without this, developers must wrap every single write attempt in error handling and retry if a lock error occurs. It seems likely that developers will forget to do this and it will be a significant pain point with the API. Applications will seem to work, but then mysteriously fail in production when users have multiple copies of the application open. Even if the developer adds retry logic, it is easy for a page to get starved by another page. Serializing access would prevent all these problems at the cost of read concurrency, which I think is OK for the first version of this API. A future version of the API could add the concept of read transactions which would allow concurrency, but would fail immediately when you try to write with them. I am loath to do this, because of the performance hit. However, what we could do is say that if the first statement is read-only, they all have to be, and if the first statement is a write, then it locks the database? Though that would be rather weird... We could have a .writeTransaction() and a .readTransaction(), where the former always
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: On Wed, 26 Nov 2008, Julian Reschke wrote: If the form is more complex than two fields (identity/secret), then I don't see how authentication is going to work except by displaying the form -- just extracting the field names certainly wouldn't be sufficient, even if they would be reasonable self-describing. So, in the current form, this proposal only helps in marking the server's response as *being* a login form, but not really in making it more usable for a non-HTML client... Do you have a concrete example where the login form is complex in a manner where the fields can't be identified and there is reason to believe that a bot will want to authenticate but won't have been given enough information to do so? Well, it was you stating that the form could be arbitrarily complex. If it's just two text fields, one of which of type password, then no, it wouldn't be hard. BR, Julian
Re: [whatwg] Solving the login/logout problem in HTML
On Wed, 26 Nov 2008, Julian Reschke wrote: I'm not sure what you mean by fatal error. The spec precisely defines which form should be used in the case of multiple forms with the same name. Could you describe the attack scenario you are considering? If everybody UA is going to run an HTML5 parser as specified, then a problem is unlikely. I just don't believe this is going to happen. In *that* case, ambiguous login information is a problem, and a simple ans safe way to avoid this issue is to tell clients to abort when they detect the problem. Detecting the case of there being two identically named forms is far more complex than just using the first form with the given name. It is in fact a superset of the functionality -- you have to look for the first form, then look for a second. Whereas the current spec text just says to look for the first form and stop. So as far as I can tell what you are proposing is in fact more complicated, whether you use an HTML5-compliant parser or some other ad hoc HTML parser. Even in the asynchronous way mpt suggested? I think it would go a long way towards addressing the limitations of HTTP authentication. One of the great benefits of HTML authentication forms is that they can be made available in the equivalent of a 200 OK situation as opposed to only in the equivalent of a 401 situation. You can already handle the case of content that's available unauthenticated, but would potentially differ in case of being authenticated by adding Vary: Authorization to a response. Ah yes, I forgot that the Vary header would need to be present. But you still need to include the challenge. So that doesn't actually change the original point. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Solving the login/logout problem in HTML
On Wed, 26 Nov 2008, Julian Reschke wrote: Ian Hickson wrote: ... As can be seen in the feedback below, there is interest in improving the So when you get to a page that expects you to be logged in, it return a 401 with: WWW-Authenticate: HTML form=login ...and there must be a form element with name=login, which represents the form that must be submitted to log in. ... For security reasons, I'd prefer that to be the form element, instead of a form element -- having multiple copies of the name in the same document should be considered a fatal error. Having multiple form elements with the same name is already an error. I'm not sure what you mean by fatal error. The spec precisely defines which form should be used in the case of multiple forms with the same name. Could you describe the attack scenario you are considering? Yes, that's a simpler option. :-) (Provided that current browsers still ask for authentication even when given a 200 OK.) I don't think they do now, but it's something we can move towards. I think asking for credentials when the status is 200 would be a bug. Even in the asynchronous way mpt suggested? I think it would go a long way towards addressing the limitations of HTTP authentication. One of the great benefits of HTML authentication forms is that they can be made available in the equivalent of a 200 OK situation as opposed to only in the equivalent of a 401 situation. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Solving the login/logout problem in HTML
On Wed, 26 Nov 2008, Julian Reschke wrote: Ian Hickson wrote: A simple way to achieve it would be to restrict it to username/password pairs, and to have the names of these form parameters live in the response headers as well. We would have to, at a minimum, include the name of the username field, the name of the password field, and the URL of the form to POST to. I am very wary of duplicating information that is already available as it tends to become out of date and thus ends up being even more of a pain than if the information isn't there in the first place. I would expect that information to be autogenerated. I would be very surprised if it was. If it turns out to be widely autogenerated, then I'd be happy to add features to help with that. Anyway, if it's out of sync, authentication is not going to work, so it should be noticed quickly. On the contrary, authentication is going to work fine for 99% of users and it's only when a lone user tries using a bot that it'll break. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: Anyway, if it's out of sync, authentication is not going to work, so it should be noticed quickly. On the contrary, authentication is going to work fine for 99% of users and it's only when a lone user tries using a bot that it'll break. Yes, that's what I meant: it will not work for the bot. We apparently disagree how frequently this is going to be used. BR, Julian
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay ha scritto:
On 11/26/2008 02:34 AM, Calogero Alex Baldacchino wrote:
A
better way to do what you aim would consist of setting a listener for
key events on a displayable element and choosing a different operation
basing on the pressed key(s);
This is not content author friendly way to do it, because different
browsers/OSes
use different keys to activate accesskey targets.
-Olli
On one hand, whoever wished to write a 'complex' web application, with
keybord shortcuts, should be aware of this concern and try and deal with
it, since it's even more complex than you wrote, and might affect
accesskey attributes too. The problem is, keybord shortcuts have always
been strongly platform-dependent, while the web is aimed as a somewhat
cross-platform architecture, so both accesskeys and key events handling
cannot be 'fully author friendly'. I mean, a somewhat browser, on a
somewhat OS, might use the same combination of modifiers (i.e. crtl+alt
- just an example, not thinking on a real situation) to activate both
its own controls (which take precedence) and a web page controls, so
there is always a chance to choose an accesskey which won't work on a
particular platform. Perhaps it was an heavier concern a few (or even
several) years ago, since nowaday I think most browsers take great care
on this matter, however such problem might arise from time to time, i.e.
with a new browser version, or a version supporting a new OS (or a new
OS version), or using an old browser version apparently compatible with
a new OS version (but such should be a concern more for browser/os
developers than for web developers, since the latter can only assume the
underlying platform - browser + os - works correctly, and cannot care
about any 'bug' outside their work, yet access keys, whatever way
handled, cannot be though as a 'fully and always' reliable mechanism,
while mouse clicks and tab-key navigation plus return-key activation
usually are). Perhaps, keybord shortcuts may work better in a 'make
application state'.
I agree that setting an accesskey attribute is easyer to deal with than
handling key events, and the 'no-dimension, display:inline elements
trick' stands always out there; anyway I think key events handling may
be improved and become easier to adopt by adding to a somewhat interface
a few constants representing the modifiers combination used by the
browser to activate access keys, so those modifiers could be compared to
the modifiers 'carried on' by the key event (this would require support
for the DOM 3 Events, which I think could be improved/modified too -- if
something like the above is yet present in html5 spec and I've missed
it, I apologize).
On the other hand, the key events listener could just operate on single
alphanumerical characters, something like (javascript-style)
switch(pressedKey){
case 'a' : doSomething(); return;
case 'b' : doSomethingElse(); return;
}
so to bypass any modifiers concern, with some extra care to avoid
interferences with textual fields (and to avoid casual key pressing by
the user - i.e. the very first time a key listened for is pressed, the
webapp could just show an advise and list all valid shortcuts). Anyway,
even in this case there would be chances to clash with a browser default
behaviour for some keys (i.e. when the key is a digit).
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Scopri i games più scaricati su cellulare! Gioca la tua partita!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8272d=26-11
Re: [whatwg] Solving the login/logout problem in HTML
On Wed, Nov 26, 2008 at 10:12 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 26 Nov 2008, Julian Reschke wrote: Ian Hickson wrote: ... As can be seen in the feedback below, there is interest in improving the So when you get to a page that expects you to be logged in, it return a 401 with: WWW-Authenticate: HTML form=login ...and there must be a form element with name=login, which represents the form that must be submitted to log in. ... For security reasons, I'd prefer that to be the form element, instead of a form element -- having multiple copies of the name in the same document should be considered a fatal error. Having multiple form elements with the same name is already an error. I'm not sure what you mean by fatal error. The spec precisely defines which form should be used in the case of multiple forms with the same name. Could you describe the attack scenario you are considering? If I'm not misunderstanding things, there is a new attack scenario: I post a comment on someone's blog, saying a href=/restricted-access.php?xsshole=form action=http://hacker.example.com/capture name=logininput name=usernameinput name=password/formcrawl me!/a On their blog's web server, restricted-access.php require authentication, and unauthenticated access results in a 401 with 'WWW-Authenticate: HTML form=login' and the appropriate login form. But inevitably there's some kind of XSS hole in that page, so arbitrary markup can be inserted above the real login form. (Maybe they pass an error message in a parameter, which will be displayed above the form, but they forgot to escape the output.) Their internal search engine crawler is configured to know a username and password (and the form field names etc) for these restricted areas. It follows the link from my blog comment, it notices the WWW-Authenticate header, and like a good little bot it chooses to parse the HTML page and find the matching form and fill in the fields and submit the login details. But actually it's submitting my XSS-inserted form, and sending the login details to me. XSS holes already cause various security vulnerabilities; but they can't currently result in sensibly-written crawlers unwittingly submitting their login details to arbitrary third parties, so this is a new risk. I can imagine a few ways to avoid this problem: 1) Don't write any pages with XSS holes. 2) Detect tampering by refusing to submit login details if = 2 forms match the name. 3) Only submit login details to same-origin URLs, or to some other restricted set. 4) Configure the crawler with the form submission URL, as well as the form field names and values, so it doesn't have to trust the HTML. 5) Change WWW-Authenticate so it gives all the details (submission URL, field names, etc), so nobody has to trust the HTML. But (1) is not going to happen in reality, so we should try to minimise the damage when XSS holes exist. (2) won't work because the attacker could write '...?xsshole=...!--' and the second form would be hidden. (3) is more sensible; perhaps the spec should explicitly note that you need to be quite careful about not submitting login forms to third-party sites unless you're sure you trust them? But even with (3), I could write a href=/restricted-access.php?xsshole=form action=/public-pastebin.php... and the crawler would send the login details to somewhere on the same host where I could still read them back, which doesn't seem great. So (4) is more sensible. You already have to configure the crawler with the form field names, so you might as well tell it what URL to submit to, and it shouldn't parse the HTML response or care about the form element. (Then there's no need for WWW-Authenticate to even say what the form name is.) (5) is basically the same, except it's late-binding the form details rather than hardcoding them into the crawler's configuration, and so it makes it easy to change the server-side login handling without reconfiguring everyone's crawlers. (But the cost of the potential solutions to the vulnerability might be greater than the cost of the vulnerability, so it might not be worth doing anything - I don't have a useful opinion on that.) -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Database feedback
On Wed, Nov 26, 2008 at 3:46 AM, Ian Hickson [EMAIL PROTECTED] wrote: We could have a .writeTransaction() and a .readTransaction(), where the former always run in isolation. Any preferences? My preference is for separating read transactions from write transactions. Then the API could throw if you tried to write in a read transaction. - a
Re: [whatwg] Fallback styles for legacy user agents [was: Re: Deprecating small , b ?]
Benjamin Hawkes-Lewis ha scritto: Calogero Alex Baldacchino wrote: I know, and agree with the basic reasons; however I think that deriving an SGML version (i.e. by adding new entities and elements, as needed, to an html 4 dtd) should not be very difficoult, and could be worth the effort (i.e. to graceful degrade the presentation of a menu element thought as a context menu, wich content should not be shown untill a right click happens - if the u.a. cannot handle it, not showing it at all could be a reasonable behaviour). The derived sgml version should be aimed just for older browsers, while newer, html 5-aware ones should just ignore any dtd reference. I'd consider this chance, at least on the fly - I suspect that the complete break out with the earlier sgml specifications might carry in an undesireable side-effect: from one side it solves the problems arised from sgml partial support/bad implementation and from browser-specific quirks, but from the other side no mechanism is provided to make sgml-somehow-based user agents to gain whatever awareness on the newly defined elements. What SGML-somehow-based user agents? While many web browsers switch behavior based on what they detect in the first characters of an HTML document (including the doctype declaration), there are no (or at any rate, no remotely /popular/ web browsers) that read text/html DTDs in the way required for this idea to be workable. Since all you're proposing is to bake implied STYLE values into the DTD, it seems to me your use-case could be served by making an HTML5 foundation stylesheet publicly available. Compare: http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/ http://developer.yahoo.com/yui/base/ -- Benjamin Hawkes-Lewis Oh, I thought (and hoped) a somewhat basic support were provided... I understand I was wrong... The foundation style sheet may be at least a partial solution, but if the browser is not aware of an element, I guess its style could not apply at all. Anyway, a standard default style sheet could be desireable both to have a standard basic layout on all browsers (as far as possible, because of possible differences in CSS compliance) and as a potential aid for assistive UAs, since the default sheet could cover a few basic aureal properties. Regards, Alex -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: A fine mese devi affrontare molte spese? Intesa Sanpaolo ti parla di Check-up finanziario. Prenotalo qui senza impegno Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8436d=26-11
Re: [whatwg] Database feedback
On Mon, 26 May 2008, Chris Prince wrote: // On the 1st call, this line means create a database, // and set the version string to the empty string. var db1 = window.openDatabase(foo, , , ); // On the 2nd call, the meaning has changed to // open the 'foo' database, regardless of the version string. var db2 = window.openDatabase(foo, , , ); On Wed, Nov 26, 2008 at 3:46 AM, Ian Hickson [EMAIL PROTECTED] wrote: Yeah, that's a bit confusing. Not sure what to do about it. Two ideas: * Perhaps use a different value to mean open any version, if one exists. Using 'null' seems like an obvious candidate. * Alternately, don't allow the empty string as a valid version string. Only use the empty string to mean open existing. --Chris
Re: [whatwg] Database feedback
Ian Hickson wrote: There's a question at the bottom about how best to make transactions be free of concurrency problems. Input welcome. On Fri, 23 May 2008, Aaron Boodman wrote: I noticed one unfortunate thing about the new Database API. Because the executeSql() callback holds open the transaction, it is easy to accidentally do intensive work inside there and hold open the transaction too long. A common mistake might be to do a big select and then hold open the transaction while the UI is updated. This could hold open the tx maybe an extra couple hundred ms. A bigger problem would be to do synchronous XHR (for example, in workers). This could hold open the tx for seconds. The right place to do work like this is in transaction()'s success callback. But because the resultsets aren't easily accessible there, I think authors are more likely to do work in executeSql()'s success callback and use transaction()'s success callback less frequently. Off hand about the best solution I can think of to this problem is to have some sort of state on the transaction object that gathers the results. This is not very satisfying though. Does anyone have a better idea? Or think this is not a big enough concern to worry about? I agree that this might be a problem. I'm not sure how to address it. On Tue, 27 May 2008, Scott Hess wrote: I think the only way you can really make it better is to put something like an executeSql() function directly on Database objects, which could shift the success callback entirely outside the transaction scope. I think that would reasonably match server-side SQL use (you either send a bare SELECT with implicit transaction, or use explicit BEGIN/END to group things which must be consistent). I don't want to add this yet, in case it turns out we don't really need it, but implementation experience will definitely tell us whether this is needed or not and if it is we will have to add it in v2. On Mon, 26 May 2008, Aaron Boodman wrote: Quick thing. I don't think the spec makes it clear whether it is allowed to do this: var db1 = window.openDatabase(foo, , , ); var db2 = window.openDatabase(foo, 1, , ); I think the answer should be no. Thoughts? If so, perhaps edit this sentence: If the database version provided is not the empty string, and the database already exists but has a different version, then the method must raise an INVALID_STATE_ERR exception. To read like this: If the database version provided is not the empty string, and the database already exists but has a different version, or no version, then the method must raise an INVALID_STATE_ERR exception. Fixed. On Mon, 26 May 2008, Chris Prince wrote: I think the spec is technically correct. What's confusing is that the same line can mean two different things: // Start with no databases. // On the 1st call, this line means create a database, // and set the version string to the empty string. var db1 = window.openDatabase(foo, , , ); // On the 2nd call, the meaning has changed to // open the 'foo' database, regardless of the version string. var db2 = window.openDatabase(foo, , , ); Yeah, that's a bit confusing. Not sure what to do about it. On Mon, 4 Aug 2008, Aaron Boodman wrote: It seems like you need a way to abort an in-progress transaction. An easy way to do this would be to add an abort() method to SQLTransaction. What's the use case? Can we wait until v2 to add this, or is it critical? On Mon, 4 Aug 2008, Aaron Boodman wrote: Currently, the database API has an error code for the situation where you open a transaction for read, then try to write but the database is locked. I think that the spec should at least suggest, but perhaps require, implementors to serialize access to a single database to prevent this from happening. Without this, developers must wrap every single write attempt in error handling and retry if a lock error occurs. It seems likely that developers will forget to do this and it will be a significant pain point with the API. Applications will seem to work, but then mysteriously fail in production when users have multiple copies of the application open. Even if the developer adds retry logic, it is easy for a page to get starved by another page. Serializing access would prevent all these problems at the cost of read concurrency, which I think is OK for the first version of this API. A future version of the API could add the concept of read transactions which would allow concurrency, but would fail immediately when you try to write with them. I am loath to do this, because of the performance hit. However, what we could do is say that if the first statement is read-only, they all have to be, and if the first statement is a write, then it locks the database? Though that would be rather weird... We could have a .writeTransaction() and a .readTransaction(), where the former always run in isolation. Any preferences? I'm fine
Re: [whatwg] Solving the login/logout problem in HTML
On Tue, 25 Nov 2008 19:54:46 +0100, Julian Reschke [EMAIL PROTECTED] wrote: thanks a lot for this proposal which seems to go into the right direction. Indeed. I think this is an area with an enormous potential for improvement and it's very encouraging to see so many great ideas about the issues involved and how to solve them. I didn't yet have time to look into this in detail, but it currently seems to require the UA to still parse the HTML page. Wouldn't it be better of the *headers* of the response (such as WW-Authenticate, Link, ...) would contain sufficient information to perform the login without having to do that; such as a URI to POST to, plus the parameter names for user name and password? I agree that more should happen on the HTTP level and with more control given to the web application. Considering the state of the next version of the HTTP specification(s), would it perhaps be a good idea to discuss this with the HTTP WG as well? 'WWW-Authenticate: HTML' or something similar is a step in the right direction. I don't see it as necessary to identify the form that does the authentication, though. Just as [1], I think that puts a burden on the user agent that really isn't necessary. Web application developers pulls a lot of hair doing web form-based authentication already and are used to having control over just about every part of it. Taking that control and responsibility away at this point is only deterring, imho. Instead, we should leave the control in the hands of the web application developers and force as little as possible on to the user agent developers. The way I see it, the following example should be enough to perform a successful authentication: [Request 1] GET /administration/ HTTP/1.1 [Response 1] HTTP/1.1 401 Unauthorized WWW-Authenticate: HTML realm=Administration !DOCTYPE html html form action=/login input name=username input type=password name=password input type=submit /form /html [Request 2] POST /login HTTP/1.1 username=adminpassword=secret [Response 2] HTTP/1.1 302 Found Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm=Administration Location: /administration/ [Request 3] GET /administration/ HTTP/1.1 Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm=Administration [Response 3] HTTP/1.1 200 OK !DOCTYPE html html ... h1Welcome!/h1 /html The twist here is that it is up to the server to provide the authentication token and through the 'Authorization' header, give the client a way to authorize future requests. I append the realm parameter to the 'Authorization' header to give the server and client a way to control authorization and more importantly deauthenticate (e.g. logout) for different realms on the same web site. Since more is up to the web application now, a deauthenticate works the following way: [Request] POST /logout HTTP/1.1 [Response] HTTP/1.1 200 OK Authorization: HTML realm=Administration !DOCTYPE html html ... h1Good bye!/h1 /html The empty token in the 'Authorization' header indicates that it should be forgotten for the given realm by the user agent and that future requests to resources within the same realm requires a reauthentication. This suggestion overloads the 'Authorization' header quite a bit, but since we're inventing a new authentication scheme that the UA needs to understand anyway, and especially if we get the HTTP WG on board here, I think this can only give positive effects. The alternative is to invent a new response header to serve the same purpose, but seeing as the request and response header -- if 'Authorization' is used -- are identical, a typical authentication by a browser supporting the HTML scheme is just to opaquely copy+pasting the entire 'Authorization' header from the request to the response. [1] http://www.w3.org/TR/NOTE-authentform -- Asbjørn Ulsberg -=|=- [EMAIL PROTECTED] «He's a loathsome offensive brute, yet I can't look away»
Re: [whatwg] accesskey attribute with display:none elements
On 11/26/2008 05:35 PM, Calogero Alex Baldacchino wrote: anyway I think key events handling may be improved and become easier to adopt by adding to a somewhat interface a few constants representing the modifiers combination used by the browser to activate access keys, so those modifiers could be compared to the modifiers 'carried on' by the key event (this would require support for the DOM 3 Events, which I think could be improved/modified too -- if something like the above is yet present in html5 spec and I've missed it, I apologize). Note, accesskey events (http://www.w3.org/2008/webapps/track/issues/40) won't be probably defined in DOM 3 Events (which is still just a draft). And those events are anyway different thing to this problem. I'd want it to be specified somewhere how accesskeys should behave in display:none content. Because of the valid use case (dhtml menus) and the current behavior of FF2/Safari/Opera and it-is-used-in-the-web, I think allowing those accesskeys to work should be ok. Of course if there is some *good* argument why they shouldn't work, that behavior should be standardized. br, -Olli
Re: [whatwg] Fallback styles for legacy user agents [was: Re:
From: Calogero Alex Baldacchino [EMAIL PROTECTED] Subject: Re: [whatwg] Fallback styles for legacy user agents [was: Re: Deprecating small , b ?] To: Benjamin Hawkes-Lewis [EMAIL PROTECTED] Cc: WHAT Working Group whatwg@lists.whatwg.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed The foundation style sheet may be at least a partial solution, but if the browser is not aware of an element, I guess its style could not apply at all. Anyway, a standard default style sheet could be desireable both to have a standard basic layout on all browsers (as far as possible, because of possible differences in CSS compliance) and as a potential aid for assistive UAs, since the default sheet could cover a few basic aureal properties. Regards, Alex Not too long ago I needed to provide a special section for a website which was only accessible to users of screenreaders. I collaborated with users from windows-eyes and JAWS (the 2 screenreaders with the biggest custumer-base). I got myself some trieal versions and started testing and talking... Guess what, aural styles are ignored by screenreaders (they were a year and a half ago and I am assuming they are now). I contacted one of the manufactureres and I am sorry I can't remember which one, I think it was JAWS but it could have been Windows-eyes. After a lengthy correspondance they told me what basically comes down to this: They do not support aural style sheets because they don't want us (authors) to take control away from the users. They say it is too confusing and basically non-accessible when we (authors) change voice, pitch, volume, etc. Well, in that area I can agree with them. Screenreaders are very personal tools I gather from users. Basically it is a bad idea to mark-up aural properties when it comes to accessibility. However, it would still be nice to hide/show things solely for specific UAs. But just because CSS gives us the ability to use extensive aural properties is exactly why they don't want to gice us the ability to hide/show things. Again, this information is well over a year old, so maybe they have changed policies. Still I think it is unwise to include aural properties in style sheets, default or otherwise. We must let the users choose their volume, speed, pitch, voice, etc. because that is what is helping them most (this is what I have been told by manufacturer and users). I know it is a side-issue on this topic (and has little to do with HTML) but since you mention it as an argument I just thought it might be relevant. Bert
Re: [whatwg] Solving the login/logout problem in HTML
On Wed, 26 Nov 2008, Philip Taylor wrote: If I'm not misunderstanding things, there is a new attack scenario: I post a comment on someone's blog, saying a href=/restricted-access.php?xsshole=form action=http://hacker.example.com/capture name=logininput name=usernameinput name=password/formcrawl me!/a On their blog's web server, restricted-access.php require authentication, and unauthenticated access results in a 401 with 'WWW-Authenticate: HTML form=login' and the appropriate login form. But inevitably there's some kind of XSS hole in that page, so arbitrary markup can be inserted above the real login form. (Maybe they pass an error message in a parameter, which will be displayed above the form, but they forgot to escape the output.) Their internal search engine crawler is configured to know a username and password (and the form field names etc) for these restricted areas. It follows the link from my blog comment, it notices the WWW-Authenticate header, and like a good little bot it chooses to parse the HTML page and find the matching form and fill in the fields and submit the login details. But actually it's submitting my XSS-inserted form, and sending the login details to me. XSS holes already cause various security vulnerabilities; but they can't currently result in sensibly-written crawlers unwittingly submitting their login details to arbitrary third parties, so this is a new risk. Hm, this is indeed a problem. I can imagine a few ways to avoid this problem: 1) Don't write any pages with XSS holes. 2) Detect tampering by refusing to submit login details if = 2 forms match the name. 3) Only submit login details to same-origin URLs, or to some other restricted set. 4) Configure the crawler with the form submission URL, as well as the form field names and values, so it doesn't have to trust the HTML. 5) Change WWW-Authenticate so it gives all the details (submission URL, field names, etc), so nobody has to trust the HTML. But (1) is not going to happen in reality, so we should try to minimise the damage when XSS holes exist. (2) won't work because the attacker could write '...?xsshole=...!--' and the second form would be hidden. (3) is more sensible; perhaps the spec should explicitly note that you need to be quite careful about not submitting login forms to third-party sites unless you're sure you trust them? (3) won't work anyway, since sometimes the login form is cross-domain on purpose (e.g. OpenID). But even with (3), I could write a href=/restricted-access.php?xsshole=form action=/public-pastebin.php... and the crawler would send the login details to somewhere on the same host where I could still read them back, which doesn't seem great. So (4) is more sensible. You already have to configure the crawler with the form field names, so you might as well tell it what URL to submit to, and it shouldn't parse the HTML response or care about the form element. (Then there's no need for WWW-Authenticate to even say what the form name is.) (5) is basically the same, except it's late-binding the form details rather than hardcoding them into the crawler's configuration, and so it makes it easy to change the server-side login handling without reconfiguring everyone's crawlers. If we want to go with (4) or (5) then there is no need for this to be bound to an HTML form anymore, and we should remove it from the spec. Is there anyone who can volunteer to edit this section as a separate spec? I guess I'll remove this section. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Solving the login/logout problem in HTML
On Wed, 26 Nov 2008, Jonas Sicking wrote: As I said at the F2F meeting in France, I don't think this is the right way to go. I think moving away from passwords and HTML logins are absolutely necessary. I agree. There are much better identity based authentication schemes out there. Many do have problems, but these problems can be addressed. Let's address them. I don't know how to do so. I'd much rather find a identity based solution that significantly can improve the current, really bad, situation regarding authentication. Well, given Philip`'s description of the security problem, and the observation that it needs to be changed in a way that decouples it from HTML, I'll remove the section soon. If anyone wants to edit it, please, take the text and run with it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
On Wed, 23 Apr 2008, Jon Gibbins (dotjay) wrote: For example, take that both abbr title=United States of AmericaUSA/abbr and abbr title=United Space AllianceUSA/abbr previously occurred in the document, and you *don't* want, as an author, for every future use of either term to be expanded by default (so will not provide titles for all occurrences). I then jump into the middle of a page from somewhere else and see The USA's fleet of Space Shuttles are refurbished by USA, LLC. and wonder what's going on! There's no way to tell which is which without heuristical analysis of the language, so the UA can't auto-expand based on a single previous occurrence, which I think is the behaviour you were expecting by disallowing abbrs without titles and removing the referencing. I didn't expect any autoexpading at all. Ever, even with abbr present with a title= attribute. Why would one want that? That would be really annoying. We have acronyms and abbreviations for a reason -- to make things shorter! :-) People with learning disabilities, the elderly or people unfamiliar with certain jargon may prefer to have certain, or even all, abbreviations display in their expanded form by default. I know I can never remember what all the US state codes are, for example. I still wouldn't expect title-free abbrs to expand by default, for the very reason described above. a) Documents will either mark up every acronym with an abbr title=… tag—user agents that expand these by default (primarily aural as I understand it) will appear very verbose—or, User agents that expand abbreviations by default are poor, IMHO. There are certain options to expand abbreviations in place of the abbreviated form in both JAWS and Window-Eyes screen readers, but this is not default behaviour in either case. That seems reasonable. b) Documents will only mark up the first occurrence. UAs that do not process subsequent occurrences of the abbreviation (currently all of them), will suffer from lack of definitions. I don't follow this. Why would documents only mark up the first one? I think the confusion here is that current best practice is to only mark up the first abbreviation in a page with the expansion to avoid verbose output to users. To all intents and purposes, such advice should be ignored for reasons already identified to the list (i.e. you can't know a user's entry point into a document). However, it *could* be a preference in software to only expand the first occurence thus putting control back into the hands of the user. The problem that remains is how to disambiguate abbreviations that have more than one expanded form. Authors should use the title= attribute to include the expansion if they want their pages to be clear. In my opinion, a more useful solution is to offer some form of infrastructure for glossaries where abbreviations can be uniquely identified to an expanded form. This would aid disambiguation and give control of rendering to users via their user agent. I don't see why just having the title= attribute isn't enough. I've added a note to the spec that says that authors shouldn't expect a UA to expand abbreviations just based on earlier abbr elements with the same contents. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fallback styles for legacy user agents [was: Re:
Pentasis wrote: Basically it is a bad idea to mark-up aural properties when it comes to accessibility. It does not follow from the fact that popular screen readers ignore publisher aural/speech CSS or the reasonable argument that they _should_ ignore such CSS, that providing publisher aural/speech CSS is bad for accessibility. For example, if you want to put a novel online with aural/speech CSS so it can be read aloud by Opera with the Voice plugin with those styles, there's no reason why that's bad for accessibility. It just means that providing aural/speech CSS doesn't do what well-meaning web developers sometimes imagine it should. However, it would still be nice to hide/show things solely for specific UAs. Maybe, but I wonder if in practice, the rationales for this tend to boil down to: 1. Working around bugs in someone's code. (e.g. A screen reader fails to deal with Feature X in a webpage, so the developer inserts a message for screen reader users describing a workaround.) 2. A workaround for supporting non-linear, non-gestalt browsing (e.g. additional context for lists of links in a screen reader). There may be more direct and effective ways to deal with these problems, such as * Making product support information available to all users (what if the screen reader user has a sighted companion? What if they're using a screen magnifier/reader combination?) * Fixing browsers and screen readers. * Providing explicit markup for additional context. -- Benjamin Hawkes-Lewis
Re: [whatwg] Solving the login/logout problem in HTML
Asbjørn Ulsberg wrote: [Request 1] GET /administration/ HTTP/1.1 [Response 1] HTTP/1.1 401 Unauthorized WWW-Authenticate: HTML realm=Administration !DOCTYPE html html form action=/login input name=username input type=password name=password input type=submit /form /html [Request 2] POST /login HTTP/1.1 username=adminpassword=secret [Response 2] HTTP/1.1 302 Found Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm=Administration Location: /administration/ [Request 3] GET /administration/ HTTP/1.1 Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm=Administration [Response 3] HTTP/1.1 200 OK !DOCTYPE html html ... h1Welcome!/h1 /html The twist here is that it is up to the server to provide the authentication token and through the 'Authorization' header, give the client a way to authorize future requests. Your auth token here seems to me to be equivalent to a session cookie. If you change the Authorization header in Response 2 to Set-Cookie (and make some syntactic adjustments) then this doesn't require any changes to how deployed apps handle sessions today.
Re: [whatwg] Solving the login/logout problem in HTML
Julian Reschke wrote: You can already handle the case of content that's available unauthenticated, but would potentially differ in case of being authenticated by adding Vary: Authorization to a response. According to section 14.8 of the HTTP 1.1 specification, the presence of the Authorization header field implies that the response varies by Authorization: When a shared cache (see section 13.7) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds: [some exceptions in the presence of cache-control directives] My understanding of this is that Vary: Authorization is effectively implied for all HTTP responses.
Re: [whatwg] Solving the login/logout problem in HTML
artin Atkins ha scritto: Asbjørn Ulsberg wrote: [Request 1] GET /administration/ HTTP/1.1 [Response 1] HTTP/1.1 401 Unauthorized WWW-Authenticate: HTML realm=Administration !DOCTYPE html html form action=/login input name=username input type=password name=password input type=submit /form /html [Request 2] POST /login HTTP/1.1 username=adminpassword=secret [Response 2] HTTP/1.1 302 Found Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm=Administration Location: /administration/ [Request 3] GET /administration/ HTTP/1.1 Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm=Administration [Response 3] HTTP/1.1 200 OK !DOCTYPE html html ... h1Welcome!/h1 /html The twist here is that it is up to the server to provide the authentication token and through the 'Authorization' header, give the client a way to authorize future requests. Your auth token here seems to me to be equivalent to a session cookie. If you change the Authorization header in Response 2 to Set-Cookie (and make some syntactic adjustments) then this doesn't require any changes to how deployed apps handle sessions today. Perhaps that token was meant as a cross-session one, surviving untill an explicit logout -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Innammorarsi è facile con Meetic, milioni di single si sono iscritti, si sono conosciuti e hanno riscoperto l'amore. Tutto con Meetic, prova anche tu! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8292d=26-11
Re: [whatwg] Deprecating small , b ?
Tab Atkins Jr. ha scritto: On Tue, Nov 25, 2008 at 3:08 PM, Calogero Alex Baldacchino [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Tab Atkins Jr. ha scritto: On Tue, Nov 25, 2008 at 10:24 AM, Calogero Alex Baldacchino [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Do you mean that if you had markup like pbW/bhen I was young.../p, it would be read out as I was young...? If so, that's clearly a bug in the reader, and has nothing to do with semantics or the lack of it. There is *no* legitimate interpretation of that markup that would lead one to discard the first word. I agree that a reading software unable to understand some text with unexpected typographic variants, should read it as normal text; however, I guess how the above can result in an unexpected situation, when looking for non-typographic semantics. Basically, there is a subset of authors who are morons, and they'll screw up anything we do. Most of us aren't like that, but trying to design around that subset is a game you can't win. Their pages will be FUBAR no matter what we do, until browsers' rendering engines are literally hooked up to a sentient semantic parser. Arghh!! Such a software would be too smart and dominate the world... That could think, morons are bothering; human beings generate morons; no more human beings means no more bother for me Ah, the default style could be slightly or very different from the small one, i.e. the text could be surrounded by parenthesis or hyphens, despite of the font size (and the new elements could be designed such to accept just non-empty strings consisting of more than one non-spacing character). We could, but is there any reason to have it do that? Making the text small is a good visual representation of the small print or aside semantics. The concept was (or could be - let me modify it), the more we provide alternative visual representations of the aside semantic element, the more likely a moron designer will stay far from it, since he could be confused about the style he's creating. As well, the rule there is no default style for the element could prevent authoring tools from just changing the name of a button used to style some text. But I know, all would fail because most popular browser would choose very similar rendering (or would they just follow rendering small fonts). Anyway, I wouldn't underestimate the latter characteristic (ok, that wasn't clear), that is establishing the use of the element is legal if it sorrunds a piece of text made up of one or more whole words (or at least one readable character) and if it's bounded by spacing or punctuation characters (that is, the 'semantic element' cannot be a part of a word). Of course, the misuse concern would just move from the messed-up word to a messed-up sentence, but at least, in this case, an assistive reader would be less likely fouled up and, without any need for luck, it could speak out something funny, yet understandable. Of course the same could be done redefining b and small parsing rules, but such would result in a break with a bounch of (possible) legacy uses, and if we had to break somehow with the past, why don't have a look for some more significant names? - Just to say, not hoping to persuade you :-P Here it is me not understanding. I think that any reason to offset some text from the surrounding one can be reduced to the different grade of 'importance' the author gives it, in the same meaning as Smylers used in his mails (that is, not the importance of the content, but the relevance it gets as attention focus - he made the example of the English small print idiom, and in another mail clarified that It's less important in the sense that it isn't the point of what the author wants users to have conveyed to them; it's less important to the message. (Of course, to users any caveats in the small print may be very important indeed!)). From this point of view, unless we aimed to avail of b as an intermediate grade of relevance between 'normal text' and 'em/strong' (but, aren't these enough to attract a reader's attention?), redefining its semantic might be redundant with lesser utility. (In my crazy mind, this applies to the headings too, since a 'good' heading focuses attention on the core subject of its following section, so have to be evidenced as an important slice of text). Furthermore, I meant that strong and em would have been a better choice than b in Smylers' examples because their *original semantics* is very close together with that of a more relevant text/a text needing greater attention, while b *original semantics* is very different and needs to be redefined for this purpose (but we have still got possible alternatives to this).
Re: [whatwg] Solving the login/logout problem in HTML
Ian Hickson wrote: ... Ok let me rephrase. What are the user agent requirements for processing the realm value? For other schemes, it's basically show the realm to the user as a hint as to what password is wanted. But here we aren't going to show anything to the user. ... Yes. It's the same as with Basic and Digest when used for a non-interactive login. BR, Julian
Re: [whatwg] Solving the login/logout problem in HTML
Martin Atkins wrote: ... By that line of reasoning, you could equally argue that sites don't need this authentication scheme at all since they do just fine without it today. I think this new authentication scheme is most interesting when used in conjunction with other schemes, because it allows the same endpoint to be used for both browsers and other non-browser agents. ... That would be nice in theory, but will be tricky to deploy. The current proposal may fly because it doesn't require browsers to change (well, at least as long as they display the response body when the auth scheme is unknown -- which AFAIU is the case for FF and IE). Once you add a *known* scheme such as Basic or Digest, you'll get the authentication dialogue box most site designers want to avoid. One use-case, which I hinted at in my message, is pages that contain data annotated with microformats. These are useful both to browsers and non-browser agents, but today it's cumbersome to use microformats on pages that require authentication to view, since it is difficult for a non-browser agent to figure out how to log in to an arbitrary site without human intervention. Yes, that's the same case as spiders, WebDAV, feed readers, calendaring clients, whatnot. I went ahead and did some basic testing of this case, anyway. For my initial test, I arranged for my server to send a response like this: --- HTTP/1.0 401 Unauthorized Content-type: text/html WWW-Authenticate: HTML form=login WWW-Authenticate: Basic realm=test thing html head titleLog in/title /head body h1Log in/h1 form name=login action=/login.cgi?return_to=/testauth.cgi divUsername: input type=text name=u //div divPassword: input type=text name=p //div /form /body /html --- This case didn't turn out so well: * IE7: Displayed Basic login dialog * F3: Displayed Basic login dialog * O9.5: Displayed Basic login dialog Yes. In all cases, hitting Cancel on the login dialog caused the body to be rendered as a normal page, which is better than nothing but not really ideal. I swapped the ordering so that Basic came before HTML, but the results were the same. (as you'd expect.) I figured though that in most cases if your two types of clients are browsers and non-browser clients, it's quite likely that the non-browser clients will be using OAuth rather than Basic authentication, since that seems to be the big thing right now. I swapped out Basic for OAuth in my second WWW-Authenticate header above, and the results were more promising: * IE7: Rendered the response body as a normal page * F3: Rendered the response body as a normal page * O9.5: Displayed an error: The server requested an authentication method that is not supported. Yes, once the 'other' authentication scheme is new as well, this may work. ... BR, Julian
Re: [whatwg] Solving the login/logout problem in HTML
On Wed, Nov 26, 2008 at 6:13 PM, Julian Reschke [EMAIL PROTECTED] wrote: * IE7: Rendered the response body as a normal page * F3: Rendered the response body as a normal page This behavior is what needs to be specified by this working group. The rest can be handled by authentication specifications. -- Robert Sayre
[whatwg] importScripts() no longer checking for cross-origin loads
Heads-up: Since nobody could say what security vulnerability we were protecting against in making importScripts() block cross-origin loads, I've commented out the step that enforces same-origin restrictions for importScripts(). The only vulnerabilities I can find are things that can already be done with script (e.g. slurping cookie-protected JSON). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img element: downloading a resource
On Fri, 11 Apr 2008, Anne van Kesteren wrote: On Fri, 11 Apr 2008 02:03:45 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 7 Nov 2006, Anne van Kesteren wrote: The definition of downloading a resource must be clear that even if the resource does not need to be downloaded (because it has been cached or something) the load event still needs to be dispatched (or the error event, in case it contains errors). Isn't this an HTTP issue? I suppose you could call it that. The main issue is that people are confused with the current wording and assume it either doesn't cover cached images or that in case of images being cached the text does not apply. (The Opera browser has for some time not dispatched those events because of incorrect assumptions.) So a generic note somewhere that downloading can refer to retrieving it over the network or reading it from the cache, etc. would be good. Does the current text do this to your satisfaction? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
On Thu, 27 Nov 2008, Calogero Alex Baldacchino wrote: Perhaps a silly idea: what if abbreviations could work as an img-map couple? That is, i.e., an abbr without a title could avail of a, let's say, 'ref' attribute indicating the id of a previous abbr element with a title, and the former could be 'self-closing' (i.e. abbr ref=#foo /), so by default the UA would substitute it with the referenced element content (the unexpanded abbreviation), and, at the user will (when he/she clics on the abbreviation, or just stops the pointer, or navigates to the abbreviation, or according to any setting in the browser options) the abbreviation is expanded. (I guess the above won't be agreed because of backward compatibility, though) What problem would this solve? It's not like including the abbreviation each time is a great burden. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
Ian Hickson ha scritto: On Thu, 27 Nov 2008, Calogero Alex Baldacchino wrote: Perhaps a silly idea: what if abbreviations could work as an img-map couple? That is, i.e., an abbr without a title could avail of a, let's say, 'ref' attribute indicating the id of a previous abbr element with a title, and the former could be 'self-closing' (i.e. abbr ref=#foo /), so by default the UA would substitute it with the referenced element content (the unexpanded abbreviation), and, at the user will (when he/she clics on the abbreviation, or just stops the pointer, or navigates to the abbreviation, or according to any setting in the browser options) the abbreviation is expanded. (I guess the above won't be agreed because of backward compatibility, though) What problem would this solve? It's not like including the abbreviation each time is a great burden. Right, I retire this hint. Or perhaps could work in conjunction with dfn as an explicit reference to the definition and a shorter alternative to the use of an a element. The same rationale can apply to discard this too, however... if the id were put in the abbr inside the dfn, instead of setting the dfn id, perhaps it could be a reference slightly less prone to mistakes (the more I write, the more likely I can press a wrong key inside and mess everithing up - I'm for short syntax when possible/meaningful, but this might not be the case, of course). I.e., instead of writing: a href=#gdoabbr title=Garage Door OpenerGDO/abbr/a one could just write: abbr ref=#gdo / so that, by default, the user agent automatically insterts the text 'GDO', when the user leaves the mouse pointer over it, or focuses it elsewhere, the text is expanded, and when the user clicks or activates it (i.e. by pressing 'return'), the definition is recalled. '#gdo' could be the id of the abbreviation inside the dfn element, but could work also being the dfn id itself, so both way (using the a element or the abbr one) might exist as alternatives working in a consistent manner for different uses (i.e. the a-fashion would be suitable if the defined term were a plain text or the title of the dfn element itself). Maybe still useless, if so disregard it (and forgive my insistence). Best Regards, Alex. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Attiva Carta Eureka! Credito fino a 3.000, rate da 20 e zero costi di attivazione. Conviene! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8429d=27-11
Re: [whatwg] A document's cookie context
On Fri, 13 Jun 2008, Adam Barth wrote: The current draft of the spec doesn't specify how to compute the cookie context for a document. Here is how to compute it: A document's cookie context can be represented as a URI and largely (but not exactly) follows the document's origin. 1) If the document does not have a browsing context (e.g., it was retrieved via XMLHttpRequest or created using createDocument) then it's cookie context is or about:blank (or whatever you prefer for I don't have a cookie context). 2) If the document was served over the network and has an address that uses a URI scheme with a server-based naming authority, then the document's cookie context is that URI. I've specced the above, including the handling of document.open(). 3) If the document has the URI about:blank or , then, like the origin, the document's cooke context is the cookie context of the parent browsing context (if it has a parent) or the cookie context of the opener browsing context (if it has an opener but no parent). Failing that, the document's cookie context is about:blank or (or whatever you prefer for I don't have a cookie context). I wasn't able to reproduce this. In particular, I couldn't work out what browsers were doing for the case of setting cookies on an about:blank frame. It wasn't reflecting the cookies on the parent browsing context. I've made the spec say that for these cases (specifically, when the document URI doesn't have a server-based naming authority) that .cookie always returns . If this isn't implementable, it would be helpful to have test cases demonstrating what exactly it should specify. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Error propagation in child workers
Hey folks,
I just got around to fixing the error handling in our worker
implementation and realized that the spec is a little vague here,
especially when workers are created within workers. This is what we
have now, and Jonas and I both find it intuitive and useful:
Assuming we have a page that creates a worker (let's call this worker
the parent), and it creates a new worker (the child).
First, we currently use a MessageEvent object for our 'error' events
where the 'data' property contains a string representing the
exception, but we don't really like that. We'd like to propose that we
use a new type of event, ErrorEvent, that looks like this:
interface ErrorEvent : Event {
readonly attribute DOMString message;
readonly attribute DOMString filename;
readonly attribute unsigned long lineno;
}
If the child worker experiences an unhandled exception, syntax error,
etc., then an 'error' event is fired at the child worker that will run
in the parent's execution scope. If the parent has an error handler it
will be called, and the handler can call 'event.preventDefault()' to
stop propagation. Otherwise another error event will be dispatched to
the parent's parent, etc., until we reach the top-level worker. And
finally, for Firefox at least, we plan to log an error message in the
JS console if the top-level worker doesn't have a handler and call
preventDefault (as we've found that the lack of error logging is a
common development headache).
So, what do you guys think?
-Ben Turner
