Intent to implement: directory picking and directory drag and drop

[Jonathan Watt]

MS has a proposal for a minimal set of functionality to support directory
picking via <input> and to support directory drag and drop.

https://microsoftedge.github.io/directory-upload/proposal.html

This spec is a work in progress but we now have an implementation for platforms
that have a native directory picker (desktop) landed and turned on in Nightly
only (the boolean pref is dom.input.dirpicker). The bug for keeping pace with
spec changes and eventually shipping is:

https://bugzilla.mozilla.org/show_bug.cgi?id=1188880

Currently we're waiting for MS to officially take their proposal to one of the
W3C groups, probably either one of:

https://lists.w3.org/Archives/Public/public-webapps/
https://lists.w3.org/Archives/Public/public-wicg/

Once that happens my expectation is that the proposal will change as feedback
comes in. Once things look stable enough to ship I'll send out an intent to ship.

For those who are interested I have a test page that demonstrates the API at:

https://jwatt.org/tmp/directory.html

If you file any bugs please CC me and mark them as blocking bug 1188880.

[Anne van Kesteren]

On Wed, Jul 29, 2015 at 5:37 PM, Jonathan Watt <jw...@jwatt.org> wrote:
> MS has a proposal for a minimal set of functionality to support directory
> picking via <input> and to support directory drag and drop.
>
> https://microsoftedge.github.io/directory-upload/proposal.html

It doesn't seem to define how it affects the FormData API.

Also, it would be clearer if the language was written in the same
style as every other HTML form feature is defined in... I guess that's
for later.


--
https://annevankesteren.nl/

[Jonathan Watt]

Targeting Firefox 44 we intend to ship[1] Directory Upload[2], which provides
directory picking (via <input type=file directory>) and directory drag-and-drop.
Our implementation has been developed behind the `dom.input.dirpicker`
preference, enabled only in Nightly builds so far.

In addition to previously announcing our intent to implement[3], Directory
Upload has also been publicized to public-wicg[4], public-webapps[5], and
planet.mozilla.org via my blog[6]. There has been very little formal feedback
other than a suggestion to also support Directory integration with FormData
(that would be a good and obvious enhancement) and some questioning of whether
I/O blocking is really an issue (it can be). Informal feedback has been along
the lines of "seems good to me". Further feedback continues to be welcome of course.

Our informal understanding is that MS will not ship an implementation in Edge
until at least the new year.

-Jonathan

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1188880
2. https://wicg.github.io/directory-upload/proposal.html
3. https://groups.google.com/forum/#!topic/mozilla.dev.platform/Q3BLd4Cwj6Q
4. https://lists.w3.org/Archives/Public/public-wicg/2015Sep/0000.html
5. https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0347.html
6. https://jwatt.org/blog/2015/09/14/directory-picking-and-drag-and-drop

[Eric Rescorla]

This seems like a fantastically dangerous feature and ripe for abuse.

Are we doing anything in the UI to make very clear to users what's going on?
Is there going to be a way to disable it?

-Ekr

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Jonas Sicking]

Note that this, similarly to clipboard integration, is already exposed
to the web through flash. So the main goal of this feature is to
enable developers to migrate off of flash and instead use Gecko.

That said, if there are ways we can improve the UI here to further
explain to users what is going on, then that sounds good to me.

/ Jonas

On Mon, Sep 21, 2015 at 8:49 AM, Eric Rescorla <e...@rtfm.com> wrote:
> This seems like a fantastically dangerous feature and ripe for abuse.
>
> Are we doing anything in the UI to make very clear to users what's going on?
> Is there going to be a way to disable it?
>
> -Ekr
>
>
> On Mon, Sep 21, 2015 at 8:37 AM, Jonathan Watt <jw...@jwatt.org> wrote:
>

[Eric Shepherd]

Jonas Sicking wrote:
> Note that this, similarly to clipboard integration, is already exposed
> to the web through flash. So the main goal of this feature is to
> enable developers to migrate off of flash and instead use Gecko.
>
> That said, if there are ways we can improve the UI here to further
> explain to users what is going on, then that sounds good to me.

My concern with shipping this would be that it seems very far removed
from being a proper proposed spec at this point. Seems to just be an
unofficial draft. Shouldn't it spend more time preffed off to give
developers more time to offer feedback? It's only been a few weeks since
this was first brought up, and we've not exactly made it broadly known
that it could use some trying-out.

