This sounds great, I fully agree. Comments inline.
On 10 March 2015 at 00:23, Jonas Sicking <[email protected]> wrote:
> First off, I think we should get rid of "apps" as a platform feature.
>
Let's unpack that a little.
- Get rid of the current .zip packages - Yes. For the offline part we
have Service Workers. For the signing part we now have three proposed
alternatives, which we can discuss in a separate thread:
- Signed hosted packages [1]
- Signed Service Worker cache [2]
- Signed manifests [3] (currently my preference)
- Get rid of the app:// protocol - yes please! Giving apps real HTTP
URLs on the web will be a huge step forward. It will make them web apps,
which is always what we intended.
- Get rid of cookie jars - yes, data jars are a nice idea but break some
things on the web. We can experiment with this for some apps, but probably
not enforce it for all content.
What I don't necessarily think we should get rid of is the app registry.
One thing that other vendors (Google/Microsoft/Apple/Intel) *are* currently
showing a lot of interest in is installable hosted web apps using a
standard web app manifest [4]. The manifest can be used to describe a part
of the web as a web app which can break out of the browser and register to
handle a defined URL scope as a standalone app on the OS (Android, Windows
10, Firefox OS etc.). The W3C spec defines an "application context" as a
browsing context with a manifest applied, which can have a different
display mode with no browser chrome like "standalone" or "fullscreen" for a
defined URL scope.
I think the app registry is still useful as a place to register an app as
handling a particular URL scope. The W3C spec does not define an app
installation API (for use by an app store), but instead defines an HTML
manifest link relation (for use by a user agent which can detect it and
provide UI to offer to install the app). This allows web apps to be
discovered simply by searching and browsing the web rather than distributed
through a central app store. We can still use our proprietary mozApps
install API to do this internally from browser chrome in the built-in
system app or bookmark app (signed Firefox apps) which could provide that
UI (this is actually already landed in master). I think this registry needs
to be maintained in Gecko so it knows how to handle any given HTTP
navigation.
> * Enable the user to simply navigate to content which uses sensitive
> APIs, without the need to install it first. I.e. enable the content to
> be available through "real" linkable URLs.
>
Agreed. Ideally web apps should work equally well inside and outside the
browser.
One thing I don't think we want (though this is largely a UX issue) is for
a browser window to constantly switch between different display modes as
you simply browser non-installed web apps, i.e. a manifest shouldn't be
applied to a browsing context simply by navigating to a URL if the app that
manifest describes has not been installed/pinned. This could make for a
very nauseating experience if the display mode keeps changing as you
browse, and provides a vector for phishing attacks if any web content can
enter a standalone display mode without an explicit user action.
My opinion is that the browser chrome provides the user with a safety net
while they browse web sites and web apps (they always know where they are,
and can always go back), the manifest should only be applied when the user
is no longer "just browsing" but has installed/pinned the app to their
device. From that point on that app should handle its own URL scope in its
preferred display mode and can capture navigations to those URLs so the
system can switch to an app window to handle a navigation.
Maybe a creative UX designer can re-invent browser chrome and provide a UI
where the installation step is not necessary, but I haven't yet seen a
design which achieves that.
> * Enable developers to sign the content without going through a
> marketplace review. I.e. enable developers to distribute and updated
> version of their content without having to go through marketplace
> review.
>
I think this is crucial. All three of the proposed alternatives to the
current signed packaged app system have problems with updates if every
update has to be signed by a central authority rather than the developer
themselves.
> * While I think signed content that can use sensitive APIs should have
> real URLs, I think it needs to never be same-origin with unsigned
> "normal" content.
>
This makes sense from a security point of view, a challenge is going to be
that for a signed hosted resource to talk to other resources on its own
domain (like a server-side API), it will need to have CORS set up
(otherwise something like systemXHR is needed). The obvious answer is to
encourage developers to use CORS, but that can be a hard pill to swallow.
How do you even configure CORS to give access to its own domain...?
> The only content distinction we'd end up with is "signed" vs.
> "unsigned". And to the user both would look like normal web.
>
> The "signed" content will be FirefoxOS specific until we find others
> which are interested in collaborating on APIs, which isn't expected to
> be soon. But to put this in perspective, the vast majority of authors
> are able to author content without using these APIs.
>
This isn't a technical issue, but I would suggest that we re-brand Firefox*
specific certified and privileged apps as "Firefox Apps", and hosted apps
as simply "Web Apps", and start to migrate those apps to use the new W3C
manifest format. the properties of the mozApps hosted app manifest could
just be proprietary extensions of the W3C manifest until that spec matures
enough to fulfil all use cases.
We also need to provide an easy migration path for existing authors of
packaged apps. I would suggest this should include offering to host those
apps for people on a Mozilla-run or partner-run web server. Perhaps we can
talk to the Webmaker folks about that?
I would also like to see the Marketplace move away from a "you come here to
download apps" model, and towards a "guide to the best of the web" model
where it just provides links to web apps already on the web which you can
use instantly and optionally install afterwards.
Let me know what you think.
>
I think this is a great path forward.
Ben
1. https://bugzilla.mozilla.org/show_bug.cgi?id=1036275
2. https://groups.google.com/forum/#!topic/mozilla.dev.webapi/PicfHG9Figk
3.
https://groups.google.com/forum/#!msg/mozilla.dev.webapi/pCY77YAg_i4/HxS89bvQ7wsJ
4. http://w3c.github.io/manifest/
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
