Hacker News new | past | comments | ask | show | jobs | submit login
Why Instagram is so fast at uploading photos (speakerdeck.com)
259 points by daviday on May 1, 2012 | hide | past | favorite | 102 comments



Their motivation for speed is very well put:

"mobile experiences fill gaps while we wait. no one wants to wait while they wait"

Awesome quote


I absolutely agree. I now have an instinctive reaction to reach for my pocket whenever I'm feeling the slightest bit impatient, and I have caught myself on a couple of occasions reaching for my pocket when I already have my phone out, because I'm waiting for a page to load in the mobile browser.


When I reboot my computer, I very often find myself trying to cmd-tab over into Safari to browse the web while I wait for my computer to boot.


A little devil's avocate: Isn't Instagram primarily a photo sharing app? I'm not sure why people are complaining that it starts the upload on filter completion.

My only question is how long are photos not marked as user initiated uploads kept?


To me this seems way offside.

What if I, a regular user, uses instagram for taking all my photos.

What if I take nude photos of my wife. Should I really expect instagram to upload them without my permission?

I'm guessing 99% of people would not only be surprised by this behavior, but also outraged.


If you're taking nude photos of your wife with an app that is specifically known for sharing photos, you're doing it wrong.

99% of people are probably very happy that their uploads don't take 5 minutes once they hit save. To them, it's worth the privacy "risk".


Is it a privacy risk at all, though? Instagram starts uploading after you click the green check mark, which presumably says, "Hey, upload this for me," and continues uploading while you dilly-dally over the photo metadata sheet.

I'm a complete paranoid when it comes to privacy issues, and I don't see any issue with an upload that starts after I click a green check mark that, to me, means, "Hey, upload my photo, please!" There's the question of what happens to the uploaded photo on their servers when you cancel at the metadata stage, for sure, but that's a data retention question, not acquisition.


From what I've used of the Android app, there are enough warnings that notify you that the photo is being uploaded.

After taking a photo with your camera (or selecting one that you have stored locally), you get to a details page with a big button that says "UPLOAD" at the top right. So assuming that one does take naked photos of oneself or someone else, you'd have to confirm the upload. I only bring this up because FTA, the iOS screenshots just say "Done".

Now, if Instagram does indeed upload before you press the big green "UPLOAD" button, I'd say that's a breach in trust with the app.


Which is exactly how Facebook works... i.e. you select some files and then you mess around with the album properties, like date/place take, album notes and whatever else there is. Granted you need to explicitly choose the photo's in the first place, but that's the green button you speak of.


"You look nice and everything, Honey, but you could use an Instagram filter."


No, you're not. Several answers of this sort, ignoring the expectation that apps to disseminate information without your permission. This is a general expectation, but in particular on iOS there is a clear tilt towards ensuring the user is happy with such actions.

You know that Instagram can load photos from your camera roll, right? "what would this nude photo look like with that filter?" is a common use-case, I'd guess. And a strong expectation that it would not be sent to an outside party as a result.


That's a pretty damn presumptuous thing to say... have you seen any studies or conducted one yourself where people admitted to leaning towards user-experience benefits about online photo sharing at the expense of privacy?

I agree with your point though that users have a responsibility to figure out the objective of the app in order to understand the context of its intended use.


I think Facebook is an excellent piece of evidence that users are generally concerned about UX over security.

Just because you and I are are thinking about security, doesn't mean most people are. And I don't even feel like this is a horrible thing for Instagram to do. It is an app specifically for uploading and sharing photos.


There are concrete studies (search Acquisti) that shown Facebook users have a big disconnect between what they want as privacy and what they do. And that disconnect has , in more than one top journal papers, been attributed to a lack of total grasp of the privacy settings and its implications by the common public. So I think one should refrain from making bold claims like "users are generally concerned about UX over security" (I believe you meant privacy and not security).

I totally agree with the philosophy behind your claim that users see privacy as part of a utility function where sometimes the value of the experience trumps privacy controls and it also depends on the value one attaches to the information he/she is sharing. So from that perspective, especially given the publicly accepted norm that everything on instagram is public (like in Twitter), this "privacy calculus" will probably work out in favor of Instagram's decision here. And yes, it is not a horrible thing for them to be doing either.

But it does break the trust for those who are accustomed to the connotations of certain UI features (like "Done" button and progress bar).

Instagram will get away with this, but if somebody with a less trust level was engaging in such pre-"Done" uploading activity, there would be pushback. What I fear is that the co-founder by sharing this with the developers community will encourage this behavior in other startups/apps and this will then become an industry best practice even for the shady apps (just like it did for the address book).


