Proposal: File-system access: Provide a user-friendly way to request permission to access specific file locations.

[Felix-Dev]

Edit: A revised proposal can now be found at Project Reunion.

Summary

Rcently, there have been quite a few discussions about the UWP sandbox model and how it restricts access to the user's file system. Currently, UWP apps can freely access only a select few locations on the file system such as the pre-defined Music, Pictures and Videos libraries. If an app needs to access a file system location outside of those locations, it currently has two ways to gain access to that location:

1. Using a FolderPicker and the FutureAccessList API
2. Using the restricted Broad File-System Access (BFSA) capability

Both approaches have their issues.

Approach FolderPicker & FutureAccessList:

• Using a FolderPicker means I have to ask the user to navigate to the file location in question which, depending on the actual file location, can be quite cumbersome. The user might have to walk through several directories with many files and folders until they reach the destination file/folder.
• Currently, The FutureAccessList API only allows storing 1000 files/folders and if the app needs to add more items to the list it is up to the developer to make room for those. Thus, depending on the actual app, this might lead to the user having to add folders/files they previously had to add already. The developer also has to invest in an implementation which will not constantly ask the user to re-add files.

Approach BFSA:

• The user may need to close the app, grant permission in the Windows Settings app, and restart the app.
• The user might not want to give an app unrestricted access to their files.
• The developer needs to provide a reason for the BFSA to Microsoft when submitting the app to the store which may or may not get accepted.
• In some cases, having to use this capability is actually the case of taking a sledgehammer to crack a nut.

In my specific case, one of my UWP apps wants to enable the user to have easy access to the local Windows Spotlight images stored on their device and save those images they like (Windows Spotlight images will be removed regulary from your device and replaced with a new batch). The issue is that the file system location Windows uses to store the current batch of local Spotlights is outside of the select few file locations an UWP can access freely.

Given the current state of the UWP sandbox I can open a FolderPicker and tell the user to navigate to this file location:
C:\Users\<User>\AppData\Local\Packages\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\LocalState\Assets

which hardly delivers a nice user experience and can be quite cumbersome. @kmgallahan pointed out a way how to avoid having the user navigate through a potential sea of files and folders by providing some UI which would copy the target location to the clipboard from where the user would paste it into the address bar of the opened file explorer. Depending on the target location in question, this could indeed be a slight improvement over the manual navigation, but the fundamental issue remains: This is not a friendly user experience.

If I don't want to display a FolderPicker and ask the user to navigate to the specific location, I will have to use the BFSA capability which is a massive overkill in this case and could end in the user choosing not to install my app. At that point, this leaves both the user and me as the developer of the app unsatisfied.

Thus, to provide a more streamlined and modern user experience, I propose the following solution:

When an app tries to access a file system location it cannot freely access by default, the system shows a prompt asking the user if they want to grant the app access to the file location in question. The user can either deny or grant access. If access is granted the app can from now on freely access the location. If the request is denied, the app won't be able to access the file location.

An example dialog is shown below:

This dialog prompt concept is nothing new, in many cases users will be shown these prompts asking for permission when running UWP apps (such as Camera access, asking for automatic start at log-in, etc...). Hence this new prompt will seamlessly integrate into the current well-known UWP sandbox experience.

Scope

Capability	Priority
Allow developers to create experiences which can request access to specific file system locations(*) in a user-friendly way.	Must
Allow apps to access file locations without the consent of the user.	Won't

(*) = (outside of the already allowed file locations)

Open Questions

Assuming the user granted an app access to a specific file location: How can the user revoke this permission? The Windows Settings app will presumably be the relevant system component to manage these permissions. The Windows 10 Security app could be useful to look at for inspiration: See "Controlled Folder Access" and "Exclusions" in the category "Virus & threat protection".

[kmgallahan]

If an app needs to access a file system location outside of those locations, it currently has to use the restricted Broad File-System Access (BFSA) capability.

No it doesn't... You can access other locations via the File/Folder Picker + FutureAccessList.

https://docs.microsoft.com/en-us/windows/uwp/files/file-access-permissions#accessing-additional-locations

https://docs.microsoft.com/en-us/uwp/api/windows.storage.accesscache.storageitemaccesslist#remarks

That isn't to say being able to explicitly request access to a location without a File/Folder Picker prompt wouldn't be nice, but it isn't like you have to go through the whole broadFileSystemAccess ordeal you laid out.

[Felix-Dev]

@kmgallahan You are indeed correct and I was aware of this option yet somehow it managed to slip my mind when I wrote the issue. Awkward.

Thankfully, this lapse is not a k.o. for this issue as the way you mentioned above still leaves a lot to desire: I would have open a FolderPicker, point it perhaps to the PickerLocationId.ComputerFolder as the start location and have to tell the user to go to this specific file location. The user then needs to navigate through the Windows files structure to the location in question.

Not very appealing. It's a way though so I will edit my proposal. Thanks again for the reminder.

[kmgallahan]

