Hi Webapps, Per your request for wide review, I've done a brief review of the "Manifest for web application" draft with an eye to privacy issues. The comments below are informed by discussions with the Privacy Interest Group and based on Mike West's privacy/security questionnaire [0] and my fingerprinting guidance doc [1] -- documents which might be useful for you as well. All mistakes and misunderstandings are solely my own.
I have a few suggested changes below, but for the most part I have questions about how a feature is intended to be implemented or what guidance would be necessary for features to be implemented consistently in a way that wouldn't have bad security or privacy outcomes. Apologies; I recognize that direct text change proposals are easier to evaluate, but I don't know the intended implementation as well as you all certainly do. If it would be helpful to discuss these questions/answers, please feel free to include public-priv...@w3.org <mailto:public-priv...@w3.org> (the Privacy Interest Group). Hope this helps, Nick ## Persistent state (Questionnaire 3.3) 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? I believe this should be marked as contributing to fingerprinting and creating a new cookie-like local state mechanism. 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?) Are there use cases where user-specific start_url's are advantageous? 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; if sites are going to depend on it but it's going to be implemented inconsistently, that might be a reason to re-think it. Are sites sufficiently forewarned of the reasons why start_url shouldn't be relied upon? ## Cross-origin persistent state (Questionnaire 3.4) 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 another particular Web application is installed? What protections are necessary to prevent one page/app from enumerating the other installed web apps? ## Control over native UI (Questionnaire 3.11) 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" That 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 <http://evil-weather.com/> to their phone and then clicks on a Google search result for evil-weather.com/app/blah <http://evil-weather.com/app/blah> and that sends the user directly to a fullscreen mode of evil-weather.com <http://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 <http://evil-weather.com/>, click install/bookmark (so that I can easily get to my weather tomorrow), and evil-weather.com <http://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 <http://evil-weather.com/>? ## Other Yay for explicitly noting that developer errors may be reported or may be ignored. > "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. 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. "Manifest for web application" seems strange wording for a title. "Manifests for Web applications", maybe, or "Web application manifest"? [0] https://mikewest.github.io/spec-questionnaire/security-privacy/ <https://mikewest.github.io/spec-questionnaire/security-privacy/> [1] http://w3c.github.io/fingerprinting-guidance/ <http://w3c.github.io/fingerprinting-guidance/>
