Outside of the privacy concerns, internet keywords is really quite a good idea. On a larger basis, the privacy concerns are not any worse than the use of DNS, which allows the logging of all browser destinations anyhow. That being said, one logical direction to go, would be to use IK as a replacement for URL resolution of a user-entered string. Currently, the IK implementation reflects the original thinking, which was effectively take unresolvable user-entered input, and send it to a search engine to attempt to present a set of alternatives to the user. The cause of this problem was largely the fact that putting user navigation of the web over DNS was a bad idea to begin with (that's why some things are so hard to find). What might be better, would be to improve IK servers so that they could handle all user strings. Server abstraction would have the traditional centralization advantages (upgrades, new features, network profiles, etc.) In order to do this, IK would need to send all input (including single words) directly to the keyword server, rather than trying to do DNS resolution first. This would also disable the behavior described in other bugs about punctuation or other special combinations have special meanings that nobody has figured out. In effect, it would solve all IK syntax related bugs, because you send all the problems to the server logic. A smart IK server provider would offer a server preference that emulates the default (not so great in my mind) client behavior. This would keep likers of the old ways happy. For example, if you were in that compatability mode, then requesting "warp" would do keyword:warp -> "http://keyword.netscape.com/warp", and return a redirect to "http://warp.mcom.com". The net effect is easy to describe: Take everything in the location field, UTF-8 encode it and do an HTTP get on the keyword URL prefix + the UTF-8 encoded string. This would probably be best done as a preference mode.

Yikes! This is wrong, IMO. Reasons: 1. Performance A DNS request to a server at the provider's network is *much* faster than a request to an HTTP server in the USA. 2. Centralization would have the traditional centralization advantages (upgrades, new features, network profiles, etc.) ... and disadvantages. Centralization is considered a bad thing on the internet. The spirit of the internet is decentral. For example, 3. Privacy On a larger basis, the privacy concerns are not any worse than the use of DNS, which allows the logging of all browser destinations anyhow. No. * DNS resolves the hostname only, not everything the user entered (pathname and all). That's already a large difference. * The DNS is decentral, the information is publically available. This means that there are countless of DNS servers and they are simple to switch. This in turn means that if I have only small privacy concerns about one DNS server, I can simply switch to another, without noticing any difference in service. * This also means that ISPs can offer their own DNS servers, and are doing so. The ISP already knows practically all data anyways, so I don't expose info more. (I would expose info more, if I sent it to Netscape or Google.) * ISPs, incl. IP traffic and DNS servers, have a different legal status (here in Germany / Europe) than websites (i.e. your keyword provider), I think. ISPs just transport data (in that case, from the authorative DNS servers), while websites offer data (in that case, search results). Those who transport data generally have to follow the 'secrecy of post' law in our constitution. Those who offer the data are the recievers - I sent the data to them, so they have much less stringent rules about privacy. * Netscape and Google are in the USA. DNS servers are in Germany. Totally different privacy laws (practically non-existant vs. strong). (There are German search engines, granted, but you won't configure them by default, I guess.) 4. Customization if I don't like the lookup rules of my browser, I can change them simply (open-source). I can't change the server. How would you implement preferences for the lookup rules? Do you want users to use accounts? (->privacy hell) Recommending WONTFIX.

ops, the > marks are lost during copy&paste. "would have the ..." and "On a larger basis, ..." were quotes. I wrote: > (I would expose info more, if I sent it to Netscape or Google.) Not only does a new party come in, the data also travels over the whole internet, traceable back to me. This is not true for DNS: outside the provider's network, it is very hard to see, which user made which request, and most requests are even cached.

random thoughts: 1) I like this idea, but only if I can configure the IK server (as I can currently). I don't have to worry about HTTP lag because I'll use localhost. 2) if this behavior is on by default, users will see mozilla as slow. type stuff -> HTTP to IK server -> result to browser -> DNS lookup vs type stuff -> DNS lookup this will be a very legitimate gripe when network traffic is congested or when the user is stuck behind a narrow bandwidth pipe

I would like this to be an option, so if there are objecctions, their relevance is somewhat conditional to adding this feature. Also most of these are objections to IK in general, so they really belong in bug 76547. However, to address you points: 1 I have a working server, and it is not much slower, because it sends back a re-direct. So many sites are redirected, multi-server or multi-part that nobody I have demoed my server to have complained about speed. Also, since the user can type a single string and get to where they want, there is a huge type-to-page view improvement. How many people type the same query in google to go to a page because they don't want to add bookmark #111 to their toolbar or bookmark listing? 2 Centralization of profiles is desirable to a large number of users and service providers in many contexts. That objection is very textbook. DNS is centralized and has created horrible, unsolvable namespace conflicts. A configurable kewyord server would be MORE decentralized, for example, I have my own keyword server now, and I can call it whatever I want. "Train schedule" brings up the train schedule. "Buy books" brings up amazon. "go pik" goes to my personal internet keyword server. 3 Privacy is very complicated, and there is no net decrease. The main reason is that this feature is replacing DNS as the user-input -> URL resolution method, so they have largely the same function and network behavior. DNS is not encrypted, HTTPS can be used for IK. Privacy at the HTTP URL level is compromised anyhow, because you still send out a GET for an HTTP URL. You are also assuming that this feature will be used by large service providers. An IK server can be any web server, so there are many intranet, VPN, localhost applications that can be done. 4 Uh, the number of the people on earth who can modify this code are relatively few. The IK server I use was written by a friend in Java. I passed Java 101, and I am already working on modifying the code. Regarding the most recent comment: Yes it might not be desirable for very slow connections. However, maybe a persistent connection (and the fact that some redirects are cached), could be used to increase the net performance. Remember, the total page load latency is usually caused by page complexity, all you add is another re-direct on the front.

