Research
Security News
Malicious npm Packages Inject SSH Backdoors via Typosquatted Libraries
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.
browser-statuses
Advanced tools
Implementation status for Web specifications based on info from external platform status sites
This repository contains implementation support information of Web technologies on main desktop and mobile Web browsers, assembled from data gleaned from external open source platform status projects:
This Web technologies included in the final list are those for which there exists some implementation information. The list is expected to grow over time. It should roughly contain specifications in browser-specs, in other words those published by W3C Working Groups, as well as standards and proposals developed or incubated in W3C Community Groups, the WHATWG, or the Khronos Group.
The data is distributed as an NPM package. To incorporate it to your project, run:
npm install browser-statuses
You can then retrieve the list from your Node.js program:
const impldata = require("browser-statuses");
console.log(JSON.stringify(impldata, null, 2));
Alternatively, you can either retrieve the latest
release or fetch
index.json
.
Note: If you choose to fetch the index.json
file directly, keep in mind
that it may contain (possibly incorrect) updates that have not yet been included
in the NPM package and the latest GitHub release.
The implementation info is available for the following browsers:
identifier | name | type |
---|---|---|
baidu_android | Baidu Browser | mobile |
chrome | Google Chrome | desktop |
chrome_android | Google Chrome | mobile |
edge | Microsoft Edge, based on Chromium | desktop |
firefox | Mozilla Firefox | desktop |
firefox_android | Mozilla Firefox | mobile |
opera | Opera | desktop |
qq_android | QQ Browser | mobile |
safari | Apple Safari | desktop |
safari_ios | Apple Safari for iOS | mobile |
samsunginternet_android | Samsung Internet | mobile |
uc_android | UC Browser | mobile |
webkit | Webkit | engine |
Each entry in the list describes the implementation status of a specification series, and/or of some of the features it defines, on main desktop and mobile Web browsers. Each entry has the following overall structure:
{
"shortname": "series shortname",
"support": [
{
"ua": "user agent identifier",
"status": "implementation status",
"source": "platform status project that gave birth to this info",
"details": [
{
"status": "implementation status",
"flag": true,
"notes": ["Possible implementation notes"],
"href": "URL to the corresponding platform status project page"
},
"other implementation status pages considered to compute overall status"
],
"selected": true
}
],
"features": {
"feature name": {
"url": "URL of the section that defines the feature in the spec",
"title": "Human readable description of the feature",
"support": ["same construct as main one"]
}
},
"polyfills": [
{
"url": "URL of a polyfill library",
"label": "Name of the polyfill library"
}
]
}
In many cases, the features
level will not exist, and implementation support
information will only exist at the series level. Here is a simple example
(support info truncated to keep number of lines minimal):
{
"shortname": "beacon",
"support": [
{
"ua": "chrome",
"status": "shipped",
"source": "bcd",
"details": [
{
"status": "shipped",
"notes": [
"Starting in Chrome 59, this method cannot send a <code>Blob</code> whose type is not CORS safelisted. This is a temporary change until a mitigation can be found for the security issues that this creates. For more information see <a href='https://crbug.com/720283'>Chrome bug 720283</a>."
],
"href": "https://developer.mozilla.org/docs/Web/API/Navigator/sendBeacon",
"representative": true
}
]
},
{
"ua": "chrome",
"status": "shipped",
"source": "chrome",
"details": [
{
"status": "shipped",
"href": "https://www.chromestatus.com/feature/5517433905348608",
"representative": true
}
],
"selected": true
},
{
"ua": "firefox",
"status": "shipped",
"source": "bcd",
"details": [
{
"status": "shipped",
"href": "https://developer.mozilla.org/docs/Web/API/Navigator/sendBeacon",
"representative": true
}
],
"selected": true
},
{
"ua": "firefox",
"status": "shipped",
"source": "caniuse",
"details": [
{
"status": "shipped",
"href": "https://caniuse.com/#feat=beacon",
"representative": true
}
]
}
]
}
shortname
A shortname that uniquely identifies the spec series. In most cases, the series
shortname is the shortname of an individual spec in the series without the level
or version number. For instance, the series' shortname for css-color-5
is
css-color
. When a specification is not versioned, the series' shortname is
identical to the spec's shortname.
All spec series described in this project must exist in
browser-specs. In other words, the
value of the shortname
property must match the value of a
series.shortname
property
in the index.json
file of browser-specs.
The shortname
property is always set.
support
The list of implementation support information for the specification series. Each item in the list is an Implementation info object that describes the implementation support in a given browser.
There may be more than one implementation support information in the list for
the same browser, as information may come from different sources. The most
authoritative source will be flagged with a selected
property set
to true
.
The support
property is usually set, but there may exist a few specs in the
list for which there is no implementation support information, and that still
appear in the list, e.g. because there are known polyfills.
features
A list of specific features defined in the specification, indexed by some unique feature identifier.
url
A pointer to the definition of the feature in the latest Editor's Draft of the specification.
The URL must be an absolute URL.
The url
property should be set whenever possible. It may not be set in cases
where the feature describes a generic concept (e.g. "support in workers").
title
A short human-readable English title for the feature.
support
The list of implementation support information for the feature. Each item in the
list is an Implementation info object that
describes the implementation support in a given browser. See also
support
.
polyfills
A list of known polyfills for the specification. Each polyfill has the following properties.
url
The URL to the web site that describes the polyfill.
The url
property is always set.
label
The name of the polyfill.
The label
property is always set.
All items in support
properties describe the implementation status of the
underlying specification or feature in a given browser, collected from one of
the external platform status projects.
The structure and possible properties that may appear in an implementation info object are illustrated by the following example:
{
"ua": "safari",
"status": "experimental",
"source": "caniuse",
"guess": true,
"flag": true,
"partial": true,
"selected": true,
"details": ["support info details"]
}
ua
An identifier for the browser, see List of web browsers.
The ua
property is always set.
status
The implementation status for the spec or feature. Value may be one of:
"shipped"
: spec or feature is supported"experimental"
: support for the spec or feature is available but not final"indevelopment"
: implementation of the spec or feature is ongoing"consideration"
: support for the spec or feature is under consideration but
not under active developement."notsupported"
: spec or feature is not supported in the browser.""
(only when implementation info was entered manually): implementation status reported by platform status projects is incorrect. Actual implementation status is unknown.The status
property is always set.
source
The provenance for the implementation status information. Can be one of:
bcd
: MDN's Browser Compatilibity Data projectcaniuse
: Can I Usechrome
: Chrome Platform Statuswebkit
: Webkit Feature Statusfeedback
: Specific feedback receivedother
: Heard through the grapevineThe last two types of information are maintained manually in this repository. They should only be used as last resort when information from other sources is invalid or inexistant for some reason.
The source
property is always set.
flag
A boolean flag set to true
when the spec or feature is available behind a flag
and needs to be manually enabled by the user before it may be used.
The flag
property is only set when it is truthy.
guess
A boolean flag that may only appear at the spec series level, set to true
when
the implementation info was derived from support for individual features that
the specification defines.
When the flag is true, the features
property gives the
list of feature identifiers that were used to derive the overall implementation
status.
The guess
property is only set when it is truthy.
partial
A boolean flag set to true
when implementation of the spec or feature is known
to be incomplete.
The partial
property is only set when it is truthy.
prefix
A boolean flag set to true
when the implementation of the spec or feature
requires a prefix (e.g. webkitXXX
), as is typically the case as long as an
API is not final.
The prefix
property is only set when it is truthy.
selected
A boolean flag set to true
when the implementation information is the best
one in the list for the browser, typically because it originates from the
most authoritative source for the browser (Chrome Platform Status for Chrome,
Webkit status for Safari).
The selected
property is only set when it is truthy. For each browser that
appears in a support
list, there will always be one and only one
implementation info object with a selected
flag set to true
.
details
The implementation status at the spec series or feature level is often computed
by looking at a set of platform status entries. The details
property is an
array that lists the implementation status for each of them.
Note: to keep the index.json
file to a reasonable size, this array
currently only contains implementation details for entries that are
representative.
Each item in the array looks like the following example:
{
"status": "shipped",
"href": "https://www.chromestatus.com/feature/6488656873259008",
"representative": true
}
Some of the properties that may appear in details
items are the same as those
in support
: status
, flag
, partial
,
prefix
.
Additional properties are described below.
href
The absolute URL of the page that describes the spec or feature in the platform status project that is at the source of the info.
The href
property is always set. It uniquely identifies the related entry in
the platform status project.
representative
A boolean flag set that indicates whether the related entry in the platform status project is considered to be representative of the implementation of the underlying spec or feature. There may be more than one representative entry for a given spec or feature.
When there are entries for which the representative
flag is set, only these
entries are taken into account to compute the final implementation status of
the underlying spec or feature, even though the implementation status of non
representative entries still appears in the details
array.
In the absence of entries for which the representative
flag is set, the final
implementation status takes the individual implementation status of all
(non representative) entries into account, and the resulting status is
considered to be a guess (see the guess
flag).
The representative
flag is only set when it is truthy.
notes
A list of implementation notes, collected from the implementation info source.
The notes
property is only set when needed.
If you believe that a spec or a feature should be added, modified, or removed from the list, or if you would like to otherwise contribute to this project, please check the contributing instructions.
This project adheres to Semantic Versioning
with the following increment rules given a major.minor.patch
version:
major
: A property disappeared, its meaning has changed, or some other
incompatible API change was made. When the major
number gets incremented, code
that parses the list likely needs to be updated.minor
: A new property was added, the list of spec changed (a new spec was
added, or a spec was removed). Code that parses the list should continue to work
undisturbed, but please note that there is no guarantee that a spec that was
present in the previous version will continue to appear in the new version.patch
: Implementation info about one or more specs changed. Minor updates
were made to the code that don't affect the list.index.json
manuallyTo re-generate the index.json
file locally, run:
npm run build
To run all tests:
npm test
Tests are run automatically on pull requests.
Implementation support information gets assembled from the following external open source platform status projects:
The code that generates and validates the index.json
file makes use of a
number of open source libraries, listed as dev dependencies in
package.json
. Kudos to everyone involved in these projects! 🙏
FAQs
Implementation status for Web specifications based on info from external platform status sites
We found that browser-statuses demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.
Security News
MITRE's 2024 CWE Top 25 highlights critical software vulnerabilities like XSS, SQL Injection, and CSRF, reflecting shifts due to a refined ranking methodology.
Security News
In this segment of the Risky Business podcast, Feross Aboukhadijeh and Patrick Gray discuss the challenges of tracking malware discovered in open source softare.