On Sun, 7 Dec 2014 09:38:36 -0500 Patrick McManus <[email protected]> wrote:
>On Sat, Dec 6, 2014 at 7:21 PM, Christopher Barry < >[email protected]> wrote: > >> >> My strong opinion, and indeed it is the understood expectation of >> anyone using any application that requires name resolution, is that >> all applications always strictly obey the local resolver >> configuration of the host running the application. Period. > Hi Patrick, I understand the spirit of encouraging investigation and development, that's a great thing and I couldn't agree more. I'm personally skeptical that this redundant name resolution scheme wouldn't just adversely impact name servers and make a lot of noise for relatively imperceptible gain if any, especially if deployed at scale. In my experience, it's not name resolution that's the bottleneck in my web usage. It's typically waiting for ad servers to deliver their drivel. And, while I'm also concerned about the potential of user privacy invasion and tracking capabilities that appear, to me at least, to possibly be a subliminal motive for this research, that's just my personal gut reaction and my *opinion*, and not at all at the heart of my objection to this discussion here. please see comments inline... > >I'm going to push back against this notion that operating system >services must always take priority. well, it's not really a notion. it's established secure practice that's in place for a reason. you're going to say that an application should take *priority*, essentially usurp control over system services for it's own particular reasons? possibly behind the user's back where private data will be shared with unknown third parties? huh? doesn't that basically describe how malware operates? i'm reasonably sure you don't really feel that way. > >For instance, windows provides a trust root list that firefox ignores >in favor of its own. That's a design choice. but, the user in this case is free to control this subsystem, no? > >There are several reasons we might do things like that - performance, >security, and the ability to effect legacy configurations for example. >There are also costs in terms of administrative awkwardness, >surprises, and incompatibilities. Its not to be undertaken lightly. increasing performance and security are correct goals within the scope of the application, absolutely, and reasonable defaults are always a good idea too, but i will posit that it's not the domain nor purview of applications to worry about, nor override system functions. If one has an improvement to the behavior of a system function, they should put their energy into helping improve that system function, but it should not be a part of an application where it's use essentially performs an end-run around the existing system function. simply put, that just ain't cool. > >It would be wrong to interpret this mail as supporting the algorithm >being discussed in this thread (I'm basically open minded on the >topic), I'm just saying its plausible to discuss. well that's encouraging. I consider myself open minded as well, but in this case the discussion should be done in the appropriate forum(s). while the work is interesting, and likely requires much more investigation, the suggested behavior is not germane to this forum. > >The much larger problem, to me, is that use of a public dns adds >another party to your transaction: {client, origin, isp, >public-dns} .. its conceivable such an algorithm would boost bingo. and this is why this is a very bad idea unless the administrator-user has complete control over the name servers being used if and when this idea is deployed as a 'system level daemon'. >performance using only multiple isp servers, but there is no evidence >to show that at this point and honestly thin evidence overall. So its >the kind of thing that bears more investigation. agreed. yet for me, and granted maybe i'm missing something important here, but intuitively, it's not clear how this methodology at scale would not eventually settle into similar (or worse) latencies over time, while at the cost of a lot of resource-consuming noise and churning that would, in my view, ultimately impact the latencies of literally all other traffic. but yeah, it may merit more investigation, but probably not here. > >regardless of possible performance benefit. If this is what FF is doing >> now, >> > >Just to be clear - this thread is discussing the results of a small >academic experiment not of general Firefox behavior. I appreciate the >authors bringing it here to discuss - let's keep it a welcoming >environment for exploration. yes, and discussion of it with the idea of possibly helping the authors find a more appropriate forum in which to investigate it's possible merits should definitely be undertaken. i'm certainly not saying that they should not investigate the potential usefulness of their work, nor that if it does indeed prove to be an effective idea, that Firefox (and any other application) would not benefit from that. i'm simply saying that even considering embedding this technology into any application, not just Firefox, is absolutely not the correct approach, and that i would hope members of this forum, knowing that as well, would help to steer the authors in the right direction. for instance, the bind-* or dhcp-* lists may be a good place for these folks to initially discuss their project ideas, and folks there may have additional ideas about other appropriate lists to address, and where and how this technology can be best investigated and evaluated for use in other client operating systems. The bind/dhcp list server: https://lists.isc.org/mailman/listinfo -- Regards, Christopher Barry Random geeky fortune: Round Numbers are always false. -- Samuel Johnson _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
