Introduce canShareFiles #184

ewilligers · 2020-09-24T09:12:32Z

Note: I am not sure of the best way to word the definition.

This is an incomplete early draft seeking feedback.

For normative changes, the following tasks have been completed:

Modified Web platform tests (link to pull request)

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=)

Preview | Diff

Note: I am not sure of the best way to word the definition. This is an incomplete early draft seeking feedback.

marcoscaceres · 2020-09-25T04:38:50Z

index.html

@@ -103,15 +103,21 @@ <h3>
        </h3>
        <pre class="idl">
          partial interface Navigator {
+            [SecureContext] boolean canShareFiles(sequence&lt;USVString&gt; file_types);


Also, I don't see much advantage of allowing a sequence. As this is a synchronous check, it's better to only allow a single value. Then there is no ambiguity about which passed value is supported and which is not.

Maybe we should generalize the name too... to canShareType()

marcoscaceres · 2020-09-25T04:39:46Z

index.html

+            Each user agent should have an `allowlist` of permitted MIME types
+            and file extensions or file names. These may contain wildcards, for
+            example `*.txt` or `text/*`.


I think we should only support mime types, not file extensions.

I'd be against using wildcards in the manner suggested here. Let's just stick to well-formed/valid MIME Types per:
https://mimesniff.spec.whatwg.org

Additionally, we should have a list of allowed types that we all agree on, otherwise this API has the potential to becomes a fingerprinting vector.

I agree this needs more details, also for web developers who should have some assurances about the capabilities.

marcoscaceres · 2020-09-25T04:41:46Z

index.html

-            <li>If a file type is being blocked due to security considerations,
-            return <a>a promise rejected with</a> with a {{"NotAllowedError"}}
-            {{DOMException}}.
+            <li>If |data|'s {{ShareData/files}} member is present and


The support check should be split out into its own algorithm (see #177).

Note here, we need to do the same check as in #177 to make sure {files: []} gets rejected, but passing {text: "hi", files: []} is ok.

marcoscaceres · 2020-09-25T04:42:45Z

index.html

+            argument |file_types|, run the following steps:
+          </p>
+          <ol class="algorithm">
+            <li>For each |file_type| in |file_types|, if |file_type| does not


We probably want a permissions policy check here. If not allowed, throw NotAllowedError.

marcoscaceres · 2020-09-25T04:44:23Z

index.html

+            <li>If |data|'s {{ShareData/files}} member is present and
+            {{Navigator/canShareFiles()}} returns false when called with the
+            files' extensions and content types, return <a>a promise rejected
+            with</a> with a {{"NotAllowedError"}} {{DOMException}}.


I think this should be a {{TypeError}} instead, as the type is not allowed to be shared.

marcoscaceres · 2020-09-25T04:46:44Z

Thanks for putting this together @ericwilligers! This is a really good starting point.

marcoscaceres · 2020-09-25T05:17:53Z

index.html

+          </p>
+          <ol class="algorithm">
+            <li>For each |file_type| in |file_types|, if |file_type| does not
+            match any entry in the user agent's `allowlist`, return `false`.


For the mime types, they need to be parsed (which can return "failure", so throw a TypeError), and then the "essence" of each type can be checked against the allowlist.

marcoscaceres · 2020-09-25T05:21:56Z

index.html

@@ -103,15 +103,21 @@ <h3>
        </h3>
        <pre class="idl">
          partial interface Navigator {
+            [SecureContext] boolean canShareFiles(sequence&lt;USVString&gt; file_types);


We probably just want a regular DOMString.

Suggested change

[SecureContext] boolean canShareFiles(sequence<USVString> file_types);

[SecureContext] boolean canShareFiles(sequence<DOMString> file_types);

marcoscaceres · 2020-09-25T08:08:29Z

index.html

-            {{DOMException}}.
+            <li>If |data|'s {{ShareData/files}} member is present and
+            {{Navigator/canShareFiles()}} returns false when called with the
+            files' extensions and content types, return <a>a promise rejected


Note: This needs to be spec'ed as a for each |file:File| in files:, the check each file's content type separately.

marcoscaceres · 2020-09-28T03:39:00Z

Prototype implementation in Gecko using .canShareType():

I like it :)

mgiuca · 2020-10-27T22:55:27Z

Discussed at TPAC 2020. @NotWoods suggests that we do something like this but call it canShare and take a string parameter. Details to follow (see IRC).

NotWoods · 2020-10-27T23:16:03Z

We discussed canShareFiles and TAG concerns about adding many methods to the Navigator namespace. If future share categories arise in the future (i.e.: formatted text, html) we would want a canShareX for each which is not ideal.

A design we settled on is to change canShare to take two parameters, a category and optional extra data to refine the check as the second parameter.

partial interface Navigator {
  boolean canShare(ShareCategory category, optional any option);
};

enum ShareCategory {
  "files"
}

The type of the second parameter would change based on the first argument, similar to eventTarget.addEventListener. In the case of "files", it would correspond to the file_type parameter in this proposal.

// check if file sharing is supported
if (navigator.canShare("files") { ... }

// check if image sharing is supported
if (navigator.canShare("files", "image/*") { ... }

marcoscaceres · 2020-10-28T00:33:19Z

Re: optional any option);, I'd prefer we use a dictionary there. Then we can have the types: specifically defined there: sequence<DOMString> types;.

marcoscaceres · 2020-10-28T01:23:53Z

Actually, playing around a bit... just DOMString type; might be more useful than sequence types;.... otherwise, we get back into the situation where you need to test arrays with a single item to work out what is actually supported.

marcoscaceres · 2020-10-28T05:31:33Z

I've updated #177 to specify canShare(name, options)... for backwards compat, what we might be able to do is support both:

            [SecureContext]
            boolean canShare(optional ShareData data = {});

            [SecureContext]
            boolean canShare(DOMString name, optional CanShareQuery options = {});

Then we can just encourage developers to use the canShare(name, options) version when it's widely supported.

Let me know what you think...

NotWoods · 2020-10-28T06:17:47Z

Can we simply leave the previous version as a Chromium-only variant rather than including it in the spec?

marcoscaceres · 2020-10-28T07:15:16Z

Can we simply leave the previous version as a Chromium-only variant rather than including it in the spec?

We can, but that might end up having web compat issues (for Gecko)... I guess it somewhat depends on what the Webkit folks want to do also. Safari shipped with canShare() matching Chrome, I believe.

The above allows us to move away from the original version in somewhat sane way without breaking too much content (although the usage stats suggest that usage of .canShare() is low still).

cc @othermaciej

marcoscaceres · 2021-08-20T01:49:46Z

Closing, as we not implemented by anyone. Looks like we are sticking with .canShare().

Introduce canShareFiles

79a872c

Note: I am not sure of the best way to word the definition. This is an incomplete early draft seeking feedback.

ewilligers mentioned this pull request Sep 24, 2020

canShare() is not future compatible #108

Open

marcoscaceres requested changes Sep 25, 2020

View reviewed changes

marcoscaceres reviewed Sep 25, 2020

View reviewed changes

marcoscaceres mentioned this pull request Oct 5, 2020

chore: inform people that l2 is folded into main spec #134

Merged

marcoscaceres mentioned this pull request Oct 19, 2020

TPAC planning and specification status report #162

Closed

Base automatically changed from master to main February 3, 2021 03:22

marcoscaceres mentioned this pull request Aug 8, 2021

Plan to transition to CR #207

Closed

Merge branch 'main' into canShareFiles

568ceb7

marcoscaceres closed this Aug 20, 2021

saschanaz mentioned this pull request Nov 19, 2021

Better log messages for canShare #226

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce canShareFiles #184

Introduce canShareFiles #184

ewilligers commented Sep 24, 2020 •

edited by pr-preview bot

Loading

marcoscaceres Sep 25, 2020

marcoscaceres Sep 25, 2020

marcoscaceres Sep 25, 2020

annevk Sep 29, 2020

marcoscaceres Sep 25, 2020

marcoscaceres Sep 25, 2020

marcoscaceres Sep 25, 2020

marcoscaceres Sep 25, 2020

marcoscaceres commented Sep 25, 2020

marcoscaceres Sep 25, 2020

marcoscaceres Sep 25, 2020

marcoscaceres Sep 25, 2020

marcoscaceres commented Sep 28, 2020

mgiuca commented Oct 27, 2020

NotWoods commented Oct 27, 2020

marcoscaceres commented Oct 28, 2020

marcoscaceres commented Oct 28, 2020

marcoscaceres commented Oct 28, 2020

NotWoods commented Oct 28, 2020

marcoscaceres commented Oct 28, 2020

marcoscaceres commented Aug 20, 2021

	[SecureContext] boolean canShareFiles(sequence<USVString> file_types);
	[SecureContext] boolean canShareFiles(sequence<DOMString> file_types);

Introduce canShareFiles #184

Introduce canShareFiles #184

Conversation

ewilligers commented Sep 24, 2020 • edited by pr-preview bot Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marcoscaceres commented Sep 25, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marcoscaceres commented Sep 28, 2020

mgiuca commented Oct 27, 2020

NotWoods commented Oct 27, 2020

marcoscaceres commented Oct 28, 2020

marcoscaceres commented Oct 28, 2020

marcoscaceres commented Oct 28, 2020

NotWoods commented Oct 28, 2020

marcoscaceres commented Oct 28, 2020

marcoscaceres commented Aug 20, 2021

ewilligers commented Sep 24, 2020 •

edited by pr-preview bot

Loading