Today we’re releasing a new version of TimelineJS, but most of you shouldn’t even notice a difference.
We make updates to TimelineJS periodically, and we usually don’t say much about it, partly because people who publish timelines using our embed tool are automatically updated to the new version—there’s nothing they need to change. That includes this new release. However, in this case, we thought it was worthwhile posting for two related reasons.
First, this release is in response to a security vulnerability in previous versions of TimelineJS. For an attacker to take advantage of this vulnerability, they must be able to edit your Google Sheets document, or whatever data source you use for your timeline. (Please note: you should never set your timeline spreadsheets to “anyone with the link can edit.”) We believed that creators would already be taking responsibility for who could edit their timelines, and so considered it an acceptable risk. However, earlier this year, we were contacted by security researcher Zander Work, who argued that there was enough risk of either people accidentally leaving their timelines editable, or by an “internal bad actor” taking advantage of the vulnerability. (We’ll say this again: you should never, ever, set your timeline spreadsheets to “anyone with the link can edit.”)
The security issue is an exposure to “cross-site scripting” attacks, also known as XSS attacks. These attacks take advantage of systems that pass through maliciously crafted HTML to a reader’s browser. For some fields, TimelineJS allows users to use HTML markup, intended for formatting and links. Until now, we did not check that markup, because we wanted people to have maximum flexibility in creating their timelines. With the new release, HTML markup in Google Sheets cells (or any other timeline data source) is “sanitized” to remove potentially risky markup, while known “safe” markup is passed through. The most common markup is generally passed through unchanged, but there’s a small chance that some of the HTML you are using is now stripped. If you use HTML in your TimelineJS Google sheet for links or formatting, you should take a minute to make sure nothing has changed.
This “sanitizing” process is fairly standard in web development today. We didn’t want to reinvent the wheel, and we wanted to take advantage of proven solutions. This led us to the other major change: in order to take advantage of one of these solutions, we decided to update TimelineJS to work a little better with npm and more modern JavaScript building processes.
Under the hood, this is a pretty big change, but it’s our intention that TimelineJS work exactly as it did before, and we’ve done pretty thorough side-by-side testing to see that it does. Nevertheless, with nearly 1 million timelines created (!!), there’s a chance a few of them won’t go so smoothly. As always, we’re happy to take your support requests. Please be sure to send us a URL where we can see the timeline in action—the best thing is the “share link” from the timeline creation tool.
This also sets us up to publish TimelineJS3 to the npm package registry, which has been a much requested feature. In fact, at least a few people have taken it upon themselves to publish a version themselves. Those don’t seem to be maintained, and won’t include the security fix. If installing TimelineJS via NPM is a priority for you, we strongly encourage you to use our package, available now.
For those interested in a more technical write-up, see Zander Work’s post.
About the author
