Hi, Josh Bryant, co-founder of Droplr.<p>First, apologies that we didn't meet your expectations in regards to security on our service. Just to be clear, any password-related data or personal information you've sent in Droplr has been over HTTPS. But, we didn't go as far as we should have. We misjudged where usage was falling on the public-private spectrum, and we're ensuring we meet privacy expectations now.<p>We can see that it's a priority for people, and it's a priority for us. We've already deployed the fix, so ALL drop content should now be served over HTTPS.<p>We'll work on getting the pages themselves on the d.pr domain served over HTTPS as well and also look into a solution or better documentation for customers using their own custom domain.<p>Thanks for your patience with us and I hope you can forgive us and give us another shot.<p>Cheers
It really shouldn't be a major issue to fix, I've encountered this before.<p>Since they are using S3 (guessing by the second to last comment - <a href="http://support.droplr.com/discussions/suggestions/153-https#comment_17210884" rel="nofollow">http://support.droplr.com/discussions/suggestions/153-https#...</a>) they can use amazon's SSL url<p>so:
<a href="http://files.droplr.com/files_production/acc_1927/xkcd?AWSAccessKeyId.." rel="nofollow">http://files.droplr.com/files_production/acc_1927/xkcd?AWSAc...</a>.<p>would become:
<a href="https://s3.amazonaws.com/files.droplr.com/files_production/acc_1927/xkcd?AWSAccessKeyId" rel="nofollow">https://s3.amazonaws.com/files.droplr.com/files_production/a...</a><p>The only reason not to would be to hide the fact they are using S3, but the AWSAccessKeyId tips their hand anyways.
Why do they keep closing the request? It's obviously a problem. The fact that they seem so willfully ignorant makes me rather nervous about relying on droplr for anything.<p><i>Edit:</i> Looks like they're fixing the problem after all. It's unfortunate that it took a Hacker News article to bring attention to the problem, but at least they're taking the appropriate steps.
<i>The reason why the content itself is not served under https is precisely to avoid the SSL warning. As I've said before, this particular issue is not high priority right now, which doesn't mean we're not aware or aren't going to fix it.</i><p>Something about the tone of this response irks me.
This brings up the concept of taking the right tone with your customers. This is a perfect example of what not to do. "Don't worry, your concerns are invalid... Oh, you have a valid point? Doesn't matter, we don't care."
No content protection is a huge oversite. I hope they re-prioritize this one -- they should care that their customer's data isn't secure on public networks.
In their defence:<p>* Who uses a free file sending service for critical docs?
* The only mention of 'secure' on their homepage has (to my mind) more of an implication of "safe and secure eg your file won't be lost" rather than "secure from hackers"<p>I think it's forgivable, at least for the free version of the service. Maybe they should upgrade then tout the paid version as offering https as a benefit.
<p><pre><code> Bruno de Carvalho closed this discussion
Glyph re-opened this discussion
Repeat
</code></pre>
This is the current formula for customer service (delivered electronically) these days. Drives me up the flippin' wall.<p>CSRs: your customer's problem is not resolved when <i>you</i> are satisfied.
Big red flag that they don't understand the distinction made by the requester over there. I'd be seriously concerned if I had sensitive data in their systems.
What's the point of even using HTTPS if the content in question (and worth protecting) is served via HTTP. The way the support person misunderstands repeatedly and then plays it off as "That's what I meant, duh, we don't care" is pretty tacky.<p>"Oh, I'm sorry, I misunderstood." changes the entire tone of the post. It's not like this is even hard to fix.