Proposal: [UWP] Provide a user-friendly UX to request access permissions to specific file locations #45
Comments
|
So something like the IAsyncOperation<StorageAccessRequestResult>
RequestStorageAccessForWindowAsync(WindowId window, String path, String comment);
IAsyncOperation<IVector<StorageAccessRequestResult>>
RequestStorageAccessesForWindowAsync(WindowId window, String[] paths, String comment);Where:
Would you also want "nice names" for the paths? |
|
[MUST] If the user approves a directory this way it should allow CreateFile2 API to freely create files in that directory without needing to go through the storage broker to do it. Just as it does with the AppData folder. That would solve my main pain-point with file access in UWP. |
|
@Felix-Dev - thanks for this proposal – I didn’t realise you’d proposed something like this before as well. I have a few thoughts on this. I really need longer to think about it but I don’t have time. What locations should it allow access to and should this require a capability?The one major problem I have with the original post is the location used in the example, which is inside AppData. I wonder what the general feeling is on this. I have gone back and forth a bit while considering this, but in my opinion, the dialog should not allow prompting for files in this location by default. Many users will probably just click ‘Allow’ without reading it properly, moreover, they won’t know that AppData can contain particularly sensitive information, especially since it’s a hidden folder so they won’t have seen it before. Let’s assume a malicious app prompts for access to AppData and the user allows it because they don’t know any better. Now the app has access to all data and settings stored by other apps. In particular, if you use Outlook, this includes all your emails, which could allow it to perform all sorts of phishing scams etc. Also, since a lot of apps store their settings here, the malicious app could modify the behaviour of other apps by altering their settings, which could have serious consequences. I realise that Documents also often contains sensitive data, but I think it could be good to encourage a convention where apps store their most sensitive data and settings in AppData if possible, and that this location is considered more access-restricted than other locations like Documents. In my opinion the dialog should allow prompting for access to all locations that the user has access to, apart from sensitive file system locations, and AppData should be classified as sensitive. I don’t think there’s any need to exclude hidden files in general though. Maybe there could be an additional, possibly restricted, capability declaration that would allow AppData access via this method as well. Would the use of this dialog require a capability anyway? I don’t see why it should. But if it should, then please ensure the Store page for the app says something like ‘Can access your files via a consent dialog’, instead of ‘Can access all your files’, as the latter implies access upon app installation which will discourage users from installing the app. I can’t emphasise enough how important these seemingly trivial details are and yet they are almost always overlooked by Microsoft, especially as it probably requires communication with another internal team. I hope this project can increase such communication. An ‘Always allow this app to access my files’ checkboxI believe that the experience for both the user and the developer would be much improved if the dialog contains a checkbox that says ‘Always allow this app to access my files’. If the user checks it, the app now has access to the user’s files without the dialog, much like broadFileSystemAccess, except I think, as I mentioned above, that it should exclude sensitive locations like AppData by default. Possibility the presence of this checkbox could require an additional capability. But I hope that it doesn’t have to be a restricted capability, especially if access to sensitive file system locations is denied by default. Why would this checkbox be useful? Well, if the user performs a lot of actions that require file-system access (such as some of the scenarios I mentioned in my post #8 (comment)), they will eventually get annoyed with the prompt and will naturally expect a way to always agree to it. This is also a much more natural way of asking for some sort of broad file system access, because the user can see why it’s needed and it doesn’t appear that the app is trying to access all the user’s files for no reason. Also, they can build up trust in the app using the dialog without checking this option before they trust it enough to check this option. There should obviously be an option in Settings (or somewhere) for the user to revoke this permission. Should there be an option for one-off access?As far as I’m aware, the concept of one-off file access isn’t really part of the UWP app model currently, because you can always add a storage item that you have access to to the future access list, although there is a limit to the number of items to the list I suppose. I feel like such an option might cause problems. First of all, it’s an additional decision for the user to make. But, more importantly, whatever IStorageItem type interface it returned would need to include information about whether or not it can be added to the future access list, and the developer has to decide how to deal with the situation where access cannot be guaranteed next time. Sometimes it’s very difficult to show a dialog in order to access a file (e.g. working on a background thread etc). How should future access be cached?In an ideal world, the app would not have to worry about future access of files accessed via the dialog, and the system would simply grant access without the dialog if access was requested again. In my opinion, the user should be able to clear the access list for the app, but I don’t know if the user needs to be able to see all the locations since it could be quite a long list. However, perhaps it is unrealistic to expect the system to maintain an arbitrary-sized list. There is no value in the dialog adding items to the current implementation of the FutureAccessList automatically, because the app could just as well do that itself. Conceptually, I think what the dialog should do, is aim for the ideal unlimited list, but in reality store a maximum number item items (e.g. 10000 or however many is sensible). The dialog should be able to use this list in a performant, efficient manner. If it runs out of space it can remove the items that were first to be added to the list (and each request for access should update the effective time at which an item was added to the list even if already in the list). It should also be clever – for example if access is granted to a folder, then it can replace any child entries in the list with that single folder entry. Also, this is optional but not required, it might be nice if the app could also add stuff to this list that it obtained in another way. I think there is value in keeping this list distinct from the FutureAccessList, because sometimes the app needs to guarantee future access even if the item was only accessed some time ago, in which case it can use the FutureAccessList (although in an ideal world this list could do with some improvements – see my comments in #8 (comment)). I guess it could be sensible to consider improvements to the FurtureAccessList at the same time. How should the locations be displayed by the dialog?Obviously, they should be displayed in a user-friendly way! Ideally the app would be able to request an almost untimed number of files at a time, and the dialog would automatically determine a good way to present that, for example by reducing it to a maximum of 10 common parents and then saying ‘The app wants to access 1000 files in these folders: …’. If this is too difficult, the I guess you could force the developer to do this themselves and limit the number of files requested. I also like the idea of a customisable message giving a reason for access. It should be possible for the developer to rely on this dialog, and not to have to implement endless fallback solutionsIt’s tempting to say that there should be a way for the user to disable the app from showing the dialog. However, this should not be possible in my opinion. The app may enable scenarios that rely on this feature. To disable the dialog would be to break the app. Then it’s even more work for the developer to try and find an alternative workaround in this case. The dialog, if implemented, should be something that can be relied upon. This should really be explored properly, along with potential alternative solutions…Since this is so fundamental, it should really be given careful thought and consideration, along with possible alternatives. The user experience is always very important in situations like this, so ideally it needs some UX investigations with a number of scenarios in mind, like some of the scenarios I mentioned in #8 (comment). But it should be focussed UX work that doesn’t drag on for ages. Also, it would be worth looking at how this sort of thing works on iOS, Android and MacOS. I am completely unfamiliar with that. One concern I have that I would like to be investigated, is will this turn out to be very annoying for the user? Will the user actually stop using my app because of this dialog, so is it better to try and use another solution instead? I don’t know the answer. Would it be possible to implement this without a full OS feature update?I can’t see how this could be implemented via NuGet packages shipped with the app. However, perhaps it wouldn’t need a full OS feature update if certain components could be updated more frequently. For example, an update to the broker process might be able to deal with some of this. Would there be multiple side-by-side versions of the broker process corresponding to a version that the app specifies (to avoid any accidental breaking changes)? Or would this result in OS bloat and delayed startup times for apps? Can the Settings app be updated to accommodate these changes independently of an OS feature update? Or will we realistically have to wait for an OS feature update? Final points@jonwis – I am unfamiliar with what the WindowId would mean in a UWP app. I have multiple CoreApplicationViews in my app and would obviously like files to be accessible from all of them. Finally, I would like to reiterate that I think this needs some careful investigation, ideally with UX input, but it is very important for the future of the UWP app model so this should not be a barrier – indeed it should be a reason to focus on this issue. |
To make sure we are on the same page here: The example in this proposal would not give the app in question access to all the data inside the AppData folder and thus have "access to all data and settings stored by other apps". The app would only have access to the content of the I do see your concern though and here are two ideas to aid users in making an informed decision:
|
|
@Felix-Dev - my point was that if you are allowed to prompt for access to the folder you give in the example, then presumably you would be allowed to prompt for any folder in AppData, including the whole of AppData itself. I suppose perhaps the system could show an additional warning for a location such as this after you press OK, or show a warning in the dialog with an additional link for more info as you suggested. An option to review the content in the directories/files, or some sort of very brief indication of what content they might contain could be useful, perhaps based on file extensions or just a guess based on file location e.g. Pictures for the Pictures library etc. Obviously it wouldn't be good to impact performance too much here, so reviewing it could be optional as you say. |
ghost
added
the
|
This looks ready to move along to the backlog for potential future features. If anyone has further questions or discussion, let us know. |
|
The problem is which a dialog for asking permissions is that it blocks the UI. While this should be the case for UI thread, when you are doing work in a background thread this is not feasible. Also while the user is doing something showing a sudden prompt might not be a good experience. If it comes after an action it is fine but if the app performed when the user is idle or doing nothing related isn't that good. Since the APIs are async there's no need for a blocking dialog. Instead, why not use a toast notification? |
The blocking of the UI is essential if it is a permission. Now there may be more delicate ways to handle this, like the OS displays a black screen until a webcam permission is agreed to, or the app received a blank audio stream until microphones are granted permission. But network access, or file access permissions, these would require blocking code from running until the permission is granted. |
Yes but UWP Storage APIs are async so the request can be in a toast notification and only if the user agrees, send a callback to the caller. Windows Runtime APIs don't need to return right away because of async. In C# it looks like that with await keyword but actually, it's in a callback. |
|
It would complicate things for the developers, who would have to handle UI States where permission was being sought, and when permission is granted. The idea of having the permissions dialog being modal, means the app only needs to call it on use, and can wait for a response. It also reduces the likelihood that multiple apps, will request the same permission at the same time, and that could cause confusion to the user. |
Ok but what about background access not in the UI itself? |
What kind of background access do you want to request without preventing your app from doing other things. The user who did an action requesting access to this background API, would need to know the app won't do the thing until the permission is granted. And the app will need to present a permissions dialog to ask for the permission. If the permission dialog was not modal, and the user leaves it and does something else, something which cancels out the action the user wanted to do before. Granting permission would not make the action happen, and it may have to request permission next time the app wants to do that thing. |
|
Please update the permission dialogs with a modern Fluent design |
Proposal: [UWP] Provide a user-friendly UX to request access permissions to specific file locations
Summary
Allow UWP apps to request specific file/folder access by displaying a user-consent dialog (system prompt) instead of having to display a File/FolderPicker UI or require the restricted BFSA capability.
@benstevens48 has described this in their long post (Scenarios 5-8) in issue #8 and to my understanding this is also listed as a 'Could' in the issue scope. I believe this particular file-system access painpoint of the UWP sandbox implementation deserves its own proposal instead of being just one of many suggestions put together in a massive thread. It is also not related to the core idea of issue #8 which seems to focus more on the actual UWP File APIs themselves (see 'Must' vs 'Should' vs 'Could' scope) and as such should be treated as its own actionable issue.
Rationale
Currently, if my UWP app needs access to specific files or folders of the user, I can either use the BFSA system capability or display a File/FolderPicker UI. Both cases come with severe drawbacks for the scenario where an app wants to access a select few file system locations already known in advance.
a) not ask for access to multiple distinctly-located folders all at once and
b) the user will have to navigate to the actual file/folder location
There are ways to aid the user in navigating to a location without having to manually walk the entire folder tree, however, this is only mitigating this bad UX. And if my app needs access to distinctly located files & folders, I will have to show multiple *Picker UIs (one UI for each location) if I want to create an app experience which values the user privacy greatly and only obtains access to the minimum required file system locations for it to work.
To improve the process for UWP apps to get access to select file\folder locations, I thus suggest using the well-known user-consent dialog. For example, if the app tries to access a folder it currently does not have access to, the system will show the user-consent dialog asking the user if they want to give the app access to this folder. If the user consents, the app from now on will have access (until the user revokes their consent or the app is uninstalled). If the user denies the request, it won't (and the app could ask again if needed). Visually, this could look like this:
(In this case, the app asks for access to the folder where Windows Spotlight Images are saved by Windows.)
In the example image above, access is only requested to a single folder, yet we can easily imagine apps asking for access to multiple distinctly located files/folders. It should be possible for apps to also request access to specific files/folders in "bulk", in other words, the user-consent dialog will display a list of file system locations the app wants to access.
Scope
Open Questions
Assuming the user granted an app access to a specific file location: How can the user revoke this permission (without having to uninstall the app)? 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".
There is also the concept of granting access "just for this session". What this would mean here is that after closing the app, granted file system access "just for this session" will be removed for the app. In other words, when the app is launched the next time, it will have to ask for access permission to those file system locations in question again.
Is there added user (security) value by providing such an option where the user won't have to actively remove access to a specific file system location for the app?
Additional Context
Original WinUI issue by me here. View this proposal here as the most up-to-date one.
The text was updated successfully, but these errors were encountered: