Re: [widgets] Minutes from 30 October 2008 Voice Conference
Hi Larry, On Sun, Nov 23, 2008 at 4:54 AM, Larry Masinter [EMAIL PROTECTED] wrote: Resolving the general topic of ZIP-based packages and URI references within them on the webapp mailing list doesn't seem practical, because those who need to review the package/URI issue are likely not interested in wading through the mass of other email on other unrelated topics within WebAPP WG. Valid point. I don't understand why setting up a separate mail list/archive/issue list on the specific topic is a lengthy process, it mainly requires the will to take the need for coherence seriously. Sorry, my understanding was that your wanted to set up a separate working group, which in my experience seems to take around 6 months. Setting a up a separate mailing list seems like a great idea. Who do we need to talk to to make this happen? Under which charter would this work be done? If resolving this in a timely fashion is important to you (as you seem to indicate by invoking time scope) then perhaps you might want to respond more quickly. I'm sorry. I only got back three days ago from vacation from somewhere far away from any internet connection. I'll try to be more prompt with my responses in the future. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Comments on Widgets 1.0: Requirements LCWD
Hi Krzysztof, 2008/11/3 Krzysztof Maczyński [EMAIL PROTECTED]: Marcos, Sorry for the delay in replying. When you wrote to me on 14 October, I was in the Near East with very occasional Internet access. I'll understand if at this moment it's to late to give my input the full weight in your process it could have had if sent earlier. Anyway, here it goes: No pros. Apologies on my part too, I've also been away on vacation for the last 3 week. Ok, I think we have been misunderstanding each other. I agree 100% with what you are saying, so I am relaxing this to a MAY. However, please understand that they reason we want file extensions is because widget are shared over communication channels other than HTTP. It's like the situation when a Mac user sends Windows users a file without a file extension... it can lead t o a lot of frustration, which want to avoid (more below). Yes, I understand this issue and I believe I have already treated it previously. But I'll try to restate my thoughts with a concrete example. The resource, when stored as a file on a file system supporting extensions as the way of indicating content types (or in some other context where using extensions in this way is the standard practice), should indeed be named with an appropriate extension. But that is a consideration principally outside the Web. I wrote that it needn't be mentioned, but if mentioning is deemed desirable, no normative specification language should apply (ideally no MUST, SHOULD, MAY or their RFC 2119 relatives). For example, assume you have a Linux system with a file ~/public_html/MyWidget.widget and you decide to publish it on the Web with HTTP. Then the default thing to do for your Web server may be to create a resource under the URI http://MyDomain.example.org/MyWidget whose representation will be the content of this file and which will be served with an appropriate Content-Type header. Conversely, if a Windows user downloads this resource and saves it on his file system, the user agent performing this (e.g. a download manager which follows Web usage of MIME and can access a mapping from MIME types to extensions registered in Windows (maintained by itself, by the default Web browser, by the browser for which the download manager is a plugin, or wherever else)) may add an appropriate extension automatically or include it as the default if the user is prompted for the file name. Your last sentence captures the intention of the usage of the file extension precisely. However, it is not a guarantee that a user agent will know what extension to apply based on the MIME type. To this effect, the spec will still recommended that the extension be .wgt (if only to guide authors for these exceptional circumstances - and completely unrelated to the world of HTTP). We by no means want to violate the TAG findings or to mandate that the file extension always be present, but we need to do our best to ensure interop once widgets leave the Web. I don't know of any other way of reducing the file extension interop problem in the spec, but to recommend the file extension and the appropriate content-type sniffing behaviors for UAs. The requirement is now simply: A conforming specification MUST specify a file name extension that authors MAY assign to widget resources in contexts that rely on file extensions, such as many popular file systems. So, it is now silent on any HTTP related matter. In the rationale, I used some of your text (last sentence): When a MIME Type is not present, as is the case when a widget is instantiated locally from an end-user's storage device, the operating system will sometimes use the file extension to associate the widget resource with the appropriate widget user agent. However, when the widget is distributed over HTTP and a MIME type is present, a file extension is not required. However, it should be noted that in some cases a Web server may rely on a file extension to correctly set a widget resource's MIME type in the HTTP headers. In addition, when saving a widget to a storage device, a user agent that is aware of the content type of widgets could add the appropriate file extension automatically or include it as the default if the user is prompted for the file name. no schema langauge exists that can capture the intricacies required to fully validate the configuration document correctly. I think you may mean assert conformance of instead of validate. Then this is a common situation with other specifications as well (yours for the configuration document seems to be going to be relatively simple, so maybe what you've written will turn out not to be even the case), especially those which have much to do with users. (There has been much effort to significantly reduce this phenomenon in WCAG 2.0, but it would be futile to try to eliminate it.) Agreed. However, the entire idea behind this paragraph seems surprising, to say the
Re: [XHR] security issue with spec's same-origin and the Document pointer
On Fri, 21 Nov 2008 21:14:59 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: var xhrConstructor = iframe.contentWindow.XMLHttpRequest; iframe.src='http://attackee.example.com/'; . . var xhr = new xhrConstructor(); When the constructor is invoked here, the associated document of its associated window object is not safe to do same-origin comparisons against. I've tested this in the main 4 engines, and they all protect against this exploit but as far as I can see someone implementing the spec as it's written would end up vulnerable. Why would the SECURITY_ERR exception not be thrown during the open() method invocation as the specification requires? Because when you call new xhrConstructor() the document pointer is initialized *but at that point the document of the associated window originates from attackee.example.com*. If the script goes on to request content from this domain, the same-origin comparison against the document pointer would pass when it should in fact fail because the script itself is from a different origin. -- Hallvord R. M. Steen Core JavaScript tester, Opera Software http://www.opera.com/ Opera - simply the best Internet experience
Re: [XHR] security issue with spec's same-origin and the Document pointer
On Sun, 23 Nov 2008 18:13:41 +0100, Hallvord R. M. Steen [EMAIL PROTECTED] wrote: On Fri, 21 Nov 2008 21:14:59 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: var xhrConstructor = iframe.contentWindow.XMLHttpRequest; iframe.src='http://attackee.example.com/'; . . var xhr = new xhrConstructor(); When the constructor is invoked here, the associated document of its associated window object is not safe to do same-origin comparisons against. I've tested this in the main 4 engines, and they all protect against this exploit but as far as I can see someone implementing the spec as it's written would end up vulnerable. Why would the SECURITY_ERR exception not be thrown during the open() method invocation as the specification requires? Because when you call new xhrConstructor() the document pointer is initialized *but at that point the document of the associated window originates from attackee.example.com*. If the script goes on to request content from this domain, the same-origin comparison against the document pointer would pass when it should in fact fail because the script itself is from a different origin. Once you navigate the original Document is either destroyed or stays around. However, it does not suddenly change into the Document of another domain. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Comments on some Web IDL extended attribute names
Maciej Stachowiak:
I think [NativeObject] should be renamed to [Callback]. It is meant to
be used for callback objects that have a single designated callback
method, right?
Cameron McCormack:
Not only a single callback method, perhaps multiple. But yes, it’s
pretty much for callbacks. [Callback] looks nicer than [NativeObject],
so I think that’s a reasonable change.
I’ve now renamed [NativeObject] to [Callback].
I see, I misunderstood what [Variadic] does. I think [Optional] would be
a useful addition for functions that have a fixed number of optional
arguments. Unless Web IDL has some way to represent that which I missed.
…
[Optional] could be defined such that:
interface A {
void f(in long w, [Optional] in long x, in long y, [Optional] int long z);
};
is equivalent to:
interface A {
void f(in long w);
void f(in long w, in long x, in long y);
void f(in long w, in long x, in long y, in long z);
};
I’ve added [Optional] to do exactly the above.
Thanks,
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [selectors-api] Investigating NSResolver Alternatives
This is moot now that NSResolver is gone from selector-api, but… Boris Zbarsky: The way I see it, all current impls should throw something if more than one arg is passed Lachlan Hunt: Which exception should be thrown? Is this something I should define in this spec, or is it something for WebIDL or some other spec to deal with? Boris Zbarsky: Honestly, I don't care much on that point. Anne van Kesteren: FWIW, I consider it to be a Web IDL issue as it affects every interface. (HTML5 currently has explicit text for this (to have additional arguments be ignored) but expects it to move into Web IDL.) The rewritten Operations section of the ECMAScript binding now ignores additional arguments: http://dev.w3.org/2006/webapi/WebIDL/#es-operations Passing fewer arguments than required results in a TypeError. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [Bindings] extended attribute for callback function interfaces?
Cameron McCormack wrote: Hi David. Cameron McCormack: [re allowing a Function to implement a callback interface] I believe this is already handled for all such interfaces, in the last paragraph of section 4.4: L. David Baron: I'm not sure if you want it to be handled for all such interfaces. You often want this behavior for interfaces that you expect will always have a single method, but you may not if they currently have one method but you expect more methods to be added via derived interfaces (either now or potentially later). You can now specify [Callback], to allow either a function or a property on a native object to be the implementation, [Callback=FunctionOnly] to require it to be the function that is the implementation, and [Callback=PropertyOnly] to require the property on the object to be the implementation. http://dev.w3.org/2006/webapi/WebIDL/#Callback Why do we need the FunctionOnly/PropertyOnly feature? In gecko we don't have that functionality and it hasn't caused any problems that I can think of. What could make sense to do is to say that if the [Callback] interface has any attributes or more than one function you can't pass a function. But why would we ever want an interface that only had one function that we didn't want to be implementable as a function. / Jonas
Re: [Bindings] extended attribute for callback function interfaces?
Jonas Sicking: Why do we need the FunctionOnly/PropertyOnly feature? In gecko we don't have that functionality and it hasn't caused any problems that I can think of. I took David’s feedback to mean that sometimes you want to state that a single-function interface can’t be implemented by a function (and added PropertyOnly for that). What could make sense to do is to say that if the [Callback] interface has any attributes or more than one function you can't pass a function. Attributes can’t be specified at all on callback interfaces to be implemented by a native object. But why would we ever want an interface that only had one function that we didn't want to be implementable as a function. Yes I think that is sensible, and I’d rather have it uniform like this. If nobody can point to any interfaces that should have non-uniform behaviour, I’ll happily take the arguments out. -- Cameron McCormack ≝ http://mcc.id.au/
