[w3c/FileAPI] Consider allowing re-reads after snapshot state change for applications loaded from file: URIs (#174)

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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/174