Skip to main content


Node.js Security Progress Report – Security Release and Node.js 21

By Blog, Node.js, Node.js Security

Thank you to the continued support from the Alpha-Omega project at the OpenSSF Project, helping us make Node.js more secure and easier to build! 

October was busy due to the latest security release affecting Node.js 18 and Node.js 20. Usually, we lock in the Continuous Integration (CI) cycle at least 5 days before a  release. This time, however, due to the recent changes to the CITGM (Canary In The Gold Mine: a simple tool for pulling down an arbitrary module from npm and testing it using a specific version of the node runtime) and changes to the automation of the security release proposal, it was just 3 days.


And, a day after the security release, we put out Node.js 21. Main updates for Node.js 21:

  • V8 JavaScript engine updated to 11.8
  • Stable WebStreams which helps to process data in small sizes for applications
  • A new experimental flag to flip module defaults (–experimental-default-type) – Node.js has two module systems: CommonJS modules and ECMAScript modules. Node.js treats files with a .js extension by default as CommonJS modules. This can now more easily be flipped.
  • Many updates to test runner which allows users to run functional tests and export results

If you’d like to find out more about Node.js 21:

This means a transition from Node.js 20 to LTS. Node.js 21 is now our Current release.

Security Release

In October, Node.js addressed 4 CVEs within Node.js and 2 within its dependencies:

  • 2 High severity issues
  • 1 Medium severity issue
  • 1 Low severity issue in Node.js
  • Security updates for undici and nghttp2

The 20.x release line of Node.js was vulnerable to 2 high severity issues, 1 medium severity issue, and 1 low severity issue. The 18.x release line was vulnerable to 1 medium severity issue, and 1 low severity issue.

Users can always check their version’s vulnerability status by running:

$ npx is-my-node-vulnerable

Security initiatives and assessments

Recently, OpenSSL disclosed 3 security releases which were assessed by the Node.js team as non-critical patches. They were handled in regular releases.

Additionally, two pull requests were created to update Permission Model stability. The Permission Model has been moved to version 1.1 and Active Development. We’ve documented that some files can be read before V8 initialization, which implies before permission model initialization, too.

With the intention of improving the scorecard for different repositories under Node.js, we created 5 pull requests to pin Github Actions by commit-hash. We are evaluating how effective this approach is for non-libraries since it can cause some maintenance burdens for the maintainers. 

You can pin Github Actions by tag without having to manually (or through dependabot) update semver-minor and semver-patch releases. actions/checkout@v2 will always fetch the latest release of v2.

In October, we’ve added support to Ada and simdtuf to our dependency-vulnerability-scanner. And Node.js 21 was added to the cycle.

As a final update, we’ve identified that a previous security release might have broken the usage of the esm npm package. However, considering this package is now archived and the usage of monkey patching is not guaranteed by Node.js, it is unlikely a patch will be produced.

Interested in getting involved with Node.js security? We are actively looking for new contributors! Find out more about the Node.js Security Team here:

From OpenJS World 2023: Revolutionizing Browser Automation: A Deep Dive into the WebDriver BiDi Project and its Integration with Selenium – Tamsil Sajid Amani

By Blog, OpenJS World

Talk from Tamsil Sajid Amani, Software Engineer at BrowserStack at OpenJS World 2023 in Bilbao, Spain, September 19-21, 2023.

The web is constantly evolving, and so is how we need to test it. WebDriver BiDi is a new way to control the browser without compromising the ability to use everyday browsers that people use. It is supported by Google, Microsoft, Mozilla, and Apple, making sure all your users are getting the same level of support. It is an ergonomic and powerful tool for browser automation and testing with support for popular testing frameworks like Selenium with more control over low-level events in the browser. Attendees leave with a clear understanding of how WebDriver BiDi can be used to enhance their browser automation and testing capabilities.

Main Sections

00:00 Introduction

02:05 Browser Automation Testing Timeline

03:56 Browser Automation: Two approaches

06:48 WebDriver “Classic”

12:41 Chrome Devtools protocol

17:54 WebDriver BiDi

18:27 Collaboration

21:21 WebDriver BiDi Demo

25:15 Accessibility 

30:30 Questions

OpenJS Resources

About the OpenJS Foundation

