Jonas Sicking <mailto:[email protected]>
May 4, 2015 at 5:06 PM
Hi Peter,
I think we can and should simplify this actually.
The main thing that I think we should do is abandon the term "app".
The term "app" is often associated with things like "installing" and
"app store", both of which I'd like to move away from.
To be clear, I think we should still have our marketplace. But not as
the sole provider of "install buttons" as it is today. But rather as a
directory of content works really well on FirefoxOS, similar to the
dmoz.org of days past.
But I think we generally should just consider web content as web
content. I.e. as normal websites that you can browse to. Having a W3C
or a FirefoxOS manifest shouldn't really make a big difference in what
that content can do, what permission it gets or what UI it has.
I think this should be the basis for our design. That content is just
content. Especially from a user perspective having just a single type
of content is the simplest thing.
There are a couple of complexities though.
The first one is what we currently call "privileged apps". I.e. pages
that get access to additional APIs, like TCPSocket and DeviceStorage.
From a user perspective I think we should still simply treat this as
"web content". I.e. it's something that you can browse to in the
browser and without requiring any installation.
However from a security point of view we'll still need this content to
go through a marketplace review and get signed.
I think we should refer to this content as "signed content". I.e. web
pages that have been authorized by the marketplace team to get access
to additional APIs, and which is signed by the marketplace. More
details about the current proposal for how to deliver that content and
that signature is available in [1], though there are a couple of
alternative proposals that we're still investigating.
But from a user point of view, "signed content" still acts and behaves
just like normal web content. So mainly "signed content" is an
implementation complexity which hopefully won't affect the user or UX.
But I do think that this signing mechanism is something we need to
call out in your document because it does affect web developers.
Specifically it affects developers which need access to "sensitive
APIs" as described by [1].
The second complexity is "pinning". I think we should allow users to
pin websites to the homescreen. This should be possible for *any*
website, whether it has a W3C manifest, a FirefoxOS manifest, the
Apple-invented <meta> tags, or none of the above.
When the user pins a website I think we should grant it some
additional permissions automatically. Mainly we should grant it the
ability to store more data, run in the background using the
BackgroundSync and Alarm APIs and maybe create notifications. It might
also give that content special UX treatments, such as the ability to
show up in webactivity picker, or to run without a URL bar.
But all those capabilities should come with getting pinned. It should
not be related to if the website has any types of manifests or not.
Additionally, ideally the capabilities, like storage, BackgroundSync
API, Alarm API and notification API, is something that we make
available to all websites. However if the user hasn't pinned the
website the user would get prompted. So really the pinning is mainly
about UX. I.e. the prompting UX disappear, and the website can choose
to hide URL bar or appear in the webactivity picker.
Given that web developers care a lot about UX, I do think that the
pinning aspect is also worth mentioning in your document.
[1] https://wiki.mozilla.org/FirefoxOS/New_security_model
/ Jonas
On Thu, Apr 16, 2015 at 12:27 PM, Peter Dolanjski
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
Peter Dolanjski <mailto:[email protected]>
April 16, 2015 at 3:27 PM
Hello All,
There have been a number of discussion threads around the details
pertaining to the various forms of apps that are needed as we move
forward with new architecture (based on permissions, presence of a
manifest, etc.). A few of us (product, engineering, partner
engineering, Marketplace) got together to try to assemble a simple
description of what each distinct category is for and when they would
be used. I plan to publish this on one of the v3 wikis, but before I
do I just wanted to open it up for comments/suggestions.
You can see the breakdown here: v3 App Model
<https://docs.google.com/a/mozilla.com/document/d/1_OFzh9P-2jjf_iqtgd_9qNfgkoquo3nBt9oE3XVPRZw/edit>
Feel free to comment right in the doc.
In addition, I'll summarize it here in case you prefer some email
dialogue on it:
*_Web Site_*
Description:
Vanilla web site with no app manifest.
Distribution Channel(s):
1. Any web server
2. Indexed by Marketplace (hosted elsewhere)
Why would a Developer choose this option?
- Just a web site that should be used inside the browser. (no point in
enumerating all reasons for building a web site)
Why would a Developer *not* choose this option?
- Want to provide a more "native" experience
- Need access to sensitive APIs
Signing Required?
No
Mozilla Review?
Yes, for Marketplace indexed content only
Impact of Changes to Existing Apps
none
Proposed User Experience on v3
Discovered through browsing (any web server), searching or via
Marketplace with “open” button. Can optionally pin a page (not “site”)
to the homescreen which will open in a browser window.
*_Web App_*
Description:
Standards-based web app with W3C web app manifest.
Distribution Channel(s):
1. Any web server
2. Indexed by Marketplace (hosted elsewhere)
3. Hosted by Marketplace (TBD)
Why would a Developer choose this option?
- Want content to run standalone outside the browser on multiple
platforms.
- No need to package assets
- If no sensitive APIs required, no extra signing process
Why would a Developer *not* choose this option?
- Developers coming from native consider hosting a service provided by
the Marketplace
Signing Required?
No
Mozilla Review?
Yes, for Marketplace indexed/hosted content only
Impact of Changes to Existing Apps
Existing hosted apps should use the new manifest format going forward,
but new FxOS versions should support legacy app versions.
Proposed User Experience on v3
Discovered through browsing (any web server), searching or via
Marketplace with “open” button. Can use instantly in the browser and
optionally pin to the homescreen to use as a standalone app (in an app
window with fullscreen, standalone or minimal-ui display mode).
Details TBD
*_Firefox App_*
Description:
Signed web app (when privileged API access needed), at least initially
Firefox* specific. W3C web app manifest with moz-prefixed extensions,
inside a hosted streamable package.
Distribution Channel(s):
1. Any web server
2. Indexed by Marketplace (hosted elsewhere)
3. Hosted by Marketplace
Why would a Developer choose this option?
- Easier to handle offline support until ServiceWorkers lands and
gains support
- Need access to Firefox* specific privileged APIs
Why would a Developer *not* choose this option?
- Requires signing by Marketplace (for privileged apps)
Signing Required?
Yes (for privileged apps, TBD)
Mozilla Review?
Yes, for Marketplace indexed/hosted content only
Impact of Changes to Existing Apps
Existing packaged apps need to be converted to new format. Developers
need to adhere to new format going forward.
Proposed User Experience on v3
Discovered through browsing, searching or via Marketplace via “open”
button. Can use instantly in the browser and optionally pin to the
homescreen to use as a standalone app (in an app window with
fullscreen, standalone or minimal-ui display mode). Some permissions
may require app installation (TBD).
_*Legacy (Open Web App)*_
Description:
“web”, “privileged” and “certified” apps with an Open Web App
Manifest. Packaged in a signed zip file (except “web” type).
Distribution Channel(s):
1. Marketplace
2. Any web server (“web” type only)
Why would a Developer choose this option?
- Supporting an old app
Why would a Developer *not* choose this option?
- Requires review by Marketplace
Signing Required?
Yes (except web type)
Mozilla Review?
Yes, for Marketplace indexed/hosted content only
Impact of Changes to Existing Apps
none
Proposed User Experience on v3
Hosted apps should work the same as web apps in v3 adhering to the
display mode. Packaged apps likely won’t be supported but we’ll need
to automatically convert them to work with the new UX.
Thanks,
*Peter Dolanjski*
/Product Manager, Firefox OS /
Mozilla
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
------------------------------------------------------------------------
