Does this repro if the page just does a postMessage() to itself? (i.e. are workers a necessary part of this repro?)

Nope, doesn't repro with just a window posting to self.

Requires a SharedWorker to be active, and a secondary tab to connect to the SharedWorker.

Note to self while debugging:

If a WebBlobInfoArray is passed to SerializedScriptValue::serialize() then File::captureSnapshot() is called on each file. Otherwise, it's called only if file.hasValidSnapshotMetadata() is true. Unsure if this behavior difference is intentional.

The ChildProcessSecurityPolicyImpl::GetInstance()->CanReadFile() check in FileUtilitiesMessageFilter::OnGetFileInfo is failing; the worker is running in the same process as the first tab and the second isn't granted permission.

(Current implementation is that read permission is granted to a (pid, path) tuple, so the repro only occurs if a different file path is used from the two tabs.)

Now, why does the FileReader work...

(Blink-Worker bug triage)

jsbell@, let me tentatively assign this to you. Please feel free to reassign to me if this is an issue of worker implementation.

It's not a worker issue per se; we need to either propagate permissions to other processes when posting File references or do snapshots before posting.

So yeah, I'll take/delegate this one.

Further testing in Chrome 52.0.2743.116 on Linux shows File.size is sometimes available when passing the File object to the SharedWorker (from a tab connecting to the already running SharedWorker).

Other observations:
- File.lastModified/File.lastModifiedDate attributes track new Date().getTime()/new Date() respectively whenever the File.size attribute is dropped.
- File.slice(start, end) operations fail whenever the File.size attribute is dropped.
- FileReaderSync is able to read files to a dataURL regardless of the File.size attribute being dropped as originally reported (thought this was only tested with files < 10MB)

updating title. It looks like we either need to transfer permissions or snapshot the metadata. The right solution would transfer permissions.

(Blink-Worker bug triage) I remove the Blink>Worker label based on c#11.

If we start transferring permissions, it'll be important to defend the kind of against the attack scenario described in https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_view_host_impl.cc?type=cs&q=OnStartDrag&sq=package:chromium&l=1019 -- i.e. a compromised renderer trying to initiate transfer of permissions it never had in the first place.

Transferring permissions seems like a nearly impossible task. I.e. if a File is transferred over a MessagePort, normally that never even passes through the browser process. It's just a direct mojo MessagePipe between two renderers.

The correct solutions instead might be not to just ask the browser for file info for a path, but also pass along the UUID of the DOM File (Blob) which should allow the browser to verify that yes, this is a file being referenced by this blob, so the renderer knowing the blob UUID should be enough proof that the renderer is allowed to access the file contents.

Does this mean that the file stat-ing will be an IPC to the browser instead of directly in the renderer?

Stat-ting is already a (sync) IPC - https://cs.chromium.org/chromium/src/content/renderer/renderer_blink_platform_impl.cc?l=512

note-to-self: with site isolation enabled this might be a little bit more urgent to fix, as this now means that posting files to cross origin iframes is much more likely to cause problems... i.e.  issue 866805 

 Issue 866805  has been merged into this issue.

We'll probably need to figure this out while tackling persistence for file/directory handles.

Persistence for file/directory handles is almost entirely unrelated to this. It is trivially easy to fix this with the current code in almost all cases, with the caveat that we'd lose special-casing for files in things like form uploads, which might or might not be a performance regression.

(I'm not saying the trivial fix is the correct fix, I haven't fully thought through the implications; but ideally I would like to get rid of all the special cases for file-backed-blobs, at least on the renderer side, as there really is no reason for blink to have to know what file a blob is backed by)

More related to file/directory handles is how to deal with filesystem backed blobs, where I'd also like to get of all special casing. That one is almost easier already, as the only place we're currently doing any special casing for those is for drag-and-drop of blobs (where arbitrary blobs for whatever reason aren't supported, but filesystem or file backed blobs are).