Enable MIME type detection for Local Files |
||||||||||||
Issue descriptionWe currently get the MIME type of a file from the file extension. This has two problems: (1) If a file is renamed and loses its extension (see issue 847255 ), the file can no longer be opened (2) If a file has the wrong extension (see issue 429455 ), the suggested apps for the file are incorrect (3) It (might be?) a security issue to open a file based on its extension; bad files can mask themselves as different types to get into an exploit
,
May 31 2018
Issue 847255 has been merged into this issue.
,
May 31 2018
,
May 31 2018
Mostly in response to (3): For some files the extension is going to be the only option is it not? If Chrome downloaded the file then we know the MIME type reported by the server and could store that in an extended attribute for later. If the file comes from an external storage device what other option is there? It seems though that preferring the MIME type if is available (as in issue 847255 ) over the file extension would solve some problems.
,
May 31 2018
Oops; thanks - clarified that this would only be for Local files. For Drive files, Drive sends us the MIME type as you described. Yup - this bug is about preferring the MIME type over the file extension, which would also fix the issue you filed in bug 429455 .
,
May 31 2018
Re: (3) If the file in question (is like an image etc) is being opened in the context of a chrome renderer, the provided mime-type does not matter -- chrome renderers ignore it anyway, since it is controlled by a third-party (oldest exploit trick in the book, and solved long ago in the context of the web). Chrome renderers content sniff, see images for example [1], they never trust a provided mime-type. If this bug is about some C++ code in chrome that is trusting a mime-type controlled by a third party, then you maybe have a serious problem, like FireDragging [2]. [1] Image decoder creation for example https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/image-decoders/image_decoder.cc?type=cs&q=ImageDecoder::Create&sq=package:chromium&g=0&l=68 [2] See crbug.com/259669
,
Jun 1 2018
Adding the conops Chrome OS hotlist for tracking.
,
Jun 8 2018
Issue 603650 has been merged into this issue.
,
Jun 8 2018
Investigate why the detection is disabled, and perhaps re-enable it (maybe behind a flag) with UMAs to check slowness in the wild.
,
Jul 25
,
Aug 15
,
Oct 4
,
Oct 23
,
Dec 10
,
Jan 2
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a332cfd89084c6930277948c8a0a5cd03b5fdb02 commit a332cfd89084c6930277948c8a0a5cd03b5fdb02 Author: Alex Danilo <adanilo@chromium.org> Date: Wed Jan 02 02:41:30 2019 Fix display of MIME type for PDF in Quickview. First part of general cleanup of MIME and file extension handling. Opening a QuickView preview of PDF files shows the MIME type correctly iff the extension is '.pdf'. If there are PDF files without an extension, or with an incorrect extension the file should be sniffed to display the correct MIME type. This is done in QuickView via the MediaGalleryAPI but was not being propagated to the QuickView metadata panel. This change corrects that, using the local file sniff data. The display of contents in QuckView is managed from the manifest, so this doesn't fix the preview itself, just the metadata. Bug: 848124 Change-Id: Ic4ef725698f96d59748da3c1097f5f9db9e20c8b Reviewed-on: https://chromium-review.googlesource.com/c/1392696 Reviewed-by: Joel Hockey <joelhockey@chromium.org> Commit-Queue: Alex Danilo <adanilo@chromium.org> Cr-Commit-Position: refs/heads/master@{#619364} [modify] https://crrev.com/a332cfd89084c6930277948c8a0a5cd03b5fdb02/ui/file_manager/file_manager/foreground/js/metadata/content_metadata_provider.js
,
Jan 3
Issue 824115 has been merged into this issue.
,
Jan 14
Issue 921447 has been merged into this issue.
,
Jan 16
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by sashab@chromium.org
, May 31 2018