https
Glyph
Do you have plans to supply HTTPS support so the file is encrypted at least between me and droplr? (Of course it would be nice for it to be encrypted the whole way to the people I'm sharing with, but I realize that might be a kind of crazy peer-to-peer technology problem.)
Comments are currently closed for this discussion. You can start a new one.
Support Staff 2 Posted by Bruno de Carvalho on 07 Jul, 2012 12:16 PM
I'm not sure what you mean, the whole Droplr stack runs on HTTPS only.
Bruno de Carvalho closed this discussion on 07 Jul, 2012 12:16 PM.
Glyph re-opened this discussion on 07 Jul, 2012 11:47 PM
3 Posted by Glyph on 07 Jul, 2012 11:47 PM
Ah, I was a bit confused by the UI in Safari. The problem is not that there's no HTTPS, it's mixed content, so HTTPS isn't actually doing anything useful.
For starters the cert for https://d.pr/ is just wrong; it's publishing the *.droplr.com cert.
Support Staff 4 Posted by Bruno de Carvalho on 10 Jul, 2012 02:02 PM
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 content).
Bruno de Carvalho closed this discussion on 10 Jul, 2012 02:02 PM.
Glyph re-opened this discussion on 10 Jul, 2012 08:33 PM
5 Posted by Glyph on 10 Jul, 2012 08:33 PM
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 :).
Thanks for your consideration.
Support Staff 6 Posted by Bruno de Carvalho on 10 Jul, 2012 08:56 PM
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.
Cheers.
Bruno de Carvalho closed this discussion on 10 Jul, 2012 08:56 PM.
Glyph re-opened this discussion on 10 Jul, 2012 09:03 PM
7 Posted by Glyph on 10 Jul, 2012 09:03 PM
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 :).
Thanks for your continued attention, though.
Support Staff 8 Posted by Bruno de Carvalho on 10 Jul, 2012 09:10 PM
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.
Thanks for raising this subject.
Bruno de Carvalho closed this discussion on 10 Jul, 2012 09:10 PM.
Josh Bryant re-opened this discussion on 11 Jul, 2012 12:19 AM
9 Posted by Josh Bryant on 11 Jul, 2012 12:19 AM
Glyph,
Apologies we didn't meet your expectation on this. We've committed an update that serves all content over HTTPS.
We'll work on getting the pages themselves over HTTPS as well in the near future.
Sorry for your troubles but hopefully you'll give us another shot. Thanks for your patience and support.
Cheers
10 Posted by Jo Denson on 11 Jul, 2012 11:19 AM
Josh, thanks for sorting this issue out. Can you take some time to explain why Bruno de Carvalho says
"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 this was clearly not true?
And then when he is shown that it is not true, he does not apologies or admit the mistake?
Support Staff 11 Posted by Bruno de Carvalho on 11 Jul, 2012 01:49 PM
Jo,
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.
Cheers.
12 Posted by Glyph on 11 Jul, 2012 08:58 PM
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.
Bruno de Carvalho closed this discussion on 17 Jul, 2012 12:13 AM.