RE: Request to move app: URI to FPWD

> j. Section 6.4: Use of MIME sniffing to set Content-type header.  I assume that applications should be able to use File API to read the same files.  Is MIME sniffing currently used to set File.type? The spec lists it as an informative reference, but does not seem to have a normative requirement to use it.  However, app:URI makes this a normative requirement.   If a valid File API implementation does not uses a different MIME sniffing methodology from the one the one used for app:URI, there is a possibility that a file retrieved via XHR could have a different content type from a file retrieved via FileReader.

Apologies - mistake in the comment above.  " If a valid File API implementation does not uses a different MIME sniffing methodology from the one the one used for app:URI, there is a possibility that a file retrieved via XHR could have a different content type from a file retrieved via FileReader" should be " If a valid File API implementation uses a different MIME sniffing methodology from the one the one used for app:URI, there is a possibility that a file retrieved via XHR could have a different content type from a file retrieved via FileReader."

-----Original Message-----
From: Mandyam, Giridhar [mailto:mandyam@quicinc.com] 
Sent: Friday, April 19, 2013 3:41 PM
To: Marcos Caceres; Mounir Lamouri; wonsuk11.lee@samsung.com
Cc: public-sysapps@w3.org
Subject: RE: Request to move app: URI to FPWD

Comments:

Section 1
-----------
I realize this is non-normative, but there are IMO misleading statements in this section and I think it would be better if some (maybe all) of this material is removed entirely.  I think the abstract as written covers the justification for this feature pretty well regarding the desire to leverage XHR for resource retrieval from a package.  Rather than focusing on alleged shortcomings of the File URL, it might be good to collapse this section into an overview of requirements to make file retrieval from a package via XHR possible.  If you are open to it, I can suggest replacement text.  

a. "Security/privacy issues: on Unix systems, naive implementations expose the user name as part of the path, as well as the full path on the file system to where a file is residing (e.g., "/Users/username/app/index.html"). In addition, the file URL scheme potentially opens up the ability for an attacker to address any file on the file system."

Knowing the address of the file is different from being able to access the file.  Certainly root access would override any file system sandboxing, but I believe it is up to the implementation to protect from unauthorized file access outside of root login.


b.  " Undefined security model: The HTML specification lacks a security model definition for when the file URL scheme is used as a document's address, meaning that different user agents behave inconsistently when content is loaded using the file URL scheme (e.g., same origin policy doesn't apply, local storage areas of [WebStorage] don't work as expected if at all, and so on)."

Agreed, but shouldn't this be addressed eventually in Section 6 in the runtime spec (see http://www.w3.org/TR/2013/WD-runtime-20130321/#data-isolation)?  

c. " An app: URI is a safer alternative to the file URL scheme, as it does not allow addressing outside a sand-boxed environment. Additionally, it does not expose the location of a file on user's local device, nor their user name, as in the case with some Unix-based implementations."

I simply do not understand this.  Let us go back to one of the docs cited as examples in the charter - the OMTP Application Security Framework (which is cited as "The BONDI App Security Framework" in the charter). 

First,  Section 2.1.16 of this doc cites examples of when file access outside of the sandbox is necessary.  I assume we'd want privileged applications that can bypass sandboxing for WebOS devices too.

Second, some of the AEE's cited by the OMTP (e.g. BREW, Symbian) have implemented file system sandboxing for 3rd-party applications while leveraging file URL.  These environments allow the application to query available roots, and as a result the app can construct the File URL for use in the appropriate file management API.  The file system implementation in this way implements the sandbox (e.g. iFile and FileConnection for BREW and J2ME respectively).

