I'm ok with this just to get us over the line (so big thanks @xfq for putting it together!). However, it will be a quite a chore to maintain in the future. After we publish, I can add the rs-changelog and filter out all the editorial/chore stuff.

          <li>Make {{ScreenWakeLock}} constructable.</li>

Isn't there some mechanism that can restrict access to APIs from third-party scripts?

No, unfortunately.

Use of unscrutinized third party script falls into a different class of threats, like disgruntled developer risk, that affect all powerful APIs and are not specific to the web platform.

Right, I think this is where we get into the fundamental philosophical differences in our communities: Mozilla folks are hesitant to add anything to the platform that allow a "disgruntled developer" level attack. Why we have no BlueTooth, MIDI, etc. etc... so, in a sense they are specific to the web platform in as far as Mozilla (and Apple) have not allowed shipped these kinds of APIs for this reason.

That's not to say it's a show stopper - but it gives us a point at which we can ask, "what's this thing trying to do?"

So that https://w3c.github.io/manifest-app-info works

@siusin if everything looks good to you, please feel free too merge :) Everything should work from there 🤞

@siusin, can you confirm the IPR bot is set up properly? I don't see it in the branch protection list in settings?

At section 2, after Example-1 "As the application manifest is JSON, this the members of this specification are of the types object, array, and string as defined in The JSON Data Interchange Format."

I am far from being good at English, but wouldn't there be one extra "this"?

You are right. Typo :) Will fix.

So, turns out we are actually going to need "gh-pages" branch, because the W3C auto-pub service needs to access the ECHINDA at the root of this repo over HTTPS... so, we might just treat "gh-pages" as our default branch.

Github fixed this.

Good news! looks like Github now allows main to serve the main branch... just set it up and works! So, no need to wait.

@xfq, how we looking for for just getting screen-wake-lock on TR again?

@tomayac is interested in this for the GeolocationSensor.

https://docs.microsoft.com/en-us/windows/uwp/launch-resume/run-minimized-with-extended-execution

Windows also has special API for geolocation as there can

• Only be one lock at a given time
• Regular CPU "system" lock has a time limit when the device is running on battery

We could also spec that the lock would be rejected if the same global scope doesn't have an active GeolocationSensor - I think that makes sense.

This might require some spec changes in the GeolocationSensor spec as well.

Up for speccing this @tomayac ?

Closing, as this is now out of scope for this spec. @tomayac, should we spin this issue up somewhere else? I wonder if we should just spin this up directly in http://github.com/w3c/geolocation-api/ ?

Closes #264

<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):

Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.

-->

<a href="https://pr-preview.s3.amazonaws.com/w3c/screen-wake-lock/pull/266.html" title="Last updated on Aug 4, 2020, 2:12 AM UTC (4e7231f)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/screen-wake-lock/266/0cef480...4e7231f.html" title="Last updated on Aug 4, 2020, 2:12 AM UTC (4e7231f)">Diff</a>

https://w3c.github.io/screen-wake-lock/#policy-control

The spec has been renamed: w3c/webappsec-permissions-policy#379

CI issue is #262

Bumps elliptic from 6.5.2 to 6.5.3. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/indutny/elliptic/commit/8647803dc3d90506aa03021737f7b061ba959ae1"><code>8647803</code></a> 6.5.3</li> <li><a href="https://github.com/indutny/elliptic/commit/856fe4d99fe7b6200556e6400b3bf585b1721bec"><code>856fe4d</code></a> signature: prevent malleability and overflows</li> <li>See full diff in <a href="https://github.com/indutny/elliptic/compare/v6.5.2...v6.5.3">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Those are good suggestions @tomayac. I'm still hopeful we can see actual cases where something like "prefers-reduced-energy" would help... like what would added/removed/changed. We talked about video above, so we would need to figure out if it could help there.... like, if <video>'s element could be used with <source media="(prefers-reduced-energy: yep)" src="video">.

Closes #165

For normative changes, the following tasks have been completed:

• [X] Modified Web platform tests - happens automatically.

Implementation commitment:

• [ ] WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
• [X] Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=1112600)
• [ ] Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=1635700)

When passing dictionaries as arguments, FrozenArray doesn't make much sense, as:

1. dictionaries are passed by value
2. it implies that dictionary.files = Array.freeze([...files]);, which is really what is mean there.

Related discussion https://github.com/heycam/webidl/issues/900

See: https://github.com/w3c/respec-w3c-auto-publish

What's nice is that we get the validation errors directly in Github, without needing to go to TravisCI.

Thanks for the additional check @rakuco. Hopefully all good to go!

<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):

Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.

-->

<a href="https://pr-preview.s3.amazonaws.com/w3c/payment-request/pull/921.html" title="Last updated on Jul 30, 2020, 7:38 AM UTC (ecc70aa)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/payment-request/921/28dd285...ecc70aa.html" title="Last updated on Jul 30, 2020, 7:38 AM UTC (ecc70aa)">Diff</a>

Closes #165

For normative changes, the following tasks have been completed:

• [X] Modified Web platform tests - happens automatically.

Implementation commitment:

• [ ] WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
• [ ] Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
• [ ] Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)

