Re: general question

Apologies for not replying sooner.

On Mon, 1 Oct 2001, Kenji Takahashi wrote:

> Andrew,
>
> I am happy to hear from you again!! You may be right and I do not have
> strong preferences on the format/coding, which is out of scope of this
> working group.
>
> I am more interested in privacy issues on the geo-tag/header.
> I think that using, for example, HTTP HEAD, people can pass around their
> position information. This scenario is a bit different from the one written
> in your draft, which is for search engines....
> Do you have any ideas on how the "Negotiation" written in Section 3.1 of the
> geo-header draft can be done? What is the negotiation protocol? What does
> the "trusted site list" look like? How can users securely store and access
> to the list? etc. I think they are the main topics of this working
> group.....
>

My ideas were modelled loosely on the behaviour of Web browsers
handling of cookies or certificates, or IE's concept of zones.
The trusted site list is a database of some kind (or perhaps like
the Unix Netscape cookie file, a text file that is read when the browser
is launched. It might look something like this

# this is a comment
# server send region send position rounding (degrees)
http://www.google.com TRUE TRUE 0.01
# never send any geo to doubleclick
http://*.doubleclick.com FALSE FALSE 0
http://find.irishpub.com FALSE TRUE 0.01
# send accurate position to the Irish pub finder!
https://find.irishpub.com TRUE TRUE 0
http://my.weather.com TRUE TRUE 0.1
# send position only to bert67 not to other users
http://my.tripod.com/bert67/ TRUE TRUE 0.2
# default to send my region but not my position
http://* TRUE FALSE 0
# on SSL, send my position to nearest 2 degrees (about 120 miles)
https://* TRUE TRUE 2

Typically a user does not access this directly but by a popup GUI,
similar to the Netscape security GUI that is launched when one
encounters an SSL site using a self-signed certificate.
The security of the file is assured by the security of the operating
system. If this is deemed inadequate, the user may elect to protect
it with a password as for the Netscape certificate database.
Tampering with the file would allow position data to be sent to
sites the user did not wish; however, if an intruder can do that they can
probably read the positioning data directly or plant a trojan that
sends position data covertly so there is little point in "hardening" this
file excessively.

The browser might also have a select feature "enable geo in mail"
similar to Netscape's "enable javascript in mail". The danger here is
of someone sending an HTML email message which incorporates a geo-enabled
"web bug". If the site was one that the user trusted, it would allow
someone with access to the server or intervening network to locate them.

Negotiation:

When user goes to a geo-enabled site, the server sends an Accept-Geo
header. The geo-enabled browser sees this and checks the local database.
If there is an entry for the server then the browser sends the requested
geo headers with each transaction if the corresponding flag is TRUE.
Position data is rounded to the accuracy given, e.g. 49.013;2.567 rounded
to 0.1 is 49.0;2.6
If there is no entry, the browser launches a dialog
asking whether to send data for this session, or always, or not send it,
or never.
If the user selects "send always" or "never" an entry is written to the
permanent database. At any time the user may edit the permanent database
and change or remove entries.

The use of an "Accept-Geo" header by the server means that the user
does not by default send position information with every transaction, yet
geo-enabled sites have a way to automatically alert users that they
implement this feature.

-- 
Andrew Daviel