The W3C mobileOK Trustmark

Editor's Draft 8 April 2008

This version:
Latest Editor's version:
Previous version:
Charles McCathieNevile, Opera Software
Previous Editors:
Sean Owen, Google
Jo Rabin, dotMobi (and before at Segala)
Phil Archer, ICRA


This document describes the W3C mobileOK Trustmark. mobileOK defines machine-readable content labels which may be applied to content to indicate that the content and its delivery pass a suite of tests based on the Mobile Web Best Practices document [BestPractices]. The Mobile Web Best Practices Working Group is creating these labels to help promote development of an effective user experience for mobile users of the web.

This document is directed primarily at mobile content authors, tools developers and content providers. Readers are expected to be familiar with the Mobile Web Best Practices document [BestPractices].

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a first Editor's Draft of the W3C MobileOK scheme; this document establishes the rough shape of the mobileOK scheme. It lacks many details, and it is subject to significant change. This document should not be taken to reflect group consensus. The Working Group is seeking feedback on the general direction of the document.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document has been produced by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative. Please send comments on this document to the working group's public email list public-bpwg-comments@w3.org , a publicly archived mailing list.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

0. Reading this document

This document is a working draft, and liable to change. It currently contains errors, ommissions, and editorial notes (the latter are marked out with a distinctive style, as is this parenthesis).

1 Overview

This document describes the W3C mobileOK scheme (referred to here as simply "mobileOK"), version 1.0.

1.1 What is mobileOK?

mobileOK is a scheme comprised of two content labels, called mobileOK Basic [Basic] and mobileOK Pro [Pro]. These machine-readable labels may be applied to content to indicate that the content and its delivery pass a suite of tests based on the Mobile Web Best Practices document [BestPractices].

mobileOK Basic tests are based upon a limited subset of the Mobile Web Best Practices and are all machine-verifiable. Conformance to mobileOK Basic requirements is thus simple to check or verify. Content bearing this label has taken some basic steps to provide an effective experience for mobile users, and been tested by checking software.

mobileOK Pro tests are based upon a significantly larger subset of the Mobile Web Best Practices, and are a superset of mobileOK Basic tests. These tests are not all machine-verifiable and require verification by a human. Content bearing this label has taken significant steps to provide an effective experience for mobile users, and has been tested by a person (optionally with the assistance of software when applicable).

Note that not all Mobile Web Best Practices map to a test in mobileOK conformance tests. Some best practices, like EXPLOIT_DEVICE_CAPABILITIES , are advisable but may not meaningfully translate into concrete tests, whether machine- or human-verifiable.

mobileOK says nothing about what may be delivered to non-mobile devices from that URI; however, note that a mobileOK URI must return mobileOK content by default if the nature of the user agent (desktop or mobile) cannot be reliably determined.

A mobileOK label also does not imply endorsement or suitability of content. For example, it must not be assumed that mobileOK content is of higher informational value, is more reliable, more trustworthy or is appropriate for children.

1.2 Why mobileOK?

The Mobile Web Best Practices document [BestPractices] and Techniques document [Techniques] @@Issue: the Techniques wiki is not in development. Should we remove this reference or just note that the target is dead? have already enumerated much of what it takes to deliver an effective user experience to users of mobile devices. mobileOK complements this effort by providing machine-readable labels for mobileOK content. The presence of standard mobileOK labels may catalyze production of effective content for mobile users, and tools to create and detect this content, and even create demand for this content. It is hoped that this ultimately improves the quantity, quality and usability of Web content available to mobile devices.

1.3 Who is mobileOK for?

mobileOK has value at many points in the content authoring and delivery chain for mobile devices. These are developed in more detail in the Use Cases, but the main audiences are briefly listed here:

Content Developers

Developers who create content which follows Mobile Web Best Practices, and which passes tests outlined in this document, have added value for mobile users. They can advertise this to consumers of their content through the mobileOK labels.


Likewise, tools that can produce, parse, adapt or manipulate mobileOK content (browsers, content management systems, authoring tools, content adaptation systems, etc.) add value for authors, and can advertise this capability.

Content Providers

Sites that are concerned with providing a quality experience to mobile users can look for a mobileOK label when acquiring content and tools.

Content Discovery Services

Search engines, content aggregators, and other services which locate content for mobile devices can look for a mobileOK label and possibly prioritize mobileOK content.

Content Consumers

End consumers of content may also treat mobileOK content differently, preferring sites that advertise mobileOK content.

Certification Provider

