Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
On Tue, Nov 17, 2009 at 9:12 PM, Julian Reschke julian.resc...@gmx.de wrote:
3. We could not directly call out a URI scheme at all. The benefit of
doing this is we can specify *behavior* without actually getting into
details about the actual identifier scheme used. But, the chief reason to
not take this course of action is that leaving *anything* unspecified on the
web platform leads to reverse engineering in ways that we can't envision
currently. Developers may rely on quirks within one implementation and
incompatibly use them with other implementations. Having to mimic another
user agent's behavior has been a common outcome on the web, due to lack of
specifications -- *many* examples of this exist on the web throughout its
history. One lesson from the browser competition of the past is to avoid
leaving things to guesswork. I'd like us to agree on something, and I'd
like that agreement to be bolstered with concrete implementor feedback.
...
Not requiring a specific scheme is not exactly the same thing as leaving it
unspecified. If the *only* use of the identifier is within the API, the
syntactical form of the identifier really doesn't matter as long as it's
understood by the those parts of the platform that need to.
Requiring a specific scheme here seems to be a case of *overspecifying*.
As far as I'm concerned, the reason to specify a scheme here is for
code that would stuff a bunch of URIs into an array, then walk through
the array and depending on what type of URI it is do different things.
Say a function that takes an array of URIs of images to pre-cache (in
order to allow the images to be displayed in a user interface without
ugly half-loaded images). The code might look something like:
var imgCache = [];
function cacheURIs(uris) {
for each (var uri in uris) {
// No need to waste resources on caching local images, they load
fast enough anyway
if (uri.substr(0, 9) != urn:uuid:) {
img = document.createElement(img);
img.src = uri;
imgCache.push(img);
}
}
}
Now, we can certainly debate how likely it is that someone will write
code like the above. For example, when would you have a mixture of
remote and local uris like that? But I don't think it's impossible, so
I wouldn't think it's overspecifying.
/ Jonas
Re: Let's turn WebDatabase into a WG Note
I'm not sure that further back-and-forth on this topic is useful at this time. I know that you are strongly against Web Database. You have expressed that view for some time, and I don't expect to change your mind. I don't find your arguments particularly persuasive either. If we continue this debate, then doubtless we will rehash points that have already been discussed to death. (If, contrary to my expectation, the rest of the Working Group would like to see more of this discussion, then please let me know, and I'll be glad to reply to Nikunj's points in exacting detail.) Further: if the other vendors planning to ship Web Database implementations (Google, Opera, perhaps others who have not spoken up yet) take the position that they would be like to end work on Web Database at the W3C, then I'm fine with publishing it as a Note (and possibly continuing work as a WHATWG or webkit.org spec). Until then, I would prefer to see work continue here. Regards, Maciej On Nov 17, 2009, at 11:23 PM, Nikunj R. Mehta wrote: On Nov 17, 2009, at 10:58 PM, Maciej Stachowiak wrote: On Nov 17, 2009, at 10:26 PM, Nikunj R. Mehta wrote: On Nov 17, 2009, at 10:17 PM, Maciej Stachowiak wrote: On Nov 17, 2009, at 9:34 PM, Nikunj R. Mehta wrote: Hi guys, I've been thinking about the WebDatabase specification [1] and I've come to two conclusions. (1) We are miles away from consensus on this specification, and, hence, we should _not_ consider putting it out for last call. (2) While good work has gone into the IDL/JavaScript Call Level Interface (CLI), we have made no progress on its SQL language specification and are not likely to in the future. Thus we should publish the CLI as a WG Note titled WebSQLDatabase CLI and curtail active work on this specification in the working group. This is Oracle's official position on this matter. I disagree. I don't understand your reasons. I already sated some reasons in the previous thread about 'parking' the spec. I did not want to belabor the point, since it's clear we don't have consensus within the Working Group on the right way to go. Publishing a WG Note would be appropriate if we had WG consensus to stop work. Understood I don't think we have consensus to do that. This is what I am trying to bring about. See the reasoning in my original email. It would help if you can respond to the three points why I think we have reached the end of the road. I think that the three possibilities you listed are: From your message it is clear that you are not willing to refute any of the points. That is a good start. - Not an exhaustive enumeration of the possibilities. (I realize that at this point, to convincingly show that a good SQL dialect spec is possible will require actually doing it; I'm not sure how or when that will happen but I am looking into it.) You have not provided a logical explanation of why my list is not exhaustive. Can you show what is left out? - Not sufficient reason to stop work, given that we have multiple willing implementors and so far no problems in practice. More than simply a existential implementation proof is necessary to continue work on WebDatabase. I note that there is a difference between an implementable spec and a public standard. Neither your nor anyone else has made a convincing argument about how WebDatabase will lead to a legal public standard, i.e., be capable of supporting multiple independent implementations. I welcome you to prove me wrong. Furthermore, stopping work would do practical harm: I understand that a lot of good work went on in to WebDatabase as well as the implementations thereof. It is another matter that this effort was misguided from the beginning. Consequentially, WebDatabase doesn't stand a practical chance at becoming a standard. Therefore, we do not see any harm caused by stopping work. In fact, I find it harmful to continue efforts in this direction. - A WG Note would stop work without producing a test suite, thus harming interoperability. Interoperability should only matter if you care for multiple _independent_ implementations. You have already acknowledged in prior emails that this is unlikely to happen, ergo lack of a test suite does no harm. - A WG Note would leave us with no clear process to fix problems found in the spec in the course of implementation. The WG Note is dissuading implementors to go forward with this technique. Therefore, there is no need to fix problems. In any case, no one seems interested in solving the real problem - lack of an interoperable SQL. - A WG Note is harder to resurrect in case of new info than a stalled Working Draft; it would require essentially a new FPWD. The rate at which FPWDs are produced in this WG, this seems like a marginal issue. - It's likely that Web Database implementors will at some point want to add
Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
Jonas Sicking wrote:
On Tue, Nov 17, 2009 at 9:12 PM, Julian Reschke julian.resc...@gmx.de wrote:
3. We could not directly call out a URI scheme at all. The benefit of
doing this is we can specify *behavior* without actually getting into
details about the actual identifier scheme used. But, the chief reason to
not take this course of action is that leaving *anything* unspecified on the
web platform leads to reverse engineering in ways that we can't envision
currently. Developers may rely on quirks within one implementation and
incompatibly use them with other implementations. Having to mimic another
user agent's behavior has been a common outcome on the web, due to lack of
specifications -- *many* examples of this exist on the web throughout its
history. One lesson from the browser competition of the past is to avoid
leaving things to guesswork. I'd like us to agree on something, and I'd
like that agreement to be bolstered with concrete implementor feedback.
...
Not requiring a specific scheme is not exactly the same thing as leaving it
unspecified. If the *only* use of the identifier is within the API, the
syntactical form of the identifier really doesn't matter as long as it's
understood by the those parts of the platform that need to.
Requiring a specific scheme here seems to be a case of *overspecifying*.
As far as I'm concerned, the reason to specify a scheme here is for
code that would stuff a bunch of URIs into an array, then walk through
the array and depending on what type of URI it is do different things.
Say a function that takes an array of URIs of images to pre-cache (in
order to allow the images to be displayed in a user interface without
ugly half-loaded images). The code might look something like:
var imgCache = [];
function cacheURIs(uris) {
for each (var uri in uris) {
// No need to waste resources on caching local images, they load
fast enough anyway
if (uri.substr(0, 9) != urn:uuid:) {
img = document.createElement(img);
img.src = uri;
imgCache.push(img);
}
}
}
Now, we can certainly debate how likely it is that someone will write
code like the above. For example, when would you have a mixture of
remote and local uris like that? But I don't think it's impossible, so
I wouldn't think it's overspecifying.
...
If the use case is, given an arbitrary URI, to distinguish one
identifying a file object from others, then *either* a distinct scheme
(1) is needed, or an API could be added that answers that question.
(1) In that case, re-using urn:uuid seems to be a bad idea, because it
precludes that scheme being used for anything else.
BR, Julian
Re: comments from Osmosoft on the File API
Hi Paul! On Nov 11, 2009, at 12:30 , paul.dow...@bt.com paul.dow...@bt.com wrote: During our review we have one overall disappointment: whilst the Use Cases describe saving local files programatically, the specification does not provide any write methods. We wondered if these were to be provided in a later version or via extensions? --We now gather this is a topic of debate within the WG and with the DAP WG. The reason for this split is largely due to the different security requirements. During the f2f we discussed producing layered specifications that would have read, then write, then navigating the file system as compatible APIs that would at the very least share a similar style and some basic objects. There were some doubts that such a thing would really work out, but we're looking into options and I have good hope. What is the current expectation of the status of the published document? Is it on the Recommendation track, or will it be published as a Working Group Note? It is on Rec track, it is intended to become a web standard supported across all browsers (and other web runtimes). What is the relationship between the File API document and the File Upload API listed on the historical Web API WG page? http://www.w3.org/2006/webapi/ http://www.w3.org/TR/file-upload/ As Art said, the File (Reader) API is just the new File Upload API. The name changed to reflect the evolution of its core concern. * Acknowledgements Where is the original document from Robin Berjon? A link to the input document may help us better understand the context of this specification. Even I would be pained to dig it up, and if I did it would be unlikely to be very useful. My name is only there because Arun is a urbane and gentlepersonly fellow — I believe that the current content is entirely his. If you feel that you need some context outside of the current document in order to understand it then we're missing something there — reading antiquated material really should never ever be a requirement in order to make sense of a specification. If you could pinpoint the context that you may feel to be missing, we would certainly be indebted. * Processing Models Much of the specification seems to be written in terms of pseudo-code steps. Whilst this follows the style of parts of the HTML 5 specification, and simplifies cloning a working implementation, it can make it harder to read and more difficult to write tests for than a series of assertions. I'd suggest wherever possible, replacing the processing steps with a set of inputs, observable changes of state and outputs, even if this does make the specification more verbose. This pseudo-code approach definitely has readability limits, but it does have the big advantage of making the job of implementing the specification (and, through that, of spotting specification bugs) far easier, as I can attest having recently implemented a specification written similarly. So while I do think that we should keep looking for ways in which to improve this writing style, I would rather wish it to stay. I believe that the issue is largely one of audience. In order to produce interoperability, specifications need to be primarily tailored to implementers. I guess that you are approaching the document more from an author's point of view. I do believe that authors should also be catered to (either within the same document, or with a separate authoring primer), but the corresponding text can only be written once we have some confidence that we've nailed down the grittier details of the implementer-orientated stuff; lest we have to make changes twice while the API is still in flux. * Conformance The terminology used for conformance currently links within the document, rather than to HTML 5 specification. I'm not sure what you mean here? A a frag-id for each individual assertion, along with a table listing all of the assertions at the end of the document useful when building test suites. That's probably something that will happen (as it has in the widgets specifications) but I would expect that to come a little bit later. -- Robin Berjon - http://berjon.com/
File upload superseded by File API?
Hi, My understanding is that the File Upload spec is now superseded by the File API spec, but http://www.w3.org/TR/file-upload/ doesn't redirect to http://www.w3.org/TR/FileAPI/ I guess ideally the latter would have used the former has previous version, but since it’s too late for that, I think the group should at least ask the W3C Webmaster to do the redirect from the former to the latter. Thanks, Dom
Re: Let's turn WebDatabase into a WG Note
On Wed, 18 Nov 2009 09:35:57 +0100, Maciej Stachowiak m...@apple.com wrote: Further: if the other vendors planning to ship Web Database implementations (Google, Opera, perhaps others who have not spoken up yet) take the position that they would be like to end work on Web Database at the W3C, then I'm fine with publishing it as a Note (and possibly continuing work as a WHATWG or webkit.org spec). Until then, I would prefer to see work continue here. I agree. I don't get the sudden rush to end this as WG item. -- Anne van Kesteren http://annevankesteren.nl/
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com wrote: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events. Without bikeshedding too much, I like your proposal above, but wonder whether we should use the name 'write*' or something else. Since we already have document.write, 'write' is probably the most vetted string to use here :) For what it's worth, for XMLHttpRequest sending events (which are arguably somewhat like write) we still use loadstart/... and simply dispatch them on a distinct object. I've no idea what the file writer API will look like, but I can imagine we might be able to do the same there. -- Anne van Kesteren http://annevankesteren.nl/
Re: File upload superseded by File API?
On Wed, 18 Nov 2009 10:13:10 +0100, Dominique Hazael-Massieux d...@w3.org wrote: My understanding is that the File Upload spec is now superseded by the File API spec, but http://www.w3.org/TR/file-upload/ doesn't redirect to http://www.w3.org/TR/FileAPI/ I guess ideally the latter would have used the former has previous version, but since it’s too late for that, I think the group should at least ask the W3C Webmaster to do the redirect from the former to the latter. If we do that (seems like a good idea) we should add file-upload to Previous Versions: as well so that going forward you can find it somewhat easily. -- Anne van Kesteren http://annevankesteren.nl/
Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
On Wed, 18 Nov 2009 01:03:23 +0100, Arun Ranganathan a...@mozilla.com wrote: 1. We could coin a new scheme such as the originally proposed filedata: scheme. This has the advantages of associating behavior (and semantics) with a scheme, so that existing schemes aren't confused or co-opted inappropriately. However, actually registering a new scheme used by browsers seemed problematic (with overhead due to coordination with multiple groups). I'm willing to revisit this idea given enough feedback, but to date, haven't really received enough of it. It's not implementor feedback, but I think this is the best solution. I think it's valuable that you can tell what the URL is for just by looking at it. Jonas gave an example of how that might be used in practice. From what I've heard so far it does not matter much for Opera either, but I rather have a new scheme. It also seems safer in case something comes up down the road. -- Anne van Kesteren http://annevankesteren.nl/
Re: Let's turn WebDatabase into a WG Note
On Wed, Nov 18, 2009 at 9:16 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 18 Nov 2009 09:35:57 +0100, Maciej Stachowiak m...@apple.com wrote: Further: if the other vendors planning to ship Web Database implementations (Google, Opera, perhaps others who have not spoken up yet) take the position that they would be like to end work on Web Database at the W3C, then I'm fine with publishing it as a Note (and possibly continuing work as a WHATWG or webkit.org spec). Until then, I would prefer to see work continue here. I agree. I don't get the sudden rush to end this as WG item. Agreed. There are many unfortunate aspects to WebDatabase, but it's not going away any time soon. Lets re-examine this once we have some implementational experience with WebSimpleDB (or whatever it's called these days).
Re: [FileAPI] File.mediaType
On Tue, 17 Nov 2009 22:26:20 +0100, Arun Ranganathan a...@mozilla.com wrote: 1. I agree that name consistency is desirable, so mediaType is now simply type. I'll point out that style.type expects very few types back, whereas for files, the picture is more complicated, so simply calling it type has drawbacks, but since mediaType isn't used elsewhere on the platform, I agreed that reusing the same name was desirable. Yay! Now can we please get File.URL too? :-) (It does not matter what the scheme ends up being, they're all URLs as far as author-facing APIs elsewhere are concerned, as mentioned before.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Rename “File API” to “FileReader API”?
Hey Arun, On Nov 13, 2009, at 11:28 , Arun Ranganathan wrote: Discussion about renaming shows that there isn't really consensus about a name change [1][2], so I haven't proceeded with one. I'd rather proceed without a name change for now, but work towards evolving file write capabilities safely for the web based on this API. I'm not averse to multiple specifications (and better naming later on), if we find that use cases diverge between groups. Some editorial help has been forthcoming [3], which is welcome. I was thinking about this yesterday, and while there's no emergency (it doesn't need to happen before the FPWD), how about: File API Level 1: Reading File API Level 2: Writing File API Level 3: Directories Arguments: - we've already received feedback that people are confused that the API does only reading (even if after hearing the explanation they understand), having it somewhere in the name would help - it matches the way we sliced it at the f2f that seemed to garner at least some amount of consensus (and in fact since it seems some who agree with it most violently weren't actually listening at the time :) - levels are rather familiar to implementers and authors - I do think we can model these as layers of the same API (with different entry points of course) No need to decide now, it's just an option I wanted to put out there before I forgot. -- Robin Berjon robineko — hired gun, higher standards http://robineko.com/
Re: [widgets] About the test suite
On Nov 14, 2009, at 04:30 , Marcos Caceres wrote: Also, we are working on an implementation of the widget spec but we don't have support for HTML, only SVG. The tests are currently designed with HTML start files. Would it be possible to have alternative versions with SVG start files ? Sure! I'm happy to include that. However, I will need your help to make that happen. If you can commit some time, then we can talk about how we get SVG as a standard part of the test suite. WDYT? That should actually be reasonably trivial. Most of the HTML documents in the test suite are the same green/red/grey documents. It's easy to make the same in SVG, and then replace all the HTML documents with the same hash with their corresponding SVGs, renaming the .html in the config files. That should leave a few to change manually, but nothing horrible. Having a script to do the entirety of this (including, if possible, the mostly manual parts) would be great as it would help us maintain only one source. -- Robin Berjon - http://berjon.com/
Re: [WARP] Comments to WARP spec
On Nov 12, 2009, at 16:36 , Marcin Hanclik wrote: I understand that too many details may not work or be an obstacle in the adoption. However, I derive that from the security point of view we still would like to distinguish at least between executable and non-executable content. That doesn't work. Not only could some script just manipulate canvas stuff, but some images can execute script. It would be trivial to create lossless bitmaps that could encode script. One could also use XHR to evaluate content returned as text/plain (or as a bunch of other things). One could request an image that is redirected to http://address/of/image?put+a+complete+script+here and then evaluate the query. I think there are two threads in this discussion, one seems to concern the default behaviour of widget UAs as defined by WARP — I think that's a valuable discussion to have (is the request simply that WARP be open by default for the same things that are allowed in a browser?) that is being drowned in the other discussion, which is about a semi-sentient local filtering proxy firewall built using pieces of flint and some string. Can we focus on the first one? -- Robin Berjon - http://berjon.com/
Re: [WARP] Comments to WARP spec
On Nov 9, 2009, at 20:22 , SULLIVAN, BRYAN L (ATTCINW) wrote: (1) we need to be specific about which API's / resource types are affected by inclusion (or exclusion) of domains in access (and keep this equivalent to HTML5) We're very specific: it's a blanket exclusion. Now I can be sensitive to an argument indicating that the default is defined by the security policy of the host language, in which case we need to also clarify which default to pick when there are several (HTML for instance has different origin rules for file:// and http://). My primary objection is that it's pretty late to have this discussion, the restriction has been there for months. -- Robin Berjon - http://berjon.com/
Re: DAP and security (was: Rename “File API” to “FileReader API”?)
2009/11/12 Dominique Hazael-Massieux d...@w3.org: Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit : I would be concerned with leaving file writing to DAP, because a widely held view in DAP seems to be that security can be ignored while designing APIs and added back later with an external policy file mechanism. I don't know where you got the idea that it's a widely held view - That is plainly ridiculous and verging on the insulting. I'm pretty certain no one holds that view in DAP. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Test suite: problem with test cases
2009/11/14 Scott Wilson scott.bradley.wil...@gmail.com: I've added the tests to Apache Wookie as JUnit tests that directly load the test .wgt's from the SVN - so far so good! Awesome. However testing has revealed a few possible bugs in the test cases: Assertion 14: Test AY Test the UA's ability process the height attribute. To pass, the widget height must be the value 0 (the value is composed of characters). Widget config.xml: widget xmlns=http://www.w3.org/ns/widgets; height=1234 nameay/name /widget This has probably got mixed up with another test widget; I imagine it should work the same way as test case 15: c9 and should be: widget xmlns=http://www.w3.org/ns/widgets; height=ABC nameay/name /widget woops, fixed. Assertion 34: Test d7, d8 === These test cases both contain badly-formed XML: widget content /widget Presumably these ought to be: widget content/ /widget Fixed and checked in. -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] LCWD#3 comments (1)
Hi, Marcin! 2009/11/17 Marcin Hanclik marcin.hanc...@access-company.com: Hi, A couple of comments to the latest PC. 7.4 Media type attribute Media type attribute defines the grammar and refers to RFC2045/6. What about referring to RFC4288 that includes the grammar required for MIME registration [1]? (I have no strong opinion about this point, though.) I think I will leave this as is. Numeric attribute For example, the characters 002, 323, 23214 Could be For example, the character strings 002, 323, 23214 Good suggestion, but I changed it to just say the strings... The words character strings would be a tautology. 7.11.1 When an icon element is used, it is required for authors to use the src attribute. Should be an authoring guideline. Fixed. 7.13.1 that a user agent will behave as the required attribute Should be that a user agent will behave as if the required attribute Fixed. Acknowledgments It seems a paragraph is missing there. Fixed. -- Marcos Caceres http://datadriven.com.au
[Widgets] LCWD#3 comments (2)
5.3 (grammar: I hope these are final corrections :( ) [*folder-name] Should be *folder-name Since the current form makes it optional twice Zip-rel-path file-name/ could be file-name / (note the space before '/') safe-char I suggest putting the '/' sign at the end of each line instead of at the beginning 7.4 Media type attribute It is unclear why the valid-MIME-type production requires parameter. parameter could specify the charset and that could conflict with the @encoding attribute of the content element. Also the valid-MIME-type could be replaced with the following from RFC4288 type-name = reg-name subtype-name = reg-name reg-name = 1*127reg-name-chars reg-name-chars = ALPHA / DIGIT / ! / # / $ / / . / + / - / ^ / _ BTW: I understand that W3CMediaReg uses RFC2046 (actually RFC2048), but RFC4288 (also BCP13) obsoletes RFC2048. So it gets blurred to me. Path attribute a valid path represent a hierarchical Should be a valid path represents a hierarchical Version attribute e.g. '1.0' is not greater than '2.0' Could be e.g. '1.0' is not less than '2.0' 9.1.10 a) There is no step 11, ol was changed to ul after step 4. b) SNIFF spec basically specifies the algorithms for the resources retrieved from the network. The statement relevant to PC seems to be: For resources fetched from the file system, user agents should use platform-specific conventions, e.g. operating system file extension/ type mappings. Therefore it is unclear what processing filehttp://dev.w3.org/2006/waf/widgets/#file through the [SNIFF]http://dev.w3.org/2006/waf/widgets/#sniff specification. means (i.e. SNIFF is big, but we need just one sentence?). Are we restricted e.g. to section 5 (Unknown Type)? c) The version of the SNIFF spec that is referred by PC is 00 (by date) and it has already expired as ID. Thanks, 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] LCWD#3 comments (1)
Hi Marcos, 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, November 18, 2009 1:02 PM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [Widgets] LCWD#3 comments (1) Hi, Marcin! 2009/11/17 Marcin Hanclik marcin.hanc...@access-company.com: Hi, A couple of comments to the latest PC. 7.4 Media type attribute Media type attribute defines the grammar and refers to RFC2045/6. What about referring to RFC4288 that includes the grammar required for MIME registration [1]? (I have no strong opinion about this point, though.) I think I will leave this as is. Numeric attribute For example, the characters 002, 323, 23214 Could be For example, the character strings 002, 323, 23214 Good suggestion, but I changed it to just say the strings... The words character strings would be a tautology. 7.11.1 When an icon element is used, it is required for authors to use the src attribute. Should be an authoring guideline. Fixed. 7.13.1 that a user agent will behave as the required attribute Should be that a user agent will behave as if the required attribute Fixed. Acknowledgments It seems a paragraph is missing there. Fixed. -- 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: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
Robin Berjon wrote: ... Couldn't we just register a URN NID for this? It seems that one has to go through fewer hurdles, and no matter how transient I believe that it's a useful thing to identify. ... Yes, that's possible and probably would cause less eyebrows being raised... BR, Julian
RE: DAP and security (was: Rename “File API” to “FileReader API”?)
+1 APIs - specifically their design - shall be specified tightly with the security model in mind to make them both easy to use and effective. This is what makes the whole task that difficult. Thanks, 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: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Dominique Hazael-Massieux Sent: Thursday, November 12, 2009 10:30 AM To: Maciej Stachowiak Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: DAP and security (was: Rename “File API” to “FileReader API”?) Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit : I would be concerned with leaving file writing to DAP, because a widely held view in DAP seems to be that security can be ignored while designing APIs and added back later with an external policy file mechanism. Frederick already mentioned this isn’t the case at all, and I want to strongly reject the notion that DAP is considering security as an after-the-fact or out-of-band aspect in the design of its APIs. Our charter clearly stipulates that our policy model “must be consistent with the existing same origin policies (as documented in the HTML5 specification), in the sense that a deployment of the policy model in Web browsers must be possible”. In fact, most of models that have been discussed in this thread to reduce the risks exposed by new APIs (sandbox for writing, user interaction or markup-based element for sharing data) were already mentioned as options by DAP WG participants during our F2F last week. More generally, I don’t think assuming that DAP would create worse/less secure APIs than WebApps or any other group would is either right nor useful to ensure a good collaboration between our groups. And clearly, we will actively be seeking feedback and input from the WebApps Working Group when we produce new APIs, which should also contribute to reduce the fears that we would get it all wrong :) Regards, Dom 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: DAP and security (was: Rename “File API” to “FileReader API”?)
OK, I will take your word for it that security is an important consideration for DAP. But while at the TPAC, I heard more than one DAP participant say, when faced with a potential security concern, something like can't we just leave that up to the policy? In one case when I enquired further, at least one DAP member mentioned to me the idea of using some sort of policy file that would take care of all security issues. He suggested this might come from a corporate administrator, and that the format would be XML, but otherwise details were light. To me that seems like a plausible model for something like widgets or browser extensions or walled garden content, but not for sites on the public Web. My apologies if I misinterpreted these remarks or got the wrong impression. One more comment below: On Nov 18, 2009, at 4:18 AM, Marcin Hanclik wrote: +1 APIs - specifically their design - shall be specified tightly with the security model in mind to make them both easy to use and effective. This is what makes the whole task that difficult. Thanks, 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: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org ] On Behalf Of Dominique Hazael-Massieux Sent: Thursday, November 12, 2009 10:30 AM To: Maciej Stachowiak Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: DAP and security (was: Rename “File API” to “FileReader API”?) Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit : I would be concerned with leaving file writing to DAP, because a widely held view in DAP seems to be that security can be ignored while designing APIs and added back later with an external policy file mechanism. Frederick already mentioned this isn’t the case at all, and I want to strongly reject the notion that DAP is considering security as an after-the-fact or out-of-band aspect in the design of its APIs. Our charter clearly stipulates that our policy model “must be consistent with the existing same origin policies (as documented in the HTML5 specification), in the sense that a deployment of the policy model in Web browsers must be possible”. It seems to me that for most of DAP's likely deliverables, there are serious security considerations, but the same-origin policy is irrelevant to addressing them. The same-origin policy is designed to protect Web sites from attacks by other Web sites. It does not really apply to access to system resources. Doing that in a Web-safe way will require new inventions or might not even be possible in some cases. In fact, most of models that have been discussed in this thread to reduce the risks exposed by new APIs (sandbox for writing, user interaction or markup-based element for sharing data) were already mentioned as options by DAP WG participants during our F2F last week. More generally, I don’t think assuming that DAP would create worse/ less secure APIs than WebApps or any other group would is either right nor useful to ensure a good collaboration between our groups. And clearly, we will actively be seeking feedback and input from the WebApps Working Group when we produce new APIs, which should also contribute to reduce the fears that we would get it all wrong :) Regards, Dom 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: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Hi Anne, XHR still is used also for data retrieval, so it is a kind of border case and I can live with load there :) . Using load for writing to a file will mean that we are stuck with the legacy stuff. load and write pull semantically in the opposite directions, IMHO. I think there is still time to change it in case of FileReader and prepare background for FileWriter. I like the ProgressEvents spec and would keep it generic, i.e. change the names there to be generic and mandate their change in each spec that refer to ProgressEvents. PE is perfect to be a design pattern for asynchronous (and lengthy, more-than-one-shot, with-start-and-end, abortable and potentially erroneous) DAP APIs. In the firing grammar: progressgrammar = loadstart working (error | abort | load) loadend working = *( progress | (progress suspend progress) | (progress stalled progress) ) potentially rewritten to progressgrammar = start working (error | abort | done) end working = *( progress | (progress suspend progress) | (progress stalled progress) ) we would only need to change the working rule to accommodate various event firing scenarios. Thus under the same design pattern we could accommodate XHR, HTML5's media API, FileReader and any new DAP API. The event names could be related to the API for naming consistency, but firing model would be pre-defined were possible for design consistency. For example for directory walker (aka File Directory API or File API Level 3: Directories as proposed by Robin) we could have: directorywalkereventgrammar = start working (error | abort | done) end working = *( enterdir *file leavedir ) to be able to walk over e.g. 1M file entries in some FS. Any thoughts? I guess it may be over-engineering, but ... Thanks, 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: Anne van Kesteren [mailto:ann...@opera.com] Sent: Wednesday, November 18, 2009 10:31 AM To: a...@mozilla.com; Marcin Hanclik Cc: WebApps WG; public-device-a...@w3.org Subject: Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com wrote: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events. Without bikeshedding too much, I like your proposal above, but wonder whether we should use the name 'write*' or something else. Since we already have document.write, 'write' is probably the most vetted string to use here :) For what it's worth, for XMLHttpRequest sending events (which are arguably somewhat like write) we still use loadstart/... and simply dispatch them on a distinct object. I've no idea what the file writer API will look like, but I can imagine we might be able to do the same there. -- Anne van Kesteren http://annevankesteren.nl/ 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: DAP and security (was: Rename File API to FileReader API?)
Hi Maciej, From my side I'd like to understand what your thoughts and proposals for file writing security / policy would entail - would you defer the decision responsibility to the user via a prompt? Thanks, David. -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Maciej Stachowiak Sent: 18 November 2009 12:35 To: Marcin Hanclik Cc: Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) OK, I will take your word for it that security is an important consideration for DAP. But while at the TPAC, I heard more than one DAP participant say, when faced with a potential security concern, something like can't we just leave that up to the policy? In one case when I enquired further, at least one DAP member mentioned to me the idea of using some sort of policy file that would take care of all security issues. He suggested this might come from a corporate administrator, and that the format would be XML, but otherwise details were light. To me that seems like a plausible model for something like widgets or browser extensions or walled garden content, but not for sites on the public Web. My apologies if I misinterpreted these remarks or got the wrong impression. One more comment below: On Nov 18, 2009, at 4:18 AM, Marcin Hanclik wrote: +1 APIs - specifically their design - shall be specified tightly with the security model in mind to make them both easy to use and effective. This is what makes the whole task that difficult. Thanks, 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: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org ] On Behalf Of Dominique Hazael-Massieux Sent: Thursday, November 12, 2009 10:30 AM To: Maciej Stachowiak Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: DAP and security (was: Rename File API to FileReader API?) Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit : I would be concerned with leaving file writing to DAP, because a widely held view in DAP seems to be that security can be ignored while designing APIs and added back later with an external policy file mechanism. Frederick already mentioned this isn't the case at all, and I want to strongly reject the notion that DAP is considering security as an after-the-fact or out-of-band aspect in the design of its APIs. Our charter clearly stipulates that our policy model must be consistent with the existing same origin policies (as documented in the HTML5 specification), in the sense that a deployment of the policy model in Web browsers must be possible. It seems to me that for most of DAP's likely deliverables, there are serious security considerations, but the same-origin policy is irrelevant to addressing them. The same-origin policy is designed to protect Web sites from attacks by other Web sites. It does not really apply to access to system resources. Doing that in a Web-safe way will require new inventions or might not even be possible in some cases. In fact, most of models that have been discussed in this thread to reduce the risks exposed by new APIs (sandbox for writing, user interaction or markup-based element for sharing data) were already mentioned as options by DAP WG participants during our F2F last week. More generally, I don't think assuming that DAP would create worse/ less secure APIs than WebApps or any other group would is either right nor useful to ensure a good collaboration between our groups. And clearly, we will actively be seeking feedback and input from the WebApps Working Group when we produce new APIs, which should also contribute to reduce the fears that we would get it all wrong :) Regards, Dom 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] LCWD#3 comments (1)
Hi Marcos, For the purposes of my LC comments, I am satisfied with your response. Thanks, 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, November 18, 2009 1:02 PM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [Widgets] LCWD#3 comments (1) Hi, Marcin! 2009/11/17 Marcin Hanclik marcin.hanc...@access-company.com: Hi, A couple of comments to the latest PC. 7.4 Media type attribute Media type attribute defines the grammar and refers to RFC2045/6. What about referring to RFC4288 that includes the grammar required for MIME registration [1]? (I have no strong opinion about this point, though.) I think I will leave this as is. Numeric attribute For example, the characters 002, 323, 23214 Could be For example, the character strings 002, 323, 23214 Good suggestion, but I changed it to just say the strings... The words character strings would be a tautology. 7.11.1 When an icon element is used, it is required for authors to use the src attribute. Should be an authoring guideline. Fixed. 7.13.1 that a user agent will behave as the required attribute Should be that a user agent will behave as if the required attribute Fixed. Acknowledgments It seems a paragraph is missing there. Fixed. -- 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: [widgets] Test suite: problem with test cases
On 18 Nov 2009, at 12:02, Marcos Caceres wrote: 2009/11/14 Scott Wilson scott.bradley.wil...@gmail.com: woops, fixed. Assertion 34: Test d7, d8 === These test cases both contain badly-formed XML: widget content /widget Presumably these ought to be: widget content/ /widget Fixed and checked in. Thanks - btw you still need to check in the updated .wgt files as well as the config.xml smime.p7s Description: S/MIME cryptographic signature
[widgets] Draft Agenda for 19-Nov-2009 Voice Conf
Below is the draft agenda for the 19 November Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2009/11/12-wam-minutes.html -Regards, Art Barstow Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge:+1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/ member-bin/irc/irc.cgi Confidentiality of minutes: Public Agenda: 1. Review and tweak agenda 2. Announcements a. No Voice Conf on 26 November; next one will be 3 December b. Reminder: last day to request publications for 2009 is Friday 18 December c. Call for Comments: OASIS Packaging spec for ODF for Office Apps: http://www.w3.org/mid/4b016692.2090...@w3.org 3. Packaging and Configuration spec http://dev.w3.org/2006/waf/widgets/ a. LCWD#3 comment period ends 19 November http://www.w3.org/TR/2009/WD-widgets-20091029/ http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-20091029/ b. Discuss LC comments without WG responses (if any) c. CR #2: plans; Call for Consensus to Publish PC CR#2, contingent on comments submitted on or before Nov 19 4. Access Requests Policy (WARP) spec http://dev.w3.org/2006/waf/widgets-access/ a. Patent exclusions by Apple: http://www.w3.org/2004/01/pp-impl/p73 b. Plans for PAG; topic to be led by W3C Team member c. Next steps d. Security model: Robin: http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0745.html Bryan: http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0757.html 5. URI Scheme spec http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ a. Review period ended 10 November; comment tracking: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets- uri-20091008/ 6. AOB
RE: DAP and security (was: Rename File API to FileReader API?)
Hi Maciej, I think that there are many potential oversimplifications when stating that security concerns are to be left to the policy and that a policy file could be a cure to everything. These seem to be just superficial comments from the people who already did related exercise in some implementation. E.g. BONDI spec - input to DAP already in version 1.1 - touches upon the whole problem. OK, I will take your word for it that security is an important consideration for DAP. It is for me after BONDI experience. I cannot speak for the others. The first step is to have the security concerns. The widget environment, BONDI etc. then encode them somehow (e.g. as device capability, feature etc.) creating an abstraction. In case of the browser, those concerns seem to be simply coded in the browser. Still the concerns remain and are handled. The widgets spec try to abstract them in order to give the freedom either to the end user, administrator, operator or any other party. Alternatively they could be simply hard-coded in the webruntime. So the issue is only who is able to specify whether the policy is applied, the concerns are still there. During the TPAC I commented on irc that the policy file is just a representation of the policy, specifically for interchange purposes. It is up to the spec designers whether the concerns are properly reflected in the policy and later in the format/syntax of the policy file. In BONDI we agreed on the format, there is no need for all to comply with that format. No problem with that, but the security concerns are still there and are handled. It seems to me that for most of DAP's likely deliverables, there are serious security considerations, but the same-origin policy is irrelevant to addressing them. The same-origin policy is designed to protect Web sites from attacks by other Web sites. It does not really apply to access to system resources. Doing that in a Web-safe way will require new inventions or might not even be possible in some cases. The origin is a topic in WebApps in the Widgets 1.0 spec, e.g. TWI [1]. We have the issue of the widget instance (e.g. do we allow the same widget be instantiated multiple times, how to synchronize between instances etc.). BONDI specs distinguish additionally between websites and widgets. The same-origin policy is still there. We would potentially like a widget not to be able to act in place of another widget (identity spoofing, for this we need widget URI [2] with authority component). So similarly to same-website/script, we have same-widget policy. Origins are websites and widgets. It may be up to the policy (set by whoever) whether e.g. two widgets or two websites are able to write to the same folder in the FS. In this case, the security concern is: who can write to FS, where actually can it write etc. The realization of these concerns is abstracted in BONDI as: - io.file.read / io.file.write: device capability (abstraction to accommodate various APIs doing file writing / reading) - http://bondi.omtp.org/api/filesystem.read / http://bondi.omtp.org/api/filesystem.write: API feature (api availability, specific for BONDI-defined APIs) - path: parameter to device capability that states the actual path being accessed. Each API has different security concerns, thus there are e.g. different parameters in BONDI. In case of the browser environment, I was personally thinking about something like personal firewall (a tab in the browser settings? ) where the end-user defines the actual policy defaulted by the browser vendor. In walled-garden environments such firewall would be disabled and e.g. the operator would define the policy. The prompts would then depend on the policy and not only on the API being used. There could also be browsers that do not expose the policy settings to the end users. In BONDI there is freedom about that, but still the security concerns are there and are handled. Thanks, Marcin [1] http://dev.w3.org/2006/waf/widgets-api/ [2] http://dev.w3.org/2006/waf/widgets-uri/ 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: Maciej Stachowiak [mailto:m...@apple.com] Sent: Wednesday, November 18, 2009 1:35 PM To: Marcin Hanclik Cc: Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) OK, I will take your word for it that security is an important consideration for DAP. But while at the TPAC, I heard more than one DAP participant say, when faced with a potential security concern, something like can't we just leave that up to the policy? In one case when I enquired further, at least one DAP member mentioned to me the idea of using some sort of policy file that would take care of all security issues. He suggested this might come from a corporate
RE: DAP and security (was: Rename File API to FileReader API?)
Maciej, Security is important in DAP, and should be considered carefully in the context of each API and its use cases. There is no one size fits all solution to security, and that includes approaches based solely upon explicit user action (including explicitly expressed permission via dialogs). The ability to define trust and related policy in a manageable policy document is a necessary *supplement* to the native (API-specific) security methods inherent in API's and their support/influence on the UI. The supplement ensures that the security approach can be tailored to the device in which the webapp is running, supporting a better user experience where reliance upon implicit user action is insufficient. It is however just a supplement that may applied in specific cases, and its use is a deployment decision. BONDI defined such a policy file based upon XACML concepts (this has been provided as input to DAP), and ATT (among others supporting BONDI) considers this to be a valuable option, which complements the API-specific methods. Best regards, Bryan Sullivan | ATT -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Maciej Stachowiak Sent: Wednesday, November 18, 2009 4:35 AM To: Marcin Hanclik Cc: Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) OK, I will take your word for it that security is an important consideration for DAP. But while at the TPAC, I heard more than one DAP participant say, when faced with a potential security concern, something like can't we just leave that up to the policy? In one case when I enquired further, at least one DAP member mentioned to me the idea of using some sort of policy file that would take care of all security issues. He suggested this might come from a corporate administrator, and that the format would be XML, but otherwise details were light. To me that seems like a plausible model for something like widgets or browser extensions or walled garden content, but not for sites on the public Web. My apologies if I misinterpreted these remarks or got the wrong impression. One more comment below: On Nov 18, 2009, at 4:18 AM, Marcin Hanclik wrote: +1 APIs - specifically their design - shall be specified tightly with the security model in mind to make them both easy to use and effective. This is what makes the whole task that difficult. Thanks, 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: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org ] On Behalf Of Dominique Hazael-Massieux Sent: Thursday, November 12, 2009 10:30 AM To: Maciej Stachowiak Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: DAP and security (was: Rename File API to FileReader API?) Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit : I would be concerned with leaving file writing to DAP, because a widely held view in DAP seems to be that security can be ignored while designing APIs and added back later with an external policy file mechanism. Frederick already mentioned this isn't the case at all, and I want to strongly reject the notion that DAP is considering security as an after-the-fact or out-of-band aspect in the design of its APIs. Our charter clearly stipulates that our policy model must be consistent with the existing same origin policies (as documented in the HTML5 specification), in the sense that a deployment of the policy model in Web browsers must be possible. It seems to me that for most of DAP's likely deliverables, there are serious security considerations, but the same-origin policy is irrelevant to addressing them. The same-origin policy is designed to protect Web sites from attacks by other Web sites. It does not really apply to access to system resources. Doing that in a Web-safe way will require new inventions or might not even be possible in some cases. In fact, most of models that have been discussed in this thread to reduce the risks exposed by new APIs (sandbox for writing, user interaction or markup-based element for sharing data) were already mentioned as options by DAP WG participants during our F2F last week. More generally, I don't think assuming that DAP would create worse/ less secure APIs than WebApps or any other group would is either right nor useful to ensure a good collaboration between our groups. And clearly, we will actively be seeking feedback and input from the WebApps Working Group when we produce new APIs, which should also contribute to reduce the fears that we would get it all wrong :) Regards, Dom
Re: [WARP] Comments to WARP spec
Hi Marcin,
On Nov 18, 2009, at 14:37 , Marcin Hanclik wrote:
One could request an
image that is redirected to
http://address/of/image?put+a+complete+script+here
and then evaluate the query.
Ok, but then it will still be processed as image and will result in an
invalid image, I think.
Not so. Consider the following piece of Perl:
#!/usr/bin/perl
print Location: img.png?alert('I am evil!')\n\n;
And the following HTML:
!DOCTYPE html
iframe src='img.pl' id='pl'/iframe
script
window.onload = function () {
eval(unescape(document.getElementById(pl).contentDocument.location.search.substring(1)));
}
/script
This produces the expected alert. No script was ever exchanged, and I get the
image to display perfectly fine.
--
Robin Berjon - http://berjon.com/
Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
On Nov 18, 2009, at 13:13 , Julian Reschke wrote: Robin Berjon wrote: ... Couldn't we just register a URN NID for this? It seems that one has to go through fewer hurdles, and no matter how transient I believe that it's a useful thing to identify. ... Yes, that's possible and probably would cause less eyebrows being raised... It also doesn't seem like a lot of work, registration doesn't require specifying the behaviour of the beast (which we'd leave where it is today). We could take the urn:transient-data NID, or urn:data-handle (whichever way the bike is shed today) and toss a UUID at the end of it; then declare victory. -- Robin Berjon - http://berjon.com/
Re: Blob as URN was Re: [FileAPI] Latest Revision of Editor's Draft
On Tue, Nov 17, 2009 at 6:25 PM, Arun Ranganathan a...@mozilla.com wrote:
Eric,
I recall you saying at TPAC that you wanted to keep the Blob
interface as small as possible, since it seemed likely to get used in
a lot of places. I think that's an excellent goal, but of course,
having said that, I am immediately going to suggest that you add
something to it.
I'm definitely not averse to additions :) Actually, I'm also following the
discussion initiated by Maciej about BinaryData [2] with
public-script-co...@w3.org. Eventually, I believe ECMAScript will provide a
Binary primitive (perhaps ByteArray), and I think Blob should expose that
primitive. This would be a natural extension of what I envision Blob to be
used for. I also envision natural streaming extensions to this API.
How would you feel about exposing a way to produce a URN from a
Blob, instead of just getting one from a File?
I'm not averse to it. In fact, it was originally in the Blob interface
(which at that time, was dubbed FileData). We moved it to the File
interface since the understanding of use cases at the time was that all
URL consumers expect a full file. [3] You've provided use cases that show
that this isn't the case, and so we should revisit our earlier
understanding. More on your use cases below:
This seems likely to
have wide-ranging uses. Pretty much anywhere you have a blob of data,
you might want to hand it off to the browser, even if it didn't come
from, or wasn't, a single user-supplied file. Here are a few use
cases, but I'm sure more won't be hard to come up with:
* Viewing a single chapter of a book in a frame.
* Slicing one episode out of a DVD and handing it to the video tag, so
that the player controls start and end at the episode boundaries.
* Analogous to the game-asset archive I mentioned at [1], one might
pack a number of small files together to speed download [using only
HTTP compression], then parse them apart on the client. Picture a
Picasa client written in the web browser; it's got to handle maybe
1+ thumbnails, and putting each in a separate file would be
terribly inefficient. Pulling down a tarfile would be a lot quicker.
I can understand why you'd want *partial* data exposed through a URL, and
why your API may force a type on the partial data. Question: would a
fragment identifier scheme [4] address any of these use cases, or is this
completely orthogonal to the use cases you envision? I ask because you
envision a chapter within a frame but I'm not sure what the frame data
structure is.
Ah--I think I wasn't clear here. I just pictured taking a file,
chopping out a chapter by, say, byte offset, and writing it into an
iframe for display. I don't think a fragment identifier is powerful
enough, even if we spec out how to overload it. For example, say you
wanted to chop a chapter out of an HTML document *and* scroll your
iframe to a specific page of that chapter?
One can also imagine use cases in which the Blob is constructed
completely from scratch by JavaScript, in which case there's no File
at all.
it
would seem natural to me do to something like this:
interface Blob {
...
DOMString getURN(in DOMString mediaType,
[Optional] in DOMString contentDisposition,
[Optional] in DOMString name);
};
Given that a File that one gets from the user will still tell you its
name and detected mediaType, and can have a constant urn, there seems
to be no conflict in leaving the File interface as-is and adding
something like getURN to Blob. On the off chance that you want to
override the detected mediaType for a file, force a contentDisposition
of attachment, or change the name, you might still use getURN there as
well.
To be clear: you want the File object's URN capabilities to inherit from
Blob, and not be separate, correct? Thus, each Blob has an affiliated URN,
and when a Blob is a File, it uses the Blob's getURN method?
No, I picture both being there, although I'm open to discussion about
it. The getURN method forces the user to specify how the data is to
be presented to the UA via the URN created. In contrast, the urn
property of File is inherently based on what the UA knows about the
file, and the user need not specify anything in order to use it.
Hmm...I guess there's no reason that we couldn't make the mediaType
parameter optional as well, so that in the case of a File getURN could
just return what the UA thought was appropriate. That makes me
nervous for Blob data, though...perhaps we should spec it to throw in
that case?
Can you explain what a contentDisposition is a bit better? Can you write
some psuedo-code showing how contentDisposition is used, perhaps to flesh
out the above use cases?
Sure. Let's say that you're writing an offline version of GMail.
You've got a File referring to an image attachment, and you want to
offer links through which the user can either view
Re: DAP and security (was: Rename File API to FileReader API?)
On Wed, Nov 18, 2009 at 5:27 AM, David Rogers david.rog...@omtp.org wrote: Hi Maciej, From my side I'd like to understand what your thoughts and proposals for file writing security / policy would entail - would you defer the decision responsibility to the user via a prompt? From my point of view the answer is unfortunately there are no simple answers, it's always a judgement call. For example for the geolocation the security model is basically: 1. Page asks for user position 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answers yes then the position is returned to the page. In this case I think this was an acceptable solution. If we added a directory API which gave access to a requested path on the users hard drive we could use a similar security model: 1. Page asks user for permission to read/write to a specific directory, say C:\ 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answeres yes a reference to the directory is returned which the page can read from/write to. This would *not* be an acceptable solution to me, despite being basically identical to the geolocation case. The reason is two-fold. I think it's easier to explain to the user what the user is authorizing (your location), and if a user doesn't understand and still clicks yes, it has less catastrophic results. For the directory API though, it's much harder to explain the decision to the user. What's the C:\ directory? What's the difference between that and C:\Documents and Settings\Jonas Sicking\My Images? What's a directory? Also, if a user clicks yes without understanding the risks, that has catastrophic results if the directory in question is C:\ and read/write access is granted. When it comes to security dialogs, the basic rule to keep in mind is Lots of people are not going to understand it and just click whatever button they think will get stuff to work, or a random button. / Jonas
Re: Let's turn WebDatabase into a WG Note
On Nov 18, 2009, at 2:03 PM, Robert O'Callahan wrote: On Wed, Nov 18, 2009 at 9:35 PM, Maciej Stachowiak m...@apple.com wrote: Further: if the other vendors planning to ship Web Database implementations (Google, Opera What they are going to ship is mostly the same implementation as yours. It sounds like Opera intends to use the same database engine, but I would be very surprised if they used any of our code that implements the API, threading, query management, etc. As I've mentioned before, that is a substantial amount of code, and is the part that implements what the Web Database actually specifies. But I agree that it's premature to abandon WebDatabase. You should have a chance to spec out the SQL dialect. There is negligible risk of anyone significant implementing WebDatabase unaware of the objections. There is a greater risk that authors will come to depend on it because they think it's headed for spec status, but implementations and marketing will encourage that anyway. Some authors have already come to depend on it without really caring about the future or present spec status. I don't think we can stuff that genie back in the bottle. Regards, Maciej
CfC - publish Selectors API as CR
Hi folks, this is a Call for consensus to request publishing the Selectors API draft at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1 as a Candidate Recommendation (assuming Lachy fixes the apparent encoding errors, the incorrect URIs and so on as editorial corrections). The proposed exit criteria are in a separate thread, but essentially are: For a set of tests based on HTML, CSS 2.1 selectors and this spec, there are two implementations that pass every test interoperably, and do not fail any additional tests based on misimplementing this specification (i.e. failures based on not supporting a technology used only in the additional tests, such as MathML, will not be taken into account). Note that the test suite has not been agreed by the Working Group, and will not be required for the transition request. Agreeing on a test suite will be part of the work we have to do before this spec can move futher than CR. Please respond yes or no before the end of Friday 27 November. Silence will be taken as assent, but this call will not be considered to result in a resolution without a reasonable level of positive response. 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: Exit criteria Re: [selectors-api] Transitioning to CR
I'm about to issue a CfC on publishing Selectors as a CR, independent of getting the test suite done. Because it has taken a long time not to get it done, and the result is no CR. We will need to agree on a Test Suite, and on exit criteria. So this message is to see if there is any disagreement. A possible question is whether it counts to have a JS implementation or similar. I think it would be reasonable, so long as it is a completely independent implementation, although I would rather have it *in addition to* native implementations in shipping products. On Wed, 24 Jun 2009 15:56:11 +0200, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Charles McCathieNevile wrote: Actually, based on feedback on the list (thanks Maciej and Robin), and talking to Lachy, we are thinking that we should seperate out the tests that *require* CSS 3 selectors, to make the test suite check implementation of the API, and then require at least two 100% complete and completely interoperable implementations. I believe Lachy will be following up on this about now - both for the list and the test suite. Here is the revised proposal for the exit criteria. * Tested implementations are required to have support for: - Selectors API - Selectors defined in CSS 2.1. - HTML * Tested implementaions may optionally support: - Selectors introduced in Selectors Level 3 - XHTML - SVG At least two implementations must pass 100% of the baseline testsuite and should pass additional tests, dependent on the following conditions: * The baseline testsuite comprises tests that check for conformance to all requirements in the API using only HTML and Selectors defined in CSS 2.1. * Tests using Selectors introduced in Selectors Level 3, or XHTML+SVG, are considered to be additional tests. I wonder if we need to make these additional tests rather than baseline, for the purposes of demonstrating that browsers get this spec right. * An additional test may be marked as N/A for an implementation if: - The test uses a selector that the implementation does not support - The test uses XHTML+SVG that the implementation does not support * Implementations are not required to pass all additional tests, however no failures must be caused by an incorrect implementation of the API itself. Failures of additional tests caused only by an incorrect implementation of Selectors do not count. This implies that the testsuite should be split into several files: I think that at most we should be designating tests as baseline or additional, rather than trying to classify the various kinds of additional files. 1. Baseline containing tests using only HTML and CSS 2.1 2. Additional tests using XHTML+SVG and CSS2.1 (equivalent to the previous test, but with the addition of SVG-related tests) Maybe, maybe not, as per above. 3. Additional tests using HTML and Selectors 3 4. Additional tests using XHTML and Selectors 3 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: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Marcin Hanclik wrote: Hi Anne, XHR still is used also for data retrieval, so it is a kind of border case and I can live with load there :) . Using load for writing to a file will mean that we are stuck with the legacy stuff. load and write pull semantically in the opposite directions, IMHO. I think there is still time to change it in case of FileReader and prepare background for FileWriter. To be clear, IMHO it's absolutely too late for FileReader, and also not desirable. I've already mentioned developer familiarity with onload, etc. and I strongly disagree with changing names in this case. The existing progress events are fine for FileReader. We've also got a beta implementation in place in Fx 3.6. Regarding FileWriter, I'm open to considering new event names, but in general, discussing FileWriter's event model may be putting the cart in front of the horse. Even if we had an event-driven FileWriter, what would it do? We'll need to figure out filesystem access (real or virtual) first! :-) More on this topic in separate email. -- A*
Re: CfC - publish Selectors API as CR
Charles McCathieNevile wrote: Hi folks, this is a Call for consensus to request publishing the Selectors API draft at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1 as a Candidate Recommendation (assuming Lachy fixes the apparent encoding errors, the incorrect URIs and so on as editorial corrections). The encoding errors are caused because you're overriding the encoding with the content-type parameter in the query string. Just change that to UTF-8 and it'll work. http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=UTF-8 I'll make all the necessary editorial changes to get it ready for CR when I find out what the publication date will be. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com wrote: Greetings Marcin, Thanks for the thoughtful feedback. My comments below: In my opinion some part of the design from ProgressEvents is taken over in FileReader API too directly. Specifically the event names are the same as within the ProgressEvents, ... What's in a name? [Floral poetry reference elided :-) ]. You are right to point out that there's some inconsistency in the naming convention. This discussion came up with the discussion of readyState [1] state name changes, when READING was considered as a potential readyState, were it not for consistency with the progress events in question (loadstart, load, loadend... ). We elected to stick to LOADING to match the names of existing progress events with 'load' in them. ... To date, you'll note that progress event nomenclature reflects loading or reading operations, since there are very few write metaphors on the web that have affiliated events bound to them. Actually, this is a false etiology. The naming conventions are based on what people were already implementing (as Robin says, it is often easier to extend the definition than change the term, as linguistics shows us over a far longer history than the Web). If the design of the FileWriter is similar to the design of the FileReader (which is something we're currently working on), then I think your names make sense. I don't actually. We have dumb names, because those are the terms we keep using... and the ones people are used to. Then, the ProgressEvents spec could act as a design pattern definition for lengthy, asynchronous operations. To make it happen, the names of the events there could be changed to be generic: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events Actually, if the argument to keep the names makes sense, then it makes sense, so there is not much point in trying to separate out a bunch of things with a new name. Experience has shown it doesn't usually work anyway. loadstart - start progress stalled suspend error I like the proposal to have a section specific to data transfer and loading, but am wary of splitting specs. Input and feedback from the author of the ProgressEvents specification would be welcome here. The author is the Working Group - and ergo all the members. I'm just the editor. 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: DAP and security (was: Rename File API to FileReader API?)
This is a good point, and an argument for policy rather than implicit user consent, if I'm not mistaken. It highlights that usability might also be an issue with the non-modal interaction model, as well as not always be very meaningful (since I the user might have no idea what most directories are for or where to navigate). Arbitrary directory navigation for writing files is not a good idea. More importantly we have to be careful with analogies. regards, Frederick Frederick Hirsch Nokia On Nov 18, 2009, at 3:14 PM, ext Jonas Sicking wrote: On Wed, Nov 18, 2009 at 5:27 AM, David Rogers david.rog...@omtp.org wrote: Hi Maciej, From my side I'd like to understand what your thoughts and proposals for file writing security / policy would entail - would you defer the decision responsibility to the user via a prompt? From my point of view the answer is unfortunately there are no simple answers, it's always a judgement call. For example for the geolocation the security model is basically: 1. Page asks for user position 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answers yes then the position is returned to the page. In this case I think this was an acceptable solution. If we added a directory API which gave access to a requested path on the users hard drive we could use a similar security model: 1. Page asks user for permission to read/write to a specific directory, say C:\ 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answeres yes a reference to the directory is returned which the page can read from/write to. This would *not* be an acceptable solution to me, despite being basically identical to the geolocation case. The reason is two-fold. I think it's easier to explain to the user what the user is authorizing (your location), and if a user doesn't understand and still clicks yes, it has less catastrophic results. For the directory API though, it's much harder to explain the decision to the user. What's the C:\ directory? What's the difference between that and C:\Documents and Settings\Jonas Sicking\My Images? What's a directory? Also, if a user clicks yes without understanding the risks, that has catastrophic results if the directory in question is C:\ and read/write access is granted. When it comes to security dialogs, the basic rule to keep in mind is Lots of people are not going to understand it and just click whatever button they think will get stuff to work, or a random button. / Jonas
Re: DAP and security (was: Rename File API to FileReader API?)
On Nov 18, 2009, at 5:13 PM, Frederick Hirsch wrote: This is a good point, and an argument for policy rather than implicit user consent, if I'm not mistaken. It highlights that usability might also be an issue with the non-modal interaction model, as well as not always be very meaningful (since I the user might have no idea what most directories are for or where to navigate). Arbitrary directory navigation for writing files is not a good idea. policy is not a solution to the scenario Jonas posted either. Who is going to define a home PC or Mac user's browser policy? The user doesn't have the expertise to do it. There's no sysadmin to do it for them. And browser/OS vendors should not be in the game of whitelisting a specific set of sites for extra access. Regards, Maciej More importantly we have to be careful with analogies. regards, Frederick Frederick Hirsch Nokia On Nov 18, 2009, at 3:14 PM, ext Jonas Sicking wrote: On Wed, Nov 18, 2009 at 5:27 AM, David Rogers david.rog...@omtp.org wrote: Hi Maciej, From my side I'd like to understand what your thoughts and proposals for file writing security / policy would entail - would you defer the decision responsibility to the user via a prompt? From my point of view the answer is unfortunately there are no simple answers, it's always a judgement call. For example for the geolocation the security model is basically: 1. Page asks for user position 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answers yes then the position is returned to the page. In this case I think this was an acceptable solution. If we added a directory API which gave access to a requested path on the users hard drive we could use a similar security model: 1. Page asks user for permission to read/write to a specific directory, say C:\ 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answeres yes a reference to the directory is returned which the page can read from/write to. This would *not* be an acceptable solution to me, despite being basically identical to the geolocation case. The reason is two-fold. I think it's easier to explain to the user what the user is authorizing (your location), and if a user doesn't understand and still clicks yes, it has less catastrophic results. For the directory API though, it's much harder to explain the decision to the user. What's the C:\ directory? What's the difference between that and C:\Documents and Settings\Jonas Sicking\My Images? What's a directory? Also, if a user clicks yes without understanding the risks, that has catastrophic results if the directory in question is C:\ and read/write access is granted. When it comes to security dialogs, the basic rule to keep in mind is Lots of people are not going to understand it and just click whatever button they think will get stuff to work, or a random button. / Jonas
