On Tue, Mar 10, 2015 at 3:35 AM, Antonio Manuel Amaya Calvo < antoniomanuel.amayaca...@telefonica.com> wrote:
> > On 10/03/2015 1:23, 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). > > 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. > > > From a security point of view, I think the cookie jar model is much better > than having everything on the same pile. Maybe rather than getting rid of > that, or even making it an opt-in feature we could try and hide the > implementation details from the content. So we keep a cookie jar per origin > (instead of per-app as we do know, which is really the same since we can > only have one app per origin) and every time that origin is loaded it uses > it's own cookie jar. > We actually tried this on desktop, but it broke the web. The problem is that when a page from http://site-a.com loads a javascript file from http://site-b.com/scripts/library.js it expects to get site-b's cookies. Even more importantly, if http://site-a.com opens an <iframe> to http://site-b.com/widget.html, it's expected that the iframe is loaded using site-b's cookies. While we theoretically could use a different child process to load the <iframe>, Gecko isn't able to do this yet. What I'm hoping we can do eventually, is just that though. I.e. make each origin load in a separate process. Even if the origin is loaded inside an <iframe> inside another origin. That way we could use process boundaries to ensure that a given origin is not able to read data that belongs to another origin. Hopefully this is something that the platform team will start looking at once the initial process separation work is done for desktop. > To keep this isolated at a process level this would mean changing the way > the processes work (having one process per origin instead of one process > per app, for example, so every window that's loaded for > https://a.origin.com lives on the same process independently of where > that window was defined)... but that should be transparent to content > developers. > > 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. > > This is nice... but I believe it's ultimately futile. It works for well > known, giant developers... I could say I trust Google, or Mozilla, or > Facebook... but I don't think it'll work for Pop&Mom SW, Inc. How would > Mozilla know if they should trust them and with what APIs? > This is a good point. I think in practice we're not doing a lot of verification right now. The reviews that marketplace does is done mainly by running the app, rather than by looking at it's source code. But keeping the *ability* to review each app version sounds like a good idea. Then leave it up to the review team when they want to review the app vs. review the developer. Possibly in instances where we can identify, and get legally binding commitments from, a legally liable person, that we can provide more access to that developer. This definitely sounds like something that we should discuss with the marketplace team that's currently responsible for reviews. > > 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. > > The problem here is that we need people using those APIS (or maybe new > ones?) for the platform to move out of the "cheap smartphone for people > that only had feature phones before" segment. And the second problem is > that bootstrapping this requires those APIs to be useable in some form for > the rest of the web. > I'm not sure what you are arguing here. You were pretty strongly arguing above that simply exposing these APIs to untrusted developers was a bad idea :) Like I've said, if anyone has ideas for how we can expose a particular API to the web at large, I'm all ears. > > 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. > > This is actually a very nice way of making those APIs 'reusable' :). > > 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. > > Hmm... I think that while those things would be nice to have, on a geeky > way, we might be losing sight of the target. Replacing the dialer is a nice > configuration option, if we can do it (well, not replacing, *adding* a new > dialer because I think replacing the certified one is a no-go from a > certification point of view), but the phone already *has* a dialer. What we > should worry about is giving developers enough tools to do things the phone > doesn't have but other phones do. For example: > > - IM applications (be it Whatsapp, Line, Telegram, Wickr, whatever, it > should be doable on the new model). > - VoIP applications (Skype). We already have Firefox Hello, which is > nice, and it's packaged, and it uses a bunch of privileged APIs and another > bunch of "they're privileged but only for you" APIs. > - Richer calendar apps with support for public and private servers > (Exchange, Google,... whatever) which might or might not have a nice > REST/HTTP API. > - File browser (since we do have a SD card that can be mounted) > - Wearable APIs (ok, reaching for the moon here but it's something big > that will only get bigger) > > Maybe we're going at this the wrong way... and instead of seeing what APIs > we have or would like to have we should look at what applications we want > our ecosystem to have, and what is needed to implement those applications. > I know we learned a lot about what was missing while writing the Firefox > Hello app. > Agreed. We should definitely continue to find APIs which allows awesome content to be developed for FirefoxOS. But I believe that there will always be some set of APIs which we can't expose to the "untrusted" web. Or at least that for a long time such APIs will exist. This thread was intended to discuss those APIs, old and new. But I definitely think that we should continue to look at adding more APIs. And we should continue to look at modifying the APIs that we have as to make them meet more use cases. That's just not the topic I tried to address in this thread. / Jonas
_______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
