On 09/28/2013 12:17 PM, Brian Smith wrote: > On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard <dev+mozi...@seantek.com> wrote: >> On 9/27/2013 5:51 PM, Robert Relyea wrote: >>> I don't have a problem with going for an industry standard way of doing >>> all of these things, but it's certainly pretty presumptuous to remove these >>> features without supplying the industry standard replacements and time for >>> them to filter through the internet. bob > Why isn't <keygen> good enough? > > AFAICT, based on this discussion and others, smart card events are not > a must-have feature for any website. They are a nice-to-have, at best. > At worst, they are the wrong model altogether. Either way, > clearcutting them to make our sandboxing project easier and faster to > complete still seems to make sense for me. I understand that that > isn't the most friendly strategy towards the websites that are using > that feature, but it is extremely unfriendly (at best) of us toward > hundreds of millions of people to be giving them a browser without a > sandbox. Sandboxing is a must-have-ASAP feature. > >> In addition, it would be a great shame to remove this set of APIs from >> Firefox because the Mozilla platform itself uses them for chrome-privileged >> purposes. If you search "smartcard-insert", for example: >> http://mxr.mozilla.org/mozilla-central/search?string=smartcard-insert >> Our >> Firefox extension makes use of these events (in addition to the other APIs) >> so that would directly impact us as well. > Good point. We can still keep them around in chrome-privileged > contexts because chrome-context stuff lives in the parent process and > so would not be affected by sandboxing. So, if we preserved the > chrome-context stuff, would your extensions still work? > >> It is one thing to remove the <blink> tag, which most users have found >> annoying or harmful (epilepsy). Removing crypto functionality in contrast >> impacts critical security functionality for many users. > Again, smartcard events don't seem like critical functionality They are to several customers, who have been limping along despite their lack of support. > and > <keygen> exists. So CRMF exists to handle missing function in keygen (namely key archival). If you have a way of doing that in the current keygen, then it's probably not a problem to remove CRMF. > signText is the only API I can see where there is no > replacement and that would be difficult to go without. But, it is also > problematic because of its UI; I don't think its UI is sufficiently > clear and bulletproof that it is really effective at conveying exactly > what is being signed--especially when you consider > internationalization and localization issues. signText is probably the least used of the three you are talking about removing.
bob
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
