| TL;DR...that is until I saw you calling me a concern troll. You make it abundantly clear you believe I am far too ignorant to participate meaningfully in this discussion but I wish you had the humility to ask questions when you don't understand something instead of donning the mantle of intellectual superiority and giving a dressing-down to all you deem inferior. The latter has become quite tiresome. Now, with regards to the iOS and Android ecosystem approach, I understand that model and its strengths and weaknesses. With regards to routers and other autonomous devices, I understand that model, too, and its strengths and weaknesses. With regards to the need for interoperability, well here we have a problem. Your insistence that no such need exists betrays your shortsightedness. Let's consider a (hypothetical) situation where I'm a manufacturer of anti-lock braking systems that go into cars made by 5 different companies. If I need to update the controller software for thousands of cars already on the road, it can be a pretty complicated task but it would be good to know I at least have a straightforward means to do it. Viewing this as an ecosystem isn't all that great since I could have 5 (maybe more?) such ecosystems to deal with. Viewing this as an autonomous system gets complicated since there are other systems on the car that my anti-lock braking module needs to work with and there's no clear delineation to be made. How the auto industry should solve a problem like this is not for me to say. In fact I would suggest it's the height of arrogance for anyone in this forum to dictate the ways in which these manufacturers may solve problems. My contention is that we should allow viable solutions to remain viable, and a Mozilla-maintained trust store is a component of one possible solution. As an extra bonus to those still reading, suppose you go to the dealership to get the oil changed in your car and you end up driving away with a anti-lock braking systems that no longer functions properly because it's been compromised by malware: http://www.wired.com/2015/10/car-hacking-tool-turns-repair-shops-malware-brothels/ Finally, I'm deliberately not connecting all the dots in this email to avoid straying too far off topic. If clarification is needed just let me know.
Peter, I can't help but read your replies and reach the conclusion that you may be fundamentally confused about code signing. ... ... Both Apple and the Android ecosystems demonstrate this - both have strong notions of code signing, ... We also know it's not necessary for identity information to be an intrinsic part of code signing. Indeed, if you actually look at the embedded space ... What you're arguing for - which I'd go as far as to suggest it was a active strawman if I wasn't convinced you just earnestly misunderstand - is the specific need for third-party mediated identity information as part of a code-signing ecosystem. ... But I do want to emphasize that code signing is decidedly NOT equivalent to TLS, and this is not a case where you need to interoperate with existing systems, thus necessitating doing 'whatever is necessary'. Codesigning itself is necessarily green field - when you integrate code signing in a product, you HAVE to make a variety of choices about format, signature schemes, validation, etc - and there is zero need to interoperate. ... I do hope you can see why the arguments you present are easily misinterprable as concern trolling; save for the fact that you've participated in past discussions and shown far more consideration, the arguments you've presented for code signing are somewhat indistinguishable from that. I can only hope it was based on a misunderstanding of how both modern and historic systems have deployed code signing, and perhaps confusion over the terminology, rather than deeply held beliefs in spite of that knowledge. Best, Ryan | ||
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
