In particular, https://www.chromium.org/security-keys notes that it's possible to get a permission prompt if you ask for attestation.

great site! continue updating it!

I plan to create a pull request that adds the following Generic Sensor API permission requests:

• AmbientLightSensor
• Accelerometer
• LinearAccelerationSensor
• GravitySensor
• Gyroscope
• Magnetometer
• UncalibratedMagnetometer
• AbsoluteOrientationSensor
• RelativeOrientationSensor
• GeolocationSensor
• ProximitySensor

This expands on #13.

Right now, we e.g. call navigator.storage.persist() regardless of whether navigator.storage exists (for almost everyone, it doesn't exist right now). We should surface the absence of an API better.

All platforms, tested on 4/20/20
Chrome 84.0.4115.5 (Official Build) dev (64-bit) (cohort: Dev) and Firefox 74.0.1
Windows 10 Pro Version 1909
not a regression

While the site is toggled to HTTP, the notifications do not launch in Chrome and Firefox. There are no warnings on the site about this so it's easy to accidentally conclude that notifications aren't working if you didn't know that this was expected behavior.

I'd like to see some text on the site letting users know about the expected behavior just to make testing easier.

When the WebHID chooser is dismissed without a selection, the requestDevice promise resolves with an empty array (i.e. it does not reject). This should not be treated as a success since no permission was granted.

Would the team be interested in a PR that adds enough support for this site to meet Chrome's PWA installability bar? This would entail an app manifest with icons, and a service worker.

One plan was to do this once GitHub Pages launched HTTPS support, since we need HTTPS to work. Today's announcement reminds me we still need to do it!

@adrifelt, two questions:

• Is there an Enamel point of contact I should use for the registration migration?
• Other Google projects (that aren't Google products) use GitHub Pages and/or Let's Encrypt; any concerns with using it for permission.site?

(This sort of overlaps with issue #7)
Newer versions of Chrome have separate Camera and Microphone sections in chrome://settings/content. Would you consider adding separate Camera and Microphone permission buttons, in addition to the current combined "Audio + Video" button?

@jyasskin, is https://github.com/chromium/permissions.request "ready for production"? Can/should we use it?

The code from https://googlechrome.github.io/samples/presentation-api/ could be used.

As of Chrome 61, this demo does not work on Android. If that is still the case when this issue is addressed, we should include a note in the Notes table.

Instead of just throwing an error in the browser’s console, consider showing in the site’s UI that an error occurred; e.g. when the user clicks on a button which causes an error, you could add

<span style="color: red;">⚠</span>

to the button:

Update: Using a pseudo-element would probably be a better idea.

button.error::after {
    content: " ⚠";
    color: red;
}

There is a demo at https://avayvod.github.io/remote-playback/test.html.

e.g. audio:

https://www.google.com/intl/en/chrome/demos/speech.html

In Chrome, the tab indicator stops when you pause recording.

Dear Admin, I will add dark theme for permission site, Kindly asign me this.

The implementation of the Bluetooth button currently passes filters: [{services: ['battery_service']}] to navigator.bluetooth.requestDevice(). The result is that only devices that support this service are shown in the resulting UI.

Users of the button would be more likely to see devices and be able to proceed further in the resulting UI if there was no filter applied. For example, https://googlechrome.github.io/samples/web-bluetooth/device-info.html?allDevices=true finds other types of devices.

/cc @beaufortfrancois

Chromium now treats motion sensors as a permission. Would be a good idea to add a check for it.

I suggest adding a subdomain, embedded.permission.site which embeds permission.site in an iframe so that the behavior of permissions when requested from content embedded within another origin can be exercised.

Common guys, don't use ternary operator, replace it within if else to see logic errors more faster, next error is too childish -_-

Example:
https://github.com/chromium/permission.site/blob/master/index.js#L108

    "camera": function() {
      navigator.mediaDevices ?
        navigator.mediaDevices.getUserMedia(
          {video: true}).then(
            displayOutcome("camera", "success"),
            displayOutcome("camera", "error")
        ) :
        navigator.getUserMedia(
          {video: true},
          displayOutcome("camera", "success"),
          displayOutcome("camera", "error")
        );
    },

Uncaught TypeError: navigator.getUserMedia is not a function

And same in lot of other places

Several private web servers have no fully qualified domain name (FQDN) and therefore can have no certificate issued by a certificate authority that major web browsers recognize by default. This includes corporate intranet sites, as well as any appliance on a home network (such as a router, printer, or NAS device) that lacks a valid binding to a dynamic DNS service. Any HTTPS connection to such a server would raise an interstitial certificate warning.

I suggest adding a self-signed version to test whether a user agent's secure context determination differs between a site using a certificate issued by a public CA and a site relying on an exception added by the user.

Similar in spirit, but without permission prompts:

It might make sense to reference, just like badssl.com links to Safe Browsing examples at the bottom.

What about adding rules to the repo for Prettier code formatter and ESLint code analyzer?

This should significantly improve the contributor experience.

E.g. I've found that current code uses async / await syntax for Idle Detection API test (1, 2). This is the only place in the code where it is used.

The problem is that permission.site can be used for checking permissions in old browsers that don't support async / await syntax.

Adding disable-async-await ESLint rule could solve this problem.

We may also want to look into other common protocol handlers.

• Instead of moving cursor left and right, it should be kept simple. I reckon, that would be much more preferable

The http-https toggle is stuck in Android as seen here:

Not sure if a chrome or permission.site issue, but reporting it to keep track of it.

https://w3c.github.io/webappsec-credential-management/, especially the password mode, but possibly the federated mode.

@mikewest

Like if I hover it visually switches to the value NOT selected, if I click on it it visually switches to the value not selected and you have to unhover to see what is actually the selected value.

This is confusing. Please remove the hover effect.

Currently: "This text was copied from the all-permissions demo."

We should use something like "This text was copied from the permission.site clipboard example."

Intent to ship: https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/blink-dev/isXS3f3Tqo8/GPIQi_8oCAAJ
Spec: https://w3c.github.io/keyboard-lock/
Chrome design doc: https://docs.google.com/document/d/1z8_VDDj5qrixHxXYeYrotJna_lsBtpzfL7uFKj7F3sA/edit#

Simple use case:

navigator.keyboard.lock();

However, this does not appear to be available in Chrome Canary yet, even with the #system-keyboard-lock and #keyboard-lock-api flags enabled.

Written by James Thompson as part of an accessibility audit:
All platforms, tested on 6/25/20

All browsers

Not a regression

Whether or not a button has permission in the browser is indicated with a background color change for the applicable button. No textual equivalent is available in the code.

Light green for
Notifications

Light red for

Location

White for

Camera

Ideally, the color changes would rely on a hue difference between the red and green (for color-blind users), the color will have a high contrast difference from the background (for low-vision users), and either text that is moved of-screen using CSS (See below) or aria-attributes that describes the current state of the button.

Using off-screen text

NotificationsAllowed

…

LocationBlocked</span

…

Camera

Using ARIA attributes

<button aria-pressed=”true” aria-label=”Notifications allowed” id="notifications" class="success">Notifications

…

<button aria-pressed=”true” aria-label=”Location blocked” id="location" class="error">Location

…

Camera

The site should include the new window placement permission.

The Window Placement API shipped in Chrome 100: https://chromestatus.com/feature/5252960583942144

Even though permission.site gives you the option to connect using HTTP instead of HTTPS, I still feel that it is important for HTTPS to be implemented securely. Please drop support for weak cipher suites for TLS 1.2. See the link below for more details:
https://www.ssllabs.com/ssltest/analyze.html?d=permission.site

Especially since they are perfectly valid HTML5 tags. Can we call them Microphone and Camera, respectively? That's at least a lot less confusing to me.

I'd be happy to make a quick PR, if you're okay with that.

As far as I know, every browser that supports vibration does so without requiring permissions. But it's still a good example.

(Suggested by @marumari on Twitter: https://twitter.com/aprilmpls/status/717801697503002624)

fennec 68.3
https everywhere disabled
http toggle is on

[ 1 ] str:
tap pop up

observed behaviour :
opens a new tab
pop up button has green background on http://permission.site/

[ 2 ] str:
tap pop up (delayed 5 seconds)

observed behaviour :
it shows: firefox prevented this site from opening a pop-up window. would you like to show it.