WhatsApp, a Facebook owned app, will not give you read access to your own chat database - it’s encrypted. But they have an arrangement with Google where it’s will back up unencrypted to your Google account (though, Google won’t let you retrieve it ... only the WhatsApp app can)
Everything about this duopoly, their cooperation and lack of competition stinks to high heaven.
You can store data on Google Drive that isn't accessible from Google Drive and only that app can read or write it.
But why would WhatsApp store it unencrypted on Google Drive, and encrypted (without giving you any access to the key) on your own SD card or local backup? It makes no sense.
Except ... Google and Facebook have agreed that WhatsApp stores the database unencrypted, and in return Google doesn't count it against the user's quota. Everybody wins! Facebook get to have free backup for users, Google gets to see all user messages and metadata. And the user gets rid of this pesky privacy thing!
[0] https://faq.whatsapp.com/android/chats/about-google-drive-ba... - "WhatsApp backups no longer count against your Google Drive storage quota." and "Media and messages you back up aren't protected by WhatsApp end-to-end encryption while in Google Drive."
some serious cognitive dissonace is going on - either that or it's the effects of the news-cycle making us blind to it. Maybe we should think twice before applauding FAANG engineers in future posts because Technology isn't neutral.
note: a company can't be evil. it's just a group of people who can be evil and who hide behind the facade of the "legal person" statute. I'm happy to celebrate individual breackthroughs but let's not forget that without (metaphorically) nailing the culprits to the cross who are responsible for ICE contracts or privacy invasive tech there isn't even a point in complaining about all the horrid stuff these people (working for these companies) do.
But they also produced some really cool tech. Unix being the obvious one to bring up on this site.
That era is romanticized to hell (including by me), and Ritchie, Thompson, and the like are folk heroes. Despite being engineers at the subsidiary of a giant monopolistic entity.
Ultimately, for people who think the tech is cool, it doesn't matter where it comes from. In 50 years people will be romanticizing the era of the FAANG companies (more than they already do) the same way we romanticize bell labs.
That said, with FB/Google these days the bad weighs more than the good.
On android? On iOS you can get a tarball of all your chats.
As much as I'm happy to pile on Google, Facebook and WhatsApp, this appears to be untrue.
Or do you demand that any file under your control that contains chat should be accessible, rather than just one of them?
You can't download it without impersonating the WhstsApp app.
Do you know if the icloud backup is encrypted or not?
Haven’t seen anything like this before.
Convert all active whatsapp contacts to signal? 80%? 50%?
Same for Facebook messenger!
It needs to be uncomfortable enough - if they want to communicate with us and are minimally tech savvy ("click link to install app") they have to switch to signal.
That's it.
I'm starting to send out messages over my morning coffee.
Let's do this together:
https://support.signal.org/hc/en-us/articles/360007060592-In...
1. There are tons of replies in this thread. People have very strong feelings about signal.
2. Some people feel VERY STRONGLY that the pin numbers are stupid, and it has a terrible UX.
3. Some people feel VERY STRONGLY that the phone numbers are the simplest, most straightforward thing to use, and they would hate Signal if they didn't support it.
4. Some people feel VERY STRONGLY that they don't want their phone number used as an identifier, and it's a failure of Signal that they use them.
And it seems like many of these replies assume that their own position is the only possible one to take (or at least the only intelligent one!).
Imagine working on Signal and trying to create a product that pleases all these people, as well as even less technically minded folks, while having none of the usual analytics at your disposal to measure actual user interaction!
My hat's off to Signal. I admire their work but I don't envy their position.
The uptake? Like ~30% of the people I'd like to contact bother with it. The rest, it's even worse - we get stuck with SMS. And a lot of conversations I just miss, period, because they're groups of people in one of those other ecosystems (and missing those is a price I'm personally OK with paying, but not everybody will be).
The situation is just really bad. Signal is a good baby step forward, but it's not really the answer for most people, because they're sticky to wherever their network graph of contacts already is, and they're not going to switch just because the one weird nerd in their life isn't available there.
They can start by removing the atrocious phone number verification first.
There are some good-looking and user-friendly clients
1. Shady addictive game requires full access to drive.
2. Shady game downloads all your chats with all contacts
3. FB is on fire since they allowed access to people's chats with others, even those who didn't download the game.
4. People get mad on FB/Google for not protecting their data.
Claiming that this is the reason is sort of like rearranging the chairs on the deck of the titanic when you can see the iceberg.
Much more likely it is to stop import/export to a competing app. The fact they will let you keep a local encrypted copy, but not an unencrypted one under any circumstances, is telling.
At least this time you can disable the SDK (at least one app developer has a kill switch for the SDK) unlike the last issue that happened during code initialisation you couldn’t skip.
"A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." -- Leslie Lamport, 1987 (https://lamport.azurewebsites.net/pubs/distributed-system.tx...)
No, I don’t think there’s any “to be fair” in that, unless those SDKs have been officially EOL’d. Even then it shouldn't take down the whole app, Facebook should just break.
That this only happens with some SDKs certainly makes the problem less severe than last time, but only relatively.
There's no such thing as QA at Facebook. Really. Developers are supposedly responsible for all testing of their own code, but all of the pressure is to "move fast" so that goes about as well as you'd expect.
If you have a team run by idiots, then you won't have QA.
If you have a team run by adults, then there is plenty of QA. I mean its total shite that this wasn't caught. I'd expect much better, especially as this is the second time in n months. But then perhaps working for a company run by a dick who can't listen is getting to people.
The first two times it took months to fix. It’s happening again currently, too.
Clear there are GAPING holes in their test suites.
Workaround for developers: Go to Facebook Developer page > Analytics and disable automatic Events.[0] Apparently this doesn't solve the issue for everyone.
Issue in Facebook's tracker: https://developers.facebook.com/status/issues/17391881029111...
[0] https://github.com/facebook/facebook-ios-sdk/issues/1427#iss...
facebook.com
fbcdn.com
fbcdn.net
fbsbx.com
fb.com
instagram.com
https://github.com/confirmedcode/lockdown-ios/blob/master/Lo...
https://github.com/confirmedcode/lockdown-ios/blob/master/Lo...
https://github.com/confirmedcode/lockdown-ios/blob/master/Lo...
https://github.com/confirmedcode/lockdown-ios/blob/master/Lo...
I couldn’t help but notice neither app worked even after a reboot, yet google maps did. I was thinking there was a carplay bug and then thought: “oh boy here we go, what are the odds, let’s check hackernews” and bam, of course it’s the Facebook sdk again
I’m thankful that googles iOS-chrome and google maps doesn’t use the Facebook sdk for something...
I want a central document with clear steps on how to mitigate. Currently the best option for documentation seems to be wading through comment threads, which is very frustrating.
Or if you must, use their oauth flow and API but _don't_ include code of theirs you don't control directly in your binary. It's just asking for trouble.
>It turns out that by just including the SDK with your app, Facebook runs hidden code on launch. (FBSDKApplicationDelegate.m)
[0] https://twitter.com/sandofsky/status/1258288056399847425
There are some intricacies on iOS surrounding null values and serialization, and as a developer it is important to understand that you may encounter NSNull. As a standard practice in my company, we type check every remote value before calling anything on it. Seems like that would have prevented this issue.
It makes me wonder what all those engineers at FB are actually doing... ? Every time I tried to integrate or look into the FB SDK for simple functionality it was a total clusterfuck.
Source: have had that issue before
Also maybe it’s time for them to start rewriting things in Swift, where this would be much less likely to happen
What has this industry become? How are we so goddamn inept at writing software? This is an industry where we can automate testing - not many other industries have this capability - and we still don't have a simple test regime of "check if the app opens" for any of those apps. Somehow, at the most valuable software companies of the world, nobody has set up a system that makes sure that you can't introduce a change that renders these apps unusable?
WHAT THE FUCK.
I have always been afraid of software engineering becoming a trade similar to medicine or law or (regular) engineering where significant barriers will be put up before you can enter the industry, but this sort of shit makes me feel like it could be for the better. I will have to go and get a degree, but that's the price I have to pay I guess.
Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized.
A couple of days later I caught up with the people allegedly responsible for this stuff in the bigger review meeting. "Shouldn't you open a SEV because you are shipping stuff that can't possibly work and aren't catching it pre-release?" The response was a lot of hand-waving and stupid manager-speak that boiled down to "no, go away".
I basically wrote them off at that point. If they could act that way and get away with it by way of implicit acceptance from upper management, that's just the way it was going to be.
I see the quality is as high as always.
:(
Facebook's own apps did not break since they are on the latest version of FBSDK.
What Facebook needs to do is to test whether their changes don't break other people's apps.
2. Client-side SDKs can be designed in a way that even if the server-side changes (which it shouldn't), it does not cause the whole application to crash. This can of course be hard depending at which level the SDK operates and how integrated it is into the app.
3. Are there no contracts between Google/Spotify/etc and Facebook? If I were FB and there were contracts on the line, I would make sure that there is no way something like this can slip through (automated testing).
I'd argue this is at the very core of why you test. I mean this problem is as simple as (n+1).m vs n.(m+1) in terms of versioning vs revisioning.
If that is not being tested then I'd say Facebook isn't actually testing at all - at least not in a practically relevant sense ...
... despite the shit-load of YouTube videos from FB devs lecturing about CI/CD and what not.
2. Throw exceptions
Don't tell me "No amount of testing" just because you aren't responsible for your own dependencies.
Recently tested an enterprise marketing app with an SDK ... and we tested if the endpoint wasn't available. Nothing happened -- it worked just fine. Failed quietly and gracefully -- the user would never notice.
"We" know how to do this.
Facebook hasn't done anything to fix this problem since it happened a few weeks ago.
But it's Facebook -- I hope they keep it up. Can't wait for them to AOL themselves.
I can almost guarantee that the programmer who wrote this had a degree and passed a very rigorous testing process to get their job at Facebook. Doesn't mean anything when the company tells them to cut corners to iterate faster.
Stop blaming engineers for the mistakes of management.
Proximate Issues
The app makers cannot easily prevent the crash since it is happening in Facebook provided code. Perhaps the only thing they could do is to code in kill switches. Another possibility would be to modify the Facebook code. That introduces maintainability issues.
The crash happened because of a server side change that triggered roughly the Objective-C equivalent of a null pointer exception.
Objective-C is an old unsafe language.
Ultimate Issues
Client-side libraries have a poor history in the industry. They are often written by server engineers who aren’t expert on the platform.
For instance, if it was really a static load method that called the server, then this was a poor design decision.
Furthermore, weaker server engineers are notorious for breaking backward compatibility. They don’t design nor build in tests to ensure backward compatibility. The backward compatibility must include backward data compatibility.
The above issues are indicative of organizational issues.
Facebook is a little bit of an outlier. It was notorious for badly written client libraries stretching back to the Facebook platform days. The joke was that their libraries may have been written by interns even though so many companies were dependent on them.
The Facebook libraries and the ilk are used for sign on through Facebook and ad attribution. The trade off an app maker needs to make it a whether to run ads on Facebook and whether to support sign in.
Facebook is not the only big company with these issues. Google’s equivalent also crashed albeit at a much lower rate due to a much more convoluted issue.
Apple introduced the Swift programming language to address the deficiencies in Objective-C. That these companies are running into these issues makes me wonder if they never transitioned to Swift. They are certainly way behind the latest version of the libraries.
To summarize, it is a cascade of issues some technical and some organizational rather than a single coding error. These issues span companies.
> Objective-C is an old unsafe language.
This was a safe crash, not an unsafe one. Swift can and would crash the same way.
This one was a good one because the app cache was poisoned so the only solution was to ask customers to reinstall the app (after Google deployed their fix, which took a while) or upload an update that nuked the SDK cache on startup.
This would still happen because A) the programmers that made this mistake probably have the knowledge to pass any certification exam you can throw at them, B) most of the time we are not just building something that has exploded 1000 times before, we are creating new stuff.
The engineering process was the issue here, and sadly the only way to prevent this is not to make personal barriers of entry higher but to slow down the process with more QA, testing or whatever you can throw at it. In other words, make software more expensive. And keep in mind that this would only give better numbers but it would not solve the issue either (see Boeing 737 MAX).
Very unlikely. You probably don't realize how tough some professional exams are in some fields. We are talking dedicated months of study here.
> B) most of the time we are not just building something that has exploded 1000 times before, we are creating new stuff
Most software out there is just CRUD stuff, not really new stuff...
Wow who would have thought no standards, free access to learning, fake-ass meritocracy, and exorbitant profits and market control would have led to such a thing
Pick a standard, whether it's a degree program, a cert, or apprenticeships. Hurry up! Just give us a solid target to aim for.
There's a good chance that the one who wrote this bug had a degree.
Surgeries in medicine still get botched despite all of their degrees and barriers. Degrees don't produce good code, good developers produce good code.
> I will have to go and get a degree
Was not aware that having a degree made you immune to writing bugs.
This will be a fart in the wind and lessons will be learned.
The industry seems to have very low standards. Let's let these mistakes happen over and over and let's just patch them as we go. No long-term thinking.
Someone should collect all these horrible incidents and start a university course on just plainly what NOT to do.
“ Earlier today, a code change triggered crashes for some iOS apps using the Facebook SDK. We identified the issue quickly and resolved it. We apologize for any inconvenience.” (1)
At the scale of Spotify and other massive blue chip apps, this bug could have very well cost companies hundreds of thousands to millions of dollars in damages. This apology on the bug tracker seems so insincere. With this type of issue occurring twice in a couple months, I’ll be ensuring that no clients of mine ever install or rely on Facebook services within their mobile apps. Facebook has a responsibility to developers to ensure that their SDKs and integrated components are stable, and they have failed.
[1] https://developers.facebook.com/status/issues/17391881029111...
Facebook are big enough to blow this off, and they know it. At least... they hope so.
How is this even possible, even less acceptable from Spotify point of view?
None of the apps broken on my phone require Facebook features for core functionality. Downtime happens, but downtime due to your non-essential & user-hostile ads/tracking/social SDK? These companies deserve every single cent of lost revenue.
IMO, blame Facebook.
Turn airplane mode on, open Spotify, go to Settings > Playback, set it to Offline, then turn airplane mode off.
At least now you can listen to cached music and browse the web again.
Longer term, install a Pi-Hole on your home network and block all Facebook owned domains, because they’re a scourge on humanity and your life will be much better void of their infection.
[1] https://parachute.live/blog/forensic-investigation-the-shock...
Can you give a few examples?
> none of them had ads
The comment was about the Facebook SDK being used for ad attribution, not that the apps themselves have ads.
It creates a local VPN that sets up a local filtering DNS. I just added the following domains to the block list:
facebook.com
fbcdn.com
fbcdn.net
fbsbx.com
fb.comOpen source and free. Don't be confused by the VPN service they also offer for a price. You just want the local firewall functionality.
Even ignoring the privacy concerns, this is unjustifiable.
So Apple have put out an incentive to their third party Devs while still giving some freedom.
Obviously it would require app developers to implement, but Apple has a lot of power here.
1) Download NextDNS from App Store
2) Open app. Hit (...)
3) Enable Custom Configuration, Config ID 22776a
It’ll DNS block some ads and Facebook domains. Turn off after you’re done. Also assume any DNS server offered by random dude as poisoned.
Edit: Issue resolved! People, turn it off or switch to your own configuration.
Mobile phones were a big step forward from plain old landline ones. But in terms of ease of communication this change was the last one with non-deminishing returns. Maybe smart phones also just for browsing HN when I wait in a queue or in the bus etc.
All those social networking and communication apps? Fcuk them.
I can perfectly communicate by calling or texting or video calling someone. What exactly is the added value of those apps?
And for Communication, you never use Slack? It's useful to segment your communications by type, I don't want to give random Tinder ladies my home phone number.
Someone recommended airplane mode and lo and behold the app started working. This is Facebook's fault, but also Spotify's.
How such an established platform with supposedly-established engineers can let a third party library crash their app at startup is genuinely embarrassing.
Not again...
This is what FB for dev says:
"To make your app compatible with the latest iOS, be sure to use the latest Facebook SDKs for iOS."
:)
Anything that can open the general public's eyes to how much data is leaked through these kind of practices is a good thing. Hope it amounts to some non-negligible loss for Facebook, Spotify and the others.
Mild inconvenience for now, hopefully this will have more people move away from the FB SDK.
Thanks, send her the github issue.
The crash is:
Crash information
-[NSNull count]: unrecognized selector sent to instance 0x1cd6fe1e0 2020-07-10 17:24:26.052924+0800 OSDemo[4198:604792] * Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSNull count]: unrecognized selector sent to instance 0x1cd6fe1e0'
Any idea why seemingly no one of the big apps does this?
Like wtf. they have so many resources how is it possible that even with that they can't make their sdk error resilient.
Maybe the mass revocation of EV certs happening ~today is the trigger?
"HackerLemon is listening to Band on Spotify"