Author here: Indeed, 15% is fine. They do provide some services. They provide the CDN for downloading the APK. They handle sales taxes in the various countries, which would be a PITA to handle yourself. Similar-ish services like Patreon charge a fee too. The 30% they charged a couple of years back was bad. But I could live with 15% if the support were anything other than zero.
The problem is that it ISN'T a fee for services as it should be. Their platform power means that they can levy a tax, and they don't feel the need to do anything on exchange for that.
Yep, I'd hypothetically economically gladly build an alternative app store charging "only" 5% on app revenue. The blocker would be that Google has a hold on what store is installed by default on Android. Apple even more so. This is hardly a fair market.
There are other app stores on Android, e.g. OEM ones like the Galaxy store. The latter doesn't really compete on price though - 20% cut of one time payments and 15% of subscriptions. I think the Android app stores anchor to the iOS app store prices to piggy back on Apple's monopoly power - devs are used to having to pay Apple that much, so they will not resist if you charge the same.
Google is not developing Android for the IAP fees, they're doing it to sell phones loaded with their search, advertising, browser and services. They take hundreds of billions in revenue annually from this, they are being paid several times over for that work even if they get no IAP fees.
The speed of government is slow, incredibly slow. It's measured in election cycles. It takes government eight, twelve years to simply turn around and notice. But once it does, it's a juggernaut.
Nothing can stop it. Nothing can avert it. Nothing can prevent it. And as everybody from Facebook to Microsoft knows, once it starts moving, you're screwed.
In the US, the oil companies thought they were too big. Then the telco companies thought they were too big. What really happens is eventually people just get pissed off, and then it's too late.
Google is fast approaching that. They almost had chrome and other things ripped away from them, and now they've got requirements to have alternate play stores. If they don't turn course, and turn course blazingly fast, they're going to have their entire empire wrenched away from them.
> If they don't turn course, and turn course blazingly fast, they're going to have their entire empire wrenched away from them.
Unfortunately, that's no longer the case with the app store monopolies. While Apple is under some partial enforcement on parts of their app store policies, Google managed to play the game of regulatory brinksmanship better and largely avoided that for their app store. So the regulatory powers (such as they are) have already taken their best shot and this is where we are.
There is now a record of this. The next action against Google, will see people pointing out each step they took to avoid compliance.
A case a year down the road about AI, will see stubborn attempts to comply like the above cited.
Google, with the gold plated shovel, digging a hole for itself. Put another way, breaking up a company typically comes after other methods don't work. Such as being sneaky and making them not work.
Or even because the required competition didn't occur, regardless of fault.
It's not over. It's a step taken, with a positive outcome, and a judge who is making sure there's follow through. Next step will be more stark.
They also say they generate $57 billion ad revenue from being default search engine on iPhone, so obviously there is a cash value to being the default search (and everything else) on Android too even if their accountants can finagle reasons that doesn't contribute to Android's development costs.
If they didn't develop Android they'd be paying $10s of billions annually for the prime positioning their apps and services and search enjoy too, so even if you buy their accounting tricks the development is paying for itself many times over.
If Android did belong to someone else then there could be an argument that IAP fees are funding it and subsequently required, perhaps even under less-than-competitive circumstances.
But if the court allowed, Google would be paying that company $10s of billions for the prime real estate their software, search and services enjoy and it would then be a very weak argument that only IAP funds its development. Just like it is when Google earns $100s of billions in revenue from Android now.
Would it be OK for Microsoft to prevent Steam from running on Windows because Valve doesn't contribute enough to funding the Experiences and Devices org? I've never really understood why mobile platforms should be different from how we think about desktop ones.
Parasitic? Writing software for folks' devices and selling it isn't parasitic...it's just participating in the market. Weird that the overton window has moved so far that anything not built by the trillion-dollar duopoly is considered some kind of free-rider.
It's not weird - you've just completely misunderstood the situation. This is about the OS, which the software in question (the alternate app store) relies on, but generates no revenue for. The devices are still being sold, because their manufacturers are allowed to make money, the alternate store is allowed to make money. Only the OS maker will make no money, because that would be bad.
what you are arguing for is objectively extremely bizarre. if you take a step back, this is what is playing out: company C makes a device. it needs an operating system to run software, so they add it. if there was no operating system the device would be useless and no one would buy it. now person A buys said device. it's theirs, they have paid money for it, they own it. person B writes some software. it runs on the device's operating system. they want to sell it to person A. person A wants to buy it from them. why should company C be involved at all? I found this super weird and distasteful when game consoles were allowed to use this business model, and am even more taken aback that general purpose computers get away with it.
You seem to imply Google was forced to open source Android or even to give it for free: sounded like it was a purely business decision to capture more of the market.
Now that they have, they are also turning around on bits of that too.
That trillion dollar duopoly is probably the worst case of free riders. It’s an enabler/vehicle for all the other billion dollar free riders to steal from the population.
theres nothing parasitic about a competing app store.
it is parasitic to try and prohibit competing app stores and then leverage your monopoly by charging monopoly prices.
everything google is trying to do to discourage graphene, newpipe, competing app stores, etc. is parasitic and it's right that they are being fined by the EU for this behavior.
> theres nothing parasitic about a competing app store.
I think a more honest way to say this might be: Android OS development is massively funded by Google, and the Play Store feeds into this hugely. No other store does this, so it shouldn't be surprising that they can charge a lower fee. They're just doing the easy bit.
It is rent extraction which always feels like bullshit because it is. Competition is supposed to be the counterbalancing force but it barely exists here.
The basic services Google provides can effectively only be consumed by humans individually, creating an inevitable bottleneck.
Such bottlenecks impede interchangeability of goods, as you can't reasonably entertain multiple suppliers simultaneously there. And that means, you cannot have a free market, because you can't really have meaningful competition.
Google has captured services that really are public utilities. Them being "new" doesn't play a role.
Apple recently submitted in court filings that you'd have to pay ~8% for off-the-shelf solutions like Stripe or Paddle to be Merchant of Record anyway so 15% isn't really bad except for the high-earning apps, but Google should be doing something for that extra 7%.
It's a level of service above their payment processing, where they also collect and remit certain taxes which I believe is built-in to that ~8%. This is the same service that Google and Apple provide for in-app payments.
> Stripe and Paddle are leading full-service, turnkey payment processing, and merchant-of-record providers handling all the services necessary for link-out, including payment processing, tax compliance, fraud detection, and customer service. Across the top apps, the mean implied processing and merchant-of-record fee based on Stripe’s and Paddle’s rack rates (which few, if any, large developers actually pay because they negotiate discounts or provision in-house) is 8.1% using Stripe rates, or 7.8% using Paddle rates.
XMPP at 11 years old would place us in the year 2010. Requirements were different in those times. Psi on my desktop and Bombus (a J2ME client) on my Nokia E71 worked great. The transition from that into the mobile-first age was rough though. The article says that too. It only improved in 2014-2015.
Everyone says this and so I believe them, but I used xmpp as my primary communication tool through the whole thing and it worked ok on my first android phone (HTC magic) and amazingly on my n900 followed by acceptably on my BB10 device and never had any issues
Indeed. And on a Google-free Android phone the XMPP client Conversations can utilize its existing, permanent XMPP connection to deliver push notifications to other (mostly open-source) apps using an alternative to Google push (FCM) called UnifiedPush.
XMPP these days often gets used as a friends-and-family style messenger (Think WhatsApp, iMessage, Signal replacement) rather than something communities would use (Discord/IRC). A lot of users of XMPP are also out of the public eye. NATO, police forces and intelligence agencies use it. The community style channels are supported though and a search engine for them can be found here: https://search.jabber.network/channels/1
The existence of "XEP-0365: Server to Server communication over STANAG 5066 ARQ" suggests military usage. Isode advertises XMPP as "The NATO Standard for instant messaging" (https://www.isode.com/secure-xmpp/) and it is one of their core offerings. I remember seeing NATO command posts using IRC long ago - makes sense because it is ultra light, and therefore usable on extremely low bitrate degraded links... XMPP seems to be the successor for that purpose.
https://www.sigidwiki.com/wiki/XMPP_trials says "On shortwave, you can see the military use this protocol. They are known for using MIL 188-110A Serial HF waveform (fixed 600bps/S) and 6-bit code clear text with dual bursts of STANAG 4539 and STANAG-5066 as for XMPP Multi-User Chat (MUC) messages, over a bandwidth of 34 kHz. Multi-User Chat (MUC) is a central service for military communication. [..] XMPP is widely used for military deployments, where operation over constrained and degraded networks is often essential, particularly for tactical operation"
Thanks! That was exactly the kind of "hidden usage" I was interested in as it seems to not be publicly used by a lot of people these days (As you can see by the user numbers on https://search.jabber.network/channels/1).
The blog post you are referencing explains the changes the XMPP community has to do to keep up with what Lets encrypt did. TLDR: People just need to upgrade their servers.
Maybe the first but not the only one. Ltt.rs (an email client using JMAP) does this as well. BTW you can also directly deliver WebPush notifications to FCM servers. No need for a proxy/rely run by the app developer.
Ltt.rs has support for both UnifiedPush and FCM and is fully open source. The code difference between UP and FCM is very very minimal since - as I said - both are just WebPush endpoints.
Signal, Matrix, Telegram, XMPP; Use whatever you want. But there is a lot of FUD if not outright lies in that blog post. The author looked at Conversations for all but five minutes, desperately trying to dig up some dirt.
* Conversations uses two different OpenPGP implementations. (It doesn’t)
* The auth tag truncation was 'silently' introduced in the spec. It wasn’t. The author retracted that but only barely
* ominously pointing out that Conversations has a SASL implementation (In fact Conversations can use that to detect some MITM attacks; which is pretty cool)
* ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
> * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
It's trivial to use TLS without writing your own certificate parser. Doing this means taking on a lot of unnecessary risk, such as CVE-2023-33202.
Your encrypted messaging application shouldn't need to have a separate X.509 or ASN.1 parser built into it. If you're going to use them from TLS, you should rely on the library your OS vendor maintains for you, since they have an incentive to keep theirs secure anyway.
"Ominously pointing out" that the Conversations project has taken on an unhealthy amount of complexity and risk isn't FUD, it's a criticism of how the project is managed. Confuse the two at your own peril.
There are certificates that are valid for the XMPP domain example.com but not for the regular (HTTP) server on example.com. Off-the-shelf verifier don’t have support for that.
With an up to date Conversations on a modern server we have a pretty good chance to detect or prevent that style of attack due to a mechanism called SASL Channel Binding.
JMAP (IMAP+Submission replacement) has support for WebPush. If I have a minute I’ll implement UnifiedPush in https://Ltt.rs - Sadly JMAP doesn’t have a lot of server implementations. (Yet? Maybe)
That'd be quite cool :) I've been using maddy for a self hosted mail server, itd be nice to replace it with stalwart and give ltt.rs a try... and convince the hosted mail i use to start using a JMAP supported server
AFAIK Cyrus has JMAP support. We are using it for more than 20 years at work without any issues. However, we are lacking compelling client support for JMAP (via using SoGo via IMAP currently). Would be great to have a good static webclient for security reasons. Configurable notifications would be another plus.
reply