This is a feature request. 

MD5 is broken and not an appropriate hash algorithm for this purpose, but one could imagine wanting a feature like this for SHA256 verification. Of course, the security of the feature would rely upon secure delivery of the expected hash value (not a given, in most cases). 

In terms of implementation, it might be nice if the extension APIs would allow an entry point on the download item in the download shelf that would allow Chrome's extension model to implement this sort of feature.

Adding TE-NeedsTriageHelp label for moving this Unconfirmed bug out of TE unconfirmed triaging bucket.

Chrome does not have this feature today. Whether it should is an open question.

Maybe MD5 is broken. SHA256 isn't. The secure delivery of the hash value can be left up to the user to enter upon the download completion. There's no way of catching every file's signature as they are sometimes not published. Unless chrome makes it mandatory for them to or calculates it at source when download is requested.

Whether this feature is an open question or not, I feel the community needs this. If you guys are not able to do it, point me in the right direction and I will learn to do it I guess.  

This is the first I have seen this request. To be honest, I struggle to think that this feature is going to be sufficiently used to justify the investment and/or UX overhead. However, I am going to leave the bug open for a while to see if there is more interest.

Hmmm... I don't think there's much we're likely to do here, on the extensions side.  Right now, this is pretty doable: an extension can use the HTML5 file APIs to read the contents of the file and verify it against an expected hash.  The clunky part is that the extension needs to be provided the file by the user (it can't just read it without permission), but I think that's largely a desirable feature.  I don't think we want extensions to be able to read arbitrary contents off disk.

Since there's not likely going to be extension changes to support this, removing the extensions label.

dah...@chromium.org - we're talking about security here. UX and UI overhead must be secondary to this surely?

Perhaps, If the UI is not intuitive and users don't know how to use it, then it doesn't help security. I will mark this as available in case someone has time to look at it.

I'm not much of a coder, but I doubt the best way to approach a coding challenge is fashion over function???? I think we make the feature available and then break our heads about making the UI more intuitive.

Thank you, I really hope someone takes more interest in this. I mean, it is after all about making chrome more secure and people more secure. Especially considering the number of man in the middle attacks on the internet today. 

The mitigation for MiTM attacks is HTTPS, not asking humans to manually compare inscrutable sets of hexidecimal digits. 

Users who wish to compare SHA256 sums have many options available to them, none of which require changes to the browser. 

Well, how about having site owners maintain say a .htaccess file with the downloadable file's correct signature and making that a spec which chrome can then use to automatically verify that the source is what it says it is! I mean, this is where the ball starts rolling for the internet with chrome right, so if you guys can't make that paradigm shift to a safer browsing experience, who will?

Your proposal requires HTTPS to protect access to the hashes, and after you turn on HTTPS, the proposal offers no additional security benefit. 

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot