I'm not a linux hater, but as long as it's in linux-land, there won't be much mass adoption. Not necessarily a bad thing, but might as well named it YAXC and tossed it into the list[0] (oh turns out Dino is on the list and there's already something called YAXIM)
What's the point in this comment? What good do you possibly think could have came from saying that? Not only are you pointing out something that they have already considered, you're pointing it out in an arrogant way, right after they say that they had already considered it and wanted something that would render your comment void, and on top of that, you end it with insulting the project.
I'm genuinely fascinated: what was your mindset when posting this?
I'm actually more interested in an explication for the mindset behind this comment's condescending tone.
It's a fair enough comment to make — the notion that mass adoption comes by catering to the masses is not one that should be so readily dismissed with a downvote and aggressive italicisation.
In a discussion of an XMPP client that's specifically designed for mass appeal, in this modern world of iMessage, Facebook Messenger, WhatsApp, Slack, and Discord, it's a perfectly reasonable point to bring up.
What is the reason to enforce a specific root domain?
tls-sni-02 requires the generated self-signed certificate to contain an additional subjectAltName (SAN B) that is not send as part of the request and thus only known to the actual client, not to any host that automatically generates self-signed certificates (if such hosts exist).
A web host or CDN might allow arbitrary domains to be added, and arbitrary certificates to be uploaded for said domains, all without any validation. That would ... not be my favourite implementation, but if you didn't know about how the Web PKI and ACME works, that's an implementation you might come up with and not expect a whole lot of issues.
However, it's unlikely that the web host would allow you to do this for a domain already associated with an account, or a subdomain of such a domain. Unlike the first case, this would effectively allow an attacker to fully control any subdomain, so even without any Web PKI involvement, that would be a vulnerability in and of itself.
It remains to be seen what the two affected providers were actually doing, and I don't really have enough data to make a call on whether it's actually worth changing this aspect of tls-sni-02, but it's something to consider.
If it was about the features, they could (and should) have released these bits as part of AOSP, as free software.
Not doing so reveals there actual reason: control. Forcing every manufacturer to ship Play Services and thus being able to force various things on their devices is a major financial benefit. It also ensured that Amazon or Nokia were unable to set up a commercially viable Android Fork without Google.
Actually it's not trivial to change server APIs because they don't fully control all the clients (not even all officially supported ones).
For example: push notifications are supposed to work without setting up a Google account (if you use a certain Android version). But if you don't log in to your Google account, you're not receiving updates through Play Store, and thus Google can't update the client. Google breaking their claim will upset some of their users (probably not the typical smartphone users, but think of entertainment systems based on Android for example).
Also note that most Google ToS don't specifically forbid third party usage (and some also specifically allow them), the only thing that's forbidden is to misuse APIs in a harmful way. Just another example would be the login/account management part of microG, that uses the publicly described OAuth APIs, obviously intended for third-party use.
It seems like such a small one method change, in the context of forking an entire distro.
I wonder if PackageManagerService is hard coded in many places, rather than using XML dependency injection. If the latter then may it be possible to override the method in a subclass, e.g. MicroGPackageManagerService and distribute the change via a once-only installable zip?
That way Lineage OS doesn't need to break security, only downstream.
Just to be precise: Google and Facebook did not shut down their xmpp servers, they just disabled the ability to connect to them via xmpp clients, to make sure everyone uses their web clients, so they don't loose any data they could've collected otherwise...
The original Google Talk ifnrastructure is still up and running and clients can connect to it using a protocol derived from XMPP (basically a subset XMPP converted to protobuf) and use it to message devices (Android uses it push messaging, but technically you can also send messages directly between devices). It's not directly used for text messaging though.
Beside that, Dino does support peer-to-peer file transfers using Jingle.