It has been a monumental challenge to properly detect invalid encoding issues over the years, because it has been nearly impossible to reproduce the variety of possible issues. To make matters worse, most of the encoding issues came from overseas users who did not speak English and would not reply to requests for more information.

However, with our recent improvements and increased logging, we have finally tracked down some of these occurrences in the wild. One of the biggest offenders ended up being a very specific combination of browser encoding support vs web page encoding vs screenshot request URL encoding. Read about the nitty gritty details here.

The changes released today to the delivery code, on our side, do not require any end-user changes and should prevent HASH_MISMATCH errors from occurring again. There may still be rare cases of encoding weirdness that gets through and causes that message, but so far, the changes have all but eliminated those errors.

One important note, though, is that we have implemented this invalid encoding check for referrers to the service as well. Since the recent upgrade to our delivery scripts, we have more security related to referrers, and since invalid encoding "could" be problematic; we now block any access from referrers with invalid encoding (should never be a problem, since web page encoding is not involved in referrer tracking). The important takeaway is that it is possible that our "invalid referrer detection" could unintentionally block a "good" referrer (or screenshot URL request), and it may not be entirely clear why the requests are failing. This should never happen, in practice, and we tested dozens of scenarios to ensure there were no false positives that we could reproduce; but the code to detect is extremely complex, so it is good to be aware of the possibiity of a false positive (if your requests are dropped for no obvious reason).