Proposal: Privileged Hosted Apps

[Benjamin Francis]

Hi,

Following the continued discussion on dev-b2g/dev-gaia/dev-webapps around
the topic "Can we deprecate packaged apps?" [1], and following on from my
previous "TrustedCache" proposal [2] I have a revised proposal for
privileged hosted apps for discussion.

This is fairly naive proposal from someone with pretty basic knowledge of
our existing app signing process and the cryptography involved, so feedback
is very welcome!

The app manifest of a privileged hosted app should enumerate the
permissions it may ask for, and a list of all HTML, CSS and JavaScript
resources along with cryptographic hashes of those files. We could provide
a build tool which helps generate the manifest:

{
"name": "My App",
"scope": "/",
"start_url": "/index.html",
"permissions": [
{
"systemXHR": {
"description": "Needed to download stuff"
}
}
],
"resources": [
{
"src": "/index.html",
"integrity": "ni:///sha-256;kass...eoirW-e?ct=text/html"
},
{
"src": "/page2.html",
"integrity": "ni:///sha-256;kasguie...ngeW-e?ct=text/html"
},
{
"src": "/script.js",
"integrity": "ni:///sha-256;agjdia2...wgda?ct=application/javascript"
},
{
"src": "http://libraries.com/library.js",
"integrity": "ni:///sha-256;geijfi...ae3W?ct=application/javascript"
}
]
}

Resources from other origins may be included. The ni:// integrity hashes
are inspired by the W3C "Subresource Integrity" proposal [3].

The manifest is then signed, generating a manifest.rsa file. The manifest
is referenced from the app using a link relation. The link relation
specifies the manifest file, and its signature.

<link rel="manifest" href="/manifest.json" signature="/manifest.rsa">

When the user installs the app from a web page, if the manifest validates
against its signature it is added to the app registry as a privileged app.
When the app is launched, the manifest is applied to its browsing context,
creating a privileged application context.

<webview manifest="http://myapp.com/manifest.json">

Inside this application context, only HTML/CSS/JavaScript resources which
have been enumerated in the manifest can be requested by the top level
context, and as the resources are fetched they are validated against the
hashes provided in the manifest. Any resource which doesn't match the hash
will fail to load and be blocked from executing.

The tricky part is updating the app. If only Mozilla can sign the app then
the app developer has a problem that they can't release a new version of
the app until Mozilla has signed it, and Mozilla can't review the app until
the developer has released it. Any user who tries to install the updated
app before Mozilla has signed it will find that it doesn't pass the
integrity check. This becomes particularly complicated if multiple app
stores can sign the same app, because the developer must wait for all app
stores to sign the app before users can start to install it again, which
isn't practical.

I propose that we consider allowing developers to sign their own apps, as
they can with XPIs. This means that the user is expressing trust in the app
developer, not in Mozilla to review the app. We could explore other means
of Mozilla vetting developers rather than apps, and revoking the
certificates of developers who breach set guidelines. This decentralisation
of trust means that security assurances are a little more reactive than
proactive, but having Mozilla act as a central authority for reviewing apps
doesn't really scale very well. In this model anyone can review an app, and
users can choose whether they trust the reviewer.

As long as private keys used to sign an app are kept separately from the
app's server, the user is still protected against the server being
compromised, and against man-in-the-middle attacks which would invalidate
the signed app.

Some things to note about this proposal:

- It means that certain APIs will only be available to "installed" or
"pinned" apps when they have been "launched" in order to apply the manifest
to a browsing context to create an application context. This is
unfortunate, but the numbers show that only a small minority of apps
actually need to be privileged. Those apps would need to use feature
detection for progressive enhancement when loaded in an application
context, in order to still work in an un-privileged browsing context.
- This solution does not require that all the resources in the manifest
have to be downloaded at once every time the app manifest is updated. Only
the manifest needs to be updated and validated, the individual resources
can be downloaded and validated as they are requested. An updated manifest
could be used as a signal to invalidate a cache of resources though.
- This proposal is compatible with Service Worker caches, but doesn't
require them. Resources should be validated before they are executed,
regardless of whether they come from the Internet or a Service Worker.
- This proposal is compatible with packages, but doesn't require them. A
developer could provide a hosted packaged version of all the resources so
that they can all be downloaded together, as suggested in a use case in the
W3C "Packaging on the Web" specification [4], or using special HTTP package
URLs [5].
- This model doesn't work well with resources which are dynamically
generated on the server-side. Packaged apps share this limitation, but
there are way around it, like embedding additional functionality inside an
iframe.
- The top level application context should only be allowed to navigate
to URLs within the scope of the app specified in the manifest. Navigating
outside of this scope should exit the application context and open in an
un-privileged browsing context or the application context of another app
with a corresponding scope.

Thoughts?

Ben

1. https://groups.google.com/forum/#!topic/mozilla.dev.b2g/Cepl-i0Epn8
2. https://groups.google.com/forum/#!topic/mozilla.dev.webapi/PicfHG9Figk
3. http://www.w3.org/TR/SRI/
4. http://w3ctag.github.io/packaging-on-the-web/
5. https://bugzilla.mozilla.org/show_bug.cgi?id=1036275

[Frederik Braun]

I think this or something very similar has to be the way forward. The
idea of adding Subresource Integrity into the manifest has some
intriguing side-effects: It allows us to give something tangible to talk
about and give permissions to.

But it's going to be tricky to give permissions to only some part of an
origin. An origin has been and probably will forever be common notion of
scope and privilege (i.e., localStorage, geolocation, …).
Making this change may be tricky to implement without adding loopholes
(My pessimistic security sense finds this unlikely, and history).

But (sub)domains are cheap, so hopefully this isn't a too big concern.

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Benjamin Francis]

On 2 February 2015 at 20:06, Frederik Braun <fbr...@mozilla.com> wrote:

> it's going to be tricky to give permissions to only some part of an
> origin. An origin has been and probably will forever be common notion of
> scope and privilege (i.e., localStorage, geolocation, …).
> Making this change may be tricky to implement without adding loopholes
> (My pessimistic security sense finds this unlikely, and history).
>
> But (sub)domains are cheap, so hopefully this isn't a too big concern.
>

One way of thinking about this is that you're granting a permission to the
scope of the app, which is a subset of the origin, but that's still risky.

Probably a better way of thinking about this is that you're granting a
permission to an origin only when loaded inside a privileged application
context which is a kind of sandboxed browsing context with a manifest
applied which means it can only load a predefined signed set of resources,
(and can only navigate within the defined scope of the app).

Permissions are keyed on origin + manifest URL, where a manifest represents
a complete list of resources validated by hashes.

[Andrew Sutherland]

I like the idea of involving signatures and subresource integrity
because I subscribe to the belief that it's much easier for me to keep a
signing key safe from attackers than it is for me to keep my virtual
server safe from attackers.

