HN user
Moxie Marlinspike
A lot has changed since 2014, and this might actually be possible now. It could be tough to do this right and figure out what to do with the edge cases like importing a WA conversation that overlaps with an existing Signal conversation, or handling things like quoted replies, but this could be a fun project if anyone here wants to take a shot at coding it up.
Yeah, bummer. There were some iOS 14 changes that made this stop working as reliably, which was unfortunately right around the time people were getting new devices. It should be better now, and we're working on more stuff in this area.
They store your social graph in plaintext on their servers.
Still stupid, shouldn't they ask if I want that functionality?
It's kind of a difficult thing to ask. "Do you want this app to work like every other app in the world in the ways you've come to expect?" If people were to simply reinstall Signal and find that all of their contacts were gone, all of their groups were gone, all of their block lists were gone, etc... they'd almost certainly be surprised. It's not a behavior anyone expects.
Every other consumer messaging app in the world solves this by storing all of that information in plaintext on their servers. We're trying to do something privacy preserving instead, and have done a fair amount of engineering work to try to make it as frictionless as we possibly can.
If you have ideas for how we can achieve the same ends with less friction, we're definitely interested in the feedback.
Not like it's going to be hard to brute force a user's PIN.
Check out this blog post for more information about the technology:
Right now if you re-install Signal on your device, you lose all your messages. That's already a very bad user experience, but imagine how much worse it would be if you lost your entire address book in that moment as well.
Right now that's not a problem because your social graph is in the address book on your phone, and isn't managed by Signal. This is one of the primary reasons that Signal uses phone numbers for addressing: it leverages an existing user-owned and user-managed social graph. However, what we've repeatedly heard from users is that they don't want addressing to be based exclusively on phone numbers for a variety of reasons.
If we're not using that social graph, then where does the Signal-specific social graph live? For every other app in the world, the answer is that it lives in a server-side plaintext database. Snapchat, WhatsApp, Telegram, Matrix, Wire, FB Messenger, Skype, etc etc... they're all just storing your entire social graph in a plaintext database (along with a bunch of other stuff, like your groups, profiles, etc).
Given the way that technology has developed (devices are fundamentally designed for a world of clients and servers), it's probably not possible for us to build something that makes no use of servers. Instead, we've focused on building something that doesn't store or transmit any sever-side plaintext.
For instance, when you set your Signal profile name and avatar, that lives "in the cloud" so that other Signal users can retrieve and display it. But it's encrypted (https://signal.org/blog/signal-profiles-beta/), so only your contacts can see it (not us).
With Signal Private Groups (https://signal.org/blog/signal-private-group-system/), again we have to store data "in the cloud," so that there's a canonical data source for group management, but again all of the contents are encrypted so that only group members can see it (not us).
In this case, we're using Secure Value Recovery to ensure that a future addressing scheme that's not based on phone numbers is available across app reinstalls, phone switches, phone loss, etc. We could have just done what every other consumer messaging app in the world has done (store it in plaintext on the server), but we built this instead. It is the most user-friendly option that we could conceive of while still being privacy preserving, and took a lot of engineering work.
We're going to keep looking at all the feedback we've gotten, though, to try to make it the best experience we can.
FWIW, there are a couple of things about Apple's and Google's systems that don't work for Signal:
1. There is no meaningful remote attestation. There's no way to verify that there are HSMs at the other side of the connection at all. The people who issued the certificates are the same people terminating the connections.
2. There's no real information about what these HSMs are or what they're running. Even if we trust that the admin cards have been put in a blender, we don't know what the other weak spots are.
3. The services themselves are not cross-platform, so cross-platform apps like Signal can't use them directly.
4. It's not clear how they do node/cluster replacement, and it seems possible that they require clients to retransmit secrets in that case, which is a potentially significant weakness if true. I could be wrong about this, but the fact that I have to speculate is kind of a problem in itself.
My impression is that you're suggesting the HSMs Apple uses are better than SGX in some way, but it's not clear that anyone could know one way or the other. I think all of the scrutiny SGX is receiving is ultimately a good thing: it helps shake out bugs and improve security. It's not clear to me that the HSMs Apple uses would actually fare better if scrutinized in the same way, which could be a missed security opportunity for them.
We didn't feel that it would be best for Signal to start with a system where we say "believe that we've set up some HSMs, believe this is the certificate for them, believe the data that is transmitted is stored in them." So we've started with something that we feel has somewhat more meaningful remote attestation, and hopefully now we can weave in other types of hardware security, or maybe even figure out some cross-platform way to weave in existing deployments like iCloud Keychain etc.
As for Lyme disease: The actual infection can be treated with a standard course of antibiotics. The infection does not persist indefinitely, although some people experience long-lasting effects after the infection is gone.
I don't think it's possible to make an absolute statement like this with 100% certainty given the current state of the art. Lyme is a spirochete, and there also seems to be real research suggesting it can grow biofilm to make it antibiotic resistant or resurgent.
There are patients who test positive under CDC criteria, take antibiotics, and never see a transition from IgM to IgG.
There are also patients who test postive under CDC criteria, take antibiotics, see a transition, but still experience symptoms (what you would call 'long-lasting effects'). In some cases patients in that situation have extreme gland swelling that when biopsied, seem to contain Lyme.
Like all of medicine, I think it's squishier than what you're describing. There is also a lot of crazy shit on the internet, but like you say, that's because people are genuinely suffering and have no alternatives.
"Also the end of the story mentions there are no obvious monuments to the people who worked to help rescue people but there is one in the very city he was reporting from dedicated to the firefighters and others involved: https://oddviser.com/ukraine/chernobyl/memorial"
I've seen it and really love it. The distinction is that it's inside the exclusion zone, a guerrilla art installation built by the liquidators themselves, not somewhere people can see it where life goes on, like Kiev or Minsk.
"Only 1400 kilograms of uranium and graphite mixture would have needed to hit the water to set off a new explosion. Our experts studied the possibility and concluded that the explosion would have had a force of 3 to 5 megatons. Minsk...would have been razed." - Vassili Nesterenko, director of the Institute of Nuclear Energy at the National Academy of Sciences of Belarus.
I am not a nuclear physicist, but at least some people who are did not find this to be "clearly nonsense."
I think there's a lot of uncertainty in talking about Chernobyl, since most of the information published by the Soviet authorities was intentionally incorrect or misleading, designed to downplay the significance of the accident.
One thing I've found interesting in talking about Chernobyl is that advocates of nuclear power are often willing to accept the Soviet numbers as fact, since they confirm the idea that nuclear power is still relatively "safe" even in case of disaster.
I don't know what the exact numbers are, and I'm not sure if any of us will ever know for sure, but one of the documentaries I like is Discovery's "Battle of Chernobyl," since it includes a lot of interviews with people who were actually there and participated in the events. They interview Nikolay Antoshkin, the colonel general in charge of the helicopter operations there, which is where the 600 pilot deaths number comes from. I'm more inclined to believe that account than what the state published.
Here's how WhatsApp group messaging works: membership is maintained by the server. Clients of a group retrieve membership from the server, and clients encrypt all messages they send e2e to all group members.
If someone hacks the WhatsApp server, they can obviously alter the group membership. If they add themselves to the group:
1. The attacker will not see any past messages to the group; those were e2e encrypted with keys the attacker doesn't have.
2. All group members will see that the attacker has joined. There is no way to suppress this message.
Given the alternatives, I think that's a pretty reasonable design decision, and I think this headline pretty substantially mischaracterizes the situation. I think it would be better if the server didn't have metadata visibility into group membership, but that's a largely unsolved problem, and it's unrelated to confidentiality of group messages.
In contrast, Telegram does no encryption at all for group messages, even though it advertises itself as an encrypted messenger, and even though Telegram users think that group chats are somehow secure. An attacker who compromises the Telegram server can, undetected, recover every message that was sent in the past and receive all messages transmitted in the future without anyone receiving any notification at all.
There's no way to publish an academic paper about that, though, because there's no "attack" to describe, because there's no encryption to begin with. Without a paper there will be no talks at conferences, which means there will be no inflammatory headlines like this one.
To me, this article reads as a better example of the problems with the security industry and the way security research is done today, because I think the lesson to anyone watching is clear: don't build security into your products, because that makes you a target for researchers, even if you make the right decisions, and regardless of whether their research is practically important or not. It's much more effective to be Telegram: just leave cryptography out of everything, except for your marketing.
That defense, which happens to be the only defense, is turned off by default in WhatsApp. You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the connection as if nothing happened...
One thing we've learned over the years is that security warnings should not be displayed to consumers under "normal" (eg. non-critical) circumstances, otherwise it creates a condition of "warning fatigue."
TLS certificate errors are not something that should happen under normal circumstances. When a TLS certificate fails to validate, something is really wrong. As we've gotten better about ensuring those conditions, browsers have made it harder and harder to get past the warnings, because they're not warnings anymore -- they're error conditions.
Key changes in a messenger are totally different. They happen under normal conditions, so putting them in people's faces by default has the potential to do more harm than good. If we can make them workable, systems like CONIKS or Key Transparency might be in our collective future, but if you don't like systems that are fundamentally "advisory" (don't tell you until after the fact), you're not going to like those new systems at all either.
For now, I think a fact of life is that most people will not verify keys whether the warnings are there or not, so I think what's most important is that the server can't tell who is and who isn't.
I'd love to hear other ideas about how to improve the UX of interactions like this, but I think they have to include a basis in the assumption that we can't fundamentally change human behavior and that we can't just teach everyone in the world to be like us.
This allows WhatsApp to MITM. Whatapps can rekey both Alice and Bob, decrypt both their messages from that point onwards (incl unsent messages) and forward them re-encrypted with their real keys. The only notification might be that rekeying warning, if the users have turned it on. In this scenario even the double-checkmarks are present. This is contrary to WhatsApp's claim that even they cannot snoop.
You've just described a "man in the middle" attack. It is endemic to any public key cryptosystem, including Signal and PGP, not just WhatsApp. The notification that you see in WhatsApp, Signal, SSH, PGP, or whatever is the defense.
PS: I just check on my phone if those notifications were turned on. There were not. And I'd never turn those off myself, which leads me to conclude that the rekeying notifications are off by default (in their android app)
Key change notifications are off by default in WhatsApp. That's probably going to be a fundamental limit of any application that serves billions of people from many different demographics all over the world.
Even if they were on by default, a fact of life is that the majority of users will probably not verify keys. That is our reality. Given that reality, the most important thing is to design your product so that the server has no knowledge of who has verified keys or who has enabled a setting to see key change notifications. That way the server has no knowledge of who it can MITM without getting caught. I've been impressed with the level of care that WhatsApp has given to that requirement.
I think we should all remain open to ideas about how we can improve this UX within the limits a mass market product has to operate within, but that's very different from labeling this a "backdoor."
"Various activist groups" setup their own SMS service?
If all you want is for a few hundred people to be able to communicate, you don't need a federated protocol, you just need a VPN. It is much easier to use a centralized service and access it with a VPN than to use a rotating set of hosts across successively blocked federated services. At least when the VPN gets blocked you don't have to rediscover your entire social network when you start using a new one.
Secondly it's not possible because their is not a finish list of providers. By the way 1) everybody should-could be its own provider 2) everybody must use its own domain name DNS to make addresses like greeting@name.
Just to be clear, this is never going to happen. We do not live in a world where computers are for "computer people" anymore. I've been running my own mail server since 1995, and I would not wish it on anyone.
Running my own mail server has not helped me with:
1) Metadata protection. Every email that I send or receive either has Google or Yahoo on the other end of it. Running my own mail server does not help me "own" my data at all.
2) Data protection. Federated protocols can almost never change (look at the history of IRC, XMPP, SMTP, HTTP). Email is stuck in time, which is why emails are still not encrypted. WhatsApp, on the other hand, had the freedom to deploy e2e encryption to over a billion people very quickly.
3) Censorship circumvention. Email is very easy to identify and filter using DPI. In a world where people are only doing host-based filtering, blocking 100 or 1000 hosts is no more difficult than blocking one. Whether or not there is "a finished list," if people can discover these services, so can the censors. It is much easier for the censors to add a single line to a block list than it is for people to switch to an entirely different provider with an entirely different namespace and try to rediscover all their friends.
If your idea is that every time a host gets blocked, everyone could move to a new one and somehow rediscover their entire social network, it would be way easier just to use a centralized service and access it with different VPNs as they are successively blocked instead. That would prevent you from having to rebuild your entire social network each time, but is still a terrible UX.
Can you provide specific historical examples where censorship of federated protocols was difficult or impossible for technical reasons?
I can't see how there is anything technically difficult about it. To the extent that services aren't censored, it's usually either because they're not encrypted (so no reason to block them) or because they're too popular to get away with blocking.
With XMPP and federated messaging servers they would have at least working infrastructure within their country.
Why do you think this is true? I can't see how federation is an answer to censorship. They would simply censor access to all the XMPP providers, just as they're censoring access to all the non-federated messengers.
Is your idea that people would spin up new providers so quickly that the censors wouldn't be able to keep up? Every time people switched, they'd have to rediscover their entire social network all over again, and there's an asymmetry between how difficult it is to get everyone over to different hosts while rediscovering where everyone is vs how easy it is for the censors to add a single line to their block list.
It'd be way easier just to have a centralized host and have people switch VPN providers as they get blocked, since then they don't have to rediscover each-other, but that isn't a great user experience either.
Just like with metadata hiding, really effective censorship circumvention is going to require new protocols and new techniques, so we're going to be more likely to see those emerge in centralized rather than federated systems (that are by their nature difficult to update). I think we'll be able to respond in Signal very quickly.
Reading through the comments that are linked it looks like you mostly had technical concerns about the work. Is that correct?
Clearly the perception of your actions is different than you intend. In your comment here you make it sound like no one had even attempted to do resolve these issues. But that's not what the author of the article believes, and given the public record I'm inclined to agree.
From that original discussion on LibreSignal:
"If the only thing that the remaining people here want out of LibreSignal is a websocket-only solution and gmscore isn't an option for whatever reason, I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services. However, I also realize that still won't help people that are trying to build a Google-free experience on Google's platform, since we still don't have the things we need to be comfortable distributing software outside of Play."
I have repeated that many times. That was June. Nobody has done the work, but plenty of people have written articles like this. The latter is definitely easier.
Your key point is that you're content if people do federation in their own, outside of your domain. That's fair. But what I'm saying is the dream of a federated secure messaging system that's also popular is something which you have the power to chase if you commit to it by making it a core feature of Signal.
Again, we already committed to making it a core feature of Signal, and it was a disaster. We've learned from our mistakes.
If it's something that you think is important, please get involved in the project and come up with a plan to introduce federation in ways that actually deliver on the promise of metadata hiding, anonymity, and censorship circumvention as well as avoid all of the problems that we documented based on our initial attempts.
But "their own needs" are completely out of bounds for you, and it seems pretty clear that this isn't something that's going to be fixed in patches and code, so expecting them to come and fix it because you have an open code base is rather disingenuous.
Many of the things listed in these articles, such as making GCM optional, or supporting distribution outside of Play, are not "completely out of bounds." We've expressly indicated support for them and enumerated the work required, but nobody has committed to doing the work.
I don't expect anyone to do the work, but I do think it's strange when someone from the FOSS community complains that we haven't done it for them.
If you started by promoting Signal as a generic protocol or backend to other projects, it would get much more traction in the FOSS community, as they are attracted to components on which other things can be built.
Signal is broken into three layers, two of which are designed to provide exactly that:
A crypto protocol that can be incorporated into other projects: https://github.com/whispersystems/libsignal-protocol-java
A service protocol that can be pointed at any back end: https://github.com/whispersystems/libsignal-service-java
The service protocol even includes support for federation. I don't think it's a good idea for the reasons I've enumerated, but anyone can use this code to start their own federated network and prove me wrong.
For human and community reasons, the upside to federation is probably a lot higher than you appreciate. I hope you consider it. You have built a nice platform, but for your work to make a lasting impact you need to share it with others.
We've done more than consider it, we've done it. We started Signal as a federated service, and it was kind of a disaster.
I'd definitely reconsider if people have a plan for avoiding the problems that we encountered the first time, beyond "federation is good." In the mean time I'm happy to help anyone deploying Signal in their own federated environment.
I'm repeating myself on many of these points, so I've cut and pasted some of my previous responses:
Signal uses servers controlled by OWS. Other organizations could conceivably operate their own servers because OWS open sources the software, but because OWS strictly opposes federation (meaning the interconnection of independently operated servers which the XMPP protocol (jabber) or e-mail allows), only the users connected to the OWS-run server can communicate with each other.
I've tried to write about why I don't feel like this is going to be a part of our future here: https://whispersystems.org/blog/the-ecosystem-is-moving/
However, I would love it if someone proved me wrong. The Signal clients and server already support federation, so there shouldn't be any technical hurdles stopping the people who are really into federation from using our software to start their own federated network that demonstrates the viability of their ideas.
If anyone needs help doing that, let me know. I'd be happy to help.
If a government does not approve of the use of Signal, it can simply block a single server farm, solving the problem for the state actor, and resulting in total loss of service to the users.
The authors of this article conflate a lot of things with federation. Federation = anonymity, federation = metadata protection, federation = censorship circumvention.
I don't think any of those are true. Email is federated, and I run my own mail server, but almost every single email I send or receive has GMail at the other end of it -- so running my own server does not provide me with any meaningful metadata protection, even though it is a federated protocol. The idea that everyone in the world is going to run their own mail server (or messaging server, or whatever) has not born out in practice, even in environments that natively support federation.
I think serious metadata protection is going to require new protocols and new techniques, so we're much more likely to see major progress in centralized environments that can change rather than federated environments that are stuck in time (in the same way that Signal Protocol is now on over two billion devices, but we're unlikely to ever see even basic large scale email end to end encryption).
In the case of censorship circumvention, I think it's much more common that people use censorship circumvention tools like VPNs or Tor rather than changing their entire federated identifier (and somehow re-discovering their entire social graph doing the same) every time a service gets blocked, particularly since censorship isn't just as simple as host-level filtering these days.
Again, I think we're more likely to see the incorporation of these types of censorship circumvention techniques into centralized rather than federated services.
The community reacted to this by developing a version that does not rely on GCM, however, OWS refused to merge the changes into the Signal code.
I don't believe this is true. To clarify this for casual readers, no data at all is transmitted over GCM. GCM is only used as a push event to tell the Signal Android client to wake up and connect to the Signal server to retrieve messages from the queue if the app isn't in the foreground.
This is pretty fundamentally just how Android works. However, people who want to use Google's OS without any Google services flash custom ROMs onto their devices that are missing this dependency.
I have said many times that I have no problem with supporting these custom ROMs. But I would like someone from that community to submit the PR: "I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
Nobody has done it.
The final point of criticism is that OWS distributes the Signal app exclusively via Google Play while actively preventing the distribution of independent builds.
We'd love to distribute Signal outside of Play, and have written about what we would need to be able to do so. As of yet, nobody from the FOSS community has stepped in to help.
We'll get there eventually on our own, but we have a lot of work on our plate, and have to set our priorities according to what we think is important for Signal as a whole.
The community’s demands for decentralized web services controlled by the users themselves, or by designated professionals elected by the users, seems like a burden to them.
I do not feel like the FOSS community is a "burden," however I do wish they recognized that many of their desires are unique to a very small minority of Signal users. I wish that they'd take more responsibility for manifesting those desires themselves.
This is the second time in two months that someone from the FOSS scene has written up a list of complaints, but as far as I know, in neither case have the authors ever contributed anything to Signal in an effort to meet their own needs.
Say I run the server under my control, and I talk to other people on and off my server via XMPP. What is occuring is my laptop, phone & tablet are connecting back to my XMPP server, which then connects to those clients, thus not leaking my IP address, OS, etc.
Here it seems that you're defining "metadata" as your IP address (and OS?). That's kind of a non-standard definition of "metadata" in this space -- most people approach the topic more concerned about who is communicating with who.
Email is federated, and I run my own mail server, but almost every single email I send or receive has GMail at the other end of it -- so running my own server does not provide me with any meaningful metadata protection, even though it is a federated protocol. The idea that everyone in the world is going to run their own mail server (or messaging server, or whatever) has not born out in practice, even in environments that natively support federation.
I think serious metadata protection is going to require new protocols and new techniques, so we're much more likely to see major progress in centralized rather than distributed environments (in the same way that Signal Protocol is now on over two billion devices, but we're unlikely to ever see even basic large scale email end to end encryption).
If all you want to do is hide your IP address, it sounds like you should just use Tor or a VPN.
Comparatively, as it stands now Google is getting a bunch of metadata on Signal users, such as when messages are sent and received and from which device, IP addresses, OS info, etc.
This is not true. You're referring to GCM? The only thing GCM does is wake up a device to connect to the Signal server when the app is running in the background, nothing is actually transmitted over GCM.
Hmm, I'm not sure where you got these numbers, but none of them are correct. Ten hours of downtime a month? We measure this pretty obsessively, and haven't had that much downtime in a three year period.
I appreciate the sentiment for what you're saying, but our direct user growth has surprised even us (again, not sure where you're getting your numbers), and Signal Protocol is now on over two billion devices.
If your major concerns are reliability and user growth, I think federated protocols are likely to exacerbate rather than improve those conditions -- as we've seen with XMPP historically. However, I would love it if you proved me wrong. Signal can be deployed in a federated environment today, let me know if you need any help setting it up.
The code in question is written in Java, so the type of memory corruption vulnerabilities you're thinking about are not a possibility: https://github.com/WhisperSystems/Signal-Android/tree/master...
I think these types of posts are also the inevitable result of people overestimating our organizational capacity based on whatever limited success Signal and Signal Protocol have had. It could be that the author imagines me sitting in a glass skyscraper all day, drinking out of champagne flutes, watching over an enormous engineering team as they add support for animated GIF search as an explicit fuck you to people with serious needs.
I invite those who have opinions about Signal to start by getting involved in the project. To my knowledge the author of this blog post has never submitted a PR, issue, or discussion post to any of our repositories or forums. Many of these points are things that we would like to address, and we could use the help. The day to day reality of developing apps like these is a lot of work.
To provide some color on a few of these:
Dependency on Google Cloud Messaging
To clarify this for casual readers, no data at all is transmitted over GCM. GCM is only used as a push event to tell the Signal Android client to wake up and connect to the Signal server to retrieve messages from the queue if the app isn't in the foreground.
This is pretty fundamentally just how Android works. However, people who want to use Google's OS without any Google services flash custom ROMs onto their devices that are missing this dependency.
I have said many times that I have no problem with supporting these custom ROMs. But I would like someone from that community to submit the PR: "I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
Nobody has done it.
Your contact list is not private
First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names).
However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack:
https://whispersystems.org/bigbrother/eastern-virginia-grand...
We'd obviously like to do even better. The nice thing about having a centralized service is that we can eventually take steps in this direction. People seem to equate federation with meta-data hiding for reasons I've never totally understood, but I think serious metadata protection is going to require new protocols and new techniques, so we're much more likely to see major progress in centralized rather than distributed environments (in the same way that Signal Protocol is now on over two billion devices, but we're unlikely to ever see even basic large scale email end to end encryption).
Lack of federation
I've tried to write about why I don't feel like this is going to be a part of our future here: https://whispersystems.org/blog/the-ecosystem-is-moving/
However, I would love it if someone proved me wrong. The Signal clients and server already support federation, so there shouldn't be any technical hurdles stopping the people who are really into federation from using our software to start their own federated network that demonstrates the viability of their ideas.
If anyone needs help doing that, let me know. I'd be happy to help.
Wire does not use Signal Protocol, they used some of our code to create a protocol of their own devising that we do not recommend.
Moxie has threatened to shut LibreSignal down if they allow LibreSignal users to message normal Signal users, and refused to even discuss alternative solutions.
Please cite this. To my knowledge I never threatened anything, and your comment is a response to a quote from the discussion about LibreSignal, where I suggest that they submit a PR with the functionality they desire to Signal. Is that not an alternative?
He also uses the GCM library from Google, which pulls in several analytics libraries into the APK
Could you cite this as well? Here's the entire POM file for the version of the GCM library we use:
<?xml version="1.0" encoding="UTF-8"?> <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <modelVersion>4.0.0</modelVersion> <groupId>com.google.android.gms</groupId> <artifactId>play-services-gcm</artifactId> <version>8.1.0</version> <packaging>aar</packaging> <dependencies> <dependency> <groupId>com.google.android.gms</groupId> <artifactId>play-services-base</artifactId> <version>8.1.0</version> <scope>compile</scope> <type>aar</type> </dependency> </dependencies> </project>
A single dependency. If you follow it, the only transitive dependency is the supportv4 library. Where are the "several" analytics libraries?
(And in addition to that, Moxie even refuses to allow any distribution that doesn’t come with full analytics, which is extremely user hostile.)
What do you mean by "full analytics?" Is there something user hostile about having an aggregate count of the number of users you have on what platforms, so that you can develop and deploy software accordingly? About being able to receive crash reports when users choose to submit them so that you can fix their problems?
Wire does not use Signal Protocol. They use a protocol of their own devising that we do not recommend.
Yes, Google has market leverage. However, when IE was Firefox's competitor, MS was in just as powerful of a position, and Firefox was a success. They were a success because they clearly had the better browser.
These days, that's no longer the case. I know that I certainly did not switch from Firefox because of Google's marketing efforts or underhanded tactics.
But what if you're right? In a world where, I agree, it takes an insane amount of money to develop good software, where Google has more of that money than Firefox does, and where Google has really effective market leverage, do the "shoulds" have a chance? Is the future we want even a possibility?
I don't personally think that it is, which is why I wonder what larger changes we would need to see for that to become true.
What always strikes me about these pleas is how familiar they sound. They're reminiscent of all the things we "should" -- eat better, exercise more, lower our carbon footprint -- and I suspect they all see just about the same level of long term success.
Firefox did well when their only real competitor (MS) was actively trying to make their own browser bad in order to preserve the relevance of the desktop OS and their dominance in that area.
Now that they have a competitor (Google) which is actively trying to make their own browser good in order to increase the relevance of online services and their dominance in that area, Firefox hasn't fared so well.
I don't necessarily disagree with the author of this post, but it doesn't seem like moral high ground alone is going to make Firefox any more successful than the other things we "should."
What I wonder about is what larger systemic or structural shifts would have to occur for Firefox and the other "shoulds" of the world to have a chance.