If the PWA knows that the native app is installed, it can just switch into that app, but if not, it can ask the user to install it.

This sounds a lot like "Smart App Banners" from Apple: https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html

Not saying we should use that, as it's very iOS specific - but just sounds quite similar.

Just so it's a bit more clear, is the use case then for GIRA to only work on an installed web application? That is, does a user first need to install the PWA, then when they open the PWA they are told to use/install the native app instead?

Any reason events were chosen over a stream?

Nit: just assume top-level await for examples...

try {
  const udpSocket = await navigator.openUDPSocket(options);
  doStuffWith(udpSocket);
} catch (err) {
  // handle error
}

Agree... this is the challenging bit. How do you explain what is going on here to a user and what the implications of getting pwned are? Or, alternatively, is this made scary enough that a user doesn't start filling out random things.

The concern is that if you can send the right bits of information you can attack the hardware, rewrite firmware, and if you are motivated enough, destroy the hardware.

I'm thinking of this small attack: https://www.cybersecurity-insiders.com/cyber-attack-launched-on-150000-printers-working-worldwide/

But is a web page can trick a user to ssh into some server on a company network, that's a pretty scary prospect.

This still allows for passive scans. Maybe this would be in control of the connection UI... the user could then hit a "retry" button, rather than the web page doing it.

This is good, but these can be fairly weak, as scroll events counts as transient activation I believe.

There is still a threat where a third-party is injected via a first-party context, like via any <script> tag that loads a script from a CDN for instance. Then the third-party script could silently gain access to a socket once the user grants permission.

The important point is that such algorithms do exist and can impose real risks to the users in the near future.

You raise a good point and I think we are all concerned about that kind of physical tracking. However, I think we will need to deal with things like Naveio more specifically when we get around to doing geofencing.

Bumps elliptic from 6.5.2 to 6.5.3. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/indutny/elliptic/commit/8647803dc3d90506aa03021737f7b061ba959ae1"><code>8647803</code></a> 6.5.3</li> <li><a href="https://github.com/indutny/elliptic/commit/856fe4d99fe7b6200556e6400b3bf585b1721bec"><code>856fe4d</code></a> signature: prevent malleability and overflows</li> <li>See full diff in <a href="https://github.com/indutny/elliptic/compare/v6.5.2...v6.5.3">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Oh, that's great to see @reillyeon. Thank you! Looks like Blink folks are coming to the same conclusions. If the mitigations get shipped, I'm still betting on usage going down to 0.00n% usage (and this becoming non-harmful). At the same time, I'm hopeful we can see some legit breakage, so to allow us to deal with those legitimate cases better (e.g., if YouTube is actually using it for some codec selection, then that's probably better done in the <video> element or whatever).

At the same time, it seems Dev Tools is in a way better position to provide accurate battery consumption information on a per tab basis (see "about:performance" in Firefox), which provides a real time view of energy impact of a tab.

Using a well known URL creates a large migration problem: all currently installed PWAs that don't already conform to the well-known URL would be broken, and for many sites, fixing that problem would require a site re-architecture that might not be that likely to happen. How would that problem be practically addressed?

We'd have to start warning and ask developers to migrate over the next N years. Or a browser vendor would need to take the compat hit. Alternatively, we see what percentage would be impacted and make some determination based on that.

Additionally, removing fragments, queries, and arbitrary paths removes a significant amount of positive utility (the classic tradeoff of the design of URLs). How could you replicate that utility?

Those we would need to look at on a case-by-case basis and see if we can provide the same utility in some other way.

Great point.

A proposal made internally was just to use a well-known URL. That would basically solve most things: it strips fragments, queries, and arbitrary paths where identifying information could be stored.

That could then be coupled with a hybrid solution: when a user installs an app, partition it into its own storage compartment. Then, for sites that depend on authentication, require the user to log in again using password autofill, webauthn, WebOTP, Credential Management API, or whatever standard authentication mechanism the site depends on. It's a small inconvenience for a big privacy assurance.

I agree with @domenic. Incorrect layering to HTML will more than likely lead to implementation issues. Having said that, republishing a CR seems appropriate as we address these issues - but we should make a small push to address them before we start talking about any L3 stuff.

Really appreciate the update and looking forward to hearing the outcome of the investigation (that sounds way cooler than it should).

It relates directly to the discussion we are having here: It's hard to make a case that the spec should be killed when even well meaning implementers, like Brave, are unwilling to follow the spec with regard to SecureContext and Permissions Policy even when returning bogus values.

See what I mean?

I'm currently sitting on this on the Gecko side (have a patch ready... just stuck in review), but I intend to ship it soon. I'd still encourage us to have this in the spec. Hopeful for support from WebKit. Cc @hober.

But no, Brave has no intention to do any work at all implementing anything relating to the battery API. We don't support it.

Really, then what's this?

Please understand why I'm getting really pissed off here: Brave is part of the Chromium project and you ship the API (I guess you didn't know that, surprise! 🎉 ), but you seem unwilling to go an actually fix stuff in the Chromium project you depend on.

Anyway, seems like the only solution here is remove SecureContext and Permissions Policy integration from the spec until someone has the actual guts step up and actually implement/ship secure contexts and Permission Policy.