I like the idea in general though; having no way to do this has been a
long-standing problem when trying to build file server managers, sharing
services, and the like.

--

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/eshe...@mozilla.com>

[Eric Rescorla]

On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking <jo...@sicking.cc> wrote:

> Note that this, similarly to clipboard integration, is already exposed
> to the web through flash. So the main goal of this feature is to
> enable developers to migrate off of flash and instead use Gecko.
>

I'm not sure that this is the right standard. The reason that we are
removing
Flash is that people are sad about some things in Flash. So I think we need
to replicate enough of Flash to get people to stop using it, but that
doesn't
mean we need to have it be bug-for-bug compatible with every feature Flash
has, including features we think are bad.

-Ekr

> That said, if there are ways we can improve the UI here to further
> explain to users what is going on, then that sounds good to me.
>

> / Jonas
>
>
>
> On Mon, Sep 21, 2015 at 8:49 AM, Eric Rescorla <e...@rtfm.com> wrote:
> > This seems like a fantastically dangerous feature and ripe for abuse.
> >
> > Are we doing anything in the UI to make very clear to users what's going
> on?
> > Is there going to be a way to disable it?
> >
> > -Ekr
> >
> >
> > On Mon, Sep 21, 2015 at 8:37 AM, Jonathan Watt <jw...@jwatt.org> wrote:
> >

[Mats Palmgren]

On 09/21/2015 05:37 PM, Jonathan Watt wrote:
> Targeting Firefox 44 we intend to ship[1] Directory Upload[2],

It seems there are many security, privacy and UI issues discussed in
bug 907707 that are still unresolved. I see that it's blocking the
ship-it tracking bug, but it seems premature to discuss shipping this
feature before we have consensus on those issues.

https://bugzilla.mozilla.org/show_bug.cgi?id=907707

/Mats

[Jonathan Watt]

That's a good question. There's been a bunch of discussion about this in
https://bugzilla.mozilla.org/show_bug.cgi?id=907707

[Jonathan Watt]

That's a good question. There's been a bunch of discussion about this in
https://bugzilla.mozilla.org/show_bug.cgi?id=907707

On 21/09/2015 16:49, Eric Rescorla wrote:

[Jonathan Watt]

On 21/09/2015 19:31, Eric Shepherd wrote:
> Jonas Sicking wrote:
>> Note that this, similarly to clipboard integration, is already exposed
>> to the web through flash. So the main goal of this feature is to
>> enable developers to migrate off of flash and instead use Gecko.
>>
>> That said, if there are ways we can improve the UI here to further
>> explain to users what is going on, then that sounds good to me.
> My concern with shipping this would be that it seems very far removed
> from being a proper proposed spec at this point. Seems to just be an
> unofficial draft. Shouldn't it spend more time preffed off to give
> developers more time to offer feedback? It's only been a few weeks since
> this was first brought up, and we've not exactly made it broadly known
> that it could use some trying-out.

Fair points. Note than 44 doesn't ride the trains for another 6 weeks.

[Jonathan Watt]

On 21/09/2015 19:31, Eric Shepherd wrote:

> Jonas Sicking wrote:
>> Note that this, similarly to clipboard integration, is already exposed
>> to the web through flash. So the main goal of this feature is to
>> enable developers to migrate off of flash and instead use Gecko.
>>
>> That said, if there are ways we can improve the UI here to further
>> explain to users what is going on, then that sounds good to me.
> My concern with shipping this would be that it seems very far removed
> from being a proper proposed spec at this point. Seems to just be an
> unofficial draft. Shouldn't it spend more time preffed off to give
> developers more time to offer feedback? It's only been a few weeks since
> this was first brought up, and we've not exactly made it broadly known
> that it could use some trying-out.

[Jonathan Watt]

On 21/09/2015 19:57, Eric Rescorla wrote:
> On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>
>> Note that this, similarly to clipboard integration, is already exposed
>> to the web through flash. So the main goal of this feature is to
>> enable developers to migrate off of flash and instead use Gecko.
>>
>
> I'm not sure that this is the right standard. The reason that we are
> removing
> Flash is that people are sad about some things in Flash. So I think we need
> to replicate enough of Flash to get people to stop using it, but that
> doesn't
> mean we need to have it be bug-for-bug compatible with every feature Flash
> has, including features we think are bad.

