Entropy based progress bar
For downloading a file, yes, this would work.

For a file download, there is a much simpler method: let $n$ be the total number of bytes of the file to be downloaded, and $k$ the number of bytes we have downloaded so far; then $k/n$ is a good estimate of our progress (the fraction of the file we've downloaded so far).

This turns out to be equivalent to your entropy-based notion, if we assume that the file contents are iid bits (i.e., uniform distribution over all possible files of that length).

So why count bytes instead of use entropy?  Well, if they're equivalent, they are just two different ways of describing the same thing.  However, it's much simpler to just count bytes.  Also, counting bytes has the advantage of being something that can be implemented.  Calculating the entropy of the file requires some way to measure entropy, which requires a formula -- and in this case, the formula is to count bytes, so we reduce back to the standard metric.



A progress bar for a software update isn't nearly as easy, because it often involves multiple different kinds of operations, which progress at different speeds.  Also, there is often no uncertainty: the installer knows exactly what files it is writing.  The purpose of the installation is to have a side effect.  We want to measure how long it will take until that side effect is completed.  It's not clear that this will fit into the entropy framework, because an entropy framework doesn't take into account how long it will take for those side effects to complete.  For instance, how long will it take to write one 100MB file and 1000 1KB files?  Hard to say, but I can tell you it's not simply proportional to the number of bits in the files, or the number of bits of entropy -- short files may require a seek, so the time to write a file is not proportional to the length of the file.