Certification providers may wish to offer to certify conformance to mobileOK tests; entities such as content providers that come to rely on mobile content may require more verification that content they provide is mobileOK.

1.4 Form of the mobileOK label

The precise form of the mobileOK label has not yet been finalized, however, MWBP expects to use the work of the POWDER working group [POWDER] to provide a standard encoding for mobileOK labels. In addition, a visual label (banner or icon) will (probably) be made available, to provide an indication to users that a Web page, site, or application meets mobileOK Basic [Basic] or Pro [Pro] requirements.

The abstract model for mobileOK exists independently of any particular technology. However, the expectation is that mobileOK will typically be encoded in [POWDER], a vocabulary of [RDF] that has the following basic structure:

  • Metadata
    • Who created the mobileOK label?
    • When?
  • Scope
    • The content to which the mobileOK label can be applied
  • The Label
    • Classification as mobileOK Basic or Pro

1.4.3 Visual Representation

Content which bears a mobileOK label may optionally advertise this by displaying a mobileOK logo (to be produced). Adding even a small logo image to a page increases the time and bandwidth needed to access that page; therefore, it is recommended that the mobileOK logo be displayed on relatively few key pages, if at all. If one URI returns content differently for desktop computers and mobile devices, and delivers mobileOK content to mobile devices, then the mobileOK logo may be included on the desktop rendering of the page as well.

2 Use Cases

2.1 Certification Provider

Ace Content Provision has a substantial desktop presence and wants to reach a mobile audience with its new service. Naturally it is keen to have its content display as well as possible on mobile devices and so develops its web site in accordance with the Best Practices.

Ace is keen to advertise the existence of its mobile tailored services and show that its high quality brand value extends to this area. It believes that the mobileOK claim will carry more weight, especially among search engines tuned to mobile devices, if endorsed by a trusted third party. This is particularly true of those claims related to non machine-testable aspects of mobileOK.

One of Ace Content Provision's main distribution channels is a mobile network operator that requires content on its portal to be certified as being mobileOK by one of a short list of preferred certification providers. In order to offer a flexible and competitive service, the certification provider offers several levels of service. These range from automated checking of machine-testable Best Practices through to frequent checks by human reviewers. For Ace Content Provision, this is worthwhile as an ongoing service. For other providers the balance of cost and assurance is best met by assessment at service launch and on major update thereafter.

2.2 Content Adaptation

A content developer wants to create high quality user experiences on multiple devices. Sensibly, the developer chooses to use an adaptation approach which supports mobileOK. They create device independent content together with styling and layout, using W3C standards such as DIAL and CSS.

When a device makes a request, the adaptation system uses the various materials provided by the author to construct and deliver an appropriate page that conforms to mobileOK. It automatically marks the page with the mobileOK label. If the author has requested inclusion of the mobileOK logo, the adaptation system adds it to the page.

2.3 Content Syndication / Aggregator

A content syndicator / aggregator gets content from many sources. Some may be internal to the company, some may be external partner companies; in fact some content from partners can be sent directly to the client using inclusion via iFrames for example. In short, the content syndicator has, in some sense, very little control over the syndicated content.

Since the mobileOK label can only apply to the full page delivered to the end user, the content syndicator must ensure in some fashion that the content from partners does not invalidate the label. Thus the syndicator wants partners to make mobileOK conformance claims about their content to which they can be held accountable. This may include information about who is making the claim.

2.4 Individual Content Author

Joe Lambda wants to make a web site about his holidays for a couple of friends to follow, and be sure that it can be read on mobile phones. He reads the mobileOK documents, and makes sure he follows the requirements, so he can put the mark on his pages and his friends can check they will work before they download them.

The use case requires no-cost use of the label and that the label should be sufficiently simple that it can be added by the normal processes used for web development.

It would be nice to have tools to assist in testing, to add the label when tests have been met, and to note that something important has changed and that content needs to be re-tested.

2.5 Search Engine

A search engine wants to provide search services over mobile content for the benefit of its mobile users. When crawling the web it wants to easily discover all content that is usable to a mobile device, especially content designed specifically for mobile devices. It wants to evaluate how good the mobile content is and index it. When serving queries from mobile devices, it wants to return the best mobile content that matches the query.

One might imagine several things a search engine would want from the mobileOK label. The one that seems vital to making mobileOK useful to the search engine is detecting that a page at least says it is mobileOK and thus is trying to be a good mobile page.

