Consent is the process of obtaining user permission for the API to access the device. Consent can be implicit or explicit. For example, if you press a "Take a Picture" button, you're implicitly giving permission for the app to use the camera. On the other hand, if you click an "Email a Friend" button, you're not implicitly giving the Contacts API permission to spam everyone in your contacts database. Each HTML5 API assumes that explicit permission is required by default but defines circumstances in which implicit permission is acceptable.
Minimization is the requirement that APIs make it easy to gather as little information as is required for the task at hand.
Control is the capability of the user to manage permission choices. Users must be able to revoke a browser's access to a device after they've granted it. Optionally, they should be allowed to whitelist and blacklist applications.
Finally, access is the capability of the user to view and delete his history of sharing device access with applications.
Geolocation is perhaps the most potentially privacy-invading HTML5 APIs. Interestingly, it's also one of the most widely implemented APIs. To get an idea of privacy measures for individual device APIs, it's helpful to look at how Geolocation did it.
Section 4 of the proposed Geolocation API Specification is dedicated to privacy. It divides privacy concerns into two areas of focus: considerations for implementers of the Geolocation API (browser creators) and for recipients of location information (software developers).
The job of designing the actual mechanisms and user interfaces for requesting, obtaining and managing permissions is left up to the actual browser. The specification simply says that, in order to comply with the spec, location information must not be obtained without permission in order for a user agent (a Web browser).
The specification places additional requirements on recipients of location data, too. They must disclose that they are collecting the data, protect the data against unauthorized access, allow the user to update and delete any data they store, tell the user how long the data will be stored, tell the user whether the data will be retransmitted and disclose how the data is secured.
The browser part of the equation isn't worrisome. Browser makers take their responsibility to provide a secure environment very seriously. The recipient (Web app developer) part of picture should worry, though. The processes by which a recipient of location data-or data from any device, for that matter-meets the requirements of the specification are currently up to the individual developer. Some developers aren't even aware of the requirements, and there's no enforcement mechanism.
Even though the browser specifically asks if your location data may be obtained, you might have little, if any, knowledge or assurance that the data won't be stored or used for purposes other than the one you approved. This is the next front in the battle for Web privacy.
Sign up for Computerworld eNewsletters.