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

Hi Nick, 
This is terrific feedback. Initial responses below... I need to file bugs to make the actual changes to the spec, but wanted to continue the discussion before doing so... there is a lot to do, but at least I think implementers are aware of the challenges. 

(I'm not subscribed to this list, or any mailing list, so please always cc me)

On March 2, 2015 at 12:12:54 AM, Arthur Barstow (art.barstow@gmail.com) wrote:
> -------- Forwarded Message --------
> Subject: reviewing "Manifest for web application" and trying out
> priv/sec questionnaire
> Date: Mon, 2 Mar 2015 01:47:52 -0800
> From: Nick Doty 
>
> I chose this opportunity to try out Mike West's questionnaire as a basis
> for organizing a read-through and review. 

I did the same while writing the stuff in the spec :)  Mike's questionnaire was quite helpful.  
  
> 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.

Heh! I'm sooooo going to copy/paste that as the new abstract  for the spec :)

> 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).

I can add an example to make it less ambiguous. How about something like:  

Knowing which web applications a user has bookmarked can reveal intimate things about an end-user. Just like having access to someone's browsing history, installed applications can reveal patterns of interests over time. Installing a web application can be indicative of a beyond-normal desire to access a resource, tool, or service. If this information is shared amongst third parties, it could be used to partially reconstruct the list of web applications a user has installed on their device. 

> 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?

The application of a display mode and/or orientation persists, as does the name and short_name of the app. 

> Does the start_url parameter introduce an
> effective permanent cookie upon "installing" the app?

Maybe it could:

{
   "start_url": "foo/app?cookieRebuilderID=abc123"
}

> How should UAs
> handle clearing of cookies or other local state when it comes to
> installed apps? 

Depends if the cookie jar and permissions is independent of the browser. For instance, on iOS and FxOS, an installed web app is isolated from the Web browser - so clearing cookies has no effect (though this leads to particularly bad user experiences, as users need to re-authenticate to use the apps they've just installed). 

On Chrome (beta), the cookie jar and permissions are  shared with the browser. So, clearly permissions/cookies also does so for the installed app... which may lead to confusion ("why did my app break after I did something unrelated in the browser?!").  

How cookies/permissions are handled is currently an implementation detail - though I should probably describe this in the installable web apps section. 

> Should we indicate to sites that they shouldn't
> customize manifests to users for this reason? 

It wouldn't hurt to mention it as a bad thing. 

> (If so, could browsers
> effectively detect such violations and prevent it?)

It seems very hard to detect, and easy to work around.

> I believe this should be marked as contributing to fingerprinting and
> creating a new cookie-like local state mechanism.

Yes, I think that would be fair. 

> Is it clear that pages receive the information that the user has
> "installed" the page? (This should at least be noted as a consideration.)

Yes, though it's indirect... kinda sorta... I guess start_url is kinda direct, particularly if it's an unguessable URL tailored for the user. 

> 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.

True. 

>  Via timing
> attacks, is it possible for other pages or apps to detect whether an app
> is installed?

We should certainly warn that icons should be in isolation. 

>  What protections are necessary to prevent one page/app
> from enumerating the other installed web apps?

I'm not sure how an attacker would do this. 

> 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?

Every website on the web is "unbounded". Maybe the definition was not clear :( 

Unbounded means that you can navigate freely from a.com to b.com to c.com to ... N.com, as one does today on the web.   

> What are the implications
> for my manifest "applying" to navigations to other origins
> entirely?

You can't do that. Scope must be same origin. 

However, in unbounded cases: In Chrome, when a user navigates away from the initial origin, an address bar gets shown (thus users have some sense of where they are on the Web). In iOS, if you try to leave the scope of an app, you get thrown into the browser (which is a fairly dramatic context change ... as you literally leave one application and get thrown into another).  

>  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?

Depends who well it can be mitigated by the browser. I think Chrome's policy is kinda sensible (though there is no actual evidence that it's effective in practice yet), but more dramatic visual/auditory queues, like those of iOS, could also help. I can add more text here/examples to the spec. 

> Are the security considerations of scope and display mode "fullscreen"
> limited to unbounded cases? I believe not.

Certainly 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.")

Yes, that could happen. 

> Why is the display mode "fullscreen" orthogonal to the Fullscreen API?

Because you can put any application into fullscreen, simply by going to "view > fullscreen" or clicking that little green button on a Mac's window bar thingy. Or, in Chrome, pressing the keys command-shift-f. Going fullscreen does not necessarily mean you can't access the browser's chrome, just that it's normally hidden. 

That is different from the Fullscreen API, which puts HTML elements as well as the window into fullscreen. 

> Do the security considerations of the Fullscreen API all apply here as well?

Probably. 

> 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 ?

This is the thing I'm most worried about. This needs careful UI/UX design, like you might have to go through a more explicit update process for web apps than native apps coming from an app store: just so to manually verify that the icon is not changing to fool you.    

> 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.

:) heh, if only you knew the trouble I've had trying to actually implement that in Gecko tho... 

> 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?]

Agree. I was not sure how to address this. 

> 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.

Will try to do that. 

> 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.

I could certainly use some help here.

Received on Thursday, 12 March 2015 21:47:46 UTC