Developer’s Overview of UMarks

UMarks is an open bookmark format intended to replace current proprietary systems used by applications that deal with saved links. Its aim is twofold: to use an open XML format to encourage standardization, and, secondly, to create a single, standalone file for each user that is part of their normal data and stored centrally. That is, the intention is for a bookmarks collection to become an open file that is owned by the user and therefore readable as an entity in its own right.

Format and tags

UMarks is XML-based and therefore simple to read and to manipulate. It avoids any use of attributes and all values are clearly defined data types. Its format is relatively loose, allowing applications to make updates easily, and it has been designed to resist corruption. Because it is XML-based it is simple to parse and make sense of, and doesn’t require of applications anything beyond standard XML capabilities.

The <umarks> tag is the root tag that encapsulates all others and it has four sub-tags:

  • <file-updated>
  • <container>
  • <separator>
  • <link>

The <file-updated> tag is the global timestamp for the UMarks file itself, and it records the last update time to any element. The <container> captures information that relates to elements that contain other elements, typically rendered as folders. The <separator> tag denotes visual separators used in bookmark systems, usually rendered as horizontal lines with space above and below, and used to visually organize folders and links. Finally, the <link> tag contains all the information about the links themselves.

The running order is relatively strict: it must be maintained in the order shown above with <file-updated> first and <link> tags last. The <file-updated> tag can only appear once, before all other elements. However, the <container>, <separator> and <link> tags can appear an unlimited number of times, including zero. The tags, in order to maintain the above order, must be grouped together. That is, all the containers are listed together, then the separators, and so on.

Every tag contains its own location information. That is, its location within the user’s bookmark hierarchy. Each container, separator and link entity is therefore resistant to corruption as their running order in the physical file bears little resemblance to the hierarchy of the user’s own bookmark collection – a key improvement on many proprietary systems that tend to have a rather relaxed approach to maintaining the order of a user’s collection of bookmarks. UMarks, by comparison, is inherently strict with regards to the user’s own hierarchy, and even enforces observance of visual separators.

Portability

The aim for UMarks is to treat a user’s collection of saved links as a simple chunk of data owned by them and therefore easy to shunt around and read from many different sources. To this end the idea is to create a single standalone file that captures a collection of bookmarks, and to store it centrally where it can be accessed by a user in many different ways.

In a local system, such as a desktop computer, the aim would be to store the UMarks file with the rest of the user’s data, probably in its own ‘Bookmarks’ folder. This has the advantage of being accessible by many applications (not just browsers) as well as being easily backed up along with other data. Therefore, the idea is to store the file somewhere in the ‘Home’ directory. For instance, in a Unix-style system it would reside somewhere like ~/Bookmarks.

Another benefit of this approach is the ability to store the file off site, perhaps on a cloud server. This is analogous to the local system above, with the benefit of allowing wider access to the bookmark data. It would be relatively easy to allow other devices, such as mobiles, to use the remote file as the master copy for a local browser on a handheld device. Since syncing is easy with UMarks this would ensure that the same set of bookmarks is available anywhere the user wants to access them.

Inevitably such portability comes at a price, so there is a need to consider security.

Encryption and privacy

Because the driving force behind UMarks is portability there is a real need to protect the file from hostile copying. To this end UMarks should be seen for what it really is: a glorified text file. It is non-proprietary and standards-based because it has been designed to be read by anything that can parse text. One of the benefits of a simple approach like this is the flexibility it makes available: any UMarks file is easily encrypted and equally easy to heavily compress. This makes it not only small enough to move around, but makes it safe to do so.

A key aim of the development of UMarks was the need to realise this; the need for a small, portable, self-contained system that is pre-encrypted prior to movement off the computer or device. An important element of this is a meaningful buy-in from users, and the easiest way to accomplish that is to make it clear the file is only in plain text when held on a user’s own secure system. Everywhere else – in transit, on a remote server etc. – it is encrypted, and therefore unusable by anyone.

A secondary aim of UMarks, then, is to agree an encryption standard that can work on many different devices, including low-powered mobiles and handhelds. By focusing on this element we can include privacy as standard. The idea is that security should be an integral part of a portable data system like UMarks, yet easy for non-technical users to make use of.

Conclusion

Anyone intending to work with UMarks should bear in mind its guiding principle; that the bookmarks belong to the person, and not the software. The format itself is just a means to an end, to allow a single user to access bookmarks on any software or device they use; from a newsreader on their desktop PC, to a browser on a smartphone.

UMarks Logo