d.pr domain doesn't have https support, only droplr.com and its
subdomains. The rest of the site (everything under droplr.com)
should be HTTPS, apart for a couple of exceptions (mostly static
OK, let me be very specific. This is a feature request.
When I drop an image onto the droplr icon, I want it to be uploaded via SSL and then I want my link to be an HTTPS link (which I send over a secure channel, such as XMPP-over-SSL) and then the person downloading it should get all the data over SSL too. I might want to use droplr over insecure coffee-shop wifi and I'd like to do it without the scammer sitting at the next table reading all of my traffic.
Really this should just be the default, it should be secure, I should not need to be aware of the security, but I'd personally be OK with it if it were an option I have to turn on.
I don't care about the details of droplr.com's HTTPS certificates or whether I happen to be browsing with a lock icon when I'm reading marketing materials about signup. That stuff can all be cleartext as long as my password is encrypted :).
I probably failed to conveying the right message but the
whole Droplr platform runs on HTTPS. That means
when you upload a file, note or shorten a link via any of the apps
(Windows, Mac or iPhone), it sends the file over HTTPS. When it
reloads your drops, it does it over HTTPS. When you login, it does
it over HTTPS.
If you really insist that the person receiving the file views it
using https, then you can manually replace http://d.pr with https://droplr.com, e.g, for the drop with
the code 'xkcd', you'd replace http://d.pr/xkcd for https://droplr.com/xkcd. For the time
being, we don't have an SSL certificate for d.pr domain so this
step must be done manually -- it's part of our short-term plans,
just not super high priority right now :)
Registration, login, managing your drops, changing your settings
on the webapp, all is done under HTTPS. We force third party apps
to use HTTPS when using our service (we don't even support
non-https connections to our API server).
I hope this clears it out for you. We take our user's privacy
very seriously and do whatever we can to keep their data safe from
prying eyes. Lemme know if you have any further questions.
This does not help. If you look at <https://droplr.com/xkcd>, you will see that while the chrome and scripts and such are delivered over HTTPS, *the content itself* is delivered over HTTP. Specifically, the src= on the <img> in the middle of the page is <http://files.droplr.com/files_production/acc_1927/xkcd?AWSAccessKeyId=AKIAJSVQN3Z4K7MT5U2A&Expires=1341953891&Signature=jdCEiHu0nuDN3RUXYSnzPKf5N8c%3D&response-content-disposition=inline%3B+filename%3D%222011-10-05+11.05.10+am.png%22>. When you manually replace *that* URI scheme with https, it gives a certificate warning saying that the cert is from amazon s3, not droplr.
The fact that this security problem was not obvious to you suggests to me that other parts of the stack have not been carefully audited and may in fact leak unencrypted data in places, which is why I am asking for this to be an explicit feature and not a workaround :).
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.
What Glyph wanted was content served over HTTPS **when sharing**.
You upload a file, you get a link and that particular link and all its contents should also be served as https (i.e.: https://d.pr/somecode rather than http://d.pr/somecode).
I misunderstood this as "your uploads are not https" and having designed and built the backend of Droplr, the iOS app, the windows app and the network SDK for the Mac app, I was (am) pretty sure they communicate with the server using HTTPS. If you can provide contradictory evidence in any of these apps I'll have it patched within the hour.
As for apologies I trusted that Josh's reply coupled with us patching the file content being served over HTTPS a couple of hours after the discussion -- that is, d.pr is not fully served under HTTPS but the content (files, images, etc) are -- would suffice.
If Glyph felt offended or neglected in any way during our discussion, I'm sure he would have brought it up and I would have properly apologized.
Le Jul 11, 2012 à 6:49 AM, Bruno de Carvalho <[email blocked]> a écrit :
> As for apologies I trusted that Josh's reply coupled with us patching the file content being served over HTTPS a couple of hours after the discussion -- that is, d.pr is not fully served under HTTPS but the content (files, images, etc) are -- would suffice.
Yes, this is a big improvement, thanks. I do wish that there were a way I could change the automatic copy/paste URL to be https://droplr.com/ instead of http://d.pr/ though, until d.pr has HTTPS :).
> If Glyph felt offended or neglected in any way during our discussion, I'm sure he would have brought it up and I would have properly apologized.
I did not, and I appreciate you taking the time to address this issue.