Re: [whatwg] Selectors within style scoped
On Fri, Jun 17, 2011 at 2:45 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/17/11 1:39 AM, Roland Steiner wrote: Having another scoped stylesheet under an element further up. Why does that matter for the way rules in _this_ sheet are treated? http://dev.w3.org/2006/webapi/selectors-api2/#the-scope-pseudo-class says: The :scope http://dev.w3.org/2006/webapi/selectors-api2/#scope pseudo-class *must* match any element that is a contextual reference elementhttp://dev.w3.org/2006/webapi/selectors-api2/#contextual-reference-element . so :scope is ambiguous if you have several scoping elements as ancestors. :scope in a nested sheet, meant to limit the rule to the nested scoping element, may instead match against an enclosing scoping element. Again, see the example I mailed earlier. - Roland
Re: [whatwg] Selectors within style scoped
On Fri, Jun 17, 2011 at 4:10 PM, Roland Steiner rolandstei...@google.comwrote: On Fri, Jun 17, 2011 at 2:45 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/17/11 1:39 AM, Roland Steiner wrote: Having another scoped stylesheet under an element further up. Why does that matter for the way rules in _this_ sheet are treated? http://dev.w3.org/2006/webapi/selectors-api2/#the-scope-pseudo-class says: The :scope http://dev.w3.org/2006/webapi/selectors-api2/#scope pseudo-class *must* match any element that is a contextual reference elementhttp://dev.w3.org/2006/webapi/selectors-api2/#contextual-reference-element . so :scope is ambiguous if you have several scoping elements as ancestors. :scope in a nested sheet, meant to limit the rule to the nested scoping element, may instead match against an enclosing scoping element. Again, see the example I mailed earlier. Actually, re-reading that section I think I misunderstood the meaning. If only the direct parent of a style scoped is considered a contextual reference element for rules in _that_ style-sheet (rather than an element being a contextual reference element for _some_ scoped stylesheet), there is no ambiguity. So please disregard my ramblings. - Roland
Re: [whatwg] Normalization of user selections
On Fri, Jun 17, 2011 at 4:33 AM, Ojan Vafai o...@chromium.org wrote: On Thu, Jun 16, 2011 at 12:09 PM, Ryosuke Niwa rn...@webkit.org wrote: Yes, I think all selection modified by user should be normalized by default. I'm talking more about programmatically set selection. I think we'll need to preserve programmatically set selection ranges instead of always storing normalized ranges. I disagree. That defeats all the benefits of normalizing. Now all the code that handles editing can't assume normalization. FWIW, I'm with Ryosuke on this one - NOT preserving programmatically set selections seems very dangerous to me, esp. if it's just for the sake of making it easier on the implementors. That way, neither the user NOR the programmer has complete control over what is happening in detail. On Fri, Jun 17, 2011 at 4:38 AM, Boris Zbarsky bzbar...@mit.edu wrote: Indeed. And the fact that the two DOM positions correspond to the same user-visible selection is not set in stone either. Perhaps the real answer is to use such directional hints and make it clear to the user somehow where the insertion point really is? The latter is what's hard in a wysiwyg context. Exactly my thoughts. It's unfortunate that whether 2 different positions in the DOM correspond to the same visual position cannot be determined by looking at the DOM only - for example, there may be margins or even auto-generated content around elements, that *do* neatly separate them. - Roland
Re: [whatwg] Normalization of user selections
On Thu, Jun 16, 2011 at 12:33 PM, Ojan Vafai o...@chromium.org wrote: On Thu, Jun 16, 2011 at 12:09 PM, Ryosuke Niwa rn...@webkit.org wrote: Yes, I think all selection modified by user should be normalized by default. I'm talking more about programmatically set selection. I think we'll need to preserve programmatically set selection ranges instead of always storing normalized ranges. I disagree. That defeats all the benefits of normalizing. Now all the code that handles editing can't assume normalization. We can provide a method to normalize selection to address that issue. - Ryosuke
Re: [whatwg] Hashing Passwords Client-side
Sean, thanks for the suggestion. I have the following comments (my first comment on here, please instruct me if I get the style wrong): Why? The server can first try comparing the submitted password to the stored hash, then if that fails, hash the submitted password and compare that to the stored hash. Imagine the use case where a user joins a site on a legacy browser. The legacy browser sends the un-hashed password. They then attempt to login using a modern browser, which correctly hashes the password before sending it. The authentication will fail. I see a theoretical (but potentially major) problem accepting a) Accepting the hashed value blindly and b) Multiple passwords being accepted by the server. Currently my browser accepts the value password1 to an input name=pass type=password/ field, sends it in the POST data as pass=password1 and my serverside encrypts it to the (non-salted for ease of example) MD5 7c6a180b36896a0a8c02787eeafb0e4c. I find a lot of safety in the knowledge that I can't do anything malicious with a well-encrypted password even though I can read the encrypted value clearly in the DB. If, however, my browser made the request should include pass=7c6a180b36896a0a8c02787eeafb0e4c then I can copy and paste your hashed password into a curl request and log in as you, or do the same after manipulating the input/ field to remove hashing instructions. There needs to be a way for the server to distinguish when the hash has been correctly applied. As mentioned in a previous e-mail, I would imagine this work being done by a server-side framework automatically (eventually). There is a theoretical and pedantic use-case where I as a user can have a 32 char hex-decimal password which looks like an MD5. In this case how would any framework distinguish between my browser's MD5 and my intentionally written 32 char hex-deci password? To summarise: I feel that client-side hashing does not add the security it seems to on the surface and it would add some potential new issues. A developer who is able to store a password on the server-side should be encouraged to encrypt it on the serverside and I feel that this addition would encourage excited HTML5 on-lookers into what I would consider to be a false-sense of security. Mat Carey
Re: [whatwg] Selectors within style scoped
On 2011-06-17 09:36, Roland Steiner wrote: On Fri, Jun 17, 2011 at 4:10 PM, Roland Steinerrolandstei...@google.comwrote: http://dev.w3.org/2006/webapi/selectors-api2/#the-scope-pseudo-class says: The :scopehttp://dev.w3.org/2006/webapi/selectors-api2/#scope pseudo-class *must* match any element that is a contextual reference elementhttp://dev.w3.org/2006/webapi/selectors-api2/#contextual-reference-element. so :scope is ambiguous if you have several scoping elements as ancestors. :scope in a nested sheet, meant to limit the rule to the nested scoping element, may instead match against an enclosing scoping element. Again, see the example I mailed earlier. Actually, re-reading that section I think I misunderstood the meaning. If only the direct parent of astyle scoped is considered a contextual reference element for rules in _that_ style-sheet (rather than an element being a contextual reference element for _some_ scoped stylesheet), there is no ambiguity. That is correct. However, note that the definition of :scope itself does not define which elements are the contextual reference elements (except where it defaults to the document root element) and it can it theory support more than one [1]. But it is up to the specification defining a particular context to define what the contextual reference elements are, and HTML5 needs to define that the contextual reference element for a given scoped stylesheet is its parent element. [1] In fact, the refNodes parameter of the querySelector* methods explicitly allows there to be more than one in that context. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Hashing Passwords Client-side
Hi Mat, The simple solution to your problem is: The server SHOULD still hash the password it receives, before storing it in the database (i.e., the client would send a hashed password, and the server would hash the hash). Ideally, all servers should be doing this, with per-user salts. However, the reality is that many servers do not, or they use compromised hash functions (specifically, md5 with no salt). Your use case is possible, where a naive webmaster blindly copies the client-hashed value into the database. Just as webmasters today blindly copy the plain-text password into databases. The proposal helps to add security to these (unfortunate) use cases. Ideally, the client AND server would hash the password. We cannot control the server, but we can control the client. So this proposal attempts to standardize the client-side hashing. Please note an additional benefit: with this proposal, passwords are not sent as plain-text over HTTP. This improves security for many use cases (with the exception of HTTPS, and webmasters who already use JavaScript to locally hash the password before sending). There is a theoretical and pedantic use-case where I as a user can have a 32 char hex-decimal password which looks like an MD5. In this case how would any framework distinguish between my browser's MD5 and my intentionally written 32 char hex-deci password? In the proposal, I suggested a new header value to be sent by the client when the password is hashed: X-Password-Hash: 1 Tab Atkins Jr. suggested, instead of a new header, that the browser should synthesize a new form value to submit, which has the benefit that JavaScript could be used by legacy browsers to upgrade their behavior. Thank you for the feedback. ~Sean On Fri, Jun 17, 2011 at 5:17 AM, Mat Carey m...@matcarey.co.uk wrote: Sean, thanks for the suggestion. I have the following comments (my first comment on here, please instruct me if I get the style wrong): Why? The server can first try comparing the submitted password to the stored hash, then if that fails, hash the submitted password and compare that to the stored hash. Imagine the use case where a user joins a site on a legacy browser. The legacy browser sends the un-hashed password. They then attempt to login using a modern browser, which correctly hashes the password before sending it. The authentication will fail. I see a theoretical (but potentially major) problem accepting a) Accepting the hashed value blindly and b) Multiple passwords being accepted by the server. Currently my browser accepts the value password1 to an input name=pass type=password/ field, sends it in the POST data as pass=password1 and my serverside encrypts it to the (non-salted for ease of example) MD5 7c6a180b36896a0a8c02787eeafb0e4c. I find a lot of safety in the knowledge that I can't do anything malicious with a well-encrypted password even though I can read the encrypted value clearly in the DB. If, however, my browser made the request should include pass=7c6a180b36896a0a8c02787eeafb0e4c then I can copy and paste your hashed password into a curl request and log in as you, or do the same after manipulating the input/ field to remove hashing instructions. There needs to be a way for the server to distinguish when the hash has been correctly applied. As mentioned in a previous e-mail, I would imagine this work being done by a server-side framework automatically (eventually). There is a theoretical and pedantic use-case where I as a user can have a 32 char hex-decimal password which looks like an MD5. In this case how would any framework distinguish between my browser's MD5 and my intentionally written 32 char hex-deci password? To summarise: I feel that client-side hashing does not add the security it seems to on the surface and it would add some potential new issues. A developer who is able to store a password on the server-side should be encouraged to encrypt it on the serverside and I feel that this addition would encourage excited HTML5 on-lookers into what I would consider to be a false-sense of security. Mat Carey
Re: [whatwg] on* attributes on DOM elements
On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky bzbar...@mit.edu wrote: It looks like Gecko, Presto, and Webkit all support on* event attributes on all DOM elements, not just HTMLElement. IE9 seems to only support them on HTMLElement. I would propose that these be supported on all Elements at least for events that are not element-specific (e.g. click). Should they move to DOM Core then? (I.e. those that are generic.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Hashing Passwords Client-side
Thanks Sean, The server SHOULD still hash the password it receives, before storing it in the database (i.e., the client would send a hashed password, and the server would hash the hash) I agree, but if the server-side hashing should be implemented regardless of whether the client-side hashes then are we truly adding a feature? If not then I fear we are merely adding issues caused by legacy browsers co-existing with current/future browsers as highlighted in your original post (disadvantage 2 stated Server-side code might be complicated for dealing with legacy, non-hashing browsers). Your use case is possible, where a naive webmaster blindly copies the client-hashed value into the database. Just as webmasters today blindly copy the plain-text password into databases. The proposal helps to add security to these (unfortunate) use cases. My (potentially controversial) opinion is that even though these 'unfortunate' cases may seem to benefit from a client-side hash the same webmasters may be unaware of the need for legacy support and that client-side hashing will not secure their passwords at a DB/HTTP level. I fear we would be encouraging more webmasters/developers to follow the client-side hashing will be to the detriment of server-side hashing. A developer who is able to implement a database storage in a server-side language should be able to encrypt in that language, if this is true they should be strongly encouraged to do this on the server-side and not confused by adding client-side hashing. I feel client-side hashing implies to the partially-informed webmaster/developer that server-side hashing can be replaced by client-side hashing which would lead to more security holes across the web. the browser should synthesize a new form value to submit, which has the benefit that JavaScript could be used by legacy browsers to upgrade their behavior. There is no guarantee that your user is using Javascript, which means this upgrade would not be available and it accidentally becomes the same as TJ's suggestion: (from Tab Atkins Jr. 16th June 2011 22:08:36 GMT+01:00) you can just ignore legacy browsers and store the passwords directly. Those older browsers will just have security vulnerabilities. The problem I see here is that I can register using one browser (e.g. FF3.6 with JS off or an accessible browser which doesn't run JS) and my password is sent (and potentially stored) in plain text (described as 'just have security vulnerabilities'), then try to login in after the FF comes out supporting this feature and I will be unable to log in because my hashed password that is now sent does not equate to the unhashed version which is stored. This problem also exists the other way around and pushes the developer/webmaster into the position where they need to allow pre-hashed and plain-text passwords to be sent from the browser. I feel a can of worms could be opened and not easily closed. I am of the opinion that the cross-browser/legacy-browser issues that _could_ come from this are very hard to recover from and _even if_ it were fully cross-browser and legacy-browser compatible I don't see a strong enough reason to rely upon it as users would be able to tamper with the fields and request data mitigating any potential security benefit. NOTE: I am assuming it goes without saying that SSL should be used for registrations, logins etc. _even if_ this client-side hashing is present. To qualify some of my position I feel it's worth mentioning that I have consulted on a large site (which was created years before I was involved) where there are is a mix of MD5'd and plain text passwords - it's a situation I would not want to encourage anyone to get themselves into and some of the circumstances I have commented on have been real problems for that site. Mat Carey
Re: [whatwg] on* attributes on DOM elements
On 6/17/11 8:49 AM, Anne van Kesteren wrote: On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky bzbar...@mit.edu wrote: It looks like Gecko, Presto, and Webkit all support on* event attributes on all DOM elements, not just HTMLElement. IE9 seems to only support them on HTMLElement. I would propose that these be supported on all Elements at least for events that are not element-specific (e.g. click). Should they move to DOM Core then? (I.e. those that are generic.) That would make the most sense to me. -Boris
Re: [whatwg] on* attributes on DOM elements
On 6/17/11 12:57 PM, Boris Zbarsky wrote: On 6/17/11 8:49 AM, Anne van Kesteren wrote: On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky bzbar...@mit.edu wrote: It looks like Gecko, Presto, and Webkit all support on* event attributes on all DOM elements, not just HTMLElement. IE9 seems to only support them on HTMLElement. I would propose that these be supported on all Elements at least for events that are not element-specific (e.g. click). Should they move to DOM Core then? (I.e. those that are generic.) That would make the most sense to me. And to be clear, I'm talking here about IDL attributes, not content attributes. -Boris
Re: [whatwg] Normalization of user selections
On 6/17/11 1:40 PM, Aryeh Gregor wrote: At a minimum, for instance, we could guarantee that a selection's boundary point is always in a Text or Element node that descends from a Document. That would be a big simplification by itself. Does anyone object to that? At first blush, that seems reasonable to me. -Boris
Re: [whatwg] Question about certain cases for popstate event
On Wed, Jun 15, 2011 at 8:42 PM, Ian Hickson i...@hixie.ch wrote: Google Chrome 10 seems to fire popstate even if I open totally new page. Firefox 4 seems to fire event only on going back/forward How are you determining if Firefox fires the event? Are you sure you're not just checking after Firefox has fired it? Firefox does this intentionally (http://hacks.mozilla.org/2011/03/history-api-changes-in-firefox-4/), and Chrome will be changing to follow suit (http://crbug.com/63040). http://www.w3.org/Bugs/Public/show_bug.cgi?id=12707 is open about this, I'm not sure if there's been any spec changes. Mihai
Re: [whatwg] on* attributes on DOM elements
On Fri, 17 Jun 2011, Boris Zbarsky wrote: On 6/17/11 12:57 PM, Boris Zbarsky wrote: On 6/17/11 8:49 AM, Anne van Kesteren wrote: On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky bzbar...@mit.edu wrote: It looks like Gecko, Presto, and Webkit all support on* event attributes on all DOM elements, not just HTMLElement. IE9 seems to only support them on HTMLElement. I would propose that these be supported on all Elements at least for events that are not element-specific (e.g. click). Should they move to DOM Core then? (I.e. those that are generic.) That would make the most sense to me. And to be clear, I'm talking here about IDL attributes, not content attributes. Since the IDL attributes just reflect the content attributes, I don't know how that could be separated. The main reason I didn't put them on Element rather than HTMLElement is that I didn't expect other vocabularies would appreciate it. My ideal solution would be for all event handlers for all elements supported by a browser to be supported on all Element, Node, and Window objects, but that might be a bit far. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Question about certain cases for popstate event
On Fri, 17 Jun 2011, Mihai Parparita wrote: On Wed, Jun 15, 2011 at 8:42 PM, Ian Hickson i...@hixie.ch wrote: Google Chrome 10 seems to fire popstate even if I open totally new page. Firefox 4 seems to fire event only on going back/forward How are you determining if Firefox fires the event? Are you sure you're not just checking after Firefox has fired it? Firefox does this intentionally (http://hacks.mozilla.org/2011/03/history-api-changes-in-firefox-4/), and Chrome will be changing to follow suit (http://crbug.com/63040). http://www.w3.org/Bugs/Public/show_bug.cgi?id=12707 is open about this, I'm not sure if there's been any spec changes. The spec has been updated to match the above, which is why I ask how the OP was testing Firefox. The event still fires, it just probably fires before any event handlers have been registered. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hashing Passwords Client-side
On Thu, Jun 16, 2011 at 5:39 PM, Daniel Cheng dch...@chromium.org wrote: A variation of this idea has been proposed in the past but was largely seen as undesirable--see http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In general, I feel like the same objections are still true of this proposal. This proposal is considerably better formulated than that one was. But yes, in the end, the only real benefit is that the user can confirm that their original plaintext password can only be retrieved by brute-forcing the hash, which protects them only against reuse of the password on different sites. So on consideration, it will probably lead more to a false sense of security than an actual increase in security, yes. It no longer seems like a good idea to me. On Thu, Jun 16, 2011 at 7:28 PM, Sean Connelly s...@pbwhere.com wrote: This strikes me as abnormal; I'm not aware of the browser injecting form values for any other functionality. However, one benefit of this method is that a developer can create a JavaScript file to drop in to pages that will perform hashing for legacy browsers. The JavaScript could check to see if the browser performs hashing, and if not, add listeners on all form submissions. It could hash the password fields prior to submission, and inject the the synthesized form value. This would provide a path for legacy support. Side point: there are some existing cases where magic form values are injected. input type=image submits .x and .y values, for instance. The disadvantage to this approach is that, years from now, the default may be compromised (like md5). Another side point: MD5 is actually not compromised for the purposes of password storage. There are collision attacks, but no preimage attacks. Even MD4, which has had a working collision attack since 1995, still has nothing more than a theoretical preimage attack. So this isn't a huge worry in practice. Collision attacks aren't relevant to our use-case. (But don't use MD5 for things like certificate signing where collision resistance is important!) Yes, the site should. In fact, the webmaster should be doing additional hashing on the server side. However, we can't control that. If the webmaster is clueless and just stores the data directly (which webmasters do in the real world, unfortunately), at the very least, this solution will improve security. Only in one very narrow case: it will prevent a passive network attacker or someone who compromises the database from learning the original plaintext password without brute-forcing the hash. It will not stop them from logging in as the user on the same site, only from logging in as the user on other sites. On the other hand, administrators would be likely to assume that because the passwords now look like gibberish, they must be secure, which is totally wrong. Proper use of server-side hashing will leak no info about passwords to an attacker at all without brute-forcing, and proper use of client+server-side hashing will leak no info about passwords to a passive network attacker without brute-forcing. Making it easy to do hashing badly will discourage people from doing it well. I've read some of the thread... Please keep in mind that my proposal is not a catch-all solution to password management. It is intended to solve one specific problem. It is intended to be incremental progress. The problem is it solves much less of the problem than hashing is supposed to solve, but to the uninitiated it looks the same as a real hashing scheme. It gives a false sense of security that probably outweighs any actual security benefit (which is very limited).
Re: [whatwg] Normalization of user selections
Since I've somehow managed to send from the wrong address again for
the third time in 48 hours, here's yet another resent mail, probably
to be followed by a fourth when I respond to Boris' response and Gmail
auto-selects my non-list address again for the from address instead of
my list address:
On Thu, Jun 16, 2011 at 3:09 PM, Ryosuke Niwa rn...@webkit.org wrote:
What if we had foob/bi/ibar?
Well, what's the use-case?
Yes, I think all selection modified by user should be normalized by default.
I'm talking more about programmatically set selection. I think we'll need
to preserve programmatically set selection ranges instead of always storing
normalized ranges.
Normalizing the selection even when the author sets it is helpful
because it prevents authoring mistakes. For instance, if the author
wants to put the cursor at the end of an element, they might just do
getSelection().collapse(el, el.childNodes.length). But if the element
happens to be pfoobr/p, that's not what the author wants: if the
user types, it will insert text on a new line, when the br actually
has no visual effect and the cursor should go before it. So it would
help authors if pfoobr{}/p were automatically normalized to
pfoo{}br/p.
(br handling in this sort of situation is an absolute nightmare,
incidentally. I handle the really common cases currently in my
algorithms, but anything trivially different like
pfoospanbr/span/p will cause tons of stuff to break. It's
on my todo list, but there's only so much I can do without writing
some explicit and complicated description based on the CSS box model .
. .)
Still, since IE and Gecko already don't normalize, and we now have two
WebKit people against normalizing (you and Roland -- although Ojan in
favor), it seems like not normalizing is the more plausible path.
However, I'd still like to normalize author-set selections somewhat.
At a minimum, for instance, we could guarantee that a selection's
boundary point is always in a Text or Element node that descends from
a Document. That would be a big simplification by itself. Does
anyone object to that?
On Thu, Jun 16, 2011 at 3:12 PM, Boris Zbarsky bzbar...@mit.edu wrote:
As an actual user of editors, by the way, the #1 thing that pisses me off
about wysiwyg editors is precisely having situations like the one above and
wanting to be able to make the text be bfoo/borbar in some cases but
bfoopy/bbar in others. Wysisyg editors tend to be terrible at this
sort of thing. Is that something that's inevitable, or can we do better
here?
I don't know. I'm happy to hear suggestions.
On Thu, Jun 16, 2011 at 3:30 PM, Ojan Vafai o...@chromium.org wrote:
I agree it's unfortunate. I'm not sure we can do better though. The
advantage of Aryeh's suggested normalization is that it matches nearly every
popular word processor on the market, so is most likely to match user
expectations.
And all browser engines except Gecko now, too. I got it from your
writeup about contenteditable.
That said, I would like there to be declarative control over how the
normalization happens. For example, if I'm writing a custom widget, whether
typing should go inside or outside is different depending on the widget.
This is probably not the best API, but here's a concrete proposal to control
selection normalization at the end of an node.:
document.setSelectionNormalization(INSIDE/OUTSIDE, varargs of selectors);
Ouch, that looks very unpleasant. What's the exact use-case here?
On Fri, Jun 17, 2011 at 4:01 AM, Roland Steiner
rolandstei...@google.com wrote:
FWIW, I'm with Ryosuke on this one - NOT preserving programmatically set
selections seems very dangerous to me, esp. if it's just for the sake of
making it easier on the implementors. That way, neither the user NOR the
programmer has complete control over what is happening in detail.
As I note above, there are benefits to authors too -- we can avert
some types of mistakes. An explicit normalize() method as Ryosuke
suggests would only help authors who actually use it. But as I said,
given feedback so far, it looks like I'll be going for only minimal
normalization of author-set selections.
Exactly my thoughts. It's unfortunate that whether 2 different positions in
the DOM correspond to the same visual position cannot be determined by
looking at the DOM only - for example, there may be margins or even
auto-generated content around elements, that *do* neatly separate them.
Yeah, it's really depressing how huge and elaborate the CSS dependency
would have to be to fully account for all this sort of stuff.
Realistically, I think the spec is going to have to be defined in
terms of the DOM with only minimal CSS interaction -- although of
course it needs some -- and we'll have to accept that there will be
failures in corner cases. I don't want to have to go down the path of
talking about things like containing blocks and so on. If nothing
else, a JavaScript test implementation would be
Re: [whatwg] Hashing Passwords Client-side
Thank you for your input. I had forgotten about the input type=image fields. Yes, as these issues have been brought up, I've also imagined additional disadvantages as well. For documentation purposes, here are some additional items to consider if this topic comes up again: 1. I'm not clear how a server-side framework could automatically apply hashes to password fields from legacy browsers. The framework would not be able to identify which form values were password fields (and therefore, which ones it would need to hash). 2. Some use cases for password fields are simply to mask what the user is typing, and SHOULDN'T be hashed. For example, I have seen financial/government sites that mask SSN input through a password field. Their intention is never to hash the value. 3. As Mat brought up, I think it is reasonable to imagine webmasters who think client-side hashing is good enough. This can give them a false sense of security. Ultimately, I think my next step is to develop a JavaScript library that implements the behavior (by perhaps injecting .hash form values). This can help me to figure out the details in private, and see if this is worthwhile to include in the HTML standard. I may return to WHATWG in the future with my results if I feel there is a tangible benefit. Thanks again for everyone who contributed to help me think through this problem. ~Sean On Fri, Jun 17, 2011 at 2:34 PM, Aryeh Gregor simetrical+...@gmail.comwrote: On Thu, Jun 16, 2011 at 5:39 PM, Daniel Cheng dch...@chromium.org wrote: A variation of this idea has been proposed in the past but was largely seen as undesirable--see http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In general, I feel like the same objections are still true of this proposal. This proposal is considerably better formulated than that one was. But yes, in the end, the only real benefit is that the user can confirm that their original plaintext password can only be retrieved by brute-forcing the hash, which protects them only against reuse of the password on different sites. So on consideration, it will probably lead more to a false sense of security than an actual increase in security, yes. It no longer seems like a good idea to me. On Thu, Jun 16, 2011 at 7:28 PM, Sean Connelly s...@pbwhere.com wrote: This strikes me as abnormal; I'm not aware of the browser injecting form values for any other functionality. However, one benefit of this method is that a developer can create a JavaScript file to drop in to pages that will perform hashing for legacy browsers. The JavaScript could check to see if the browser performs hashing, and if not, add listeners on all form submissions. It could hash the password fields prior to submission, and inject the the synthesized form value. This would provide a path for legacy support. Side point: there are some existing cases where magic form values are injected. input type=image submits .x and .y values, for instance. The disadvantage to this approach is that, years from now, the default may be compromised (like md5). Another side point: MD5 is actually not compromised for the purposes of password storage. There are collision attacks, but no preimage attacks. Even MD4, which has had a working collision attack since 1995, still has nothing more than a theoretical preimage attack. So this isn't a huge worry in practice. Collision attacks aren't relevant to our use-case. (But don't use MD5 for things like certificate signing where collision resistance is important!) Yes, the site should. In fact, the webmaster should be doing additional hashing on the server side. However, we can't control that. If the webmaster is clueless and just stores the data directly (which webmasters do in the real world, unfortunately), at the very least, this solution will improve security. Only in one very narrow case: it will prevent a passive network attacker or someone who compromises the database from learning the original plaintext password without brute-forcing the hash. It will not stop them from logging in as the user on the same site, only from logging in as the user on other sites. On the other hand, administrators would be likely to assume that because the passwords now look like gibberish, they must be secure, which is totally wrong. Proper use of server-side hashing will leak no info about passwords to an attacker at all without brute-forcing, and proper use of client+server-side hashing will leak no info about passwords to a passive network attacker without brute-forcing. Making it easy to do hashing badly will discourage people from doing it well. I've read some of the thread... Please keep in mind that my proposal is not a catch-all solution to password management. It is intended to solve one specific problem. It is intended to be incremental progress. The problem is it solves much less of the
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Wed, 1 Jun 2011, ilya goberman wrote: Can EventSource be enhanced to support cross-domain requests via Access-Control-Allow-Origin header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. Done. On Wed, 1 Jun 2011, Jonas Sicking wrote: We should probably consider adding the ability to specify if you want the request to happen with or without credentials (and default to the safe option which is without credentials). Why? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Selectors within style scoped
On Thu, 16 Jun 2011 19:32:42 +0100, Dimitri Glazkov
dglaz...@chromium.org wrote:
What if we do this:
1) By default, style scoped implies that all selectors in this
stylesheet are prefixed with :scope.
2) Unless the :scope is already in the selector.
That feels magical and a bit backwards to me.
Why not scope all selectors except ones starting with :root?
.foo {scoped}
:root .foo {matches outside scope}
--
regards, Kornel Lesiński
Re: [whatwg] Question about certain cases for popstate event
2011/6/17 Ian Hickson i...@hixie.ch: On Fri, 17 Jun 2011, Mihai Parparita wrote: On Wed, Jun 15, 2011 at 8:42 PM, Ian Hickson i...@hixie.ch wrote: Google Chrome 10 seems to fire popstate even if I open totally new page. Firefox 4 seems to fire event only on going back/forward How are you determining if Firefox fires the event? Are you sure you're not just checking after Firefox has fired it? Firefox does this intentionally (http://hacks.mozilla.org/2011/03/history-api-changes-in-firefox-4/), and Chrome will be changing to follow suit (http://crbug.com/63040). http://www.w3.org/Bugs/Public/show_bug.cgi?id=12707 is open about this, I'm not sure if there's been any spec changes. The spec has been updated to match the above, which is why I ask how the OP was testing Firefox. The event still fires, it just probably fires before any event handlers have been registered. Have you really fixed bug 12707? Note that this is not the initial bug filed on making the spec follow the mozilla proposed changes. If bug 12707 really has been fixed, it would be great if you could mention this in the bug and close it. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12707 / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Fri, Jun 17, 2011 at 12:57 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 1 Jun 2011, ilya goberman wrote: Can EventSource be enhanced to support cross-domain requests via Access-Control-Allow-Origin header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. Done. On Wed, 1 Jun 2011, Jonas Sicking wrote: We should probably consider adding the ability to specify if you want the request to happen with or without credentials (and default to the safe option which is without credentials). Why? For the same reasons that we're doing it for XHR and for imgs. People will likely want to create even streams that are specific to a user. For example indicating that the value of a users stock portfolio has gone up or down. / Jonas
Re: [whatwg] Question about certain cases for popstate event
On Fri, 17 Jun 2011, Jonas Sicking wrote: 2011/6/17 Ian Hickson i...@hixie.ch: On Fri, 17 Jun 2011, Mihai Parparita wrote: On Wed, Jun 15, 2011 at 8:42 PM, Ian Hickson i...@hixie.ch wrote: Google Chrome 10 seems to fire popstate even if I open totally new page. Firefox 4 seems to fire event only on going back/forward How are you determining if Firefox fires the event? Are you sure you're not just checking after Firefox has fired it? Firefox does this intentionally (http://hacks.mozilla.org/2011/03/history-api-changes-in-firefox-4/), and Chrome will be changing to follow suit (http://crbug.com/63040). http://www.w3.org/Bugs/Public/show_bug.cgi?id=12707 is open about this, I'm not sure if there's been any spec changes. The spec has been updated to match the above, which is why I ask how the OP was testing Firefox. The event still fires, it just probably fires before any event handlers have been registered. Have you really fixed bug 12707? Note that this is not the initial bug filed on making the spec follow the mozilla proposed changes. If bug 12707 really has been fixed, it would be great if you could mention this in the bug and close it. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12707 Ah, no, hadn't seen that one. Will fix that in due course also. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Fri, 17 Jun 2011, Jonas Sicking wrote: On Wed, 1 Jun 2011, Jonas Sicking wrote: We should probably consider adding the ability to specify if you want the request to happen with or without credentials (and default to the safe option which is without credentials). Why? For the same reasons that we're doing it for XHR and for imgs. For EventSource, the vast majority of streams are going to be user-specific, as far as I can tell, so the default should probably just be to send credentials. (That's what happens with script, the current way people try to solve this problem.) The reason we _didn't_ send credentials by default for img was that most cross-origin images are going to be static, and it would be a huge pain for the server to have to do per-connection work to determine the HTTP headers each time. With EventSource, that's a non-issue, since the server is going to have to do lots of much heavier per-connection work anyway. People will likely want to create even streams that are specific to a user. For example indicating that the value of a users stock portfolio has gone up or down. Agreed. But what's the use case for _not_ sending credentials here? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Fri, Jun 17, 2011 at 5:31 PM, ilya goberman gober...@msn.com wrote: I do not really understand what specify the request to happen with credentials really mean. Can someone explain or point to an example? My opinion is that it should be the same for the XHR and EventSource and should also be backward compatible. We currently generate Access-Control-Allow-Origin:* in the server responses for the XHR requests to allow cross-domain calls (and do not really do anything beyond that) and I hope it will not be broken with these new credentials validation changes. Thanks I'd love to hear more about this as it's directly related to the question Hixie asked. I take it you are sending that header from some set of URLs on your servers, which are then loaded using XHR (XDR in IE) from other sites? And you are wanting to (or perhaps are already) structuring that data such that it can be used with EventSource once browsers support it, and support using it in cross-site scenarios? Am I correct so far? If so, what type of data are you returning from these URLs? Given the header you are sending, it seems like this is not personalized data, but rather generic data which looks the same no matter which users browser is reading it. Or more specifically, you are not personalizing the response from these requests based on the users cookies, is this correct? Thanks! / Jonas