In other words, "there aren't enough implementors for the WG to take it on" is a silly complaint,

It's not. It's completely valid. A single implementer spec is not a standard.

but "based on previous experience, we don't think this should be part of the web platform" seems like a totally valid (procedurally and on the substance) reason to remove items from the group's charter / scope of work.

I disagree. And this one provable. @pes10k, stop avoiding my direct question: is Brave going to do the work to actually enable SecureContext and Permission Policy for Battery or not? It's a yes or no question. Intel and Google are not going to do it, so will you or Brave step up and actually do the work?

Additionally, if Intel and Google are not going to do the actual work. They we should remove SecureContext and Permission Policy from the spec. Having fictitious privacy claims in the spec discredits the work on this working group and w3c.

I agree this is something to consider before implementing a full brightness mode. My understanding of the use case is that app developers don't expect users to know how to adjust brightness when they are displaying something like a barcode. To support this case it seems sufficient for the site to provide a hint that full brightness is suggested and the browser can provide the UI to enable it if the user desires.

Agree. It's actually more than "developers don't expect users to know how to adjust brightness".

I've myself been in this situation: you are in line, like getting on a plane (lol, remember those!), or going to a concert (oh god, I'm so sad I miss my old life!), and you open up the app with the ticket.

When you show the ticket, there is social pressure to not hold up the line... so you want the app to put the screen to maximum brightness for maximum contrast, so then you don't need to hand your phone over to the person checking the tickets - and that's how you avoid getting or giving Covid! :)

To summarize @npdoty comments in https://lists.w3.org/Archives/Public/public-privacy/2015JanMar/0117.html there are concerns about start_url containing special ids or simply something that hints that the user is coming from a homescreen application. This is fingerprinting/privacy sensitive information that the user might not be aware of.

I think the issue of people doing start_url: 'index.html?from_homescreen' is something we might want to mention in the spec but I don't think we should encourage browsers to prevent this because it is clearly something websites want for various reasons (mostly statistics).

However, I am concerned about having start_url: 'index.html?$GUUID' because it is a way to track the user without them being aware of it. I'm not sure what the spec should say or the browsers could do. Maybe we could recommend showing the start_url to the user and allow them to edit it?

Agree. I'm closing this as we acknowledge this problem, but it's not solvable because it's inherent to URLs. We let implementers know this is a problem and provide possibilities to mitigate through the UI. https://www.w3.org/TR/appmanifest/#privacy-consideration-start_url-tracking

@siusin would you mind setting me up with Admin on this repo? I can take care of it if you'd like.

I think the difference between "default" and "auto" as proposed is significant, as dimming the screen reduces the visibility of the content being displayed and the intent of the API is to allow the content to remain visible.

Agree. I guess the question I have is if it's feasible to implement "default" (no dim) across all OSs? My assumption is that the browser can only request from the OS to keep the screen on (but OS manages what happens), or keep screen on with "full" temporarily (but the OS still manages everything). Is that understanding correct based on what @kenchris documented above? https://github.com/w3c/screen-wake-lock/issues/129#issuecomment-479882316

We could provide some guidance, probably for both exception-based and promise-based APIs.

That would be great. Personally, NotAllowedError in both cases would be fine:

[=throw=] a {{"NotAllowedError"}}` {{DOMException}}.

And:

Return [=a promise rejected with=] a {{"NotAllowedError"}} {{DOMException}}.

Nit: Same change globally. Avoid using data-link-for= as we now support the new syntax. Quick overview of ReSpec shorthands (and docs): https://respec.org/docs/#Shorthands-Guide

           property. In this case, the user agent will first check if it

          the manifest by using the {{WebAppManifest/display}}

It sounds like what you are seeing is based on Chrome's implementation, which happens to be holding the lock at a particularly brightness without allowing it do dim - so I'm hoping to hear from the Chrome folks, as I'm not sure who implemented the feature.

Personally, if I was to do this in Firefox, I would only do "full" and "auto" (or default). However, I'm certainly open to this third state:

To reiterate what we have so far:

• default: use the current brightness, and (if possible) don't allow the screen to dim - (OSs power settings probably override this).
• auto: use the current brightness, but let the OS do whatever it wants with regards to dimming.
• full: request full brightness, and let the OS do whatever it wants.

When I say "use the current brightness", the user is still obviously in control and can adjust it. Similarly, in all cases, the OS can do whatever it wants/needs to do based on available battery: the browser shouldn't override the OS, IMO.

As I said, I'm remain skeptical that "default" and "auto" are different (it sounds like an implementation detail of Chrome) - but I'm open to listen to reason as I've not implemented this Firefox yet.

Before we archive it, we need to gut the index.html. We should probably turn off gh-pages for this also.

Yes, looks like we should. This is in conflict with HTML itself.

Please leave your comments, etc. below.

CFC has passed. The chairs and team will work on publishing getting this published on TR.

Ok cool, CFC is passed. @siusin let me know if you need anything spec wise.

@himorin, @xfq let me know if https://github.com/w3c/geolocation-api/pull/51/ is a suitable fix.