Potentially Unwanted Programs Scan #37
Comments
|
This is definitely something we're considering. A few issues with it though: in chrome, for downloads, the way these checks work is that the file is first downloaded to a temporary file, then checked and finally moved/renamed to its actual destination. That flow won't really work if we want to support an efficient So yeah, it would make sense to have some kind of safe browsing/virus scan checks as part of this, but I'm not sure I see a way of doing that while also keeping a reasonably performant API that actually solves the use cases we want to solve. Perhaps some balance is to only support |
|
Is there a reason Chrome or the operating system cannot scan the file after writing has been completed, or before the user attempts to open it? |
|
"After writing has been completed" might not be very well defined with a pwrite style API. Doing a check after every individual write would probably cause unacceptable performance overhead, but doing the checks later after some delay/some amount of "idle" time could result in a bad user experience where chrome first tells the website that the write was successful (and the website probably then tells the user), but ultimately we end up somehow acting on detected possible malware. Also unclear how we'd react on anything detected in such a way. Simply deleting the suspected malware files could be problematic, especially if a website is merely modifying an existing file on disk. Maybe we could try to undo the modifications, but that isn't really plausible either (without deep OS integration on certain types of filesystems only). |
|
Are you aware of what happens with malware detected when the user selects an existing file to overwrite using the download functionality? |
This attempts to solve #37 by making it explicit that changes made to files might not be reflected on disk until flush() or close() is called on the writer. This also introduces a "atomic" mode for FileSystemWriter where any changes are written to a temporary file, and only on flush or close is that file moved on top of the destination file. This should address #48.
This attempts to solve #37 by making it explicit that changes made to files might not be reflected on disk until flush() or close() is called on the writer. This also introduces a "atomic" mode for FileSystemWriter where any changes are written to a temporary file, and only on flush or close is that file moved on top of the destination file. This should address #48.
* Add options to createWriter() to deal with atomic writes. This attempts to solve #37 by making it explicit that changes made to files might not be reflected on disk until close() is called on the writer. This also introduces a "atomic" mode for FileSystemWriter where any changes are written to a temporary file, and only on close is that file moved on top of the destination file. This should address #48.
This makes it clear when user agents can perform such scans, and how failing a check will be reported. Fixes #37
This makes it clear when user agents can perform such scans, and how failing a check will be reported. Fixes #37
* Call out malware scans in writer close algorithm. This makes it clear when user agents can perform such scans, and how failing a check will be reported. Fixes #37 * address comment
Currently, browsers perform a scan on files when downloaded. I'm not sure how this works under the hood but I know that some browsers have their own internal scanners. Also, that under most operating systems, the default virus/malware scanner is invoked in any newly downloaded path. Any such hooks should also be applied to paths newly created by this API.
The text was updated successfully, but these errors were encountered: