Consider allowing re-reads after snapshot state change for applications loaded from file: URIs

Currently, the spec denies file reads if the file's snapshot state changed after the file was selected. In practical terms, this means that I can't select a file, read it, edit the file out of band, then read it again. This is a sensible security measure in most cases: if I select a file on some website, that website should not be able to cache a reference to the file and load it again later to see what I've been doing.

However, this measure seems like overkill for web sites loaded from file: URIs. I have an HTML+JS document validator that when originally written a few years ago, allowed a user to select a file, display it, edit it out of band, then re-display it without needing to select it again. The application was normally loaded from a file URI. Then browsers implemented this restriction on re-reading files that have changed and the application's workflow broke.

Is there a security requirement for this restriction to apply to web sites loaded from file URIs? If not, can we consider relaxing this requirement in the case that the application's origin is a file URI or any other scenario where the application's origin is the same as that of the file being loaded?

Commencez par la restriction de la File API specification concernant la lecture des fichiers après une modification de leur snapshot state, puis examinez comment sont définis les file: URI origins et le comportement same-origin. Déterminez si l’assouplissement de la restriction est compatible avec la sécurité et documentez la specification decision qui en résulte ; le payload ne nomme aucun fichier d’implémentation ni aucun test.