Join the OpenJS Foundation

Follow Us on Social

OpenJS Foundation Warns Consumer Privacy and Security at Risk in Three-Quarters of a Billion Websites

By Announcement, Blog, jQuery, jQuery Security

OpenJS Foundation reports poor security practices across industries in North America, UK and Europe

SAN FRANCISCO – November 1, 2023 – Global web infrastructure is in a precarious position based on new research by the OpenJS Foundation thanks to an OpenSSF grant.

The OpenJS Foundation is announcing the results of an end-user audit based on an IDC survey that shows three-quarters of a billion websites are running out of date software, with most capturing personal and financial information. Over one-third of respondents confirm having experienced a security incident in the last 24 months.

The OpenJS Foundation analyzed the IDC survey results of this end-user audit and other data points and estimated that of the 1.9 billion websites worldwide, almost 90% use the open source software jQuery, and one-third of those, over three-quarters of a billion sites, require an upgrade. Due to the size of the problem, the OpenJS Foundation suggests that a behavioral change to web security is required.

Key findings:

  • 89% of random survey respondents reported knowing the use of jQuery on their internet-facing websites
  • 80% of these organizations capture vital information such as personal identifiable information (PII), including payment information (52%) location (64%), contact information (80%)
  • Websites are essential or high priority for 85% of respondents
  • The business damage from security incidents is severe with 28% reporting loss of customers and 29% reporting loss of revenue. Additionally, 39% reported regulatory violations, and 45% reported brand damage
  • Better security is the #1 motivation for upgrading for 48% of respondents

The end-user audit conducted by IDC surveyed more than 500 people in 23 industries across North America, UK and Europe, representing small, medium and large organizations. 

It is the responsibility of business owners and developers to make their websites secure. Getting actionable information is a key part of the process. Keeping packages up to date is an important way to improve security. Any one package may not be a site’s main security issue and packages can be abused, or used in ways that open up security problems.

Al Gillen, group vice president, Software Development and Open Source IDC, IDC, in a blog post published today on the OpenJS Foundation blog, states: “The take-away from this study is simple: jQuery users have access to a robust, community-supported technology that is free from subscription costs for them to acquire or use, and this project is seeing continual investment and enhancement. Users are already enjoying considerable benefits from the technology, but if you are not using current versions, you owe it to your business to move forward to a supported version to maximize the benefit and minimize any potential risks.” Full IDC blog post is available here.

“There’s a big problem when three-quarters of a billion websites need an upgrade of just one open source project. It leads us to believe companies are using more outdated and unsupported technologies and potentially putting consumers at risk,” said Robin Bender Ginn, executive director of OpenJS Foundation. “To solve a problem of this scale, we need to start thinking about regular assessments of website technology, similar to how people visit their doctor every year for a physical medical checkup.” 

As a result of the study, the OpenJS Foundation is developing a free Healthy Web checkup tool. It will be provided widely to businesses and organizations around the world. The OpenJS Foundation is also seeking to partner with governments, businesses, and consumer advocacy organizations to better the health of the global web economy. 

jQuery made web page development approachable to everyone, but has led to millions of websites remaining on older, unsupported versions. Even as the jQuery Team releases security fixes, these sites often don’t update and remain vulnerable. 

The IDC survey, the Healthy Web checkup tool, and many security improvements were funded by an Alpha-Omega grant. As an associated project of the Open Source Security Foundation, Alpha-Omega’s mission is to catalyze sustained security improvements to the most critical open source software and ecosystems. 

“Many of our engagements start with an audit and then fund security fixes. This situation called for a different approach and we were keen to help,” said Bob Callaway, co-lead of the Alpha-Omega project and engineering manager of Google’s Open Source Security Team. “The Healthy Web checkup tool will be an innovative solution to a thorny problem,” he added. “This problem is not unique to jQuery. We’re hopeful this work can be extended to help everyone understand and mitigate the global risk.” 

“Secure open source software is a public good,” said Omkhar Arasaratnam, general manager of the Open Source Software Foundation (OpenSSF). “We applaud the OpenJS Foundation for making the web more secure through the OpenJS Healthy Web checkup.”

