HTTP Shamer here. I absolutely practice 'responsible disclosure' when it is appropriate.
In the case of TripIt, they've known about this issue for a VERY LONG TIME and chose not to address it. I'm incredibly sad about this because I absolutely love TripIt.
There's several sites and apps I've either found out about myself or have been submitted to the Tumblr that I do think warrant responsible disclosure, and I've either done that or am working on that. Sadly, only one of those vendors even has a security e-mail address with a responsible disclosure policy.
In the case of Scribd, if you're using HTTP for all of your account activity, it's not going to be encrypted, period. I'm not going to responsibly disclose that passwords are sent cleartext over HTTP because that's obviously what happens with HTTP. If the vendor made any attempt to use SSL that appears broken, I would stop and responsibly disclose.
In the case of apps going out and checking for updates insecurely, I think that behavior is prevalent enough to see, and obscure enough to exploit, that responsible disclosure doesn't really apply. It's just that HTTPS is something I'd like to see on developer roadmaps. There's been good discussions about this on Twitter, including the VLC team closing a ticket about it.
If I saw personally-identifiable information being sent from an app, I would stop and responsibly disclose.
Personally, I don't see how responsible disclosure can really apply to cases like this.
This is not some obscure vulnerability. It's a deliberate design decision with obvious tradeoffs. It's analogous to a bank keeping deposits sitting on tables in front of the building. It's obvious to anyone who looks, and it should have been obvious to the person who came up with the scheme.
The point of responsible disclosure is to give companies a chance to fix a vulnerability before it becomes widely known. That doesn't work when the problem is obvious to anyone who glances at it, because you've lost your chance at "before".
For something like "you can hijack session cookies sent over an unencrypted connection", I can see how that would warrant responsible disclosure. But for "this entire feed is dedicated to sensitive information, and it's sent in clear text by the very nature of the protocol you've chosen to deliver it", it doesn't seem like it works.
In the case of TripIt, they've known about this issue for a VERY LONG TIME and chose not to address it. I'm incredibly sad about this because I absolutely love TripIt.
There's several sites and apps I've either found out about myself or have been submitted to the Tumblr that I do think warrant responsible disclosure, and I've either done that or am working on that. Sadly, only one of those vendors even has a security e-mail address with a responsible disclosure policy.
In the case of Scribd, if you're using HTTP for all of your account activity, it's not going to be encrypted, period. I'm not going to responsibly disclose that passwords are sent cleartext over HTTP because that's obviously what happens with HTTP. If the vendor made any attempt to use SSL that appears broken, I would stop and responsibly disclose.
In the case of apps going out and checking for updates insecurely, I think that behavior is prevalent enough to see, and obscure enough to exploit, that responsible disclosure doesn't really apply. It's just that HTTPS is something I'd like to see on developer roadmaps. There's been good discussions about this on Twitter, including the VLC team closing a ticket about it.
If I saw personally-identifiable information being sent from an app, I would stop and responsibly disclose.