>> The big problem with that is that this whole concept of "signed >> applet" has zero value. There is no auditing of the app whatsoever, >> everyone with a certificate can sign his app and certificates are a >> dime a dozen.
> Two points here: First, the certificates are cheap, but I think it > would be difficult for you to buy a valid certificate saying that you > are the NIC.br. Mildly difficult, but how many microsoft.com certs have been issued to non-Microsoft people? I've heard of something like four, and I'm not even close to any community where I'd expect to notice such things. > Talking about reputation, NIC.br is the executive arm of the > Brazilian Internet Steering Committe, [...] I probably trust governments _less_, if anything, than other entities. And I'm very vrey deeply cynical about Internet government in particular. Consider, for example, the disaster that CIRA (my own country's ccTLD governance body) has been; see my blah posts of 2010-03-15 and 2012-02-01, available at http://ftp.,rodents-montreal.org/mouse/blah/2010-03-15-1.html and .../blah/2012-02-01-1.html - I certainly wouldn't trust code from CIRA, quite aside from the extent to which I can trust that it really is from them (which latter is all that certs, even when they work, address). > But would you [trust an applet from] the ISC [...]? Or by NTP.org? > [...] If not, this question leads us to the second point: you > already run software that is hosted by ISC or NTP.org, I think (ntpd, > for instance). Would an applet be less secure than a "full" > software? Yes. > In which way? (1) No chance to vet it. When I install software, I can, and not too infrequently do, vet it in various ways. In extreme cases, this can mean reading through the whole thing. In less extreme cases, it can mean running nm over the .o files and looking for references to unexpected calls, then, if any are found, checking the code that gives rise to them. It can also involve grepping through the source. None of this is feasible for code that the client system is expected to fetch afresh each time it's used. (2) Because it's fetched afresh each time it's used, because it's expected to be run by end users with no particular security competence and quite likely on grossly insecure end systems, because it's distributed by a full-fledged webserver, it's a relatively attractive attack target. (3) It's written in Java. Java tends to attract less competent programmers than the C the NTP programs are written in does. While I don't know the competence level of whoever wrote it, _because_ I don't know that I am less inclined to trust it. (4) It's distributed as binaries, making it significantly more difficult to check it over even if I wanted to. > Do you think we should just stop using Java applets, and that it is > wrong to provide an application based on this technology? Is your "we" nic.br, or all Web users, or what? Yes, I think people in general should stop using applets, Java or otherwise; feeding code to be run by an end user's machine live is a security disaster waiting to happen - and, unsurprisingly, it has happened, multiple times, in the history of applets of various sorts. There is a place for them in walled-garden intranets. But across the open Internet, from arm's-length hosts? No, there I believe the risks easily outweigh the benefits. I am aware others disagree. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