The OpenJS Healthy Web checkup tool takes 5 seconds and currently only checks the version of jQuery. It is a great indicator of whether or not organizations have implemented security practices because of how ubiquitous it is and how easy it is to test.

“The first step to improve the health of your website is to find out if your technology stack needs to be upgraded,” said Michał Gołębiowski-Owczarek, jQuery Core Team member and Senior Staff Software Engineer at Sumo Logic. “We’re constantly improving the security and performance of jQuery and ask people to check the versions of software used on their sites either with the upcoming Healthy Web checkup tool from the OpenJS Foundation or their own assessment.” 

“It is everyone’s responsibility to make their own websites secure. That’s not always a simple task, but ensuring packages are up to date can be a good place to start,” said Timmy Willison, Team Lead for jQuery Core and Lead Front-End Engineer at “The jQuery Team is pleased to work with the OpenJS Foundation as a part of this Healthy Web checkup campaign. Please join with us and the OpenJS Foundation to help improve the health of the consumer web.” 

“Consumer-facing software requires regular maintenance. Checking for updates from packages like jQuery and keeping your website secure is essential. The open web plays such an important role in modern life,” said Timo Tijhof, Infrastructure Lead for jQuery and Principal Engineer at the Wikimedia Foundation. “Like going to a doctor for regular checkups, auditing your website regularly is key to good web health. Please do your part!”

The OpenJS Foundation is assessing expanding the checkup tool to include additional open source JavaScript projects critical to the health of the web.

The OpenJS Healthy Web checkup tool is currently in beta and limited for use by technical evaluators and OpenJS members. General availability is planned for early 2024. OpenJS Foundation is actively seeking partner organizations to join in this important effort.

The new IDC study is freely available: The Benefit of Modernizing jQuery Deployments

OpenJS Resources

To learn more about how you could be a part of the OpenJS Foundation, click here.

About OpenJS Foundation

The OpenJS Foundation is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large. The OpenJS Foundation is made up of 35 open source JavaScript projects including Appium, Electron, Jest, jQuery, Node.js, and webpack and is supported by 26 corporate and end-user members, including GoDaddy, Google, IBM, Joyent, Microsoft, and the Sovereign Tech Fund. These members recognize the interconnected nature of the JavaScript ecosystem and the importance of providing a central home for projects which represent significant shared value. 

About Alpha-Omega

Alpha-Omega is an associated project of the OpenSSF, established in February 2022, funded by Microsoft, Google, and Amazon, and with a mission to protect society by catalyzing sustainable security improvements to the most critical open source software projects and ecosystems, trying to build a world where critical open source projects are secure and that security vulnerabilities are found and fixed quickly. For more information please visit the Alpha-Omega website.

About the OpenSSF

The Open Source Security Foundation (OpenSSF) is a cross-industry initiative by the Linux Foundation that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. The OpenSSF is committed to collaboration and working both upstream and with existing communities to advance open source security for all. For more information, please visit us at 

About Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1000 members and is the world’s leading home for collaboration on open source software, open standards, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js and more are considered critical to the development of the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit their website.

This post was originally published on PR Newswire.

Better Features and Operational Benefits Come with Current jQuery Use

By Blog, jQuery, jQuery Security

Sponsored guest post by Al Gillen, International Data Corporation (IDC)

After decades of being sequestered in a back room and treated as a service department for other parts of the business, information technology (IT) professionals now enable modern, critical business operations. In many organizations today, IT is becoming integral to and inextricably intertwined with the business. Accompanying this newfound attention comes increased expectations and increased responsibility to ensure that applications, application services, and data services are robust, feature-rich and secure.

As a result, the pressure on IT departments to perform well and deliver quickly is increasing, thanks to greater corporate reliance upon the applications, websites, and cloud services used to operate and promote the business. In many cases, the software directly powering today’s external-facing solutions is open source, and in the majority of scenarios, there is reliance, at least in part, upon open source software (OSS) technologies in the underlying software stack. 

OSS is available in a multitude of formats and support models. For many critical enterprise deployment scenarios, OSS technologies must have a reliable governance model and a large and healthy community surrounding the technology. In some cases, there is also a commercial support option. Of course, if the technology is available with ongoing maintenance and upgrades at no subscription cost for accessing that ecosystem, that is a real bonus. 

