Re: HTML imports: new XSS hole?
On Mon, 02 Jun 2014 11:32:45 +0200, Anne van Kesteren ann...@annevk.nl wrote: How big of a problem is it that we're making link as dangerous as script? HTML imports can point to any origin which then will be able to execute scripts with the authority of same-origin. I still think it is a problem. http://www.w3.org/mid/op.ww3ecpo5idj3kv@simons-macbook-pro.local -- Simon Pieters Opera Software
[admin] Reminder of Patent Policy for Non-member Contributions [Was: Fwd: Re: CommandEvent for user intentions]
Hi Piotr, All, This is a reminder the W3C's Patent Policy has a goal of assuring W3C Recommendations can be implemented Royalty-Free and this requires all spec contributions include a commitment to that policy. This topic was last discussed in September 2013 and I encourage all Contributors and Editors to read it in its entirety. Here is a short excerpt: [[ http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0654.html ... All Participants in a given Working Group have made a commitment to the W3C Patent Policy (in particular, the provisions regarding licensing obligations), but only for the Recommendations of that particular Working Group. In general, other parties have not made the same commitment for those same deliverables, although they MAY make this commitment if they wish. Similarly, W3C may request that they make such a commitment (see instructions for licensing commitments from non-W3C Members). This means that the Working Group should consider very carefully any contribution from a non-Participant before including it in a document intended to become a W3C Recommendation. ]] Piotr, All - before a proposal/contribution from you - or any other non-WG member - can be included in a specification, we must have a proper patent commitment from your organization via http://www.w3.org/2004/01/pp-impl/42538/nmlc. I will followup separately with you re how you can make such a commitment. Editors - please do _not_ include any contributions from non-WG unless you are sure they have made a patent commitment. In the event you are unsure, please notify me. For a list of WebApps' Members and participants see http://www.w3.org/2004/01/pp-impl/42538/status. -Thanks, AB Original Message Subject:Re: CommandEvent for user intentions Resent-Date:Thu, 22 May 2014 15:24:09 + Resent-From:public-webapps@w3.org Date: Thu, 22 May 2014 13:02:39 +0200 From: Piotr Koszuliński p.koszulin...@cksource.com To: Ben Peters ben.pet...@microsoft.com CC: Julie Parent jpar...@gmail.com, Johannes Wilm johan...@fiduswriter.com, public-webapps@w3.org public-webapps@w3.org I wrote a longer reply in the contentEditable=minimal thread, which touches some aspects of command events. Actually, before some stable point about cE=minimal is reached I feel that it may be hard to design command events in a way that both are interoperable. Command events should be an extension to cE=minimal making it possible to create advanced solutions on top of it. Therefore, it may be beneficial to discuss both of them in one thread. But for now, here are some additional thoughts which I haven't included in the email about cE=minimal. 1. It should be possible to modify selection and DOM in a command event listener, but leave the action to the browser. Browser should perform the action on the updated selection and DOM. Example - I want to transform * to a list when user types additional character. So I would listen to keyboard event, check if two previous characters are * , replace them with a list and place selection inside li. But I want browser to perform character insertion so I don't have to handle undo manager, scrolling to show caret, etc. There are of course other ways to achieve the same, but this seems to be the cleanest. 2. It's not totally necessary, but it would be nice if command event would also carry an information about its future result. For example command fired for up-arrow key could carry a range with the proposed position of caret. So if I don't agree with browser implementation, because for example it enters a non-editable region, I can check that and handle this specific case by myself. Since there's no easy JavaScript solution for handling up/down arrow keys such information would allow us to focus only on these specific behaviours we don't like. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: Fetch API
On 2 June 2014 00:08, Domenic Denicola dome...@domenicdenicola.com wrote: Presumably RedirectResponse being a subtype would also be acceptable, as its .prototype.constructor would be RedirectResponse? Yeah, although I'm not sure there's a need to override any functionality here, so not sure that there's a need for subclassing. Agreed. So Response.redirect(url, status)? Btw, I'd like to add similar-style factories to Response which set header mode defaults Response.image(url); Response.font(url); etc. Don't need these for the first pass though.
RE: Fetch API
From: Jake Archibald [mailto:jaffathec...@gmail.com] Agreed. So Response.redirect(url, status)? LGTM
Re: Fetch API
Ugh, I meant Request for a lot of that: I'd like to add similar-style factories to *Request* which set header mode defaults Request.image(url); Request.font(url); etc. Don't need these for the first pass though. On 3 June 2014 14:01, Jake Archibald jaffathec...@gmail.com wrote: On 2 June 2014 00:08, Domenic Denicola dome...@domenicdenicola.com wrote: Presumably RedirectResponse being a subtype would also be acceptable, as its .prototype.constructor would be RedirectResponse? Yeah, although I'm not sure there's a need to override any functionality here, so not sure that there's a need for subclassing. Agreed. So Response.redirect(url, status)? Btw, I'd like to add similar-style factories to Response which set header mode defaults Response.image(url); Response.font(url); etc. Don't need these for the first pass though.
Re: File API - Writer suspension
On 6/2/14 11:28 AM, Arun Ranganathan wrote: On Jun 1, 2014, at 1:22 PM, Julian Ladbury julian.ladb...@berrick-computing.co.uk mailto:julian.ladb...@berrick-computing.co.uk wrote: I fail to understand why work on this API has been suspended. Just to be clear, by “this API” I think you mean: http://dev.w3.org/2009/dap/file-system/file-writer.html Julian - the group agreed to stop work on the File API: Directories and System [1] and File API: Writer [2] specs. The group also agreed to work on: FileSystem API http://w3c.github.io/filesystem-api/Overview.html [Hint for Arun: move this spec toward FPWD?] -AB [1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html [2] http://dev.w3.org/2009/dap/file-system/file-writer.html
Re: WebApp installation via the browser
On June 2, 2014 at 4:52:41 PM, Alex Russell (slightly...@google.com) wrote: The Chrome team is excited about this direction and is collaborating on the manifest format in order to help make aspects of this real. In particular we're excited to see a Service Worker entry added to the format in a future version as well as controls for window decorations and exit extents. This is great to hear. I've captured SW integration in the issue tracker [#161], but would like to hear more about what you have in mind for window decorations and exit extents. If you can give me some pointers to what you mean, I'm happy to go and do the research for the use cases, etc. [#161] https://github.com/w3c/manifest/issues/161 -- Marcos Caceres
RE: File API - Writer suspension
Arthur Arun, Thank you for your help and clarification. I can calm down now! Yes, to be clear, by this API I did mean: http://dev.w3.org/2009/dap/file-system/file-writer.html Julian -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: 03 June 2014 15:06 To: Arun Ranganathan; Julian Ladbury Cc: Web Applications Working Group WG Subject: Re: File API - Writer suspension On 6/2/14 11:28 AM, Arun Ranganathan wrote: On Jun 1, 2014, at 1:22 PM, Julian Ladbury julian.ladb...@berrick-computing.co.uk mailto:julian.ladb...@berrick-computing.co.uk wrote: I fail to understand why work on this API has been suspended. Just to be clear, by this API I think you mean: http://dev.w3.org/2009/dap/file-system/file-writer.html Julian - the group agreed to stop work on the File API: Directories and System [1] and File API: Writer [2] specs. The group also agreed to work on: FileSystem API http://w3c.github.io/filesystem-api/Overview.html [Hint for Arun: move this spec toward FPWD?] -AB [1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html [2] http://dev.w3.org/2009/dap/file-system/file-writer.html
Re: HTML imports: new XSS hole?
On 02/06/2014 15:08 , Boris Zbarsky wrote: On 6/2/14, 9:02 AM, James M Snell wrote: I suppose that If you needed the ability to sandbox them further, just wrap them inside a sandboxed iframe. The worry here is sites that currently have html filters for user-provided content that don't know about link being able to run scripts. Clearly once a site knows about this they can adopt various mitigation strategies. The question is whether we're creating XSS vulnerabilities in sites that are currently not vulnerable by adding this functionality. P.S. A correctly written whitelist filter will filter these things out. Are we confident this is standard practice now? I haven't bumped into a blacklist filter in a *long* while. I suspect that any that might exist will be hand-rolled and not part of any platform. The odds are pretty strong that they're already unsafe if not wide open. So I would say there's a risk, but not a huge one. That said, I still prefer Simon's approach. PS: I've been wondering if adding an HTML sanitiser to the platform might make sense. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Fetch API
On Thu, May 29, 2014 at 4:58 PM, Marcos mar...@marcosc.com wrote:
I would change them to:
enum RequestMode { same-origin, cors, cors-tainted, cors-preflight };
cors-preflight does not really express the same thing. cors might
have preflights too. But maybe I should hide the difference between
CORS and CORS-with-forced-preflight at the API level.
enum RequestOmitCredentialsMode { always, CORS, never };
The item CORS here is not self evident (unlike always/never modes). Can
you find a better word?
Jake came up with same-origin which works if you rename omit
credentials mode to credentials mode and flip the other values as
well. That's implemented now.
--
http://annevankesteren.nl/
Re: Fetch API
On Tue, Jun 3, 2014 at 3:04 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Agreed. So Response.redirect(url, status)? LGTM Done. -- http://annevankesteren.nl/
Re: Fetch API
On Sun, Jun 1, 2014 at 8:06 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
- HeaderMap should have a constructor that takes an iterable of [key, value]
pairs, in the same way Map does.
Yeah, waiting for IDL hooks that would work here ;-)
- I like HeaderMap a lot, but for construction purposes, I wonder if a
shorthand for the usual case could be provided. E.g. it would be nice to be
able to do
fetch(http://example.com;, {
headers: {
X-Foo: Bar
}
});
instead of, assuming a constructor is added,
fetch(http://example.com;, {
headers: new HeaderMap([
[X-Foo, Bar]
])
});
Yeah, it's not clear to me what is best here. An object whose keys are
ByteString and values are either ByteString or a sequence of
ByteString? I agree that we want this. Part of the problem here is how
to best represent HTTP headers. See
https://github.com/slightlyoff/ServiceWorker/issues/300 for more
details.
--
http://annevankesteren.nl/
Re: Fetch API
On 3 June 2014 16:50, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Jun 1, 2014 at 8:06 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
- I like HeaderMap a lot, but for construction purposes, I wonder if a
shorthand for the usual case could be provided. E.g. it would be nice to be
able to do
fetch(http://example.com;, {
headers: {
X-Foo: Bar
}
});
instead of, assuming a constructor is added,
fetch(http://example.com;, {
headers: new HeaderMap([
[X-Foo, Bar]
])
});
Yeah, it's not clear to me what is best here. An object whose keys are
ByteString and values are either ByteString or a sequence of
ByteString? I agree that we want this.
I vote ByteString: ByteString. If you want something more complicated,
provide a HeaderMap or mutate after construction.
Re: HTML imports: new XSS hole?
A clarification to make sure people in same page: On Mon, Jun 2, 2014 at 5:54 AM, James M Snell jasn...@gmail.com wrote: So long as they're handled with the same policy and restrictions as the script tag, it shouldn't be any worse. HTML Imports are a bit more strict. They see CORS header and decline if there is none for cross origin imports. Also, requests for imports don't send any credentials to other origins. On Jun 2, 2014 2:35 AM, Anne van Kesteren ann...@annevk.nl wrote: How big of a problem is it that we're making link as dangerous as script? HTML imports can point to any origin which then will be able to execute scripts with the authority of same-origin. -- http://annevankesteren.nl/ -- morrita
Re: HTML imports: new XSS hole?
On 6/3/14, 12:48 PM, Hajime Morrita wrote: HTML Imports are a bit more strict. They see CORS header and decline if there is none for cross origin imports. Also, requests for imports don't send any credentials to other origins. These two measures prevent attacks on other origins via imports. It does nothing about attacks by the imported script on the page the import is happening into. -Boris
Re: HTML imports: new XSS hole?
On Tue, Jun 3, 2014 at 9:59 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/3/14, 12:48 PM, Hajime Morrita wrote: HTML Imports are a bit more strict. They see CORS header and decline if there is none for cross origin imports. Also, requests for imports don't send any credentials to other origins. These two measures prevent attacks on other origins via imports. It does nothing about attacks by the imported script on the page the import is happening into. Perhaps it would make sense to also require explicit allowing of imports via CSP? Scripts are allowed when no CSP is provided for historical compatibility so you'd need to make sure that imports fell under a separate directive, but there's no need for backwards compatibility so it probably makes sense to choose a more conservative default behaviour for HTML Imports.
Re: Fetch API
On Tue, Jun 3, 2014 at 9:38 AM, Jake Archibald jaffathec...@gmail.com wrote:
On 3 June 2014 16:50, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Jun 1, 2014 at 8:06 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
- I like HeaderMap a lot, but for construction purposes, I wonder if a
shorthand for the usual case could be provided. E.g. it would be nice to be
able to do
fetch(http://example.com;, {
headers: {
X-Foo: Bar
}
});
instead of, assuming a constructor is added,
fetch(http://example.com;, {
headers: new HeaderMap([
[X-Foo, Bar]
])
});
Yeah, it's not clear to me what is best here. An object whose keys are
ByteString and values are either ByteString or a sequence of
ByteString? I agree that we want this.
I vote ByteString: ByteString. If you want something more complicated,
provide a HeaderMap or mutate after construction.
One thing we should keep in mind is if we actually need to support
100% of all the crazyness that servers do. And especially if we need
to support it in a particularly convenient way.
Something like
headers: {
X-Foo: Bar
}
Does actually have a defined order between the name-value pairs, even
though it's not terribly explicit. And we could even support
headers: {
X-Foo: [Bar, Bar2]
}
For supporting sending multiple X-Foo headers.
This wouldn't support interleaving headers such that we send two
X-Foo headers with a X-Bar header in between, but are there
actually use cases for that?
I feel fairly sure that simply doing:
headers: {
X-Foo: [Bar, Bar2]
}
Will cover well over 99% of everything that people need to do. And
hopefully the remaining part of a percent could update their servers
to actually support HTTP semantics properly.
/ Jonas
RfC: Last Call WD of Encoding; deadline July 1
All, This is a Request for Comments for the June 3 Encoding specification that WebApps was asked to review: http://www.w3.org/TR/2014/WD-encoding-20140603/ Individual WG members are encouraged to provide individual feedback. If anyone in WebApps wants to propose an official group response, please do so ASAP, in reply to this e-mail so the group can discuss it. Comments should be sent to www-internatio...@w3.org [1] by July 1. Presumably, group also welcomes data about silent reviews, f.ex. I reviewed section N.N and have no comments. Addison - if there are any specific section(s) you want WebApps to review, please let us know. Also, unless we here otherwise from you, we will assume our review should be against the LCWD and _not_ the latest ED. -Thanks, AB [1] http://lists.w3.org/Archives/Public/www-international/ On 6/3/14 3:44 PM, Phillips, Addison wrote: Today, 3 June 2014, the Internationalization Working Group published a Last Call Working Draft of the Encoding specification. The Internationalization WG specifically invites the following working group's comments: HTML, CSS, Webapps, Webapps Security, SVG, XML Core. We welcome and encourage other reviews. Title: Encoding Publication: 3 June 2014 LC Ends: 1 July 2014 URI: http://www.w3.org/TR/encoding/ Full LC URI: http://www.w3.org/TR/2014/WD-encoding-20140603/ Editors URI: http://encoding.spec.whatwg.org/ Instructions for Providing Feedback: Please submit comments to the www-internatio...@w3.org mailing list with a subject line prefixed with [Encoding]. The Internationalization working group will track issues and create bugzilla bugs for you. Issues are tracked by the Working Group here: https://www.w3.org/International/track/products/25 Open bugs against the Encoding spec are found here: https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWGcomponent=Encodingresolution=--- Abstract of this Specification: While encodings have been defined to some extent, implementations have not always implemented them in the same way, have not always used the same labels, and often differ in dealing with undefined and former proprietary areas of encodings. This specification attempts to fill those gaps so that new implementations do not have to reverse engineer encoding implementations of the market leaders and existing implementations can converge. This document is a snapshot of the WHATWG document of the same name. Record of the Decision to Request Transition: http://www.w3.org/2014/05/29-i18n-minutes.html#item05 There are no formal objections to this document currently. The patent disclosure page is located here: http://www.w3.org/2004/01/pp-impl/32113/status The last call period for this document will end 1 July 2014 (approximately 4 weeks). Addison Phillips Chair (W3C I18N WG)
[Bug 25969] New: [XHR] Does process response body get processed even if the XHR is abort()-ed in readystatechange?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25969 Bug ID: 25969 Summary: [XHR] Does process response body get processed even if the XHR is abort()-ed in readystatechange? Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: tyosh...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org process response and process response body are separately queued (specified in fetch.spec.whatwg.org). Even if abort() is called in readystatechange handler in process response, it seems we'll run queued task to run process response body and run redundant Handle errors for response step and unexpectedly (I believe) run steps 3 and 4. Don't we want to insert state check to process response body algorithm to skip them, or cancel tasks queued in the networking task source on termination of fetch? Or, that handle the tasks queued is placed in the step 13. Fetch req ... implies that termination of fetch also cancels task handling? Anyway, it's nice to add some text for clarification. -- You are receiving this mail because: You are on the CC list for the bug.
