This is born out of my frustration of using different JavaScript mapping solutions - my phone has a mapping app, why do I need to share my location with a website and their mapping provider?

At the moment, if I want to use Google Maps, or OpenStreetMap, or Carto, or any other mapping provider, I have to load in a bunch of external JavaScript and then add <div id="map"></div> to my markup.

How about we get rid of all those external libraries as a dependency? Let's do what we did with <video> and make mapping a first class element.

It's quite common to suggest new HTML elements based on popular <div id="..."> - that's how we got <nav>, <footer>, <aside>, <audio>, and the like.

I'd like to propose a new tag:

<geo>

(In an ideal world, this would use the <map> element - but that has already been taken by image maps. It could equally be called <mapping>, <maps>, or similar.)

Use cases

1. As a user of a website, I want embedded maps on a website to offer a fast and consistent experience.
2. As a user, I don't want to share my location with a website.
3. As a user, I want access to my devices' mapping features when I view a map on the web.
4. As a developer of a website, I want to take advantage of any in-built mapping software the user has, rather than use a 3rd party library.

Dive in!

This is a sketch of how a <geo> element could be used. This doesn't cover all use cases, it misses out important things, it glosses over problems. This is a prototype for others to critique.

Display a map centred on a specific location

<p>Visit our restaurant!</p>
<geo location="51.75026,-1.248338">
   Your browser doesn't support interactive maps.
   <img src="...">
</geo>

Fairly simple. A block element which takes a location. It includes a fallback experience - just like the <video> element.

If the user has a mapping app installed on their device, that will be used to provide the map. That will give the user access to all the mapping features they regularly use (favourite places, routing, preferred map styles, street view).

If they don't have a mapping app installed, the browser can provide that service - or the web developer can specify a fallback solution. Just like HTML5 Video.

Location

I envisage location= as taking any data. It is up to the mapping provider to interpret it.

<geo location="Oxford, UK">
   Your browser doesn't support interactive maps.
   <script src="...">
</geo>

Zoom

A common requirement for a map is to specify a zoom level. For example, Google Maps uses zoom levels 0 - 20 - with being fully zoomed out. Similarly, OpenStreetMap uses 0 - 19.

Rather than arbitrary numbers to represent zoom, the <geo> element uses a zoom tag which defines how wide the map is in measurable units. For example zoom="5KM" shows a map with a diameter of 5 kilometres. zoom="90deg" shows a map zoomed out to show quarter of the world.

<geo location="51.75026,-1.248338" zoom="10KM">
   Your browser doesn't support interactive maps.
   <img src="..." />
</geo>

Possible values could include degrees, kilometres, metres, and metres per pixel.

Interactivity

A website owner may not want a "slippy map" experience - in order to create a map which can't be moved or zoomed, they can use the boolean attribute static.

<geo location="51.75026,-1.248338" zoom="10deg" static ></geo>

Markers

It is useful to put a selection of markers on a map. For example, the location of the entrance points to a venue.

<geo location="日本武道館" >
   <marker location="35.69391,139.7494" display="entrance">
      <img src="..." >
   </marker>
   <marker location="35.69274,139.7501" display="exit"></marker>
</geo>

In this case, the markers have a location tag, with an optional display tag for textual representation. They also have an optional child which contains an image to be used as the marker.

Directions

In this example, the map shows directions from the user to the destination.

<p>Have a drink with us:</p>
<geo location="Strangers' Bar, SW1A 0AA, UK" directions></geo>

A boolean tag. Crucially, the <geo> element doesn't share the user's location with the website.

Complex data (KML and geoJSON)

Both KML and geoJSON are popular ways of expressing complex spatial data. It should be possible to pass that data to the mapping software via the src= parameter.

<geo src="/data/points.json"></geo>

<geo src="/data/points.kml"></geo>

Other Stuff

Wait! What about....? As I said, this is a basic skeleton description of a new element. It probably doesn't involve your specific use case.

Just like the <video> element, this doesn't stop a developer using a 3rd party solution if they want.

Your thoughts?

People don't own mobile phone numbers. They are rented from mobile operators. Yes, you may be able to move "your" number between a limited set of providers - but it ultimately doesn't belong to you. An operator can unilaterally take your number away from you.

If you move to a different country, you will almost certainly have to change your number - thus invalidating any account which relies on a mobile being your primary identifier.

That's before we get on to how hideously insecure phone numbers are. Transmitting an SMS with a sensitive one-time code over a cleartext which can be easily intercepted is not a sensible approach to security. Modern phone networks are designed to accommodate Lawful Intercept - and suffer from a range of security weaknesses.

Fine. Whatever. Let's use emails as our primary ID. Bzzzt! Wrong! Email addresses are just as ephemeral as mobile numbers.

If you use a service like Gmail, Yahoo, or Hotmail, then you're at the mercy of those providers. They can revoke your access at any time. They can give away your cherished address. And, like phones, they can be legally compelled to give access to certain 3rd parties.

Social Media IDs are equally rubbish. Your presence on Twitter or Facebook is little more than virtual sharecropping. You don't own or control your ID. If the provider goes bust, you've lost the ability to identify yourself.

OK, here's an answer! What if I run my own domain? Then I'll be in control of my identity. And my email as well!

No. Not really. Your domain is only temporarily leased from your registrar. Perhaps you forget to renew your domain. Or renewal prices will jump and you can't afford your "home" any more. Perhaps a global corporation insists that they alone have the right to use your name and take you to court. That kills off the ability to use something like IndieAuth.

Umm... How about IP addresses? Again, for most people these are leased from ISPs and are dynamic. Even with a switch to IPv6, there's no way to own an address permanently and move it between ISPs.

I want an online identity which is immune from 3rd parties to take back. Something unaffected by Eminent Domain. That - no matter the social and technological changes of the Internet - will remain valid throughout my lifetime.

Let's craft a problem statement

As a user, I want to have an identifier on the Internet which can only be revoked by me.

(That's not a perfect story, of course. It says nothing about security, access rights, or usability. But it is a simple starting point.)

Does such an identifier exist today?

Something like a Public/Private keypair is almost right. Ignoring the many usability issues with things like PGP, it is conceivable that you could authenticate yourself to a service by cryptographically signing a challenge they send you which is then verified against your public key.

This is more-or-less how FIDO UAF works. You generate and store your keypair on a piece of cryptographic hardware and use that for authentication and identification.

But there is a more fundamental flaw - a keypair doesn't provide a method for delivering a message or a service.

At the moment there's no way to say

• "Visit my website at impossibly long cryptographic string" or
• "Give me a call at ..." or
• "Let's exchange data via ..."

OK, I can add multiple email addresses to a PGP key and hope that all the major email providers don't go bust, or sell me out.

I'm sure there are hacks which will turn 000D05F640557C62 into a DNS entry for a website. But that still falls back on requiring an existing domain name. Which can be taken away from you.

(As an aside, if you're an intergovernmental agency registered by an international treaty, you can apply for a .int domain. That's probably harder for someone to unilaterally revoke.)

The Internet, so we are told, routes around damage. But where does it route to?

I don't have an answer to this. It seems like a fundamental design flaw with existing Internet infrastructure. How can I carve out a permanent home here?