注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

写着玩

Bob

 
 
 

日志

 
 
 
 

Geolocation in Chromium  

2010-01-10 22:47:11|  分类: Chrome |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
Status: Draft

Modified: Nov 24 2009

Objective

This document describes a design for adding Geolocation support to Chrome.

Background

The W3C Geolocation API provides access to geolocation information of the host device via a simple JavaScript API. The API is agnostic of the underlying location information sources. Common sources of location information include Global Positioning System (GPS) and location inferred from network signals such as IP address, RFID, WiFi and Bluetooth MAC addresses, and GSM/CDMA cell IDs, as well as user input.

Today, Chrome supports a precursor to the Geolocation API via Gears. The goal of providing full support of the W3C Geolocation API is to remove the dependency on Gears (thereby addressing platforms that don't have this module, crucially Linux, Mac, ChromeOS) as well as to move to a standardized API.

Location in the browser enables applications ranging from mapping and navigation, through to social networking and location-based search.

Overview

Support for the Geolocation API was added to Webkit in late 2008. Since then, it has been extended and updated, and is available in several browsers on both mobile and desktop.


The basic steps of an integration to Chrome include:

  • Providing a GeolocationService implementation that communicates with the browser process' I/O thread via IPC.
  • Implementing an system of location providers in the browser process
  • Implementing a security UI in the browser process.

Examples of location providers include WiFi-based access point scanners that use a cloud-based service to return lat/lng location information, interfaces to GPS hardware, etc.

Existing work

Geolocation implementations

We should look at existing implementations for comparison:
  • Google Gears on various browsers and platforms:  IE on Windows, Firefox on Windows, Mac and Linux, Safari on Mac, Chrome on Windows
  • Opera natively using Skyhook, in a March 2009 demo build
  • Firefox natively, version 3.5 onwards, using Google Location Service (GLS)
  • iPhone with CoreLocation
  • Android Web browser in Eclair using Webkit geolocation implementation
  • WebKit GTK is bound to the GeoClue location framework

Permission grant/review mechanisms

Within Chrome, the user permissions UI needs to fit within the context of these other UIs:
  • Password manager
  • Cookie manager
  • Client side storage
  • Info bar users include: SSL certificate warnings, save password, reload tabs after crash, plugin crash.

Detailed Design

Overview

The implementation must be split across 2 processes, the Browser process and the Render process (See Chromium Multiprocess Architecture).
There is one instance of the Browser process per running chrome instance, and multiple instances of the renderer (typically 1 per webpage), providing a natural 1:N fan-out of location information from a combined location manager to multiple potential client pages.
In this phase of development the implementation strategy is reuse so far as possible the location manager code from the Google Gears project (see next sections). This will be refactored to run within the browser process, providing hardware access abstraction, location provider arbitration, recent location caching and movement detection/change notification responsibilities. (Not all of these are relevant in the initial implementation; arbitration, caching and movement detection will be enhanced in future iterations).
In addition, new code will be developed to glue this to the UI path for geolocation, specifically the icon bar and the infobar prompt.
The Renderer process code will contain the existing WebKit JavaScript (V8) bindings, Chromium Bridge glue code, and interfacing to IPC to obtain location information from the browser process; renderer sandboxing blocks direct access from this process.

Browser ? Renderer IPC


Within the existing WebKit geolocation bindings there are 2 main interfaces that need implementing by the embedder to provide geolocation support:
    
  • Permissions:
    • RequestChromeClient::requestGeolocationPermissionForFrame()
    • CallbacksGeolocation::setIsAllowed()
  • Geolocation Service 
    • RequestGeolocationService::startUpdating() / stopUpdating()
    • CallbacksGeolocationServiceClient::geolocationServicePositionChanged() / geolocationServiceErrorOccurred()

New IPC messages will be defined in order to proxy these interfaces to the browser process. The parameters in these messages will be modelled on this function prototypes.


Renderer to Browser messages:

IPC_MESSAGE_ROUTED1(ViewHostMsg_GeolocationStartUpdating, PostionOptions);
IPC_MESSAGE_ROUTED1(ViewHostMsg_GeolocationStopUpdating, PostionOptions);
IPC_MESSAGE_ROUTED1(ViewHostMsg_GeolocationRequestPermissionForFrame, std::string /* origin */);

Browser to Renderer messages:

IPC_MESSAGE_ROUTED1(ViewMsg_GeolocationPositionChanged, Postion);
IPC_MESSAGE_ROUTED1(ViewMsg_GeolocationPositionErrorOccurred, PostionError);
IPC_MESSAGE_ROUTED1(ViewMsg_GeolocationSetAllowed, bool);

All aspects of handling the request, including interpretting the content of PostionOptions and making the success or error callbacks in accordance with the spec, will be handled by the location manager in the browser process.
Exception: timeouts are already implemented within the WebKit geolocation bindings, and so are not required in the browser process. It should be just enableHighAccuracy that needs to be done by the browser process - it's interpretation is inherently platform-specific. As you say, timeout is already handled in WebKit, and maximumAge will be soon too (it's already in Android's forked WebKit). See https://bugs.webkit.org/show_bug.cgi?id=30676 -Steve Block 24/11/2009 11:24 

Routed messages are used, as the WebKit Geolocation bindings have an implicit context of one set of updates per view, and the Chrome View and routed message architecture allows a convenient way to reflect this page context within the browser process.

Geolocation resources associated with a renderer can easily be freed in the case of a render process death, as the RendererViewHost class gets cleaned up automatically.

Note there is some duplication of functionality between ViewMsg_GeolocationPositionErrorOccurredand ViewHostMsg_GeolocationSetAllowed -- both can be used to indicate permission denied error. It is done this way to keep the IPC close to the WebKit embedder API, and also as the former gives a single position failure whereas the latter "latches" for the remainder of this page load (or until a subsequent ViewHostMsg_GeolocationSetAllowed  message is received).

Location Providers

Note: the design here closely resembles that of the Google Gears Geolocation implementation, but some names are changed to better match Chromium convention.
TODO: Change LocationManager -> LocationArbitrator
TODO: Replace successCallback and errorCallback fn_ptrs with interface class pointers

The LocationManager manages a pool of location providers (illustrated below). Each location provider implements a positioning strategy (e.g. interfaces to a GPS receiver, or collects WiFi signals and uses a network service to convert to lat/lng, etc). 

Geolocation in Chromium - yolcy - 写着玩
When GetCurrentPosition or WatchPosition is called, the LocationManager creates a new FixRequestInfo. Multiple fix requests can operate in parallel - the LocationManager assigns to each fix request a number of location providers, subject to the parameters specified in the PositionOptions argument. To improve efficiency, a given location provider is shared between multiple fix requests. Management of this sharing, and the lifetime of the location providers is handled by a location provider pool.

Note: If one FixRequestInfo has enableHighAccuracy associated with it and another doesn't but a high accuracy provider is available, both requests will receive highest accuracy position information. I think that if you're going to do this, there's little point in assigning a specific set of providers to a fix request. Each fix request might as well use all of the providers available (subject to the restriction of enableHighAccuracy). The added complexity in Gears was because we had an arbitrary number of location providers (a server URL could be passed from JS) and we made the decision not to share the results of providers assigned to a given fix request with other fix requests.  -Steve Block 24/11/2009 11:30 

Once a fix request has been registered with a set of location providers, the the LocationManager receives position updates via the listener interface. On receipt of a position update, the LocationManager performs an arbitration mechanism. The goal of the arbitration mechanism is to determine which, if any, of the success callbacks of the existing fix requests to invoke. This is determined by comparing the new location data against the data that was used during the previous invocation of the callback. The decision to invoke is determined based on whether the new data is either more accurate or it denotes a significant movement from the last time the callback was invoked.
There will be one fix request outstanding per page actively using geolocation -- i.e. that has issued at least one StartUpdate call since the last StopUpdate (if any).  Not sure i understand this  -Steve Block 24/11/2009 11:34 

Google Location provider

Initially, a single location provider will be implemented. This will use Wifi scan data from the host operating system and the JSON google network location provider protocol to resolve the client location.

The server address will be configurable via a command line flag, to allow for automated testing.

Where required, the location provider will delegate work into helper thread, e.g. if making calls to operating system API functions that will block whilst the scan occurs.


Future enhancements
In the initial version only a basic arbitrator and provider will be implemented, but could be enhanced in future iterations, for example:
  1. The initial version the location arbitrator only needs to support a replacing the current provider rather than full multi-provider arbitration and provider degradation arbitration.
  2. handle location provider degradation: if the provider callback indicates GPS signal loss (for example), at some point the watchers must be informed and provided with the next-best location.
  3. Cell ID support can be added to the Google Location provider, where appropriate (abstraction for access Cell ID will be required)
  4. Significant latency and battery savings can be made by aggressively caching Wifi and Cell ID database lookups, and interpolating responses, within the client. This will also require protocol enhancement.
  5. Numerous extensions could be to runtime selection and loading of the location providers.


Persisting geolocation permissions

In order to meet the intended user experience, it is necessary to persist authorization state per page origin.
A persisted state may be one of {Allow, Deny, Undefined}. Undefined will be represented as no entry in the permissions table.

In addition a 'temporarily denied' state exists, for any page that has the info bar dismissed. This temporary states exist for the current page session, but do not modify the persisted state.

Permissions will be stored in an sqlite table accessed via the db_thread. I think this needs to some after the UI mocks and discussion of permissions flow. Otherwise it's a bit confusing.  -Steve Block 24/11/2009 11:37 

User Interface

There are 2 main entry-points in the user interface: URL bar icon, and info bar prompt. Each of these have a pop-up bubble that can provide options or help info respectively (See the UI Mocks section below).
All UI code is implemented in the browser process (UI thread), as it is painted in the browser's chrome, not in the web-page content.

Upstream WebKit Code

The initial WebKit Geolocation was added by Greg Bolisnga from Apple. Some fixes have been made to Android's version of WebKit by steveblock, but the process of upstreaming to webkit.org is still ongoing. You can see the status of the outstanding WebKit Geolocation bugs at http://go/webkitgeolocationbugs Internal URL redirecting to https://bugs.webkit.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=geolocation&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&rep_platform=All&op_sys=All&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&known_name=Geolocation&query_based_on=Geolocation&field0-0-0=noop&type0-0-0=noop&value0-0-0=  -Steve Block 24/11/2009 11:44 
In addition, the following modifications will be required for the Chromium implementation:
  • Allow a page to have geolocation access revoked (and be informed of this correctly via PositionErrorCallback) before and without the need for a reload.
  • Clarify the balancing of startUpdate and stopUpdate calls, when proxied via IPC to the browser process.

V8 Bindings

V8 bindings are one of the elements that have been added to Android but not yet upstreamed to webkit.org.

UI Mocks

Since geolocation information is sensitive, the W3C API mandates that "User Agents must not send location information to Web sites without the express permission of the user". The UI must solicit the user's permission before granting the Web page access to location. 

Further, the API specification states: "The user interface must include the URI of the document origin." hence Permission is granted and persisted at the document origin level.
Note: this is not the effective script origin; changes to to document.domain will not affect geolocation permissions.

See http://mocks/glen/chrome/spec/77_geo/ for up to date mocks.

TODO:  The examples below are wrong.  The pop-up should be asking about "www.yelp.com" not "yelp.com".

http://mocks/glen/chrome/spec/77_geo/3/#01_bar.png
Geolocation in Chromium - yolcy - 写着玩

http://mocks/glen/chrome/spec/77_geo/3/#02_learnmore.png
Geolocation in Chromium - yolcy - 写着玩

http://mocks/glen/chrome/spec/77_geo/3/#03_tracking_icon.png
Geolocation in Chromium - yolcy - 写着玩

http://mocks/glen/chrome/spec/77_geo/3/#04_tracking_bubble.png
Geolocation in Chromium - yolcy - 写着玩

http://mocks/glen/chrome/spec/77_geo/3/#05_tracking_icon_off_01.png
Geolocation in Chromium - yolcy - 写着玩

NOTE: Specific details in the mocks are subject to change as they are finalized, however the basic flow is expected to remain as outlined here.

Basic flow:
  1. On JavaScript call to geolocation API to fetch location, info bar prompt shown (see 01_bar.png)
  2. If user clicks Allow, this site is now access geolocationand the tracking icon is shown in the URL bar (see 03_tracking_icon.png)
  3. If the user clicks Reject or dismisses the Infobar the API calls are rejected and the no tracking icon is shown (see 05_tracking_icon_off_01.png)
    1. An 'Allow' or 'Reject' is persisted to future page loads from this site
    2. An info bar dismissal rejects all further API calls for this page load, but the info bar will show again on the next page load for this site.
  4. At any subsequent time whilst on the page the user can click the tracking icon to control the state (see 04_tracking_bubble.png)

Working assumptions:
  1. If the page is not visible when it makes its first geolocation request, the info bar will not be visible until the page is restored, and hence the API call will not complete until this time (at the earliest) (excepting client specified timeouts) The API is asynchronous. Do you mean the success callback? -Steve Block 24/11/2009 11:39 
  2. If a page cancels / times out its request without the user responding to the infobar, the infobar may be dismissed.  The timeout includes the time spent acquiring the location, but not that spent acquiring permissions. See http://dev.w3.org/geo/api/spec-source.html#position_options_interface. I guess we could remove the infobar if a watch is cancelled, but one-shots aren't cancellable. Note too that WebKit doesn't ask the chrome for permission until a position has successfully been acquired, to avoid prompting the user only to have the location acquisition fail. Of course you could preempt this and show the UI in advance.-Steve Block 24/11/2009 11:39 
  3. When a page is opened in an incognito window, persisted permissions for that origin are not created or honored.
  4. The Clear Browsing Data dialog will have an additional tick-box to clear geolocation permissions.
  5. Multiple origins (frames) on the pages
    1. Info bars are queued in fifo order.
    2. URL bar icon can open a dialog with multiple entries.

Possible areas for future enhancement:
  1. Require a user interaction to initiate the location info-bar prompt (possibly show a passive icon if the page wants location without user interaction). As discussed with erg:-
    1. "bool ScriptController::processingUserGesture()" - when this returns true we're currently inside a javascript call stack handling user input
    2. see DOMWindow::allowPopUp
  2. Frames (multiple origins): postponing the info bar prompt until it is clicked means that it's clearer to the user what is requesting it / which origin is granted the permission
  3. Multiple origins (frames) on the pages
    1. We could treat the top-level origin different from others.  Top-level could display notification straight away while others require a gesture.
    2. Dismissing or revoking permissions for the top-level site could clear permissions for the embedded domains too. [Works better with a "forget" button]
  4. when there is redesigned control panel that enumerates permissions per site, add geolocation attribute


Testing Plan

Webkit layout tests (run under TestShell): upstreamed, testing binding javascript to mock geolocation service.

Unit tests: for individual chromium classes

Browser tests: location manager and related classes.

UI tests: for the info bar & url bar icon.

Large tests can be made by configuring the browser to use a test server address


Internationalization and Localization

Strings are required for the infobar, more info and icon bar bubbles as per the mocks. In addition, there will be strings for any tooltips, clear browsing data options, and any help pages.
These will be internationalized via standard Chromium mechanism.

Besides strings, no specific internationalization requirements are identified.

Project

Code Location

src/chrome/common/geolocation

src/third_party/WebKit/WebCore/platform/Geolocation*

src/third_party/WebKit/WebCore/page/Geolocation*


Release plan

Working assumption: 5.0 features need to be in the dev channel before late Feb '10

Implementation will be phased:
  1. Add Chrome Bridge glue to the webkit javascript bindings for geolocation
  2. Implement basic lookup in browser process using dummy provider
  3. Implement platform location providers
  4. Implement security prompt UI
  5. Implement permissions persistence

Steps 1-2 provide proof of concept implementation.
Step 3 extends it to end-to-end demoable state.
Step 4 extends to dev channel
Step 5 needed for beta and eventual main channel releases.

Command line flags will be provided to:
  • enable geolocation support (on by default when released in dev channel)
  • configure the google location provider server address (for testing purposes)

Group Members

  • Jonathan Dixon (joth, eng)
  • Mark Seaborn (mseaborn, eng)
  • Jeremy Orlow (jorlow, consultant Chrome)
  • Steve Block (steveblock, consultant, Android dev)
  • Andrei Popescu (andreip, consultant, Gelocation spec editor)
  • Ian Fette (ifette, PM)
  • beng, glen (UX)
  • Dave Burke (daveburke, TLM)




Security Considerations

Threat: A site might try to obscure or spoof the location access indicator.
Measure: UI for permissions and location access reminder (URL bar icon) are drawn by the browser process in reserved browser chrome.

Threat: A compromised renderer might access the screen or location sources directly
Measure: Chromium renderer sandboxing counters these attacks.

Threat: An already-authorized site may be embedded within another unauthorized site, yet reveal location information to it, intentionally or otherwise. (note to do so is in violation of 4.2 of the Geolocation API specification)
Measure: The URL bar icon indicates to the user that location is being accessed and allows user to revoke.

Privacy Considerations

See the Mocks section.
  评论这张
 
阅读(849)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017