While I’m all for simplification, installation is a useful metaphor for signalling user intent. Removing installation leaves us limited to prompts only. Prompts are pretty limited in terms of a security mitigation and we will have a hard time authorising access to the privileged APIs, especially (but not only) those which are currently granted without user consent (implicit permissions). And we are not talking at all here about extensions/add-ons which afaik is a key part of ignite. I think there is a still case for install, especially for “add-on” content.
So I imagine something more like this: Content (linkable, no install required) Web Content Web Apps Signed Web Apps (for APIs with prompt only) Add-ons (not linkable? installed via install step) Signed Web Apps (apps that need access to more sensitive or implicit APIs, or things we generate with customiser etc) - Paul > On 5 May 2015, at 7:06 am, Jonas Sicking <[email protected]> wrote: > > 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 > <[email protected]> wrote: >> 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 >> 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 >> > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