You probably wouldn't use Instagram for taking all your photos.

On the iPhone at least, it only saves photos if you post them. You wouldn't be able to use it as a camera for private photos unless you didn't want to keep them.

There is one work around - you can get it to save the photo if the upload fails, so if you put your phone in airplane mode, you can take a private photo. Apart from that, Instagram only works as a sharing app, not a general camera. I think since it works this way, 99% of people won't care.


> On the iPhone at least, it only saves photos if you post them.

Ah, if that's the case, then this seems much better.

I was under the assumption that photo's were uploaded after being taken.

If the user has to explicitly say, "Upload this picture" and only then does the upload start, then this seems to be much better.


The Android version saves all the photos I've taken with Instagram locally. Of course I don't know whether there are copies of these images on their servers, not published to my public stream, as the app doesn't show anything like that.


It saves the local copy after you apply a filter, so at the same time it is uploaded but probarbly before the user is "finished" with the upload process (screen 2 after applying filter is to add a caption, and while that is happening the photo is uploaded).

But then again that is like writing erotic short stories in your twitter apps drafts and be outraged that they are saved online.


"writing erotic short stories in your twitter"

OT: If there isn't a novelty twitter account for this I'm disappointed.


Instagram is a photo sharing service. They've never hidden that aspect. The default user expectation is uploading and sharing. I don't see why immediately initiating the upload would be unexpected for the user.


Because, uploading before pressing the "save this publicly" button is counter-intuitive to most people. Much like if texts were sent before I pressed the send button -- until i press that button there is the option to change my mind, edit what i say, etc. This is the mental model most people will have, way more so when presented with a "publish" button (akin to a send mms button).


> Much like if texts were sent before I pressed the send button -- until i press that button there is the option to change my mind, edit what i say, et

Except that analogy doesn't fit. Other users cannot see, nor do you see on your account, the uploaded-but-not-explicitly-published photo. It only appears publicly when you choose for it to be.

A text message that was sent before you pressed the send button would have to be held at an intermediate (such as BBM servers or iMessage servers), and of course makes little sense due to the size of a text vs. the size of a photo.


I understand the technical aspects of it. There is still no guarantee that they delete the photo. They say they do, and I don't seriously doubt them, but the possibility exists that they keep them around for whatever reason. Further, there is a real possibility that an attacker could find a way into the Instagram systems or hijack the communication streams between users and the servers, and then you have a leak. It is a potential privacy concern that is caused by the "upload everything and throw away some of them" algorithm.


If you take nude photos of your wife, you're using the wrong app and you know it. Also, what's your Instagram user name?


There is a difference between upload and publish. The app might be uploading the photo in the background, but that's to get it over the wire to instagram. The publish isn't being made (aka, the photo being visible to anyone) until you complete the upload process.


They're uploaded once you get to the caption screen, not when you take the photo.


Uploaded doesn't mean it's permanently stored, it only means that part of the file might have been uploaded already by the time you confirm the upload.

If your intention was in fact to upload the photo, good on you, you save a few precious seconds. If your intention was not to upload the photo, then they simply cut the connection, send a delete order and move on.


Does it bother you if no one ever sees those images that are uploaded?


True. But there's a disconnect between the common person's understanding of the process and what's happening. It matters because it's user content.

As for the deletion, who knows. They could say anything and the users would have no way to tell unless they slip up.


> I'm not sure why people are complaining that it starts the upload on filter completion.

If it put responsiveness before everything else, it could even start uploading before the filters are applied and apply the filters server-side when they are validated.

While this would significantly increase server load (and duplicate the work, as filters would be applied both by the phone and by the server), it would make the visible upload window even lower (or even not exist at all).


So Instagram has photos I don't click "upload" on. Well that's nice to know.

Edit: So I tried to use a proxy on my phone but it looks like Instragram on Android doesn't honour the wireless proxy server. Anyone else want to do some digging?


On slide 89 it mentions that they delete the data if the user cancels it.


And of course they do. They respect user choice and privacy. Whilst you can be all tin-foil hat and think they are going to keep these "cancelled" photos, I would seriously doubt it.


People also doubted that Facebook retained deleted profiles a number of years ago. Is this an unhealthy opinion to form in an age of growing "cloud" data?


Do they also delete photos from a backend database backup that might've occurred after the upload but before the user cancelled the photo?


The photo isn't store in a database. It's stored on S3. They are not backing up S3, so this concern is misplaced.


Ha, I love the HN reaction to this. Sperging out about Instagram getting photos they're "not supposed to", fake outrage about fake privacy breaches, all while blatantly ignoring this fact.

And of course, I'm sure all this fake outrage has nothing to do with Instagram's recent purchase by Facebook.


