Re: reviewing "Manifest for web application" and trying out priv/sec questionnaire

Thank you very much Nick.

As a reminder, comments have been requested by 5 March 2015 (i.e. tomorrow). 

If you have any feedback on this document or Nick’s review, it would be helpful if you could circulate your comments on this list today.

On 2 Mar 2015, at 10:47 am, Nick Doty <npdoty@W3.org> wrote:

> We were asked to review the app manifest document as part of its wide review. Comments are requested by this week.
> 
> I chose this opportunity to try out Mike West's questionnaire as a basis for organizing a read-through and review. I believe the idea of that questionnaire was for self-review, but I think it can still be helpful for external review, and it's a way to give it a little exercise anyway. I've also tried to apply the fingerprinting guidance best practices list (though I've not created separate sections for those). [Comments in square brackets are more meta comments for use of this questionnaire, the rest is actually about the draft under review.]
> 
> Comments on my answers to the questions below, suggestions for recommendations or comments on how this list of questions works are all welcome. I think 3.3 (persistent local state) and 3.11 (affecting UA UI) are the most important.
> 
> —Nick
> 
> 
> So, here's the "Manifest for web application" draft:
> 	http://www.w3.org/TR/2015/WD-appmanifest-20150212/
> 
> The super-short summary: a manifest is a little JSON file that provides some metadata about an "installable" web page, so that the name/icon etc. can be nicely bookmarked on a device and so that a standalone web app can indicate some display mode features so that it acts more like a native app.
> 
> 
> 
> Questions to Consider
> 
>     3.1 Does this specification deal with personally-identifiable information?
>     
> [Not among my favorite questions. *skipping*]
>     
>     3.2 Does this specification deal with high-value data?
>     
> [Also not among my favorite questions.] The spec specifically addresses this in the media type registration, albeit a little ambiguously:
> 
> > This specification does not directly deal with high-value data. However, installed web applications and their data could be seen as "high value" (particulaly from a privacy perspective). 
>     
>     3.3 Does this specification introduce new state for an origin that persists across browsing sessions?
>     
> Likely. What does "installing" an app via use of the app manifest have on persistent state? Does the start_url parameter introduce an effective permanent cookie upon "installing" the app? How should UAs handle clearing of cookies or other local state when it comes to installed apps? Should we indicate to sites that they shouldn't customize manifests to users for this reason? (If so, could browsers effectively detect such violations and prevent it?)
> 
> I believe this should be marked as contributing to fingerprinting and creating a new cookie-like local state mechanism.
> 
> Is it clear that pages receive the information that the user has "installed" the page? (This should at least be noted as a consideration.)
> 
> While it is noted that user agents may choose not to use the start_url hint for an installed web application, we should say more about why not. For example, when I bookmark a URL in my desktop browser and come back to it, I may have a look at the URL and get an impression of what it contains; but if the start_url is not typically shown to the user at bookmarking time but is used for future navigations, then it could be persisting login state in an unexpected way. User agents serving those particularly conscious about fingerprinting are likely to specifically not implement this feature. Are there use cases where user-specific start_url's are advantageous? Are sites sufficiently forewarned of the reasons why start_url shouldn't be relied upon?
>     
>     3.4 Does this specification expose cross-origin persistent state to the web?
>     
> Though not required by interop requirements in this spec, installation is likely to include caching (for example, of icons) which may be observable by the server on subsequent uses of the app. Via timing attacks, is it possible for other pages or apps to detect whether an app is installed? What protections are necessary to prevent one page/app from enumerating the other installed web apps?
>     
>     3.5 Does this specification expose any other data to an origin that it doesn’t currently have access to?
>     
> I don't think so.
>   
>     3.6 Does this specification enable new script execution mechanisms?
> 
> I don't think so.
> 
>     3.7 Does this specification allow an origin access to a user’s location?
>     3.8 Does this specification allow an origin access to sensors on a user’s device?
>     3.9 Does this specification allow an origin access to aspects of a user’s local computing environment?
>     
> No particular sensor or device access that I'm aware of.
>     
>     3.10 Does this specification allow an origin access to other devices?
> 
> I don't think so.
> 
>     3.11 Does this specification allow an origin some measure of control over a user agent’s native UI?
> 
> Yes! The majority of my security/privacy concerns lie in this area, and the existing security considerations text is predominantly about this as well. It seems worth emphasizing the potential challenges of implementing this installation, deep-linking and browser display mode control in a way not vulnerable to phishing and other attacks. Some concerns:
> 
> 
> What are the use cases for unbounded scope? What are the implications for my manifest "applying" to navigations to other origins entirely? Beyond the potential security dangers (phishing, in particular) cases of fullscreen and navigating to different origins, what are the advantages? "for legacy reasons, this is the default behavior" is a parenthetical in a section describing this potential security risk. What are the legacy reasons? Are legacy reasons a sufficient reason for the specified default behavior to incur security risks for the user?
> 
> Are the security considerations of scope and display mode "fullscreen" limited to unbounded cases? I believe not. For example, if a user installs evil-weather.com to their phone and then clicks on a Google search result for evil-weather.com/app/blah and that sends the user directly to a fullscreen mode of evil-weather.com, they could show an apparent Google login screen with no indication of the URL. ("Oh, I guess I have to login to my Google account to get to this search result.")
> 
> 
> Why is the display mode "fullscreen" orthogonal to the Fullscreen API? Do the security considerations of the Fullscreen API all apply here as well?
> 
> 
> This is noted in the section on updates, but I think it's important beyond that:
> >  To avoid one application masquerading as another, it is RECOMMENDED that users be made aware of any such updates using implementation or platform specific conventions.
> What are the privacy and security considerations of using site-provided names and icons when installing an app? Say I go to evil-weather.com, click install/bookmark (so that I can easily get to my weather tomorrow), and evil-weather.com provides "Bank of America" and a BofA icon in its manifest, display mode of minimal or full screen and a start_url to go to a special sub-page that mimics my bank's website. When I look at my list of icons tomorrow morning, how will I know that "Bank of America" is hosted by evil-weather.com?
> 
> 
>     3.12 Does this specification expose origin-controlled data to an origin?
> 
> It seems like caching of icons and the suggested start_url parameter do indicate to the origin that it's installed, but otherwise I don't think this adds more such methods. Customizing the manifest with an identifier could provide another cookie-like thing -- see above.
> 
> Yay for explicitly noting that developer errors may be reported or may be ignored.
> 
>     3.13 Does this specification expose temporary identifiers to the web?
>     
> [We should elaborate on this question a little more. Are we talking about identifiers that a passive network attacker could see? Or for the page itself?]
> 
>     3.14 Does this specification distinguish between behavior in first-party and third-party contexts?
> 
> > "This specification distinguishes between behavior in first-party and third-party contexts."
> 
> But "first-party" and "third-party" aren't defined anywhere. This paragraph could be better explained.
> 
> 
>     3.15 Does this specification have a "Security Considerations" and "Privacy Considerations" section?
> 
> Yes. In particular, security considerations are noted for displaymode and navigations. The media type registration notes a long list of related privacy and security considerations. That may be helpful, but it would also be useful to elaborate on which parts are specific to implementation of this feature.

Received on Wednesday, 4 March 2015 08:22:06 UTC