127872 - "Internet Keywords-only" mode for "Location"

Status: RESOLVED EXPIRED

(SeaMonkey :: Location Bar, enhancement)

Description

[benc]

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.

Comment 1

[Ben Bucksch (:BenB)]

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.

Comment 2

[Ben Bucksch (:BenB)]

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.

Comment 3

[m_mozilla]

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

Comment 4

[benc]

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.

Comment 5

[Ben Bucksch (:BenB)]

> 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).

Comment 6

[m_mozilla]

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

Comment 7

[benc]

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...)

Comment 8

[m_mozilla]

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

Comment 9

[Ben Bucksch (:BenB)]

> 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.

Comment 10

[Anthony DeRobertis]

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.

Comment 11

[benc]

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).

Comment 12

[Ben Bucksch (:BenB)]

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.

Comment 13

[benc]

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

Comment 14

[Asa Dotzler [:asa]]

->default contacts

Comment 15

[Robert Kaiser]

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

Comment 16

[Robert Kaiser]

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