FAQs

• Why is the Physical Web built on top of the web?

  The Physical Web’s core value proposition is to enable users to have information at their fingertips no matter their physical context. This information can take the form of a simple static web page to a more robust web application. A few examples might include:

  
  

  • A dog collar could allow passerby to call a service to find the owner.
  • A bus that could alert users of its next stop.
  • A city rent-a-bike service could enable users to sign up on the spot.
  • A home appliance could offer an interactive tutorial.
  • An industrial robot could display diagnostic information.
  • A mall that could offer a map.

  
  

  Each of these examples, taken by itself, is modestly useful. In the aggregate, they imply a vast “long tail” of interaction where anything can offer information and utility. The web enables the low friction and ephemerality to enable this kind of interaction on demand.

• Why does the Physical Web use URLs?

  URLs are the fundamental building blocks of the web -- they are both flexible and decentralized. URLs allow any developer to have a digital presence without requiring a central gatekeeper to bottleneck access to the ecosystem. This is a core principle of the web and one that the Physical Web leverages to lower the barrier to entry.

  
  

  The flexibility of URLs affords the opportunity to experiment with URL + ID models that utlimately do utilize a central server (e.g. exampleserver.com/?id=12345). In many ways, this highlights how URLs can be scaled to a variety of use cases.

• Why does Physical Web use Bluetooth Low Energy?

  There are many ways to broadcast a URL. Today, the Physical Web uses Bluetooth Low Energy (BLE) because of its ubiquity on mobile devices. Additionally, it is highly energy efficient -- many bluetooth beacons today have multi-year battery lives.

  
  

  However, this does not preclude the possibility of Physical Web catering to alternate transport protocols in the future. Early potential options include mDNS and uPnP over WiFi.

• What does the openness of the Physical Web refer to?

  The Physical Web is designed to be interoperable at every level of the stack -- from the beacons used to broadcast URLs to scanners used to gather these URLs to the proxy used to filter and sort URLs. Users will ultimately be able to choose which services are appropriate for their use case.

  
  

  In this vein, we have also open sourced sample implementations of Physical Web scanners for iOS and Android, along with an open source proxy service. These are included in our Github.

• How does the Physical Web address potential security concerns?

  URLs in the Physical Web are broadcast such that any device with a Physical Web scanner can detect them. The use of a proxy service prevents a beacon deployer from monitoring each event in which a user passes by the beacon. Additionally, Physical Web deployments are encouraged only in public spaces.

  
  

  The Physical Web also benefits from the web security model, given that it is built on top of URLs. Some of these benefits include:

  
  

  • Certain implementations of the Physical Web require that the broadcast URL be over HTTPS (e.g. Chrome, Nearby Notifications)
  • The URL could be obfuscated (e.g. using a non-branded domain)
  • A rotating token on the beacon could constantly alter the URL
  • The web page could require a login
• How does the Physical Web address potential spam?

  The proxy service used plays the role of a spam filter -- malicious URLs will be filtered away, and less valuable and useful URLs will be displayed lower in the list of URLs. This service is in many ways analogous to a search engine, which is tasked with minimizing spam by providing super ranking of results. Over time, the proxy service will improve in its ability to rank down spam.

• How can Physical Web results be viewed?

  Different implementations of the Physical Web might offer different user experiences for users to discover nearby URLs.

  
  

  For example, on Android, the open source implementation, the Nearby Notifications implementation, and the Chrome implementation surface Physical Web results via low priority notifications, which do not vibrate the user’s device. This ensures that the user’s workflow is not interrupted and that results appear only when the user proactively seeks them out.

• Will the Physical Web display a very long list of URLs to the user?

  Today, there is not a large number of beacons in the environment, but over time, this number will increase if the Physical Web gains in prominence. Proxy services will play the role of not only filtering unwanted URLs but also ranking and sorting URLs that users see. Over time, these will grow in sophistication to rank URLs in the order of usefulness to the user, using signals such as distance between the user’s device and the nearby beacon.

• How does Physical Web affect battery life?

  Ultimately, this is dependent on the design of the Physical Web implementation. The open source, Nearby Notifications, and Chrome implementations only scan for nearby beacons when the device screen is on, which significantly reduces the battery impact.

• Which platforms are supported?

  Both iOS and Android offer bluetooth scanning APIs at the platform level on which Physical Web clients can be built. The open source Physical Web implementations on Github include both iOS and Android. Additionally, the Chrome implementation of Physical Web is available on iOS and Android. The Nearby Notifications implementation is available on Android.

• Why does the title and description not update in the Physical Web notification?

  The proxy service might cache metadata for a certain amount of time before displaying a result. For example, in the Chrome implementation, the proxy service caches metadata for at least 5 minutes in order to provide a fast response. It does not obey "no-cache" HTTP headers.