If you don't select upload then they can either stop the process if the photo hasn't been uploaded yet OR if its complete then they can send a signal and delete a photo.

But yeah its waste of bandwidth for the user if he decides against uploading the photo.


I imagine they start uploading when you click the greet "tick" button.


Exactly. All this outrage about photos being uploaded without permission is overblown, because tapping the green check button is just the same as clicking a submit button. Instagram just separates the upload process from the process for setting the photo's metadata, which is very intelligent and more efficient.


It isn't submit it's "upload". And it is only overblown outrage now that we know the facts right?


The easy technical workaround would be to pre-send the photos encrypted with a random key, and only send the key after you explicitly click "upload". At least that way you could verify with a proxy that they were, in fact, not seeing photos you haven't sent them the keys for.


Good idea.. they should do this.. Maybe the encryption is too "heavy" for mobile phones? (uses too much battery ore whatever) ?


Or maybe it's just extra work and complexity that so few of their users actually care about.


I don't think that's playing dirty at all. I think it's quite clever.


Gmail used to do that with their attachment. You choose the attachment, and it silently starts to upload. Most applications wait for you to hit "Send" to start uploading.


It used to. It still does, but it used to, too.


Thank you, Mitch Hedberg. Also, and strangely appropriate for an Instagram thread:

One time, this guy handed me a picture of him, he said,"Here's a picture of me when I was younger." Every picture is of you when you were younger. "Here's a picture of me when I'm older." "You son-of-a-bitch! How'd you pull that off? Lemme see that camera... what's it look like?“


There was a progress bar that shows that the progresses of the file upload. It was not secret.


There still is the progress bar.


Chrome does the same, when you right-clic on a file and select "Save as…", the download begin in a temporary file, and then when you select the emplacement where you want to put the new file, it moves the temporary file in it.


I don't know a browser which does not do that. They need to start the download to get the metadata (file name and type), and they'll do it if only because shitty servers may react very badly to the browser just stopping with a full socket buffer.


They don't need to start it to get the metadata. All that's sent is the content-disposition header with the suggested file name.


> They don't need to start it to get the metadata. All that's sent is the content-disposition header with the suggested file name.

That is the start, unless you perform a HEAD followed by a GET (which takes 2 round-trips instead of one and may not even be correctly supported). And because any link can lead to that, every single link you click would have to be implemented via 2 round-trips, that's complete madness.

> All that's sent is the content-disposition header with the suggested file name.

Nonsense, there is no situation in which "all that's sent is the content-disposition header", that header is part of a full header section and immediately precedes the content itself.


Right you are. This is why I shouldn't comment before coffee.


Firefox does that too.


Firefox.. since nightly 15 i think also does stuff like, when you go to the search box, it open the connection to the http server before sending the search request i believe chrome does it too


Even IE6 did it.


I'm not an Instagram user, so I may be off base... but why not start uploading the photo right when the user snapped it, i.e. before selecting a filter. Then apply the selected filter server-side on the original photo. That way you save a few more seconds while the user is selecting the filter.


Image manipulation on a large scale is expensive. Leaving it up to the user's device to run the image through filters eliminates server strain.


Definitely the case especially since they were on Amazon, and thus had to pay for EC2 minutes.

Now that they're at Facebook, server load shouldn't be a problem anymore though. So they could implement that.


What about sending a video stream to the server and then when you hit the button it just sends a timestamp that determines which frame to extract on the server and delete the unneeded ones?

The future is going to be sweeeeeet.


Problem there is quality of the image.


for previewing each filter's effects, this would require constant downloads of the processed images off the server in addition to the initial upload


No it wouldn't. You could run the filter on the client, then finally run it on the server when their choice is made.