Such is the case for jQuery, which continues to evolve with new features and stronger security thanks to an engaged and attentive community organized by and supported by the OpenJS Foundation, a Linux Foundation organization. The OpenJS Foundation, working with its community, continues to deliver regular updates to the widely-used jQuery solution.

IDC conducted research on the use of jQuery in the U.S., Germany and the U.K., with a total of 509 survey respondents in those three countries representing small, medium and large businesses across 23 distinct industries. The survey participants were selected based on knowing their company’s use of internet-facing websites, but were not qualified based on knowledge of or confirmed use of jQuery. After that qualification, the study found that 89% of the respondents confirmed knowledge of the use of jQuery on their internet-facing websites. This data indicates that jQuery is heavily deployed throughout Internet-facing websites today.

This IDC study focused on gauging how current the customer base is, in terms of the versions of jQuery deployed to support internet-facing websites. The good news is that 44% of organizations that IDC contacted are using current versions of jQuery on at least some of their Internet-facing websites. But the less good news is that over half of the respondents are either slightly behind or significantly behind on the versions of jQuery in use on their websites, with those respondents citing the use of a version of jQuery that is no longer under maintenance by the OpenJS Foundation and its community. Unfortunately, many users are unaware of what versions of jQuery are under active support today.

There are, of course, risks associated with using any software that may no longer be under current maintenance, and this concern is not limited to open source software; the same would be true of using proprietary software that is no longer supported, patched, and updated.

But equally important is that some of the best features that a given technology offers are typically found in the most modern versions. These cutting-edge features often are used by digital innovators to create differentiation for their customer experience or the user experience associated with the products and services they deliver.

Further compounding the risks associated with using out-of-support versions of jQuery is that most organizations that completed this survey indicated that they are using jQuery for capturing and processing personally identifiable information (PII). Across the survey sample, including respondents using in-support and out-of-support versions of jQuery, 80% of the respondents are capturing one or more types of PII. For organizations using versions of jQuery that pre-date version v3.6.0, this data capture can represent a potential risk, as any mishandling of PII could potentially lead to regulatory compliance issues for the business.

The good news is that most organizations say they are either up to date or have the ability to get there. In fact, 3 out of 4 respondents fall into this camp. The other quarter of the respondents to this survey say they will need help or cannot update their jQuery instances. Even in the case of the 36% who say they can get current (roughly half of the 75% that say they are current or can get current), the urgency to make that upgrade – even with the capture of PII and the lack of ongoing support from the jQuery community – is not enough motivation to make such an upgrade a high priority.

The take-away from this study is simple: jQuery users have access to a robust, community-supported technology that is free from subscription costs for them to acquire or use, and this project is seeing continual investment and enhancement. Users are already enjoying considerable benefits from the technology, but if you are not using current versions, you owe it to your business to move forward to a supported version to maximize the benefit and minimize any potential risks. 

Node.js Security Progress Report – Looking Into SBOM for Node.js

By Blog, Node.js, Node.js Security

September was a busy month with participation in 3 different events, regular work on security reports, and discussions around creating an SBOM for Node.js.

In September, we responded to 9 submitted reports (3 Triaged, 3 Closed as non-applicable, 3 Closed as informative) and the average first response time was 4 hours and 30 minutes, slightly faster than in August.

Work on Node.js security is thanks in part to the Open Source Security Foundation (OpenSSF) and the Project Alpha Omega. You can read more details about our partnership here: Security Support Role 2023.

Possible Software Bill of Materials (SBOM) for Node.js

We are now actively looking at ways to include a Software Bill of Materials (SBOM) for Node.js releases. In May 2021, the US government issued an Executive Order on Improving the Nation’s Cybersecurity which specifically advocates providing SBOMs for software products. 

From the executive summary:

“…the term ‘Software Bill of Materials’ or ‘SBOM’ means a formal record containing the details and supply chain relationships of various components used in building software.  Software developers and vendors often create products by assembling existing open source and commercial software components.  The SBOM enumerates these components in a product.  It is analogous to a list of ingredients on food packaging.”

However, exactly what the SBOM includes is debatable. Timing for implementation is not decided. The full internal Node.js discussion on adding an SBOM for Node.js is available here: 

Node.js Security WG Initiatives

