gilles Bernabé wrote: > > > 2010/4/29 Anders Rundgren <anders.rundg...@telia.com > <mailto:anders.rundg...@telia.com>> > > I doubt that SCP01 (is that what you refer to or what?) is useful > in browsers but I leave that for you guys to find out :-) > > Gemalto has/is also pushing this concept though: > > http://w2spconf.com/2009/papers/s4p4.pdf > > My opinion is that you need a subsystem in the browser, like > an upgraded <keygen> to actually get somewhere because the > PC/SC approach exposes the card API to untrusted browser code > and that is a genuinely baaaaaaaaaaaaaaaaaaaaaaaaaaad idea. > > Anders > > With XPCOM C++ you can implement counter measures to avoid phishing > attacks or malicious Javascript execution, you can even apply domain > restrictions to a plugin [1]... > In my opinion if the plugin is well implemented, it shouldn't implicate > vulnerabilities for the smart card... > but pherhaps plugins are bad ideas... I don't know yet...
You are right, a well-written plugin shouldn't be a problem. What I *do* consider a problem is exposing PC/SC to browser code. > @Martin > So if there's nothing to install on the client side to execute the Java > applet, that's looks good Concerning Browsers plugin, Although I haven't tried this myself there are a lot of issues with I/O from applets and ActiveX controls. To begin with you need signed code and then you get into this "interesting" question where the user must understand what hes/she is doing. > Yes I think NPAPI is a better choice than > XPCOM because NPAPI is compatible with others browsers like google > chrome, Opera...but it's a different technology, [2]. which suffers by not being supported by Microsoft. So what's the solution? IF there is a solution, it should be endorsed by at least Mozilla so that it becomes a part of the distribution and is maintained over releases. Plugins have a tendency of failing on newer versions of browsers even if they follow APIs because of undocumented side-effects. Anders > > Gilles > > [1] : > http://www.casabasecurity.com/blog/2008/01/how-to-apply-domain-restrictions-to-a-browser-plugin-activex-or-xpcom/ > [2] : > https://developer.mozilla.org/en/Gecko_Plugin_API_Reference:Plug-in_Basics#How%20Plug-ins%20Work > > > Martin Paljak wrote: > > On Apr 29, 2010, at 08:43 , gilles Bernabé wrote: > > Oh interesting, but Java is much more heavy, if I remember > correctly the Java plugin(JRE + JDK) is more than 40mb, the > XPCOM plugin just takes some kb once installed. > > > The ups and downs of Java have been interesting, but these days, > with 1.6 supporting javax.smartcardio it has become quite sexy - > no need for locally installed software or scary JNI bridges > (like PKCS#11) so it is possible to implement card access > software entirely inside and applet so that nothing needs to be > installed on the client side. And of course - applets work > almost in every browser whereas XPCOM does not. > BTW, NPAPI is a much better framework for a browser plugin that > would work on more browsers. Or check out Firebreath [1] > > [1] http://code.google.com/p/firebreath/ > > > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
