Re: Transferring File* to WebApps - redux
On Fri, Jun 18, 2010 at 10:53 AM, SULLIVAN, BRYAN L (ATTCINW) wrote: > Eric, > Based upon your responses there are a couple of additional things we > need to check on, but I'll look deeper into the current specs for the > things that should already be supported. > > The additional things are: > > - how to safely grant access "outside the sandbox", which depends upon > ability to discover available file systems in persistent storage and > select arbitrary locations within them. We would prefer that this > functional capability is addressed within the File* APIs directly rather > than through an extension API in DAP, thus we may propose two additional > methods for the LocalFilesystem interface: > getDefaultLocation: as from > http://bondi.omtp.org/1.1/apis/filesystem.html#getDefaultLocationN101E4 > getRootLocations: as from > http://bondi.omtp.org/1.1/apis/filesystem.html#getRootLocationsN10253 > These methods can be covered under the general one-time prompt approach > or under the policy approach (once we have worked out how the File* APIs > are covered under that, e.g. by association of widget feature URIs). Given that these methods would have security implications well beyond the current spec, I'd prefer to have them added in a later pass, either in an extension spec or in a later version of the filesystem spec. We've got enough to argue about in there already, and if we try to do too much in one pass, we'll bog down. These certainly look like logical extensions to what we've been discussing, though. > - clarify the difference between "memory" and "persistent storage": "In > memory" usually means the content is in the working RAM of a device. The > File* specs talk about working with files "in memory" which I take to > mean that the file has been read from persistent storage into the > working memory of the browser (upon selection by the user), and is being > read or updated (with presumed writing back to persistent storage > later). The different may be subtle but is important. If what's meant > instead of a file copy "in memory" is that the webapp can *directly* > access/update a file in persistent storage, then I suggest the spec > terminology be updated to make that clear. Arun: in 5.4 and 5.5.1, I think you want to change "in memory" to "into memory" to match the other 15-or-so instances of that phrase in the spec. Bryan, is that sufficient? > Thanks, > Bryan Sullivan | AT&T > > > -Original Message- > From: Eric Uhrhane [mailto:er...@google.com] > Sent: Wednesday, June 16, 2010 4:42 PM > To: SULLIVAN, BRYAN L (ATTCINW) > Cc: a...@mozilla.com; Robin Berjon; public-device-a...@w3.org; Ian > Fette; Web Applications Working Group WG > Subject: Re: Transferring File* to WebApps - redux > > Sorry about the delay in response; I've been out of the office for the > past 10 days. [Also, sorry Bryan--I forgot to reply-all.] > > On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) > wrote: >> I am not meaning to be unfair, perhaps the message is not coming > through >> clearly enough. >> >> There are specific technical requirements that we need these APIs to >> fulfill, that I indicated to Thomas in another email: >> 1) access filesystems on the host device > > FileSystem/FileWriter/FileReader do this. > >> 2) traverse directories > > FileSystem does this. Currently it's only specced to do so within a > per-origin sandbox, but the API could be used outside the sandbox if > another spec defined a mechanism to grant such access safely. > >> 3) read files as they exist on the filesystem (not just a local >> representation in memory, as currently defined in the File API to my >> understanding), in bytes and lines > > FileReader does this [not sure what you mean about a local > representation--if you can read an on-disk file, you're doing so via > memory]. > >> 4) write files (similar requirement to write directly to the >> filesystem), in bytes and lines, with overwrite and append options > > FileSystem/FileWriter do this [details of appending still being hammered > out]. > >> 5) do the above programmatically in Javascript (not dependent just > upon >> user selection of an input element and interaction with a file > selector) > > FileSystem does this. And no, there's no need for the UA to prompt > the user on each access; permissions should be more on the order of > "can access temporary filesystem storage" and "can access persistent > filesystem storage", and need only be granted once. > >> 6) provide security for this using the policy-framework approach as >> being defined for DAP APIs > > This remains for DAP to work out. It should be fairly straightforward > to add a policy-based mechanism to grant access to FileSystem APIs > [e.g. your example "documents" folder, via resolveLocalFilesystemURI, > mentioned elsewhere in this thread]. > > Thanks, > > Eric >
RE: Transferring File* to WebApps - redux
Eric, Based upon your responses there are a couple of additional things we need to check on, but I'll look deeper into the current specs for the things that should already be supported. The additional things are: - how to safely grant access "outside the sandbox", which depends upon ability to discover available file systems in persistent storage and select arbitrary locations within them. We would prefer that this functional capability is addressed within the File* APIs directly rather than through an extension API in DAP, thus we may propose two additional methods for the LocalFilesystem interface: getDefaultLocation: as from http://bondi.omtp.org/1.1/apis/filesystem.html#getDefaultLocationN101E4 getRootLocations: as from http://bondi.omtp.org/1.1/apis/filesystem.html#getRootLocationsN10253 These methods can be covered under the general one-time prompt approach or under the policy approach (once we have worked out how the File* APIs are covered under that, e.g. by association of widget feature URIs). - clarify the difference between "memory" and "persistent storage": "In memory" usually means the content is in the working RAM of a device. The File* specs talk about working with files "in memory" which I take to mean that the file has been read from persistent storage into the working memory of the browser (upon selection by the user), and is being read or updated (with presumed writing back to persistent storage later). The different may be subtle but is important. If what's meant instead of a file copy "in memory" is that the webapp can *directly* access/update a file in persistent storage, then I suggest the spec terminology be updated to make that clear. Thanks, Bryan Sullivan | AT&T -Original Message- From: Eric Uhrhane [mailto:er...@google.com] Sent: Wednesday, June 16, 2010 4:42 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: a...@mozilla.com; Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux Sorry about the delay in response; I've been out of the office for the past 10 days. [Also, sorry Bryan--I forgot to reply-all.] On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > I am not meaning to be unfair, perhaps the message is not coming through > clearly enough. > > There are specific technical requirements that we need these APIs to > fulfill, that I indicated to Thomas in another email: > 1) access filesystems on the host device FileSystem/FileWriter/FileReader do this. > 2) traverse directories FileSystem does this. Currently it's only specced to do so within a per-origin sandbox, but the API could be used outside the sandbox if another spec defined a mechanism to grant such access safely. > 3) read files as they exist on the filesystem (not just a local > representation in memory, as currently defined in the File API to my > understanding), in bytes and lines FileReader does this [not sure what you mean about a local representation--if you can read an on-disk file, you're doing so via memory]. > 4) write files (similar requirement to write directly to the > filesystem), in bytes and lines, with overwrite and append options FileSystem/FileWriter do this [details of appending still being hammered out]. > 5) do the above programmatically in Javascript (not dependent just upon > user selection of an input element and interaction with a file selector) FileSystem does this. And no, there's no need for the UA to prompt the user on each access; permissions should be more on the order of "can access temporary filesystem storage" and "can access persistent filesystem storage", and need only be granted once. > 6) provide security for this using the policy-framework approach as > being defined for DAP APIs This remains for DAP to work out. It should be fairly straightforward to add a policy-based mechanism to grant access to FileSystem APIs [e.g. your example "documents" folder, via resolveLocalFilesystemURI, mentioned elsewhere in this thread]. Thanks, Eric
Re: Transferring File* to WebApps - redux
Sorry about the delay in response; I've been out of the office for the past 10 days. [Also, sorry Bryan--I forgot to reply-all.] On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > I am not meaning to be unfair, perhaps the message is not coming through > clearly enough. > > There are specific technical requirements that we need these APIs to > fulfill, that I indicated to Thomas in another email: > 1) access filesystems on the host device FileSystem/FileWriter/FileReader do this. > 2) traverse directories FileSystem does this. Currently it's only specced to do so within a per-origin sandbox, but the API could be used outside the sandbox if another spec defined a mechanism to grant such access safely. > 3) read files as they exist on the filesystem (not just a local > representation in memory, as currently defined in the File API to my > understanding), in bytes and lines FileReader does this [not sure what you mean about a local representation--if you can read an on-disk file, you're doing so via memory]. > 4) write files (similar requirement to write directly to the > filesystem), in bytes and lines, with overwrite and append options FileSystem/FileWriter do this [details of appending still being hammered out]. > 5) do the above programmatically in Javascript (not dependent just upon > user selection of an input element and interaction with a file selector) FileSystem does this. And no, there's no need for the UA to prompt the user on each access; permissions should be more on the order of "can access temporary filesystem storage" and "can access persistent filesystem storage", and need only be granted once. > 6) provide security for this using the policy-framework approach as > being defined for DAP APIs This remains for DAP to work out. It should be fairly straightforward to add a policy-based mechanism to grant access to FileSystem APIs [e.g. your example "documents" folder, via resolveLocalFilesystemURI, mentioned elsewhere in this thread]. Thanks, Eric
Re: Transferring File* to WebApps - redux
On 6/16/10 12:59 PM, David Rogers wrote: [DAVID] I was actually referring to: http://dev.w3.org/2009/dap/privacy-reqs/ (As mentioned in previous correspondence, I think securing an API and privacy can be decoupled, but both are very relevant topics). I've read that document and think that much of it is reasonable (the first section matches the section in the licensing document, which I thought was reasonable), but I strongly disagree with the explicit vs. implicit reasoning here. You say: "D evice APIs may also be defined such that consent must be explicit, not implicit. Examples are a camera API that takes a photograph without user involvement, or a messaging API that sends a message without the user pressing "send." In these cases dialogs may be required." A Camera API that takes a photograph without user involvement seems like something that is risky to build into web content, and I'm not sure I totally understand the use case behind it. Earlier email threads have raised the issue of the policy-file based security model. While you say dialogs 'may' be required, you also make a case for not overwhelming the use with dialogs. This isn't as clear as it could be. Bryan's email -- http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1050.html -- gives a good explanation of points where it may make sense to specify additions to the API. Robin's email -- http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1055.html -- proposes a layered approach in the File* context which makes sense, namely layering into the existing File model additional features that cross the current sandbox. and yes I don't want to pre-judge the outcome of the workshop but we all pretty much acknowledge that there are privacy issues we need to deal with and that the design of any the work we're doing here should take it into account (in the same way as security). The whole basis of establishing the DAP working group was to protect the consumer and improve on the current status quo. Like you, I'm not precious about where things live, but I just want to make sure that if the file related APIs go into webapps that we can continue in that spirit, not just forget all that - otherwise there is no point and you won't see take-up of the API in the long-term because it would be too risky. As I said before, there is no value in creating a schism here, it would create more problems for W3C as a community and is absolutely needless. I think privacy is important. I think security is important. I think wherever work is done, both should be respected. 2) Also, please can you outline the security model that you will propose if it does transfer to WebApps - would it allow for management of access to the file system by policy (in the BONDI manner or by Google Powerbox or Mozilla's separate policy scheme)? If so, the security model (which needs more work and shouldn't be considered final by any means) probably shouldn't be based on policy schemes like BONDI's policy language. I'm not sure yet what to make of PowerBox, but I'm personally not considering it in this regard. There isn't a separate Mozilla policy scheme, but the same-origin scheme for scripts and the separation of chrome content and web content is applicable here. [DAVID] So I'll take that as an agreement that we need to address the security model properly before we can progress. Can we work together to achieve this? Certainly. If you have concerns about security (or privacy) in any WebApps API, you should share these on the listserv. 3) Would your proposed API require prompts to the user and explicit user acceptance of some sort? *Which* proposed API? The File API (covering FileReader) already uses the existing selection mechanism via input elements, and is shipping in Firefox 3.6.3. This does have explicit user acceptance, but this model has already been around in the web for interacting with file systems. We should secure this model further in lieu of proposing a new one. So, earlier proposals for spawning a script-only FileDialog were abandoned. [DAVID] Yes agreed, so this is where OMTP and Google are coming from - we need to deal with this issue head-on. How would you propose to deal with file writing if you need explicit user acceptance - bombard the user with prompts? It doesn't and can't work and is an out-of-date mechanism that has been abused for years via social engineering and technical means. Users end up having to download applications to do this sort of stuff now for picture uploading etc. Let's try and tackle it together and come up with a decent solution, but first we need to agree that these issues will be properly taken into consideration if file writing moves over from DAP. The user shouldn't be bombarded with prompts, nor should user notification be bypassed. You've identified an important issue,
RE: Transferring File* to WebApps - redux
Hi Arun, -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: 16 June 2010 19:48 On 6/16/10 2:16 AM, David Rogers wrote: > >> The question of where you are represented and your ability to >> participate cuts both ways - the same is true for us. I think if the >> browser vendors want their products really to be seen as compatible >> > with > >> the Web application space (as compared to just dynamic Web pages), >> > they > >> will support the work in DAP as its there that non-obtrusive and >> inherently secure models for Web application access to device >> > resources > >> will be defined as APIs. >> >> > At present time, I think that the paragraph above accurately summarizes > a technical rift between certain members of both working groups (DAP and > > WebApps). It may not be worthwhile to resolve this rift, and we should > allow disparate families of specifications to bloom, taking care not to > cause developer confusion with naming (a hard problem). Where > specifications worked on in the DAP WG lend themselves to implementation > > plans, I think Mozilla participants interested in these can comment on > them (e.g. Contacts API, at least for now). > > [DAVID] I don't think it is worth creating a schism. The file API hadn't > been touched since 2006 when we started looking at this work so it is > good that we have managed to help motivate some further work on it. A > number of browser vendors are involved in DAP and are starting to build > DAP APIs so I think this might be an incorrect assumption too. We're all > in this together, so let's try and get it right for the user. > > The key question remains around security model. OMTP members believe in > separating policy for good security reasons and to advance the general > discipline away from the natural answer which would be 'provide a prompt > or explicit user interaction'. If we slip back into this old way of > thinking, we are destined for failure. Yes, at some point you need user > interaction but let's try to minimise that in an intelligent manner > which means that the user is not bombarded with prompts, making the > system less secure. So, some questions from me: > > 1) I want to make sure that we can continue the good privacy work that > has been started in DAP - please can you clarify if you would propose > adopting those requirements if transferred to WebApps? > I think you are referring to: http://dev.w3.org/2009/dap/docs/privacy-license.html . Is that correct? If so, that's a document that seems like a really good start. There's an upcoming workshop on this subject for which Aza Raskin has submitted a paper which also posits a "license" style model, but couples it with easy user-readable icons. I don't mind where general privacy guidelines live. I think what's wise is to allow for maximum browser vendor review, but additional charter items on WebApps is hard. I think we can review sensible privacy guidelines wherever they live; they don't have to be transferred, but widespread review is desirable. It might be useful to decouple privacy from a secure model for APIs. [DAVID] I was actually referring to: http://dev.w3.org/2009/dap/privacy-reqs/ and yes I don't want to pre-judge the outcome of the workshop but we all pretty much acknowledge that there are privacy issues we need to deal with and that the design of any the work we're doing here should take it into account (in the same way as security). The whole basis of establishing the DAP working group was to protect the consumer and improve on the current status quo. Like you, I'm not precious about where things live, but I just want to make sure that if the file related APIs go into webapps that we can continue in that spirit, not just forget all that - otherwise there is no point and you won't see take-up of the API in the long-term because it would be too risky. As I said before, there is no value in creating a schism here, it would create more problems for W3C as a community and is absolutely needless. > 2) Also, please can you outline the security model that you will propose > if it does transfer to WebApps - would it allow for management of access > to the file system by policy (in the BONDI manner or by Google Powerbox > or Mozilla's separate policy scheme)? > Are you talking about the email Robin sent about transferring FileWriter and FileSystem over to WebApps? [DAVID] Yes, that is what this whole message thread is about. If so, the security model (which needs more work and shouldn't be considered final by any means) probably shouldn't be based on policy schemes like BONDI's policy language. I'm not sure yet what to make of PowerBox, but I'm personally not considering it in this regard. There isn't a separate Mozilla policy scheme, but the same-origin scheme for scripts and the separation of chrome content and web content is applicable here. [DAVID] So I'll take that as an
Re: Transferring File* to WebApps - redux
Hi David, Thanks for your questions. On 6/16/10 2:16 AM, David Rogers wrote: The question of where you are represented and your ability to participate cuts both ways - the same is true for us. I think if the browser vendors want their products really to be seen as compatible with the Web application space (as compared to just dynamic Web pages), they will support the work in DAP as its there that non-obtrusive and inherently secure models for Web application access to device resources will be defined as APIs. At present time, I think that the paragraph above accurately summarizes a technical rift between certain members of both working groups (DAP and WebApps). It may not be worthwhile to resolve this rift, and we should allow disparate families of specifications to bloom, taking care not to cause developer confusion with naming (a hard problem). Where specifications worked on in the DAP WG lend themselves to implementation plans, I think Mozilla participants interested in these can comment on them (e.g. Contacts API, at least for now). [DAVID] I don't think it is worth creating a schism. The file API hadn't been touched since 2006 when we started looking at this work so it is good that we have managed to help motivate some further work on it. A number of browser vendors are involved in DAP and are starting to build DAP APIs so I think this might be an incorrect assumption too. We're all in this together, so let's try and get it right for the user. The key question remains around security model. OMTP members believe in separating policy for good security reasons and to advance the general discipline away from the natural answer which would be 'provide a prompt or explicit user interaction'. If we slip back into this old way of thinking, we are destined for failure. Yes, at some point you need user interaction but let's try to minimise that in an intelligent manner which means that the user is not bombarded with prompts, making the system less secure. So, some questions from me: 1) I want to make sure that we can continue the good privacy work that has been started in DAP - please can you clarify if you would propose adopting those requirements if transferred to WebApps? I think you are referring to: http://dev.w3.org/2009/dap/docs/privacy-license.html . Is that correct? If so, that's a document that seems like a really good start. There's an upcoming workshop on this subject for which Aza Raskin has submitted a paper which also posits a "license" style model, but couples it with easy user-readable icons. I don't mind where general privacy guidelines live. I think what's wise is to allow for maximum browser vendor review, but additional charter items on WebApps is hard. I think we can review sensible privacy guidelines wherever they live; they don't have to be transferred, but widespread review is desirable. It might be useful to decouple privacy from a secure model for APIs. 2) Also, please can you outline the security model that you will propose if it does transfer to WebApps - would it allow for management of access to the file system by policy (in the BONDI manner or by Google Powerbox or Mozilla's separate policy scheme)? Are you talking about the email Robin sent about transferring FileWriter and FileSystem over to WebApps? If so, the security model (which needs more work and shouldn't be considered final by any means) probably shouldn't be based on policy schemes like BONDI's policy language. I'm not sure yet what to make of PowerBox, but I'm personally not considering it in this regard. There isn't a separate Mozilla policy scheme, but the same-origin scheme for scripts and the separation of chrome content and web content is applicable here. 3) Would your proposed API require prompts to the user and explicit user acceptance of some sort? *Which* proposed API? The File API (covering FileReader) already uses the existing selection mechanism via input elements, and is shipping in Firefox 3.6.3. This does have explicit user acceptance, but this model has already been around in the web for interacting with file systems. We should secure this model further in lieu of proposing a new one. So, earlier proposals for spawning a script-only FileDialog were abandoned. -- A*
Re: Transferring File* to WebApps - redux
er-agent. Interaction with data sources from the application would all be through ecmascript (xhr/xdr) and be RESTful in nature, these data sources would not be from the same origin (as I only made the app, not the data), rather it would pull from the web of data. I would like the user to be able to any files they liked, however these files would be exposed through HTTP and addressed with URIs, I care not for some file access api but would rather see the focus go in to exposing peoples resources through http. I'd want any personally identifiable information to always be sent over secure channels [http+tls], and any sensitive resources to be accessed via http+tls, access to that resource should be determined by the server, but this can only be done if the person is also identified, thus a client side certificate with a unique identifier for the person would have to be presented in the http+tls session. And finally, but most importantly, I'd like this application to run on any device and in any user-agent that supports html5 and ecmascript, after all, why shouldn't this be possible? What we all need, and want, is just a way to create an application, wrap it up and know that whoever wants to can run it on whatever device (and in whatever ua) they please - this isn't a pipe dream, and everything needed already exists - it just needs pieced together and for you guys to adopt + promote. Apologies for the length of the mail, but you know.. had to say it.. Best, Nathan SULLIVAN, BRYAN L (ATTCINW) wrote: Arun, The basic concern I have is with the notion of "browsers" as the only Web context and use-case that matters. The browser-based model for API integration view (as I understand your position) is that the user must be actively involved in every significant action, and choose explicitly the actions that enable integration with browser-external resources (including local and remote). Step back and you will see the inconsistency in that (what would Ajax be if the user had to approved every HTTP API request via an element?). Webapps are much more than just dynamic Web pages. They are applications, and with HTML5 will have the ability to rival desktop applications, as is clearly the vision of many in the industry. It might even enable a return to a thin client world (e.g. browser as OS) in which most significant resources are cloud-based. I see the logic and value in that, but it's not the only valid (and valuable) model. W3C focuses on the Web, and the Web is bigger than the browser use-case. HTML5 and the APIs that attach HTML-based applications to the world can actually be the application platform for the next era of the Web, but only if we do not limit the options to the user-centric/control paradigms of the past. Thanks, Bryan Sullivan | AT&T -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Tuesday, June 15, 2010 1:48 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On 6/15/10 1:15 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: We would not be in favor of this transfer. We believe this API needs to be developed in the DAP group, as our vision for its functionality was driven by the input from BONDI and in general as a *device* API (as compared to an abstracted API for cloud-based file resources), and we do not believe that vision will be fulfilled if this work is transferred to Webapps. The BONDI API isn't a good starting place for an API that can be built into web browsers, since it doesn't gracefully layer into the existing HTML input element model for file selection. You are making a distinction I don't understand clearly, since we're not really considering "cloud-based file resources" with the FileReader API. Rather, we are considering file resources resident on the device. The API allows you to select them using an input element, and then access the file resource and programmatically manipulate it as a Blob. Similarly, the FileWriter API allows you to use the "save as" channel to write to the device in question. The FileSystem specification posits an abstraction that isn't necessarily "cloud-based" (although FWIW that is also possible). If you have a different vision, then that vision is incompatible with web browsers. In this case, I'd encourage the DAP WG, which *also* has a charter to work on file system deliverables, to construct an API which matches the use case you have in mind. You may then pursue the relevant BONDI API, which as a browser vendor I cannot consider. If the issue is the level of discussion in this group, that can be addressed. For one, I have seen quite a lot of traffic on the DAP email list about this, so I don't understand the question of activity.
RE: Transferring File* to WebApps - redux
> The question of where you are represented and your ability to > participate cuts both ways - the same is true for us. I think if the > browser vendors want their products really to be seen as compatible with > the Web application space (as compared to just dynamic Web pages), they > will support the work in DAP as its there that non-obtrusive and > inherently secure models for Web application access to device resources > will be defined as APIs. > At present time, I think that the paragraph above accurately summarizes a technical rift between certain members of both working groups (DAP and WebApps). It may not be worthwhile to resolve this rift, and we should allow disparate families of specifications to bloom, taking care not to cause developer confusion with naming (a hard problem). Where specifications worked on in the DAP WG lend themselves to implementation plans, I think Mozilla participants interested in these can comment on them (e.g. Contacts API, at least for now). [DAVID] I don't think it is worth creating a schism. The file API hadn't been touched since 2006 when we started looking at this work so it is good that we have managed to help motivate some further work on it. A number of browser vendors are involved in DAP and are starting to build DAP APIs so I think this might be an incorrect assumption too. We're all in this together, so let's try and get it right for the user. The key question remains around security model. OMTP members believe in separating policy for good security reasons and to advance the general discipline away from the natural answer which would be 'provide a prompt or explicit user interaction'. If we slip back into this old way of thinking, we are destined for failure. Yes, at some point you need user interaction but let's try to minimise that in an intelligent manner which means that the user is not bombarded with prompts, making the system less secure. So, some questions from me: 1) I want to make sure that we can continue the good privacy work that has been started in DAP - please can you clarify if you would propose adopting those requirements if transferred to WebApps? 2) Also, please can you outline the security model that you will propose if it does transfer to WebApps - would it allow for management of access to the file system by policy (in the BONDI manner or by Google Powerbox or Mozilla's separate policy scheme)? 3) Would your proposed API require prompts to the user and explicit user acceptance of some sort? Thanks, David.
RE: Transferring File* to WebApps - redux
Mike, To be clear - I'm not saying that the current File* APIs are poorly designed or that they won't be useful. As I have read through them I agree there is a lot of the functionality that we are looking for in them and we appreciate the effort it took to create them, even though they are different from the BONDI API (there are many good ways to design such things). Extending them will be one option if we can't resolve the gaps in the APIs directly. But if we can count on a couple of key things then in the interest of having a single API for developers to use, I would agree we should focus on these APIs and see how far they can take us: 1) An app can use resolveLocalFilesystemURI directly to resolve a generic filesystem URI, e.g. "documents", "pictures", "videos", "music" (we can create a normative set of these), or some other URI that is known to be supported by the device (which is itself known for example through the System Info API), e.g. file://home/user . Alternatively we can extend the LocalFilesystem interface with a getRootLocations method ala the BONDI filesystem API. 2) Access to resolveLocalFilesystemURI can be defined in policy (the resolve method can have an assigned feature URI used in widget config and policy documents), thus the user does not have to be prompted (if the app is trusted) or the element used. Note that the alternatives requestPersistentFilesystem and requestTemporaryFilesystem are quite useful also, and may support the majority of use cases anyway. Thanks, Bryan Sullivan | AT&T From: Mike Clement [mailto:mi...@google.com] Sent: Tuesday, June 15, 2010 4:40 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: a...@mozilla.com; Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux As I understand it, #5 (programmatic access to files without user interaction) is indeed supported via the getFile method. But again, this is only within the sandboxed filesystem, not for an arbitrary file on the device. As for #6, I can't speak to the "policy-framework approach", but I do know that the security provisions for manipulating files with regards to JavaScript will be the usual same-origin policy. --mike On Tue, Jun 15, 2010 at 3:55 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: Actually I think "sandboxing" an app into a certain area of the filesystem, especially for less-trusted apps, is a useful model. But I don't think the current File* APIs will support the items 5-6 that I mention below. 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs In BONDI, it's possible to define the sandbox as policy and avoid the user needing to select it. For example it's possible to restrict an application to: * a "temp" filesystem location (whatever that maps to on the current device) * other "well-known" filesystem locations * browser-internal storage (e.g. localstorage) Thanks, Bryan Sullivan | AT&T From: Mike Clement [mailto:mi...@google.com] Sent: Tuesday, June 15, 2010 3:42 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: a...@mozilla.com; Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux Hi, Am I correct in thinking that what you find too restrictive is that the FileSystem API only allows programmatic access to a sandboxed portion of the device's filesystem instead of the entire filesystem? Otherwise, I believe that the File APIs as a whole will allow most of the other operations you mention. --mike On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: Arun, I am not meaning to be unfair, perhaps the message is not coming through clearly enough. There are specific technical requirements that we need these APIs to fulfill, that I indicated to Thomas in another email: 1) access filesystems on the host device 2) traverse directories 3) read files as they exist on the filesystem (not just a local representation in memory, as currently defined in the File API to my understanding), in bytes and lines 4) write files (similar requirement to write directly to the filesystem), in bytes and lines, with overwrite and append options 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs Apart from the details of (1-4) above, which will help ensure are addressed in the current File* APIs (no matter where they are finished),I think it's (5
Re: Transferring File* to WebApps - redux
As I understand it, #5 (programmatic access to files without user interaction) is indeed supported via the getFile method. But again, this is only within the sandboxed filesystem, not for an arbitrary file on the device. As for #6, I can't speak to the "policy-framework approach", but I do know that the security provisions for manipulating files with regards to JavaScript will be the usual same-origin policy. --mike On Tue, Jun 15, 2010 at 3:55 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > Actually I think “sandboxing” an app into a certain area of the > filesystem, especially for less-trusted apps, is a useful model. But I don’t > think the current File* APIs will support the items 5-6 that I mention > below. > > 5) do the above programmatically in Javascript (not dependent just upon > user selection of an input element and interaction with a file selector) > > 6) provide security for this using the policy-framework approach as being > defined for DAP APIs > > > > In BONDI, it’s possible to define the sandbox as policy and avoid the user > needing to select it. For example it’s possible to restrict an application > to: > > · a “temp” filesystem location (whatever that maps to on the > current device) > > · other “well-known” filesystem locations > > · browser-internal storage (e.g. localstorage) > > > > Thanks, > > Bryan Sullivan | AT&T > > > > *From:* Mike Clement [mailto:mi...@google.com] > *Sent:* Tuesday, June 15, 2010 3:42 PM > > *To:* SULLIVAN, BRYAN L (ATTCINW) > *Cc:* a...@mozilla.com; Robin Berjon; public-device-a...@w3.org; Ian > Fette; Web Applications Working Group WG > > *Subject:* Re: Transferring File* to WebApps - redux > > > > Hi, > > > > Am I correct in thinking that what you find too restrictive is that the > FileSystem API only allows programmatic access to a sandboxed portion of the > device's filesystem instead of the entire filesystem? Otherwise, I believe > that the File APIs as a whole will allow most of the other operations you > mention. > > > > --mike > > On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) < > bs3...@att.com> wrote: > > Arun, > > I am not meaning to be unfair, perhaps the message is not coming through > clearly enough. > > There are specific technical requirements that we need these APIs to > fulfill, that I indicated to Thomas in another email: > 1) access filesystems on the host device > 2) traverse directories > 3) read files as they exist on the filesystem (not just a local > > representation in memory, as currently defined in the File API to my > understanding), in bytes and lines > > 4) write files (similar requirement to write directly to the > > filesystem), in bytes and lines, with overwrite and append options > > 5) do the above programmatically in Javascript (not dependent just upon > > user selection of an input element and interaction with a file selector) > > 6) provide security for this using the policy-framework approach as > > being defined for DAP APIs > > Apart from the details of (1-4) above, which will help ensure are > addressed in the current File* APIs (no matter where they are > finished),I think it's (5-6) where the real differences are. If we need > another API in DAP to address them, then AT&T will help ensure it gets > done separately from the current File* APIs. > > The question of where you are represented and your ability to > participate cuts both ways - the same is true for us. I think if the > browser vendors want their products really to be seen as compatible with > the Web application space (as compared to just dynamic Web pages), they > will support the work in DAP as its there that non-obtrusive and > inherently secure models for Web application access to device resources > will be defined as APIs. > > > Thanks, > Bryan Sullivan | AT&T > > > -Original Message- > From: Arun Ranganathan [mailto:a...@mozilla.com] > > Sent: Tuesday, June 15, 2010 2:53 PM > To: SULLIVAN, BRYAN L (ATTCINW) > Cc: Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications > Working Group WG > Subject: Re: Transferring File* to WebApps - redux > > On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > > Arun, > > > > The basic concern I have is with the notion of "browsers" as the only > > Web context and use-case that matters. The browser-based model for API > > integration view (as I understand your position) is that the user must > > be actively involved in every significant action, and choose > explicitly > > the actions that enable integration with br
Re: Transferring File* to WebApps - redux
Bryan, On 6/15/10 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs I agree with you that those goals are incompatible with the File* APIs as they are currently evolving (although perhaps you can use these as the basis for interfaces and signatures, and swap out the invocation paradigm and the security paradigm separately within the W3C DAP WG). That being the case, let's agree to having separate DAP-oriented file APIs that address those particular use cases. I think that we agree that the FileWriter and FileSystem APIs as currently written (and with the current editor, Eric Uhrane) can move to WebApps, where they can evolve along with the existing File API specification. Apart from the details of (1-4) above, which will help ensure are addressed in the current File* APIs (no matter where they are finished),I think it's (5-6) where the real differences are. If we need another API in DAP to address them, then AT&T will help ensure it gets done separately from the current File* APIs. The question of where you are represented and your ability to participate cuts both ways - the same is true for us. I think if the browser vendors want their products really to be seen as compatible with the Web application space (as compared to just dynamic Web pages), they will support the work in DAP as its there that non-obtrusive and inherently secure models for Web application access to device resources will be defined as APIs. At present time, I think that the paragraph above accurately summarizes a technical rift between certain members of both working groups (DAP and WebApps). It may not be worthwhile to resolve this rift, and we should allow disparate families of specifications to bloom, taking care not to cause developer confusion with naming (a hard problem). Where specifications worked on in the DAP WG lend themselves to implementation plans, I think Mozilla participants interested in these can comment on them (e.g. Contacts API, at least for now). -- A*
RE: Transferring File* to WebApps - redux
Actually I think "sandboxing" an app into a certain area of the filesystem, especially for less-trusted apps, is a useful model. But I don't think the current File* APIs will support the items 5-6 that I mention below. 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs In BONDI, it's possible to define the sandbox as policy and avoid the user needing to select it. For example it's possible to restrict an application to: * a "temp" filesystem location (whatever that maps to on the current device) * other "well-known" filesystem locations * browser-internal storage (e.g. localstorage) Thanks, Bryan Sullivan | AT&T From: Mike Clement [mailto:mi...@google.com] Sent: Tuesday, June 15, 2010 3:42 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: a...@mozilla.com; Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux Hi, Am I correct in thinking that what you find too restrictive is that the FileSystem API only allows programmatic access to a sandboxed portion of the device's filesystem instead of the entire filesystem? Otherwise, I believe that the File APIs as a whole will allow most of the other operations you mention. --mike On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: Arun, I am not meaning to be unfair, perhaps the message is not coming through clearly enough. There are specific technical requirements that we need these APIs to fulfill, that I indicated to Thomas in another email: 1) access filesystems on the host device 2) traverse directories 3) read files as they exist on the filesystem (not just a local representation in memory, as currently defined in the File API to my understanding), in bytes and lines 4) write files (similar requirement to write directly to the filesystem), in bytes and lines, with overwrite and append options 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs Apart from the details of (1-4) above, which will help ensure are addressed in the current File* APIs (no matter where they are finished),I think it's (5-6) where the real differences are. If we need another API in DAP to address them, then AT&T will help ensure it gets done separately from the current File* APIs. The question of where you are represented and your ability to participate cuts both ways - the same is true for us. I think if the browser vendors want their products really to be seen as compatible with the Web application space (as compared to just dynamic Web pages), they will support the work in DAP as its there that non-obtrusive and inherently secure models for Web application access to device resources will be defined as APIs. Thanks, Bryan Sullivan | AT&T -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Tuesday, June 15, 2010 2:53 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > Arun, > > The basic concern I have is with the notion of "browsers" as the only > Web context and use-case that matters. The browser-based model for API > integration view (as I understand your position) is that the user must > be actively involved in every significant action, and choose explicitly > the actions that enable integration with browser-external resources > (including local and remote). Step back and you will see the > inconsistency in that (what would Ajax be if the user had to approved > every HTTP API request via an element?). > In the case of the File API, I'm merely stating that the capability should be an evolution on top of what web pages already do with respect to the input element, and not introduce a new unbounded API space which doesn't consider user involvement, or reconsiders it with other consent models. Equating ajax with this in general isn't relevant to the argument. If you have no substantial technical differences with FileReader, FileWriter, and the FileSystem API, why are you blocking them from moving? What additional oversight does the DAP WG provide, that the WebApps WG does NOT provide? The WebApps WG has MORE browser vendors than the DAP WG, allowing review that's pertinent to the technology we are building. Below, you say: > Webapps are much more than just dynamic Web pages. They are > applications, and wi
Re: Transferring File* to WebApps - redux
Hi, Am I correct in thinking that what you find too restrictive is that the FileSystem API only allows programmatic access to a sandboxed portion of the device's filesystem instead of the entire filesystem? Otherwise, I believe that the File APIs as a whole will allow most of the other operations you mention. --mike On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > Arun, > > I am not meaning to be unfair, perhaps the message is not coming through > clearly enough. > > There are specific technical requirements that we need these APIs to > fulfill, that I indicated to Thomas in another email: > 1) access filesystems on the host device > 2) traverse directories > 3) read files as they exist on the filesystem (not just a local > representation in memory, as currently defined in the File API to my > understanding), in bytes and lines > 4) write files (similar requirement to write directly to the > filesystem), in bytes and lines, with overwrite and append options > 5) do the above programmatically in Javascript (not dependent just upon > user selection of an input element and interaction with a file selector) > 6) provide security for this using the policy-framework approach as > being defined for DAP APIs > > Apart from the details of (1-4) above, which will help ensure are > addressed in the current File* APIs (no matter where they are > finished),I think it's (5-6) where the real differences are. If we need > another API in DAP to address them, then AT&T will help ensure it gets > done separately from the current File* APIs. > > The question of where you are represented and your ability to > participate cuts both ways - the same is true for us. I think if the > browser vendors want their products really to be seen as compatible with > the Web application space (as compared to just dynamic Web pages), they > will support the work in DAP as its there that non-obtrusive and > inherently secure models for Web application access to device resources > will be defined as APIs. > > Thanks, > Bryan Sullivan | AT&T > > > -Original Message- > From: Arun Ranganathan [mailto:a...@mozilla.com] > Sent: Tuesday, June 15, 2010 2:53 PM > To: SULLIVAN, BRYAN L (ATTCINW) > Cc: Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications > Working Group WG > Subject: Re: Transferring File* to WebApps - redux > > On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > > Arun, > > > > The basic concern I have is with the notion of "browsers" as the only > > Web context and use-case that matters. The browser-based model for API > > integration view (as I understand your position) is that the user must > > be actively involved in every significant action, and choose > explicitly > > the actions that enable integration with browser-external resources > > (including local and remote). Step back and you will see the > > inconsistency in that (what would Ajax be if the user had to approved > > every HTTP API request via an element?). > > > > In the case of the File API, I'm merely stating that the capability > should be an evolution on top of what web pages already do with respect > to the input element, and not introduce a new unbounded API space which > doesn't consider user involvement, or reconsiders it with other consent > models. Equating ajax with this in general isn't relevant to the > argument. > > If you have no substantial technical differences with FileReader, > FileWriter, and the FileSystem API, why are you blocking them from > moving? What additional oversight does the DAP WG provide, that the > WebApps WG does NOT provide? The WebApps WG has MORE browser vendors > than the DAP WG, allowing review that's pertinent to the technology we > are building. Below, you say: > > Webapps are much more than just dynamic Web pages. They are > > applications, and with HTML5 will have the ability to rival desktop > > applications, as is clearly the vision of many in the industry. It > might > > even enable a return to a thin client world (e.g. browser as OS) in > > which most significant resources are cloud-based. I see the logic and > > value in that, but it's not the only valid (and valuable) model. > > > > W3C focuses on the Web, and the Web is bigger than the browser > use-case. > > HTML5 and the APIs that attach HTML-based applications to the world > can > > actually be the application platform for the next era of the Web, but > > only if we do not limit the options to the user-centric/control > > paradigms of the past. > > > > But, by charter, the DAP WG allows you to address those very use
RE: Transferring File* to WebApps - redux
Arun, I am not meaning to be unfair, perhaps the message is not coming through clearly enough. There are specific technical requirements that we need these APIs to fulfill, that I indicated to Thomas in another email: 1) access filesystems on the host device 2) traverse directories 3) read files as they exist on the filesystem (not just a local representation in memory, as currently defined in the File API to my understanding), in bytes and lines 4) write files (similar requirement to write directly to the filesystem), in bytes and lines, with overwrite and append options 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs Apart from the details of (1-4) above, which will help ensure are addressed in the current File* APIs (no matter where they are finished),I think it's (5-6) where the real differences are. If we need another API in DAP to address them, then AT&T will help ensure it gets done separately from the current File* APIs. The question of where you are represented and your ability to participate cuts both ways - the same is true for us. I think if the browser vendors want their products really to be seen as compatible with the Web application space (as compared to just dynamic Web pages), they will support the work in DAP as its there that non-obtrusive and inherently secure models for Web application access to device resources will be defined as APIs. Thanks, Bryan Sullivan | AT&T -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Tuesday, June 15, 2010 2:53 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > Arun, > > The basic concern I have is with the notion of "browsers" as the only > Web context and use-case that matters. The browser-based model for API > integration view (as I understand your position) is that the user must > be actively involved in every significant action, and choose explicitly > the actions that enable integration with browser-external resources > (including local and remote). Step back and you will see the > inconsistency in that (what would Ajax be if the user had to approved > every HTTP API request via an element?). > In the case of the File API, I'm merely stating that the capability should be an evolution on top of what web pages already do with respect to the input element, and not introduce a new unbounded API space which doesn't consider user involvement, or reconsiders it with other consent models. Equating ajax with this in general isn't relevant to the argument. If you have no substantial technical differences with FileReader, FileWriter, and the FileSystem API, why are you blocking them from moving? What additional oversight does the DAP WG provide, that the WebApps WG does NOT provide? The WebApps WG has MORE browser vendors than the DAP WG, allowing review that's pertinent to the technology we are building. Below, you say: > Webapps are much more than just dynamic Web pages. They are > applications, and with HTML5 will have the ability to rival desktop > applications, as is clearly the vision of many in the industry. It might > even enable a return to a thin client world (e.g. browser as OS) in > which most significant resources are cloud-based. I see the logic and > value in that, but it's not the only valid (and valuable) model. > > W3C focuses on the Web, and the Web is bigger than the browser use-case. > HTML5 and the APIs that attach HTML-based applications to the world can > actually be the application platform for the next era of the Web, but > only if we do not limit the options to the user-centric/control > paradigms of the past. > But, by charter, the DAP WG allows you to address those very use cases! If the FileWriter, FileSystem, and FileReader specifications do NOT address the vision you articulate above, why not create a specification relevant to your use case? Naturally, browser vendors see value in technology that serves the cause of dynamic web pages. Why are you disallowing maximum browser vendor review by prohibiting a sensible move? Even within the DAP WG, feedback isn't as forthcoming on these specifications as it is in the WebApps WG. Please reconsider your stance here. You are not providing technical feedback on the specifications in question, nor illustrating why they don't address your use cases. But, you are blocking them from moving to a place where there *is* healthy technical feedback, worrying that those who *are* providing technical feedback will be poor custodians of a technology they are enthusiastic about building into their products. This is unfair. -- A*
Re: Transferring File* to WebApps - redux
On Tue, Jun 15, 2010 at 3:11 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > Jonas, > I guess there might be a parting of the ways here, resulting from > differing (I guess some would say, incompatible) use cases and the APIs > that support them. > > If the current File APIs in DAP are expected to only serve the > user-centric browser paradigm then I agree they will not meet the DAP > requirements and could be finalized in Webapps. But in DAP we will still > need to define an API that *does* meet the use cases and requirements as > envisioned in BONDI (which are focused more on mobile use cases and > security models, as compared to a desktop browser focus) and that are > now being carried forward in the WAC. > > So to help move us forward with the use cases that matter most to us in > DAP, AT&T will draft a new API (filesystem) and provide that as input to > the upcoming DAP F2F. That sounds great. Thank you! / Jonas
RE: Transferring File* to WebApps - redux
Jonas, I guess there might be a parting of the ways here, resulting from differing (I guess some would say, incompatible) use cases and the APIs that support them. If the current File APIs in DAP are expected to only serve the user-centric browser paradigm then I agree they will not meet the DAP requirements and could be finalized in Webapps. But in DAP we will still need to define an API that *does* meet the use cases and requirements as envisioned in BONDI (which are focused more on mobile use cases and security models, as compared to a desktop browser focus) and that are now being carried forward in the WAC. So to help move us forward with the use cases that matter most to us in DAP, AT&T will draft a new API (filesystem) and provide that as input to the upcoming DAP F2F. Thanks, Bryan Sullivan | AT&T -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Tuesday, June 15, 2010 2:48 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: a...@mozilla.com; Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On Tue, Jun 15, 2010 at 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > Arun, > > The basic concern I have is with the notion of "browsers" as the only > Web context and use-case that matters. The browser-based model for API > integration view (as I understand your position) is that the user must > be actively involved in every significant action, and choose explicitly > the actions that enable integration with browser-external resources > (including local and remote). Step back and you will see the > inconsistency in that (what would Ajax be if the user had to approved > every HTTP API request via an element?). > > Webapps are much more than just dynamic Web pages. They are > applications, and with HTML5 will have the ability to rival desktop > applications, as is clearly the vision of many in the industry. It might > even enable a return to a thin client world (e.g. browser as OS) in > which most significant resources are cloud-based. I see the logic and > value in that, but it's not the only valid (and valuable) model. > > W3C focuses on the Web, and the Web is bigger than the browser use-case. > HTML5 and the APIs that attach HTML-based applications to the world can > actually be the application platform for the next era of the Web, but > only if we do not limit the options to the user-centric/control > paradigms of the past. Hi Sullivan, I certainly agree that browsers aren't the only web context or use-case. However I strongly feel that we should design APIs for browsers separately from APIs where the security model is different from that of browsers. For example in a browser it is unacceptable for the web page to read the users file system without the user first granting access to this. And even then there are likely restrictions as to prevent users from getting hacked just because they clicked "yes" on a dialog they didn't understand and just wanted to go away (aka the "whatever dialog" problem). On the flip side, it might make a lot of sense for a widget running on a mobile phone, which some authority has authorized, to have read access to large parts of the phones file system. And possibly even write access to parts of it. However these differences in security model will likely lead to differences in API. This is ok. Lessons from the past, with for example the DOM-Core spec, show that if we try to create an API that fit too many different audiences (in that case it was both server-side environments, as well as web pages). I would really like to avoid repeating similar mistakes. So my suggestion is that we let the FileWriter and File System APIs be ones that are designed for the browser security model. And let them be designed in the webapps WG which is already working on several very similar features (for example I would argue that IndexedDB should supersede File system). If you or anyone else wants to design similar file related specifications, but that has different security model or otherwise different requirements than what exists in the web browser context, then this in no way should impact you. If this should happen in DAP, BONDI, or even in WebApps is a separate question which I basically don't have much of an opinion on at all. / Jonas
Re: Transferring File* to WebApps - redux
On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: Arun, The basic concern I have is with the notion of "browsers" as the only Web context and use-case that matters. The browser-based model for API integration view (as I understand your position) is that the user must be actively involved in every significant action, and choose explicitly the actions that enable integration with browser-external resources (including local and remote). Step back and you will see the inconsistency in that (what would Ajax be if the user had to approved every HTTP API request via an element?). In the case of the File API, I'm merely stating that the capability should be an evolution on top of what web pages already do with respect to the input element, and not introduce a new unbounded API space which doesn't consider user involvement, or reconsiders it with other consent models. Equating ajax with this in general isn't relevant to the argument. If you have no substantial technical differences with FileReader, FileWriter, and the FileSystem API, why are you blocking them from moving? What additional oversight does the DAP WG provide, that the WebApps WG does NOT provide? The WebApps WG has MORE browser vendors than the DAP WG, allowing review that's pertinent to the technology we are building. Below, you say: Webapps are much more than just dynamic Web pages. They are applications, and with HTML5 will have the ability to rival desktop applications, as is clearly the vision of many in the industry. It might even enable a return to a thin client world (e.g. browser as OS) in which most significant resources are cloud-based. I see the logic and value in that, but it's not the only valid (and valuable) model. W3C focuses on the Web, and the Web is bigger than the browser use-case. HTML5 and the APIs that attach HTML-based applications to the world can actually be the application platform for the next era of the Web, but only if we do not limit the options to the user-centric/control paradigms of the past. But, by charter, the DAP WG allows you to address those very use cases! If the FileWriter, FileSystem, and FileReader specifications do NOT address the vision you articulate above, why not create a specification relevant to your use case? Naturally, browser vendors see value in technology that serves the cause of dynamic web pages. Why are you disallowing maximum browser vendor review by prohibiting a sensible move? Even within the DAP WG, feedback isn't as forthcoming on these specifications as it is in the WebApps WG. Please reconsider your stance here. You are not providing technical feedback on the specifications in question, nor illustrating why they don't address your use cases. But, you are blocking them from moving to a place where there *is* healthy technical feedback, worrying that those who *are* providing technical feedback will be poor custodians of a technology they are enthusiastic about building into their products. This is unfair. -- A*
Re: Transferring File* to WebApps - redux
On Tue, Jun 15, 2010 at 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > Arun, > > The basic concern I have is with the notion of "browsers" as the only > Web context and use-case that matters. The browser-based model for API > integration view (as I understand your position) is that the user must > be actively involved in every significant action, and choose explicitly > the actions that enable integration with browser-external resources > (including local and remote). Step back and you will see the > inconsistency in that (what would Ajax be if the user had to approved > every HTTP API request via an element?). > > Webapps are much more than just dynamic Web pages. They are > applications, and with HTML5 will have the ability to rival desktop > applications, as is clearly the vision of many in the industry. It might > even enable a return to a thin client world (e.g. browser as OS) in > which most significant resources are cloud-based. I see the logic and > value in that, but it's not the only valid (and valuable) model. > > W3C focuses on the Web, and the Web is bigger than the browser use-case. > HTML5 and the APIs that attach HTML-based applications to the world can > actually be the application platform for the next era of the Web, but > only if we do not limit the options to the user-centric/control > paradigms of the past. Hi Sullivan, I certainly agree that browsers aren't the only web context or use-case. However I strongly feel that we should design APIs for browsers separately from APIs where the security model is different from that of browsers. For example in a browser it is unacceptable for the web page to read the users file system without the user first granting access to this. And even then there are likely restrictions as to prevent users from getting hacked just because they clicked "yes" on a dialog they didn't understand and just wanted to go away (aka the "whatever dialog" problem). On the flip side, it might make a lot of sense for a widget running on a mobile phone, which some authority has authorized, to have read access to large parts of the phones file system. And possibly even write access to parts of it. However these differences in security model will likely lead to differences in API. This is ok. Lessons from the past, with for example the DOM-Core spec, show that if we try to create an API that fit too many different audiences (in that case it was both server-side environments, as well as web pages). I would really like to avoid repeating similar mistakes. So my suggestion is that we let the FileWriter and File System APIs be ones that are designed for the browser security model. And let them be designed in the webapps WG which is already working on several very similar features (for example I would argue that IndexedDB should supersede File system). If you or anyone else wants to design similar file related specifications, but that has different security model or otherwise different requirements than what exists in the web browser context, then this in no way should impact you. If this should happen in DAP, BONDI, or even in WebApps is a separate question which I basically don't have much of an opinion on at all. / Jonas
Re: Transferring File* to WebApps - redux
On Tue, Jun 15, 2010 at 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > Arun, > > The basic concern I have is with the notion of "browsers" as the only > Web context and use-case that matters. The browser-based model for API > integration view (as I understand your position) is that the user must > be actively involved in every significant action, and choose explicitly > the actions that enable integration with browser-external resources > (including local and remote). Step back and you will see the > inconsistency in that (what would Ajax be if the user had to approved > every HTTP API request via an element?). The similarity between AJAX and the use-cases we're discussing is thin. XHR is the page communicating back with its origin server, and is security-wise in roughly the same category as a script adding an to a page (the sends a script-crafted request back to the server and receives data back). Interacting directly with the user's file system is a substantially more security-conscious action. Involving the user in the action, at least minimalloy, appears to be a common-sense good idea to mitigate the possibility of attacks. The decisions in this arena have been highly informed by security considerations specific to the particular cases being discussed. ~TJ
RE: Transferring File* to WebApps - redux
Arun, The basic concern I have is with the notion of "browsers" as the only Web context and use-case that matters. The browser-based model for API integration view (as I understand your position) is that the user must be actively involved in every significant action, and choose explicitly the actions that enable integration with browser-external resources (including local and remote). Step back and you will see the inconsistency in that (what would Ajax be if the user had to approved every HTTP API request via an element?). Webapps are much more than just dynamic Web pages. They are applications, and with HTML5 will have the ability to rival desktop applications, as is clearly the vision of many in the industry. It might even enable a return to a thin client world (e.g. browser as OS) in which most significant resources are cloud-based. I see the logic and value in that, but it's not the only valid (and valuable) model. W3C focuses on the Web, and the Web is bigger than the browser use-case. HTML5 and the APIs that attach HTML-based applications to the world can actually be the application platform for the next era of the Web, but only if we do not limit the options to the user-centric/control paradigms of the past. Thanks, Bryan Sullivan | AT&T -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Tuesday, June 15, 2010 1:48 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On 6/15/10 1:15 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > We would not be in favor of this transfer. We believe this API needs to > be developed in the DAP group, as our vision for its functionality was > driven by the input from BONDI and in general as a *device* API (as > compared to an abstracted API for cloud-based file resources), and we do > not believe that vision will be fulfilled if this work is transferred to > Webapps. > The BONDI API isn't a good starting place for an API that can be built into web browsers, since it doesn't gracefully layer into the existing HTML input element model for file selection. You are making a distinction I don't understand clearly, since we're not really considering "cloud-based file resources" with the FileReader API. Rather, we are considering file resources resident on the device. The API allows you to select them using an input element, and then access the file resource and programmatically manipulate it as a Blob. Similarly, the FileWriter API allows you to use the "save as" channel to write to the device in question. The FileSystem specification posits an abstraction that isn't necessarily "cloud-based" (although FWIW that is also possible). If you have a different vision, then that vision is incompatible with web browsers. In this case, I'd encourage the DAP WG, which *also* has a charter to work on file system deliverables, to construct an API which matches the use case you have in mind. You may then pursue the relevant BONDI API, which as a browser vendor I cannot consider. > If the issue is the level of discussion in this group, that can be > addressed. For one, I have seen quite a lot of traffic on the DAP email > list about this, so I don't understand the question of activity. > If you note the discussion on FileWriter, you'll see that the lion's share of feedback comes from cross-posts to public-weba...@w3.org. Feedback from others, including those that post to the DAP WG, is always welcome. > But to start, I will address some of the open topics in the current > draft on the DAP list, to help get the discussion moving faster. > > Again, I'd urge you to reconsider your position. The move of the specification in question -- FileWriter and FileSystem -- allows for greater collaboration on the same web stack, *and* allows parties that are NOT members of the DAP WG to comment on the technology. Perhaps you are misunderstanding the goals here? Or, perhaps you can provide a tighter definition of what you mean by "cloud-based file resources" *exactly*? DAP WG members are, by charter, free to consider technology that matches their particular use case. -- A*
Re: Transferring File* to WebApps - redux
On 6/15/10 1:15 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: We would not be in favor of this transfer. We believe this API needs to be developed in the DAP group, as our vision for its functionality was driven by the input from BONDI and in general as a *device* API (as compared to an abstracted API for cloud-based file resources), and we do not believe that vision will be fulfilled if this work is transferred to Webapps. The BONDI API isn't a good starting place for an API that can be built into web browsers, since it doesn't gracefully layer into the existing HTML input element model for file selection. You are making a distinction I don't understand clearly, since we're not really considering "cloud-based file resources" with the FileReader API. Rather, we are considering file resources resident on the device. The API allows you to select them using an input element, and then access the file resource and programmatically manipulate it as a Blob. Similarly, the FileWriter API allows you to use the "save as" channel to write to the device in question. The FileSystem specification posits an abstraction that isn't necessarily "cloud-based" (although FWIW that is also possible). If you have a different vision, then that vision is incompatible with web browsers. In this case, I'd encourage the DAP WG, which *also* has a charter to work on file system deliverables, to construct an API which matches the use case you have in mind. You may then pursue the relevant BONDI API, which as a browser vendor I cannot consider. If the issue is the level of discussion in this group, that can be addressed. For one, I have seen quite a lot of traffic on the DAP email list about this, so I don't understand the question of activity. If you note the discussion on FileWriter, you'll see that the lion's share of feedback comes from cross-posts to public-weba...@w3.org. Feedback from others, including those that post to the DAP WG, is always welcome. But to start, I will address some of the open topics in the current draft on the DAP list, to help get the discussion moving faster. Again, I'd urge you to reconsider your position. The move of the specification in question -- FileWriter and FileSystem -- allows for greater collaboration on the same web stack, *and* allows parties that are NOT members of the DAP WG to comment on the technology. Perhaps you are misunderstanding the goals here? Or, perhaps you can provide a tighter definition of what you mean by "cloud-based file resources" *exactly*? DAP WG members are, by charter, free to consider technology that matches their particular use case. -- A*