For the signature file, it's worth considering the JOSE JWS/JWK stuff
for the signature (https://datatracker.ietf.org/wg/jose/documents/).
Otherwise I'm sorta picturing x509 .pem files or something sorta gross.

In terms of the "privileged" state and permissions, one of the reasons
for the privileged tier is because of permissions like "tcp-socket" that
are hard to explain to the user and where the marketplace is helping the
user make the determination. This can be improved by being able to make
the permissions more specific: tcp-socket for ports x/y/z, tcp-socket
for domain example.com, systemXHR for domains example.com/example.org,
etc.

One possibility would be for the marketplace to perform a preliminary
review and to sign the per-app signing key as well as the set of
permissions and the name and description of the app. The idea would be
that the marketplace would be effectively saying, "yes, this is a
reasonable set of permissions for the app as described and I have no
reason to suspect the author of the app of being a bad actor". That
would also be what the UI shows. The idea is that an email app
shouldn't suddenly be able to decide it wants
"homescreen-webapps-manage" without going through the marketplace again.
Or it shouldn't be able to repurpose the tcpsocket permission to become
a game (and then nefariously nmap and attack the user's home network.)

In the case the app does need new (privileged) permissions, the
marketplace could issue a new signature if the change is deemed
reasonable and within the scope of the existing description. Otherwise
the marketplace could require the creation of a new app with a new
description that the user would have to explicitly install or confirm or
something like that.

Andrew

[Paul Theriault]

Thanks for pushing along this discussion Ben!

Some high level thoughts:
- what are the benefits to this approach to something like the previous hosted packaged apps proposal (bug 1033360 I mean, confusing names ;).
- I guess one benefit is loading only changed resources, but support for differential package updates would seem to be a better solution to that issue
- What update model did you envision? Same as current where user approves every update?

“Any resource”? Does this include resources for frames? IE are apps allowed to frame other content or are they completely siloed from the web? What about inline-resources (data-URI etc)? I would suggest we allow inline, but maybe consider restricting inline with CSP later for privileged apps.

Another question: what origin are you proposing these apps have? This is the part I’m stuck on and I’m not sure of a good answer. IE either the app content is same-origin with the content that its hosted with, and you run the risk that compromised web content on that domain access data which only privileged content can access (i.e. if the privileged app frames web content, or opens content with window.open). So we either need to make apps not same-origin with web content on the same domain, or somehow prevent access from web content into app content.

> The tricky part is updating the app. If only Mozilla can sign the app then
> the app developer has a problem that they can't release a new version of
> the app until Mozilla has signed it, and Mozilla can't review the app until
> the developer has released it. Any user who tries to install the updated
> app before Mozilla has signed it will find that it doesn't pass the
> integrity check. This becomes particularly complicated if multiple app
> stores can sign the same app, because the developer must wait for all app
> stores to sign the app before users can start to install it again, which
> isn't practical.

How do you handle the case when the app has been updated, but the user doesn’t have all the previous version assets cached locally?
Gecko will load the missing resources from the web and they won’t match since the manifest is old.

Force them to update to the new manifest version before running the app I guess?

>
> I propose that we consider allowing developers to sign their own apps, as
> they can with XPIs. This means that the user is expressing trust in the app
> developer, not in Mozilla to review the app. We could explore other means
> of Mozilla vetting developers rather than apps, and revoking the
> certificates of developers who breach set guidelines. This decentralisation
> of trust means that security assurances are a little more reactive than
> proactive, but having Mozilla act as a central authority for reviewing apps
> doesn't really scale very well. In this model anyone can review an app, and
> users can choose whether they trust the reviewer.

Im interested to explore other options for vetting apps. Not sure developer signing is the answer, but could be. Another option might be Marketplace signing the apps for the developer. IE on-demand signing, like a “unreviewed” state which can still be installed, but maybe a different UI from an app that has gone through review?. Centralised signing might be easier for developers and also marketplace could keep a record of version updates. We probably want to support unsigned/self-signed for things like developer beta testing. BTW, My understanding is that we are moving towards AMO signed add-ons rather than using PKI certs.

>
> As long as private keys used to sign an app are kept separately from the
> app's server, the user is still protected against the server being
> compromised,

An attacker could replace the manifest.webapp entirely (and manifest.rsa). We could enforce the that the signing cert was issues to host domain, but the attacker could downgrade the app to a regular web app that doesn’t need to be signed. It would lose permissions, but still be able to access data stored in indexeddb etc. This risk applies equally to Hosted Packaged apps actually if we went that route. Can probably address in update logic, but just a thought.

[Anne van Kesteren]

On Mon, Feb 2, 2015 at 6:16 PM, Benjamin Francis <bfra...@mozilla.com> wrote:
> "Can we deprecate packaged apps?"

It is not clear to me how this proposal solves that problem. It
changes how packaged apps can be distributed, but it's still a walled
garden.

The only way out I still see is identifying what we learned from
"Firefox Apps" (and perhaps gathering what Google learned from their
stores) and applying those lessens to new features for the web:

https://wiki.whatwg.org/wiki/OS

Given that rewriting packaged apps does not accomplish that it seems
less engineering intensive to keep them around until we get there. And
perhaps move more resources into platform to get us there more timely.


--
https://annevankesteren.nl/

[Eric Rescorla]

On Mon, Feb 2, 2015 at 9:16 AM, Benjamin Francis <bfra...@mozilla.com>

> The tricky part is updating the app. If only Mozilla can sign the app then
> the app developer has a problem that they can't release a new version of
> the app until Mozilla has signed it, and Mozilla can't review the app until
> the developer has released it. Any user who tries to install the updated
> app before Mozilla has signed it will find that it doesn't pass the
> integrity check. This becomes particularly complicated if multiple app
> stores can sign the same app, because the developer must wait for all app
> stores to sign the app before users can start to install it again, which
> isn't practical.
>

> I propose that we consider allowing developers to sign their own apps, as
> they can with XPIs. This means that the user is expressing trust in the app
> developer, not in Mozilla to review the app. We could explore other means
> of Mozilla vetting developers rather than apps, and revoking the
> certificates of developers who breach set guidelines. This decentralisation
> of trust means that security assurances are a little more reactive than
> proactive, but having Mozilla act as a central authority for reviewing apps
> doesn't really scale very well.

Why do you say that? Apple signs every app in the iTunes store and their
ecosystem is vastly bigger than the Firefox ecosystem. It might or might
not be a good idea to have centrally reviewed apps but I don't see any
reason to believe it doesn't scale.

It's also important to distinguish between *review* bandwidth and signing
bandwidth. Just because we centrally sign doesn't mean we need to
centrally review. For instance, we could have a central signing server
that signs anything from a registered developer. There's certainly
no reason to believe that that won't scale computationally.

> As long as private keys used to sign an app are kept separately from the
> app's server, the user is still protected against the server being

> compromised, and against man-in-the-middle attacks which would invalidate
> the signed app.
>

How will we enforce that?

-Ekr

[Benjamin Francis]

On 3 February 2015 at 00:18, Andrew Sutherland <asuth...@asutherland.org>
wrote:

> In terms of the "privileged" state and permissions, one of the reasons
> for the privileged tier is because of permissions like "tcp-socket" that
> are hard to explain to the user and where the marketplace is helping the
> user make the determination. This can be improved by being able to make
> the permissions more specific

I agree. Building Firefox OS 1.x helped us find what the missing pieces of
the web platform are, and we ended up with a collection of proprietary
Firefox APIs to fill those holes. We should now be looking at ways to
create equivalent standardised Web APIs which can safely expose the same
type of functionality to the web, whether that's through a new API design
or a new UI design. Restricting APIs to only signed privileged hosted web
apps should be a last resort.

On 3 February 2015 at 02:55, Paul Theriault <pther...@mozilla.com> wrote:

> - what are the benefits to this approach to something like the previous

> hosted packaged apps proposal (bug *1033360* I mean, confusing names ;).
>

It's not clear to me how this proposal will solve the permissions issue or
provide a security model which allows more privileged APIs to be made
available to the web. I assume it would mean signing packages in a similar
way to Firefox packaged apps, but that's not clear from the bugs. Is there
somewhere I can read about that?

Based on my limited understanding of that proposal, benefits of the
privileged hosted apps approach might be:

- It can be retro-fitted to existing hosted web apps which want to
access a privileged API, it doesn't require changing the whole URL
structure of a web app and packaging up all of its resources.
- It's backwards compatible with user agents which don't support
packaging, they can use progressive enhancement when privileged APIs are
available.
- Deep linking to a particular resource doesn't require downloading the
whole package.
- It's potentially compatible with both Service Workers and a hosted web
package solution, but doesn't require either of them. Deciding whether to
package a collection of resources together is orthogonal to whether they
can access privileged APIs or work offline.

Having said all that, if we can solve all the same problems with hosted
packaged apps then I'm certainly not opposed to them in principle, this was
just another option.

> - I guess one benefit is loading only changed resources, but support for
> differential package updates would seem to be a better solution to that
> issue
>

Yes, if only one file of a web app changes you probably only need to update
the manifest and that one file, you could continue to used cached versions
of the other files if the hashes still match. You probably could achieve
something similar with differential package updates, yes.

> - What update model did you envision? Same as current where user approves
> every update?
>

No, same as the web where updates happen transparently.

“Any resource”? Does this include resources for frames? IE are apps allowed
> to frame other content or are they completely siloed from the web?

Apps should be able to frame other content. Also, some files like images
likely won't need hashes. Will CSS files need hashes?

> What about inline-resources (data-URI etc)? I would suggest we allow
> inline, but maybe consider restricting inline with CSP later for privileged
> apps.
>

Sounds fine.

> Another question: what origin are you proposing these apps have? This is
> the part I’m stuck on and I’m not sure of a good answer. IE either the app
> content is same-origin with the content that its hosted with, and you run
> the risk that compromised web content on that domain access data which only
> privileged content can access (i.e. if the privileged app frames web
> content, or opens content with window.open). So we either need to make apps
> not same-origin with web content on the same domain, or somehow prevent
> access from web content into app content.
>

I'm not sure about the answer to this one. How does it work with hosted
apps in B2G today? An origin only has certain permissions when loaded
inside a mozapp iframe with a particular manifest URL set. i.e. The origin
only has those permissions when used inside a privileged application
context with a manifest applied. Can we use that same approach? Are same
origin resources loaded inside an iframe inside a Firefox hosted app
considered same origin with the app?

How do you handle the case when the app has been updated, but the user
> doesn’t have all the previous version assets cached locally?
> Gecko will load the missing resources from the web and they won’t match
> since the manifest is old.
>
> Force them to update to the new manifest version before running the app I
> guess?
>

Yes, I imagine the new manifest would be detected and would invalidate the
cached copies of any resources which no longer match their hashes.

Im interested to explore other options for vetting apps. Not sure developer
> signing is the answer, but could be. Another option might be Marketplace
> signing the apps for the developer. IE on-demand signing, like a
> “unreviewed” state which can still be installed, but maybe a different UI
> from an app that has gone through review?. Centralised signing might be
> easier for developers and also marketplace could keep a record of version
> updates. We probably want to support unsigned/self-signed for things like
> developer beta testing. BTW,

A centralised solution relies on the app developer a) knowing Mozilla
exists and b) caring enough about the Firefox Marketplace to submit their
app there and have it signed by Mozilla. It might make sense from a
security point of view, but I think having a central point of control would
cripple the growth of the web ecosystem. Ideally someone should be able to
create a privileged hosted app for Chrome OS and it automatically work on
Firefox OS too.

