- From: <bugzilla@jessica.w3.org>
- Date: Thu, 05 Jun 2014 16:22:22 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985 --- Comment #19 from Mark Watson <watsonm@netflix.com> --- (In reply to Ryan Sleevi from comment #17) > (In reply to Web Cryptography Working Group from comment #14) > > Precisely, I think that is what we discussing doing as well - i.e. change > > "recommended" to "suggested" and then see how tough interop is doing CR. I'm > > not adverse to, if we get widespread interop during CR, to adding some > > algorithms as mandatory to be implement. > > In case it hasn't been perfectly clear, I am strongly opposed to this and > would view it as a blocking issue. > > I suspect that the Google team is the most unique, so far, in their > WebCrypto implementation. I'm not aware of Microsoft's mobile implementation > plans. Apple's plans in theory share the same implementation infrastructure > (CommonCrypto), but I do believe that the iOS implementation is slightly > different than the OS X (certainly has been the case for every one of their > previous APIs). > > However, on the Chrome side, I'm daily dealing with a wide variety of > hardware and platforms. Our abilities on Windows (where we have chosen to > deal with the hassle of shipping crypto ourselves) are different than our > abilities on Linux (where we have not) than our abilities on ChromeOS (where > there is specialized hardware) than our abilities on Android (where there is > variance in capabilities based on the OS level and various hardware > capabilities) than our abilities on other platforms that use Chrome/Chromium > as the basis for capabilities (such as ChromeOS). > > Even if the WG were to say "Tough, that's Google's problem, you can afford > more lawyers and engineers", every other UA that would have these different > profiles is going to be similarly affected. > > This thread has been trying to explain the same issues that have been > present for the past two years. While good to be written down, it doesn't > change the very unfortunate reality of the world, so it would be truly > unfortunate to ignore these issues. It's not clear to me how the above is an argument against what was proposed. The idea would be that at some future point (say a year from now), we look at what has actually been implemented across multiple platforms. You have the advantage that your platform would certainly be included in the ones we look at. If we find there is a common subset that is widely implemented, we make that subset mandatory for future implementations. At least from Chrome's point of view, surely this process would be a noop, since the only things made mandatory would be those you have already implemented ? If we were to follow the above process, there seems also no harm in writing down our 'wish list' for that common subset, making it clear that it is no more than that. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Thursday, 5 June 2014 16:22:23 UTC