5 ms·

Instagram iOS session hijack

132 points by sjtgraham 12y ago

minimaxir 12y ago
Relevant comment: @wodim I adhered to the FB responsible disclosure procedure. FB replied saying they're already aware of the issue and closed the ticket.
- InAnEmergency 12y ago
  "Closed the ticket" as what, though? "Duplicate, working on fixing" or "won't fix"? Because those are pretty different...
  - Sephr 12y ago
    Duplicates of non-public security vulnerabilities should be treated the same as the original reports (including the same rewards consideration process), especially if it was independently discovered. An unfixed security vulnerability is still an unfixed security vulnerability, no matter how many people discover it in the interim. By refusing to coordinate with the new submitter, the new submitter does not know if the vulnerability will ever be fixed and is reasonably justified in using public disclosure. The one case where refusing to coordinate with the new submitter is reasonable is when the new submitter learned about the vulnerability from the original submitter, which means that the original submitter has violated responsible disclosure. In that case, nobody would deserve a reward.
    - oneweirdtrick 12y ago
      So if it's marked as a duplicate, the original submitter loses visibility and is not even followed up with on whether there was a resolution? Is there a way to include an outside submitter on an original ticket or bug filed internally? I am pretty much clueless on the standard procedure of most big tech companies when it comes to these things.
      - InAnEmergency 12y ago
        As example, HackerOne allows you to link duplicate reports to the original, and all reporters are "thanked" when the issue is resolved. But I think in many cases reporters of duplicate issues do not get any follow up.
    - InAnEmergency 12y ago
      > Duplicates of non-public security vulnerabilities should be treated the same as the original reports (including the same rewards consideration process), especially if it was independently discovered. This is rare for bug bounty rewards. All the programs I am aware of only reward the first reporter. > By refusing to coordinate with the new submitter, the new submitter does not know if the vulnerability will ever be fixed and is reasonably justified in using public disclosure. That's kind of what I'm pointing out here. We are missing information about what Facebook actually said and when it was said. The "we already know about it" response could mean "we know about it and are working on fixing it" or it could mean "we know about it and we don't care". In the former case, it is not responsible to publicly disclose the issue until it is fixed. In the later, it is. A separate scenario is if the company is taking a long time to fix the issue. This is obviously subjective, but in my opinion it is understandable for a reporter to publicly disclose a long-standing issue in an attempt to force the company to act.
      - danielweber 12y ago
        Yes, rewards to every submitter basically lead to the first guy telling N of his friends to all claim the bounty, too. It sucks to work for dozens of hours on something and then find out they already know about it, but the other option just leads to there being no bounties at all.
NietTim 12y ago
Same goes for Android http://thehackernews.com/2014/07/instagram-mobile-app-issue-leads-to_27.html http://thehackernews.com/2014/07/instagram-mobile-app-issue-...
captn3m0 12y ago
I recently found that a very popular web-service serves its api console over HTTP, rendering all API keys vulnerable to MITM. I sent over a mail to their security issues mail address. Still waiting for a response. Step 1 of securing an API: Use SSL.
- deleted 12y ago
  [deleted]
pgrote 12y ago
I found a way to hijack someone's instagram account by accident. All it took was signing up for Facebook. Never could get any traction with Instagram to look into the issue.
- greggarious 12y ago
  Maybe try FB's bug bounty program? https://www.facebook.com/whitehat https://www.facebook.com/whitehat