> My understanding is that we are moving towards AMO signed add-ons rather
> than using PKI certs.
>

Does that mean developers won't be able to sign their own extensions any
more? What's the rationale behind that?

An attacker could replace the manifest.webapp entirely (and manifest.rsa).

We could enforce the that the signing cert was issues to host domain, but
> the attacker could downgrade the app to a regular web app that doesn’t need
> to be signed. It would lose permissions, but still be able to access data
> stored in indexeddb etc. This risk applies equally to Hosted Packaged apps
> actually if we went that route. Can probably address in update logic, but
> just a thought.
>

I don't have a lot of knowledge in this area but it sounds like if the
certificate it tied to a domain then we're not adding any new risks that
don't already exist. If someone takes control of the server of an existing
web app they can access IndexedDB databases. Someone who compromises the
server of a privileged hosted app still wouldn't be able to modify the app
and access privileged permissions without the developer's private key?

On 3 February 2015 at 07:48, Anne van Kesteren <ann...@annevk.nl> wrote:

> On Mon, Feb 2, 2015 at 6:16 PM, Benjamin Francis <bfra...@mozilla.com>
> wrote:

> > "Can we deprecate packaged apps?"
>

> It is not clear to me how this proposal solves that problem. It
> changes how packaged apps can be distributed, but it's still a walled
> garden.
>

Can you explain that in a bit more detail? The apps don't have to be
packaged and the idea is that anyone can host a self-signed privileged
hosted app without any involvement with Mozilla. What part of the proposal
do you think creates a walled garden?

> The only way out I still see is identifying what we learned from
> "Firefox Apps" (and perhaps gathering what Google learned from their
> stores) and applying those lessens to new features for the web:
>
> https://wiki.whatwg.org/wiki/OS
>

As I said above, I agree that creating standardised versions of our
proprietary Firefox privileged APIs which can safely be exposed to the web
without needing a signed app should be a big part of the solution. So far
that doesn't seem to be happening. This proposal is a last resort for those
APIs which we can't otherwise think of a safe API or UI to enable it to be
exposed to the web. Privileged hosted apps should hopefully be a small
minority of web apps, but would allow us to get rid of the existing
packaged app solution which forces a centralised solution and fragments the
web. Ultimately I hope it would allow us to host Gaia at http://*.
firefoxos.com.

Given that rewriting packaged apps does not accomplish that it seems
> less engineering intensive to keep them around until we get there.

Which part of the proposal did you read as "rewriting packaged apps"?

> And
> perhaps move more resources into platform to get us there more timely.

Sounds great.

On 3 February 2015 at 15:06, Eric Rescorla <e...@rtfm.com> wrote:

> Why do you say that? Apple signs every app in the iTunes store and their
> ecosystem is vastly bigger than the Firefox ecosystem. It might or might
> not be a good idea to have centrally reviewed apps but I don't see any
> reason to believe it doesn't scale.
>

The web ecosystem is vastly bigger than the Apple ecosystem, and shouldn't
rely on a single point of control. Imitating Apple's walled garden is
exactly what we shouldn't be doing, in my opinion.

>
> It's also important to distinguish between *review* bandwidth and signing
> bandwidth. Just because we centrally sign doesn't mean we need to
> centrally review. For instance, we could have a central signing server
> that signs anything from a registered developer. There's certainly
> no reason to believe that that won't scale computationally.
>

Do we really want to be in the business of automatically signing the whole
web? Why should someone need Mozilla's approval to create a web app anyway?
What if a user decides they don't trust Mozilla?

As long as private keys used to sign an app are kept separately from the
>> app's server, the user is still protected against the server being
>> compromised, and against man-in-the-middle attacks which would invalidate
>> the signed app.
>>
>
> How will we enforce that?
>

It's true we can't stop developers doing stupid things, but I don't think
Mozilla having a monopoly on trust is the right answer. We could explore
other approaches of vetting developers rather than apps, and maybe
blacklisting certificates of developers known to be doing something stupid,
or malicious.

I honestly don't claim to have all the answers, I'm just putting this
forward as a starting point for talking about a solution for web apps which
have some of the benefits of native apps without losing the unique benefits
of the web.

Ben

[Eric Rescorla]

On Tue, Feb 3, 2015 at 10:09 AM, Benjamin Francis <bfra...@mozilla.com>
wrote:
>
>

> On 3 February 2015 at 15:06, Eric Rescorla <e...@rtfm.com> wrote:
>
> > Why do you say that? Apple signs every app in the iTunes store and their
> > ecosystem is vastly bigger than the Firefox ecosystem. It might or might
> > not be a good idea to have centrally reviewed apps but I don't see any
> > reason to believe it doesn't scale.
> >
>
> The web ecosystem is vastly bigger than the Apple ecosystem, and shouldn't
> rely on a single point of control. Imitating Apple's walled garden is
> exactly what we shouldn't be doing, in my opinion.
>
>

I think we may be talking past each other.

There are (at least) two categories of applications here:

- Those which do not require any elevated privileges.
- Those which do require elevated privileges.

It's the latter which need to be authenticated in some fashion
and which we presently require to be signed. That's the only
ones I'm discussing. As I understand it, your proposal still
requires some sort of authentication, it's just that you propose
to have Mozilla authenticate developers and then delegate
app signing to those developers.

> It's also important to distinguish between *review* bandwidth and signing
> > bandwidth. Just because we centrally sign doesn't mean we need to
> > centrally review. For instance, we could have a central signing server
> > that signs anything from a registered developer. There's certainly
> > no reason to believe that that won't scale computationally.
> >
>
> Do we really want to be in the business of automatically signing the whole
> web? Why should someone need Mozilla's approval to create a web app anyway?
>

This is not what I am suggesting. See above.

-Ekr

[Gervase Markham]

On 02/02/15 17:16, Benjamin Francis wrote:
> I propose that we consider allowing developers to sign their own apps, as
> they can with XPIs. This means that the user is expressing trust in the app
> developer, not in Mozilla to review the app. We could explore other means
> of Mozilla vetting developers rather than apps, and revoking the
> certificates of developers who breach set guidelines.

The trouble with this (and you should talk to the people who have been
wrestling with similar issues for addons) is not revoking the cert of an
evil developer, but preventing them immediately minting a new one. Who
would issue certs to app developers, how would their identity be
verified, how much would they therefore have to pay for that work to be
done, and so on.

Gerv

[Benjamin Francis]

On 3 February 2015 at 18:19, Eric Rescorla <e...@rtfm.com> wrote:

> I think we may be talking past each other.
>

Possibly, or maybe I'm just getting over-excited :)