Fyi, it is definitely clumsy, but for the specific use case you walked through above you could provide a button to copy this string to their clipboard so they can paste it into the FolderPicker:

%userprofile%\AppData\Local\Packages\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\LocalState\Assets

At the minimum I'd recommend the Folder/File picker get the option to open at a specific location, even if the app doesn't currently have access to it.

Another good option would be to present a dialog that can request access to one or more specific locations, as you mentioned.

Regarding the whole centralized app file/folder access permissions thing, that would be more in line with work the Windows team would have to do in the Settings app. It would mostly revolve around removing items from the FutureAccessList per-app via a single UI. Not super complicated, but doing in a user friendly manner could be challenging.

[Felix-Dev]

@kmgallahan I updated my proposal.

[kmgallahan]

@Felix-Dev FYI, using the literal %userprofile% string as mentioned above will open the picker directly to the location without having to know the username. Not sure if this will help with something you are actually trying to do right now or if this is just a theoretical example.

Also, regarding the 1000 item limit of the FutureAccessList - I'm doubting a user would ever be going through the picking process 1000 times for different files / folders, rather than just choosing a couple parent directories, so that isn't a realistic concern IMO.

[Felix-Dev]

@kmgallahan

Also, regarding the 1000 item limit of the FutureAccessList - I'm doubting a user would ever be going through the picking process 1000 times for different files / folders, rather than just choosing a couple parent directories, so that isn't a realistic concern IMO.

Yeah, I really only added it for completeness. At least in my case it would definitely not be an issue. Perhaps others reading this issue could comment in case this limit posed (or would likely pose) an issue for them.

As for the %userprofile%, I would definitely use that with the FolderPicker approach until I have a better option available. The app itself is not currently in development but I'll keep this suggestion firmly in mind!

[lukeblevins]

I would like to see a modern File Picker component, but this will probably only come to Windows 10 if Explorer is modernized as well. I know one is already in Windows 10, we just cannot access it.

[ranjeshj]

This is not part of the WinUI code base. @jesbis do you know where to route this feedback ?

[ranjeshj]

@Felix-Dev This is not owned by the WinUI team, could you please file a feedback request though the feedback hub app and share a link here? We can try to route that to the appropriate team.

[kmgallahan]

@ranjeshj

@jesbis essentially invited this type of feedback with his comment here.

So you two might want to discuss intentions.

[ranjeshj]

@kmagallahan I understand. Teams outside of those in WinUI do not actively track this repo but they do look at feedback issues. I want to make sure that the proposal is visible to the appropriate folks. As @jesbis mentioned unfortunately there isn't a way to communicate back and forth. We can still use this feature proposal to do that.

Some things to note.

1. Sandboxed apps don't support spamming users with permission requests by design - the intent is that resource access should be initiated by user actions and can be cached with the FutureAccessList
2. WinUI 3 should allow unrestricted file access if not sandboxed
3. I will forward this thread to the storage team. I've created an internal bug and linked the proposal so that it can be routed to the storage team.

[kmgallahan]

@ranjeshj

Sandboxed apps don't support spamming users with permission requests by design

If app developers think spamming users is a good practice, then currently they could just keep popping open a new window asking them to open a FolderPicker > copy + paste a location > hit OK.

In either case, a user can just uninstall the abusive app and report it (if there is a way to?).

The possibility of bad developers making spammy apps shouldn't preclude responsible developers from providing users with a better folder permissions experience.

[Felix-Dev]

@ranjeshj @kmgallahan

I would also like to point out the behavior of the StartupTask API which does not show the prompt again on subsequent app requests in case the user already turned down the request to automatically start the app at log-in. Instead, the user has to change that decision in the Windows Settings app before the app can successfully make a request again.

See in this blog post:

If the user disables (either via the user prompt, or via the Task Manager Startup tab), then the prompt is not shown again, regardless of any requests from the app.

If showing a dialog prompt each time the app tries to get access to the same file location (after the user denied each request attempt) is seen as a serious problem, then it might be worth to consider using the same approach as currently chosen for the StartupTask API. Especially as we might want to enable the user to remove permissions previously granted to apps to access specific file locations by using the Windows Settings app. The UI would be the same, just that for some file locations the toggle switch would be in an ON state (indicating access granted) while for other paths the the toggle switch would be in an OFF state.

[jtorjo]

@ranjeshj @kmgallahan

Is it possible to add a function to FutureAccessList (StorageItemAccessList class), something like bool AskUserAndAddFolder(string) ?

This would basically ask the user for the prompt @Felix-Dev showed, and if the user says yes, it would return true.

Personally, I would also like the following: the user can go to Windows Exporer (or any other app, for that matter), and copy one or more files/folders into clipboard.
In UWP, they will actually show up when interrogating the clipboard (as far as I remember) - so we could have an extra another function bool TryAddItemsFromClipboard() - once again, the user is shown in a dialog the items he would grant access to, and if so , the function would return true.