Re: send data using the Web Socket and UCS-2
Jonas Sicking: Yes, I don't see how we could handle this in WebIDL, other than defining that all DOMStrings must be structurally correct UTF-16. However that would be prohibitively expensive since we would have to add checks in many many places. I agree, I don’t think it would be good to require this. Anne van Kesteren: Web IDL could define algorithms how you convert a DOMString to and from UTF-8. And maybe other encodings if that is desirable. I added a simple algorithm that converts a sequence of 16 bit code units to a sequence of Unicode characters, inserting U+FFFD characters when bad surrogates are used: http://dev.w3.org/2006/webapi/WebIDL/#dfn-obtain-unicode Nothing in Web IDL references this algorithm. Other specs can do so if it is useful. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] overloading and fallback
Anne van Kesteren: In XMLHttpRequest in the send() method is overloaded to take a Document and a DOMString. All non-Document objects are treated with the semantics of DOMString. (Attempt to stringification etc.) Is there a way to specify this without explicit language in the specification? I added [AllowAny] to support this: http://dev.w3.org/2006/webapi/WebIDL/#AllowAny -- Cameron McCormack ≝ http://mcc.id.au/
Re: [webidl] DOMString
Anne van Kesteren:
If something takes a DOMString as value is it clearly defined what
happens if the toString algorithm throws or returns a non-DOMString? I
haven't been able to find descriptions for that in the Web IDL
specification. E.g.
obj = { toString:function() { throw(haha) } }
obj2 = { toString:function() { return 1 } }
obj3 = { toString:function() { return obj } }
Oliver Hunt:
The [[ToString]] algorithm is defined in ECMAScript (Section 9.8, [1]),
the specified behaviour would result in [[ToString]] on obj2 producing
the string 1; [[ToString]] on obj3 will result in a TypeError, as
[[DefaultValue]] will produce a non-primitive type (Section 9.1, [1])
I would assume that the exception will be propagated to the runtime, but
it should be stated.
Added some text for this:
http://dev.w3.org/2006/webapi/WebIDL/#es-handling-exceptions
Let me know if you think it’s insufficient.
Thanks,
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [cors] Web application
Anne, Might I suggest that it seems more logical because you work for a browser vendor, and are steeped in the client-side application world? A Web service means many different things to many different people (SOAP, WSDL, REST, etc.) and generally refers to an exposed API, not a web application. As far examples: http://en.wikipedia.org/wiki/Web_application_framework http://www.scripting.com/davenet/2000/03/12/ whatIsAWebApplication.html http://www.webappsec.org/ http://java.sun.com/javaee/technologies/webapps/ ... and that's just from the first page of search results. Note that I'm not disputing that what's in-scope here *could* be called a Web Application -- just that it's a very broad and muddy term that may mislead people who come at this document from a different angle. Anyway, it was just a suggestion, not a big deal. Cheers, On 16/06/2009, at 3:05 AM, Anne van Kesteren wrote: Mark, You said Web application has been traditionally used to refer to server-side applications. Is there any reference for this? It seems more logical to call those Web services to me. Also, the name of this group suggests Web applications is pretty much client-side so I'm thinking of simply removing client-side within CORS. Cheers, -- Anne van Kesteren http://annevankesteren.nl/ -- Mark Nottingham m...@yahoo-inc.com
Re: [cors] Web application
On Wed, 17 Jun 2009 08:51:00 +0200, Mark Nottingham m...@yahoo-inc.com wrote: Might I suggest that it seems more logical because you work for a browser vendor, and are steeped in the client-side application world? A Web service means many different things to many different people (SOAP, WSDL, REST, etc.) and generally refers to an exposed API, not a web application. As far examples: http://en.wikipedia.org/wiki/Web_application_framework http://www.scripting.com/davenet/2000/03/12/whatIsAWebApplication.html http://www.webappsec.org/ http://java.sun.com/javaee/technologies/webapps/ ... and that's just from the first page of search results. Note that I'm not disputing that what's in-scope here *could* be called a Web Application -- just that it's a very broad and muddy term that may mislead people who come at this document from a different angle. Anyway, it was just a suggestion, not a big deal. Leaving it the same is no problem either. I realize a Web service is just an API on the server, but it seemed to me that any kind of other Web application would have some kind of UI part rendered in a Web browser. But yeah, given that this specification deals with requests I can see how it might be confusing if you don't know about e.g. XMLHttpRequest. -- Anne van Kesteren http://annevankesteren.nl/
Re: File API, Editor's Draft II
Hey Arun, On Jun 11, 2009, at 12:34 , Arun Ranganathan wrote: I'd like review on the most recent draft of the File API Just a few things on first pass, in a good spec: - Great idea listing the defined interfaces with links in the abstract, makes quick access easy; this should be standard for all API specs. - The indentation of your WebIDL snippets is a bit broken, which makes them hard to read. - Do we want to keep FileList? I think we're all tired of those. I know that the sequenceT section of WebIDL hasn't been written, but this could be a good way of encouraging Cameron :) I'd personally be all for killing that interface and just using sequenceFile. - FileAsText is poorly named IMHO, I had to reparse the description of getAsDataURI several times before I realised that it used FileAsText (which on quick read was immediately classified as for getAsText). How about just FileContent? - It might be useful if the FileAsText (or FileContent) callback got a second argument telling it what kind of data it's getting (in this case text or dataUri). No strong feelings on this, just a thought I'm putting out there. - There's some lexicographic confusion around URI/URL (for a change). Data URLs are called, well Data URLs (as per RFC 2397) and it's also the terminology you use in the prose. Yet the method is called getAsDataURI. Consistency wouldn't hurt, I don't really care which way. - Suggestion: how about having a mediaType attribute on File? The system usually knows such things (I believe) and it could be useful for scripts to decide what to do based on what users have picked, or to correctly label the file when interacting with a service (e.g. DAV). - Flash doesn't ask permission to show the file picker, but it requires genuine interaction (as of F10 you can't trigger it without interacting with Flash content). - For FileListDataCallback what happens if the user cancels? Do I get an error? A defined but empty FileList? I have a slight preference for the latter, but either way the author should be notified. - General note on asynchronous calls: instead of void, should they return an opaque token which can be used to cancel the request (or provide one way or another of doing that, possibly just having cancel() on the object)? That's available on setTimeout/setInterval, and on XHR — it's generally useful. - How do you propose to handle encoding errors? Say a file is UTF8 and I request it as ASCII? Drop what can't be converted? Use a replacement character? Throw an error? -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [cors] Review
On Wed, 17 Jun 2009 07:41:42 +0200, Tyler Close tyler.cl...@gmail.com wrote: One solution is: 1. Don't add any client credentials to requests. 2. Allow the script to use whatever HTTP method, headers and request entity it wants, restricting use of some headers, such as Referer. This leaves resources relying solely on a firewall for authentication vulnerable. It also leaves sites vulnerable that do IP-based authentication. -- Anne van Kesteren http://annevankesteren.nl/
[widgets] conformance requirements review
Hi, I wrote a simple XSLT to extract the conformance requirements from the Widgets spec [1], with the following output: http://www.w3.org/2005/08/online_xslt/xslt?xslfile=http%3A%2F% 2Fdev.w3.org%2F2006%2Fwaf%2Fwidgets%2Ftests% 2FextractTestAssertions.xslxmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin% 2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fwww.w3.org%252FTR%252Fwidgets% 252F Based on these, here is a review of the Widgets spec based on conformance requirements analysis: * ideally, only the classes of products would appear as subjects of the conformance requirements; e.g. A folder may contain zero or more file entries or zero or more folders would be rephrased as A valid widget package may contain folders with zero or more file entries or zero or more folders; this would have two benefits: simplify the analysis of conformance requirements for building test suites, and identify possible ambiguities as to what is affected when the conformance requirements is not respected; that said, I don't think it is crucial so feel free to not go through all the conformance requirements if that's too much work * similarly, conformance requirements that use the passive voice are suspect (since they often don't tell to which class they apply) * For sniffing the content type of images formats, a user agents must use the rule for Identifying the media type of an image - this assumes that the user agent already knows the file it is sniffing is an image; if that's true, the text should make it clear why, and if not, it should probably be reworded to say that a user agent must sniff for images format first * rather than say Reserved file names must be treated as case-sensitive, I would amend the previous sentence to say The reserved file names table, below, contains a *case-sensitive* list... (and similarly for folder names) * If [...] the start file is not one that is supported by a particular user agent, then the CC must inform the author: does that mean that a CC need to know all the supported formats by all user agents? That seems a bit excessive - I guess I can see cases where a conformance checker could be configured to report knowledge on a special user agent, but that would need to be made explicit, and clearly shouldn't be a must * a widget may attempt to access the feature identified by the feature element's name attribute I think the may here is not intended as a conformance requirement, so it probably shouldn't be marked as such * there is a spurious empty em class=ct/em element in A feature canem class=ct/em have zero or more a href=#parameter0 title=parameterparameters/a associated with it. * The steps for processing a widget package involves nine steps that a user agent SHOULD follow ; the should appear in upper case in the source, while other conformance requirements are lower case * a user agent must to decompress is not correct English * If a user agent encounters an unusable file entry, it must ignore the file entry: is ended by a colon, but followed by a new sentence * The algorithm always returns a string, which may be empty: again, this may doesn't look like a conformance requirement so shouldn't be marked as such * that must eventually be presented to the end-user - I don't think this is meant as a conformance requirement (e.g. a conformance checker is a user agent, but will probably never present any of the widget content to the end-user); I would reword it as to be presented to the end user * an error condition can ask the user agent ignore an object I don't think error conditions can ask anything to anyone in general, so I would rephrase it; I think ignore needs a preceding to too. HTH, Dom 1. http://dev.w3.org/2006/waf/widgets/tests/extractTestAssertions.xsl
Re: [WebIDL] On overloaded operations in an effective overload set
Hi Cameron, The [AllowAny] extended attribute looks nice, and it will provide a clearer ECMAScript runtime semantics. One thing still not very clear to me is that a DOMString with [AllowAny] and a primitive type should be distinguishable as in the example or not; maybe should we treat a parameter with [AllowAny] like an 'any' type in an effective overload set for simplicity? Thank you, - Shiki ps. it's good to see the 'double' type in Web IDL. On Wed, Jun 17, 2009 at 3:34 PM, Cameron McCormackc...@mcc.id.au wrote: Hi Shiki. Shiki Okasaka: I've chatted with several engineers and researchers about this. If this interface A becomes an effective overload set in Web IDL, we need a clear set of rules to resolve ECMAScript function calls like below into either f2 or f3: a.f(123, hello, there, 3.14); a.f(not a number, hello, 2.72, 3.14); a.f(123, 1234, 3.14, 2.72); And it seems defining those rules would be not very easy. I’ve made DOMString and the numeric boolean types be distinguishable, now. Your examples from the original mail in this thread, * f2, (DOMString, DOMString) and f3, (long, DOMString) * f2, (DOMString, DOMString, float) and f3, (long, DOMString, DOMString) * f2, (DOMString, DOMString, float, float) and f3, (long, DOMString, DOMString, float) should now work. I have revised the definition of the effective overload set and the overload resolution algorithm. Review would be welcome. http://dev.w3.org/2006/webapi/WebIDL/#dfn-effective-overload-set http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: 'scroll' and 'resize' events
On Wed, 17 Jun 2009 08:56:43 +0200, Ian Hickson i...@hixie.ch wrote: As mentioned on IRC, it would be cool if the CSSOM spec could define when to fire 'scroll' and 'resize' events. If there's a particular place I should log this so that whoever takes over that spec doesn't lose this feedback, let me know. For people following this thread: This is now logged in the CSS WG issue tracker by Ian as that is the group working on the CSSOM. -- Anne van Kesteren http://annevankesteren.nl/
Re: [WebIDL] On overloaded operations in an effective overload set
Shiki Okasaka: The [AllowAny] extended attribute looks nice, and it will provide a clearer ECMAScript runtime semantics. One thing still not very clear to me is that a DOMString with [AllowAny] and a primitive type should be distinguishable as in the example or not; I am thinking that [AllowAny] is an ECMAScript-specific extended attribute that just influences the overload resolution algorithm. As such, it wouldn’t affect the definition of “distinguishable”. So: void f(in DOMString x); void f([AllowAny] in long x); would remain distinguishable, unlike: void f(in DOMString x); void f(in any x); maybe should we treat a parameter with [AllowAny] like an 'any' type in an effective overload set for simplicity? It is effectively treated as ‘any’ in the overload resolution algorithm, since if the there is a true value in the list of booleans that is the third element of the triples in the effective overload set, any removals of entries from the set are skipped when looking at that argument position. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] On overloaded operations in an effective overload set
I see. So the expected ECMAScript behaviour is to try to invoke an operation that can be executed without applying ToString(), ToNumber(), etc., to [AllowAny] parameters firstly, and then look for an invokable operation taking [AllowAny] into account if no such method was found? - Shiki On Wed, Jun 17, 2009 at 6:15 PM, Cameron McCormackc...@mcc.id.au wrote: Shiki Okasaka: The [AllowAny] extended attribute looks nice, and it will provide a clearer ECMAScript runtime semantics. One thing still not very clear to me is that a DOMString with [AllowAny] and a primitive type should be distinguishable as in the example or not; I am thinking that [AllowAny] is an ECMAScript-specific extended attribute that just influences the overload resolution algorithm. As such, it wouldn’t affect the definition of “distinguishable”. So: void f(in DOMString x); void f([AllowAny] in long x); would remain distinguishable, unlike: void f(in DOMString x); void f(in any x); maybe should we treat a parameter with [AllowAny] like an 'any' type in an effective overload set for simplicity? It is effectively treated as ‘any’ in the overload resolution algorithm, since if the there is a true value in the list of booleans that is the third element of the triples in the effective overload set, any removals of entries from the set are skipped when looking at that argument position. -- Cameron McCormack ≝ http://mcc.id.au/
[widgets] Draft Agenda for 18 June 2009 Voice Conference
Below is the draft agenda for the June 18 Widgets Voice Conference (VC). Inputs and discussion before the meeting on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 90 minutes (maximum) Zakim Bridge +1.617.761.6200, conference 9231 (WAF1) IRC channel = #wam; irc.w3.org:6665 Confidentiality of minutes = Public Agenda: 1. Review and tweak agenda 2. Announcements a. Public call for prior art on Widgets 1.0 Updates spec: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0937.html 3. PC LC Comments http://dev.w3.org/2006/waf/widgets/ Comment Tracking doc: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-20090528/ a. Comments from Dom Hazael-Massieux (12 June and 15 June) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0936.html http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0971.html b. Comments from Francois Daoust (14 June) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0962.html c. Comments from Opera (15 June; submitted by Marcos) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0975.html d. Comments from Dom Hazael-Massieux (17 June) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 1021.html 4. Who should be asked to review the FPWDs of the WARP spec and the URI Scheme spec (besides public-webapps)? a. WARP spec: public-device-a...@w3.org, ? b. URI Scheme spec: TAG (www-...@w3.org), public-pkg-uri- sch...@w3.org, ? 5. AOB
XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, 17 Jun 2009 01:52:36 +0200, Mark S. Miller erig...@google.com wrote: I've now read the relevant portions of http://dev.w3.org/html5/spec/Overview.html#the-iframe-element. Looks like a great start on the right direction! I'm genuinely enthused. Some questions: FWIW, I may be wrong in which case I hope Ian will correct me. The second example says [...] and the origin sandbox restrictions are lifted, allowing the gadget to communicate with its originating server. I don't understand this. Given the cors this document assumes, couldn't the gadget do a cross-domain xhr to the originating server anyway? HTML5 does not assume CORS at this point I believe. Having said that, the sandboxed origin browsing context flag does more. It forces the content of the iframe into a unique origin. A number of features are disabled because of this: * storage * same-origin communication channels * document.cookie * communicating with the document that hosts the iframe if they're same-origin And maybe more. Does an xhr from a sandboxed unique origin iframe carry any credentials in the sense in which we've been using in this thread: * HTTP auth info * cookies (I think the text implied not, but I'd like to check.) I don't think these are impacted though XMLHttpRequest cannot be used to read or set cookies. (They will still be included in the request as currently drafted.) * client-side certs I don't have sufficient knowledge about these to answer :/ * REFERRER I think Referer is still included. This may have been an oversight. * identified Origin (clearly not if I understand the spec) Unless same-origin is set the origin is a unique identifier. That equals the string null in requests. * Anything else I forgot? I don't think so. If it does transmit any of these currently, are there any objections to revising the spec so that it doesn't? Not necessarily. I'd like to know what Ian thinks about this. What happens if a data: URI appears as the value of the src attribute? Would this allow the containing page to construct and provide the source directly? Or is this what the document=... you mention above is for? The document= or doc= idea is to have something simpler than data URLs. Basically all you'd have to escape is the double or single quotes used around the attribute value and inside could be a complete HTML document. data URLs accomplish the same but are tricker with respect to escaping rules. How does a sandboxed, unique origin iframe communicate with its containing page? My guess is postMessage, which is necessarily asynchronous. However, the useful functionality of the GuestXHR we've been discussing would be async as well. (Unless html5 has separate provisions to make sync xhr practical, which would be surprising.) If you spawn worker threads as detailed in http://dev.w3.org/html5/workers/ synchronous XMLHttpRequest is somewhat usable again. Though not ideal if you also care about things such as progress events etc. So async GuestXHR would play well with async postMessage as follows: Given the above elements including the removal of all credentials and the acceptance of either document=... (if I have that right) or src=data:..., then it seems we may be able to build the GuestXHR we've been talking about as an object in the containing page that uses postMessage to relay requests to a sandboxed unique origin iframe acting as a credential removal laundry. Is this analysis right? What am I missing? In what ways would these not be equivalent? postMessage reveals the origin of the containing page. On the other hand, if a sandboxed iframe restricts XMLHttpRequest in various ways XMLHttpRequest is GuestXMLHttpRequest in a sense unless I'm missing something. If the above speculations are on the right track, it could be the basis for something much simpler than cors for enabling cross origin xhr requests: Only allow cross origin xhrs from browsing contexts that have the sandboxed origin browsing context flag set. These xhrs are credential-free and not associated with any other origin, and so can safely go cross-origin. For any browsing context without this flag set, its xhr is restricted by the conventional old same-origin policy. If it want to issue a cross origin request, it can use a sandboxed unique origin iframe to launder out any credential confusion. I followed you so far, but I don't think we want this :-) Besides that this causes issues for sites based on IP-authentication it seems that having credentialed XMLHttpRequest is a useful thing to have. The recommended server behavior would then be to allow or deny an Origin: null request based only on authorization information explicitly placed into the payload, avoiding confused deputy confusions. All redirect-path origin accumulation problems disappear as unnecessary, as would server-side origin-based ACLs. Thanks for
[selectors-api] Transitioning to CR
Hi, In order to complete the transition of Selectors API to CR, there were a number of things that needed to be done, following the call for consensus we had in April/May. http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0471.html 1. Write CR Exit Criteria 2. Write updated Status of the Document section 3. Complete the test suite *CR Exit Criteria* I propose the following as the CR exit criteria: At least two interoperable implementations of each feature, dependent upon the following conditions: * Each individual test in the test suite must pass in at least two of the reviewed implementations. * Test failures in a given implementation caused by the lack of support for a particular feature of an independent specification are not counted. This does not apply to failures caused by an incorrect implementation of such features. (e.g. IE lacks support for many of the CSS3 selectors tested in the test suite, but to be fair, these failure should be ignored.) * Each implementation reviewed must have at least a 95% pass rate, not counting ignored tests. (With these criteria, I believe the current available implementations in at least Firefox, Opera and Safari, will be sufficient to exit CR, even though each fails a small subset of the tests.) *Status of the Document* In December, I wrote a draft transition request which can be used. However, I've made minor updates to the proposed Status of the Document section. --- This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. This is the XXX June 2009 Candidate Recommendation of Selectors API. W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. The Web Applications (WebApps) Working Group expects to request that the Director advance this document to Proposed Recommendation once the Working Group has developed a comprehensive Selectors API test suite, and demonstrated at least two interoperable implementations for each test. There are several known implementations believed to be complete and interoperable (or on the point of being so) and the WebApps Working Group expects to develop a test suite and use it to show that that these implementations pass by July 2009. The Working Group does not plan to request to advance to Proposed Recommendation prior to 01 July 2009. The Last Call Working Draft for this specification resulted in a number of Last Call comments which have all been addressed by the Working Group, a list of which can be found in the Disposition of Comments. The W3C Membership and other interested parties are invited to review the document and send comments to public-webapps@w3.org (public archive) with [selectors-api] in the subject, through 12 December 2008. (Please note that a different list was used until mid 2008, so some old messages are archived there instead). The editor’s copy of this specification is available in W3C CVS. A detailed list of changes is also available from the CVS server. This document was developed by the Web Applications Working Group. The Working Group expects to advance this Working Draft to Recommendation Status. Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy. --- *Test Suite* Finally, there were a number of additional tests that needed to be reviewed and either incorporated into the test suite, or rejected. 1. Erik proposed additional tests related to using Selectors API with SVG content. His proposal would add SVG directly into the existing test suite file. However, as the existing file is HTML, not XHTML, this will not work in current browsers, and would instead require the tests to be in a separate XHTML file. http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0788.html 2. Hixie proposed two sets of tests. The first seems to be non-controversial and I believe it should be integrated into the test suite. http://www.hixie.ch/tests/adhoc/dom/selectors/001.html Based on past discussion, however, the second
Re: [widgets] PC LC, general comments
8.11 The content element, definition of charset attribute: - Despite widespread use, the name charset is not good. A more accurate name would be encoding. I've given another pass at this section: encoding A keyword attribute that denotes the character encoding of the file identified by the src attribute. The allowed value is the name or alias of any Character Set listed in [IANA-Charsets]. A user agent MUST support [UTF-8], which has the UTF-8 name in [IANA-Charsets]; all other character encodings are optional. It is optional for authors to use this attribute. When the value of encoding is absent or in error, the user agent will assume the default encoding which is the value UTF-8. Authoring Guideline: Where aliases are given by the [IANA-Charsets], authors are encouraged to use those aliases marked as preferred MIME name. - Suggest to replace (a user agent are REQUIRED to support [UTF-8]) with User agents MUST support [UTF-8]. I had missed this in the last set of comments. Fixed. -- Marcos Caceres http://datadriven.com.au
[widgets] PC Last Call Period
Just a gentle reminder that the PC Last Call period ends on 19 June. Comments after the deadline will not be considered until we are in CR (or in another Last Call, if need be). Spec is at: http://dev.w3.org/2006/waf/widgets/ Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Progress Events normative text
On Mon, 15 Jun 2009 17:00:46 +0200, Charles McCathieNevile cha...@opera.com wrote: On Sat, 13 Jun 2009 13:54:10 +0200, Anne van Kesteren ann...@opera.com wrote: That definitely makes sense, though please take into consideration that for cross-origin loads exposing the file size cannot be done until all HTTP headers have been received and the requested resource has opted in with CORS. OK. One of the things I intended to keep leaving to the host spec was definining what the size actually refers to. I'd think we would like this to consistently refer to the entity body for all usage of progress events as to not confuse people using the API. It seems odd to take great care in order and naming but not in consistent implementation of the event objects. Since interaction with CORS will have to be defined by the specification defining the API (due to things such as source origin) the specifics of event dispatching will also need to be defined there and can probably not be done in a generic way. (Unless you make it integrate well with CORS semantics somehow I suppose, but that might just make matters more confusing.) Can you elaborate? Exposing file size for cross-origin loads is a concern as I understand it. It makes it easier to do port scanning. So in order to prevent that resources loaded in a cross-origin fashion would have to opt in to sharing this information (much like they opt in to share the resource itself) and therefore they have to follow the model that CORS outlines. Also, as currently phrased it seems to place limitations on specifications. E.g. if we want to introduce a timeout event in XMLHttpRequest for a specific operation the specification currently requires user agents to also dispatch a load/error/abort event in such scenarios Yes, that's the way I understand it. which we do not want I think. Why not? (thinking out loud, it makes sense to me that the requirement becomes a should, enabling specs to define things in different ways while providing some clear guidance to people who don't want to guess. But if you have some clearer thoughts about use cases and requirements that would be helpful...) There's no reason for XHR2 to also dispatch one of load/error/abort if it already does both timeout and loadend. And I think you want to know the difference by the request being aborted due to a timeout versus a script or user initiated abort. Even SHOULD seems too strong for this in my opinion. Second, it should provide a reasonable default - if specifications are defining something significantly different then the defaults themselves should be changed to match that. But if they are not, then it is saving specifications from guessing what makes sense as a default behaviour... It seems to do a little more than saving specifications from guessing :-) Then what it says doesn't match what I intend it to say. Some more detailed explanation would help me spot where the problems are. User agents must ensure that these events trigger event listeners attached on Element nodes for the relevant event and on the capture and target phases. does not work for XMLHttpRequest or XMLHttpRequestUpload. Neither is an Element node. Also, this requirement should be present in DOM Events and it would help I think if it was not restated here. (If you think it helps make it a non-normative note about DOM Events.) Specifications should use the events defined in this specification in preference to other events (e.g. in a different namespace, or with a different name) that offer the same functionality. is another example. The section Event firing order duplicates text from e.g. XMLHttpRequest Level 2 which gives confusing and potentially contradictory requirements as I outlined above. I think that just as in CORS it should be advice given to API specifications, not requirements. Given that other specifications probably need to be fairly specific about when to dispatch certain progress events due to cross-origin loads etc. I still think it makes more sense to have no requirements in the specification regarding dispatching and have it be just an event name registry and interface description. On top of that you could have a single definition of what it means to dispatch a progress events: To *dispatch a progress event called x on y*, dispatch an event named x that implements the ProgressEvent interface on y with the members of the event object set as follows: namespace null bubbles false cancelable false lengthComputable true if the size of the resource is known. false otherwise. loaded The size of the entity body transferred so far. total The size of the entity body or zero if this is not known. Also, section 3 still talks about the now renamed start event. Furthermore, it also suggests the total member includes the request and
Re: [widgets] Public keys in widgets URI scheme?
Hi Aaron, Thanks for this info! really interesting... just a few questions below... On Tue, Jun 16, 2009 at 7:24 PM, Aaron Boodmana...@google.com wrote: On Tue, Jun 16, 2009 at 4:11 AM, Robin Berjonro...@berjon.com wrote: Just out of curiosity, would you mind expanding on the design ideas that you share with widgets that make you so happy? We're interested in happiness :) Also, do you think that beyond design ideas you could at some point reuse the concrete specifications that we've developed, and if not why, what's missing, etc.? Thanks! The intent of the Chrome extensions system is to reuse as much of the web platform as possible, just like with Widgets. In actual implementation, they are zipped packages of HTML, CSS, and JavaScript, which is similar to your design. Nice. But the thing I was talking about that we have been very happy with was the idea of using a public key as the unique identifier for an extension. This has worked very well for us. Every extension has an RSA key pair and the public key is the extension's one true unique ID (but for convenience, we also use a hash of the public key as an ID in some places). Every deployed instance of the extension is signed with this key pair. Does that mean that Google must sign every package? Can unsigned package be deployed? One interesting outcome of this is that it is impossible to have ID collisions. In systems where a GUID must be chosen by a developer, developers sometimes accidentally or maliciously copy the ID of another extension. This is not possible if the unique ID is the public key because the developer would have to know the private key, too, since every extension must be signed by the private key. Is that the developer's private key, or the vendor's (Google's) key? As for reusing the actual widgets spec, I think that there are some important differences. Chrome extensions are intended to extend the actual Chrome UI, not stand alone. I see, but you conceptually package things in the same way as widgets. I'm interested to see that you guys opted to put the signature and the manifest as the first bits of data of a package. Does that mean that chrome extensions cannot be read/opened by standard zip tools (I just tried this on my Mac, and seems to be the case)? If so, I guess that also means special/proprietary tools are needed to create chrome conforming packages for distribution. Aside from optimization reasons, was there any other reason why Chrome went down this route? So there are multiple surfaces where you can run HTML pages that are tightly coupled to the visual design of a browser (toolbars, sidebars, urlbar, etc). Similarly the APIs you have access to as a developer are frequently browser-related: bookmarks, history, etc. But the good thing is that as everyone seems to converge on HTML as the core of their systems, reuse gets easier and easier. If somebody did want to repackage an extension as a widget, it should be possible to reuse a lot of the code directly. Yes, I can certainly see that on the code path there would not be much problem (aside from the proprietary bookmarks, history, etc. APIs). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, Jun 17, 2009 at 4:29 AM, Anne van Kesteren ann...@opera.com wrote: HTML5 does not assume CORS at this point I believe. Having said that, the sandboxed origin browsing context flag does more. It forces the content of the iframe into a unique origin. A number of features are disabled because of this: * storage * same-origin communication channels * document.cookie * communicating with the document that hosts the iframe if they're same-origin What about communication using postMessage? As long as the iframe can communicate with its containing page using postMessage, denying the rest of these makes perfect sense, since the containing page can provide corresponding attenuated services based on its own access to these features. And maybe more. Does an xhr from a sandboxed unique origin iframe carry any credentials in the sense in which we've been using in this thread: * HTTP auth info * cookies (I think the text implied not, but I'd like to check.) I don't think these are impacted though XMLHttpRequest cannot be used to read or set cookies. (They will still be included in the request as currently drafted.) Is there no way to make the unique origin sandboxed iframe cookieless? I suppose, if not, the containing page could create a fresh unique origin sandboxed iframe per request, but seems rather heavy. Would that successfully render the resulting network messages cookieless? * client-side certs I don't have sufficient knowledge about these to answer :/ * REFERRER I think Referer is still included. This may have been an oversight. * identified Origin (clearly not if I understand the spec) Unless same-origin is set the origin is a unique identifier. That equals the string null in requests. Good. Yes, I was asking only about unique-origin sandboxed iframes. * Anything else I forgot? I don't think so. If it does transmit any of these currently, are there any objections to revising the spec so that it doesn't? Not necessarily. I'd like to know what Ian thinks about this. Wonderful! Ian? What happens if a data: URI appears as the value of the src attribute? Would this allow the containing page to construct and provide the source directly? Or is this what the document=... you mention above is for? The document= or doc= idea is to have something simpler than data URLs. Basically all you'd have to escape is the double or single quotes used around the attribute value and inside could be a complete HTML document. data URLs accomplish the same but are tricker with respect to escaping rules. Good. So syntax aside, would document=... and src=data:... to have identical semantics? How does a sandboxed, unique origin iframe communicate with its containing page? My guess is postMessage, which is necessarily asynchronous. However, the useful functionality of the GuestXHR we've been discussing would be async as well. (Unless html5 has separate provisions to make sync xhr practical, which would be surprising.) If you spawn worker threads as detailed in http://dev.w3.org/html5/workers/ synchronous XMLHttpRequest is somewhat usable again. Though not ideal if you also care about things such as progress events etc. Interesting. But I think we can still leave sync xhr aside for purposes of the present discussion. So async GuestXHR would play well with async postMessage as follows: Given the above elements including the removal of all credentials and the acceptance of either document=... (if I have that right) or src=data:..., then it seems we may be able to build the GuestXHR we've been talking about as an object in the containing page that uses postMessage to relay requests to a sandboxed unique origin iframe acting as a credential removal laundry. Is this analysis right? What am I missing? In what ways would these not be equivalent? postMessage reveals the origin of the containing page. to the contained sandboxed iframe. But it can of course choose not to include this info, so it can still act as a credential laundry for network message. On the other hand, if a sandboxed iframe restricts XMLHttpRequest in various ways XMLHttpRequest is GuestXMLHttpRequest in a sense unless I'm missing something. Excellent! If the above speculations are on the right track, it could be the basis for something much simpler than cors for enabling cross origin xhr requests: Only allow cross origin xhrs from browsing contexts that have the sandboxed origin browsing context flag set. These xhrs are credential-free and not associated with any other origin, and so can safely go cross-origin. For any browsing context without this flag set, its xhr is restricted by the conventional old same-origin policy. If it want to issue a cross origin request, it can use a sandboxed unique origin iframe to launder out any credential confusion. I followed you so far, but I don't think
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, 17 Jun 2009 15:22:27 +0200, Mark S. Miller erig...@google.com wrote: On Wed, Jun 17, 2009 at 4:29 AM, Anne van Kesteren ann...@opera.com wrote: * storage * same-origin communication channels * document.cookie * communicating with the document that hosts the iframe if they're same-origin What about communication using postMessage? As long as the iframe can communicate with its containing page using postMessage, denying the rest of these makes perfect sense, since the containing page can provide corresponding attenuated services based on its own access to these features. That will still work, but I don't think that's always enough. E.g. if you embed a Google Maps widget in your page it would be nice if the widget could still obtain user preferences from other visits to Google Maps (like default location) while not being able to spawn popups or navigate the top-level browsing context. Does an xhr from a sandboxed unique origin iframe carry any credentials in the sense in which we've been using in this thread: * HTTP auth info * cookies (I think the text implied not, but I'd like to check.) I don't think these are impacted though XMLHttpRequest cannot be used to read or set cookies. (They will still be included in the request as currently drafted.) Is there no way to make the unique origin sandboxed iframe cookieless? I suppose, if not, the containing page could create a fresh unique origin sandboxed iframe per request, but seems rather heavy. Would that successfully render the resulting network messages cookieless? Cookies (and HTTP authentication) in a request do not depend on the source but on the destination. So XMLHttpRequest would have to be explicitly told not to include them for one reason or another. [SNIP] The document= or doc= idea is to have something simpler than data URLs. Basically all you'd have to escape is the double or single quotes used around the attribute value and inside could be a complete HTML document. data URLs accomplish the same but are tricker with respect to escaping rules. Good. So syntax aside, would document=... and src=data:... to have identical semantics? Pretty much. data URLs have a little more freedom due to allowing any media type but are more complicated for authors to use. postMessage reveals the origin of the containing page. to the contained sandboxed iframe. But it can of course choose not to include this info, so it can still act as a credential laundry for network message. I think you misunderstand. Invoking postMessage() causes an event to be dispatched that as currently specified _always_ includes the origin from the script that invoked the method. (Currently this is specified in section 8.2.3 of HTML5.) On the other hand, if a sandboxed iframe restricts XMLHttpRequest in various ways XMLHttpRequest is GuestXMLHttpRequest in a sense unless I'm missing something. Excellent! If we make it so, that is ;-) I followed you so far, but I don't think we want this :-) Besides that this causes issues for sites based on IP-authentication it seems that having credentialed XMLHttpRequest is a useful thing to have. I don't understand. Could you expand on the IP-authentication issue? Thanks. Certain servers allow user access purely based on their IP. If such a user visits evil.com that site could do data theft and potentially other harmful things to the site the user is authenticated with through IP-based authentication if cross-origin requests do not require any kind of opt in. Since you say Besides above, are there other reasons we don't want this? I think we want requests that include authentication data as well. It seems you are suggesting HTTP authentication and cookies have no use. Which might be fine, but is a completely different perspective from what we have been operating with here. -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] origin and redirects
On Tue, 16 Jun 2009 18:12:14 +0200, Mark S. Miller erig...@google.com wrote: On Tue, Jun 16, 2009 at 8:05 AM, Anne van Kesteren ann...@opera.com wrote: This creates some related issues we have to sort out one way or another: A) How does this affect Access-Control-Allow-Origin? B) How does this affect the preflight result cache? I am very glad that the current cors document explains recommended server behavior. Any enhancement, changes, or alternatives to cors should follow this example. If the Origin header expands to carry a list of origins, then we should update the cors recommended server behavior to account for this. Right. Only then can we evaluate what new vulnerabilities we create by adding yet more epicycles. If we cannot write down a coherent recommendation for how servers should make use of this new information, then we should not propose to provide this new information. Yeah, I do not think this is the problem though. Although it does increase complexity. Not sure if it increases it significantly, but comparing a list is certainly more complex than a string. If cors is indeed on a path to recapitulate the Java stack introspection architecture as Tyler alleges, I would expect the first recommendation to be: Check every origin in the set against the resource's ACL. Only if the ACL allows this access for all origins in the set, then the access is allowed. IIRC, this recapitulates something like Java 1.1 or so. If this is indeed the cors path, the next step on this path would be to allow the redirections to provide additional access control advice, and for the recommended ACL check at the server to treat the list no longer as a set but rather in an order dependent manner, where some of this access control advice cuts off the search farther back in the stack. But perhaps the constraints are different leading to a different trajectory? I'm not sure. I'm hoping for people smarter than me to figure this one out :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: 'scroll' and 'resize' events
2009/6/17 Ian Hickson i...@hixie.ch Anne, As mentioned on IRC, it would be cool if the CSSOM spec could define when to fire 'scroll' and 'resize' events. If there's a particular place I should log this so that whoever takes over that spec doesn't lose this feedback, let me know. More in general, exactly where is the firing of common events such as click, mousedown and keyup defined? I can't find them in the HTML5 spec (or did I overlook them?), and the DOM3 Events spec is rather old and has little to do with reality. If they're currently undefined and you ask nicely, I might even create a first overview of their firing in current browsers; an overview that could lead to a proper specification. I've got most of the relevant data already in my head. -- --- ppk, freelance front-end consultant, agent, and trainer http://www.quirksmode.org/about/ --
Re: [cors] Review
On Wed, Jun 17, 2009 at 12:15 AM, Anne van Kesterenann...@opera.com wrote: On Wed, 17 Jun 2009 07:41:42 +0200, Tyler Close tyler.cl...@gmail.com wrote: One solution is: 1. Don't add any client credentials to requests. 2. Allow the script to use whatever HTTP method, headers and request entity it wants, restricting use of some headers, such as Referer. This leaves resources relying solely on a firewall for authentication vulnerable. It also leaves sites vulnerable that do IP-based authentication. I assume you're talking about sites on the public Internet that rely solely on the client IP address for authentication, since we've already covered the firewall case. I think it's worth studying that scenario in more detail, because the details may save them. Responses lacking a cross-domain enabled header are still dropped by the browser, meaning we're only worried about side-effects from a request to a well-known URL. Isn't it already possible to forge the IP address on a HTTP request to a web site, especially if you don't need to get the answer? It's also worth keeping in mind that both CORS and HTML also let a POST request through to the site, so the site already needs some other way of authenticating these non-safe requests. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [widgets] PC Last Call comments, zip-rel-path ABNF
On Thu, Jun 4, 2009 at 4:48 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Marcos, Great thanks for all the fixes! I have seen also the further changes in the draft. One more comment to this chunk: Authors need to keep path lengths below 250 bytes. Unicode code points can require more than one byte to encode a character, which can result in a path whose length is less than 250 characters. The second sentence is actually not needed in this form. I would drop it or change it as follows: Authors need to keep path lengths below 250 bytes. Unicode code points may require more than one byte to encode a character, which can result in a path whose length is less than 250 characters to be represented in more than 250 bytes. Right, I used this instead: Authoring guideline: Authors need to keep path lengths below 250 bytes. Unicode code points may require more than one byte to encode a character, which can result in a path whose length is less than 250 characters but whose size is greater than 250 bytes. -- Marcos Caceres http://datadriven.com.au
[PC] Definitions: installation, instantiation
Hi Marcos, As per my action point http://www.w3.org/2009/06/10-wam-minutes.html#action02 we discussed the definitions in BONDI. The output is as follows: It is within the scope of W3C to provide the definitions and BONDI will comply to them. By principle, BONDI will refer to the definitions provided in the PC spec. BONDI may add something to the W3C definitions, but this should not bother the definition that we work on in WebApps. My further comment is: Could we have the definitions published e.g. in the Editor's Draft before LC period ends, i.e. before Friday? I think this would help many people to have a look at the proposal. Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
RE: [widgets] PC Last Call comments, zip-rel-path ABNF
Hi Marcos, Thanks for the change. It's ok for me. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Wednesday, June 17, 2009 4:54 PM To: Marcin Hanclik Cc: public-webapps@w3.org Subject: Re: [widgets] PC Last Call comments, zip-rel-path ABNF On Thu, Jun 4, 2009 at 4:48 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Marcos, Great thanks for all the fixes! I have seen also the further changes in the draft. One more comment to this chunk: Authors need to keep path lengths below 250 bytes. Unicode code points can require more than one byte to encode a character, which can result in a path whose length is less than 250 characters. The second sentence is actually not needed in this form. I would drop it or change it as follows: Authors need to keep path lengths below 250 bytes. Unicode code points may require more than one byte to encode a character, which can result in a path whose length is less than 250 characters to be represented in more than 250 bytes. Right, I used this instead: Authoring guideline: Authors need to keep path lengths below 250 bytes. Unicode code points may require more than one byte to encode a character, which can result in a path whose length is less than 250 characters but whose size is greater than 250 bytes. -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [PC] Definitions: installation, instantiation
On Wed, Jun 17, 2009 at 5:03 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Marcos, As per my action point http://www.w3.org/2009/06/10-wam-minutes.html#action02 we discussed the definitions in BONDI. The output is as follows: It is within the scope of W3C to provide the definitions and BONDI will comply to them. By principle, BONDI will refer to the definitions provided in the PC spec. BONDI may add something to the W3C definitions, but this should not bother the definition that we work on in WebApps. My further comment is: Could we have the definitions published e.g. in the Editor’s Draft before LC period ends, i.e. before Friday? I think this would help many people to have a look at the proposal. The definitions are all in the document and explicitly marked as definitions (using the dfn tag). I'm going on vacation in 50 mins, so I don't have time to extract them. Maybe someone on the BONDI side can write some XSLT magic to extract them out? -- Marcos Caceres http://datadriven.com.au
RE: [PC] Definitions: installation, instantiation
Hi Marcos, The definitions are all in the document and explicitly marked as definitions (using the dfn tag). I cannot find e.g. instantiation under http://dev.w3.org/2006/waf/widgets/. Could you please provide a URL? BTW: have nice holidays! Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Wednesday, June 17, 2009 5:15 PM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [PC] Definitions: installation, instantiation On Wed, Jun 17, 2009 at 5:03 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Marcos, As per my action point http://www.w3.org/2009/06/10-wam-minutes.html#action02 we discussed the definitions in BONDI. The output is as follows: It is within the scope of W3C to provide the definitions and BONDI will comply to them. By principle, BONDI will refer to the definitions provided in the PC spec. BONDI may add something to the W3C definitions, but this should not bother the definition that we work on in WebApps. My further comment is: Could we have the definitions published e.g. in the Editor’s Draft before LC period ends, i.e. before Friday? I think this would help many people to have a look at the proposal. The definitions are all in the document and explicitly marked as definitions (using the dfn tag). I'm going on vacation in 50 mins, so I don't have time to extract them. Maybe someone on the BONDI side can write some XSLT magic to extract them out? -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: Comments on Widgets spec
On Mon, Jun 15, 2009 at 2:54 PM, Dominique Hazael-Massieuxd...@w3.org wrote: Hi, I have also noted that the two examples in 7.2 use a wrong namespace (w3.org instead of www.w3.org). Fixed. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Draft Minutes from 10 June 2009 f2f meeting
Hi Scott,
On Fri, Jun 12, 2009 at 1:54 PM, Scott
Wilsonscott.bradley.wil...@gmail.com wrote:
One scenario for hasFeature():
1. I install a Widget with:
feature name=http://my.feature.com/x; required=false/
2. In my Widget's JavaScript, I have something like:
if (hasFeature(http://my.feature.com/x;)){
doCoolThing(); // great, we have the X API! Lets use it
} else {
doLessCoolThing(); // ok do something that doesn't need the X API
}
How can this be realised if hasFeature() is removed? Or should this UC be
specifically out of scope for AE? For example, would I have to create two
different widgets, one with X and one without?
During the F2F, we dropped the feature because it was too problematic.
As Henri Sivonen pointed out, it is easy to say a feature is available
but not have it fully implemented. Other means of testing for the
availability of a feature will be required (like testing if an object
is available in JS, etc.). The WG will not be defining what those
methods are, however.
Without hasFeature(), what does PC feature ... required=false mean?
The definition given in the spec still holds. hasFeature() and the
semantics of the feature element and its attributes are orthogonal.
--
Marcos Caceres
http://datadriven.com.au
Re: [widgets] PC Last Call comments, 7
On Tue, Jun 9, 2009 at 10:41 AM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Step 7 ... 10. For each element in the elements list, if the element is one of the following: A description element: If this is not the first description element encountered, then the user agent must ignore the element and its child nodes. Stop processing this element ... My point is: This sentence: If this is not the first description element encountered, then the user agent must ignore the element and its child nodes. Is descriptive. Whereas this sentence: Stop processing this element ... is imperative following the mode from: For each element in the elements list, if the element is one of the following: A description element: So I would just align the text to be either descriptive or all imperative for consistency. If you can live with it, I think I will leave this as is. -- Marcos Caceres http://datadriven.com.au
RE: [widgets] PC Last Call comments, 7
Hi Marcos, I can live with it. We seems to feel the time pressure on our backs. Nobody's perfect :) Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Wednesday, June 17, 2009 6:03 PM To: Marcin Hanclik Cc: public-webapps Subject: Re: [widgets] PC Last Call comments, 7 On Tue, Jun 9, 2009 at 10:41 AM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Step 7 ... 10. For each element in the elements list, if the element is one of the following: A description element: If this is not the first description element encountered, then the user agent must ignore the element and its child nodes. Stop processing this element ... My point is: This sentence: If this is not the first description element encountered, then the user agent must ignore the element and its child nodes. Is descriptive. Whereas this sentence: Stop processing this element ... is imperative following the mode from: For each element in the elements list, if the element is one of the following: A description element: So I would just align the text to be either descriptive or all imperative for consistency. If you can live with it, I think I will leave this as is. -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Events Re: 'scroll' and 'resize' events
On Wed, 17 Jun 2009 15:41:09 +0200, Peter-Paul Koch pp.k...@gmail.com wrote: More in general, exactly where is the firing of common events such as click, mousedown and keyup defined? I can't find them in the HTML5 spec (or did I overlook them?), and the DOM3 Events spec is rather old and has little to do with reality. The DOM 3 Events spec is being revised now. Discussion takes place on the www-dom list... If they're currently undefined and you ask nicely, I might even create a first overview of their firing in current browsers; an overview that could lead to a proper specification. I've got most of the relevant data already in my head. Perhaps you would like to send that to www-...@w3.org as a change proposal to the DOM 3 Events spec... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [cors] Review
On Wed, Jun 17, 2009 at 10:11 AM, Anne van Kesterenann...@opera.com wrote: On Wed, 17 Jun 2009 16:35:13 +0200, Tyler Close tyler.cl...@gmail.com wrote: On Wed, Jun 17, 2009 at 12:15 AM, Anne van Kesterenann...@opera.com wrote: It also leaves sites vulnerable that do IP-based authentication. I assume you're talking about sites on the public Internet that rely solely on the client IP address for authentication, since we've already covered the firewall case. I'm not too convinced that hoping the IT department deploys the new software correctly is going to work, to be honest. And while some heuristics might certainly help, that is not a solid solution. I believe the described heuristics provide complete coverage for resources behind my company's firewall. Is there a common firewall configuration you are concerned about? The proposed solution uses both heuristics and configuration, not relying solely on either for protection. If this technique can in practice provide adequate protection, it is a much better solution than CORS, which undermines HTTP and webarch in a number of ways (all discussed previously and again raised by mnot). I think it's worth studying that scenario in more detail, because the details may save them. Responses lacking a cross-domain enabled header are still dropped by the browser, meaning we're only worried about side-effects from a request to a well-known URL. Yes, either with methods other than HEAD/GET/POST/OPTIONS or headers other than the default set. Isn't it already possible to forge the IP address on a HTTP request to a web site, especially if you don't need to get the answer? I don't know. http://en.wikipedia.org/wiki/IP_address_spoofing It's also worth keeping in mind that both CORS and HTML also let a POST request through to the site, so the site already needs some other way of authenticating these non-safe requests. That could be as simple as using an HTTP header form cannot generate. Also, they might be using different methods. In which case they are already vulnerable to IP address spoofing. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Dated URI for Widgets 1.0: URI Scheme seems to be broken
This is a comment on Widgets 1.0: URI Scheme. Link [1] appears to work, link [2] is 404. Thanks. Noah [1] http://dev.w3.org/2006/waf/widgets-uri/ [2] http://www.w3.org/TR/2009/WD-widgets-uri-20090618/ -- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --
Re: Dated URI for Widgets 1.0: URI Scheme seems to be broken
On Wed, 17 Jun 2009 19:48:34 +0200, noah_mendels...@us.ibm.com wrote: This is a comment on Widgets 1.0: URI Scheme. Link [] appears to work, link [] is 404. Thanks. It is not published yet. -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] Review
Re-sending from the right address. Adam 2009/6/17 Adam Barth a...@adambarth.com: 2009/6/17 Anne van Kesteren ann...@opera.com: On Wed, 17 Jun 2009 16:35:13 +0200, Tyler Close tyler.cl...@gmail.com wrote: Isn't it already possible to forge the IP address on a HTTP request to a web site, especially if you don't need to get the answer? I don't know. I'd classify this as moderately difficult. It's not something I can do for $5, but given a few hundred dollars, I can probably do it. Recall that sending an HTTP request requires a full TCP handshake, so its not as easy as SYN flooding. Adam
Re: Dated URI for Widgets 1.0: URI Scheme seems to be broken
On Jun 17, 2009, at 2:05 PM, ext Anne van Kesteren wrote: On Wed, 17 Jun 2009 19:48:34 +0200, noah_mendels...@us.ibm.com wrote: This is a comment on Widgets 1.0: URI Scheme. Link [] appears to work, link [] is 404. Thanks. It is not published yet. June 18 is the publication date. -Regards, Art Barstow
Re: 'scroll' and 'resize' events
Hi, PPK- Peter-Paul Koch wrote (on 6/17/09 9:41 AM): More in general, exactly where is the firing of common events such as click, mousedown and keyup defined? I can't find them in the HTML5 spec (or did I overlook them?), and the DOM3 Events spec is rather old and has little to do with reality. We are updating that spec to align better with reality right now. :) If they're currently undefined and you ask nicely, I might even create a first overview of their firing in current browsers; an overview that could lead to a proper specification. I've got most of the relevant data already in my head. Pretty please, with sugar on top? I'm working on it right now, but suggestions, contributions, or corrections are most welcome. Also, if you'd like to participate in the DOM3 Events teleconferences, you are welcome to do so: http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0124.html Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Interaction events (Was: 'scroll' and 'resize' events)
On Wed, 17 Jun 2009, Peter-Paul Koch wrote: More in general, exactly where is the firing of common events such as click, mousedown and keyup defined? I can't find them in the HTML5 spec (or did I overlook them?), and the DOM3 Events spec is rather old and has little to do with reality. It's currently undefined. I'm hoping that we will eventually have a User Interaction Events specification companion to DOM3 Events that defines this. If they're currently undefined and you ask nicely, I might even create a first overview of their firing in current browsers; an overview that could lead to a proper specification. I've got most of the relevant data already in my head. Please please please could you do that? That would be awesome. If there's anything I can do to help with this please let me know. If you search the HTML5 source for the term interaction event you'll find the various places in HTML5 where I've knowingly dependend upon this as yet non-existent spec, which might be useful (or might not). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [widgets] Public keys in widgets URI scheme?
On Wed, Jun 17, 2009 at 6:18 AM, Marcos Caceresmarc...@opera.com wrote: On Tue, Jun 16, 2009 at 7:24 PM, Aaron Boodmana...@google.com wrote: But the thing I was talking about that we have been very happy with was the idea of using a public key as the unique identifier for an extension. This has worked very well for us. Every extension has an RSA key pair and the public key is the extension's one true unique ID (but for convenience, we also use a hash of the public key as an ID in some places). Every deployed instance of the extension is signed with this key pair. Does that mean that Google must sign every package? Can unsigned package be deployed? One interesting outcome of this is that it is impossible to have ID collisions. In systems where a GUID must be chosen by a developer, developers sometimes accidentally or maliciously copy the ID of another extension. This is not possible if the unique ID is the public key because the developer would have to know the private key, too, since every extension must be signed by the private key. Is that the developer's private key, or the vendor's (Google's) key? Neither. Each extension has its own distinct key pair which stay constant across versions. That is to say, extension are self-signed. The key pair can be generated using standard tools (the openssl command line tool), or the Chromium/Google Chrome binary. This scheme allows us to autoupdate extensions over normal HTTP without SSL because the signature proves that whoever created the first version of an extension created all subsequent versions. As for reusing the actual widgets spec, I think that there are some important differences. Chrome extensions are intended to extend the actual Chrome UI, not stand alone. I see, but you conceptually package things in the same way as widgets. I'm interested to see that you guys opted to put the signature and the manifest as the first bits of data of a package. Does that mean that chrome extensions cannot be read/opened by standard zip tools (I just tried this on my Mac, and seems to be the case)? If so, I guess that also means special/proprietary tools are needed to create chrome conforming packages for distribution. The zip format actually allows arbitrary data at the beginning of the package, but many tools (importantly the built-in ones in Windows and OS X) appear to not support this. This seemed like an OK trade-off to us. As a last resort, the Chromium/Google Chrome binary itself can be used to unpack the files (by registering itself with the OS for the .crx extension). Aside from optimization reasons, was there any other reason why Chrome went down this route? We want to be able to do content-sniffing to determine if a package is an extension, and not rely on a content-type alone (it is difficult for many developers to set content types on their servers). This implies that extensions have a known header that can be scanned for. - a
Re: Dated URI for Widgets 1.0: URI Scheme seems to be broken
OK, thanks. Someone sent the link, and the status of document section didn't say unpublished. Thinking about the date, I now realize that I'm probably in the window just before publication where the text looks like it's published but all the copies aren't in the right place. I should have noticed that 18 June date. Sorry for the confusion. Noah -- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -- Anne van Kesteren ann...@opera.com 06/17/2009 02:05 PM To: noah_mendels...@us.ibm.com, public-webapps@w3.org cc: Subject:Re: Dated URI for Widgets 1.0: URI Scheme seems to be broken On Wed, 17 Jun 2009 19:48:34 +0200, noah_mendels...@us.ibm.com wrote: This is a comment on Widgets 1.0: URI Scheme. Link [] appears to work, link [] is 404. Thanks. It is not published yet. -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, 17 Jun 2009, Mark S. Miller wrote: If it does transmit any of these currently, are there any objections to revising the spec so that it doesn't? Not necessarily. I'd like to know what Ian thinks about this. Wonderful! Ian? Sorry, I haven't been following this thread. Could you elaborate on what the question is exactly? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [cors] Review
On Wed, Jun 17, 2009 at 1:01 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 17 Jun 2009 19:45:54 +0200, Tyler Close tyler.cl...@gmail.com wrote: If this technique can in practice provide adequate protection, it is a much better solution than CORS, which undermines HTTP and webarch in a number of ways (all discussed previously and again raised by mnot). I do not think CORS undermines HTTP or webarch. Let me see if I understand mnot's criticism. The current CORS proposal requires a preflight per URL, and that therefore can only be cached per URL. HTTP / REST / webarch are premised on distinct resources being named by distinct URLs. A RESTful server serving a large number of linked small resources may therefore serve a large number of URLs, each of which may only be fetched once in typical use. A browser-based app, navigating among these resources by following their links to each other is limited (ignoring fancy protocols that go beyond HTTP recommendations) to one level of traversal per round trip. The contrasting style represented by SOAP uses a URL to designate a large aggregate of resources, and uses other information in the payload to determine which of these resources is being addressed. This is considered to be counter to HTTP / REST / webarch recommendations. Under CORS, a browser-based app navigating a cross-origin RESTful service will typically be limited to one level of traversal per sequential pair of rond trips. In the peformance approximation of latency is everything, this doubles the cost of following HTTP / REST / webarch recommendations. Under CORS, a SOAP-like service would pay no such penalty, since the preflight cache would almost always hit. These comparative costs would create an irresistable incentive to violate HTTP / REST / webarch recommentations. Mnot, do I have this right? -- Cheers, --MarkM
Re: [cors] Review
The description below is mostly correct, but the issue is with updates, not fetches. A GET does not require a pre-flight under CORS, but a PUT does and a POST probably does. So for example, cross-domain use of a CouchDB database will result in doubled latency and network requests in all data update scenarios. HTTP Document API - Couchdb Wiki http://wiki.apache.org/couchdb/HTTP_Document_API Also note the probably for POST requests. CORS encourages web-apps to label all POST entities as text/plain. Mnot also raised additional issues in his most recent CORS review. --Tyler On Wed, Jun 17, 2009 at 1:29 PM, Mark S. Millererig...@google.com wrote: On Wed, Jun 17, 2009 at 1:01 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 17 Jun 2009 19:45:54 +0200, Tyler Close tyler.cl...@gmail.com wrote: If this technique can in practice provide adequate protection, it is a much better solution than CORS, which undermines HTTP and webarch in a number of ways (all discussed previously and again raised by mnot). I do not think CORS undermines HTTP or webarch. Let me see if I understand mnot's criticism. The current CORS proposal requires a preflight per URL, and that therefore can only be cached per URL. HTTP / REST / webarch are premised on distinct resources being named by distinct URLs. A RESTful server serving a large number of linked small resources may therefore serve a large number of URLs, each of which may only be fetched once in typical use. A browser-based app, navigating among these resources by following their links to each other is limited (ignoring fancy protocols that go beyond HTTP recommendations) to one level of traversal per round trip. The contrasting style represented by SOAP uses a URL to designate a large aggregate of resources, and uses other information in the payload to determine which of these resources is being addressed. This is considered to be counter to HTTP / REST / webarch recommendations. Under CORS, a browser-based app navigating a cross-origin RESTful service will typically be limited to one level of traversal per sequential pair of rond trips. In the peformance approximation of latency is everything, this doubles the cost of following HTTP / REST / webarch recommendations. Under CORS, a SOAP-like service would pay no such penalty, since the preflight cache would almost always hit. These comparative costs would create an irresistable incentive to violate HTTP / REST / webarch recommentations. Mnot, do I have this right? -- Cheers, --MarkM -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: XHR and sandboxed iframes
On Wed, 17 Jun 2009 22:43:07 +0200, Mark S. Miller erig...@google.com wrote: Doh! Momentary confusion on my part. Thanks for catching this. FWIW, by default cross-origin XMLHttpRequest will not include cookies or HTTP authentication data. The withCredentials flag would have to be set for this and the requested resource would have to specify the Access-Control-Allow-Credentials header in the response in addition to the Access-Control-Allow-Origin header. -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, 17 Jun 2009, Mark S. Miller wrote: Does an xhr from a sandboxed unique origin iframe carry any credentials in the sense in which we've been using in this thread: * HTTP auth info * cookies (I think the text implied not, but I'd like to check.) * client-side certs Same-origin XHR will just fail with a sandboxed unique origin iframe. If you mean cross-origin XHR2, then it will work the same as for any other cross-origin situation, which I believe means it depends on the credentials flag, but I can't see where that is initialised so I don't know what the default is. * REFERRER Changing the origin doesn't affect the referrer (that is, it doesn't affect the document's current address of any document), so assuming that XHR2 uses the 'fetch' definition from HTML5 or has equivalent text that invokes the document's current address to set Referer (sic), the referrer will be included. * identified Origin (clearly not if I understand the spec) Right, this will be serialised as null. If it does transmit any of these currently, are there any objections to revising the spec so that it doesn't? Why? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [cors] Review
On Wed, 17 Jun 2009, Tyler Close wrote: For those at work, watching the show, here's the beast we're looking for: 1. A firewalled intranet, where servers behind the firewall have routable IP addresses (ie: not 10.*, or 192.168.*) 2. *and* where servers on the Internet are *not* accessed via an HTTP proxy 3. *and* there is a resource on a server behind the firewall that depends solely on connectivity for authentication (if you can get packets to me you're allowed to use me) 4. *and* where this resource does *not* treat GET and POST as equivalent methods 5. *and* where this resource checks that the Content-Type header on a POST request is either application/x-www-form-urlencoded or text/plain If you find a resource that meets the above criteria, then you've got a resource that may be secure under CORS, but not under my alternate proposal. Do we have any winners? I believe we have such services at Google, though for obvious reasons I wouldn't want to elaborate on that. Is this the propoal to which you refer?: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1011.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [cors] Review
On Wed, Jun 17, 2009 at 3:42 PM, Ian Hicksoni...@hixie.ch wrote: On Wed, 17 Jun 2009, Tyler Close wrote: For those at work, watching the show, here's the beast we're looking for: 1. A firewalled intranet, where servers behind the firewall have routable IP addresses (ie: not 10.*, or 192.168.*) 2. *and* where servers on the Internet are *not* accessed via an HTTP proxy 3. *and* there is a resource on a server behind the firewall that depends solely on connectivity for authentication (if you can get packets to me you're allowed to use me) 4. *and* where this resource does *not* treat GET and POST as equivalent methods 5. *and* where this resource checks that the Content-Type header on a POST request is either application/x-www-form-urlencoded or text/plain If you find a resource that meets the above criteria, then you've got a resource that may be secure under CORS, but not under my alternate proposal. Do we have any winners? I believe we have such services at Google, though for obvious reasons I wouldn't want to elaborate on that. Wow, if you could just confirm their existence, that would do fine. So this resource acts on PUT or DELETE, or POST of a Content-Type other than application/x-www-form-urlencoded or text/plain? And it checks the Content-Type header? And it doesn't require any user credentials at all? Connectivity is good enough. Is there any way a browser could tell a request is being sent to a server behind your firewall, and not a server on the open Internet? Is this the propoal to which you refer?: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1011.html Yes. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [cors] Review
On Wed, 17 Jun 2009, Tyler Close wrote: I believe we have such services at Google, though for obvious reasons I wouldn't want to elaborate on that. Wow, if you could just confirm their existence, that would do fine. So this resource acts on PUT or DELETE, or POST of a Content-Type other than application/x-www-form-urlencoded or text/plain? And it checks the Content-Type header? And it doesn't require any user credentials at all? Connectivity is good enough. What you describe here seems to differ from what you described previously. I don't feel comfortable talking about our internal services, though, so I'd rather not elaborate. Is there any way a browser could tell a request is being sent to a server behind your firewall, and not a server on the open Internet? No. Is this the propoal to which you refer?: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1011.html Yes. This seems to fail for cases that aren't even Intranet cases. Consider for instance a publicly accessible SOAP service that does authentication on an IP address basis only, and relies on checking the Content-Type header to make sure forms can't submit to it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, Jun 17, 2009 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 17 Jun 2009, Mark S. Miller wrote: If it does transmit any of these currently, are there any objections to revising the spec so that it doesn't? Why? So that the containing page can use such a credential removing service to allow sanitized content within the page to make requests -- either to its own or to other origins -- while preventing this content from speaking for the containing page or the user. The contained page already can't speak on behalf of the containing page -- that's what removing the Origin (and setting Origin to 'null') prevents. or the user. So what about * HTTP auth info * cookies * client-side certs * REFERRER ? -- Cheers, --MarkM
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, 17 Jun 2009, Mark S. Miller wrote: On Wed, Jun 17, 2009 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 17 Jun 2009, Mark S. Miller wrote: If it does transmit any of these currently, are there any objections to revising the spec so that it doesn't? Why? So that the containing page can use such a credential removing service to allow sanitized content within the page to make requests -- either to its own or to other origins -- while preventing this content from speaking for the containing page or the user. The contained page already can't speak on behalf of the containing page -- that's what removing the Origin (and setting Origin to 'null') prevents. or the user. But... we want the page talking on behalf of the user. That's the point of a browser. I don't really understand what we're trying to prevent here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [cors] Review
On Wed, Jun 17, 2009 at 4:31 PM, Tyler Closetyler.cl...@gmail.com wrote: 2009/6/17 Adam Barth a...@adambarth.com: I'd classify this as moderately difficult. It's not something I can do for $5, but given a few hundred dollars, I can probably do it. Recall that sending an HTTP request requires a full TCP handshake, so its not as easy as SYN flooding. Adam And also: http://en.wikipedia.org/wiki/IP_address_spoofing Wikipedia seems disagree with your point that IP-based authenication is inherently broken. From that page: IP spoofing can also be a method of attack used by network intruders to defeat network security measures, such as authentication based on IP addresses. This method of attack on a remote system can be extremely difficult, as it involves modifying thousands of packets at a time. I'm not sure extremely difficult is the characterization I'd use, but the reality is that some number of services use IP-based authenication. In some cases, it's a bad idea. In other cases, like the ACM digital library, it works quite well. Adam
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, Jun 17, 2009 at 4:46 PM, Ian Hickson i...@hixie.ch wrote: But... we want the page talking on behalf of the user. That's the point of a browser. Not in this way. At least not according to Roy Fielding (Mr. REST) http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html. I don't really understand what we're trying to prevent here. Confused deputies such as XSRF problems. Original paper is at http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html. It's well worth rereading. Much deeper than it at first appears. Perhaps my own srl.cs.jhu.edu/pubs/SRL2003-02.pdf may help. The threads and links already cited should make the connection with browser security clear. I'm not really sure what more to explain. Perhaps you could ask a more specific question? -- Cheers, --MarkM
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, Jun 17, 2009 at 5:02 PM, Mark S. Millererig...@google.com wrote: On Wed, Jun 17, 2009 at 4:46 PM, Ian Hickson i...@hixie.ch wrote: But... we want the page talking on behalf of the user. That's the point of a browser. Not in this way. At least not according to Roy Fielding (Mr. REST) http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html. That email also claims that CSRF is not a security issue for the Web, so I guess we need not worry about these issues. :) Adam
Re: [cors] Review
On Wed, Jun 17, 2009 at 4:45 PM, Ian Hicksoni...@hixie.ch wrote: On Wed, 17 Jun 2009, Tyler Close wrote: What you describe here seems to differ from what you described previously. I don't feel comfortable talking about our internal services, though, so I'd rather not elaborate. We're just doing an existence test here. We don't need to know any particulars. It'd be a shame to undermine webarch in an attempt to preserve security that doesn't actually exist. We should make sure CORS is not being unduly conservative. When we're talking about security, I don't think being unduly conservative is a bad thing at all. So turn off your computer then. ;) unduly is always undue. It sounds like you might be changing your answer to: No, we don't have such resources. Are you? You asked two questions. I'm pretty sure we have services that match your original description. I haven't checked if we have specific services that match the second description, though it wouldn't surprise me. I don't want to elaborate. Huh. So, how should we proceed? Should we drop this proposal on the hypothesis that there might exist resources that require the more conservative approach taken by CORS? Regardless of the costs this imposes? Is there any way a browser could tell a request is being sent to a server behind your firewall, and not a server on the open Internet? No. Does Google IT centrally configure any of your browser settings, so that it could add this information to the browser? I've never worked for a company that didn't give me root on my network-attached machines and let me configure them however I wanted. That's fine, but presumably these companies also provide some setup assistance to you. Does Google IT have any way to put configuration settings in your browser? For example, do you install packages from a Google provided repository? I've heard Google uses something called Goobuntu, or some such. Do you install your own machines, or does Google do that for you? This seems to fail for cases that aren't even Intranet cases. Consider for instance a publicly accessible SOAP service that does authentication on an IP address basis only, and relies on checking the Content-Type header to make sure forms can't submit to it. This service is already vulnerable to IP address spoofing. Unless there is some new attack I'm not familiar with, TCP (and thus HTPT) is not practically vulnerable to IP spoofing. 2009/6/17 Adam Barth a...@adambarth.com: 2009/6/17 Anne van Kesteren ann...@opera.com: On Wed, 17 Jun 2009 16:35:13 +0200, Tyler Close tyler.cl...@gmail.com wrote: Isn't it already possible to forge the IP address on a HTTP request to a web site, especially if you don't need to get the answer? I don't know. I'd classify this as moderately difficult. It's not something I can do for $5, but given a few hundred dollars, I can probably do it. Recall that sending an HTTP request requires a full TCP handshake, so its not as easy as SYN flooding. That's news to me. As far as I can tell short of a man-in-the-middle attack it would take a phenomenal combination of a brute-force attack on the sequence numbers and a simultaneous DOS of the spoofee's network connection. In practice these systems exist, and IP spoofing HTTP traffic is, as Adam put it, at least moderately difficult. What you describe would change it from moderately difficult to trivial. Adam quantified moderately difficult at a few hundred dollars. That's pretty cheap. I think we should also look for more details here. These systems that are using the client IP address for authentication, is the client computer an end user computer with a browser installed on it? And also: http://en.wikipedia.org/wiki/IP_address_spoofing That page explicitly lists TCP as a protocol that isn't vulnerable. with caveats that seem important: Since the attacker normally can't see any reply packets, he has to guess the sequence number in order to hijack the connection. The poor implementation in many older operating systems and network devices, however, means that TCP sequence numbers can be predicted. Let's not brush aside details that could be important to solving this problem. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [cors] Review
On Wed, Jun 17, 2009 at 4:45 PM, Ian Hicksoni...@hixie.ch wrote: That's news to me. As far as I can tell short of a man-in-the-middle attack it would take a phenomenal combination of a brute-force attack on the sequence numbers and a simultaneous DOS of the spoofee's network connection. In practice these systems exist, and IP spoofing HTTP traffic is, as Adam put it, at least moderately difficult. What you describe would change it from moderately difficult to trivial. I don't know of any IP spoofing attacks that aren't public. I wouldn't trust the confientiality of my email to IP-based authentication, but I would trust the confientiality of my grocery list to it. Adam
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, Jun 17, 2009 at 5:09 PM, Adam Barth w...@adambarth.com wrote: On Wed, Jun 17, 2009 at 5:02 PM, Mark S. Millererig...@google.com wrote: On Wed, Jun 17, 2009 at 4:46 PM, Ian Hickson i...@hixie.ch wrote: But... we want the page talking on behalf of the user. That's the point of a browser. Not in this way. At least not according to Roy Fielding (Mr. REST) http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html. That email also claims that CSRF is not a security issue for the Web, so I guess we need not worry about these issues. :) C'mon Adam, I was citing that regarding what the point of a browser is. That same paragraph goes on to say If browsers create a security issue because they allow scripts to automatically direct requests with stored security credentials onto third-party sites, without any user intervention/configuration, then the obvious fix is within the browser. As he says, browsers created this security issue by cross-origin presentation of ambient credentials. Had they not, then CSRF would not have been a security issue for the web. I don't agree that we can fix browsers as he proposes. As we all know, the weight of legacy mistakes is too great. However, so long as we are in the midst of proposing new mechanisms, we should endeavor to free these new mechanisms from repeating these old mistakes. -- Cheers, --MarkM
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, Jun 17, 2009 at 5:16 PM, Mark S. Millererig...@google.com wrote: On Wed, Jun 17, 2009 at 5:09 PM, Adam Barth w...@adambarth.com wrote: On Wed, Jun 17, 2009 at 5:02 PM, Mark S. Millererig...@google.com wrote: Not in this way. At least not according to Roy Fielding (Mr. REST) http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html. That email also claims that CSRF is not a security issue for the Web, so I guess we need not worry about these issues. :) C'mon Adam, I was citing that regarding what the point of a browser is. I know, but you do appreciate the irony in citing that email in a discussion of how to mitigate CSRF. Adam
Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, Jun 17, 2009 at 5:32 PM, Adam Barth w...@adambarth.com wrote: I know, but you do appreciate the irony in citing that email in a discussion of how to mitigate CSRF. ;)