Creating Security Release issues is now automated. The new command manages all the states of a security release. It  includes CREATE. In the future, it will include requesting CVEs, creating issues, sending emails and more.

Node.js Security Sustainability

September was a month full of speaking engagements. We believe events like the ones listed below are an excellent opportunity to connect directly with the Node.js community and to get feedback and welcome outside contributors. We hope to meet you face-to-face in the near future!

  • “The State of Node.js Security”
    • Node.js Collab Summit, Bilbao, Spain, Sept 18th
  • “The Journey of Node.js Permission Model”
    • OpenSSF Day, Bilbao, Spain, Sept 18th
  • “Improving the security of a large open source project”
    • Open Source Summit EU, Bilbao, Spain, Sept 20th
  • “Node.js Project”
    • Grace Hopper Celebration Day, virtual, Sept 22th
  • “Improving the security of a large open source project”
    • OpenJS World, Shanghai, China, Sept 26th

Interested in getting involved with Node.js security? The new Permission Model is still experimental, which makes it the right time for you to try it. We are actively looking for new contributors. And, we’re super friendly! 🙂

Find out more about the Node.js Security Team here:

Node.js 21 Available Now!

By Announcement, Blog, Node.js

The release of Node.js 21 is available now! Node.js 21 replaces Node.js 20 as our current release line, and Node.js 20 is being promoted to long-term support (LTS). 

What’s the difference between the two releases? Node.js 21 is great for early feature testing for your own specific environment, while Node.js 20 LTS is for production deployments. Node.js 21 will be ‘Current’ release for the next 6 months, until April 2024. Here is our full Node.js release schedule.

​​Highlights in Node.js 21 include updates of the V8 JavaScript engine to 11.8, stable WebStreams, a new experimental flag to flip module defaults (–experimental-default-type), many updates to our test runner, and more!

“If you’re interested in getting access to interesting new features early, Node.js 21 is a great way to test and see what’s coming. Our release schedule specifically covers this. If you’re already in active deployment or if you are planning for it, Node.js 20 and 18 LTS are for you,” said Rafael Gonzaga, Node.js Technical Steering Committee (TSC) Member. “Many thanks to our open source contributors for making Node.js better and better. Thanks also to OpenSSF and Project Alpha Omega for helping us improve Node.js security.”

“Node.js demand among developers continues to grow as the need for reliable and scalable web applications rises. With Node.js 21, you can evaluate the current state of Node.js features directly,” said Michaël Zasso, member of the Node.js TSC. “As just one example, Node.js has had a stable test runner since Node.js 20. There’s no need to install a third-party module, and you can create test scripts easily. Node.js 21 includes many improvements to the test runner. Try it out!” 

Main updates for Node.js 21

  • V8 JavaScript engine updated to 11.8
  • Stable WebStreams which helps to process data in small sizes for browser applications
  • A new experimental flag to flip module defaults (–experimental-default-type) – Node.js has two module systems: CommonJS modules and ECMAScript modules. Node.js treats files with a .js extension by default as CommonJS modules. This can now more easily be flipped.
  • Many updates to test runner which allows users to run functional tests and export results
  • Full changes and commits here

Download Node.js 21 here and get started testing right away! More details can be found in the Node.js blog.

How the Wikimedia Foundation Balances Security and Open Information in Web Development

By Blog, Case Study


The Wikimedia Foundation is the non-profit that hosts Wikipedia and other free knowledge and open data projects. These projects are made possible by a global community who, together with the Foundation, comprise the “Wikimedia movement”. The Wikimedia movement is united by a vision: to bring about a world in which every single human being can freely share in the sum of all knowledge.

Photo by Sage Ross (CC BY-SA 2.0)

We talked with Timo Tijhof, Principal Engineer at the Wikimedia Foundation, to find out how the organization approaches security and performance at scale. Timo has worked at the Wikimedia Foundation for over 10 years, first starting as a front-end developer and eventually as a part of the Performance Team. 

The Wikimedia movement is rooted in the culture of freely licensed software. The MediaWiki application that Wikipedia runs on, and all other software developed at the Foundation, is open source. “That includes the configuration and datacenter automation of our web servers, databases, and CDN service,” said Timo. The Wikimedia community and any other individual or organization may inspect, contribute to, reuse for themselves, or fork any aspect of the platform at any time. This philosophy is also the basis of long-standing security practices which support visibility and openness.