There are a couple things that would be nice to have. First is an easy way to discover many mobileOK resources at once -- for example all mobileOK URL in a directory or domain. Next is a way to at least partially verify that a page does comply with mobileOK tests as claimed. Last is a way to identify claims of partial conformance, so that the search engine can customize its offerings to a particular profile of requirements. For example in a real use case, I have a phone that has a certain set of constraints, but is much more powerful than the baseline device -- specifically I don't care whether content relies on JavaScript or not, since my browser supports it, so I want content that meets various other requirements whether or not they meet any requirements on script.

2.6 Software Developer

A software developer is prioritizing fixing problems in rendering content appropriately. Being able to gather a collection of mobileOK content provides a useful test set, that allows prioritizing development based on what we trust to be the approach to content that more people will be using -- chasing a growing, rather than diminishing, market.

So the use case would require a discoverability mechanism for mobileOK content, and people using mobileOK.

It would be very helpful to have some reasonably reliable and simple method of verifying the claim.

2.7 Operator

An operator might use the mobileOK label to predict which content and sites would work better on the mobile devices of its customers. By detecting the existence of this label, an operator might apply different prices to the data traffic, provide better network caching for those sites and in some cases enrich the communication (policies at network transcoders, more parameters, etc.).

2.8 Accepting or Rejecting a mobileOK claim

An agent is set to crawl the Web to collect content to be presented in an ATOM feed that is updated daily. Several criteria are used sequentially to decide whether content resolved at a particular URI should be included or not, including mobileOK conformance.

The crawler detects a mobileOK label describing content at http://mobile.example.org. The label itself comes from a server the crawler recognizes as being trusted. Although the label is digitally signed, for efficiency, this is not checked before the crawler passes the content on to the next stage in the evaluation process for possible inclusion in the ATOM feed.

At http://new.example.org content is again described by a mobileOK label. This time, however, the label is on a server the crawler has not encountered before and so it does not know, yet, whether to trust the claims or not. The data in the label carries a valid digital signature and so the content is passed on to the next stage in the evaluation process for possible inclusion in the ATOM feed. If it is subsequently included, the newly discovered server will be added to the list of trusted sources as will the digital certificate.

Finally the crawler discovers content at http://bad.example.org that is again claimed to be mobileOK. The server is not recognized and the digital signature is not valid for the data in the label. It is therefore rejected and content is not forwarded to the next stage in the evaluation process.

3 Requirements for mobileOK

The following requirements were considered in the development of mobileOK.

The mobileOK label must be discoverable by a machine.
It must be possible to label content as mobileOK without the need to acquire specialized tools, expend a disproportionate amount of effort, and without the involvement of a third party. Anyone may label content as mobileOK, including its author. See use case A.5.
In other words, it should be possible for anyone with a reasonable developers' knowledge of Web technology and the mobileOK tests to check and label content according to both schemes.
Third-party labeling
It must be possible for a third party -- someone other than the author or host -- to claim that content and its delivery are mobileOK. See use cases A.1, A.2, and A.3.
List of mobileOK Resources
It must be possible to publish and locate listings of one or more resources which bear the mobileOK label. See use cases A.1, A.6.
Partial Conformance
In addition to indicating whether a resource is mobileOK, it must be possible to indicate partial conformance to the mobileOK test suite, ideally at the level of individual tests. See use case A.5.
It must be possible to determine who is claiming that the content is mobileOK. See use case A.3.
It must be possible to determine which version of the mobileOK label is being claimed. See use cases A.1 and A.3.
It must be possible for a third party to verify that a mobileOK claim was actually made by the party named in the claim, perhaps through the use of digital signatures. See use cases A.3, A.8 and possibly A.5.
It must be possible to make a mobileOK claim in a way that is very hard, if not impossible, to forge or replicate maliciously. See use case A.8.

A Revision Description

Beginning a revision.
  • Refer to mobileOK Basic and Pro
  • Replace WCL with POWDER
  • Remove a lot of the detail about labels for now
The first public draft from the MWBP group

B Acknowledgements (Non-Normative)

The editor would like to thank members of the BPWG for contributions of various kinds.

The editor acknowledge significant written contributions from:

C References (Non-Normative)

"Mobile Web Best Practices", Jo Rabin, Charles McCathieNevile, W3C Working Draft, 2 February 2006 (See http://www.w3.org/TR/mobile-bp/.)
Mobile Web Techniques for Best Practices [in development] (See http://www.w3.org/2005/MWI/BPWG/techs/TechniquesIntro.)
Content Label Incubator Activity (WCL-XG) (See http://www.w3.org/2005/Incubator/wcl/Overview.html.)
RDF (See http://www.w3.org/RDF.)
EARL (See http://www.w3.org/2001/03/earl/.)