[Bug 26480] Author style max-width/height can interfere with style
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26480 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Anne ann...@annevk.nl --- https://github.com/whatwg/fullscreen/commit/134cdeb6d6d3f7c3bdb3c9df754185c24a59353f -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26493] New: Null dereference in exitFullscreen()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26493 Bug ID: 26493 Summary: Null dereference in exitFullscreen() Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Fullscreen Assignee: ann...@annevk.nl Reporter: phil...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org In both of these steps, doc can be null: 3.4.3. Remove the top element of doc's fullscreen element stack. 3.5. Let topLevelDoc be doc's top-level browsing context's document. It looks like and to null otherwise could be replaced by the equivalent of break and then lastDoc can go as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26493] Null dereference in exitFullscreen()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26493 Philip Jägenstedt phil...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
Write-only form fields (was Re: Proposal for a credential management API.)
Forking this out into a separate thread, as I think it's a great idea, but tangential to the original proposal. :) TL;DR: I put together a strawman based on these suggestions which defines a 'writeonly' attribute on HTMLInputElement: http://projects.mikewest.org/credentialmanagement/writeonly/, WDYT? On Thu, Jul 31, 2014 at 6:37 PM, Brian Smith br...@briansmith.org wrote: And/or the password form could be annotated with an attribute that indicates for which domain an XHR should be allowed to submit the password to. And/or, you could have a submit-password CSP directive to indicate which domains passwords are allowed to be submitted to. We already have 'form-action', I think that serves the purpose suitably well: https://w3c.github.io/webappsec/specs/content-security-policy/#directive-form-action particular, if we are worried about XSS stealing passwords then we have to consider the possibility that XSS has inserted a form without any httponly attributes being used, right? Correct. I think we'd also want a new CSP directive which toggles write-only status for all password fields on a given page: how about http://projects.mikewest.org/credentialmanagement/writeonly/#credentials-directive ? I was thinking the placeholder would be a base64url-encoded cryptographically-random nonce of sufficient length, so that the browser can replace the placeholders within arbitrary HTTP requests, regardless of (most) use of JS to mangle forms before submitting them, and without worrying about replacing the wrong part. I agree, but I don't think we need to specify this normatively. User agents will know what they can easily replace and what they can't, if they choose to go down a nonce route. This would work with (C) too, would it not? It may be a good idea to add an attribute to XHR to trigger such replacement, so that the browser doesn't have to attempt substitution for every HTTP request. I think we'd be able to get away with relying on magical UA behavior: if the browser process hands a nonce to a renderer, it can set a flag, and then look at POSTs generated by the page. As soon as one POST contains the nonce, clear the flag. My suspicion is that most login pages don't do much POSTing, so the overhead would be trivial. I'd prefer that approach, because I don't think we want to expose the actual mechanics to the web. The website shouldn't need to care about whether or not the password it's received is the real password or not. Based on a quick read of Mike's proposal, this would require Mike's proposed API to change to pass around tokens that represent passwords, instead of the password values themselves. This would add complication, but it would be useful. This approach adds complication to the UA's implementation, but shouldn't add complexity to the site consuming the API. This would probably not interact well with use of the WebCrypto API to encrypt the contents of input fields (passwords, credit card numbers, etc.) before submission. I'm pretty happy to break that use case, given that the credential API I've proposed is locked to secure origins. There's no advantage to using WebCrypto to doubly encrypt the password in this context, and I don't think it's something we should encourage. Thanks! -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: Proposal for a credential management API.
Hi Mike, On 31/07/2014 09:48 , Mike West wrote: It's not clear to me that WebApps is the right venue from a process perspective, but this is almost certainly the right group of people to evaluate the proposal. Thanks in advance for your feedback, suggestions, and time. :) As you know I think that a solution in this space is absolutely needed and I like your approach, I think it's on to the right set of use cases. There are some paper cuts with your proposal but nothing I've seen that can't be ironed out. Concerning the process part, I'd like to only worry about that as much as needed, which shouldn't be a lot. We can work something out and come back to you with a solution to make this happen. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: =[xhr]
In this case, a freeze on all browser operations is desirable. The thread
cannot be interrupted, and if it is interrupted (by browser closure or
other such) then the transactions are immediately stopped and no update
will occur (this is the most desirable outcome.) Async is not desirable,
since it gives control back to the browser and the user has a false
impression that interaction may be ok or even desirable. In this case it
is not, it is an all stop until complete requirement. I use both async
and sync xmlhttprequests, and they both have their place. Please do not
deprecate sync requests simply because you cannot imagine where they would
be desirable. When they are needed, they are ABSOLUTELY needed and async
requests are not only NOT desirable, but can lead to potentially
disastrous results.
From: Tab Atkins Jr. jackalm...@gmail.com
To: nmork_consult...@cusa.canon.com,
Cc: public-webapps public-webapps@w3.org
Date: 07/31/2014 03:47 PM
Subject:Re: =[xhr]
On Tue, Jul 29, 2014 at 1:41 PM, nmork_consult...@cusa.canon.com wrote:
While debugging an intranet application using xmlHttpRequest recently, I
got
a message on the Firefox browser console: Synchronous XMLHttpRequest on
the
main thread is deprecated because of its detrimental effects to the end
user's experience.
This worries me, since many useful web browser features which are
deprecated eventually disappear (e.g. CSS width specification in the
col
tag.)
This is definitely one of those things.
I have an application which makes many http requests to make multiple
large updates to database work tables, finally running a single SQL
xmlHttpRequest to copy all work table data to the main data tables after
all
updates are successful.
1. The volume and size of the data is too large to be sent by a single
request
2. Each subsequent request cannot be submitted until the prior request
is
completed SUCCESSFULLY or the database will be corrupted
3. The final SQL acts as the commit for the whole shebang and has its
own
BEGIN TRANSACTION and COMMIT/ROLLBACK for safety
In this case, synchronous xmlHttpRequests are not only NOT deprecated,
they
are ABSOLUTELY ESSENTIAL to provide reliable database updating for the
end
user, and reliability is what the end user most desires, in addition to
IMMEDIATE FEEDBACK whether the update succeeded or not.
None of what you have described requires a synchronous XHR; it can all
be done with async XHR. You just wait to send the subsequent batches
of data until the listener from the previous one informs you that it
has succeeded. This is slightly more complicated than doing sync, but
no slower (and possible faster, if some of them can be done in
parallel), and just as reliable.
You get feedback exactly as quickly, modulo a millisecond or two of
accumulated delay from waiting for your listener to reach the top of
the message queue.
Your users get a vastly better experience out of it, too. Synchronous
XHR freezes the JS main thread until it returns, which means that any
interaction with the page is frozen too. (Users *might* be able to
scroll, if the browser is doing scrolling on another thread, but
that's about it.) Multiple large consecutive sync XHRs mean things
are frozen for a noticeable amount of time, especially if the network
is slow for whatever reason. Async XHR has none of this problem.
The last person on this list to assert that they absolutely needed
sync XHR didn't seem to understand what async XHR was. (They seemed
to think it was related to form submission; I don't know what you
think it is.) It's exactly identical to sync XHR, but rather than
freezing javascript until the response comes back, and giving you the
result as a return value, you just have to register an event listener
which'll get called when the response comes back, passing the result
as an argument to your callback. Spreading your logic across
callbacks is a little bit more complicated than doing sync code, but
it's a necessary part of tons of JS APIs already, so if you're not
familiar with how it works, you're gonna have to get familiar with it
really soon. ^_^
Also, unrelated, please bring back CSS width to the col tag. On very
large data tables, this can reduce page downloads by megabytes, no
matter
how small you make your column class names.
Rather than putting classes on your tds, you can just use better
selectors. If you need to set the width of the cells in the second
column, you can just do `td:nth-child(2) { width: XXX; }`. Save
yourself a couple megabytes. ^_^
(This isn't *precisely* reliable, because it doesn't know about
rowspans/colspans, but you can often deal with that yourself.
Selectors level 4 adds an :nth-column() pseudo-class which is
identical to :nth-child(), but only works on table cells and knows
about rowspans and colspans, so it'll properly style everything in the
desired column no matter how the table is structured.)
~TJ
Re: Write-only form fields (was Re: Proposal for a credential management API.)
On Fri, Aug 1, 2014 at 5:37 AM, Mike West mk...@google.com wrote: On Thu, Jul 31, 2014 at 6:37 PM, Brian Smith br...@briansmith.org wrote: particular, if we are worried about XSS stealing passwords then we have to consider the possibility that XSS has inserted a form without any httponly attributes being used, right? Correct. I think we'd also want a new CSP directive which toggles write-only status for all password fields on a given page: how about http://projects.mikewest.org/credentialmanagement/writeonly/#credentials-directive? There is some tension here between making things password-specific and simple vs. making them general and harder to understand. Defining this as a mechanism to protect only passwords keeps it simple. But, it seems wrong to have a way to protect passwords but not credit card numbers and social security numbers and other very sensitive input fields that don't use input type=password. This would work with (C) too, would it not? It may be a good idea to add an attribute to XHR to trigger such replacement, so that the browser doesn't have to attempt substitution for every HTTP request. I think we'd be able to get away with relying on magical UA behavior: if the browser process hands a nonce to a renderer, it can set a flag, and then look at POSTs generated by the page. As soon as one POST contains the nonce, clear the flag. My suspicion is that most login pages don't do much POSTing, so the overhead would be trivial. I am not sure that looking only at POSTs is sufficient. Also, some websites put login forms on every page (whether they should or not). But, I agree that it would be better to avoid the need for the attribute if we can. I'd prefer that approach, because I don't think we want to expose the actual mechanics to the web. The website shouldn't need to care about whether or not the password it's received is the real password or not. I suspect some websites will want to disable some aspects of their form validation code if they are dealing with placeholders instead of the real values, especially if the mechanism is extended to things such as social security numbers and credit card numbers. Based on a quick read of Mike's proposal, this would require Mike's proposed API to change to pass around tokens that represent passwords, instead of the password values themselves. This would add complication, but it would be useful. This approach adds complication to the UA's implementation, but shouldn't add complexity to the site consuming the API. This would probably not interact well with use of the WebCrypto API to encrypt the contents of input fields (passwords, credit card numbers, etc.) before submission. I'm pretty happy to break that use case, given that the credential API I've proposed is locked to secure origins. There's no advantage to using WebCrypto to doubly encrypt the password in this context, and I don't think it's something we should encourage. I think it is fine to say that this would be mutually-exclusive with WebCrypto-based approaches to encrypting passwords in the short term. However, I think it is too early in the history of WebCrypto to say that there's advantage to encrypting passwords (or other sensitive information like credit card numbers) in a way that protects them from the from the web server. I think it is likely that some way of composing WebCrypto and this mechanism will be necessary, eventually. Cheers, Brian
Re: =[xhr]
On Aug 1, 2014 8:16 AM, nmork_consult...@cusa.canon.com wrote: In this case, a freeze on all browser operations is desirable. The thread cannot be interrupted, and if it is interrupted (by browser closure or other such) then the transactions are immediately stopped and no update will occur (this is the most desirable outcome.) Assuming you're handling transactions yourself, using async XHR has no effect on this. (The browser doesn't provide any transactions for you.) Async XHR doesn't continue after tab closure. Async is not desirable, since it gives control back to the browser and the user has a false impression that interaction may be ok or even desirable. In this case it is not, it is an all stop until complete requirement. You can throw up a spinner to indicate that if you want, and get the same effect. The spinner solution lets you do more things, too, such as providing feedback or other information to the user. (Or just allowing hover effects to work - freezing the main thread restricts a *lot* of things.) I use both async and sync xmlhttprequests, and they both have their place. Please do not deprecate sync requests simply because you cannot imagine where they would be desirable. When they are needed, they are ABSOLUTELY needed and async requests are not only NOT desirable, but can lead to potentially disastrous results. Sync XHR offers you literally nothing over async XHR besides a little bit of restrictive simplicity. There is absolutely no situation in which sync XHR is actually required. ~TJ
Re: =[xhr]
Spinner is not sufficient. All user activity must stop. They can take a coffee break if it takes too long. Browser must be frozen and locked down completely. No other options are desirable. All tabs, menus, etc. must be frozen. That is exactly the desired result. From: Tab Atkins Jr. jackalm...@gmail.com To: nmork_consult...@cusa.canon.com, Cc: public-webapps public-webapps@w3.org Date: 08/01/2014 06:33 AM Subject:Re: =[xhr] On Aug 1, 2014 8:16 AM, nmork_consult...@cusa.canon.com wrote: In this case, a freeze on all browser operations is desirable. The thread cannot be interrupted, and if it is interrupted (by browser closure or other such) then the transactions are immediately stopped and no update will occur (this is the most desirable outcome.) Assuming you're handling transactions yourself, using async XHR has no effect on this. (The browser doesn't provide any transactions for you.) Async XHR doesn't continue after tab closure. Async is not desirable, since it gives control back to the browser and the user has a false impression that interaction may be ok or even desirable. In this case it is not, it is an all stop until complete requirement. You can throw up a spinner to indicate that if you want, and get the same effect. The spinner solution lets you do more things, too, such as providing feedback or other information to the user. (Or just allowing hover effects to work - freezing the main thread restricts a *lot* of things.) I use both async and sync xmlhttprequests, and they both have their place. Please do not deprecate sync requests simply because you cannot imagine where they would be desirable. When they are needed, they are ABSOLUTELY needed and async requests are not only NOT desirable, but can lead to potentially disastrous results. Sync XHR offers you literally nothing over async XHR besides a little bit of restrictive simplicity. There is absolutely no situation in which sync XHR is actually required. ~TJ
Re: =[xhr]
On Aug 1, 2014 8:39 AM, nmork_consult...@cusa.canon.com wrote: Spinner is not sufficient. All user activity must stop. They can take a coffee break if it takes too long. Browser must be frozen and locked down completely. No other options are desirable. All tabs, menus, etc. must be frozen. That is exactly the desired result. By spinner, I also meant freezing other parts of the page as necessary, or obscuring them so they can't be clicked. Asking to freeze the rest of the browser is unnecessary and extremely user-hostile, and we don't support allowing content to do that. ~TJ
Re: =[xhr]
Thank you for letting me know my input is not desired. From: Tab Atkins Jr. jackalm...@gmail.com To: nmork_consult...@cusa.canon.com, Cc: public-webapps public-webapps@w3.org Date: 08/01/2014 06:46 AM Subject:Re: =[xhr] On Aug 1, 2014 8:39 AM, nmork_consult...@cusa.canon.com wrote: Spinner is not sufficient. All user activity must stop. They can take a coffee break if it takes too long. Browser must be frozen and locked down completely. No other options are desirable. All tabs, menus, etc. must be frozen. That is exactly the desired result. By spinner, I also meant freezing other parts of the page as necessary, or obscuring them so they can't be clicked. Asking to freeze the rest of the browser is unnecessary and extremely user-hostile, and we don't support allowing content to do that. ~TJ
Re: Write-only form fields (was Re: Proposal for a credential management API.)
On Fri, Aug 1, 2014 at 3:31 PM, Brian Smith br...@briansmith.org wrote: There is some tension here between making things password-specific and simple vs. making them general and harder to understand. Defining this as a mechanism to protect only passwords keeps it simple. But, it seems wrong to have a way to protect passwords but not credit card numbers and social security numbers and other very sensitive input fields that don't use input type=password. I hadn't considered autofilled credit cards; that's a reasonable use case. We could address credit cards by turning the CSP directive into a list of autocomplete attribute values: `form-readonly cc-number cc-csc ... current-password new-password`. That seems like it would address the credential use case, while leaving flexibility for future field types that developers might care about giving extra protection. That said, it gets quite verbose. If we go this route, perhaps we could come up with a chunk of those types we'd expect developers to want to protect, and give them a special keyword expression: `form-readonly 'the-usual-stuff'`. I am not sure that looking only at POSTs is sufficient. I don't think we should encourage GET-based submission of valuable information. websites put login forms on every page (whether they should or not). If we filled a form on every page, but the user never logged in, there would indeed be a (marginal?) performance impact if we had to examine every POST a website made. That feels like an edgy enough case that we don't have to worry too much about it, but I don't have any numbers to back that up. But, I agree that it would be better to avoid the need for the attribute if we can. The less work we make the website do to get some security benefit, the better. I suspect some websites will want to disable some aspects of their form validation code if they are dealing with placeholders instead of the real values, especially if the mechanism is extended to things such as social security numbers and credit card numbers. If the field is write-only, they won't be able to do client-side validation. That's a necessary consequence of keeping the password out of the renderer, and out of reach of JavaScript. I agree that this is more problematic for SSN or CC fields than for passwords, but I don't see an alternative that would keep the renderer in the dark about the actual value. If they use the credential management API to get credentials, they'll only be getting credentials the user saved. Presumably the user wouldn't save credentials that weren't valid for the site. I'm pretty happy to break that use case, given that the credential API I've proposed is locked to secure origins. There's no advantage to using WebCrypto to doubly encrypt the password in this context, and I don't think it's something we should encourage. I think it is fine to say that this would be mutually-exclusive with WebCrypto-based approaches to encrypting passwords in the short term. However, I think it is too early in the history of WebCrypto to say that there's advantage to encrypting passwords (or other sensitive information like credit card numbers) in a way that protects them from the from the web server. I think it is likely that some way of composing WebCrypto and this mechanism will be necessary, eventually. I'm curious about the use cases for protecting the password from the webserver. I've had some conversations with Sigbjørn Vik about returning hashed passwords rather than real passwords, which might be going along the lines you're thinking. That is, the site would provide hash function and a server nonce when requesting credentials, and the UA would return a client nonce and a LocalCredential whose password value was `hash(password + server nonce + client nonce)`. I think that's worth exploring, but it's tough to do well without requiring the site to hold passwords in plaintext. Is that the kind of use case you're considering? -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: =[xhr]
On Aug 1, 2014 9:52 AM, nmork_consult...@cusa.canon.com wrote: Thank you for letting me know my input is not desired. As Tab said, you can visually and functionally lock user input in your tab and even provide a progress meter. Nothing you suggest is difficult with a sync xhr and promises, and it's less hostile. How is this unreasonable? From:Tab Atkins Jr. jackalm...@gmail.com To:nmork_consult...@cusa.canon.com, Cc:public-webapps public-webapps@w3.org Date:08/01/2014 06:46 AM Subject:Re: =[xhr] On Aug 1, 2014 8:39 AM, nmork_consult...@cusa.canon.com wrote: Spinner is not sufficient. All user activity must stop. They can take a coffee break if it takes too long. Browser must be frozen and locked down completely. No other options are desirable. All tabs, menus, etc. must be frozen. That is exactly the desired result. By spinner, I also meant freezing other parts of the page as necessary, or obscuring them so they can't be clicked. Asking to freeze the rest of the browser is unnecessary and extremely user-hostile, and we don't support allowing content to do that. ~TJ
Re: =[xhr]
On Aug 1, 2014 8:49 AM, nmork_consult...@cusa.canon.com wrote: Thank you for letting me know my input is not desired. All input is definitely desired, but you seem to either not fully understand what async XHR does, or are ascribing greater functionality to sync XHR than it actually possesses. So far you have not described any problem for which sync XHR is actually required, and I'm fairly certain that such a problem does not exist. ~TJ
Re: =[xhr]
From: nmork_consult...@cusa.canon.com Thank you for letting me know my input is not desired. No, not at all. I think many engineers reading this list are truly delighted to have seen your message. Some of us are also very sad, but I would argue that all of us who have a good sense of humor are actually in the first category. To be honest, it seems you just need to take a look at modern application coding best practices. There's nothing wrong with you giving your opinion -- thanks for taking the time to do so! -- but there's nothing in the scenario you explained that requires a synchronous http request done on the main browser thread. Please trust us.
Re: =[xhr]
On 8/1/14, 9:39 AM, nmork_consult...@cusa.canon.com wrote: All tabs, menus, etc. must be frozen. Sync XHR doesn't do that. -Boris
Re: =[xhr]
If you use your tab key, you will discover that you will need to disable all controls under your spinner to prevent user input completely. Kind of a lot of work to get exactly the effect that sync requests do for you. I find sync xmlhttprequests useful and you don't, it's clear. But instead of recognizing this and doing something like saying hm. interesting, maybe there is a use for it, you have decided since you have no use for sync requests that no one should be using them. I don't care to go through the effort of trying to write this application with async requests again, when I already have experienced the fact they don't give me the desired behavior. From: Brian Kardell bkard...@gmail.com To: nmork_consult...@cusa.canon.com, Cc: public-webapps@w3.org, Tab Atkins Jr. jackalm...@gmail.com Date: 08/01/2014 07:13 AM Subject:Re: =[xhr] On Aug 1, 2014 9:52 AM, nmork_consult...@cusa.canon.com wrote: Thank you for letting me know my input is not desired. As Tab said, you can visually and functionally lock user input in your tab and even provide a progress meter. Nothing you suggest is difficult with a sync xhr and promises, and it's less hostile. How is this unreasonable? From:Tab Atkins Jr. jackalm...@gmail.com To:nmork_consult...@cusa.canon.com, Cc:public-webapps public-webapps@w3.org Date:08/01/2014 06:46 AM Subject:Re: =[xhr] On Aug 1, 2014 8:39 AM, nmork_consult...@cusa.canon.com wrote: Spinner is not sufficient. All user activity must stop. They can take a coffee break if it takes too long. Browser must be frozen and locked down completely. No other options are desirable. All tabs, menus, etc. must be frozen. That is exactly the desired result. By spinner, I also meant freezing other parts of the page as necessary, or obscuring them so they can't be clicked. Asking to freeze the rest of the browser is unnecessary and extremely user-hostile, and we don't support allowing content to do that. ~TJ
Re: Write-only form fields (was Re: Proposal for a credential management API.)
Your proposal decouples spec from implementation more than the placeholder approach does, which is good. I think the CSP directive is unnecessary and makes things more fragile. The 'protect this credential from XSS' attribute should be a property of a stored credential, not a web site. If the site has the correct CSP headers on 99% of its website, but then for some reason doesn't have them on one page, that page is a potential vector to expose the credential. I think making input fields write-only is more powerful than we strictly need. When a user is manually entering a password, it's okay for the page to be able to read the value they are typing in. If the page has been modified by an attacker at this point, it's too late. What we want is a mechanism to specify 'once this value is stored in a password manager*, protect it from future JS on this page.' That's why I feel like it's relevant to define credential management APIs for the web. *or credit card autofiller. The write-only spec fully breaks XHR form submission (style C in my earlier mail). As Brian pointed out, the placeholder approach can be made to work with XHR if you're willing to do a little extra inspection of arbitrary XHRs. Also, as you pointed out, write-only breaks client-side validation. Client-side validation is very broadly used for password strength meters during signup and change password. I think interfering with strength meters would make it a lot harder for implementers to adopt the spec. I'm curious about the use cases for protecting the password from the webserver. One common use case for client-side crypto is removing systems from scope in PCI (payment card industry) compliance. There's a set of standards related to the handling of credit/debit cards that involve auditing all systems that have card data. There are third-party services that offer compliance by having you encrypt card data in JS and pass it, encrypted, through all your non-compliant systems and into their secure vault where it is decrypted.
Re: =[xhr]
On Fri, Aug 1, 2014 at 8:39 AM, nmork_consult...@cusa.canon.com wrote: Spinner is not sufficient. All user activity must stop. They can take a coffee break if it takes too long. Browser must be frozen and locked down completely. No other options are desirable. All tabs, menus, etc. must be frozen. That is exactly the desired result. My browser isn't yours to lock down. My menus aren't yours to freeze. You don't get to halt my browser, it doesn't belong to you. In this case, a freeze on all browser operations is desirable. It may be desirable to you, but it's never desirable to the user, and users come first. -- Glenn Maynard
[Bug 26502] New: Need to define UIEvent or link to where it's normatively defined
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26502 Bug ID: 26502 Summary: Need to define UIEvent or link to where it's normatively defined Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: UI Events Assignee: gary...@google.com Reporter: i...@hixie.ch QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org -- You are receiving this mail because: You are on the CC list for the bug.
Re: Write-only form fields (was Re: Proposal for a credential management API.)
Thanks Jacob! On Fri, Aug 1, 2014 at 6:48 PM, Jacob S Hoffman-Andrews j...@eff.org wrote: I think the CSP directive is unnecessary and makes things more fragile. The 'protect this credential from XSS' attribute should be a property of a stored credential, not a web site. If the site has the correct CSP headers on 99% of its website, but then for some reason doesn't have them on one page, that page is a potential vector to expose the credential. 1. Nothing in the 'writeonly' document prevents UAs from using some sort of heuristic to determine when to fill forms. We already look at things like the form action, there's no reason we couldn't also look at the page-level policy, or field-level attributes. Tagging the credential as 'writeonly' is certainly compatible with this approach. 2. We need CSP anyway in order to specify where forms may permissibly be submitted. Using it as a mechanism for setting a writeonly policy seems like a reasonable extension. I think making input fields write-only is more powerful than we strictly need. When a user is manually entering a password, it's okay for the page to be able to read the value they are typing in. If the page has been modified by an attacker at this point, it's too late. It seems like we could prevent this attack if we stop firing events on 'writeonly' fields. At best, that would prevent reading the value. At worst, that would make the attacker's job harder (she'd have to layer an invisible field over the password field and do magic to get the value out of the one and into the other). What we want is a mechanism to specify 'once this value is stored in a password manager*, protect it from future JS on this page.' That's why I feel like it's relevant to define credential management APIs for the web. *or credit card autofiller. 1. How do we retroactively apply this policy to users' existing credentials? 'writeonly' is a nice, drop-in solution that works for existing credentials as well as new credentials. 2. I'd prefer not to rely on multiple subsystems' understanding of the protect from JS concept. In Chrome, at least, credit cards and passwords are in separate databases, and filled via different code paths. I suspect that doing the work once at the DOM-level would be less error-prone. The write-only spec fully breaks XHR form submission (style C in my earlier mail). As Brian pointed out, the placeholder approach can be made to work with XHR if you're willing to do a little extra inspection of arbitrary XHRs. This approach breaks XHR-based systems which read the data directly from the form field. It doesn't necessarily break an API-driven mechanism. Also, as you pointed out, write-only breaks client-side validation. Client-side validation is very broadly used for password strength meters during signup and change password. I think interfering with strength meters would make it a lot harder for implementers to adopt the spec. Would we need strength meters for sign-in forms? We'd really only need those for sign-up forms when users are creating an account, right? If we can find a reasonable way of distinguishing the two, we can address this use case. For example, if we set a CSP which includes `autocomplete=current-password`, but excludes `autocomplete=new-password` (and we assert that browsers are updated to exclude 'new-password' from autofill), we'd get the advantages of a blanket page-level policy, while allowing developers to help users create strong passwords. I'm curious about the use cases for protecting the password from the webserver. One common use case for client-side crypto is removing systems from scope in PCI (payment card industry) compliance. There's a set of standards related to the handling of credit/debit cards that involve auditing all systems that have card data. There are third-party services that offer compliance by having you encrypt card data in JS and pass it, encrypted, through all your non-compliant systems and into their secure vault where it is decrypted. Interesting. The proposal I've made doesn't support this use case. How common do you believe it is? If we need to support it, then blocking JS-level access to the form data will be difficult. -mike
