Can you please point to a Drop Link that's served over HTTPS,
"convincing users that all their communication is
Our marketing pages are the only pages we serve over HTTPS. We
have never served public shared drops over HTTPS.
Whenever you share a link, we serve a notification including the
link, e.g., "http://d.pr/1234 has
been copied" making it pretty clear it's not an HTTPS link.
I don't see any downside to serving content over HTTPS, so we'll
do it where we can.
It is however a but disingenuous to claim we're trying to
convince users their "publicly shared links" are sent over HTTPS
when we've never done anything of the sort.
We make it very clear in our knowledge base that even with
Droplr's more privately obscured links, the content itself is still
very public and we don't advocate people sharing sensitive
information with Droplr.
First of all, I never meant to say that you purposely try to
convince users that their shared links are over HTTPS. I meant to
say that having your site hosted on HTTPS happens to make users
think your service does everything over HTTPS, even if the
resulting shared link is not.
The more egregious offense is the upload, since the upload
happens entirely on an HTTPS front-end. However, while the UI is
all on HTTPS, the upload itself is not. If you upload a file from
the HTTPS homepage (https://droplr.com/hello), the file
is transferred to a non-HTTPS endpoint (http://api.droplr.com:8080/files.json).
The same is true when you upload from the HTTPS web app. This would
convince even technical savvy users that the upload is happening
over HTTPS, and only with browser/traffic inspection can you tell
that the upload is not encrypted.
You claim that "marketing pages are the only pages we serve over
HTTPS". This is not true. Your landing page and your entire web app
is served over HTTPS. This is a good thing, and I'm not sure why
you're claiming otherwise.
Again, I'm not accusing you of intentionally tricking your
users. I'm just saying the user experience conveys a sense of
security that is not completely there.
URL obscurity is not enough to claim that you "do whatever we
can to keep their data safe from prying eyes," especially when you
acknowledge that you don't see "any downside to serving content
Finally, I would like to highlight that I'm a fellow developer
that wants to see good and secure web services. You provide a
valuable tool, and I just wanted to help you and your users by
highlighting some things that can be improved.
When I said "marketing pages", I meant to refer to our
"marketing and web app stack" which is a different stack than our
public drop pages (on http://d.pr).
As for the upload, WOW, thanks for the heads up. We updated our
whole stack to HTTPS quite awhile ago and somehow the web uploader
slipped through. We sincerely appreciate you calling this out.
We'll get this patched immediately.
And then we'll figure out how to fire our QA person (me)