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 and <keygen> exists. 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. > The Internet is made good when people can use it to do productive work. > Removing functionality that is used by vendors and users for no reason other > than "purity" is unproductive and costly. My main motivation is to make the sandboxing project easier to complete ASAP. The WebAPI team has the "purity" goal and it isn't my place to judge that, as I don't know as much as they do about the web API standardization situation. > By the logic of "purity", > XMLHttpRequest should have been removed a long time ago because it was an > IE-proprietary feature. The "open web" is an ecosystem of server-side and > client-side technologies where everyone can innovate by introducing new > things. If it's a useful feature, you can copy it. XHR became standardized. Which of the Mozilla-proprietary APIs in window.crypto.* do you think has any chance at all of standardization? Ryan Sleevi is on the Chrome team and works on the W3C Web Crypto API spec., and based on what he's written, he seems to agree with me that they don't. I also agree with Ryan that we don't have to feel committed to these APIs just because we implemented them back when we were trying to make money selling the enterprise server software that these APIs were created to support. So, I'm not going to predicate the removal of these APIs on the creation of replacements. However, there's no reason why this community can't help formulate, standardize, and even implement the replacements before we ship a browser without these APIs. In fact, everybody at Mozilla would love for that to happen. But, also, I don't think we're going to be sad if we ship a sandboxed browser without any such APIs. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
