I think you're basically saying that if you had an enhancement that yielded a 10% improvement in overall pageload times, scaled well, and didn't have a privacy or security concern would we consider deploying it in the browser?
If that was the most practical way to reach our users, absolutely. But you've set a pretty high bar and I'm skeptical that this can yield those kind of broad based gains. Prove me wrong and we'll all be better for it. :) -P On Fri, Dec 12, 2014 at 3:53 PM, Vulimiri, Ashish <[email protected]> wrote: > > Apologies for the slow response, I was traveling. > > Suppose (1) we were going to replicate exclusively to whichever DNS > servers the OS has configured, so no trust issues would be raised; and (2) > we had enough large-scale/realistic experimental data to prove the > technique does significantly reduce page load time when used this way. In > your opinion, what would the most appropriate place be for something like > this to be deployed? > > 1. In the browser. > > 2. As a a separate piece of software users would need to install. > > 3. As part of bind or another DNS resolver. > > 4. In the OS. > > > On Dec 7, 2014, at 3:59 PM, Christopher Barry < > [email protected]> wrote: > > > > 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 > > _______________________________________________ > dev-tech-network mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-network > > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
