Since the latest release, XING is able to embed YouTube and vimeo videos as well as SlideShare presentations in the “What’s new in your network” feed so you can watch and navigate them without having to leave XING. While this isn’t a completely new feature, embedding is now implemented using oEmbed, which gives us more reliability and flexibility, and allows us to integrate more services in the future.
What is oEmbed?
oEmbed is an open format for embedding media from third-party providers. It allows for different media types like videos, pictures and tweets. The oEmbed spec is very simple and was published back in 2008. Since that time it has grown increasingly popular.
So far, embedding was implemented on a case-by-case basis. Website owners could manually copy some code snippets from the media provider and paste them into their website. Social networks, blogging platforms and content management systems have automated the fetching of the embed code, but the process was very close to the manual one, i.e. parse the URL, request additional data from the media provider’s API or, if there isn’t any data available, screen scrape the missing data, and finally parse the results to create an embedded representation of the media. Due to huge differences between providers, adding another media provider required additional effort. This construct is generally quite vulnerable since a minor change by the media provider could break the embedded content. XING has embedded YouTube and vimeo videos in a similar fashion, meaning that they’re likely to break at some point in time, thus making them hard to maintain and extend.
oEmbed instead offers the possibility to bypass provider-specific APIs and avoid screen scraping completely. It standardizes the process of media embedding so that it’s easier and more reliable to embed media from different providers. An oEmbed API is provided by – among others – YouTube, vimeo, Flickr, SlideShare and Twitter. If a user posts, say, a YouTube link to an oEmbed consumer, the embedded video is shown instead of a simple link. Generally speaking, oEmbed turns a URL into an embeddable representation of the media content. Technically, the oEmbed API returns XML or JSON formatted meta data that explains how to embed the media. Depending on the type of media used, the oEmbed response may, among other things, contain an HTML snippet for embedding.
How can it look like?
Isn’t that terribly insecure?
Embedding arbitrary HTML snippets provides a vector for XSS attacks from the oEmbed provider. That’s why we don’t use the so-called oEmbed discovery. Using a certain selector, we collect all of the links to the oEmbed providers we support. We also show a specific icon above the preview image to give the user the idea that they can find content of the type shown when interacting. Clicking on such an image creates an overlay (a lightbox) and asynchronously asks the oEmbed provider for information about the given URL. A whitelist of trustworthy providers directly maps the URLs into requests to the respective oEmbed API. We also have some additional security measures in place: Besides stripping all of the script tags and keeping only a minimal amount of the delivered markup, we also check an iFrame against an attribute whitelist. This ensures no harmful attributes (no matter which encoding is used) are rendered.
What about encryption?
Open-minded yet wary
Users are more and more used to handling a link more like an entity than a simple pointer to another website. oEmbed provides us developers with various ways to display valuable information about a link and attract users with an image and a clear name rather than a “dry” URL. They can even interact with the embedded entity and learn about the content to be found behind the link without leaving the embedding site. Eventually, the challenge will be to open up our platforms to enable better integration of third-party content without neglecting security aspects.