Hi Jonas, The subject you brought up is IMO the #1 question not only for Mozilla but for the Web at large.
I think my recently updated document http://webpki.org/papers/web2native-bridge.pdf pretty well describes ONE way ahead which essentially is a "Semi-Open" Web. Although the document is targeting "Security Applications", the principle should be applicable to other kinds of application as well. Unfortunately I get the feeling that the Web is stuck, leaving the market with Android and iOS apps as the only viable solutions. That's surely NOT my goal! I don't see signed websites as the future; websites referring to locally installed web-apps in IFRAMEs have a sounder deployment- and trust-model and also requires much less standardization to work. Cheers, Anders On Tuesday, March 10, 2015 at 1:24:18 AM UTC+1, Jonas Sicking wrote: > (Sorry to change from dev-webapi to dev-b2g, but I think dev-b2g is > better given the size of these changes). > > On Wed, Feb 4, 2015 at 4:49 AM, Benjamin Francis <bfran...@mozilla.com> wrote: > > 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. > > Hi All, > > This matches pretty closely with my thinking as of late. > > I think there are a few things that we need to realize and accept. > > First off, it's really hard to "move the web". Especially with a > marketshare as long as FirefoxOS has. If we're going to stand any > chance of actually changing web developer behavior at large, we need > at the very least Firefox for Android and Firefox desktop to push for > the same changes. But realistically also other browser vendors. > > In this light, I would say that some of our efforts of trying to make > the web more "appy" has been a mistake. Though one that we've learned > a lot from I think. We should make sure that this experience is used > as we work on standards like web manifests and web activities. > > > Second, I think we need to accept the fact that some of the APIs that > are needed to build a complete OS simply aren't safe to expose to > untrusted content authors. > > As long as the web maintains a model that content can be consumed > without users having to worry about security concerns, and be > published without any need to go through reviews, there has to be > limits on what type of content that can be created. And I think > there's broad agreement here that we don't want to give up that model. > > I don't think statements like "being able to write an irc client is a > minimum" is really fair. We could likewise say "being able to run an > run any software without worrying that it's going to reconfigure your > router is a minimum", which is a statement that all other platforms > fail. > > That said, I'm all ears for constructive ideas for how we can solve > shortcomings of the web platform. But I also think we should also keep > this in perspective. There's a lot of content on the web. All of it > has been built without access to these APIs. Even for content that is > explicitly built for FirefoxOS and submitted to the Firefox > marketplace, only about 5-10% need these APIs. > > > Third, there is essentially no interest from other browser vendors to > "standardize" or even get alignment on APIs that can't be exposed to > normal webpages. > > Google is about as interested in aligning their chrome apps APIs with > our APIs, as they are to listen to us about what their Android APIs > should look like. Other vendors have shown about the same amount of > interest. > > There just isn't much value in anyone changing their APIs. Authors > aren't really asking for it, and the platforms are different enough > that authors wouldn't see large benefits anyway. > > One interesting question to ask here is, would we be interested in > adopting Tizen's API for, for example, SD card access? Or Chrome-app's > API for TCPSocket? > > > So what does this mean that we should do? > > First off, I think we should get rid of "apps" as a platform feature. > This doesn't need to mean that we should change the UX of B2G. That is > a separate consideration. > > But we should get rid of cookie jars. And accept the web for the big > goop of content that it is :) > > We could add features to allow websites to indicate that it wants the > security protections that the current cookie jars support. But per the > above, that's not a feature that we should push through FirefoxOS > alone. If it's something that we think is important, we should push it > as a web feature together with Firefox desktop and other browser > vendors. > > > I think we should also keep exposing "sensitive APIs", both to gaia > and to 3rd party developers. Converting all the email servers in the > world to use CORS simply isn't realistic. But we should make > improvements in how these APIs are exposed. > > I do think that we still want code that uses these "sensitive APIs" to > be signed. However that doesn't mean that we have to keep using the > same model, of app:-protocol and installable zip files that we > currently use. > > There's a few things that I think would be great to accomplish for > content that uses these sensitive APIs: > > * 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. > * 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. > * Enable Marketplace to hand out the ability to use a particular API > to a developer, rather than to a particular version of a particular > app. > * Remove technical separation between "privileged" and "certified" > APIs. We can still decide not to grant any third party content the > ability to use, for example, the power API, by simply not granting the > right to use that API to any developers other than gaia developers. > But the client-side code doesn't need to make that decision. > * 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. > * It would be good if we can keep the process separation advantages > that we currently have for content that can use "sensitive APIs". I.e. > it would be nice if it required more than finding a buffer overflow > bug in Gecko in order to gain access to use the telephony API. But > it'd be good if we can hide this fact as much as possible from web > developers. > * I think we should still keep the CSP requirements that we have for > content that uses "sensitive APIs". I.e. all JS that can use those > APIs has to be signed by the developer. > > What signing format to use, and how to keep it not same-origin as > unsigned content, is probably best done as a separate thread. > Hopefully we can get agreement on the rest of this thread without > solving that part. > > I also think we need to stop worrying so much about that these APIs > aren't standardized. It simply isn't in our power to make these really > standardized. It requires that other vendors are actually willing to > work together with us on aligning APIs, and I just haven't seen that. > > And more importantly, very little content is using these APIs. The web > is far greater. Even developers that target FirefoxOS specifically are > 90-95% of the time able to write their content without using these > APIs. > > That said, if anyone wants to make an effort and reach out to other > vendors to get agreement on any API, feel free to give it a try. > > The only thing that I could see being successful in the short term > would be to simply adopt APIs from other platforms. Cordova and > Node.js would be prime candidates here I think. If anyone has > suggestions for APIs that you think would be good candidates, please > let me know. > > > As mentioned above, I think there's still some APIs that I'm very > nervous about exposing to 3rd party websites. For example, enabling > placing phone calls through direct calls to the API, rather than by > using <a href="tel:..."> or a WebActivity seems like inviting malware. > > It's also not a terribly good way to enable users to replace the > built-in dialer. Since the user would still have the built-in dialer. > > A better solution to enable replacing the dialer UI might be to use > some form of addon system. An addon which tweaked, or completely > replaced, the built-in dialer UI would be awesome. > > Likewise an addon which sat between the dialer and the actual phone > hardware, and did things like block lists, or changed incoming and/or > outgoing phone numbers would be great. Or addons which encrypt the > voice audio when calling friends which has the same addon. > > Addons have been great for Firefox desktop. I think it can be as > awesome for FirefoxOS, if not more so. > > Addons will definitely be Firefox(OS) specific. But no more so than > the telephony API is, and is likely to remain for the foreseeable > future. > > Again, I think how exactly how these addons will work is a better > topic for a separate thread. > > > In summary: > > On a technical level we'd be much more like the web has traditionally > been. I.e. no cookie jars or app silos. The user can navigate between > any content by following normal links. This will include content that > use "sensitive APIs". > > 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. > > On a technical level, Gaia would just be normal signed content. The > distinction between "certified" and "privileged" disappear. Though we > can still choose on a per-API and per-developer basis which API we > allow what developers to use. Though UX-wise we might still want to > give gaia special treatment. > > Users can install addons which change the behavior of other content. > This will include both change behavior of gaia, as well as of signed > and unsigned websites. > > > Let me know what you think. > > / Jonas _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
