Manifest for web application privacy review

[Nick Doty]

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

Re: CORS performance

[Austin William Wright]

On Mon, Feb 23, 2015 at 12:42 PM, Jonas Sicking  wrote:

> Do we have any data on how common it is for people to use CORS with
> credentials? My impression is that it's far less common than CORS
> without credentials.
>
> If that's the case then I think we'd get most of the functionality,
> with essentially none of the risk, by only allowing server-wide
> cookie-less preflights.
>
> But data would help for sure.
>


The credentials issue is a great concern. I've seen two cases I've been
able to exploit where the Origin header is always passed back to
Access-Control-Allow-Origin with Access-Control-Allow-Credentials; not
realizing this exposes CSRF tokens and other sensitive information. Though
this is not so much data as anecdote. (One was on a company-internal
project, one briefly appeared in a software library we are using in between
stable releases.) It's not hard to find additional examples [1][2][3][4].
I've never used the credentials functionality of CORS, instead passing an
Authorization header explicitly. I think we could survive without it.

I also recently ran into the CORS performance issue. CORS seems very biased
against hypermedia services, in that it doubles the roundtrip time to an
already very "chatty" API design.

To work around these two issues, I began work on a proxy to accept
`message/http` POST requests which returns `message/http` responses
(actually for now, application/json to avoid the full RFC7230
implementation). (Existing proxies solving this problem don't have the
performance characteristics or flexibility, or both, desired around HTTP
headers, hypermedia, and streaming.) The only downside is this bypasses the
user-agent cache, but for many kinds of services the user-agent cache is
rarely utilized (for instance, jQuery's AJAX actively disables caching).

I suggest that any request I can make with this proxy (which does not
itself verify CORS before passing the request), I should be able to make
without the CORS preflight request.

The semantics of the proposed header then becomes a declaration that "This
server is accessible from the Internet" (as opposed to a request on an
intranet server made from an Internet-served page); and would then allow
the making of requests that never utilize stored user-agent data
("credentials"). (With the exception of the Date header, could this be
called deterministic, since the same XHR call will always produce the same
HTTP request?)

This definition would have the following desirable effects:

1. HTTP requests become stateless
2. Removes the possibility of exposing sensitive, stored user information
(a TRACE response, if honored, would not divulge anything the sender
doesn't already know)
3. Brings performance in line with non-browser user-agents that don't
require CORS checks
4. Eliminates the privacy and security concerns associated with CORS
work-arounds, like JSONP. As seen in [5] [6] [7]

This wouldn't introduce new security concerns, because by definition it
would not allow requests that couldn't already be made by proxy.

The `OPTIONS *` request seems appropriate for this; as it is defined to be
a request for metadata about the server itself, which is all that is
necessary.

Austin Wright.

[1]
https://github.com/primiano/blink-gitcs/blob/0b5424070e3006102e0036deea1e2e263b871eaa/LayoutTests/http/tests/security/resources/cors-redirect.php
[2]
https://github.com/wohlig/sergybackend/blob/3df9e42dccf620e53253c746022fbe1e53a97a3a/application/views/json.php
[3]
https://github.com/AslakNiclasen/ProjektOpgave/blob/7d5de466398371ab1481973bf54074ab005fffdc/Kode/ad_controller/.htaccess2.txt
[4]
https://github.com/datfinesoul/starphleet-logviewer/blob/af42371daad52fa7e7ba759e94b20024077a30bb/nginx.conf
[5] http://blog.javascripting.com/2015/01/17/dont-hassle-with-cors/
[6] https://jsonp.nodejitsu.com/
[7] https://github.com/Rob--W/cors-anywhere

[manifest] RE: Manifest for web application; review deadline March 5

[Nilsson, Claes1]

Hi, 

We support that this version of the specification is moved to Candidate status 
but we have a few comments/questions:

In this version 1 we miss:

* A "permissions" field
* A "content security policy field". This is only included as a way to state 
allowed origins from which the manifest file itself could be loaded. However, 
there is, in this first version, no CSP-field defined for the manifest 
document, allowing restriction of origins the web app could download scripts 
and other content types from. There is also a draft companion document, 
http://w3c.github.io/manifest-csp/, defining this CSP-member of the manifest.

We consider the above features important for allowing server hosted web apps 
access to more sensitive APIs and have been experimenting with this for FFOS:
https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-/SoMC_FFOS_Trusted_Hosted_Apps.pdf.
 Accordingly we want to discuss these features for the further work on the 
manifest specification. 

We also would like to ask the WG if it has been discussed if https: transport 
should be required for downloading the manifest? Other specifications are 
moving towards requirement for https:. See for example the discussion 
https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/0045.html. For 
the manifest version 1 this may not be critical but if above features are added 
the transport probably have to be protected. 

However, once again note that these comments do not prevent that we support 
that the current version of the manifest is moved to candidate status, I am 
just taking the opportunity state our views on the further work on the manifest 
specification.

Best regards

Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nils...@sonymobile.com

sonymobile.com




> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@gmail.com]
> Sent: den 13 februari 2015 01:31
> To: public-webapps
> Subject: RfC: Manifest for web application; review deadline March 5
> 
> [ Bcc: public-webappsec, www-style, public-privacy, public-sysapps,
> public-digipub-ig, public-pfwg, public-web-mobile, www-international,
> chairs^1, public-review-announce; Reply-to: public-webapps ]
> 
> This is a Request for Comments (RfC) for WebApp's "Manifest for web
> application" specification:
> 
> 
> 
> "This specification defines a JSON-based manifest that provides
> developers with a centralized place to put metadata associated with a
> web application."
> 
> This Working Draft is intended to meet the wide review requirements as
> defined in the 2014 Process Document. The deadline for comments is 5
> March 2015 and all comments should be sent to the public-webapps @
> w3.org mail list [Archive] with a Subject: prefix of "[manifest]". The
> next anticipated publication of this specification is a Candidate
> Recommendation. (See [CR-Plan] for the specification's Candidate
> Recommendation status.)
> 
> WebApps welcomes review and comments from all individuals and/or groups
> and we explicitly ask the following groups to review the document and
> to submit comments: WebAppSec, CSS WG (in particular, the "display
> mode"
> media feature), PING, SysApps, Digital Publishing IG, WAI (PF, User
> Agent, Authoring Tools), and I18N WG.
> 
> In addition to substantive comments, to help us get a sense of how much
> review the document receives, we also welcome data about "silent
> reviews", f.ex. "I reviewed section N.N and have no comments".
> 
> -Thanks, AB
> 
> ^1 RfC is the new LCWD TransAnn
> [CR-Plan] 
> [Archive] 
> 
>