For BREW in particular, I have yet to hear of anyone successfully attacking the file system through a downloaded packaged app. Regarding J2ME (which many in the industry feel has a stricter sandboxing model than BREW), Symantec has a study online (http://www.symantec.com/avcenter/reference/attack.surface.analysis.of.blackberry.devices.pdf) for Blackberry's version of J2ME where the conclusion is " traditional file infector viruses are not feasible for the BlackBerry, short of the discovery of a new vulnerability" (p. 16).  

Sideload access is a different matter, but I don't think App URI is going to defeat someone who has sideload access to the entire fs.  

d. "An app: URI provides a means to retrieve a file from within a package using similar semantics to performing a GET request over [HTTP]."

I do not believe you need app:URI to do this.  I am going to assume that there is a critical developer need to retrieve resources using XHR as opposed to direct file access (although I am not convinced about this either).  An on-device proxy can be used to accomplish retrieval of resources as well.  The app can send an XHR request to the proxy, the proxy can retrieve files directly, and serve them back.  In the early days of the mobile web (when connectivity was intermittent at best), this was one of the solutions used to provide a continuous web experience.

Section 2
-----------

a. We concluded last week during the review of the Runtime and Security spec that resources could be downloaded (post-install) as well (or at least that was my conclusion as to why " All resources that are commonly used by the application SHOULD be available in the container" from http://www.w3.org/TR/2013/WD-runtime-20130321/#packaged-applications is a SHOULD requirement rather than a MUST) .  I think it would be appropriate to leverage FileWriter or FileHandle and provide an example of an app storing a resource on the fs, and retrieving it afterwards.  I assume app:URI is still applicable.

Section 5
-----------

a. Can I conclude that any locally-stored resources for hosted apps will not be covered by app:URI?  For example, locally cached copies of hosted resources will not be accessible from an application, therefore they do not need app:URI.  

Section 6
-----------

a.  The mention of UUID in the text preceding Section 6.1 implies that it is required, when Sec. 6.2 makes it clear that it is recommended.  Moreover, (obviously) the ABNF spec does not place any requirements on use of unique identifiers.  I would suggest changing " And, and uuid is defined in [UUID]" to "See Section 6.2 for more information on the use of UUID in construction of the authority field." 

b.  Section 6.1:  "The identifier represented by the authority is bound to an instance of an application for the life of that application instance: that is, until that instance is destroyed (e.g., the application is uninstalled from an end-user's device)."

Does this prevent continuity of the authority for a given application after uninstall?  For instance, if the app is uninstalled due to lack of device memory but reinstalled shortly afterwards when memory is freed up, can the authority be retained?  Or should the authority be regenerated after reinstall?

c. Section 6.1:  " The reason for having a unique authority is, amongst other things, to prevent multiple instances from overriding each other's data."

I don't think the authority field uniqueness is the mechanism that will prevent this.  Rather I believe that runtime security mechanism would control the roots available to the application in order to prevent this (see Jonas's post https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/).  Moreover, depending on how you define an instance's data, there will be other mechanisms for modifying data created by another application instance when both have access to common directories (see https://wiki.mozilla.org/WebAPI/DeviceStorageAPI).

No point in painting yourself into a corner.  Since the intent of the above sentence appears to be informative, I would remove it altogether.

d. Section 6.3: I really do not understand how query can ever be used in the context of retrieval of static resources. Seems wasteful to define a feature that has no use to developers.

e. Section 6.3: Similar comment for frag.  You certainly can't use XHR for doc frag retrieval, at least that's the way I interpret Step 7 ("Drop <fragment> from url") in http://www.w3.org/TR/XMLHttpRequest2/#the-open-method (though there are proprietary web services that propose using URL frags to retrieve parts of an XML doc).

f. Section 6.4:  I believe this section covers new behavior required of the UA and could not have been anticipated by a casual reading of the charter.  Can you point me to any one of the references cited in the charter that discusses the dereferencing requirements and required XHR response?  I had trouble finding one.

g. Section 6.4: Where does the de-referencing occur?  Is it in the UA's XHR implementation?  If so, why is this not covered in http://www.w3.org/TR/XMLHttpRequest2/#xmlhttprequest-base-url?


h. Section 6.4: Are request headers ignored?

i. Section 6.4: Section 6.3 mentions that " when dereferencing, the query and fragment components don't play any part in locating a file inside of package".  Yet there is no specific text in this section about the UA ignoring the query and fragment fields in the URI.  Why?

j. Section 6.4: Use of MIME sniffing to set Content-type header.  I assume that applications should be able to use File API to read the same files.  Is MIME sniffing currently used to set File.type? The spec lists it as an informative reference, but does not seem to have a normative requirement to use it.  However, app:URI makes this a normative requirement.   If a valid File API implementation does not uses a different MIME sniffing methodology from the one the one used for app:URI, there is a possibility that a file retrieved via XHR could have a different content type from a file retrieved via FileReader.

Also, some resources are specifically called out in the manifest (icons being the prime example).  Can the MIME type indicated by the manifest in such cases be used in place of MIME sniffing?

Finally, should there be mention of a requirement for the Blob.type to match the Content-type header if the XHR response.responseType (see https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#dom-xmlhttprequest-response) is "Blob"?  

General
----------

a. How does app:URI extend for multiple file system roots (if it does)?  For instance, if app resources are stored both on the device fs and removeable memory (e.g. SD Card),  does this need to be reflected in app:URI?  If so, how does dereferencing occur? 





-----Original Message-----
From: Marcos Caceres [mailto:w3c@marcosc.com] 
Sent: Thursday, April 18, 2013 4:19 AM
To: Mounir Lamouri; wonsuk11.lee@samsung.com
Cc: public-sysapps@w3.org
Subject: Request to move app: URI to FPWD

Chairs, All,  
This is a request to start a CfC to move the app: URI specification [1] to FWPD. If there are no objections, I can begin preparing the document for publication by the W3C.

Again, signs of support would be greatly appreciated. 

[1] http://app-uri.sysapps.org/  

-- 
Marcos Caceres

Received on Sunday, 21 April 2013 15:24:27 UTC