> There are (at least) two categories of applications here:
>
> - Those which do not require any elevated privileges.
> - Those which do require elevated privileges.
>

> There are really three:

1. Your run-of-the-mill web app which doesn't require any special
treatment. This should be the vast majority of apps.
2. Privileged packaged Firefox apps which I would like to become
privileged hosted web apps (or as a minimum have a real HTTP URL rather
than an app:// synthetic local origin). These are apps which use APIs we
can't otherwise figure out how to safely expose to the web.
3. Certified packaged Firefox apps which will hopefully be mostly
replaced by privileged hosted apps, and what's left (e.g. the system app)
will essentially be a new type of chrome.

It's the latter which need to be authenticated in some fashion
> and which we presently require to be signed. That's the only
> ones I'm discussing. As I understand it, your proposal still
> requires some sort of authentication, it's just that you propose
> to have Mozilla authenticate developers and then delegate
> app signing to those developers.
>

I actually don't know how this would work, I don't even really understand
how our current signing system works! I'm hoping other people can provide
some suggestions.

One thought is that Mozilla could issue certificates to developers to sign
their own apps, and have a contract with the developer which would result
in the certificate being revoked if breached. The problem with that is that
it's still very Mozilla-centric. Mozilla can't be the sole issuer of
certificates for standardised privileged web apps for all operating systems.

When trying to learn about our app signing I discovered that our current
Firefox extension system uses an XPI signing mechanism which isn't so
Mozilla-centric [1] with the use of code-signing certificates issued by
multiple issuers who aren't Mozilla. (Although now I learn that may be
going away, in favour of Mozilla-signed extensions only). This led me to
think that maybe we could have a non-Mozilla-centric system for app
signing. This provides some level of protection to users with regards to
compromised servers and man-in-the-middle attacks, but means the user must
ultimately trust the developers of apps rather than Mozilla. All Mozilla
can do is maintain a blacklist of bad guys.

One potential answer is that:

- Privileged hosted web apps can be self-signed by developers (using a
certificate issued by an issuer with a CA root Authority installed in
Firefox OS) and users must decide whether to trust the developer. Mozilla
could choose to become an issuer of free certificates (as we are with Let's
Encrypt) but would not be the sole issuer.
- Certified apps become a new type of chrome which happens to use HTML5
as a markup language. If we want third parties to be able to build apps or
extensions to this chrome then they become a new type of chrome extension
which can only be signed by Mozilla. Firefox OS apps/extensions would by
definition be Firefox OS-only.

How does that sound? Any other suggestions?

Ben

1.
https://developer.mozilla.org/en/docs/Signing_a_XPI#Obtaining_a_valid_software_developer_code-signing_certificate

[Benjamin Francis]

On 4 February 2015 at 10:21, Gervase Markham <ge...@mozilla.org> wrote:

> The trouble with this (and you should talk to the people who have been
> wrestling with similar issues for addons)

OK, who should I speak to?

> is not revoking the cert of an
> evil developer, but preventing them immediately minting a new one. Who
> would issue certs to app developers, how would their identity be
> verified, how much would they therefore have to pay for that work to be
> done, and so on.
>

As above, maybe:

- For privileged hosted web apps Mozilla doesn't have the power to
revoke certificates, the user has to trust the developer. Mozilla would
perhaps only be able to issue warnings, in the same way as we currently do
for phishing and malware protection. This also allows for a user to decide
to stop trusting Mozilla, but continue using their privileged web apps in
another browser.
- For certified Firefox apps/extensions only Mozilla can sign the apps,
and can block them too.

[Anne van Kesteren]

On Tue, Feb 3, 2015 at 7:09 PM, Benjamin Francis <bfra...@mozilla.com> wrote:
> On 3 February 2015 at 07:48, Anne van Kesteren <ann...@annevk.nl> wrote:
>> It is not clear to me how this proposal solves that problem. It
>> changes how packaged apps can be distributed, but it's still a walled
>> garden.
>
> Can you explain that in a bit more detail? The apps don't have to be
> packaged and the idea is that anyone can host a self-signed privileged
> hosted app without any involvement with Mozilla. What part of the proposal
> do you think creates a walled garden?

1) You're proposing a particular way of signing that has no backing
from other vendors.

2) The APIs (presumably) available behind the signing have no backing either.

>> The only way out I still see is identifying what we learned from
>> "Firefox Apps" (and perhaps gathering what Google learned from their
>> stores) and applying those lessens to new features for the web:
>>
>> https://wiki.whatwg.org/wiki/OS
>
> As I said above, I agree that creating standardised versions of our
> proprietary Firefox privileged APIs which can safely be exposed to the web
> without needing a signed app should be a big part of the solution. So far
> that doesn't seem to be happening. This proposal is a last resort for those
> APIs which we can't otherwise think of a safe API or UI to enable it to be
> exposed to the web. Privileged hosted apps should hopefully be a small
> minority of web apps, but would allow us to get rid of the existing
> packaged app solution which forces a centralised solution and fragments the
> web. Ultimately I hope it would allow us to host Gaia at http://*.
> firefoxos.com.
>
> Given that rewriting packaged apps does not accomplish that it seems
>> less engineering intensive to keep them around until we get there.
>
> Which part of the proposal did you read as "rewriting packaged apps"?

Well making it possible for Gaia to be firefoxos.com is that, no? A
rewrite of the way we wrap our code? That seems like quite a bit of
effort. And it's not clear it will be useful long term since the web
has a very different way of doing things.

That is, there seem to be various models of distributing code:

1) Global distribution. All the APIs. User has to trust what is
installed and run.

2) Centralized distribution. Not all APIs are available, but most are.
Some APIs require user permission. An authority made sure the code is
trustworthy. User has to decide whether to trust the authority, and
whether to use this particular piece of code and grant it permissions
it asks for.

3) Global distribution. Limited set of sandboxed APIs. Some APIs
require user permission. User has to put trust in the entity
distributing the code when granting it permissions and interacting
with it.

Firefox Apps is 2, the web is 3. I don't really see us bringing them
closer together. I can envision 3 cannibalizing 2.


--
https://annevankesteren.nl/

[Andrew Williamson]

Some comments:

I fear the signing of resources process would be a) initially
complicated for new developers to set up, increasing the bar to entry
significantly and then b) entirely automated in a deploy script so any
random content that in the /src folder at the time gets signed. Lets
assume that developers *will* keep the signing key somewhere as hackable
as the rest of the site, as its in the developer nature to be lazy. At
that stage, what makes this more secure than just https?
This is not to say that its technically a bad process, just if its a
self-signed process its not (imo) adding much security benefit. If
there was some way for a 3rd party (be it Mozilla, or someone else) to
do the signing, then I can see the advantages.

We're moving the decision about whether an app should be installed from
Mozilla, and contributors it trusts, to users. Users are terrible at
making that kind of decision - your average web user will agree to
pretty much anything and has insufficient knowledge to make an informed
decision. I just don't see how a user can know enough to trust a
developer or not on a random website offering an app installation. I
feel this is Mozilla abdicating our responsibility to our users,
primarily for idealogical reasons rather than practical ones.

As others have mentioned, blacklisting after the fact becomes a game of
whack-a-mole, which is one of the reasons AMO is moving to sign all
add-ons itself*.

* (In brief, addons - all versions- must either a. be hosted on AMO; b.
submitted to AMO for review and then only returned signed after review;
c. self signed - only for internal intranet type installations, and only
after contacting Mozilla and seeking our agreement and acceptance.)

I think we would gain the most by moving some of the privileged APIs to
standards-based non-privileged ones, where the user is able to make a
decision on each action (e.g. a prompt each time the app wants to save
something to their SD card, rather than a DeviceStorage permission).
That, and the much-hoped-for serviceworkers, should take away most of
the need for packaged apps anyway.

[Eric Rescorla]

On Wed, Feb 4, 2015 at 4:49 AM, Benjamin Francis <bfra...@mozilla.com>
wrote:

> On 3 February 2015 at 18:19, Eric Rescorla <e...@rtfm.com> wrote:
>
>> I think we may be talking past each other.
>>
>
> Possibly, or maybe I'm just getting over-excited :)
>
>
>> There are (at least) two categories of applications here:
>>
>> - Those which do not require any elevated privileges.
>> - Those which do require elevated privileges.
>>
>> There are really three:
>
> 1. Your run-of-the-mill web app which doesn't require any special
> treatment. This should be the vast majority of apps.
> 2. Privileged packaged Firefox apps which I would like to become
> privileged hosted web apps (or as a minimum have a real HTTP URL rather
> than an app:// synthetic local origin). These are apps which use APIs we
> can't otherwise figure out how to safely expose to the web.
> 3. Certified packaged Firefox apps which will hopefully be mostly
> replaced by privileged hosted apps, and what's left (e.g. the system app)
> will essentially be a new type of chrome.
>
>

OK. Both of the second categories require elevated privileges. The point of
having those chain back to some decision made by someone at Mozilla
(or someone else in a position of trust) is to allow users to substitute
that
person's decision about what apps/actors are good or bad for their
own, as they do in the iTunes store.

It's the latter which need to be authenticated in some fashion
>> and which we presently require to be signed. That's the only
>> ones I'm discussing. As I understand it, your proposal still
>> requires some sort of authentication, it's just that you propose
>> to have Mozilla authenticate developers and then delegate
>> app signing to those developers.
>>
>
> I actually don't know how this would work, I don't even really understand
> how our current signing system works! I'm hoping other people can provide
> some suggestions.
>

OK, well, this sort of app signing question is something that has seen a lot
of iteration over the years, both here and at other places. It might be
useful
to familiarize yourself with other designs and their pros and cons before
proposing a new one.

One thought is that Mozilla could issue certificates to developers to sign
> their own apps, and have a contract with the developer which would result
> in the certificate being revoked if breached.
>

As Gerv says, blacklist schemes like this are extremely difficult to
maintain
because bad actors just sign up with a new name.

The problem with that is that it's still very Mozilla-centric. Mozilla
> can't be the sole issuer of certificates for standardised privileged web
> apps for all operating systems.
>

I would expect that the default assumption would be that the browser
manufacturers
would be the signers of apps for their own systems, just as mobile phone OS
vendors
are largely now with the iTunes and Android app stores.

When trying to learn about our app signing I discovered that our current
> Firefox extension system uses an XPI signing mechanism which isn't so
> Mozilla-centric [1] with the use of code-signing certificates issued by
> multiple issuers who aren't Mozilla. (Although now I learn that may be
> going away, in favour of Mozilla-signed extensions only). This led me to
> think that maybe we could have a non-Mozilla-centric system for app
> signing. This provides some level of protection to users with regards to
> compromised servers and man-in-the-middle attacks, but means the user must
> ultimately trust the developers of apps rather than Mozilla. All Mozilla
> can do is maintain a blacklist of bad guys.
>

This doesn't seem very helpful. The idea here is that the user shouldn't
have to make
decisions about whether a specific app is safe.

> One potential answer is that:
>
> - Privileged hosted web apps can be self-signed by developers (using a
> certificate issued by an issuer with a CA root Authority installed in
> Firefox OS) and users must decide whether to trust the developer. Mozilla
> could choose to become an issuer of free certificates (as we are with Let's
> Encrypt)
>
>

Important note: Let's Encrypt is an independent entity of which Mozilla is
a sponsor. Mozilla
is not an issuer of free WebPKI certs.


> - but would not be the sole issuer.

> - Certified apps become a new type of chrome which happens to use
> HTML5 as a markup language. If we want third parties to be able to build
> apps or extensions to this chrome then they become a new type of chrome
> extension which can only be signed by Mozilla. Firefox OS apps/extensions
> would by definition be Firefox OS-only.
>
> How does that sound? Any other suggestions?
>

Not very good for the reasons listed above.


-Ekr


Ben
>
> 1.
> https://developer.mozilla.org/en/docs/Signing_a_XPI#Obtaining_a_valid_software_developer_code-signing_certificate
>
>

[Benjamin Francis]

On 4 February 2015 at 16:25, Anne van Kesteren <ann...@annevk.nl> wrote:

> 1) You're proposing a particular way of signing that has no backing
> from other vendors.
>
> 2) The APIs (presumably) available behind the signing have no backing
> either.
>

Of course it doesn't have backing from other vendors... I just made it up.
There is no standardised solution for exposing privileged APIs to the web,
yet we have a bunch of APIs we can't figure out how to expose to the web,
that's why I'm proposing one, to start a conversation. The APIs don't have
backing because we haven't proposed them to any standards bodies, mostly
because we know they couldn't be standardised in their current form. Let's
fix that.

Well making it possible for Gaia to be firefoxos.com is that, no? A
> rewrite of the way we wrap our code? That seems like quite a bit of
> effort. And it's not clear it will be useful long term since the web
> has a very different way of doing things.
>

Gaia should be made of the web, that was always the goal. If Firefox OS
apps are just a new type of proprietary Mozilla app rather than web apps
built on open standards then we're adding to the problem we set out to
solve. If we can't build Gaia on the web, then the web needs new APIs.
Let's fix that. (Yes, it will be a lot of effort).

>
> That is, there seem to be various models of distributing code:
>
> 1) Global distribution. All the APIs. User has to trust what is
> installed and run.
>
> 2) Centralized distribution. Not all APIs are available, but most are.
> Some APIs require user permission. An authority made sure the code is
> trustworthy. User has to decide whether to trust the authority, and
> whether to use this particular piece of code and grant it permissions
> it asks for.
>
> 3) Global distribution. Limited set of sandboxed APIs. Some APIs
> require user permission. User has to put trust in the entity
> distributing the code when granting it permissions and interacting
> with it.
>
> Firefox Apps is 2, the web is 3. I don't really see us bringing them
> closer together. I can envision 3 cannibalizing 2.
>

The web is not going to canibalize the centralised closed systems until it
can provide equivalent functionality to those systems. As Fabrice likes to
say, you still can't build Instagram with the web. Let's fix that.

If you believe a signing system isn't necessary (I would love for that to
be the case), then please propose new WebAPIs which fulfil the requirements
app developers have but using the existing security model of the web.

[Benjamin Francis]

On 4 February 2015 at 17:17, Eric Rescorla <e...@rtfm.com> wrote:


> I would expect that the default assumption would be that the browser
> manufacturers
> would be the signers of apps for their own systems, just as mobile phone
> OS vendors
> are largely now with the iTunes and Android app stores.
>

Why is it the default assumption? Because that's how the current closed
systems work? So Mozilla should sign Firefox Apps and Google should sign
Chrome apps and they shall forever remain separate? Is that the web we want?

The idea here is that the user shouldn't have to make
> decisions about whether a specific app is safe.
>

Helping the user to make good decisions and maintaining an opinionated,
curated collection of content is one thing. Forcing users of a Mozilla
device to only install Mozilla apps which have been signed by Mozilla and
downloaded from the Mozilla store is another.

[Eric Rescorla]

On Wed, Feb 4, 2015 at 10:20 AM, Benjamin Francis <bfra...@mozilla.com>
wrote:

> On 4 February 2015 at 17:17, Eric Rescorla <e...@rtfm.com> wrote:
>
>
>> I would expect that the default assumption would be that the browser
>> manufacturers
>> would be the signers of apps for their own systems, just as mobile phone
>> OS vendors
>> are largely now with the iTunes and Android app stores.
>>
>
> Why is it the default assumption?
>

Because it's the way it is now for the two biggest ecosystems and there are
obvious advantages to the owners of those ecosystems from having it
continue to be so.

> Because that's how the current closed systems work? So Mozilla should sign
> Firefox Apps and Google should sign Chrome apps and they shall forever
> remain separate? Is that the web we want?
>

The question that seems more interesting here is what's practical.

Do you have any support from other browsers or phone OS vendors
for a model where there is a single signer or set of signers for
cross-platform web apps? If not, it seems premature to be discussing
technical mechanisms.

The idea here is that the user shouldn't have to make
>> decisions about whether a specific app is safe.
>>
>
> Helping the user to make good decisions and maintaining an opinionated,
> curated collection of content is one thing. Forcing users of a Mozilla
> device to only install Mozilla apps which have been signed by Mozilla and
> downloaded from the Mozilla store is another.
>

I don't believe that anyone suggested that, so I don't know who think you're
arguing with here. Certainly, you should be able to install unsigned apps on
your FFOS phone and we might also have an easy way to install
other app stores. The question at hand should be:

1. How the system behaves by default
2. What our policies are for the apps that we authorize.