I don't think directory picking is bad - there are many sites with legitimate
uses. I think it's right that we need to think about the security implications
though, and members of the security team have been looped in to consider these
issues.

[Jonathan Watt]

On 21/09/2015 19:57, Eric Rescorla wrote:

> On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>
>> Note that this, similarly to clipboard integration, is already exposed
>> to the web through flash. So the main goal of this feature is to
>> enable developers to migrate off of flash and instead use Gecko.
>>
>
> I'm not sure that this is the right standard. The reason that we are
> removing
> Flash is that people are sad about some things in Flash. So I think we need
> to replicate enough of Flash to get people to stop using it, but that
> doesn't
> mean we need to have it be bug-for-bug compatible with every feature Flash
> has, including features we think are bad.

[Richard Barnes]

Who have you been talking to on the security team? I haven't heard any
discussion of this in our security engineering meetings. And I share EKR's
concerns here.

Thanks,
--Richard

[Eric Rescorla]

On Mon, Sep 21, 2015 at 3:58 PM, Jonathan Watt <jw...@jwatt.org> wrote:

> On 21/09/2015 19:57, Eric Rescorla wrote:
>
>> On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>>
>> Note that this, similarly to clipboard integration, is already exposed
>>> to the web through flash. So the main goal of this feature is to
>>> enable developers to migrate off of flash and instead use Gecko.
>>>
>>>
>> I'm not sure that this is the right standard. The reason that we are
>> removing
>> Flash is that people are sad about some things in Flash. So I think we
>> need
>> to replicate enough of Flash to get people to stop using it, but that
>> doesn't
>> mean we need to have it be bug-for-bug compatible with every feature Flash
>> has, including features we think are bad.
>>
>
> I don't think directory picking is bad - there are many sites with
> legitimate uses

There are lots of features with legitimate uses which are also dangerous.
For instance, it would be convenient to be able to get access to your camera
and microphone without a prompt.

I think there are some fairly obvious issues here, including:

- There are obvious sensitive files you shouldn't upload under
basically any conditions.
- It's hard for the client to know what the implications of any directory
upload are
because they may not know what's in a given directory.

> . I think it's right that we need to think about the security implications
> though, and members of the security team have been looped in to consider
> these issues.
>

This seems like a procedural response, not a substantive one.

Where is the security analysis for this feature?

-Ekr

[Eric Shepherd]

Eric Rescorla wrote:
> I think there are some fairly obvious issues here, including:
>
> - There are obvious sensitive files you shouldn't upload under
> basically any conditions.
> - It's hard for the client to know what the implications of any directory
> upload are
> because they may not know what's in a given directory.

I'm not a big fan of "the user is stupid and we have to protect him" as
an argument. :)

There are a lot of genuinely valid use cases for this feature; yes,
security concerns should definitely be considered, but it's important to
be clear that if you want to address security concerns, or kill off the
feature entirely. I hope it's the former, because the number of times
this exact thing has come up for me is not easy to dig up, since it's
been a lot of times, especially when working on web deployments or
staging of assets for media services.

[Eric Rescorla]

On Mon, Sep 21, 2015 at 8:48 PM, Eric Shepherd <eshe...@mozilla.com>
wrote:

> Eric Rescorla wrote:
>
> I think there are some fairly obvious issues here, including:
>
> - There are obvious sensitive files you shouldn't upload under
> basically any conditions.
> - It's hard for the client to know what the implications of any directory
> upload are
> because they may not know what's in a given directory.
>
> I'm not a big fan of "the user is stupid and we have to protect him" as an
> argument. :)
>

Conveniently, that's not what I said. There's lots of stuff that's in
people's directories
that they're not readily aware of, including dotfiles, missaves, etc.

> There are a lot of genuinely valid use cases for this feature; yes,
> security concerns should definitely be considered, but it's important to be
> clear that if you want to address security concerns, or kill off the
> feature entirely.
>

What's needed here is a real security assessment. That might lead to some
sort of security mediations, and might also lead to the conclusion that it
needs
to be killed. But the first thing to do is an assessment. So far I haven't
seen
one.

-Ekr

[Jet Villegas]

It looks like most of the Security discussion is happening in this bug now:
https://bugzilla.mozilla.org/show_bug.cgi?id=907707

--Jet

[Jonas Sicking]

On Sep 21, 2015 11:57, "Eric Rescorla" <e...@rtfm.com> wrote:
>
> On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>>
>> Note that this, similarly to clipboard integration, is already exposed
>> to the web through flash. So the main goal of this feature is to
>> enable developers to migrate off of flash and instead use Gecko.
>
>
> I'm not sure that this is the right standard. The reason that we are
removing
> Flash is that people are sad about some things in Flash. So I think we
need
> to replicate enough of Flash to get people to stop using it, but that
doesn't
> mean we need to have it be bug-for-bug compatible with every feature Flash
> has, including features we think are bad.

Sure, I agree that we shouldn't copy all of flash. But this is a feature
requested both by developers and users (again, like clipboard integration)
so I do think that this is a feature that we should copy.

/ Jonas

[Jonas Sicking]

On Sep 21, 2015 11:57, "Eric Rescorla" <e...@rtfm.com> wrote:
>
> On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>>
>> Note that this, similarly to clipboard integration, is already exposed
>> to the web through flash. So the main goal of this feature is to
>> enable developers to migrate off of flash and instead use Gecko.
>
>
> I'm not sure that this is the right standard. The reason that we are
removing
> Flash is that people are sad about some things in Flash. So I think we
need
> to replicate enough of Flash to get people to stop using it, but that
doesn't
> mean we need to have it be bug-for-bug compatible with every feature Flash
> has, including features we think are bad.

There are spec drafts written for most of this feature, with remaining
parts on the way. The api has been extensively discussed with all browser
vendors and has changed substantially in response to this.

/ Jonas

[Eric Rescorla]

On Tue, Sep 22, 2015 at 7:07 AM, Jonas Sicking <jo...@sicking.cc> wrote:

>
> On Sep 21, 2015 11:57, "Eric Rescorla" <e...@rtfm.com> wrote:
> >
> > On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking <jo...@sicking.cc>
> wrote:
> >>
> >> Note that this, similarly to clipboard integration, is already exposed
> >> to the web through flash. So the main goal of this feature is to
> >> enable developers to migrate off of flash and instead use Gecko.
> >
> >
> > I'm not sure that this is the right standard. The reason that we are
> removing
> > Flash is that people are sad about some things in Flash. So I think we
> need
> > to replicate enough of Flash to get people to stop using it, but that
> doesn't
> > mean we need to have it be bug-for-bug compatible with every feature
> Flash
> > has, including features we think are bad.
>
> There are spec drafts written for most of this feature, with remaining
> parts on the way.
>

To the extent to which you're referring to:
https://wicg.github.io/directory-upload/proposal.html

I find it notable that it does not contain any security section, or to the
extent I can determine, even the word "security".

The api has been extensively discussed with all browser vendors and has
> changed substantially in response to this
>

Can you please point me to those changes and to the security analysis?

-Ekr

[Jonathan Watt]

On 22/09/2015 00:27, Richard Barnes wrote:
> On Mon, Sep 21, 2015 at 6:58 PM, Jonathan Watt <jw...@jwatt.org> wrote:
>> I don't think directory picking is bad - there are many sites with
>> legitimate uses. I think it's right that we need to think about the
>> security implications though, and members of the security team have been
>> looped in to consider these issues.
>
>
> Who have you been talking to on the security team? I haven't heard any
> discussion of this in our security engineering meetings. And I share EKR's
> concerns here.

Yourself, dveditz and Jesse have all commented in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=907707

When I said "looped in to consider these issues" that's what I meant.

[Jonathan Watt]

On 22/09/2015 00:27, Richard Barnes wrote:
> On Mon, Sep 21, 2015 at 6:58 PM, Jonathan Watt <jw...@jwatt.org> wrote:
>> I don't think directory picking is bad - there are many sites with
>> legitimate uses. I think it's right that we need to think about the
>> security implications though, and members of the security team have been
>> looped in to consider these issues.
>
>
> Who have you been talking to on the security team? I haven't heard any
> discussion of this in our security engineering meetings. And I share EKR's
> concerns here.