Increased Security is about Increased Visibility and Trust

We live in an incredible world. Today, most online devices are powered by open source. Whether the data centers of video streaming giants and social media sites, or your smartphone, they likely run an open source operating system like Linux or a BSD derivative. The vast majority of websites are also built with open source tools, or run on open source platforms. When you build on existing software that is developed by another organization or community, this is called an “upstream”.

The Wikimedia Foundation relies heavily on upstream technology to power its platforms. This allows the organization to focus on its core mission of providing free knowledge to the world, rather than on developing and maintaining technology from scratch. Additionally, by collaborating with other open source projects, the Foundation is able to give back to the broader free software ecosystem and help advance the state of technology for everyone.

The Wikimedia Foundation is notable for operating exclusively with upstreams that are also open source. This ensures the community’s freedom principles (to freely inspect, modify, reuse, and fork) are not hindered by proprietary components.

New Wikimedia production software components or dependencies must pass certain fitness checks and a chain of trust for the software’s security and integrity. When the Wikimedia community creates software that is peer-reviewed during development, this trust follows implicitly from its public policies and standards. When adding a new third-party package or dependency (“upstream”), this chain needs to be established by other means.

The Wikimedia Foundation extends its chain to several credible upstream vendors and communities. For example, Debian, known for its Linux operating system, is host to the highly trusted and curated Debian package repository. When a package is present in the Debian repository, this signals trust, stability, and confidence to the industry. Timo adds, “While we usually don’t audit source code of Debian packages, installing a Debian package may still require a concept review to validate and verify that the package actually intends to meet our scale, threat model, and performance requirements.”

When considering PHP or JavaScript libraries from an anonymous and open registry like npm or Packagist, the Wikimedia Foundation audits the code as if it were its own. The Wikimedia Foundation keeps on-going costs to a minimum by adopting upstream packages in areas that solve non-trivial problems, have stable external requirements, and sit behind a module boundary. “Dependencies should reduce cost, not increase it. In practice, we only consider packages with few or no transitive dependencies, written for a stable runtime,” said Timo.

As an added precaution, the Wikimedia Foundation prohibits networking to third-party services in its production realm. When deploying or installing the MediaWiki application, it does not download JavaScript or PHP packages from npm or Composer. Instead, upstream packages are downloaded as a file with an integrity hash, and already checked into Git. This approach implements the organization’s security requirements, allowing for transparent auditing, patch-ability, and independent offline deployment. “It also helps with faster onboarding, consistent and reproducible development, and creates a natural space for auditing upstream changes,” said Timo.

The Most Localized Software in the World

With over 300 language editions, Wikipedia might be among the most-translated literature in the world. Wikipedia editors usually write or translate articles manually, and in recent years, the ContentTranslation tool has helped editors do this more efficiently, producing over 1 million articles through this new tool alone. 

The MediaWiki platform underneath it all recognizes and localizes its user interface in over 400 languages, including gender, pluralization rules (“10 new messages”), and sort order ICU collations. “We contribute to the Unicode CLDR standard on behalf of Wikipedia’s language communities. These contributions flow downstream to other Unicode customers such as Linux, Apple, and Microsoft.” said Timo.

Languages like Arabic and Hebrew are written from right to left. CSSJanus takes stylesheets designed and developed for left-to-right languages like English, and automatically converts them into right-to-left layouts. “We deploy the MediaWiki platform on a weekly basis. Each change to functionality is deployed to all supported languages from day 1, every time. CSSJanus is part of what makes this feasible and with little to no developer training,” said Timo.

Not all issues are that easy! During VisualEditor development, extensive effort went into localizing the bold and italic toolbar buttons. The familiar “B” and “I” buttons usually make place for an equivalent abbreviation, such as F (Fett) and K (Kursiv) in German, with a stylized A for language communities that have no accepted standard. But, early adoption of English-centric software led to “B” and “I” becoming the established and culturally familiar design pattern in some languages. In Hebrew, Czech, and Malayalam “correcting” these with a translation actually created confusion.

No Profit Motive Means Better Support

Large corporations, driven by profit motives, regularly drop support for older devices and browsers. The Wikimedia Foundation, however, has an imperative to make information more accessible, not less.

How does the organization pull that off without the resources of a large corporation? “Through equal parts being aggressively lean and aggressively uncompromising,” says Timo.

The organization saves development and testing costs by writing and deploying native JavaScript that targets only modern browsers. Through an approach inspired by BBC News’ cutting the mustard, the Foundation enables millions of people (1% of its 2 billion monthly users) to access Wikipedia through a JavaScript-free experience. This is the same experience that all page views start at prior the (optional) arrival of JavaScript code.

The Wikimedia Foundation’s development principles and browser support policy reflects this by emphasizing the importance of progressive enhancement.

Viewing Wikipedia through a web browser is the most common access method, but Wikipedia’s knowledge is consumed far beyond the canonical experience at “Wikipedia content goes everywhere. It’s distributed offline through Kiwix and IPFS, rendered in native apps like Apple Dictionary, and even shared peer-to-peer through USB sticks,” said Timo. What these environments have in common is that they may not involve JavaScript as they require high security and high privacy. This is made possible at no extra cost due to APIs offering complete content HTML-first, with CSS and embedded media based on open formats only.


The Wikimedia Foundation prioritizes both security and openness. To achieve this balance, it implements a number of practices and policies that ensure that it protects both the freedoms and the privacy of its audience, all while sharing information transparently.

For example, the Foundation publishes an annual transparency report detailing its response to information and takedown requests twice per year. The Wikimedia Foundation’s Board positions are largely held by community members, and appointed by public election through anonymous and cryptographically-verifiable votes from any eligible Wikipedia account. Its Governance Wiki publishes the Foundation’s bylaws, board decisions, and meetings.

The Foundation participates in an ecosystem of organizations that collaborate on freely-licensed information and open-source software. Overall, the organization balances exceptional security and openness by implementing strong security practices, and providing transparency about their policies and procedures.


Timo is currently helping with the Open Source Security Foundation (OpenSSF) Project Omega-Alpha and the OpenJS Foundation to reduce potential security risks for jQuery. OpenSSF has committed close to $350,000 to reduce potential security incidents for jQuery by helping modernize its infrastructure and its code. The goal for 2023 is to update jQuery infrastructure, identify potential security risks and pain points for end-users, and understand the factors that influence the adoption of new software versions.

Join us in Shanghai for OpenJS World China

By Blog, Event

We’re excited to be at Open Source Summit in Shanghai, China from September 26-28! We have a great lineup of JavaScript speakers at the event, and we encourage you to join us on September 26. Details are below.

📅 Date: September 26, 13:30-16:30 PM

📍 Location: Shanghai Convention & Exhibition Center of International Sourcing

🚪 Room: 3M Room 3M5A

✏️ Register: Open Source Summit China


Improving the Security of a Large Open Source Project One Step at a Time

Rafael Silva, Nearform

Node-RED in Industrial IoT

Kazuhito Yokoi, Hitachi, LTD

New Electron Forge with Vite

Leo Wang, HelloBike

YodaOS JSAR: The Web Trio in the Era of Spatial Computing

Yazhong Liu, Rokid

Node.js Training Sale

In honor of OpenJS World, all Node.js training and certification will be 60% off! Use code OPENJSWORLD2023 at Linux Foundation Training and Certification.

Node.js Security Progress Report – Fewer Steps and More Releases

By Blog, Node.js, Node.js Security

In July, we continued our regular work triaging and fixing Node.js security issues. We also welcomed a new contributor to the Node.js Security Working Group team, and increased the number of security releases, which improves security by making updates available more quickly. We have also continued to evaluate the Permission Model including adding a startup benchmark, adding support for V8 HeapSnapshot and Node.js reports, and cut down the number of steps it takes to create a security release. Nice progress!

As always, we want to say thank you to OpenSSF and Project Alpha Omega for their support. You can read more details about our partnership here: Security Support Role 2023.

Fixing and Triaging Security Issues

We closed 8 reports in July with 7 developers participating. Our average first response time in July was 53 hours, compared to only 3 hours in June, but we don’t expect month-to-month to always improve. It’s easy when we receive a report from contributors about the Node.js codebase, because we can quickly assess whether the report is accurate or not, almost at-a-glance. But sometimes we get reports that require a long assessment discussion before triagging the report as valid. In other words, not all reports are created equal. This elongates the process.