Does anyone know what the sign up slide is about (http://speakerdeck.com/u/mikeyk/p/secrets-to-lightning-fast-...)? Do they create a user account when you hit the form, then fill it in with your details asynchronously later?


I think they're preloading the 'suggested' photos and data.


that's probably when they were uploading all your contacts info so they could suggest friends to you...


I assumed this was the case because the "time since" label on a freshly posted photo is usually between 10-20 seconds, indicating they had my photo well before I tapped "Done." I think it's a pretty genius little UX hack to make the process feel quick.


The Google+ Android app does basically the same thing. It syncs everything from your camera to the cloud (configurable, but I believe the default is to sync always when on wifi), where you can choose to share them at your leisure. It's actually really handy. My wife is routinely not uploading cute kid photos to Facebook from her iPhone because it's too much of an annoyance (or because she doesn't want to compose the text to go with it). I can do it at my desktop whenever the mood hits me.


It's important to mention that when you install the Google+ app one of the configuration steps asks if you want to auto-upload your photos. You have three options: "Upload over wifi only", "Upload over wifi and mobile", and "Don't automatically upload". I believe the default is wifi-only.

You can turn it off later in the settings quite easily.


Everything he says is completely applicable to online games. Online games need to be designed around responsiveness. Another way to put it: the online game design should be pervasively focused on creating the illusion of low/no latency.

An example in an online game I'm designing: damage and deaths are finalized with a one second delay. This way, the clients can optimistically render ships and combat effects, but everything is still verified/finalized on the server.


I found it brilliant first time I founded that out myself. It's more like improving user's experience from their end.


Where in the TOS does it allow them to upload photos that the users don't explicitly select?


The user does explicitly either take the photo inside the Instagram app or select it. Note that the final button that published the photo to the user’s stream is labeled Done, not Upload. They don’t just arbitrarily upload photos from the camera roll or from the camera before the user has tapped the camera shutter button.

EDIT: And as others have pointed out, photos are only uploaded after the user has selected a filter and tapped the green check mark, not as soon as they are taken.


On the Android version it says Upload instead of Done. I can't tell what point it starts uploading but it seems to appear pretty quick on my page.


I think it's assumed that you are going to post any photos you take when you use Instagram - as the app doesn't actually save photos to your phone unless you post it (or if the upload fails).

I would understand the concern if it acted like a camera app - ie, you take a photo, it's saved to your phone's photostream, and afterwards you can choose to hit upload, but since you can't use it in that way (it's either post it or the photo is gone) I don't really see a problem.


I just had a skim through and I can't see anything under T&S nor in the Privacy Policy.


I've always wondered why client side resizing isn't more popular, it would give a major edge over any web upload.


I'm pretty sure they do client side resizing as well.


This is such a great deck. Unless you're working on a photo sharing app, this slide might offer more generally useful advice:

http://speakerdeck.com/u/mikeyk/p/secrets-to-lightning-fast-...


I'm really surprised by the number of commenters who didn't figure this out already?


Yes. Any other questions?


FYI Google instant (which is integrated, at least in AOSP) or smth does the same, by default. That is it uploads your pictures instantly to Google picture thingy. You can turn it off thanksfully.


Doesn't that mean they actually start grabbing the photos before really getting permission from the user?

Surely they probably got it covered in the Terms, but it still strikes me as playing slightly dirty..


Tapping the green checkmark isn't enough permission?


Playing the Devil's advocate (IANOCoder), but perhaps the bulk of the 1s&0s are being uploaded and then decrypted by sending a small string when the user selects "publish"?

Probably not.


That's a little silly. How is trusting them to correctly implement an encryption scheme terribly different from trusting them to responsibly delete aborted photos in the first place?


That would be the responsible way to do it, surely, although they should still mention it in the TOS.


Did Instagram v1 had this feature?

They added high-res photos in v2 and the early upload seems like maybe an attempt not to have the app start feeling much much slower.


Surprised most are concerned on privacy grounds. My first thought was, wow this could chew up many users monthly bandwidth quotas.


I have just realised that Intagram have an abundance of phallus photos that were never intended for upload!


The iOS SDK I'm building at work ultimately does the same thing. Much better UX.


We used the same idea with video uploads.


It's the little things...


I always suspected that.


I though it was slow


Why is Speakerdeck polluting my back history? :(


I trust Instagram to not engage in monkey business with my data. Having said that, this is flirting with the path-address-book kind of privacy-related scrutiny. There has to be a way of telling the user at WHAT POINT the data has started uploading. The progress bar of photo uploads has to mean what it shows or else it is a plain and simple deception (even if it's in the name of performance and user experience). I can't tell if this will erode trust though but don't be surprised if a few make a loud noise about it.

Privacy concern and trust form a chicken-egg problem. I wish the Stanford-esque brains behind these tech companies had a better grasp on it.


> I trust Instagram to not engage in monkey business with my data.

Do you trust Facebook to the same extent?


Actually yes I do trust them to the same extent. But that's a choice I have made based on my perceived trust level. I am even OK with advertisers harvesting my photos (not sure if that is possible yet). My main desired privacy control is whether people that are not supposed to see my photos or browse through my galleries, actually get to do that. That's not necessarily a monkey business but an outcome of a privacy implementation flaw (assuming it is unintentional). That will certainly have an impact on my trust level for Facebook. The difference with instagram is that you go into instagram knowing that everything is public and so is the general sharing norm on that platform.


Seriously, why is this on hacker news? This is ridiculous. I'd downvote this if we were on reddit. :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: