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
Let me elaborate on why I don't believe in signed web-sites. Signed code is GREAT. However, it doesn't have any meaning for END-USERS as a way to determine if code is to be trusted or not. The AppStore/Vetted approach has therefore become the norm but it is device/vendor/OS- dependent. I think it will stay like that which is yet another reason why signed web-sites won't fly. Another hurdle is that there's no evidence that Apple, Google and Microsoft actually intend to duplicate their sensitive APIs for usage on the web, and particularly not as standards. This posting by Google is worth looking into: https://lists.w3.org/Archives/Public/public-web-security/2015Feb/0034.html That's why I'm advocating a web which allows you to securely connect to the already established native (in FFOS proprietary HTML5/JS) world. Anders _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
