Firefox 3.6/HTML5 File Objects Security Review: Difference between revisions

← Older edit

Firefox 3.6/HTML5 File Objects Security Review (view source)

Revision as of 22:29, 25 August 2009

1,702 bytes added , 25 August 2009

m

→‎Review comments

Sidstamm

canmove, Confirmed users

1,537

edits

@@ Line 48: / Line 48: @@
 == Review comments ==
-* Currently people who drag a desktop file and drop it into a browser window (all browsers, not just Firefox) will have the page contents replaced by the new file -- they aren't giving the file contents to the old page. This will change that expectation. Need some front-end signifier that there's a change in behavior/expectation. Cursor change? Drop target in page? A popup confirmation dialog? (kidding)
+* Currently people who drag a desktop file and drop it into a browser window (all browsers, not just Firefox) will have the page contents replaced by the new file -- they aren't giving the file contents to the old page. This will change that expectation. Need some front-end signifier that there's a change in behavior/expectation. Cursor change? Drop target in page? A popup confirmation dialog? (kidding)  Maybe it would be OK to drop "replace current contents" behavior and have file-drop always provide the file to the given page?  Probably a good idea to talk about UX people about this and find out whether or not we can do both.
+* Page gets info about file. Should not include path (currently doesn't), name, size, type (not content-sniffed) and extension is OK.
+* only transfer data between pages with the same principal
+* once a page gets a "DOMFile" reference it can read that file as long as the page is open, including any future edits during that time. This may be counter-intuitive to users who expect pages to get a "copy" of the file when it's dropped/submitted.
+* &lt;jesse&gt; allowing file drops turns window.moveTo into a security hole. maybe fixing https://bugzilla.mozilla.org/show_bug.cgi?id=502561 needs to block supporting file drops.
+* &lt;script&gt; should not be allowed to load from filedata: -- could we even limit its use to images?
+* If files are sent cross-origin via postMessage() the new origin gets access to the file, not just a snap-shot. This seems bad. Not much different than one page sending updated contents to another which they could do now with strings, but the "lifetime of accessibility" would be non-intuitive to users. Closing the page to which they gave access doesn't necessarily stop access to the contents (as opposed to a copy of the data given).
+* jst thinks we should invalidate file handles if the file changes on disk.
+* storing files into globalStorage should probably be a copy of the file, not a handle to the live local file. Otherwise if this is some off-line app and the user deletes the local file after "uploading" it the file could be gone.