And wrt to the second question, I think we need to enforce rather stronger
security controls than in your proposal.

-Ekr

[Benjamin Francis]

On 4 February 2015 at 16:55, Andrew Williamson <awill...@mozilla.com>
wrote:

> Lets assume that developers *will* keep the signing key somewhere as
> hackable as the rest of the site, as its in the developer nature to be
> lazy. At that stage, what makes this more secure than just https?
>

Nothing, I agree. If you have a fancy encrypted electronic key fob and keep
it on the roof of your car, it doesn't offer any additional security.

> If there was some way for a 3rd party (be it Mozilla, or someone else) to
> do the signing, then I can see the advantages.
>

OK, fair enough. So how can we build privileged web apps in a way that
delegates trust to a trusted party, but that party doesn't always have to
be Mozilla? (i.e. something that can be standardised and work across
multiple browsers).

>
> We're moving the decision about whether an app should be installed from
> Mozilla, and contributors it trusts, to users. Users are terrible at
> making that kind of decision - your average web user will agree to pretty
> much anything and has insufficient knowledge to make an informed decision.
> I just don't see how a user can know enough to trust a developer or not on
> a random website offering an app installation

Fair enough.

> . I feel this is Mozilla abdicating our responsibility to our users,
> primarily for idealogical reasons rather than practical ones.
>

There are very practical reasons. A Firefox Marketplace simply can not
compete with established closed app stores by trying to compete on their
terms. It requires a solution which spans the whole web and has
implementations by multiple vendors. A system where Mozilla has to sign all
the apps doesn't provide that.

> As others have mentioned, blacklisting after the fact becomes a game of
> whack-a-mole, which is one of the reasons AMO is moving to sign all add-ons
> itself*.
>
> * (In brief, addons - all versions- must either a. be hosted on AMO; b.
> submitted to AMO for review and then only returned signed after review; c.
> self signed - only for internal intranet type installations, and only after
> contacting Mozilla and seeking our agreement and acceptance.)
>

Thanks for clarifying.

I think we would gain the most by moving some of the privileged APIs to
> standards-based non-privileged ones, where the user is able to make a
> decision on each action (e.g. a prompt each time the app wants to save
> something to their SD card, rather than a DeviceStorage permission). That,
> and the much-hoped-for serviceworkers, should take away most of the need
> for packaged apps anyway.
>

I agree.

[Anne van Kesteren]

On Wed, Feb 4, 2015 at 7:03 PM, Benjamin Francis <bfra...@mozilla.com> wrote:
> Of course it doesn't have backing from other vendors... I just made it up.
> There is no standardised solution for exposing privileged APIs to the web,
> yet we have a bunch of APIs we can't figure out how to expose to the web,
> that's why I'm proposing one, to start a conversation.

Is that actually true? I don't think there's many APIs for which we
don't have some idea as to how we would do them on the web given
resources. The only one I can think of that keeps coming up is "raw
sockets" and I'm not really convinced we need to solve it.

> The web is not going to canibalize the centralised closed systems until it
> can provide equivalent functionality to those systems. As Fabrice likes to
> say, you still can't build Instagram with the web. Let's fix that.

We could if we made getUserMedia() better, I think. It seems someone
is doing some work in that direction:

https://w3c.github.io/mediacapture-image/

> If you believe a signing system isn't necessary (I would love for that to be
> the case), then please propose new WebAPIs which fulfil the requirements app
> developers have but using the existing security model of the web.

It's not a matter of having rough ideas how to solve the problem, it's
about not having the resources to follow them through.


--
https://annevankesteren.nl/

[Benjamin Francis]

On 5 February 2015 at 09:17, Anne van Kesteren <ann...@annevk.nl> wrote:

> Is that actually true? I don't think there's many APIs for which we
> don't have some idea as to how we would do them on the web given
> resources.

The only one I can think of that keeps coming up is "raw
> sockets" and I'm not really convinced we need to solve it.
>
>

Looking down the list of most commonly used permissions in the Marketplace
[3] (ignoring the ones which are already exposed to hosted apps, even if
not standard)...

I hope that replacing packaged apps with hosted apps using Service Workers
will reduce the need for systemXHR, but there are still people who think we
need a cross-origin equivalent of XMLHttpRequest which doesn't require CORS
to be set up. Perhaps prompting the user on a per-requested-origin basis.

We still don't have a great story for file storage, and device-storage is a
very commonly requested permission. What's the latest thinking on that? I
heard something about a new Filesystem API proposal?

The Contacts API and more generally the DataStore API for sharing stored
data between apps doesn't have a hosted equivalent. Do we have an idea for
that? I heard something about shared IndexedDB stores?

One example I'm familiar with is Webview (the Browser API). We'd like to
try to standardise that [1][2] but it seems blocked by the lack of a
suitable permissions model. That maybe isn't the best example because it's
only the 10th most used permission in the Firefox Marketplace [3] but it's
one I'm familiar with. It's something which has similar existing
implementations across multiple platforms and a common subset [4][5] should
be relatively easy to agree on, although arguably it isn't the most
valuable of APIs to standardise.

I believe TCP Sockets would currently be required to create an app that can
cast media to the MatchStick (as an example), though maybe the Presentation
API would help with that? What are the other current use cases of this API?

There are a handful of apps using the Mobile Network API [6].


Then if you start looking at what APIs would be needed to make web versions
of built-in Gaia apps, there's a much longer list. I don't even know what
all of these permissions used by Gaia apps mean, but they're currently all
limited to only signed packaged apps:

- themeable
- attention
- bluetooth
- settings
- audio-channel-notification
- telephony
- voicemail
- time
- audio-channel-telephony
- idle
- phonenumberservice
- camera
- feature-detection
- audio-channel-alarm
- open-remote-window
- webapps-manage
- wifi-manage
- nfc-share
- nfc
- sms
- networkstats-manage
- firefox-accounts
- geolocation-noprompt
- power
- speaker-control
- input
- cellbroadcast
- audio-channel-ringer
- embed-apps
- wappush

That doesn't even include the system app.

I'm not saying that we need to make all of these permissions available to
hosted web apps, but I do think we need to start to decide which of these
are essentially always going to be chrome level type privileged things, and
which of them we could find ways to expose to web versions of Gaia apps,
and ultimately third party apps.

Hopefully you'll agree the landscape is a bit more complex than just raw
sockets.

It's not a matter of having rough ideas how to solve the problem, it's
> about not having the resources to follow them through.
>

OK, well that's both disappointing and promising. Is there somewhere (on
the wiki perhaps) where we can write all of those ideas down so that they
can be prioritised and resources can be found to work on them?

Ben

1.
https://groups.google.com/forum/#!msg/mozilla.dev.webapi/KYfiTzg8m-U/ueT6JhT5DaQJ
2. https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0324.html
3. http://people.mozilla.org/~bfrancis/images/permissions-2015-01-30.png
4. http://benfrancis.github.io/webview/
5. https://wiki.mozilla.org/WebAPI/BrowserAPI/Common_Subset
6. https://developer.mozilla.org/en-US/docs/Web/API/MozMobileNetworkInfo

[Gervase Markham]

On 04/02/15 13:06, Benjamin Francis wrote:
> OK, who should I speak to?

Jorge Villalobos would be the person to start with.

>> is not revoking the cert of an
>> evil developer, but preventing them immediately minting a new one. Who
>> would issue certs to app developers, how would their identity be
>> verified, how much would they therefore have to pay for that work to be
>> done, and so on.
>
> As above, maybe:
>
> - For privileged hosted web apps Mozilla doesn't have the power to
> revoke certificates, the user has to trust the developer. Mozilla would
> perhaps only be able to issue warnings, in the same way as we currently do
> for phishing and malware protection. This also allows for a user to decide
> to stop trusting Mozilla, but continue using their privileged web apps in
> another browser.

How will this avoid degenerating into the proverbial "Whatever" button?

Gerv

[Benjamin Francis]

On 5 February 2015 at 15:35, Gervase Markham <ge...@mozilla.org> wrote:

> Jorge Villalobos would be the person to start with.
>

Thank you.

How will this avoid degenerating into the proverbial "Whatever" button?
>

I don't have a good concise answer to that, but hopefully a combination of
good API design and good UI design, asking the right questions at the right
time. Google has presented some interesting ideas in this area recently
around the UI design of invalid certificate warnings and other security
topics.