> I have a working server, and it is not much slower, because it sends back a > re-direct. Do a calculation, based on the working of TCP/IP and roundtrip times (Germany<->Netscape: >200ms) and you will see that each HTTP request takes at least 0.5-1s. That's *a lot*, when comparing with the times that the Mozilla developers try to optimize for. *You*, with your 30ms SF broadband connection, might not see much of a difference, but the vast majority of users doesn't have such a good conenction to US servers. But even for you, you *add* one request. > Yes it might not be desirable for very slow connections. You are aware that more than 90% of the users fall in the above category (either POTS modem or phyically too far away from the IK server)? > However, maybe a persistent connection You want the Netscape webservers hold a persistant connection to *each and every* browsing Netscape user out there? I think that web servers can't hold more than several thousand simultanous connections... Maybe go to somebody in the iPlanet group and ask them how many connections a Netscape Enterprise server on a Sun can hold and what they think about this idea. > the total page load latency is usually caused by page complexity With bloated, 150K webpages maybe. But each new HTTP connection/request means significant latency. > Centralization of profiles is desirable to a large number of users and service > providers in many contexts. And undesireable to even more users. > DNS is centralized and has created horrible, unsolvable namespace conflicts. Comparing to your IK server, the DNS is very decentralized. Which namespace conflicts? > I have my own keyword server now, and I can call it whatever I want. Fine. Configure Mozilla to use it, enter "?" before your query string whenever you need it. So, we all have what we want. > The main reason is > that this feature is replacing DNS as the user-input -> URL resolution method, > so they have largely the same function and network behavior. As I outlined, keyword servers will be deployed very differently than DNS servers. If you embed a search function, you need a large, custom search database (expensive) or need to use an external service (expensive). If you don't embed search results, what do you gain over DNS? And I also described the severe implications of "intelligent" resolution servers outside the provider. > Privacy at the HTTP URL level is compromised anyhow, because you still send > out a GET for an HTTP URL. But there is no single point (apart from my provider's network), where *all* my input can be observed. One more reason against this, this alone being a reason to wontfix this bug: 5. Abuse by IK provider There is a large potential for abuse by the IK provider. The provider has full control over where I go - he can redirect me to another site whenever he wants. The only thing holding it back is reputation - but we have seen that quasi-monopolies don't care about reputation. I (or a clueless user) might not even be able to differentiate a redirect by the site from a reditect by the IK provider. This is by far too much power for any company. The power of search engines is already a problem, and you want to extend that unnecessarily (because it's easiler to implement). > You are also assuming that this feature will be used by large service > providers. Right. What will Netscape 6 ship with as default? How many people change defaults? Wasn't the reason for existance of netscape.com (which now claims to be the "real" Netscape) that people didn't even change the homepage? > "Buy books" brings up amazon. That's exactly the problem. Amazon doesn't deserve to be the only response to "buy books". See what I mean? All in all, I think that this, when implemented, will be much hated by a lot of people. Usually exactly the user group of Netscape (people who are longer on the net and those who care about privacy and are against monopolies).

My initial plan for a super-inteligent URLbar was to set my prefs to use my own IK server, and then to invoke calls to that IK server by typing any query with a space character. However, this plan was completely frustrated by bug 115139. Many of my URLbars contain dots. benc: if you really want your own IK server, maybe you could fix bug 115139 and just tap that space bar to have your entire query sent to that server? A suggsted fix is in the initial bug report http://bugzilla.mozilla.org/show_bug.cgi?id=115139#c0 Then, anytime you have a space in your URLbar, and a custom keyword doesn't fit the input, then your query goes to your IK server. You don't need to create a '?' custom keyword as you can just type any multi-word query into the URLbar. If you want to send single-word input to the IK server, then you'll either need to preface your input with ', ' (or something else that isn't a keyword and includes a space) or you'll have to get rid of *all* custom keywords that could conflict with your one-word IK query, and you'll have to fix whatever bug it is that wants 'www.foo.com' resolution of 'foo' to be optional/configurable. I think that custom IK would be less attractive for most users (users who use primarily one browser at home and one at work) if custom keywords were made more powerful/flexible. See bug 124240 bug 98749 bug 123006 bug 124237 (fixes all three of the above, and more) -matt PS: attachment in bug 124237 has some fun custom IK server code

BenB: I'm not saying netscape.com should integrate this feature. With their current keyword server logic, it wouldn't understand anything anyone typed anyhow. And, I think we can add features that work well on faster networks if we don't set the pref default to it. Otherwise, we should go back to the LCD and use LYNX to download GIFs. As for persistent connections, there is a trend for some providers to do massive conncurrent connection hosting, like AOL's IM system. So I think this too is not entirely unfeasible. I think you have a good grasp of the technical aspects of current networking, but miss the big picture. Anyone between you and your DNS server can see which hosts you go to. Also, users already trust DNS and the content provider everytime the request data. Unless you are using SSL (which comes with a hostname/cert check) the problems you describe apply to DNS and http: as well. Thus far, most providers seem to have been reasonable. As for DNS, the top level domains are completely clogged and conflicted. Type "whitehouse" w/ IK off, and you get: http://www.whitehouse.com/ If you want "buy books" to go to bn.com, set up your personal internet keyword list to do that. Or if you want to map it to some yahoo-like directory page that lists every online bookstore in the world, you can do that too. From this point forward, I think we need to talk specifically about the change this feature request makes to IK, not the larger objections to IK. They have their own bug. I think that you are constructing a very specfic case so that you can apply many general objections to what I have suggested here. I don't work for netscape.com (the portal), and setting this to the Netscape 6 default is not discussed in this bug database either. I've also been one of the people behind the push to: 1- Turn of IK by default in the mozilla builds. 2- Change the pref from keyword.netscape.com to something consistent w/ mozilla's needs. -- m m: I think you understand what I am saying here, and why it is a potentially useful feature. Are we in agreement that this proposal (just take everything, spaces, commas, dots, etc) and send it to IK would be a useful mode?) (We might need to do an aboslute URL check first...)

I like the concept. If it were implemented before all the custom kewords fixes were in place, I'd use it. I don't think that most users would use it though, or even that it would be a good thing to expose in the UI... for the same reasons I hate standard stock IK. I think it's a terrific "power user" hidden pref thing tough. So, "yes" I think we're in agreement that it would be a useful mode... for some sense of the word "useful"... I'd use it. You'd use it. I don't know whether 1% of the mozilla user base would use it though. I'd think the only folks using it would be folks with the skill/interest/time to write their own IK server. -matt

> I'm not saying netscape.com should integrate this feature. > I think we can add features that work well on faster networks if we don't > set the pref default to it. I have nothing against this feature, if it's a hidden pref with default to off, and it stays that way. But I am scared that some marketing guy from netscape.com will discover it, think "Cool! More ads! More control! Let's turn this on." and no technical objections will help anymore. > Anyone between you and your DNS server can see which hosts you go to. See comment 1, topic 3 for the differences between DNS and IK. > Type "whitehouse" w/ IK off, and you get: http://www.whitehouse.com/ Bug 34943. > From this point forward, I think we need to talk specifically about the change > this feature request makes to IK The code change should be easy. Still, discussions to wontfix a bug are ontopic. But I had my voice, so I'll leave it to others to add their opinion and wontfix this, if they agree with me. > I think you understand what I am saying here, and why it is a potentially > useful feature. benc, I understand you very well. I understand that for people willing to write and/or setup&customize their own IK server, it will be a quite useful feature. Just that I think that there'll be only a handful of people worldwide who do that and those are probably also able to hack Mozilla's JS itself. And I think that the risk for abuse by netscape.com is way too high.

One thing that no one has mentioned is that sometimes DNS servers inside LANs know of hosts that are not public, and are not in public name servers. For example, here at home, my machine is "bohr.local". I'd be willing to bet most IK servers won't recognize that as a host name, because they will see ".local" at the end and not recognize it. I've seen other non-existant TLDs used as well. It seems what is really being requested here is a way to send every URL typed in the URL bar to a server and let that server decide what to do. Sounds like a proxy server to me. -- Just another guy suggesting WONTFIX.

An HTTP proxy server could do what IK, because it is an application-level proxy that uses HTTP both for the application-layer request and the seesion-level management. However, IK is fundamentally distinct from the purpose of an HTTP proxy, what it really replaces, to some degree is URL (and effectively DNS). It maps a user typed string -> URL. HTTP proxies exist to provide network indirection (and various advantages to centralized web access).

FYI, I've thought about simpler browsers, and this doesn't sound all that wrong to me anymore. I was thinking about it from another angle, namely to get rid of the location bar altogether, never showing the URL (only the hostname) to the user and to offer a search field instead. Of course, that's a dramatic change and will not be liked by many users.

Currently, not enough sites take the trouble to produce useful titles, but I'm glad to hear that my suggestion makes sense.

->default contacts

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420