This is a bit weird. I don't believe WhatsApp are lying but there's absolutely no proof they're not.
I could release a closed source app with a bunch of padlocks in it and copy/paste their white paper and have exactly the same level of proof of security. Would I get a 7/10 from EFF?
Reputational damage is higher for entities with more money. Therefore their credibility of not doing something that causes reputational damage is higher.
> Reputational damage is higher for entities with more money.
In what world? Big business figured out a long time ago that most of the time their bad actions won't be noticed by most people. The rest can often be fixed with some inexpensive spin and PR. Their reputation is only damaged when a scandal is very large and in the right place and time to be noticed.
A "billion dollar company" necessarily has a strong profit motive. It's also subject to the codes and regulations of the country in which they operate. The former damages their credibility (they will do what is profitable, not what is moral), and the latter makes communication platforms suspect (government involvement).
Of course, we don't have to speculate - this is Facebook. They are not only part of Prism, but their entire business is based on surveillance. Not only do they have zero credibility for respecting privacy, they are actively hostile.
You're disputing that it causes reputational damage, not that reputational damage scales with money.
I'm not saying that they'd lose reputation from "not respecting privacy". That's not considered that bad by the general public. I'm saying that they'd lose reputation from "claiming to release a feature while lying through their teeth about it".
There are a lot of generalizations there. Do you have example of an audit showing that they have never misguided their users or represented their product and motivations?
No, and the burden of proof would be on you if you're claiming it's likely that they're lying.
Edit: my broad claim is basically that companies won't lie about what their products do, if their claims are specific. In this case, they released a whitepaper with technical details.
If a company makes a broad unspecific claim, it's possible to be wrong or misleading without the implication of a deliberate lie by the company. In this scenario, it's not possible for it be wrong without a direct decision to lie, and therefore I think the reputational damage would be great if exposed, and it would be easily exposed by analysing network traffic before long.
What I'm claiming in the specific here is that "the system implemented matches what the whitepaper says". I wouldn't put it beyond facebook to backdoor it in a way that's hard to figure out (with the backdoor included in the whitepaper ala Dual_EC_DRBG), but I'd consider that to be unlikely (firstly because there are actual humans behind it at the end of the day, and I'd hope that they would feel that "claim to release encryption but put a backdoor in" is morally worse than just not releasing encryption at all, and secondly because Whisper systems is involved). But all of that could arise in an open source system as well. What I have high confidence in is that the system matches the whitepaper. (There's also the possibility of an implementation problem that preserves plausible deniability for them, which I also consider unlikely.)
All in all, reducing their grade by 1 point to account for additional risk in closed source seems reasonable to me.
I'm not at all clear why this blog post is touted as evidence that the tiny modules approach is correct. I think it might be all the people after it congratulating him.
"It's all about containing complexity." - this completely ignores the complexity of maintaining dependencies. The more dependencies I have the more complicated my project is to maintain.
Dependencies are pieces of software managed by separate entities. They have bugs and need updates. It's hard to keep up to date.
When I update a piece of software I read the CHANGELOG, how am I expected to read the CHANGELOG for 1,000 packages?
Depending on a bigger package (handled by the same entities, who write one changelog, in the same form) is more straight forward.
I'm not saying this is wrong - but there's a balance here, and you must not ignore the complexity of increasing your number of dependencies. It does make things harder.