I don't think there's anything wrong with Mozilla hand-holding users to
help keep them safe sometimes. But the web also needs to be able to
continue to function even if Mozilla ceases to exist. We need to somehow
distribute the trust, if not to users then at least to more people than
just us signing off on everything.

[Paul Theriault]

I’m a few emails behind but Andrew raised most of what I was going to say anyways. I’m keen on this proposal, but I think perhaps you are trying to solve several areas in one go. To me there are separate problems here:

a) a more webby alternative to packaged apps
b) an alternative model for granting complex permissions on behalf of users

I’d suggest we focus on a) for this proposal, since that to me is more of the issue.

I do also think we need to look at way we grant implicit permissions, but I think that can be done separately. I actually started this as part of ideation. My thinking was something like having an alternative install path for apps which are signed by marketplace, but not installed from marketplace. But the issues come back to the same ones Andrew raised - the user isn’t equipped to make that decision, so you are putting them at risk. FWIW I have some notes here: https://etherpad.mozilla.org/improvedpermissiongranting

But going back to your proposal, I’d suggest we look at it from requirements perspective. So I think we need a solution which:
1. lists resources that belong to an app
2. ensures resources dont change
3. allows an entity (marketplace etc) to vouch that a specific version of an app is safe to have certain permissions
4. provides a safe separation between privileged app content and regular web content

The troublesome issues that I see are:
- apps need a separate security origin to web content otherwise there is a risk web content can access privileged data. If we don’t enforce one-app-per-origin (which we don’t anymore) we need some way of carving up an origin. Sounds something like google’s sub origin proposal maybe sound complex and error-prone.
- having resources fetched individually seems complicated from the sense of keeping updates atomic, but maybe its not that hard.

In any case - I do agree that we should focus more on APIs & permissions and seeing what can be exposed. Im going through the permissions at the moment to see which permissions are best candidates for this sort of revision.

- Paul

[Benjamin Francis]

On 5 February 2015 at 20:14, Paul Theriault <pther...@mozilla.com> wrote:

> I’m a few emails behind but Andrew raised most of what I was going to say
> anyways. I’m keen on this proposal, but I think perhaps you are trying to
> solve several areas in one go. To me there are separate problems here:
>
> a) a more webby alternative to packaged apps
> b) an alternative model for granting complex permissions on behalf of users
>

>
I’d suggest we focus on a) for this proposal, since that to me is more of
> the issue.
>

You're absolutely right, and I ended up spending a lot of time talking
about b) when I really set out to solve a). Solving a) on its own would be
a huge step forward.

The problem was that in solving a) I found I had to solve b) because our
current Mozilla-centric Marketplace signing system made a) impractical. In
my original email I mention that the problem is updates. When updating a
hosted privileged app a developer has the problem that they can't get their
update signed by Mozilla until they've pushed out the update, but they
can't push out the update without first getting it signed by Mozilla. With
packaged apps this works because the developer submits a new package to the
Marketplace, Mozilla signs the package and then pushes out the signed
update. The same process doesn't work for hosted apps.

Can we think of a way of solving updates for a) without solving b)? The
only solution I've thought of so far is developers versioning their hosted
app with a different URL for each version. Which sucks.

I do also think we need to look at way we grant implicit permissions, but I
> think that can be done separately. I actually started this as part of
> ideation. My thinking was something like having an alternative install path
> for apps which are signed by marketplace, but not installed from
> marketplace. But the issues come back to the same ones Andrew raised - the
> user isn’t equipped to make that decision, so you are putting them at risk.
> FWIW I have some notes here:
> https://etherpad.mozilla.org/improvedpermissiongranting
>

Ah yes I think I've read this, I was trying to find it to reference it but
couldn't. Thanks for the link! This proposal is heavily inspired by our
discussions in Portland.

>
> But going back to your proposal, I’d suggest we look at it from
> requirements perspective. So I think we need a solution which:
> 1. lists resources that belong to an app
> 2. ensures resources dont change
> 3. allows an entity (marketplace etc) to vouch that a specific version of
> an app is safe to have certain permissions
> 4. provides a safe separation between privileged app content and regular
> web content
>

5. Allows the app to be updated

> The troublesome issues that I see are:
> - apps need a separate security origin to web content otherwise there is a
> risk web content can access privileged data. If we don’t enforce
> one-app-per-origin (which we don’t anymore) we need some way of carving up
> an origin. Sounds something like google’s sub origin proposal maybe sound
> complex and error-prone.
>

Yes this one is tricky. I don't think I know enough about the problems this
would cause to suggest a solution. Can you list some of the problematic
areas? Currently IndexedDB databases, cookies, localStorage etc. are
isolated per app by the data jar system which might help, but I think we
might want to get rid of that. I imagine postMessage could be problematic?

> - having resources fetched individually seems complicated from the sense
> of keeping updates atomic, but maybe its not that hard.
>

Maybe there are problems I haven't thought of yet, but I actually thing
this is a desirable feature. Resources don't have to be downloaded until
they're used. A new manifest just invalidates cached versions of the
resources to force them to be fetched again the next time they're used. Or
a Service Worker could programmatically download them all together when the
new manifest is detected to make sure they're available offline.

>
> In any case - I do agree that we should focus more on APIs & permissions
> and seeing what can be exposed. Im going through the permissions at the
> moment to see which permissions are best candidates for this sort of
> revision.
>

Great. Anne started this wiki page but maybe that's for something different
https://wiki.whatwg.org/wiki/OS

Would be great to see your list.

Ben

[Paul Theriault]

>
> In any case - I do agree that we should focus more on APIs & permissions and seeing what can be exposed. Im going through the permissions at the moment to see which permissions are best candidates for this sort of revision.
>
> Great. Anne started this wiki page but maybe that's for something different https://wiki.whatwg.org/wiki/OS
>
> Would be great to see your list.

Sure. This is where I’m working [1] but I’ll move to wiki once its more ready for comment. Basically just trying to classify permissions by capability & threats at the moment, with a view to identifying patterns of controls that might be effective to make APIs more safe.


[1] https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdGVpcVpuMS1meVlDNmVFRFJ1X1JPbXc#gid=0

[Anne van Kesteren]

On Thu, Feb 5, 2015 at 3:18 PM, Benjamin Francis <bfra...@mozilla.com> wrote:
> On 5 February 2015 at 09:17, Anne van Kesteren <ann...@annevk.nl> wrote:
>> Is that actually true? I don't think there's many APIs for which we
>> don't have some idea as to how we would do them on the web given
>> resources.
>>
>> The only one I can think of that keeps coming up is "raw
>> sockets" and I'm not really convinced we need to solve it.
>

> I hope that replacing packaged apps with hosted apps using Service Workers
> will reduce the need for systemXHR, but there are still people who think we
> need a cross-origin equivalent of XMLHttpRequest which doesn't require CORS
> to be set up. Perhaps prompting the user on a per-requested-origin basis.

I don't think we can realistically make this work. Sites will have to
use a proxy.

> We still don't have a great story for file storage, and device-storage is a
> very commonly requested permission. What's the latest thinking on that? I
> heard something about a new Filesystem API proposal?

What exactly does device-storage provide that IDB does not? There's a
filesystem API proposal, but in terms of unique properties it's not
much different from IDB.

> The Contacts API and more generally the DataStore API for sharing stored
> data between apps doesn't have a hosted equivalent. Do we have an idea for
> that?

Not really. This is what activities might solve, but we haven't really
found a way yet how.

However, Firefox phones could come with a contacts application written
by Mozilla that exposes an OAuth API to share them with other
applications. And CardDAV as well. It could just be a web service
until we figure out activities and can bring the services to the
client.

> One example I'm familiar with is Webview (the Browser API). We'd like to try

> to standardise that but it seems blocked by the lack of a suitable

> permissions model. That maybe isn't the best example because it's only the

> 10th most used permission in the Firefox Marketplace but it's one I'm

> familiar with. It's something which has similar existing implementations

> across multiple platforms and a common subset should be relatively

> easy to agree on, although arguably it isn't the most valuable of APIs to
> standardise.

If the OS and the browser are one, it's not clear why we would expose
an API for a nested OS. It's not like iOS provides iOSView.

> I believe TCP Sockets would currently be required to create an app that can
> cast media to the MatchStick (as an example), though maybe the Presentation
> API would help with that? What are the other current use cases of this API?

