* Implementing a computation heavy function like the PBKDF in unoptimized Javascript code severly hinders its performance. Therefore its protection of weak passwords is rather limited and can't be relied upon. Then again, on my computer it achieves several thousand iterations within the alotted time, which I consider somewhat beneficial.

* It is necessary to first derive the key before the signature can be checked. Therefore it is trivial to create messages that will take impractically long to reject when injected into genuine communication (by setting a high N). Signing with the plain password to mitigate this would remove the protection of key derivation function against brute forcing. Setting the PBKDF to a fixed number of rounds would unavoidably make it unoptimal on some devices (either high performance or low performance). So I deem the current situation acceptable.

* 30 bytes header can make very short messages a lot longer. For special purposes it would be possible to remove the signature (16 B) or even the header altogether and rely just on the password (now with the implied condition of using a unique password each time). Acknowledging this, I still consider it wiser to always include the header for a general case.