[b2g] Mobile Banking / Revising the FirefoxOS Keystore
As I understand Firefox OS reuses the Firefox desktop infrastructure for dealing with client keys (X.509 certificates). Although practical this part was designed 1995 and doesn't really match any serious usage including mobile banking. http://images.apple.com/ipad/business/docs/iOS_Security_Feb14.pdf https://www.samsungknox.com/en/solutions/knox/technical Unlike mobile banking applications for Android and iOS, Firefox OS doesn't appear to offer (or does it it?) a low-level non-webbish platform allowing you to bypass the limitations of the web platform. Before going into the specifics, is there anybody out there who is interested in this topic? If so drop me a line at: anders.rundgren@gmail.com ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Mobile Banking / Revising the FirefoxOS Keystore
On Tuesday, March 25, 2014 9:47:48 AM UTC+1, Julien Wajsberg wrote: > Le 25/03/2014 06:44, Anders Rundgren a écrit : > > > As I understand Firefox OS reuses the Firefox desktop infrastructure for > > dealing with client keys (X.509 certificates). > > > > > > Although practical this part was designed 1995 and doesn't really match any > > serious usage including mobile banking. > > > > > > http://images.apple.com/ipad/business/docs/iOS_Security_Feb14.pdf > > > https://www.samsungknox.com/en/solutions/knox/technical > > > > > > Unlike mobile banking applications for Android and iOS, Firefox OS doesn't > > appear to offer (or does it it?) a low-level non-webbish platform allowing > > you to bypass the limitations of the web platform. > > > > In Firefox OS, we don't try to bypass the web platform but to make the > > web platform evolve to cover the use cases you need. > > > > Any idea about this? Yes, I would start by listing possible requirements. One such requirement is PIN-protected credentials. This may sound like a trivial matter but it is not; it requires a fairly substantial rebuild of the provisioning/keystore system. Cheers, Anders > > > > -- > > Julien ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Emulator performance in a VM, X86 version
Since I'm on Windows the quickest route to B2G hacking appeared to be installing it in an Ubuntu running as a VM through VMware Workstation. Unfortunately, it turned out that performance was way below what could be practically useful. Inputting text takes like 10-20 seconds per character... Q: Is this to be expected? For Android app development I have used the X86 version of the Emulator + HAXM and it is really speedy. Q: Any plans to make emulator-based B2G development a bit more realistic? I'm only interested in the platform stuff so I can't use the simulator. Q: Would a standalone box like Dell's XPS 13 with Ubuntu + i7 + 8G RAM and SSD be useful? Anders ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Emulator performance in a VM, X86 version
On Tuesday, April 1, 2014 8:02:01 PM UTC+2, Gabriele Svelto wrote: > > Unfortunately, it turned out that performance was way below what could be > > practically useful. Inputting text takes like 10-20 seconds per > > character... > > > > > > Q: Is this to be expected? > > > > That's surprisingly slow. Running the ARM emulator under Linux yields at > > least a couple of key presses per second in the SMS app. Admittedly I'm > > using a pretty fast machine but a 20x slow-downs seems excessive. It's > > possible that running the qemu's emulation code within VMWare is > > triggering some particularly slow code-paths or something. > > > > > Q: Any plans to make emulator-based B2G development a bit more realistic? > > I'm only interested in the platform stuff so I can't use the simulator. > > > > You should try running it on a native Linux installation. I use the > > emulator quite frequently for development and we even run entire > > test-suites on it. It's slower than an actual phone but not *that* slow. > > > > > Q: Would a standalone box like Dell's XPS 13 with Ubuntu + i7 + 8G RAM and > > SSD be useful? > > > > The emulator speed is almost entirely limited by single-threaded > > performance so the faster box you can buy the better but don't expect > > miracles from it. I'd try running it natively first and contemplate an > > upgrade only if that's still too slow. Thanx Gabriele, I tried the Android emulator as well and got the same result so I must get me a specific B2G-box running Ubuntu. Cheers, Anders > > > > Gabriele ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] The TPM is dead, long live the TEE!
In spite of Microsoft, Intel and Nokia "betting the house" on TPMs (Trusted Platform Modules), all their competitors in the mobile space including Google and Apple, have rather settled on embedded TEE (Trusted Execution Environment) schemes like this: http://www.nasdaq.com/article/samsung-mobilesecurity-platform-to-be-part-of-next-android-20140625-00937 http://images.apple.com/iphone/business/docs/iOS_Security_Feb14.pdf How come the competition didn't buy into TPMs? TPMs are based on a "one-size-fits-all" API philosophy. Since Intel relies on external vendors supplying TPM-components this (IMHO fairly unwieldy) API must also be standardized making the process updating TPMs extremely slow and costly. The constraints on silicon that existed during the "Palladium" days are since long gone. TEEs OTOH can be fitted at any time with application-specific security APIs which both can be standardized or entirely proprietary. In fact, even third-parties can introduce new security APIs using GlobalPlatform's TEE. Converted into practice: My old Nexus 7 got hardware-protected keys through an OTA update while my new Dell XPS-15 will be stuck with TPM 1.2 during the rest of its life! ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Time to dump NSS
IMO, you can't build a modern mobile OS using a cryptographic platform which is 20 years old. NSS was designed when externally provisioned smart cards were [anticipated to be] the norm. Modern mobile OSes have embedded security hardware which NSS's cousin "keygen" doesn't address in a useful (=like Google's U2F) way. Unlike Android and iOS, Firefox doesn't offer (AFAIK) a rich OS with access to secure keys. That may not be necessary either since W3C's WebCrypto could (in an extended version NB...), provide such functionality. For an example of what such an architecture could offer, take a peek at: http://webpki.org/papers/PKI/EMV-Tokenization-SET-3DSecure-WebCryptoPlusPlus-combo.pdf#page=4 Anders ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Time to dump NSS
On Friday, October 10, 2014 7:41:38 AM UTC+2, Anders Rundgren wrote: > IMO, you can't build a modern mobile OS using a cryptographic platform which > is 20 years old. > > > > NSS was designed when externally provisioned smart cards were [anticipated to > be] the norm. > > > > Modern mobile OSes have embedded security hardware which NSS's cousin > "keygen" doesn't address in a useful (=like Google's U2F) way. > > > > Unlike Android and iOS, Firefox doesn't offer (AFAIK) a rich OS with access > to secure keys. That may not be necessary either since W3C's WebCrypto could > (in an extended version NB...), provide such functionality. > > > > For an example of what such an architecture could offer, take a peek at: > > http://webpki.org/papers/PKI/EMV-Tokenization-SET-3DSecure-WebCryptoPlusPlus-combo.pdf#page=4 > > > > > Anders http://webpki.org/papers/SKS-KeyGen2_FullStack.pdf ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Time to dump NSS
On Friday, October 10, 2014 7:41:38 AM UTC+2, Anders Rundgren wrote: > IMO, you can't build a modern mobile OS using a cryptographic platform which > is 20 years old. > > > > NSS was designed when externally provisioned smart cards were [anticipated to > be] the norm. > > > > Modern mobile OSes have embedded security hardware which NSS's cousin > "keygen" doesn't address in a useful (=like Google's U2F) way. > > > > Unlike Android and iOS, Firefox doesn't offer (AFAIK) a rich OS with access > to secure keys. That may not be necessary either since W3C's WebCrypto could > (in an extended version NB...), provide such functionality. > > > > For an example of what such an architecture could offer, take a peek at: > > http://webpki.org/papers/PKI/EMV-Tokenization-SET-3DSecure-WebCryptoPlusPlus-combo.pdf#page=4 > > > > > Anders Firefox OS/NSS seems to lack key confinement: http://webpki.org/papers/key-access.pdf ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] The SIM-card is about to die
On Monday, October 20, 2014 6:59:17 AM UTC+2, Kyle Huey wrote: > On Sun, Oct 19, 2014 at 9:53 PM, Anders Rundgren > > wrote: > > > So this is yet another strong argument for dumping NSS as the core... > > > > This is not the right place for this discussion. You should take this > > to mozilla.dev.security. > > > > - Kyle Although it appears to be a security issue, it is really an architectural and strategy thing which affects a huge number of OS sub-systems as well as several on-going projects. Security forums are usually entirely uninterested in architecture and Mozilla's is not an exception. I hope that some of the people who represent strategy and architecture saw my two messages and took it the right (intended) way: as a friendly advice. I will refrain from further postings on this subject. Feel free exchanging ideas with me privately on anders.rundgren@gmail.com - Anders ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] The SIM-card is about to die
http://www.theverge.com/2014/10/16/6990525/the-sim-card-is-about-to-die That banks, governments and enterprises cannot use the SIM for storing authentication keys made Apple and Google bypass the SIM. I.e. building payment solutions around the SIM which Mozilla is currently doing is not mainstream although it has been talked about since the late 90'ties. So this is yet another strong argument for dumping NSS as the core... Anders ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] The SIM-card is about to die
On Monday, October 20, 2014 7:47:57 AM UTC+2, Fabrice Desré wrote: > Hi Anders, > > > > On 10/19/2014 09:53 PM, Anders Rundgren wrote: > > > http://www.theverge.com/2014/10/16/6990525/the-sim-card-is-about-to-die > > > > > > That banks, governments and enterprises cannot use the SIM for storing > > authentication keys made Apple and Google bypass the SIM. > > > > > > I.e. building payment solutions around the SIM which Mozilla is currently > > doing is not mainstream although it has been talked about since the late > > 90'ties. > > > > The mozPay api is not tied to SIM card at all (see > > https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozPay) so > > I'm not sure how you came to this conclusion. Care to elaborate? I was rather thinking about the SE API. mozPay is another thing which unfortunately is hampered by the limitations of NSS. Anders > > > > Fabrice > > -- > > Fabrice Desré > > b2g team > > Mozilla Corporation ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] The SIM-card is about to die
On Tuesday, October 21, 2014 6:41:16 PM UTC+2, Fabrice Desré wrote: > On 10/21/2014 08:53 AM, Anders Rundgren wrote: > > > > > I was rather thinking about the SE API. > > > mozPay is another thing which unfortunately is hampered by the limitations > > of NSS. > > > > Why is NSS limiting for mozPay? > > NSS is limiting for all kinds of services that could use client-based keys since it doesn't support secure provisioning of keys in TEEs, SEs and similar. However *using* keys with NSS is still a viable solution. See posting "Time to dump NSS" for more references. Anders > > Fabrice > > -- > > Fabrice Desr� > > b2g team > > Mozilla Corporation ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Mobile Banking - App vs. Web
This is sort of a followup to the "Time to dump NSS" posting. Currently mobile banking (which is a VERY popular and useful thing) is performed through "Apps". One reason (not the only) is that using the web leaves you with technology that essentially got its form around 1995 like "" which doesn't match today's security or user-experience expectations. If Mozilla wants to address mobile banking you will either have to create an app-environment that is comparable to Android or define a new web-based security architecture that addresses such applications. I would be interested in participating in the latter because that's something the competition doesn't have. Me-too isn't my cup of tea :-) OTOH, such an architecture should also work with installed web-apps which are necessary to hook into existing mobile banks using Android and iOS. You don't necessarily have to start from zero. You may (using Nightly) try out: https://mobilepki.org/WebCryptoPlusPlus Regards, Anders Rundgren WebPKI.org ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Future of packaged apps
On Thursday, September 11, 2014 12:55:58 AM UTC+2, Jonas Sicking wrote: > On Wed, Sep 10, 2014 at 12:16 PM, Ben Francis wrote: > > It seems that the W3C proposal is incompatible with arguably the main use > > case of packaged apps in Firefox OS, which is the cryptographic signing of > > source code by a trusted party. > > There are quite a few use cases that the W3C proposal is incompatible > with. I'm currently working with various people to try to make the > "!//" a reality, but since it's a change in how URLs, i.e. a change in > one of the fundamental building blocks of the web, it's a change > that's taking quite some time and quite some convincing. > > So so far I wouldn't count out "!//" as a contender for the final > standardized solution. But of course it's also not certain that it > will work. > > I'd rather not bring this proposal to W3C or IETF yet without working > through it with various stake holders to make sure that we iron out > more issues, as well as more thoroughly evaluate more alternatives. > > / Jonas There is a huge set of "security-sensitive" applications that IMO should use an entirely different trust-model but they could probably use the same package format. In spite of relying on signed packages this model would NOT require any user interaction (due to the package NB...), because it is the RESOURCE they refer to that authenticates the package: https://mobilepki.org/WebCryptoPlusPlus The described scheme requires substantial upgrades to the OS and browser but this is anyway required by related stuff like: http://defensesystems.com/articles/2014/11/10/comment-can-derived-credentials-replace-cacs.aspx Firefox OS cannot (AFAICT) enroll two-factor authentication credentials which is a prerequisite for virtualization of PIV/CAC/eID/EMV etc. AndersR ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Calling "Native" Applications from the Web
This discussion is related to the discussion "Can web deprecate packaged apps" which I didn't really saw the conclusion to. https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html I have received information from a Mozilla architect who claims that Mozilla is looking into this. Are there any pointers to that? Anders ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Calling "Native" Applications from the Web
On Monday, February 9, 2015 at 12:45:16 PM UTC+1, pther...@mozilla.com wrote: > On Monday, February 9, 2015 at 5:56:09 PM UTC+11, Anders Rundgren wrote: > > This discussion is related to the discussion "Can web deprecate packaged > > apps" which I didn't really saw the conclusion to. > > > > https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html > > > > I have received information from a Mozilla architect who claims that > > Mozilla is looking into this. Are there any pointers to that? > > > > Anders > > Its an ongoing discussion I believe. I just posted an email to this list > regarding exposing APIs to the web, but also see this thread started by Ben > Francis on dev-webapi: > https://groups.google.com/d/msg/mozilla.dev.webapi/pCY77YAg_i4/NoDBbEziyzoJ > > - Paul I believe the class of applications I'm primarily considering doesn't match any but the Other category. Here there are several problems including lack of security hardware standards, the resources are running under external parties' policies and quite different privacy considerations. I started with the idea of making trusted web apps but it won't scale and in the end only become a burden. I'm currently experimenting with Chrome Native Messaging to verify if my added requirements make sense. Anders ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Granting Permissions to the Web
On Tuesday, February 10, 2015 at 9:51:20 AM UTC+1, Fabrice Desré wrote: > On 02/10/2015 12:44 AM, Wilson Page wrote: > > Regarding access to telephony. We hoped that fxos would get to the point > > where it is so hackable that users could potentially replace the dialer > > app with something third-party. It's a bold move, but it's proof we've > > succeeded in making 'the phone for makers'. > > I'm not convinced that getting apps using the telephony api replaceable > is worth much effort. Getting webrtc to replace these apis, on the other > hand... > > Fabrice > -- > Fabrice Desré > b2g team > Mozilla Corporation I hope that we won't see this: "The site 'merchant.com' wants to connect to your EMV-card, do you agree?" I.e. permissions work for some resources but for cryptographic keys they don't. Anders ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Granting Permissions to the Web
On Tuesday, February 10, 2015 at 11:52:55 AM UTC+1, Julien Wajsberg wrote: > Hey Paul, > > Le 09/02/2015 12:41, Paul Theriault a écrit : > > === SMS === > > SMS is risky mainly due to the cost involved. Risks include cost of sending > > SMS and also SMS are very sensitive - e.g. often used in 2-factor auth > > (e.g. banking) > > > > But there are different use cases. For example, many use cases just need > > the ability to receive SMS - instead of granting SMS permission, we could > > expose a read-only SMS datastore which other apps could observe changes on > > which removes the cost risk (but not the sensitive data risk). > > I don't understand how having a read only access would prevent a webpage > from reading a 2-factor auth SMS. > > I wonder if we could have a permission as fine as giving access to a > specific thread ? > Or access to some properties (the phone numbers) but not others (the SMS > content) ? > > I'm also not sure how a user can choose knowingly whether he should give > access to such things from this webpage :/ Neither am I. I think this calls for "Trusted Web Applications" that would be installed locally but invoked from untrusted code. It would be a complement to https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html Trusted web applications would be signed and be usable in IFRAMEs. Anders ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Deprecating W3C SysApps
Although it is cool standardizing interfaces to various device resources, it comes at a price in terms of slowness and inflexibility. Recently Google publicly declared that they were not going to continue with SysApps which IMO spelled death of this effort. Since Apps using these APIs must be trusted they will need to be supplied from a trusted source which means an "AppStore" and then most of the concept is more like a complex version of http://cordova.apache.org/ at least from a developer point-of-view. Anders ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Deprecating W3C SysApps
On Wednesday, February 11, 2015 at 3:17:36 PM UTC+1, Benjamin Francis wrote:
> On 11 February 2015 at 05:02, Anders Rundgren wrote:
>
>
> Although it is cool standardizing interfaces to various device resources, it
> comes at a price in terms of slowness and inflexibility.
>
>
>
> Recently Google publicly declared that they were not going to continue with
> SysApps which IMO spelled death of this effort.
>
>
>
> Since Apps using these APIs must be trusted they will need to be supplied
> from a trusted source which means an "AppStore" and then most of the concept
> is more like a complex version of http://cordova.apache.org/ at least from a
> developer point-of-view.
>
>
>
> For context, this was the actual email from Mounir at Google
> https://lists.w3.org/Archives/Public/public-sysapps/2014Dec/.html
>
>
> He's saying that Google is still very much involved in working on these types
> of APIs, but they don't think the System Applications Working Group is the
> right place to do that because it was too focused on packaged apps. Which I
> agree with.
Yes, they want to use permissions instead.
>
>
> I don't agree that an App Store is required to add device APIs to the web.
No, but packaged ("trusted"?) apps won't fly without an App Store.
Anders
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Deprecating W3C SysApps
On Friday, February 13, 2015 at 12:29:39 PM UTC+1, Mounir Lamouri wrote:
> On Thu, 12 Feb 2015, at 01:22, Anders Rundgren wrote:
> > On Wednesday, February 11, 2015 at 3:17:36 PM UTC+1, Benjamin Francis
> > wrote:
> > > On 11 February 2015 at 05:02, Anders Rundgren
> > > wrote:
> > >
> > >
> > > Although it is cool standardizing interfaces to various device resources,
> > > it comes at a price in terms of slowness and inflexibility.
> > >
> > >
> > >
> > > Recently Google publicly declared that they were not going to continue
> > > with SysApps which IMO spelled death of this effort.
> > >
> > >
> > >
> > > Since Apps using these APIs must be trusted they will need to be supplied
> > > from a trusted source which means an "AppStore" and then most of the
> > > concept is more like a complex version of http://cordova.apache.org/ at
> > > least from a developer point-of-view.
> > >
> > >
> > >
> > > For context, this was the actual email from Mounir at Google
> > > https://lists.w3.org/Archives/Public/public-sysapps/2014Dec/.html
> > >
> > >
> > > He's saying that Google is still very much involved in working on these
> > > types of APIs, but they don't think the System Applications Working Group
> > > is the right place to do that because it was too focused on packaged
> > > apps. Which I agree with.
> >
> > Yes, they want to use permissions instead.
>
> Could you elaborate?
It is possible that I misinterpreted this but I got it from here:
https://lists.w3.org/Archives/Public/public-sysapps/2014Dec/.html
>
> > > I don't agree that an App Store is required to add device APIs to the web.
> >
> > No, but packaged ("trusted"?) apps won't fly without an App Store.
>
> Why are they needed?
I'm not sure if you are referring to App Stores or "trusted" but let's take an
example of the kind of stuff I work with:
http://webpki.org/papers/decentralized-payments.pdf
If the "wallet" would an app it would need to be trusted since it deals with
keys issued by a bank or similar. Code-signing *would not* suffice, at least
not for Apple. Then we have the little snag that standardized interfaces to
security hardware seems to be impossible to get consensus on. Still the
application interface could be standardized, i.e. "wallet" to merchant
operations.
Anders
>
> -- Mounir
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Running trusted code in the untrusted web - A writeup
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0644.html ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Running trusted code in the untrusted web - A writeup
On Tuesday, February 17, 2015 at 2:17:18 PM UTC+1, Benjamin Francis wrote: > On 17 February 2015 at 05:32, Anders Rundgren wrote: > > > > > > > > > > This code should appear to the browser as coming from a virtual domain. Interesting! If the docs are correct this is currently only available for Firefox OS. > > > > app://myapp.com > > > Unfortunately it turns out that it isn't safe to embed trusted code inside > untrusted code in this way because it provides a vector for clickjacking > attacks. That's indeed a drawback although the primary motivation behind my take on trusted web application is protecting the platform against malicious server code. Protecting users against malicious servers seems like a more generic issue. I guess it is technically very difficult forbidding alien windows covering the trusted iframe? Anders ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Running trusted code in the untrusted web - A writeup
On Tuesday, February 17, 2015 at 4:13:43 PM UTC+1, Anders Rundgren wrote: > On Tuesday, February 17, 2015 at 2:17:18 PM UTC+1, Benjamin Francis wrote: > > On 17 February 2015 at 05:32, Anders Rundgren > > wrote: > > > > > > > > > > > > > > > > > > > > This code should appear to the browser as coming from a virtual domain. > > Interesting! If the docs are correct this is currently only available for > Firefox OS. > > > > > > > > > app://myapp.com > > > > > > Unfortunately it turns out that it isn't safe to embed trusted code inside > > untrusted code in this way because it provides a vector for clickjacking > > attacks. > > That's indeed a drawback although the primary motivation behind my take on > trusted web application is protecting the platform against malicious server > code. > > Protecting users against malicious servers seems like a more generic issue. > > I guess it is technically very difficult forbidding alien windows covering > the trusted iframe? > > Anders A more complete description: http://webpki.org/papers/trusted-web-apps.pdf ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Mozilla's quest for the "Holy Grail"
If I were Mozilla I would call off the quest for the "Holy Grail" (the open portable web), because: 1) It probably doesn't exist 2) It is incompatible with the non-FFOS world which have no problems whatsoever writing "Apps" 3) Will never be able to support a large class of intrinsically proprietary systems like payments not to mention security hardware 4) It eventually makes Mozilla weaker A better solution is looking into Chrome Native Messaging which still enables the world creating fully platforms-independent web applications which is what really counts. Chrome Native Messaging should also have a fairly small footprint both as an implementation as well as a true web standard. Cheers, Anders Rundgren http://blog.chromium.org/2013/10/connecting-chrome-apps-and-extensions.html ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Mozilla's quest for the "Holy Grail"
On Thursday, February 19, 2015 at 4:25:23 AM UTC+1, Anders Rundgren wrote: > If I were Mozilla I would call off the quest for the "Holy Grail" (the open > portable web), because: > 1) It probably doesn't exist > 2) It is incompatible with the non-FFOS world which have no problems > whatsoever writing "Apps" > 3) Will never be able to support a large class of intrinsically proprietary > systems like payments not to mention security hardware > 4) It eventually makes Mozilla weaker > > A better solution is looking into Chrome Native Messaging which still enables > the world creating fully platforms-independent web applications which is what > really counts. > > Chrome Native Messaging should also have a fairly small footprint both as an > implementation as well as a true web standard. > > Cheers, > Anders Rundgren > http://blog.chromium.org/2013/10/connecting-chrome-apps-and-extensions.html Suggested enhancements to Chrome Native Messaging: http://webpki.org/papers/web2native-bridge.pdf Note: This take on the matter is a pure API not depending on additional extensions ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Mozilla's quest for the "Holy Grail"
On Thursday, February 19, 2015 at 8:31:36 AM UTC+1, Anders Rundgren wrote: > On Thursday, February 19, 2015 at 4:25:23 AM UTC+1, Anders Rundgren wrote: > > If I were Mozilla I would call off the quest for the "Holy Grail" (the open > > portable web), because: > > 1) It probably doesn't exist > > 2) It is incompatible with the non-FFOS world which have no problems > > whatsoever writing "Apps" > > 3) Will never be able to support a large class of intrinsically proprietary > > systems like payments not to mention security hardware > > 4) It eventually makes Mozilla weaker > > > > A better solution is looking into Chrome Native Messaging which still > > enables the world creating fully platforms-independent web applications > > which is what really counts. > > > > Chrome Native Messaging should also have a fairly small footprint both as > > an implementation as well as a true web standard. > > > > Cheers, > > Anders Rundgren > > http://blog.chromium.org/2013/10/connecting-chrome-apps-and-extensions.html > > Suggested enhancements to Chrome Native Messaging: > http://webpki.org/papers/web2native-bridge.pdf > > Note: This take on the matter is a pure API not depending on additional > extensions This concept (Web-Portable/Platform-Proprietary) is BTW already established: HTTPS Client Certificate Authentication is supported by all browsers since almost 20 years back. It exposes a fully standardized interface to Web Applications which simply is an URL. In spite of that it is entirely proprietary with respect to integration in the browser platform with implementations based on PKCS #11, CryptoAPI, JCE, .NET, NSS as well as working with a huge range of secure key-containers like SIM, PIV, TEE, TPM, "Soft Keys". This side of the coin has not been standardized since it [provably] wasn't needed. ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Mozilla's quest for the "Holy Grail"
On Thursday, February 19, 2015 at 2:46:47 PM UTC+1, Anders Rundgren wrote: > On Thursday, February 19, 2015 at 8:31:36 AM UTC+1, Anders Rundgren wrote: > > On Thursday, February 19, 2015 at 4:25:23 AM UTC+1, Anders Rundgren wrote: > > > If I were Mozilla I would call off the quest for the "Holy Grail" (the > > > open portable web), because: > > > 1) It probably doesn't exist > > > 2) It is incompatible with the non-FFOS world which have no problems > > > whatsoever writing "Apps" > > > 3) Will never be able to support a large class of intrinsically > > > proprietary systems like payments not to mention security hardware > > > 4) It eventually makes Mozilla weaker > > > > > > A better solution is looking into Chrome Native Messaging which still > > > enables the world creating fully platforms-independent web applications > > > which is what really counts. > > > > > > Chrome Native Messaging should also have a fairly small footprint both as > > > an implementation as well as a true web standard. > > > > > > Cheers, > > > Anders Rundgren > > > http://blog.chromium.org/2013/10/connecting-chrome-apps-and-extensions.html > > > > Suggested enhancements to Chrome Native Messaging: > > http://webpki.org/papers/web2native-bridge.pdf > > > > Note: This take on the matter is a pure API not depending on additional > > extensions > > This concept (Web-Portable/Platform-Proprietary) is BTW already established: > > HTTPS Client Certificate Authentication is supported by all browsers since > almost 20 years back. > > It exposes a fully standardized interface to Web Applications which simply is > an URL. > > In spite of that it is entirely proprietary with respect to integration in > the browser platform with implementations based on PKCS #11, CryptoAPI, JCE, > .NET, NSS as well as working with a huge range of secure key-containers like > SIM, PIV, TEE, TPM, "Soft Keys". This side of the coin has not been > standardized since it [provably] wasn't needed. http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/ I guess this declaration adds credibility to the idea of building on Chrome Native Messaging. ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Granting Permissions to the Web
On Thursday, February 19, 2015 at 9:19:40 AM UTC+1, Anne van Kesteren wrote: > On Wed, Feb 18, 2015 at 7:16 PM, James Burke wrote: > > Mobile use is really large. Native mobile apps do not have > > restrictions from these APIs. > > As indicated most don't need them either. > > > > If web sites are concerned about getting > > cross domain hits, they can get them now from native apps. > > The only reason "native apps" have these is because they are centrally > vetted and distributed. And not having that is what makes the web > great. In some peoples' eyes this rather cripples the web since it can't run trusted (vetted) code which after the demise of NPAPI and ActiveX become an even bigger issue. http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/ > > > > We definitely need to be careful, making sure we do not pass things > > like cookies for these types of requests, and to also allow for > > services to explicitly indicate they do not want to allow these types > > of connections, but what has been suggested instead of using these > > types of APIs does not seem better. > > XSRF is not the primary concern. Firewalled content is the concern. > > > -- > https://annevankesteren.nl/ ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Apps and Sensitive APIs
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 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 cook
Re: [b2g] Apps and Sensitive APIs
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 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 grea
Re: [b2g] Apps and Sensitive APIs
If you take a peek in https://code.google.com/p/chromium/issues/detail?id=378566 you will note that popular services like Spotify and Dropbox depend on bypassing the browser through a non-standard and troubled extension-scheme. ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Apps and Sensitive APIs
On Tuesday, March 17, 2015 at 7:06:21 AM UTC+1, Anders Rundgren wrote: > If you take a peek in > https://code.google.com/p/chromium/issues/detail?id=378566 > you will note that popular services like Spotify and Dropbox depend on > bypassing the browser through a non-standard and troubled extension-scheme. GitHub uses another [even more useless] browser bypass scheme: github-windows://openRepo/https://github.com/cyberphone/webpkisuite-4-android ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Service like apps
On Tuesday, March 24, 2015 at 1:14:26 AM UTC+1, Dave Huseby wrote: > Paul and I were discussing this in the context of the proposed > crypto-ish hardware framework. I'm replying here to get some more > eyes on what we discussed. > > Using apps to provide services via IAC of some form is a good approach > to adding support for crypto-ish hardware (e.g. secure elements, > yubikeys, hardware bitcoin wallets, hardware entropy sources, etc). > > What I'd like to see is crypto-ish hardware manufacturers creating > signed apps that we can grant access to restricted APIs for talking to > their hardware (i.e. Yubico writes a signed Yubikey app that gets > access to their hardware and can respond to IAC requests from other apps > ). > > This avoids having to figure out how to give 3rd party apps direct > access to the hardware. It puts the responsibility of supporting a > piece of hardware into the hands of the manufacturer. It allows for > supporting a multiplicity of crypto-ish hardware without having a > specific API for each one. > > I'm currently attempting to build a prototype certified app that will > access a Secure Element and respond to IAC requests from other > certified apps. > > Some of the prototype use cases we've thought of are: > > 1. Storing an encryption key on the Secure Element and using it to > encrypt/decrypt email credentials so that we no longer store them in > the clear. > > 2. Creating a generic key store Secure Element applet and allowing > other apps to generate and store the keys on the Secure Element > instead of on the flash. > > 3. Implementing a shared secret + time one-time-password applet for > the Secure Element and using that for two-factor auth. > > Ultimately, I want 3rd-party apps to be able to talk to the service > apps, but for now I'm just trying to prove that this is viable for > certified apps. > > WDYT? This sound very interesting. Would these services be available in the "Open Web"? Would they be useful for other platforms as well? ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Web NFC Interface Proposal
https://cyberphone.github.io/openkeystore/resources/docs/webnfc--web2device-bridge.pdf ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] New security model without package (was: Re: Rethink Hosted Packaged App)
In my opinion Mozilla is trying to solve the wrong problem. The walled garden App Stores required for Android and iOS haven't limited their success, right? The really big problem is that the "Open Web" have become toothless after the deprecation of plugins and other security actions which is making the "App" approach the only realistic option for important things like mobile payments. The W3C "Web Astronauts" have actively reduced the power of the Open Web by downplaying and actively deprecating extension schemes which are absolutely instrumental for keeping the Open Web up and running and comparable to its native (and currently much more powerful) cousin! Sorry for being a PITA but this is dead serious. Anders Rundgren ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] New security model without package (was: Re: Rethink Hosted Packaged App)
On Saturday, April 18, 2015 at 1:17:27 PM UTC+2, Tim Guan-tin Chien wrote: > Anders, > > I am pretty sure your reply is unrelated to the topic here. IMO, these things represent different visions on how the web (and thus also Firefox OS) should or could evolve. > Even if they are related, I am pretty sure the direction of the > security model work is not entirely opposite. Based on private communication on the Mozilla IRC, it seems that the general view is that the native layer should be DUPLICATED into the Open Web. This is not possible except on paper and therefore I think Mozilla should accept the idea that locally installed HTML5/JS apps is just another form of "App" technology. By doing that you can progress Firefox OS in a faster and more constructive way. Hosted apps using privileged calls represent an "edge case" that Mozilla may equally well forget which also allows you to radically simplify the security model. The recently started W3C Web NFC CG highlights the close to religious problems we have, where the conveners claim that Web NFC needs Web technology which is utterly wrong except for one and very interesting use-case: Interacting with untrusted Web pages like we currently do with QR-code. However, the CONNECTING party certainly doesn't need to have a "WebOS" to use that in similarity to any other NFC use-case I'm aware of! Anders Web + Native = Killer Combination > > Tim > > On Sat, Apr 18, 2015 at 6:16 PM, Anders Rundgren > wrote: > > In my opinion Mozilla is trying to solve the wrong problem. > > > > The walled garden App Stores required for Android and iOS haven't limited > > their success, right? > > > > The really big problem is that the "Open Web" have become toothless after > > the deprecation of plugins and other security actions which is making the > > "App" approach the only realistic option for important things like mobile > > payments. > > > > The W3C "Web Astronauts" have actively reduced the power of the Open Web by > > downplaying and actively deprecating extension schemes which are absolutely > > instrumental for keeping the Open Web up and running and comparable to its > > native (and currently much more powerful) cousin! > > > > Sorry for being a PITA but this is dead serious. > > > > Anders Rundgren > > ___ > > dev-b2g mailing list > > dev-b2g@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Fizz - Google project for powering the Web
http://www.cnet.com/news/with-fizz-google-hopes-to-bring-new-power-to-mobile-web/ I think this all wrong. DUPLICATING the native layer in the Open Web only creates gigantic standardization efforts and poor user interfaces due to mismatching security and privacy models. COMBINING these layers is a much faster, cheaper and expandable way keeping the Open Web "alive and kicking". BTW, does the world at large really care that much about the Open Web? I certainly do, but I doubt that this is universal. Anders ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Fizz - Google project for powering the Web
On Tuesday, April 21, 2015 at 2:56:36 PM UTC+2, Lewis Cowper wrote: > While they're calling it Fizz, according to > https://plus.google.com/+FrancoisBeaufort/posts/V6vWgFnKK75 it's actually > just a fancy name for API tech that's already kicking about. > > From there: > > - Service Workers¹ provide a way for applications to reliably "go offline". > - Push API² used by application servers to send messages to web apps, whether > or not the app is active in a browser window. > - Network Information API³ to access the underlying connection information of > the device. > - Geofencing API⁴ makes it possible to be notified when a device enters or > leaves specific regions. You are right. My objection to this is really the linked article http://www.cnet.com/news/can-the-mobile-web-win-back-developers-from-ios-android/ because there's no way you can do useful Web banking or e-gov applications using the mentioned stuff. The mobile web is big loser and the current strategy will make it lose even more unless Android's "WebView" counts as the web. Anders > > > As far as I'm aware (could be wrong, I'm new to all this b2g stuff), this is > just open web stuff that's already being made available to FFOS, especially > the first 3 at least. Not familiar with a similar API to Geofencing, but the > others are definitely available to us. > > > > On 21 April 2015 at 13:21, Anders Rundgren wrote: > http://www.cnet.com/news/with-fizz-google-hopes-to-bring-new-power-to-mobile-web/ > > > > I think this all wrong. DUPLICATING the native layer in the Open Web only > creates gigantic standardization efforts and poor user interfaces due to > mismatching security and privacy models. > > > > COMBINING these layers is a much faster, cheaper and expandable way keeping > the Open Web "alive and kicking". BTW, does the world at large really care > that much about the Open Web? I certainly do, but I doubt that this is > universal. > > > > Anders > > ___ > > dev-b2g mailing list > > dev...@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Aligning on an App Model for the future
On Friday, April 24, 2015 at 5:49:25 PM UTC+2, Peter Dolanjski wrote: > As an update, I've created a wiki for the summarized app types here: > https://wiki.mozilla.org/Gaia/App_Definitions#App_Types_Proposal > > Please let me know if you disagree with anything as this will be used as the > basis for the app types that we will support going forward. I really like this summary! For those who like me do a clear distinction between the Open Web and other forms of more or less proprietary web-technology, it would be nice with a row containing standards status which is not limited to the existence of a W3C draft but to actual interoperable competing implementations. Although Mozilla want to avoid the extension issue, the reality is that Chrome's (inferior but anyway "better-than-nothing") extension scheme is gaining traction: http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/ http://blog.chromium.org/2013/10/connecting-chrome-apps-and-extensions.html There are TONS of folks out there who want a from the web-side seen, portable Web app extension method! Yes, this would effectively be another Web app in the table. Anders > > Thanks, > > > Peter Dolanjski > Product Manager, Firefox OS Mozilla > > > On Thu, Apr 16, 2015 at 3:27 PM, Peter Dolanjski 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
Re: [b2g] Addons for FirefoxOS
On Tuesday, June 23, 2015 at 1:22:03 AM UTC+2, Jonas Sicking wrote: > Hi All, > > We've been talking about addons for FirefoxOS for a while. I'd like to > make it more concrete what we want these addons to be able to do. An add-on that is high on the wish-list in the Android community is the ability for third-parties making Web talk with "Apps". This could for example be performed with the navigator.nativeConnect() API now available for Chrome (Desktop) on: https://github.com/cyberphone/web2native-bridge#api Anders > This email is long enough that I didn't want to get inteo too many > details, but clearly there are a lot of details for flush out. Though > we should definitely not figure it all out before we start > implementing. > > *** Capabilities for Addons *** > > First off, what do we want addons to be able to do? > > One thing we should generally do is to look at the Chrome Addon APIs > and see what they enable. I *believe* they have a similar architecture > to what we need, and at this point I would imagine that their API is > fairly mature. So it seems like a good idea to use as a source of > inspiration. > > But a few other ideas below. Obviously we should not implement to > implement all of these capabilities right away. Instead we should pick > the most important/powerful ones first and then implement as time > permits. > > > ** Page scripts ** > > This one is pretty clear in part because we already have basic support landed > :) > > Basically this is greasemonkey. I.e. an addon should be able to inject > a script which is evaluated in the context of a webpage. This script > can take immediate action, as well as add listeners for whatever > callbacks it wants to (events, mutation observers, timers) in order to > do stuff later. > > We should also give these scripts access to additional APIs. Thanks to > some really cool security infrastructure in Gecko, we can expose > access to APIs to the greasemonkey script which runs in a page, > without also exposing that directly to the page. The APIs I'd like to > expose are: > > * Cross site XHR without CORS > * Cross site IndexedDB > * Cross site localStorage > > It's great if we can make these APIs use the same syntax as is used > for grasemonkey-like functionality elsewhere. I know that greasemonkey > on desktop can access cross-site XHR, so we should be able to reuse > syntax there. > > > ** Add APIs ** > > I'd like to enable addons to add APIs and expose them to web pages. > > The most basic version of this is to enable the addon to expose > postMessage based APIs. Simply enabling the addon to expose a > MessagePort object which the page can used to communicate with the > addon is enough to enable the addon to implement any functionality. > > We can further think about enabling the addon to create more > "javascripty" APIs. I.e. APIs that look like real DOM APIs with > objects and functions. Possibly this can be done by using the page > script feature above. > > One of the big use cases here is to enable partners to expose custom > functionality to their own apps and websites. Other use cases are > enabling addons which expose sensitive functionality only to certain > trusted websites, and shimming APIs that aren't yet available in > Gecko. > > > ** IO behavior ** > > Another category of addons that I'd like to implement is network > policies. This can be used to implement things like ad-blockers, > privacy policies, virus scanners, parental controls and usage of > compressing proxies. > > On desktop a combination of nsIContentPolicy and various notifications > like "http-on-modify-request" supply this functionality. I believe > Chrome has a far cleaner addon API that we should look at for > inspiration. > > I.e. I would like an addon to be able to register for getting called > any time a network connection is attempted, or a network result starts > coming back. In the callback the addon should get metadata about the > request, such as if it's for an image load, a XHR load, what URI is > being loaded, what the URI of the loading page is, etc. Based on this > information the addon should then be able to modify that request, for > example by cancelling it, by providing a different result, or by > modifying request headers, by redirecting it, etc. > > But websites no longer just read and write data to the network. We > should do similar things for reading/writing to localStorage and > IndexedDB (and in the future the Cache API). I.e. we should add the > ability for an addon to react when data is written to these APIs, and > to respond with "fake" results when data is read from these APIs. > > Use cases for this could be syncing a given website data to a server, > exporting/importing data from a website, clearing tracking information > from a website, or cheating in games :) > > > ** Device data ** > > This is similar to IO behavior. However with network requests and data > stored in localStorage/IndexedDB, the
[b2g] Mozilla's plan to implement Native Messaging
https://wiki.mozilla.org/WebExtensions#Additional_APIs Native Messaging is a great concept but the current solution is only a crude "workaround". ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Removing
This is not only related to Firefox OS. Google and Mozilla is apparently planning to remove where Google's position is that the classic x.509 use-case is invalid on the Web for privacy, security, and usability-reasons. This position is out of proportion since the (real-world) privacy problems created by eID are hardly measurable compared to for example Gmail and Facebook, not to mention mobile phone operators who not only know who we connect to, but also where we are geographically. ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Removing
On Monday, September 14, 2015 at 8:43:25 AM UTC+2, Paul Theriault wrote: > is not implemented on FxOS. > > > > On 12 Sep 2015, at 11:52 am, Anders Rundgren > > wrote: > > > > This is not only related to Firefox OS. > > > > Google and Mozilla is apparently planning to remove where Google's > > position is that the classic x.509 use-case is invalid on the Web for > > privacy, security, and usability-reasons. > > > > This position is out of proportion since the (real-world) privacy problems > > created by eID are hardly measurable compared to for example Gmail and > > Facebook, not to mention mobile phone operators who not only know who we > > connect to, but also where we are geographically. > > ___ > > dev-b2g mailing list > > dev-b2g@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-b2g I guess I'm at loss understanding what kind of crypto platform Mozilla intends (long-term) to support in FxOS ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
