There are different attacks, however, that makes the QR option in SQRL worse in a practical sense than a username/password. One example is a variant of the hidden-browser attack against a smartcard-based hardware token. The SQRL client in this case serves two purposes: First it reinforces the user's mental perception of what they think is going on and, second, it provides the authentication. An attack against the QR option in SQRL is more significant than a site-specific QR authentication scheme because a SQRL client has the ability to authenticate against multiple web sites.
At the very least, any site using SQRL that cares about security should disallow logins where the SQRL client and browser IP addresses are different. Web sites should also implement the "respond to the SQRL client with the authenticated session URL" option. With this option, users would be required to use a browser on the same machine as the SQRL client. Finally, users should use a client that integrates with the browser as this would enable detection of a web page URL mismatch.