Best practices for feature detection of DOM API

[alice]

One example: WebXR have a feature detection method, supportsSession(), which returns a promise which rejects if the session type is not supported.

Should this return a Promise<boolean>, on the principle that feature detection shouldn't throw?

Also, what other best practices are there for feature detection?

cc @torgo

[annevk]

https://www.w3.org/2001/tag/doc/promises-guide/#rejections-should-be-exceptional applies here I think. In particular, this does not seem exceptional.

[torgo]

We have some text in section 2.3 (New Features should be Detectable) so if we have more to say on this topic it should probably be added here.

[kenchris]

I think there is some overlap between feature detection and fingerprinting (and private browsing mode).

Of the top of my head I have heard different recommendations at different times.

Examples:

• don't expose the objects etc when feature is not available (like no underlying hardware gyroscope for instance)
• always expose (due to avoiding fingerprinting) but let object throw (NotAvailableError or similar) when instantiated - this way you can see whether the browser support the feature or not, but not whether the hardware does

All of this leads to different design and confuses users and spec authors. I am not sure what would be the right answer but it deserves some thought and it also requires some research on what kind of different solutions are in use today.

@anssik @slightlyoff @reillyeon @beaufortfrancois

[torgo]

Suggest having a dedicated breakout session on this during the non-design-review week next month.

[kenchris]

Things to keep in mind

• no diff between regular mode and privacy preserving mode (incognito)
• keeping fingerprinting to the minimum (people can know browser from UA string and features available)
• this involves permissions

Current different ways (non-exaustive):

• Presence of a namespace

if ('bluetooth' in navigator)

• Presence of an object

if ('NFCReader' in window)

• properties on objects, eg. Media Capture

const capabilities = videoTrack.getCapabilities();

if ("pan" in capabilities) { ... }

[torgo]

@triblondon do you have opinions here?

[tomayac]

Not strictly feature detection, but maybe still interesting: the Shape Detection API has a BarcodeDetector.getSupportedFormats() method, since presence of the BarcodeDetector alone may not be enough if the objective is scanning “weird” barcode formats that not all platforms may support.

[scunliffe]

I wonder if there is a solution that enables developers to detect features, but also restricts/reduces fingerprinting?

e.g. browsers are smart enough now to differentiate between a user-driven-event like a mouse click vs. a simulated .click() event applied to a link/button to determine if triggered code like a window.open() call should be allowed or not. This was done to stop spammy websites from launching popup ads, but still allow "desired" popups in web applications.

As such, for many of these features... I wonder if a Just In Time (JIT) model might work where by a check to detect a feature would only be allowed if the code following it attempts to use it.

if('NFCReader' in window){ // check is allowed
  doNFCStuff();
}

if('NFCReader' in window){ // check is denied/blocked
  addToFingerprintingData();
}

Not foolproof by any means, but mixed with browser permissions by domain etc. might cover most cases.

[dbaron]

always expose (due to avoiding fingerprinting) but let object throw (NotAvailableError or similar) when instantiated - this way you can see whether the browser support the feature or not, but not whether the hardware does

It seems like this doesn't help much with fingerprinting, since it's still exposing the information about whether the device is available or not (unless the latter response is after a permission prompt).

It's also worth noting that "implementation doesn't support X" and "implementation supports X but there aren't any devices available" are different results that pages might want to handle in different ways.

[dbaron]

... so what I'm saying is that detection of the support for a feature in the implementation should generally be separate from detection of whether a device to do something with that feature is available. (And the latter might be after a request for user permission.)

[torgo]

Discussed and agreed to close at our f2f.