- From: Andrei Popescu <andreip@google.com>
- Date: Tue, 14 Apr 2009 14:19:21 +0100
- To: Nick Doty <npdoty@ischool.berkeley.edu>
- Cc: Doug Turner <doug.turner@gmail.com>, Henning Schulzrinne <hgs@cs.columbia.edu>, public-geolocation@w3.org
On Sun, Apr 12, 2009 at 11:10 PM, Nick Doty <npdoty@ischool.berkeley.edu> wrote: > I certainly recognize the concern from the UA side; I'm just hopeful we can > find some balance to help users make an informed decision. > It seems like there are a number of cases where UAs do show site content in > the browser UI, even though that content might be false or misleading. > Offhand, I can think of Javascript alerts, the <title> element, self-signed > certificates and the status bar (though I guess window.status is often > disabled by default these days). And as was mentioned earlier, Google Gears > had a custom UI with a message from the site, and I suspect most people > couldn't distinguish Google Gears UI from the browser UI. > It seems to me that there's a trade-off here, and I just happen to think > that the risk of adding one more piece of site-generated content into the > browser UI is worthwhile, since I think it's a dangerous precedent for users > to make decisions about revealing personal information without context of > how the information will be kept and used. Could UAs mitigate the risk by > making it very explicit that this is content from the site and isn't > verified? (I believe this is how self-signed certificates are handled.) As was mentioned earlier, if the Web site doesn't want to provide this extra content, then the fact that there is a special API for it won't change matters in any way. If the web site does want to provide this extra content, then it already has the means to do so (HTML). As Doug said, there is some merit to this idea but I don't think it's worth pursuing it any further. Many thanks, Andrei
Received on Tuesday, 14 April 2009 13:19:59 UTC