https://nvd.nist.gov/vuln/detail/CVE-2020-1894 This was yesterday I think? With code-exec through a stack over flow in push to talk. Unless the date-format is out of whack. and 09/03 is 9 march not 3 september
> If you lose access to your WhatsApp account, the messages you previously received will remain on your phone and will not be available elsewhere.
As I understand it, if you give in to the android app's repeated prompts to enable backing up to your google account then your messages are stored elsewhere, and without encryption.
What surprises me about the list of CVEs is how many of them affect both Android and iOS. One would assume they are two completely independent codebases.
Many mobile apps rely on shared components/libs/frameworks that are either developed by the company or are FOSS (libpl_droidsonroids_gif for example). In either case...they are platform agnostic and usually written in C.
And as we all know C is full of memory handling problems like overflows.
Hopefully in 2020 and beyond people will be developing these shared components in Rust instead.
This thread thus far has a ton of comments from people who haven't bothered to actually read anything about how WhatsApp works, or how the Signal protocol works.
It would make for a better comment thread if everyone did that prior to expressing an opinion.
This kind of snide comment gets upvoted because everyone sees it as a way of looking down on the 'other comments'.
If you have something specific to say to each of the people who "didn't read the spec" then please respond to those people with that, instead of making passive aggressive commentary and making us assume the worst in everyone else in the comments.
It's completely appropriate to ask the HN community to do more work before posting, instead of posting opinions that haven't been checked against reality. The mods use this same approach when advising us to act better: a single top-level comment, discussing a common misbehavior and asking for it to stop. We should aspire to be a better community, but individually chastising tens of comments for posting unfounded and repetitive comments would pollute the discussion with needless repetition of the same core point.
IMO these walled-garden app stores that are supposed to be "so good for the users" should require quality release notes that describe the exact "performance improvements and bug fixes" that the respective apps apparently receive.
There are quite a few reasons to have release notes like this:
1. Major apps often do phased rollouts of features in order to react to potential production issues, or to make certain features available to a limited subset of users or regions without having to do an emergency binary release if things go wrong.
2. The new build contains an A/B experiment, and you don't want to tell users that feature X was revamped because the experiment might not even go anywhere and only a small number of users will see it, anyways.
3. Your app is stable enough to have a regular release cadence e.g. monthly or biweekly, and you actually are just shipping whatever bugfixes made it into master since the last release with the major feature changes hidden behind feature flags until they are ready for 1. or 2.
4. The vast, vast, majority of users never read the update notes on the app store. They have automatic updates enabled, and your app updates at 3AM when their phone is plugged in on wifi and they are fast asleep.
5. Building on 4, if you actually want to advertise new features to users, it is better to build a native experience into the app either building a UI highlighting what has changed in the new version, or just popping up a dialog to show the patch notes (can be coupled with 1. and 2. to only show the dialog to users who have gotten the new feature enabled in the phased rollout or experiment). Discord is an example of an app that does this well.
6. Also building on 4., the changes are so minor that they are not worth paying a translation service to translate your patch notes if you are offering your app in multiple languages.
Sure, I'm aware of those reasons (and can think of many more). As a user/customer, I don't care about any of those details. I still want to know what's changing when I click "Update".
If users have automatic/background updates, sure, they apparently don't care about release notes. For everyone else, the release notes are really the only way to know what changes are going to happen upon clicking "Update". Having those notes be [effectively] blank is a substantial disservice to the user.
It's depressingly frequent that an app I used to enjoy takes a major dive in user experience. For a contrived example, I don't like finding out I am now suddenly blocked from using my messaging app because they force me to use a new cloud-based account system I can't opt out of, and none of this was mentioned before I clicked Update. Or another favorite: an update that does nothing more than introduce in-app advertisements.
I would prefer an "app store" that required apps to be open source. This would allow everyone to see exactly what is being done by the developers. Release notes alone are not of much use for the public in the case of closed source apps because the public cannot take a closer look. Is anyone really going to look at a release note that says "Bug fixes" and make a qualitative decision on the app? With lots of such notes we could conclude the developers are busy fixing things (good) however we could also conclude the app when released contained many latent bugs (bad). But we need to see the source changes to truly understand what are the circumstances. Perhaps such vague release notes are not actually published for the benefit of users but for some other reason(s).
apple actually banned update descriptions like that a few years ago. when they announced it they started enforcing it but i goes over time they’ve gotten lax or just give big companies exceptions
I've collected screenshots of app updates with that text as their release notes so I can one day start a "bug fixes and performance improvements" tumblr or blog or the like. It's just such a joke to me. Kinda like software installers that put the GNU Public License as their license agreement you have to agree to before installing, haha
IMO these walled-garden app stores that are supposed to be "so good for the users" should require quality release notes that describe the exact "performance improvements and bug fixes" that the respective apps apparently receive.
What is it that makes you think this is caused by "walled gardens?" Do you have a link to a policy that requires this, or is it your own biases showing through?
I think you may have misunderstood my comment... I'm saying that if the walled garden app stores are supposed to be good for users (especially if this is one of their marketing bullet points), one might reasonably expect that "high-detail release notes" ought to be one of the requirements for app developers, imposed by the owner of the app store (Apple, Google, etc.) .. This way users get a good understanding of what changes will happen when they download an update of a given app.
I'm on the other end of the spectrum. Since the updates are constant, often required and automatic it makes little sense to provide these in the store itself. The user doesn't really have a choice of not updating most of the time. It's not a decision they should make
I'd rather see release notes outside the stores, for more technically inclined users only.
Users would be scared by reading technically accurate release notes. So for apps as ubiquitous as WhatsApp, it makes sense to have two kinds of release notes, one for techies, and one for commoners, who only want to know whether features were added or not.
Disagree 100%. I don't expect technical detail, I expect product change detail. Have you ever looked at Slack's release notes? Easily digestible and they don't need to go into deep technical detail to say that a given feature behaves slightly differently now. I expect a bit more than the totally-meaningless "bug fixes". Even something as simple as "icon update, old messages now stored in Archive tab". I just don't want crazy surprises like a total UI overhaul where tons of stuff I'm used to is just suddenly gone.
Having dealt with my share of technically-unsavvy users, I can confirm that half the job is managing their feelings. The other half is working around them to keep things safe and functional in spite of them.
That sounds logical in theory but in practice users may use a tool and still loathe it. Their choice to use WhatsApp is partially dependent on their contacts’ choice to use it.
I imagine for some instances, it's because a security fix might have gone in, but they don't want to clue attackers on other platforms. For example, if the fix is submitted for the Android and iOS apps to their respective marketplaces for review at the same time, and one is authorized and goes live first, then you've released information that's useful to someone looking to exploit the other (they now know there's something to look for in the differences of how they operate).
That is, unless both stores allow you to get the version authorized but hold it for release until you want. I know the Roku store did that years ago, so I imagine it's probably a feature that's present in those stores, but I don't know for sure.
That's another great reason to be vague, because even if you were able to launch your updates at the same time on all platforms, at least on mobile the adoption rate can be relatively slow - on mobile I've measured that it takes about a week to get 80% of users to update and 2 weeks for 90%, which could leave a sizable vulnerable population.
Well there is at least one reason that release notes are bad: any mention of any new feature or specific fix seems to trigger more scrutiny from Apple reviewers.
The more information you provide, the more likely it is that your app will be held up in review or you will get additional questions from reviewers delaying your release.
I generally still try to err on the side of including information in my release notes, but I have been bitten by this enough times that I completely understand this practice and sympathize with other app developers.
> We do not store private messages on our servers _once we deliver them_
Doesn't this mean that messages exist in plaintext on Facebook's servers for at least the time it takes to deliver them? To me this is equal to saying that everything is clear text anyway, since there is no way to ensure someone lawfully or unintentionally taps the text stream and diverts it somewhere.
Probably just means the encrypted messages are in holding on the server until delivered. There's not much alternative to that unless peers are enabled to talk directly to each other, which would likely be a poor experience due to reliability and connectivity issues.
True P2P isn't really possible today in the vast majority of ISP networks (especially mobile ones), so at most traffic will be relayed by a TURN server which is also centralized.
Are you sure that mobile networks really go out of their way to block STUN, not to mention that they’re predominantly IPV6 so the reasons for NAT would be weird at the carrier level (haven’t investigated this too thoroughly so not sure).
That would require at least a retry, which might fail if the sender also has a spotty connection. One of WhatsApp's main deliverables is reliable service over bad connections.
I think what they're saying, and they ought to clarify this, is that they don't store unencrypted messages, and they may temporarily store encrypted messages as part of the Signal protocol to deliver them later.
I think the interpretation is meant to be "we store private messages and we stop storing them after delivering them" rather than "we make them not private before delivering them".
When you send someone a message, you upload the encrypted message to the server addressed for them. The user checks in with the server asking "any messages for me?" The server then delivers the message and deletes its cache of messages.
The server "stores" the message for that period of time when the user uploaded it and before the receiver confirmed the download. Allegedly, it stores it in the encrypted form as its advertised as end to end so they would not have the key to decrypt it.
