Re: Update on Streams API Status
Le 07/02/2014 10:52, Anne van Kesteren a écrit : As for createObjectURL(), it has not been a great success for Blob objects. I'm not really sure we should widen that experiment. At least not until the way they are supposed to be implemented for Blob objects has actually been done in practice. Do you mean that browsers are not implementing correctly createObjectURL right now? Regards Aymeric -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
XMLHttpRequest error events
I found myself using XMLHttpRequest in an application where, when things go wrong, I wanted to provide information to the user. I was unable to do so. Specifically, I POSTed a form with a large file, and specified listeners for abort and error events (among others) on both the request and upload targets. I tried disconnecting the network, shutting down the target webserver, mis-spelling the host name, having the server refuse service and injecting various other real-world misadventures. Although I get the events in several browsers, nothing in the event tells me what went wrong. And I find nothing in the specification ( http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html - 22-Nov-2013) to help. According to the spec, in the synchronous model, the exception would at least specify 'NetworkError'. Async, the only thing one gets is the event type, bytes transfered, and (possibly) total bytes. One can assume if loaded is zero, no connection was established; otherwise there was a connection failure, but that's about it. It really would be useful - both for debugging and for providing feedback to users - if the error and abort events provided some detail: Was the problem: DNS failure: no server, host has no A() record? Proxy not reachable? Host not reachable? SSL certificate expired? Connection broken? Aborted by user action? Aborted by object destruction? Some supporting detail (e.g. IP address of peer, proxy, etc) would be helpful too. This is not intended to be an exhaustive list. While I would discourage client scripts from trying to analyze OS-specific error codes, some user-actionable clues would be really helpful. 'An error occurred sending flilename' is about the best one can do currently, and that doesn't give the user - or the helpdesk - much to go on! Please consider updating the spec to provide reasonable diagnostics for network error events. -- This communication may not represent my employer's views, if any, on the matters discussed.
[Bug 24600] New: [Custom]: Callback names are out of date?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24600 Bug ID: 24600 Summary: [Custom]: Callback names are out of date? Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: a...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 The callback names were changed a while ago (I can't find spec bug) but the spec draft still shows the old names. I believe the callback names should be: createdCallback attachedCallback detachedCallback attributeChangedCallback -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24421] [Shadow]: Clarify that Shadow DOM spec takes care of nodes which are *inDocument*.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24421 Boris Zbarsky bzbar...@mit.edu changed: What|Removed |Added Status|RESOLVED|REOPENED CC||bzbar...@mit.edu Resolution|FIXED |--- --- Comment #10 from Boris Zbarsky bzbar...@mit.edu --- without breaking incompatibility if we leave it *undefined*. That's not how compatibility works. Compatibility issues are always with _behavior_, not with _specs_. It sounds like you just need to fix the breakage in Blink/WebKit here. To me it is obvious that things should work the same whether in document or not. I agree. Reopening this bug; I don't think the current setup is at all acceptable. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24600] [Custom]: Callback names are out of date?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24600 Erik Arvidsson a...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Erik Arvidsson a...@chromium.org --- There is a discussion about this going on. *** This bug has been marked as a duplicate of bug 24314 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24603] New: [Custom]: Need callback for form submit data
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24603
Bug ID: 24603
Summary: [Custom]: Need callback for form submit data
Product: WebAppsWG
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Component Model
Assignee: dglaz...@chromium.org
Reporter: a...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14968
form
my-custom-input name=abc/my-custom-input
/form
Right now there is no way to have custom elements include data in form
submissions. We should add another callback for this
I believe we need to add a callback that is called before the submit event.
Strawman:
document.registerElement('input', {
prototype: {
__proto__: HTMLElement.prototype,
beforeSubmitCallback: function() {
switch (this.type) {
case 'checkbox';
if (this.checked)
return this.value;
return undefined;
...
}
}
}
});
Basically, the contract is that the return value of the callback is used a the
form value. If undefined is returned nothing is serialized.
This is of course a bit too simplistic but it might be enough to get started.
Things to keep in mind:
- Radio buttons need to check outside itself
- input[type=file]. Return Blob|File|data url?
- input[multiple]. Array of values?
--
You are receiving this mail because:
You are on the CC list for the bug.
Re: XMLHttpRequest error events
This sounds nice, but for security reasons cross-origin fetches would not be able to provide these diagnostics unless the fetch got as far as passing the CORS check. On 10 February 2014 12:30, tlhackque tlhack...@yahoo.com wrote: I found myself using XMLHttpRequest in an application where, when things go wrong, I wanted to provide information to the user. I was unable to do so. Specifically, I POSTed a form with a large file, and specified listeners for abort and error events (among others) on both the request and upload targets. I tried disconnecting the network, shutting down the target webserver, mis-spelling the host name, having the server refuse service and injecting various other real-world misadventures. Although I get the events in several browsers, nothing in the event tells me what went wrong. And I find nothing in the specification ( http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html - 22-Nov-2013) to help. According to the spec, in the synchronous model, the exception would at least specify 'NetworkError'. Async, the only thing one gets is the event type, bytes transfered, and (possibly) total bytes. One can assume if loaded is zero, no connection was established; otherwise there was a connection failure, but that's about it. It really would be useful - both for debugging and for providing feedback to users - if the error and abort events provided some detail: Was the problem: DNS failure: no server, host has no A() record? Proxy not reachable? Host not reachable? SSL certificate expired? Connection broken? Aborted by user action? Aborted by object destruction? Some supporting detail (e.g. IP address of peer, proxy, etc) would be helpful too. This is not intended to be an exhaustive list. While I would discourage client scripts from trying to analyze OS-specific error codes, some user-actionable clues would be really helpful. 'An error occurred sending flilename' is about the best one can do currently, and that doesn't give the user - or the helpdesk - much to go on! Please consider updating the spec to provide reasonable diagnostics for network error events. -- This communication may not represent my employer's views, if any, on the matters discussed.
Re: XMLHttpRequest error events
for security reasons cross-origin fetches would not be able to provide these diagnostics In that case, the error event should report Forbidden by cross-origin policy. At least that gives a clue - we know it's not a DNS failure or an unplugged cable or... In this case, not directly useful to the end-user, but when (s)he reports it to the help desk, the person they escalate it to will have a place to start. And a developer will (should) know what to do when his testing(?) encounters the problem. Hiding the failure cause does nothing to improve security, rather it makes diagnosing issues and writing good code harder. As such, it's more likely to cause people to write overly permissive code 'to get it working'. The bad guys know what rule they're trying to break. So the current behavior really only hurts the good gusy. On 10-Feb-14 12:16, Nick Krempel wrote: This sounds nice, but for security reasons cross-origin fetches would not be able to provide these diagnostics unless the fetch got as far as passing the CORS check. On 10 February 2014 12:30, tlhackque tlhack...@yahoo.com mailto:tlhack...@yahoo.com wrote: I found myself using XMLHttpRequest in an application where, when things go wrong, I wanted to provide information to the user. I was unable to do so. Specifically, I POSTed a form with a large file, and specified listeners for abort and error events (among others) on both the request and upload targets. I tried disconnecting the network, shutting down the target webserver, mis-spelling the host name, having the server refuse service and injecting various other real-world misadventures. Although I get the events in several browsers, nothing in the event tells me what went wrong. And I find nothing in the specification ( http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html - 22-Nov-2013) to help. According to the spec, in the synchronous model, the exception would at least specify 'NetworkError'. Async, the only thing one gets is the event type, bytes transfered, and (possibly) total bytes. One can assume if loaded is zero, no connection was established; otherwise there was a connection failure, but that's about it. It really would be useful - both for debugging and for providing feedback to users - if the error and abort events provided some detail: Was the problem: DNS failure: no server, host has no A() record? Proxy not reachable? Host not reachable? SSL certificate expired? Connection broken? Aborted by user action? Aborted by object destruction? Some supporting detail (e.g. IP address of peer, proxy, etc) would be helpful too. This is not intended to be an exhaustive list. While I would discourage client scripts from trying to analyze OS-specific error codes, some user-actionable clues would be really helpful. 'An error occurred sending flilename' is about the best one can do currently, and that doesn't give the user - or the helpdesk - much to go on! Please consider updating the spec to provide reasonable diagnostics for network error events. -- This communication may not represent my employer's views, if any, on the matters discussed. -- This communication may not represent my employer's views, if any, on the matters discussed.
Re: XMLHttpRequest error events
You misunderstood: not only a failed CORS check but any error occurring *before* the CORS check would need to be reported as a generic NetworkError without further diagnostics. Otherwise you could write a script to probe the local network by firing off (failing) CORS-enabled XMLHttpRequests to various IP addresses / local DNS names and get a treasure trove of useful information (for attackers). This is already possible to some extent via a timing attack, but at least that's more work for the attacker, and is something that could be mitigated by user agents in the future through the insertion of artificial delays for failed cross-origin fetches. Nick On 10 February 2014 18:01, tlhackque tlhack...@yahoo.com wrote: for security reasons cross-origin fetches would not be able to provide these diagnostics In that case, the error event should report Forbidden by cross-origin policy. At least that gives a clue - we know it's not a DNS failure or an unplugged cable or... In this case, not directly useful to the end-user, but when (s)he reports it to the help desk, the person they escalate it to will have a place to start. And a developer will (should) know what to do when his testing(?) encounters the problem. Hiding the failure cause does nothing to improve security, rather it makes diagnosing issues and writing good code harder. As such, it's more likely to cause people to write overly permissive code 'to get it working'. The bad guys know what rule they're trying to break. So the current behavior really only hurts the good gusy. On 10-Feb-14 12:16, Nick Krempel wrote: This sounds nice, but for security reasons cross-origin fetches would not be able to provide these diagnostics unless the fetch got as far as passing the CORS check. On 10 February 2014 12:30, tlhackque tlhack...@yahoo.com wrote: I found myself using XMLHttpRequest in an application where, when things go wrong, I wanted to provide information to the user. I was unable to do so. Specifically, I POSTed a form with a large file, and specified listeners for abort and error events (among others) on both the request and upload targets. I tried disconnecting the network, shutting down the target webserver, mis-spelling the host name, having the server refuse service and injecting various other real-world misadventures. Although I get the events in several browsers, nothing in the event tells me what went wrong. And I find nothing in the specification ( http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html - 22-Nov-2013) to help. According to the spec, in the synchronous model, the exception would at least specify 'NetworkError'. Async, the only thing one gets is the event type, bytes transfered, and (possibly) total bytes. One can assume if loaded is zero, no connection was established; otherwise there was a connection failure, but that's about it. It really would be useful - both for debugging and for providing feedback to users - if the error and abort events provided some detail: Was the problem: DNS failure: no server, host has no A() record? Proxy not reachable? Host not reachable? SSL certificate expired? Connection broken? Aborted by user action? Aborted by object destruction? Some supporting detail (e.g. IP address of peer, proxy, etc) would be helpful too. This is not intended to be an exhaustive list. While I would discourage client scripts from trying to analyze OS-specific error codes, some user-actionable clues would be really helpful. 'An error occurred sending flilename' is about the best one can do currently, and that doesn't give the user - or the helpdesk - much to go on! Please consider updating the spec to provide reasonable diagnostics for network error events. -- This communication may not represent my employer's views, if any, on the matters discussed. -- This communication may not represent my employer's views, if any, on the matters discussed.
Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)
On 2/6/14 9:06 PM, ext Ryosuke Niwa wrote: Could chairs of the working group please clarify whether we have had a reach of consensus on the default encapsulation level in shadow DOM? As described in [WorkMode], WebApps' asynchronous participation and edit first work modes means group members must actively participate on the list and actively file bugs and participate in bug reports. We also expect both Editors and group participants to work toward obtaining broad consensus as described in the charter [Decisions]. More concretely, have we _decided_ that we only want Type 1 encapsulation for the level 1 specifications of Web components instead of Type 2 or Type 1 and Type 2 encapsulations as defined in Maciej's email sent out in June 29th, 2011: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html I don't recall any consensus being reached about this matter. In fact, http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312 (referred by http://lists.w3.org/Archives/Public/www-style/2014Feb/0221.html) clearly shows the lack of consensus in my eyes as both Boris Zbarsky from Mozilla and Maciej Stachowiak from Apple have voiced to prefer Type 2 encapsulation: http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0406.html http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0421.html http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0628.html while representatives of Google preferring Type 1 encapsulations. I agree the threads started by Maciej at [1364.html] and Dimitri at [0312.html] do not appear to have reached broad consensus. (I am not subscribed to www-style so I haven't followed those discussions.) Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here? -Thanks, ArtB [WorkMode] https://www.w3.org/2008/webapps/wiki/WorkMode [Decisions] http://www.w3.org/2012/webapps/charter/#decisions [1364.html] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html [0312.html] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312
Re: XMLHttpRequest error events
Your scenario is that an attacker gets you to visit her website; that site feeds you script that does AJAX requests and the resulting errors tell ms. evil about your network. Yes, this can happen. But you also suggest a perfectly reasonable solution. If any AJAX request fails due to one of those checks, insert a delay of 30 seconds for all future AJAX requests made until the browser is closed. This makes the attack unprofitable. And encourages the user to leave the site. There are other choices: * have the browser notify the user: 'This website has attempted to use your browser to fetch data from a forbidden source'. 'A script from evil.example.com attempted to contact 'payroll.example.net', which is unreachable'. Perhaps make this behavior conditional on a parameter to open(). If it annoys the user, it communicates the fact that the website is doing something unexpected. If not, the user isn't going to get his work done, so he might as well be told why - which enables a problem to be fixed. This gives nothing away to the bad guy. * Or require compliant browsers to log the details of these errors in an about: page. Perhaps terminate a script that does particularly questionable things - denying it the opportunity to report back. * Or have a preference option that enables (more) detailed error reporting. Perhaps a site policy that it reverts to 'unset' after a period of time, or when a browser closes. If a user has to take a positive action to get/enable information, the risk is much lower. After all, if the user is the attacker, browser security is minimal - writing probing applications is trivial in any reasonably modern scripting language. Your scenario is that of an unwitting (hijacked) participant. I think we should strike a better balance between security via obscurity and making web applications easy to maintain, develop and operate. I've suggested some choices to start the conversation. I don't claim they're the final answer. But applying some creativity to helping the good guys - not just resisting the bad guys - is in order. As things stand, the API denies evil people some information - but it also denies the actual users and their developers the information that they need to solve problems. This is effectively a denial of service attack - without the attackers lifting a finger. Applications take longer to develop, cost more to diagnose, maintain and operate. On 10-Feb-14 13:14, Nick Krempel wrote: You misunderstood: not only a failed CORS check but any error occurring *before* the CORS check would need to be reported as a generic NetworkError without further diagnostics. Otherwise you could write a script to probe the local network by firing off (failing) CORS-enabled XMLHttpRequests to various IP addresses / local DNS names and get a treasure trove of useful information (for attackers). This is already possible to some extent via a timing attack, but at least that's more work for the attacker, and is something that could be mitigated by user agents in the future through the insertion of artificial delays for failed cross-origin fetches. Nick On 10 February 2014 18:01, tlhackque tlhack...@yahoo.com mailto:tlhack...@yahoo.com wrote: for security reasons cross-origin fetches would not be able to provide these diagnostics In that case, the error event should report Forbidden by cross-origin policy. At least that gives a clue - we know it's not a DNS failure or an unplugged cable or... In this case, not directly useful to the end-user, but when (s)he reports it to the help desk, the person they escalate it to will have a place to start. And a developer will (should) know what to do when his testing(?) encounters the problem. Hiding the failure cause does nothing to improve security, rather it makes diagnosing issues and writing good code harder. As such, it's more likely to cause people to write overly permissive code 'to get it working'. The bad guys know what rule they're trying to break. So the current behavior really only hurts the good gusy. On 10-Feb-14 12:16, Nick Krempel wrote: This sounds nice, but for security reasons cross-origin fetches would not be able to provide these diagnostics unless the fetch got as far as passing the CORS check. On 10 February 2014 12:30, tlhackque tlhack...@yahoo.com mailto:tlhack...@yahoo.com wrote: I found myself using XMLHttpRequest in an application where, when things go wrong, I wanted to provide information to the user. I was unable to do so. Specifically, I POSTed a form with a large file, and specified listeners for abort and error events (among others) on both the request and upload targets. I tried disconnecting the network, shutting down the target webserver, mis-spelling the host
[Bug 24608] New: What happens when calling lockOrientation() and already locked?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24608 Bug ID: 24608 Summary: What happens when calling lockOrientation() and already locked? Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: dch...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org The specification could be more explicit about what happens when lockOrientation() is called and we are already locked. Likely, it should override the previously locked orientation but the specification could be clearer about this IMHO. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24609] New: Can unlockOrientation() cause an orientationchange event to be fired?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24609 Bug ID: 24609 Summary: Can unlockOrientation() cause an orientationchange event to be fired? Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: dch...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org The specification is currently clear about the fact that calling lockOrientation() can cause an orientationchange event to be fired if the screen orientation had to be changed to meet the locking requirements. However, the specification is not as clear about unlockOrientation() IMHO. When calling unlockOrientation(), a new screen orientation may be used to best match the current device orientation, and thus an orientationchange event may be fired. Maybe this should be clarified in the specification? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24610] New: What happens when unlockOrientation() is called but no orientation is locked?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24610 Bug ID: 24610 Summary: What happens when unlockOrientation() is called but no orientation is locked? Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: dch...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org What happens when unlockOrientation() is called but no orientation is locked? The specification does not clearly mention this case, I assume we should return early (silently). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24611] New: Should the screen orientation be unlocked when navigating to a new page?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24611 Bug ID: 24611 Summary: Should the screen orientation be unlocked when navigating to a new page? Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: dch...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Should the screen orientation be unlocked when navigating to a new page? I could not find this information in the specification. I personally think it should. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24612] New: Should Screen locking work only in full screen mode?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24612 Bug ID: 24612 Summary: Should Screen locking work only in full screen mode? Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: dch...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Should Screen locking work only in full screen mode? The specification does not mention this. However, I think Firefox and IE11 behave this way. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24614] New: Should the screen orientation be unlocked asynchronously
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24614 Bug ID: 24614 Summary: Should the screen orientation be unlocked asynchronously Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: dch...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org The specification indicates that lockOrientation() should lock the orientation asynchronously. Shouldn't unlockOrientation() do the same? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24555] [imports]: Preceding import should block following document from processing.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24555 Morrita Hajime morr...@google.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.
[Bug 24565] [imports]: Dependency resolution should be stated in clearer way
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24565 Bug 24565 depends on bug 24555, which changed state. Bug 24555 Summary: [imports]: Preceding import should block following document from processing. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24555 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
Re: XMLHttpRequest error events
Note that the non-cross-origin case is still the most common, and I have no objections there. Returning to the cross-origin case: Always inserting a delay of 30s would ruin the user experience when a genuine transient failure occurs. Similarly, popping up a dialog box can easily confuse/annoy the user. For example, the request could be a background task of a web application, not related to the user's foreground activity. Then only the web application knows how best to deal with the failure, perhaps retrying after a delay or notifying the user in a softer fashion and with an accompanying explanation. For diagnostics in the cross-origin case, I would suggest a 'developer flag' in the browser settings which lifts some or all of the security restrictions, broadly similar to say --allow-file-access-from-files in Chrome/Chromium today but preferably easier to enable. (It should be accompanied by an obvious warning so that unwitting users can't be tricked into enabling it.) In case a user is having problems, a (trusted) support person could instruct them to enable the flag just for the current session to obtain diagnostics. If you want to make this even easier on the end user, you could propose an API to be implemented in browsers which the web page could call to request permission to enable cross-origin diagnostics for the current browser session (say, for that browser tab, for as long as the user remains within the same domain/origin). This would pop-up an informative dialog explaining the risks. If the user denies it once, further requests would be auto-denied for that session. These are just some ideas, but if your proposal is to gain any traction, you will have to seriously consider the cross-origin behavior. Nick On 10 February 2014 19:12, tlhackque tlhack...@yahoo.com wrote: Your scenario is that an attacker gets you to visit her website; that site feeds you script that does AJAX requests and the resulting errors tell ms. evil about your network. Yes, this can happen. But you also suggest a perfectly reasonable solution. If any AJAX request fails due to one of those checks, insert a delay of 30 seconds for all future AJAX requests made until the browser is closed. This makes the attack unprofitable. And encourages the user to leave the site. There are other choices: - have the browser notify the user: 'This website has attempted to use your browser to fetch data from a forbidden source'. 'A script from evil.example.com attempted to contact 'payroll.example.net', which is unreachable'. Perhaps make this behavior conditional on a parameter to open(). If it annoys the user, it communicates the fact that the website is doing something unexpected. If not, the user isn't going to get his work done, so he might as well be told why - which enables a problem to be fixed. This gives nothing away to the bad guy. - Or require compliant browsers to log the details of these errors in an about: page. Perhaps terminate a script that does particularly questionable things - denying it the opportunity to report back. - Or have a preference option that enables (more) detailed error reporting. Perhaps a site policy that it reverts to 'unset' after a period of time, or when a browser closes. If a user has to take a positive action to get/enable information, the risk is much lower. After all, if the user is the attacker, browser security is minimal - writing probing applications is trivial in any reasonably modern scripting language. Your scenario is that of an unwitting (hijacked) participant. I think we should strike a better balance between security via obscurity and making web applications easy to maintain, develop and operate. I've suggested some choices to start the conversation. I don't claim they're the final answer. But applying some creativity to helping the good guys - not just resisting the bad guys - is in order. As things stand, the API denies evil people some information - but it also denies the actual users and their developers the information that they need to solve problems. This is effectively a denial of service attack - without the attackers lifting a finger. Applications take longer to develop, cost more to diagnose, maintain and operate. On 10-Feb-14 13:14, Nick Krempel wrote: You misunderstood: not only a failed CORS check but any error occurring *before* the CORS check would need to be reported as a generic NetworkError without further diagnostics. Otherwise you could write a script to probe the local network by firing off (failing) CORS-enabled XMLHttpRequests to various IP addresses / local DNS names and get a treasure trove of useful information (for attackers). This is already possible to some extent via a timing attack, but at least that's more work for the attacker, and is something that could be mitigated by user agents in the future through the insertion of
[Bug 24564] [Imports]: Blocking circular reference in the import tree/list
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24564 Morrita Hajime morr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Morrita Hajime morr...@google.com --- I'm trying to fix this in [1] and following changes by: - Splitting import list into import-link-list and import-map. - The list tracks links - The map tracks imported documents for de-dup work. The import-link-list is basically a flattened and short-circuit DOM tree that only has link (modulo mutation). It is used to control loading/execution order of the documents/scripts. It throttles loading so that it guarantees loading happening in tree DFS order. Here is how the DFS ordering works. Think about following nested imports: - index.html - a.html - b.html - c.html - b.html In this case, the loading should happen index-a-b-c order so that c.html can depend on b.html (in a.html). The order guarantee makes this possible. Otherwise, c.html can be loaded before b.html, which is bad. I believe this determinisity works well for cycle prevention as well as it serializes the loading order. This doesn't mean we're going to kill all the concurrency as it prevents any work for c.html before a.html and children are loaded: It is fine for UAs to prefetch c.html while parsing loading.html Closing this so far but feel free to reopen or file new bugs. Your feedback will be appreciated. [1] https://github.com/w3c/webcomponents/commit/4c3f3600c359ab06fcb3d6a395dcc4b8ea2bb50f -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24565] [imports]: Dependency resolution should be stated in clearer way
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24565 Bug 24565 depends on bug 24564, which changed state. Bug 24564 Summary: [Imports]: Blocking circular reference in the import tree/list https://www.w3.org/Bugs/Public/show_bug.cgi?id=24564 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24583] [imports]: failed fetch should result null document in import list
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24583 Morrita Hajime morr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Morrita Hajime morr...@google.com --- https://github.com/w3c/webcomponents/commit/bd2358066695f8aba4c30abea891ee1b1611d7de -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24565] [imports]: Dependency resolution should be stated in clearer way
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24565 Morrita Hajime morr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Morrita Hajime morr...@google.com --- Closing as sub-bugs are resolved. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24042] [imports]: document.write() in imports should do nothing.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24042 Morrita Hajime morr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Morrita Hajime morr...@google.com --- Renaming the subject to reflect the discussion, and land the fix. https://github.com/w3c/webcomponents/commit/3a2ac114606bb80df5aa5aae047ae3342cc06339 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24616] New: [imports]: Stylesheets in imported documents should be loaded
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24616 Bug ID: 24616 Summary: [imports]: Stylesheets in imported documents should be loaded Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: morr...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 20683 This is a spin-off from Bug 23170. Sharing defaultView could have big implication and may need better framework on HTML side so that such a conceptulization can fit in the picture. For the first cut, it might be better to cover which should be loaded for imports feature-by-feature, instead of describing it in abstract way. -- You are receiving this mail because: You are on the CC list for the bug.
