It sounds like PrivDog is slightly worse. Superfish tries to verify the cert and provide an invalid cert if the original one is invalid, but it overlooks SubjectAltNames [1]. So if you know about this, you can make it produce a valid certificate.
By the sounds of it, PrivDog doesn't verify the cert at all - even if it gets a totally invalid cert, it will produce a valid one for that domain.
The distinction is largely academic, though. If you have either Superfish or PrivDog, any attacker who knows what they're doing can MITM your HTTPS connections.
"So if you know about this, you can make it produce a valid certificate."
Since Filippo Valsorda already went public with the same findings (I held off on the details and let the community figure it out while working with the vendor), here's the thing. SSLSplit does wildcard SAN out of the box. Any WiFi Pineapple with the SSLSPlit infusion can be up and running, MitM'ing Superfish in no time at all without even knowing about the Superfish SAN validation issue. As such, it wouldn't surprise me at all if people MitM'ing WiFi connections already got in the middle without even trying. Keep in mind that Superfish was running on consumer convertible devices like the Yoga 2 which functions either as a laptop or tablet, in short, a device you'd expect to be connecting to WiFi nearly exclusively, thus making the attack surface much larger than a desktop machine connected via a LAN cable to your DSL router.
By the sounds of it, PrivDog doesn't verify the cert at all - even if it gets a totally invalid cert, it will produce a valid one for that domain.
The distinction is largely academic, though. If you have either Superfish or PrivDog, any attacker who knows what they're doing can MITM your HTTPS connections.
[1] https://blog.filippo.io/komodia-superfish-ssl-validation-is-...