thegeomaster 12y ago
I remember when back in the day Facebook didn't default to HTTPS. You could just put your 802.11 card to monitor mode, power up ettercap in an area where there are a lot of unencrypted WiFi packets flying around, and easily you have dozens of session cookies. Script-kiddie level. More interesting would be to take over a network (MITM style) and set up iptables to route all connections to Facebook IP's to a local webserver (DNAT target helps). Then you host a phishing FB page and soon you have logged emails and passwords from unsuspecting users. I think this can actually work even if Facebook does default to HTTPS, because users never actually reach Facebook itself.
- callahad 12y ago
  > I think this can actually work even if Facebook does default to HTTPS, because users never actually reach Facebook itself. If the user has successfully reached Facebook in the past 90 days, then their browser will have seen FB's HSTS header, and refuse to connect without TLS... provided they're not browsing with IE. :(
- aptwebapps 12y ago
  "I think this can actually work even if Facebook does default to HTTPS, because users never actually reach Facebook itself." The certificate won't match. I don't know how many users will click past the big red warning page most browsers show, but I don't have much sympathy for them if they do.
  - thegeomaster 12y ago
    I was referring to serving an ordinary HTTP page on port 80. Most people type facebook.com into the address bar and hit Enter (and don't have HTTPSEverywhere). In normal circumstances, Facebook would issue a redirect to https://facebook.com https://facebook.com, but if you're controlling the network you just serve the front page via HTTP.
    - aptwebapps 12y ago
      Yes, I suppose that might work at least some of the time. Most browsers these days, however, would send you to the https site simply because you had visited it more frequently unless you typed out the full url and managed not to select the offered completion.
sjtgraham 12y ago
OP here. I discovered this years ago. I suspect it has been extant for as long as Instagram itself. I actually posted a comment about this 216 days ago! (https://news.ycombinator.com/item?id=6959472 https://news.ycombinator.com/item?id=6959472). When I checked again on Saturday, I couldn't believe my eyes when it I saw it still hadn't been fixed. I reported it to FB immediately, to which they responded it's been reported "some" times and the Instagram team were working on moving all endpoints to HTTPS and they closed the ticket without further discussion. I was incensed that such a fundamental and critical flaw was allowed to exist for so long. Because of this I decided public disclosure was justified.
- sjtgraham 12y ago
  The reply from Facebook: "Hi Stevie, This issue has been reported some already so unfortunately cannot reward you, instagram is working to get https for all endpoints. Its a pretty high barrier to exploitation to already sniffing someones traffic however. Thanks, name removed Security Facebook" And here I am sitting in the Apple Store around the corner from my apartment watching various cookies whizz past my screen. I don't agree the barrier to exploit is high. All it takes is one sufficiently skilled person to release a tool so simple even a script kiddie can use it. At that point Pandora's Box has been blown apart. The obvious precedent for this is Firesheep (now sadly not functional) from back in 2010.
  - smtddr 12y ago
    >>"All it takes is one sufficiently skilled person to release a tool so simple even a script kiddie can use it" And that's why this was made :-)... http://en.wikipedia.org/wiki/Firesheep http://en.wikipedia.org/wiki/Firesheep Maybe you should contribute instagram-sniffing to it :) https://github.com/codebutler/firesheep https://github.com/codebutler/firesheep
    - sjtgraham 12y ago
      Thanks, I referenced Firesheep in the grandparent. FS is currently very broken. I still couldn't get it to work after downloading the source and making some changes. The OS X API used by FS has long been deprecated and simply doesn't work on Mavericks. If there is enough interest I will write "Instasheep" this evening.
yeukhon 12y ago
So let me get this straight: this is just the classic non-HTTPS traffic sniffing. I am not sure why Instagram isn't moving all calls to HTTPS. Instagram itself is not as complicated as Facebook and shouldn't really be bounded to HTTP so badly. They can easily do 301/302 redirect to HTTPS, then perform HSTS (for browser, not for API calls) in addition and let the proxy like nginx handles it to their usual port 80 requests. Problem solved. How much more work do they need to do to shift from HTTP to HTTPS? I just don't get it.
- frik 12y ago
  Instagram run on Amazon AWS, though Facebook finally moved Instagram to their own datacenters (as of June 2014) where FB use SSL hardware cards (cheaper than CPU and ELB for SSL on AWS). We also terminate our SSL at the ELB level, which lessens the CPU load on nginx. -- http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of http://instagram-engineering.tumblr.com/post/13649370142/wha... http://www.zdnet.com/instagram-finally-picked-up-and-moved-from-aws-to-facebook-7000031014/ http://www.zdnet.com/instagram-finally-picked-up-and-moved-f... http://instagram-engineering.tumblr.com/post/89992572022/migrating-aws-fb http://instagram-engineering.tumblr.com/post/89992572022/mig...
sneak 12y ago
Full and public disclosure is always responsible. STOP USING THE TERM RESPONSIBLE DISCLOSURE. It serves only to frame full, public disclosure as "irresponsible disclosure", which is false.
- kcbanner 12y ago
  agreed
- yeukhon 12y ago
  No it is not in different situation. If I tell you your social security number is now accidentally written in your HTML file (probably because you copied and pasted the wrong thing), and now I tell the world "hey come look at sneak's SSN" instead of waiting for you to resolve is wrong. Now back to this gist. Is he responsible? It depends on how the situation was played out. Based on what OP said: * He found this 216 days ago and wrote about it as a comment on HN * He didn't say whether he reported that day but he recalled Instagram was making HTTP request a year prior to that day he wrote the comment * He didn't tell us when he report this issue to FB. Yesterday? Last week? * FB said they are aware of this situation and closed the ticket. Like someone else said here, "closing" has different meanings. I've never reported any vuln to FB so I don't know how that works. But on HackOne, particpating program can close a ticket and set the ticket to "Not Applicable" meaning someone else has already reported. So the decision factor is: * when was the first report submitted by OP? Yesterday? Last week? 3 months ago? 216 days ago? * if it was very recent, OP doesn't know the exact time the last duplicate report was sent out. Give FB a little more time and ask FB again in a week or so. I did say in my other comment fixing this issue should be pretty trivia for Instagram as an outsider, but I also should acknowledge any major change to infrastructure should have a proper audit and roll out. edit: One last point. If OP thinks he's doing the right thing, let it be. There are too many things unknown to me so I am just listing all the possible consideration. I have tons of bug bounty reports unfixed for 3 months on various sites and I still email those sec teams back and forth to look at progress. It's an individual decision and with every decision comes a consequence to bear.
  - sneak 12y ago
fdsary 12y ago
I'm trying to reproduce this on a macbook. I'm a developer, not a networks guy so please excuse me for not knowing the basics! After doing `sudo tcpdump -In -i en0 -s 2048 -A dst i.instagram.com`, and using every instagram feature from my iPhone, nothing happens in the terminal. ``` tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 2048 bytes ``` I try running with -v and -vv, but no difference (except it doesn't suggest running in verbose more). After hitting C-c to stop the program, it outputs ``` ^C 0 packets captured 29816 packets received by filter 0 packets dropped by kernel ``` So there's a lot of things being captured, but the filter does not catch my Instagram activity. I'm logged in there, refreshing, getting images, getting followers/following, etc. EDIT: oh shit, HN doenst do markdown. That sucks.
- piratebroadcast 12y ago
  Same exact thing happening to me. I'm loading friends pages, liking photographs, and getting nothing.
- na85 12y ago
  HN does some minimal formatting. You can add emphasis to text with asterisks You can also prepend your lines with two spaces for pre-formatted text/code
- rdrey 12y ago
  The gist doesn't show how to get your network card into monitor/promiscuous mode. EDIT: I'm not sure -In work with default drivers, but I'll test with my private Mac at home later.
- deleted 12y ago
  [deleted]
- tmops 12y ago
  Well, are you connected to the same open wireless network as the iPhone, and are within close range of it? This isn't going to work on an WPA network. Try taking off your "dst i.instagram.com" filter and see what you're actually capturing.
13throwaway 12y ago
Websites need to start taking more responsibility with HTTPS. Reddit, and a few other popular sites can also have their sessions hijacked.
- skeletonjelly 12y ago
  reddit was quick to patch the heartbleed bug, but I got downvoted when I put forward that it wasn't a big deal as HTTP is probably 99.99% of traffic.
0xeeeeeeee 12y ago
I reported this issue a long time ago. Got the same messages back from facebook as everyone else in the thread. I've reported other issues and always get the same thing back. It sounds like Facebook Security gets a lot of pushback from the developers. Certain things like coffee shop attacks and a lot of other REAL ISSUES get no notice for a long time. It took up until last year to get a damn HSTS header. I actually reported an issue today about a security practice they implemented completely incorrectly. I got a response back that it was not meant for any actual security. In theory it's unacceptable, but in practice this is a big company with thousands of employees and a lot of moving parts. Small changes can be hard to make....which to get back to my original point is why facebook seems to just ignore a lot issues but keep the pipes open for the occasional big one.
Ryel 12y ago
Every couple of months one of my friends insists that she's "quitting Instagram" because of how often things go wrong on the platform. Several times a month she gets logged into someone else's account with full read/write/update access and I believe even gets access to their Facebook. Between the above, the 4+ accounts she's has deleted for no reason, and the bugginess of often having a blank UI, it's becoming harder and harder to enjoy browsing on Instagram.

132 points by sjtgraham 12y ago

Relevant comment: @wodim I adhered to the FB responsible disclosure procedure. FB replied saying they're already aware of the issue and closed the ticket.

InAnEmergency 12y ago
"Closed the ticket" as what, though? "Duplicate, working on fixing" or "won't fix"? Because those are pretty different...
- Sephr 12y ago
  Duplicates of non-public security vulnerabilities should be treated the same as the original reports (including the same rewards consideration process), especially if it was independently discovered. An unfixed security vulnerability is still an unfixed security vulnerability, no matter how many people discover it in the interim. By refusing to coordinate with the new submitter, the new submitter does not know if the vulnerability will ever be fixed and is reasonably justified in using public disclosure. The one case where refusing to coordinate with the new submitter is reasonable is when the new submitter learned about the vulnerability from the original submitter, which means that the original submitter has violated responsible disclosure. In that case, nobody would deserve a reward.
  - oneweirdtrick 12y ago
    So if it's marked as a duplicate, the original submitter loses visibility and is not even followed up with on whether there was a resolution? Is there a way to include an outside submitter on an original ticket or bug filed internally? I am pretty much clueless on the standard procedure of most big tech companies when it comes to these things.
    - InAnEmergency 12y ago
      As example, HackerOne allows you to link duplicate reports to the original, and all reporters are "thanked" when the issue is resolved. But I think in many cases reporters of duplicate issues do not get any follow up.
  - InAnEmergency 12y ago
    > Duplicates of non-public security vulnerabilities should be treated the same as the original reports (including the same rewards consideration process), especially if it was independently discovered. This is rare for bug bounty rewards. All the programs I am aware of only reward the first reporter. > By refusing to coordinate with the new submitter, the new submitter does not know if the vulnerability will ever be fixed and is reasonably justified in using public disclosure. That's kind of what I'm pointing out here. We are missing information about what Facebook actually said and when it was said. The "we already know about it" response could mean "we know about it and are working on fixing it" or it could mean "we know about it and we don't care". In the former case, it is not responsible to publicly disclose the issue until it is fixed. In the later, it is. A separate scenario is if the company is taking a long time to fix the issue. This is obviously subjective, but in my opinion it is understandable for a reporter to publicly disclose a long-standing issue in an attempt to force the company to act.
    - danielweber 12y ago
      Yes, rewards to every submitter basically lead to the first guy telling N of his friends to all claim the bounty, too. It sucks to work for dozens of hours on something and then find out they already know about it, but the other option just leads to there being no bounties at all.

NietTim 12y ago

Same goes for Android http://thehackernews.com/2014/07/instagram-mobile-app-issue-leads-to_27.html http://thehackernews.com/2014/07/instagram-mobile-app-issue-...

captn3m0 12y ago

I recently found that a very popular web-service serves its api console over HTTP, rendering all API keys vulnerable to MITM. I sent over a mail to their security issues mail address. Still waiting for a response. Step 1 of securing an API: Use SSL.

deleted 12y ago
[deleted]

pgrote 12y ago

I found a way to hijack someone's instagram account by accident. All it took was signing up for Facebook. Never could get any traction with Instagram to look into the issue.

greggarious 12y ago
Maybe try FB's bug bounty program? https://www.facebook.com/whitehat https://www.facebook.com/whitehat

thegeomaster 12y ago

I remember when back in the day Facebook didn't default to HTTPS. You could just put your 802.11 card to monitor mode, power up ettercap in an area where there are a lot of unencrypted WiFi packets flying around, and easily you have dozens of session cookies. Script-kiddie level. More interesting would be to take over a network (MITM style) and set up iptables to route all connections to Facebook IP's to a local webserver (DNAT target helps). Then you host a phishing FB page and soon you have logged emails and passwords from unsuspecting users. I think this can actually work even if Facebook does default to HTTPS, because users never actually reach Facebook itself.

callahad 12y ago
> I think this can actually work even if Facebook does default to HTTPS, because users never actually reach Facebook itself. If the user has successfully reached Facebook in the past 90 days, then their browser will have seen FB's HSTS header, and refuse to connect without TLS... provided they're not browsing with IE. :(
aptwebapps 12y ago
"I think this can actually work even if Facebook does default to HTTPS, because users never actually reach Facebook itself." The certificate won't match. I don't know how many users will click past the big red warning page most browsers show, but I don't have much sympathy for them if they do.
- thegeomaster 12y ago
  I was referring to serving an ordinary HTTP page on port 80. Most people type facebook.com into the address bar and hit Enter (and don't have HTTPSEverywhere). In normal circumstances, Facebook would issue a redirect to https://facebook.com https://facebook.com, but if you're controlling the network you just serve the front page via HTTP.
  - aptwebapps 12y ago
    Yes, I suppose that might work at least some of the time. Most browsers these days, however, would send you to the https site simply because you had visited it more frequently unless you typed out the full url and managed not to select the offered completion.

sjtgraham 12y ago

OP here. I discovered this years ago. I suspect it has been extant for as long as Instagram itself. I actually posted a comment about this 216 days ago! (https://news.ycombinator.com/item?id=6959472 https://news.ycombinator.com/item?id=6959472). When I checked again on Saturday, I couldn't believe my eyes when it I saw it still hadn't been fixed. I reported it to FB immediately, to which they responded it's been reported "some" times and the Instagram team were working on moving all endpoints to HTTPS and they closed the ticket without further discussion. I was incensed that such a fundamental and critical flaw was allowed to exist for so long. Because of this I decided public disclosure was justified.

sjtgraham 12y ago
The reply from Facebook: "Hi Stevie, This issue has been reported some already so unfortunately cannot reward you, instagram is working to get https for all endpoints. Its a pretty high barrier to exploitation to already sniffing someones traffic however. Thanks, name removed Security Facebook" And here I am sitting in the Apple Store around the corner from my apartment watching various cookies whizz past my screen. I don't agree the barrier to exploit is high. All it takes is one sufficiently skilled person to release a tool so simple even a script kiddie can use it. At that point Pandora's Box has been blown apart. The obvious precedent for this is Firesheep (now sadly not functional) from back in 2010.
- smtddr 12y ago
  >>"All it takes is one sufficiently skilled person to release a tool so simple even a script kiddie can use it" And that's why this was made :-)... http://en.wikipedia.org/wiki/Firesheep http://en.wikipedia.org/wiki/Firesheep Maybe you should contribute instagram-sniffing to it :) https://github.com/codebutler/firesheep https://github.com/codebutler/firesheep
  - sjtgraham 12y ago
    Thanks, I referenced Firesheep in the grandparent. FS is currently very broken. I still couldn't get it to work after downloading the source and making some changes. The OS X API used by FS has long been deprecated and simply doesn't work on Mavericks. If there is enough interest I will write "Instasheep" this evening.

yeukhon 12y ago

So let me get this straight: this is just the classic non-HTTPS traffic sniffing. I am not sure why Instagram isn't moving all calls to HTTPS. Instagram itself is not as complicated as Facebook and shouldn't really be bounded to HTTP so badly. They can easily do 301/302 redirect to HTTPS, then perform HSTS (for browser, not for API calls) in addition and let the proxy like nginx handles it to their usual port 80 requests. Problem solved. How much more work do they need to do to shift from HTTP to HTTPS? I just don't get it.

frik 12y ago
Instagram run on Amazon AWS, though Facebook finally moved Instagram to their own datacenters (as of June 2014) where FB use SSL hardware cards (cheaper than CPU and ELB for SSL on AWS). We also terminate our SSL at the ELB level, which lessens the CPU load on nginx. -- http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of http://instagram-engineering.tumblr.com/post/13649370142/wha... http://www.zdnet.com/instagram-finally-picked-up-and-moved-from-aws-to-facebook-7000031014/ http://www.zdnet.com/instagram-finally-picked-up-and-moved-f... http://instagram-engineering.tumblr.com/post/89992572022/migrating-aws-fb http://instagram-engineering.tumblr.com/post/89992572022/mig...

sneak 12y ago

Full and public disclosure is always responsible. STOP USING THE TERM RESPONSIBLE DISCLOSURE. It serves only to frame full, public disclosure as "irresponsible disclosure", which is false.

kcbanner 12y ago
agreed
yeukhon 12y ago
No it is not in different situation. If I tell you your social security number is now accidentally written in your HTML file (probably because you copied and pasted the wrong thing), and now I tell the world "hey come look at sneak's SSN" instead of waiting for you to resolve is wrong. Now back to this gist. Is he responsible? It depends on how the situation was played out. Based on what OP said: * He found this 216 days ago and wrote about it as a comment on HN * He didn't say whether he reported that day but he recalled Instagram was making HTTP request a year prior to that day he wrote the comment * He didn't tell us when he report this issue to FB. Yesterday? Last week? * FB said they are aware of this situation and closed the ticket. Like someone else said here, "closing" has different meanings. I've never reported any vuln to FB so I don't know how that works. But on HackOne, particpating program can close a ticket and set the ticket to "Not Applicable" meaning someone else has already reported. So the decision factor is: * when was the first report submitted by OP? Yesterday? Last week? 3 months ago? 216 days ago? * if it was very recent, OP doesn't know the exact time the last duplicate report was sent out. Give FB a little more time and ask FB again in a week or so. I did say in my other comment fixing this issue should be pretty trivia for Instagram as an outsider, but I also should acknowledge any major change to infrastructure should have a proper audit and roll out. edit: One last point. If OP thinks he's doing the right thing, let it be. There are too many things unknown to me so I am just listing all the possible consideration. I have tons of bug bounty reports unfixed for 3 months on various sites and I still email those sec teams back and forth to look at progress. It's an individual decision and with every decision comes a consequence to bear.
- sneak 12y ago

fdsary 12y ago

I'm trying to reproduce this on a macbook. I'm a developer, not a networks guy so please excuse me for not knowing the basics! After doing `sudo tcpdump -In -i en0 -s 2048 -A dst i.instagram.com`, and using every instagram feature from my iPhone, nothing happens in the terminal. ``` tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 2048 bytes ``` I try running with -v and -vv, but no difference (except it doesn't suggest running in verbose more). After hitting C-c to stop the program, it outputs ``` ^C 0 packets captured 29816 packets received by filter 0 packets dropped by kernel ``` So there's a lot of things being captured, but the filter does not catch my Instagram activity. I'm logged in there, refreshing, getting images, getting followers/following, etc. EDIT: oh shit, HN doenst do markdown. That sucks.

piratebroadcast 12y ago
Same exact thing happening to me. I'm loading friends pages, liking photographs, and getting nothing.
na85 12y ago
HN does some minimal formatting. You can add emphasis to text with asterisks You can also prepend your lines with two spaces for pre-formatted text/code
rdrey 12y ago
The gist doesn't show how to get your network card into monitor/promiscuous mode. EDIT: I'm not sure -In work with default drivers, but I'll test with my private Mac at home later.
deleted 12y ago
[deleted]
tmops 12y ago
Well, are you connected to the same open wireless network as the iPhone, and are within close range of it? This isn't going to work on an WPA network. Try taking off your "dst i.instagram.com" filter and see what you're actually capturing.

13throwaway 12y ago

Websites need to start taking more responsibility with HTTPS. Reddit, and a few other popular sites can also have their sessions hijacked.

skeletonjelly 12y ago
reddit was quick to patch the heartbleed bug, but I got downvoted when I put forward that it wasn't a big deal as HTTP is probably 99.99% of traffic.

0xeeeeeeee 12y ago

I reported this issue a long time ago. Got the same messages back from facebook as everyone else in the thread. I've reported other issues and always get the same thing back. It sounds like Facebook Security gets a lot of pushback from the developers. Certain things like coffee shop attacks and a lot of other REAL ISSUES get no notice for a long time. It took up until last year to get a damn HSTS header. I actually reported an issue today about a security practice they implemented completely incorrectly. I got a response back that it was not meant for any actual security. In theory it's unacceptable, but in practice this is a big company with thousands of employees and a lot of moving parts. Small changes can be hard to make....which to get back to my original point is why facebook seems to just ignore a lot issues but keep the pipes open for the occasional big one.

Ryel 12y ago

Every couple of months one of my friends insists that she's "quitting Instagram" because of how often things go wrong on the platform. Several times a month she gets logged into someone else's account with full read/write/update access and I believe even gets access to their Facebook. Between the above, the 4+ accounts she's has deleted for no reason, and the bugginess of often having a blank UI, it's becoming harder and harder to enjoy browsing on Instagram.