Consider allowing re-reads after snapshot state change for applications loaded from file: URIs
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- html, javascript
Línea de trabajo
Comienza con la restricción de la File API specification sobre la lectura de archivos después de que cambie su snapshot state y, a continuación, revisa cómo se definen los file: URI origins y el comportamiento same-origin. Determina si relajar la restricción es compatible con la seguridad y documenta la specification decision resultante; el payload no menciona archivos de implementación ni tests.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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?
- Lenguaje dominante
- HTML
- Estrellas
- 118
- Forks
- 52
- Merge medio
- 9 d 16 h
- PR fusionados (30 d)
- 1
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de w3c/FileAPI
-
TPAC 2026 Status Report AbiertoTPAC2026
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Broken references in File API Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 62/100
-
Add accessibility section Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
Todos los issues de w3c/FileAPI
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
speaches-ai/speaches#678 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
[BUG] ECR GetAuthorizationToken returns a proxyEndpoint for the default region, not the request's Abiertobug ecr
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
conda-forge/spacy-feedstock#177 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100