This could easily be built into the Cryptographic Services service or something -- if it's code that comes from the vendor, it's easier to trust than code that doesn't.
The problem is the addition of another attack vector, and having to authenticate to it (unless the process can look at the TCP connection list and see what process opened it, then get the credentials of that process to see who it's supposed to impersonate). This could be mitigated by having it only listen on 127.0.0.1 on some strange port, but it's still not that great. I would rather have another virtual machine entirely running on the same hardware, but that's something of a pipe dream. -Kyle H On 2/13/06, Anders Rundgren <[EMAIL PROTECTED]> wrote: > http://opensignature.sourceforge.net/english.php > > These guys have concluded that Java applets are bad and that you > should exclude the browser altogether by using something called > URL Programming Interface, which in essens hosts a local web-server > for handling the crypto and signature stuff. > > I believe this is similar to the Austrian scheme, although a bit less > documented. > > Personally I think Java is good as a short-term solution but useless in > the long-run as Microsoft would never support a Java-based standard. > The need for accepting native and trusted code during browsing is also > something that does not seem to be ideal. > > Anders R > > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