Casting is the presentation API I believe, yes.

> There are a handful of apps using the Mobile Network API [6].

Anything compelling that uses it?

> Then if you start looking at what APIs would be needed to make web versions
> of built-in Gaia apps, there's a much longer list. I don't even know what
> all of these permissions used by Gaia apps mean, but they're currently all
> limited to only signed packaged apps:

I'm not familiar enough with these names to judge.

> Hopefully you'll agree the landscape is a bit more complex than just raw
> sockets.

I meant that those are the only ones for which there is no clear idea.
And integration of phone and sms. I've always imagined we would leave
phone be a native application until it disappears at the hand of
WebRTC. SMS sees some usage as authentication platform so perhaps
there needs to be an API for that, dunno.

> OK, well that's both disappointing and promising. Is there somewhere (on the
> wiki perhaps) where we can write all of those ideas down so that they can be
> prioritised and resources can be found to work on them?

I'm happy for folks to expand https://wiki.whatwg.org/wiki/OS


> 6. https://developer.mozilla.org/en-US/docs/Web/API/MozMobileNetworkInfo


--
https://annevankesteren.nl/

[Dale Harvey]

> I don't think we can realistically make this work. Sites will have to
> use a proxy.

This seems like the bare minimum we should be able to get working, if we
cant build basic applications like feed readers and scrapers in web
technology without hacking around security with proxy's then there doesnt
seem to be a lot of hope.

The requirement to run and maintain an online service to build really basic
applications is a pretty huge incentive to just build native applications
who happily live without these limitations

Similiarly with tcp sockets, being able to write an IRC client with web
technology seems like it should be some form of baseline of functionality

> What exactly does device-storage provide that IDB does not? There's a
> filesystem API proposal, but in terms of unique properties it's not
> much different from IDB.

> Not really. This is what activities might solve, but we haven't really
> found a way yet how.

> However, Firefox phones could come with a contacts application written
> by Mozilla that exposes an OAuth API to share them with other
> applications. And CardDAV as well. It could just be a web service
> until we figure out activities and can bring the services to the
> client.

Device Storage (and datastorage) mainly provide the ability to share data
between applications, they can be notified on write, and they dont require
storing duplicates of the data, think of taking a photo with the camera and
being able to edit it in the gallery, indexeddb doesnt currently have this
functionality. Oauth and activities arent really applicable.

[Benjamin Francis]

On 6 February 2015 at 08:17, Paul Theriault <pther...@mozilla.com> wrote:

>
> Sure. This is where I’m working [1] but I’ll move to wiki once its more
> ready for comment. Basically just trying to classify permissions by
> capability & threats at the moment, with a view to identifying patterns of
> controls that might be effective to make APIs more safe.
>
>
> [1]
> https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdGVpcVpuMS1meVlDNmVFRFJ1X1JPbXc#gid=0
>

This is awesome.

[Anne van Kesteren]

On Fri, Feb 6, 2015 at 1:36 PM, Dale Harvey <da...@arandomurl.com> wrote:
> This seems like the bare minimum we should be able to get working, if we
> cant build basic applications like feed readers and scrapers in web
> technology without hacking around security with proxy's then there doesnt
> seem to be a lot of hope.

You can build these as web applications and people have and they have
some amount of success. And actually for a lot of these having a proxy
that acts as a cache for all the other sites being hit doesn't seem
like such a bad deal.

It's not clear to me how we can make the security work. This is not
something you can realistically ask the user.

> The requirement to run and maintain an online service to build really basic
> applications is a pretty huge incentive to just build native applications
> who happily live without these limitations
>
> Similiarly with tcp sockets, being able to write an IRC client with web
> technology seems like it should be some form of baseline of functionality

I can agree with "seems like it should". I have not seen something
that could work.

> Device Storage (and datastorage) mainly provide the ability to share data
> between applications, they can be notified on write, and they dont require
> storing duplicates of the data, think of taking a photo with the camera and
> being able to edit it in the gallery, indexeddb doesnt currently have this
> functionality. Oauth and activities arent really applicable.

Well, sharing underlying data is possible with postMessage(). However,
it requires tight integration rather than something decentralized
(what activities might enable).


--
https://annevankesteren.nl/

[hst...@mozilla.com]

On Friday, February 6, 2015 at 5:09:08 AM UTC-8, Anne van Kesteren wrote:
> On Fri, Feb 6, 2015 at 1:36 PM, Dale Harvey <da...@arandomurl.com> wrote:
> > This seems like the bare minimum we should be able to get working, if we
> > cant build basic applications like feed readers and scrapers in web
> > technology without hacking around security with proxy's then there doesnt
> > seem to be a lot of hope.
>
> You can build these as web applications and people have and they have
> some amount of success. And actually for a lot of these having a proxy
> that acts as a cache for all the other sites being hit doesn't seem
> like such a bad deal.

Well, I guess you agree it's not an elegant solution.. Doable, but..

After all those years, we're still struggling with how to let a user say "I trust this site". Perhaps because we're mostly engineers discussing a UI problem..

Personally, I really liked Opera Dragonfly's model. For those of you who are not familiar with the architecture of the Opera dev tool, it's a web application loading directly from a URL into a window with special privileges. (Usually loading from a URL but Opera could also be configured to load it from a file).
The policies and methods we already have on the web - URLs, HTTPS (with cert revocation), same-origin, Extended Validation certs etc. work for the web as-is, and web sites do quite important stuff like managing your personal banking working with the existing architecture. Developers and users (mostly) understand this stuff. Can we build on this to just make a model where we grant privileges on an origin/window basis? Just to play with something completely hands-on I wrote this early in the morning:

http://hallvord.com/temp/moz/b2g-app-settings-playground.htm
(It's a playground - so the code isn't written to be beautiful)

There are lots of arguments against - along the lines of "users do not bother with / understand settings". But how else are we going to give *the web* greater powers?

-Hallvord R.

[cyberphone]

If you pay in a shop using your "Carte Bancaire" (I'm in France) you put the card in a terminal provided by a certified vendor of trusted payment terminals, right?

That is, the card is never directly exposed to potentially malicious merchant code.

Now if you rather go to the Web, you'll find that the entire concept "Trusted Code" is missing!

The Web is "retarded" and will stay that way until Mozilla and Co realizes that the Web and Native could friends instead of competitors:

http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/
http://webpki.org/papers/web2native-bridge.pdf

It is bound to happen some day in a not so distant future unless somebody comes up with a truly "Einstein-ish" idea. Personally I think we shouldn't wait for that; if such an idea actually materializes we just take it from there!

[Fabrice Desré]

On 02/25/2015 07:18 AM, cyberphone wrote:

> The Web is "retarded" and will stay that way until Mozilla and Co realizes that the Web and Native could friends instead of competitors:

"retarded" has a very different meaning in English, much more offensive
than in French. Would you say that "le Web est débile" ? I guess you
meant "le Web est en retard", ie. "the Web is lagging behind".

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Anders Rundgren]

On Wednesday, February 25, 2015 at 7:08:15 PM UTC+1, Fabrice Desré wrote:
> On 02/25/2015 07:18 AM, cyberphone wrote:
>
> > The Web is "retarded" and will stay that way until Mozilla and Co realizes that the Web and Native could friends instead of competitors:
>
> "retarded" has a very different meaning in English, much more offensive
> than in French. Would you say that "le Web est débile" ? I guess you
> meant "le Web est en retard", ie. "the Web is lagging behind".

For the kind of applications I'm working with "lagging" would be very polite since the progress has been "nul" the last 20 years.

It is not hard to imagine why:
1. Intel and ARM would standardize a security architecture. If possible it would take 5 years
2. The browser vendors standardize a JS interface to the former. If possible it would take 3 years
3. VISA creates a payment application based on the former. Should take a year
4. A global AppStore (who runs that?) checks and publishes the VISA application. Should take 0.5 year

So the current plan (+ common packaging) would take approximately 10 years to accomplish. During that time other solutions have made the (unlikely) deliverable obsolete!

Now, if you instead used a "combo" like
http://webpki.org/papers/web2native-bridge.pdf
Intel, ARM, VISA, Browser-vendors and Vetting would be "untangled" which would increase speed by at least factor 2, limit standardization to a minimum, allow new developments any time, and make competition among payment solutions a reality.

Privileged hosted apps is a nice idea. On paper.

Anders