[Anne van Kesteren]

On Mon, Sep 21, 2015 at 5:37 PM, Jonathan Watt <jw...@jwatt.org> wrote:
> 2. https://wicg.github.io/directory-upload/proposal.html

It still seems bad that this is not being integrated into whatwg/html
directly. A ton of things are basically not defined right now. It's
also unclear how this feature should work together with other
proposals that make <input type=file>.files writable and such.

For a method that returns a promise, part of its definition says "If
the input type is not "file", nothing occurs." which doesn't really
mean anything.

This draft is a good sketch, but it's not a specification from which
we can create long term interoperable implementations.


--
https://annevankesteren.nl/

[Jonathan Watt]

I can only speak to:

https://wicg.github.io/directory-upload/proposal.html

since I wasn't involved in:

http://w3c.github.io/filesystem-api/

I would note that the former is derived from a section of the latter though, and
no doubt had discussions I wasn't party to.

The discussion for Directory Upload largely happened out of band to iron out any
major implementation issues before making a proposal for public feedback. As a
result I can't point you to any relevant changes per se other than those at:

https://github.com/WICG/directory-upload/commits/gh-pages

but I don't think there's anything security related in there.

As for our security analysis thats not yet concluded but you can find it in:

https://bugzilla.mozilla.org/show_bug.cgi?id=907707

and I'd encourage you to participate there.

[Jonathan Watt]

On 22/09/2015 15:46, Anne van Kesteren wrote:
> On Mon, Sep 21, 2015 at 5:37 PM, Jonathan Watt <jw...@jwatt.org> wrote:
>> 2. https://wicg.github.io/directory-upload/proposal.html
>
> It still seems bad that this is not being integrated into whatwg/html
> directly.

It's not that this isn't going to happen (I would certainly expect it will),
it's just that MS's strong preference is to work in WICG at the moment.

> A ton of things are basically not defined right now.

Can you file issues for what you see in
https://github.com/WICG/directory-upload/issues ? I've just been added as an
editor and can hopefully promptly update the text.

> It's
> also unclear how this feature should work together with other
> proposals that make <input type=file>.files writable and such.

When directory picking .files is required to be null. I'd think it would be up
to such specs that make .files editable to also make the sequence
getFilesAndDirectories resolves to editable too.

> For a method that returns a promise, part of its definition says "If
> the input type is not "file", nothing occurs." which doesn't really
> mean anything.

Yeah, I already noted that in:

https://github.com/WICG/directory-upload/issues/13

and now that I can edit the text I'll fix that up shortly.

> This draft is a good sketch, but it's not a specification from which
> we can create long term interoperable implementations.

If you can file the issues you see (or ping me on IRC) hopefully we can fill in
the gaps to make it so.

[Anne van Kesteren]

On Tue, Sep 22, 2015 at 4:46 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> This draft is a good sketch, but it's not a specification from which
> we can create long term interoperable implementations.

E.g., it claims to build on the FileSystem API, but defines an
additional path member on Directory without mentioning why that is
done. And nobody (until I just did it) raised an issue on that. The
draft also doesn't define the directory content attribute at all as
far as I can tell, although the examples do assume it does
something... And that's just from a couple of minutes review.


--
https://annevankesteren.nl/

[Jonas Sicking]

On Tue, Sep 22, 2015 at 11:16 PM, Eric Rescorla <e...@rtfm.com> wrote:
>> The api has been extensively discussed with all browser vendors and has
>> changed substantially in response to this
>
> Can you please point me to those changes and to the security analysis?

Security wasn't discussed much in these conversations, and the changes
were all syntactical and didn't affect security. That's not to say
that no one has cared about security or been unaware about the
security implications, it's more due to the fact that any security
aspects here are likely to influence the API or the normative spec
text.

But yes, I agree that we should have the security team look at this feature.

/ Jonas

[goo...@sven-haag.de]

Any updates on this? How is the status? Feature is not shipped even in version 45 :(. Thanks.

[Andrea Marchesini]

I'm working on this. From an implementation point of view, we have almost
everything done and behind pref.
There are still some patches to review but it should not take too long.
The only missing piece is to change form submission but I should be able to
finish it for the next week.

More important is the security implications for the directory picker: bug
907707.

b