Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PR Request for Web Share API #476

Closed
siusin opened this issue Nov 24, 2022 · 7 comments
Closed

PR Request for Web Share API #476

siusin opened this issue Nov 24, 2022 · 7 comments
Assignees
Labels
Awaiting Publication Approved by the Director, waiting on publication Entering PR Proposed Recommendation wg:webapps

Comments

@siusin
Copy link

siusin commented Nov 24, 2022

Document title, URLs, estimated publication date

Web Share API
https://www.w3.org/TR/web-share/
W3C Proposed Recommendation 06 December 2022

Abstract

This specification defines an API for sharing text, links and other content to an arbitrary destination of the user's choice.

The available share targets are not specified here; they are provided by the user agent. They could, for example, be apps, websites or contacts.

Status

This document was published by the Web Applications Working Group as a Proposed Recommendation using the Recommendation track.

Publication as a Proposed Recommendation does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. Future updates to this specification may incorporate new features.

The W3C Membership and other interested parties are invited to review the document and send comments through 06 December 2022. Advisory Committee Representatives should consult their WBS questionnaires. Note that substantive technical comments were expected during the Candidate Recommendation review period that ended 08 November 2022 (?).

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 2 November 2021 W3C Process Document.

Will new features be allowed to be incorporated in the Recommendation?

Yes.

Link to group's decision to request transition

w3c/web-share#253

Changes

No.

Requirements satisfied

No.

Dependencies met (or not)

Web Share API has a few normative references on Permissions Policy. This was identified as one "feature at risk" (#169) during the CR, but it's now resolved and interoperable across all user agents.

Wide Review

  • APA
  • TAG
  • I18n (1 issue reported, but closed because of nothing actionable)
  • Privacy (2 issues reported, already addressed)
  • Security (2 issues reported, already addressed)

Issues addressed

All the outstanding issues for Web Share API are now resolved, the only open issue in the repo is just for advisory.

Formal Objections

None.

Implementation

https://wpt.fyi/web-share
https://www.w3.org/TR/web-share/#implementation-status
The spec is implemented in an interoperable manner across all major browser engines across a range of platforms and has wide usage across the Web.

The test results indicate the implementation of the Permissions Policy integration is not perfect at the moment. The group believes this will be improved with the ongoing effort to complete the Permissions Policy spec.

Patent disclosures

https://www.w3.org/groups/wg/webapps/ipr

@siusin siusin added Entering PR Proposed Recommendation [DO NOT USE] Awaiting Director Deprecated. Use Awaiting Team Verification. labels Nov 24, 2022
@plehegar
Copy link
Member

plehegar commented Dec 5, 2022

Section 4 indicates that, by default, the API is not allowed to be used in cross-origin contexts. It says so in the sentence "Its default allowlist is 'self'.". Given the incomplete state/lack of implementations for Permissions Policy, section 4 should indicate explicitly the intent of the Web Share API regarding cross-origin, independently of Permissions Policy. It can do so by adding a third sentence to the first paragraph of section 4, either by copying the definition of self or paraphrasing the intent. In addition, an editorial note will need to be added to that section to alert developers on the current lack of implementation experience from Permission Policy. That note should also be included in the call for AC review.

The transition request did not make it clear if the Recommendation will be allowed to add new features without cycling back. Don't forget to indicate this in the status of the document of the Proposed Recommendation if that's the intent.

By the way, the reference to 'self' in section 4 uses a broken fragment that will need to be fixed.

Assuming the changes mentioned above are done, this transition is approved.

@plehegar plehegar assigned siusin and unassigned ylafon and plehegar Dec 5, 2022
@plehegar plehegar added Awaiting Publication Approved by the Director, waiting on publication and removed [DO NOT USE] Awaiting Director Deprecated. Use Awaiting Team Verification. labels Dec 5, 2022
@marcoscaceres
Copy link
Member

marcoscaceres commented Dec 12, 2022

Given the incomplete state/lack of implementations for Permissions Policy, section 4 should indicate explicitly the intent of the Web Share API regarding cross-origin, independently of Permissions Policy.

@plehegar, you are correct that that Permissions Policy, as it now stands, is not fully interoperable - particularly with respect to the HTTP header. As background for others subscribed to this thread, this because the HTTP header was renamed and implementations haven't been updated to match.

However, the allow="web-share" HTML attribute is interoperable across both Chromium, WebKit, and possibly even Gecko.

It can do so by adding a third sentence to the first paragraph of section 4, either by copying the definition of self or paraphrasing the intent.

The normative behavior is governed by the "allowed to use" check, which occurs as part of share() and canShare(). I can add some clarifying text to that effect, but I'd be reluctant to duplicate what is in Permissions Policy already.

However, I've added the following to make the intent clear:

Its [=default allowlist=] is [=default allowlist/'self'=], which means third-party contexts are not [=allowed to use=] the API by default.

@plehegar also requested...

In addition, an editorial note will need to be added to that section to alert developers on the current lack of implementation experience from Permission Policy. That note should also be included in the call for AC review.

I've added the following note:

Although user agents are unified in preventing the Web Share API from being used in
third-party context, at the time of publication there are
interoperability with relying on the [[[Permissions-Policy]]] to
enable the API in third-party contexts. In particular, although
the[^iframe/allow^] attribute is widely supported, the updated syntax
for the [^iframe/allow^] attribute is not. Similarly, the
Permissions-Policy: HTTP header is not yet widely supported.
Developers are advised to check the implementation status of the
[[[Permissions-Policy]]] specification before relying on it to enable
the Web Share API in third-party contexts.

And finally...

By the way, the reference to 'self' in section 4 uses a broken fragment that will need to be fixed.

fixed.

@marcoscaceres
Copy link
Member

@siusin I've sent w3c/web-share#256 ... if it looks ok, please merge and we can use it as the basis for publication.

@marcoscaceres
Copy link
Member

Oops, forgot this:

The transition request did not make it clear if the Recommendation will be allowed to add new features without cycling back. Don't forget to indicate this in the status of the document of the Proposed Recommendation if that's the intent.

The spec is marked as class="updateable-rec", but the text only shows up when viewed with REC status:
https://w3c.github.io/web-share/?specStatus=REC#sotd

"Future updates to this Recommendation may incorporate new features."

ReSpec might need updating if we want to show that automatically in PR (or even CR).

I've added it manually for now.

@siusin
Copy link
Author

siusin commented Dec 12, 2022

@marcoscaceres ++

I believe your PR has addressed all the issues mentioned. @plehegar do you agree?

Oops, forgot this:

The transition request did not make it clear if the Recommendation will be allowed to add new features without cycling back. Don't forget to indicate this in the status of the document of the Proposed Recommendation if that's the intent.

The spec is marked as class="updateable-rec", but the text only shows up when viewed with REC status: https://w3c.github.io/web-share/?specStatus=REC#sotd

"Future updates to this Recommendation may incorporate new features."

ReSpec might need updating if we want to show that automatically in PR (or even CR).

I've added it manually for now.

I guess PLH misread this sentence. Actually, the auto-text of ReSpec is good enough.

@plehegar
Copy link
Member

@marcoscaceres @siusin , this all sounds good to me

@siusin
Copy link
Author

siusin commented Dec 29, 2022

Spec was published on 2022-12-15:
https://www.w3.org/TR/2022/PR-web-share-20221215/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting Publication Approved by the Director, waiting on publication Entering PR Proposed Recommendation wg:webapps
Projects
None yet
Development

No branches or pull requests

5 participants