We also had discussions around the Node.js policy mechanism. Policies are a security feature intended to allow guarantees about what code Node.js is able to load. Some incoming issues were actually not vulnerabilities. This means people are opening issues in part because our descriptions are not clear enough. We are looking to improve in this area.

Support for Security Releases

We have started to reduce the period between security releases. 2 security releases in in the past 2 months. By shipping security versions faster and more often, it means people will get more secure versions. 

For the most recent Security Release (released on Aug 9, 2023), all the processes described in the security release process were completed, including evaluating all Reports, requesting CVEs, and doing the pre- and post- Security Release announcements). The Security Release includes updates to OpenSSL. 

And, two new people were interested in joining the release team. This kind of real, direct participation is great news!

Node.js Security WG Initiatives

Check out the 2023 Security Initiatives here:

We are continuing to reevaluate the Permission Model. We want to better understand how useful the Permission Model is to end users. We are getting positive feedback so far. We have also done research comparing Permission Models for other runtimes and languages. We looked at Deno, Python, Ruby, and Java. The only Permission Model similar to Node.js is Deno.

Among other improvements to the Permission Model, we added a startup benchmark – nodejs/node#48905. It shows the impact on performance of the Permission Model when it starts being used. According to our benchmark tests, the overhead is low, which is excellent.

More Permission Model improvements include:

  • The Permission Model Tree can be visualized by the debug environment variable NODE_DEBUG_NATIVE=PERMISSION_MODEL
  • Fixed Permission Model usage when using Node.js REPL
  • Restricted all available resources (file system, worker, child_process, inspector) when the permission model is enabled

We also are continuing to assess our security processes against Best Practices and are looking for continuous improvement on every Security WG call. This project was formerly known as the Core Infrastructure Initiative (CII) Best Practices badge. and was originally developed under the CII. It is now part of the OpenSSF Best Practices Working Group (WG). The OpenSSF is a foundation of the Linux Foundation (LF). The project was formally renamed from “CII Best Practices badge” on 2021-12-24. We have completed the Entry Level for CII-Best-Practices. For the Silver Level, there is only one question remaining! We are aiming to get to the Gold level soon. nodejs/security-wg#953

The PR to automate the security release process for security releases has been merged! nodejs/node-core-utils#665 This further automates the release process, cutting it down from 26 steps to 20. Not all steps are created equal, and the reduced steps are some big ones that took extra time. This is a huge win on the release side. And a PR has been created to automate the next Security Release issue. It is not merged but it is ready. It was used with the most recent security release. It is an  “absolute significant productivity boost.”

Get Involved

Recent and Upcoming Speaking Engagements

Are you interested in getting involved? The new Permission Model is still experimental, which makes it the right time for you to try it. Be sure to join us for this month’s meetings:

From OpenJS World 2023: How the npm CLI Team Manages (Almost) 100 Open Source Projects – Luke Karrys

By Blog, OpenJS World

Talk from Luke Karrys, Senior Software Engineer at GitHub at OpenJS World 2023 in Vancouver, Canada, May 10-12.

The npm CLI team manages almost 100 different projects that account for 4,000,000,000  downloads per month. And the best part is all of it is open source! Each project includes automated releases, open bug bounties, triage for community issues and pull requests, (almost) full test coverage, and is all managed by a team of four engineers. 

In this talk, npm CLI engineer Luke Karrys covers the tooling and processes that allow the team to confidently and securely ship new releases every week for the CLI and some of the most used packages in the JavaScript ecosystem including Semver and which. In the talk, Luke details lessons the team has put into practice from their collective decades of open source experience.

Luke’s slide deck is available here.

Main Sections

0:00 Introduction

2:30 npm CLI team responsibilities

6:02 Everything is open

15:34 “Is this thing still maintained?”

20:53 So how do we do this? Patterns, process, automation, tooling

22:10 Patterns 

35:04 Process  

37:07 Automation

39:05 Tools 

40:05 Thanks!

OpenJS Resources

About the OpenJS Foundation

Join the OpenJS Foundation

Follow Us on Social