Re: Comprehensive List of Implementations for Testing
Any chance this list is made available with links to the feature implementations. Most of the players I know of have such a page at least for SVG and the burry of SVG viewer will create holes, I believe. paul Antoine Quint wrote: Hey Doug, A couple of precisions On 21 sept. 2006, at 14:37, Doug Schepers wrote: SVG JavaScript Desktop Batik 1.5+ Firefox 1.0+ Opera 9.0+ Safari 10.4+ No released version of Safari have so far shipped with native SVG support. However, WebKit nightlies can be used. Adobe SVG Viewer 3.x (optional, unsupported) not yet unsupported :) Corel SVG Viewer (v?, optional, unsupported) Amaya 9.5+ Mobile Opera 8.5+, 9.0+ BitFlash (v?) Ikivo (v?) ACCESS NetFront should also be listed there. Also, to the best of my knowledge, no shipping version of the Opera browser so far has provided native support for SVG. Antoine --Blog — http://the.fuchsia-design.com smime.p7s Description: S/MIME Cryptographic Signature
Re: Comments on File Upload
Hi Mark, thanks a lot for your review. On Sep 21, 2006, at 15:18, Mark Baker wrote: Editorial; - sec 1, This interface should be This specification - sec 3, I'd suggest s/apparition/display/ Applied. Substantive; - sec 3, regarding On devices that have no file system, the user-agent MAY still open a dialogue for data acquisition, for instance an interface to a built-in camera, my concern is that the file dialogue should be considered generic, not specific to any form of data, so I don't want to give the impression that the device can choose the data without user involvement. So I'd suggest for instance, a dialog which identifies a built-in camera and a microphone. Agreed, I've made a change similar to your suggestion. - sec 4, not that I care that much, but do we really need this interface? Would an array not suffice? It can't do remove, of course, but is that such a big deal? I'm not at all a big fan of all the FooList interfaces that show up here and there in W3C APIs, but I'm unsure as to how to handle this in a language-independent manner. What it maps to is binding-specific mind you, so in ES it would certainly have the behaviour of an array. I think that once we make progress on the Bindings for ES specification (Jonas?) we'll see more clearly on this issue. - sec 4, I don't think SHOULD is appropriate there, for selecting multiple files - MAY should be fine. Plus I think it's best specified in sec 3. I've moved it to section 3 as I agree that it does make more sense there. However I do think that the SHOULD is justified here. If the platform on which the UA is running has a way of selecting multiple files, then it definitely must do it — the single file selection of UAs since the introduction of input type=file has been a genuine pain. The only reason it is a SHOULD and not a MUST is due to hypothetical platforms that may not have a FS (as mentioned two points above). I have half a mind to forget about that and make it a MUST. What do you think? - sec 5, filesize - do we know the use cases for this? Yes, a non-negligible number of sites request that users not upload files bigger than X. This does not provide for server security, but it gives the page a chance to tell the user that a file is too big before it is submitted. I don't think the definition provided would be useful for much beyond scenarious using some files in a file system. Well, that is the primary use case :) What if a camera had an 8MB buffer, but image sizes could be up to that size? Or similarly, what about an audio stream? And is this meant to be a string? No, it's definitely not meant to be a string, good catch. - sec 5, mediatype - do both and null values indicate that the agent doesn't know the media type? And are we expecting this to be just be the foo/bar value, or would parameters also be included? Need some references too. Good questions, I've added an editorial note to that effect. Thanks! -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: ISSUE-86: Throw INVALID_STATE_ERR everywhere, don\'t or some mix?
On Wed, 20 Sep 2006 13:43:34 -, Web APIs Issue Tracker [EMAIL PROTECTED] wrote: My proposal is to throw an exception (INVALID_STATE_ERR) for every member where this is relevant (as has been suggested before on this list). I have implemented this proposal in the editor's draft based on group discussion. Pending feedback it will probably be in the next WD. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Adobe Flash Cross-Domain Access
Hi, folks- I'm following up on the action to research how Adobe Flash handles cross-domain access. This is done by the use of an XML file on the target server, crossdomain.xml. The security model is described in a PDF whitepaper [1]: The Cross Domain Policy File mechanism is a simple XML file (crossdomain.xml) that does the following: * Modifies the read permission for data between sandboxes and across the network. It does not apply to cross-scripting of SWF files. * Is specified with a text file (served as a policy file from the site to be accessed as an ordinary web page), and is consulted by Flash Player, which then enforces the rules, rather than requiring (or allowing) a SWF file to declare or interpret the permissions. * Applies only to the protocol and port of the server, rather than opening up an entire domain, with one exception: HTTP servers can provide the policy files that govern XML socket connections. The Cross Domain Policy File is located in the root directory of the target server by default (for example, at www.applicablesite.com/crossdomain.xml), or Flash application developers can specify another location by calling the ActionScript System.security.loadPolicyFile() API. The DTD is available on the macromedia site [2], and is quite short: cross-domain-policy.dtd === ?xml version=1.0 encoding=ISO-8859-1? !-- Macromedia DTD for cross-domain policy files -- !ELEMENT cross-domain-policy (allow-access-from*) !ELEMENT allow-access-from EMPTY !ATTLIST allow-access-from domain CDATA #REQUIRED !ATTLIST allow-access-from secure (true|false) true !-- End of file. -- === A simple example might look like this: ?xml version=1.0? !DOCTYPE cross-domain-policy SYSTEM http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd; cross-domain-policy allow-access-from domain=* / /cross-domain-policy Amazon's policy [3] is a little more verbose: cross-domain-policy allow-access-from domain=*.amazon.com/ allow-access-from domain=amazon.com/ allow-access-from domain=www.amazon.com/ allow-access-from domain=pre-prod.amazon.com/ allow-access-from domain=devo.amazon.com/ allow-access-from domain=images.amazon.com/ allow-access-from domain=anon.amazon.speedera.net/ allow-access-from domain=*.amazon.ca/ allow-access-from domain=*.amazon.de/ allow-access-from domain=*.amazon.fr/ allow-access-from domain=*.amazon.jp/ allow-access-from domain=*.amazon.co.jp/ allow-access-from domain=*.amazon.uk/ allow-access-from domain=*.amazon.co.uk/ /cross-domain-policy So, it seems that it's a simple accept-list on the target server. Is the current Access Control notably different or more secure? [1] http://www.adobe.com/devnet/flashplayer/articles/flash_player_8_security.pdf [2] http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd [3] http://www.amazon.com/crossdomain.xml Regards- -Doug Research and Standards Engineer 6th Sense Analytics www.6thsenseanalytics.com mobile: 919.932.9872
Clipboard (cut, drag, drop, etc) draft
Hi folks, I have a draft for the clipboard stuff. It's pretty rough and there is plenty to do still, but it is at http://dev.w3.org/cvsweb/2006/webapi/clipops/clipops.html?rev=1.6 comments welcome as always... cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
ISSUE-90: passwd seems underdefined in RFC2617
ISSUE-90: passwd seems underdefined in RFC2617 http://www.w3.org/2005/06/tracker/webapi/issues/90 Raised by: Anne van Kesteren On product: XMLHttpRequest For the open() method I was trying to come up with error handling for the user and password arguments. It seems that user comes down to quoted-string which is defined in http://ietf.org/rfc/rfc2616 but passwd comes down to: passwd = user's password according to http://ietf.org/rfc/rfc2617 ... Should probably raise this with the HTTP WG.
Re: ISSUE-90: passwd seems underdefined in RFC2617
* Web APIs Issue Tracker wrote:
ISSUE-90: passwd seems underdefined in RFC2617
http://www.w3.org/2005/06/tracker/webapi/issues/90
Raised by: Anne van Kesteren
On product: XMLHttpRequest
For the open() method I was trying to come up with error handling for the user
and password arguments. It seems that user comes down to quoted-string which
is
defined in http://ietf.org/rfc/rfc2616 but passwd comes down to:
passwd = user's password
according to http://ietf.org/rfc/rfc2617 ...
I am not sure which kind of error you are trying to handle. It seems the
error you are trying to cover is that a password is specified in the XHR
open method call which then cannot be used as password for the selected
authentication scheme. As an example,
xhr.open('GET', 'http://example.org', true, 'user', '\u0001');
If the authentication scheme server and client negotiate is Basic, the
client will not be able to use U+0001 in the password because for Basic
only *TEXT is allowed and TEXT excludes 0x01. Other schemes might employ
different rules. It seems for the Digest algorithm you cite above, this
is not so well-defined in the prose. However, I don't really see how the
XHR specification is affected by this, if the implementation attempts to
automatically respond to authentication challenges, it should do so only
if the supplied credentials are suitable for use with the negotiated
scheme, and it's up to those schemes to define what's suitable.
What is more of an issue is how to convert a DOMString into something
that is suitable for use as password and/or username in the context of
such a scheme.
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: XMLHttpRequest test suite suggestion
Anne van Kesteren wrote: How is that defined? Is it possible to take window1.XMLHttpRequest and use apply() to call it with window2 as |this|? ... Sorry, it's the window from which you use the constructor. That doesn't answer my question above. It just shifts the burden onto defining what the window from which you use the constructor means. Could we have a definition in terms of things defined in the ECMA specification or something? One that would be completely unambiguous? I'm getting pretty tired of definition-by-example, especially without an exhaustive example set. -Boris
[File Upload] Security problems with File Upload
I'm concerned about the open() method on the FileDialog interface. It seems like it would make it possible, through an attack like the famous fast clicking game, to cause a user to select a file (probably at random, but from the user's home directory, so likely a confidential file). I would feel much more comfortable if the FileList API was provided merely as an extension to the HTMLInputElement interface, thus requiring authors to use an input type=file control, and requiring users to click the Browse button before the dialog would appear. (UAs can then guarentee that the fast clicking game attack will be unsuccessful, by positioning the file dialog such that the button location doesn't coincide with a sensitive part of the dialog.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [File Upload] Security problems with File Upload
On Fri, 22 Sep 2006, Robin Berjon wrote: I would feel much more comfortable if the FileList API was provided merely as an extension to the HTMLInputElement interface, thus requiring authors to use an input type=file control, and requiring users to click the Browse button before the dialog would appear. The problem with this solution is that it then requires that the environment supports input type=file, which isn't always the case. Hm. Could we split the spec into two parts, one for those environments without HTML, and one for those with? It would be good to keep the APIs for browsers to an absolute minimum, especially now with the ballooning number of new APIs that are being specified, and for HTML browsers I really think it would be much simpler (and safer) to stick this on the end of HTMLInputElement rather than have a whole new API. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [File Upload] Security problems with File Upload
Hi Ian, On Sep 22, 2006, at 17:15, Ian Hickson wrote: It seems like it would make it possible, through an attack like the famous fast clicking game, to cause a user to select a file (probably at random, but from the user's home directory, so likely a confidential file). There are well-known workarounds for this, notably delayed activation of the dialogue. This could be noted in the specification. I would feel much more comfortable if the FileList API was provided merely as an extension to the HTMLInputElement interface, thus requiring authors to use an input type=file control, and requiring users to click the Browse button before the dialog would appear. The problem with this solution is that it then requires that the environment supports input type=file, which isn't always the case. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: XMLHttpRequest test suite suggestion
On Fri, 22 Sep 2006 16:41:12 -, Boris Zbarsky [EMAIL PROTECTED] wrote: That doesn't answer my question above. It just shifts the burden onto defining what the window from which you use the constructor means. Can you point out the problem in that definition? Could we have a definition in terms of things defined in the ECMA specification or something? One that would be completely unambiguous? I'm getting pretty tired of definition-by-example, especially without an exhaustive example set. Well, I don't like definition-by-example at all and was trying to define something that wasn't. It's not really clear to me what the problem with the definition is. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest test suite suggestion
Anne van Kesteren wrote: On Fri, 22 Sep 2006 16:41:12 -, Boris Zbarsky [EMAIL PROTECTED] wrote: That doesn't answer my question above. It just shifts the burden onto defining what the window from which you use the constructor means. Can you point out the problem in that definition? Did you read the question I quoted in my previous mail? To repeat it a third time. If do something along the lines of: var func = window1.XMLHttpRequest; var req = new (func.apply(window2)(); or some such, which is the window from which you use the constructor? window1 or window2? If what I said is not possible to do, I'm happy, but then I'd like to be pointed to the part of the ECMA spec that says so; I haven't been able to find it. It's not really clear to me what the problem with the definition is. The fact that it uses a concept (window from which you use the constructor) that it never defines and doesn't reference a definition for? -Boris
Re: XMLHttpRequest test suite suggestion
Boris Zbarsky [EMAIL PROTECTED] To repeat it a third time. If do something along the lines of: var func = window1.XMLHttpRequest; var req = new (func.apply(window2)(); or some such, which is the window from which you use the constructor? window1 or window2? If what I said is not possible to do, I'm happy, but then I'd like to be pointed to the part of the ECMA spec that says so; I haven't been able to find it. It's a host object the apply is undefined in ECMA, so I see no reason for the WEB API's WG to define it more than ECMA does. I would encourage you to simply not support apply on such host objects, it's far the easiest solution, and avoids the problem you have.. Jim.
Re: XMLHttpRequest test suite suggestion
Jim Ley wrote: It's a host object the apply is undefined in ECMA, so I see no reason for the WEB API's WG to define it more than ECMA does. Unless you want better interoperability than ECMA provides, of course. Which I do. I would encourage you to simply not support apply on such host objects, You could just make that part of the XMLHttpRequest spec. Fine by me. As long as behavior is well-defined. it's far the easiest solution, and avoids the problem you have.. It doesn't avoid the general interop problem. It avoids the problem in my specific implementation, sure. -Boris
Re: Clipboard (cut, drag, drop, etc) draft
Here's a few remarks that strike me at first: - I'm missing a copy-event... or do you really want to be as MSIE-follower so as not having such and rely on the old method that write directly to a clipboard singleton. If wishing to do so, I recommend we try to follow Safari's way and spec [1] which actually states that reading/writing from/to clipboard is only open when in the middle of achieving the paste/copy commands - you seem not to speak about standard gestures although this is fundamental in order to describe when a UA is expected to invoke the copy and paste mechanisms. I would suggest to add this within the security considerations by qualifying that the copy, paste, drag, and drop operations should only be triggered when the UA has recognized, by a standard gesture, that the user intended consciously to start these operations. Some more work I've been doing on the topic has been presented at the MathUI workshop, see [2]. Among these articles I tried to make clear that the differences between CnP and DnD that copy needs to store all possible translations to the clipboard whereas in DnD there is content-type negotiation at drop time (between the source and target) and that only then the content-translation occurs. It might be possible to escape this description in this note but I think it is a fundamental one and expect, for example, that it should be possible for a drop operation to actually trigger a server request. A simple example of that would be the transfer of a formula into a graphical programme where, eg, something like a bitmap could be generated from the MathML (definitely needs layout capabilities of a server). So I would suggest to separate well clipboard/copy-and-paste and dataTransfer/drag-and-drop. Maybe we should characterize how much further than MDT this note wishes to go ? Support for any mime-types, I think, is certainly a first step that's wished or ? Late translation of DnD is also one, I hope. hope that helps. May I suggest concrete text bits ? paul [1] Introduction to Safari JavaScript Programming Topics http://developer.apple.com/documentation/AppleApplications/Conceptual/SafariJSProgTopics/ [2] http://www.activemath.org/~paul/pubs/LJ-CnP-mathui06.html Charles McCathieNevile wrote: On Fri, 22 Sep 2006 14:18:31 -, Paul Libbrecht [EMAIL PROTECTED] wrote: While browsing the document, my firefox 1.5 is asking me to manually install an unknown plugin... is this something I should trust ? ;-) Oh, there is a MathML example in there. No, feel free to ignore it. I'll check that I have reasonable fallback presentation too, and find out what makes the W3C server send the right MIME type (if I recall, Firefox is supposed to support MathML). Firefox does for sure but I don't know the right way with the object tag and html 4... the Math WG has always tended to say that MathML should with as included elements within an XML document. I am not sure it'll work with HTML 4... Anything against using xhtml in this document ? smime.p7s Description: S/MIME Cryptographic Signature
Re: Clipboard (cut, drag, drop, etc) draft
Hi Paul, thanks for looking at the draft and for your comments. On Fri, 22 Sep 2006 22:33:54 -, Paul Libbrecht [EMAIL PROTECTED] wrote: Here's a few remarks that strike me at first: - I'm missing a copy-event that's just a straight bug I think, but I will look at it for the next draft. The important thing for this one is to have a draft that is formally published. I realise there are many things in the current draft that are under-specified and under-tested. - you seem not to speak about standard gestures although this is fundamental in order to describe when a UA is expected to invoke the copy and paste mechanisms. I would suggest to add this within the security considerations... I think this is already in the draft, but I will look at making it clearer for the next draft... Some more work I've been doing on the topic has been presented at the MathUI workshop, see [2]. Among these articles I tried to make clear that the differences between CnP and DnD that copy needs to store all possible translations to the clipboard whereas in DnD there is content-type negotiation at drop time (between the source and target) and that only then the content-translation occurs. It might be possible to escape this description in this note but I think it is a fundamental one and expect, for example, that it should be possible for a drop operation to actually trigger a server request. A simple example of that would be the transfer of a formula into a graphical programme where, eg, something like a bitmap could be generated from the MathML (definitely needs layout capabilities of a server). So I would suggest to separate well clipboard/copy-and-paste and dataTransfer/drag-and-drop. Maybe we should characterize how much further than MDT this note wishes to go ? Support for any mime-types, I think, is certainly a first step that's wished or ? Late translation of DnD is also one, I hope. Actually for version one I would like to have something that is pretty close to what is already implemented. I also want to go beyond this to a more useful mechanism, but I think the best approach is to get out a quick version one, and make a version two that actually does what people really want. Part of the challenge of that is getting commitment from implementors too, and I think that will take more time than I want to spend on version one. hope that helps. May I suggest concrete text bits ? These are very helpful. You are most welcome to suggest concrete text changes. However, I will probably suggest to the group that we don't go too far in version one and instead work towards a version two which actually moves beyond today's limits. I am happy to start working on that while we are still working on version one, since it can be helpful to identify what we are trying to do in general. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
