There are a number of issues with what we allow in extensions that a website can provide when showing a file picker. Since the file picker (on most platforms) appends these extensions to the filename the user enters, this can result in filenames with characters we don’t want to allow/that are otherwise problematic. In particular we don't want to allow control characters or whitespace in suffixes, or filenames that end in a '.'. As such this PR adds restrictions on what characters are allowed in accepts file extensions/suffixes, as well as limiting their length to 16.
On Windows file suffixes such as .lnk and .local are also particularly dangerous to be written to. We opted not to reject these when specified as "accepted" file types in showSaveFilePicker though, instead leaving it up to the user agent to ignore these file suffixes, and/or block writing to these file types completely.
Considered alternatives
Have a bigger allow list of characters. Other characters, such as +, -, $, # and ! are probably safe in file extensions, and have been used occasionally by applications in the past. Because of how rarely these are used, we're limiting extensions to just those characters that are at least somewhat in common use.
Have a block list rather than an allow list. This option was rejected since while we could try to enumerate all characters that might be problematic, the consequences of not blocking something we should have blocked are much worse than not allowing something we could have allowed. As such a minimal allow list was chosen instead.
Also reject when suffixes ending in .lnk or .local appear in the accepted file types for a showSaveFilePicker or showOpenFilePicker call. We opted against this because different platforms will likely have different extensions they might want to block. Rejecting for these only on some platforms would result in unpredictability where a website might work fine on one platform but fail on another. Rejecting these on platforms where these suffixes don't have special meaning would be needlessly limiting. Giving user agents the option to ignore these file suffixes, or at least not auto-append them to file names in save dialogs still protects the user without these downsides.
There are a number of issues with what we allow in extensions that a website can provide when showing a file picker. Since the file picker (on most platforms) appends these extensions to the filename the user enters, this can result in filenames with characters we don’t want to allow/that are otherwise problematic. In particular we don't want to allow control characters or whitespace in suffixes, or filenames that end in a '.'. As such this PR adds restrictions on what characters are allowed in accepts file extensions/suffixes, as well as limiting their length to 16.
Limiting extensions to only contain alphanumeric characters, + or . still allows all extensions in the shared-mime-info database as well as nearly all extensions in Wikipedia's List of filename extensions.
On Windows file suffixes such as
.lnkand.localare also particularly dangerous to be written to. We opted not to reject these when specified as "accepted" file types inshowSaveFilePickerthough, instead leaving it up to the user agent to ignore these file suffixes, and/or block writing to these file types completely.Considered alternatives
Have a bigger allow list of characters. Other characters, such as +, -, $, # and ! are probably safe in file extensions, and have been used occasionally by applications in the past. Because of how rarely these are used, we're limiting extensions to just those characters that are at least somewhat in common use.
Have a block list rather than an allow list. This option was rejected since while we could try to enumerate all characters that might be problematic, the consequences of not blocking something we should have blocked are much worse than not allowing something we could have allowed. As such a minimal allow list was chosen instead.
Also reject when suffixes ending in
.lnkor.localappear in the accepted file types for a showSaveFilePicker or showOpenFilePicker call. We opted against this because different platforms will likely have different extensions they might want to block. Rejecting for these only on some platforms would result in unpredictability where a website might work fine on one platform but fail on another. Rejecting these on platforms where these suffixes don't have special meaning would be needlessly limiting. Giving user agents the option to ignore these file suffixes, or at least not auto-append them to file names in save dialogs still protects the user without these downsides.Preview | Diff