Re: Privacy considerations for implementors of the Geolocation API

>
> > I understand the serialisation - I think the issue with the TAG is that
> the canonicalised origin isn't actually a URI so they wanted the language
> changed to clarify this. My problem is that there is a MUST requirement that
> UAs display this string but as far as I can see, nobody actually does (the
> implementations I've seen don't show the "http://" part).
>

For what it's worth, Mobile Safari 3.0 shows the scheme (the "http://" part)
as well as the host in their modal location dialogs. (I haven't yet tested
to see if they also show the port when the port isn't 80.) Chrome's
notification bar used to show the scheme in their infobar (somewhere during
Chrome 5), but does no longer (I'm running Chrome 7, I'm not sure when they
made the switch, or why).


> I'd like the consideration section to reflect the intent we had.  I would
> rather have us leave the MUST but change what we meant to be displayed to
> the user.  Maybe "HOST of the requesting document".  There are probably
> others with a better name for this field.
>

I agree with Doug here: removing the normative MUST would remove one of the
key privacy protections in the API. I think host is the correct term (
http://www.w3.org/TR/html5/urls.html#url-host, and maybe originally defined
in RFC 3987) and that maybe we want to specify the "host of the document
origin" (or perhaps "host of the effective script origin") if we conclude
that the scheme and port aren't important. You might think they're important
though: isn't it relevant information for a user to know that the requesting
script was loaded via HTTPS? (That seems nice, but of course won't guarantee
that any AJAX requests that the script makes with the returned location data
will be over HTTPS.)

Thanks,
Nick