Google prevents the developer of WireGuard from linking to the donation page of the project from their Android app, threatening the funding of open source apps maintained by independent developers.
Anti-trust action can't come fast enough. Mobile platforms have been held hostage by Google and Apple for over a decade now, and costs haven't gone down at all.
Google allows 3rd party app stores and direct installation of apps on Android. If not allowing a donation link is an issue the author is free to distribute the Wireguard app purely through other means.
Google has hindered Android such that app stores cannot compete with the Play Store on feature parity. App stores cannot implement batch installs, background installation or updates, or automatic upgrades, but the Play Store can.
I'm sorry, but that is not true at all. The altnerantive stores available on current phones (Samsung, Huawei, etc.) have all the capabilites of the builtin store.
For all the crap Google does, you really don't have to make things up :/
Rooting phones or installing strange ROMs from XDA-Developers isn't something normal users are capable of.
If I buy a LG phone, can I install the Samsung or Huawei store and use the features that the Play Store has without rooting my phone or using a weird ROM?
Why is it that if I want to use an app store that works on every Android device like F-Droid, I need to root my phone to have some feature parity with the Play Store?
> Why is it that if I want to use an app store that works on every Android device like F-Droid, I need to root my phone to have some feature parity with the Play Store?
Because silently replacing software on your phone is a very problematic safety vector.
To the point where Apple doesn't allow granting that to anyone ever.
Sometimes security features are a blunt hammer and it takes time to develop a more nuanced solution. And if it's everything as reported, Android 12 will include this ability.
I think they're referring to the fact that as a user you cannot install a third-party app store with the same capabilities as Google Play, F-Droid can't install apps in the background on a non-rooted device.
Device manufacturers are of course allowed to ship with alternative app stores, though Google is also trying to interfere with those decisions by holding access to Google Play Services as ransom, even if the practice was previously deemed illegal by the European Union.
That doesn't change the fact that alternative stores (which exist on many devices) are allowed to install all packages and autoupdate them.
Just _your pet_ store doesn't get it because silently replacing app packages would be a horrible security hole for software. Nevertheless, F-Droid will be able to do just that with Android 12.
Common. Its like saying I will give you earth but no water no winds. Using andriod for monopoly is issue here. Google Playstore can do anything. Its literally the most bloated thing in andriod. And they force mobile vendor like xiomi/samsung to install their playstore. They are just doing what internet explorer 6 thing did.
Other stores exist only because Android is open source and any manufacturer can install whatever they want and give any app the features they feel it needs.
But there is no way for an app store app to just generally work on all Android devices in an optimal way, without special blessings from all the manufacturers.
Are you referring to their respective vendor stores? If so that's not really relevant to the point. A phone vendor can of course get all those capabilities into their own phones. But can I as a consumer install a third-party store on whatever phone I have with those capabilities?
Sure, the manufacturer can install their own app store with those features, but that isn't the point. The point is that an end user can't install a third-party app store with those features, at least not without going the root/custom ROM route.
> app stores cannot compete with the Play Store on feature parity
The response was:
> that is not true at all
There are plenty of follow up remarks that then clarify that it is infact true in some cases (e.g. F-Droid today) and not true in others (e.g. Samsung store today).
One of the claims made is that it's a security issue to allow alternative stores to silently replace software on your phone (also known as auto updates), and also that this feature is coming in Android 12.
It sounds like Android 11 does not allow a fair level playing field (for what may be justifiable security concerns), and Android 12 throws those security concerns out of the window.
Can someone with knowledge on the subject help clarify?
Google has used security as a red herring repeatedly to restrict user rights and suppress the competition, and now they will offer better integration for third-party app stores in Android 12, because governments around the world are breathing down on Google's neck.
True they are just trying to avoid due to government intervention but they will do slowly anyway. But I know andriod 12 third party will definitely comes with many hiccups so user are forced to use playstore anyway.
As a user, I don't care why they're implementing it, only that it's available. I've been complaining about this exact problem for years, so I'm happy that it is finally getting resolved (if it is getting resolved — Google's statements about what Android 12 will allow have been pretty vague).
Also, as far as I know, Google hasn't used the security excuse for not implementing it. I just assumed that this wasn't going to get prioritized over OS features that enable Google to make more money.
> Can someone with knowledge on the subject help clarify?
Installing apps silently (as an app store) requires so-called "Privileged" Android premissions currently. Privileged permissions are only attainable by apps that are preinstalled on Android distribution - which means that Samsung/Huawei/other stores can get it, but it's not available for apps that aren't part of original OS distribution.
So the playing field isn't level for ALL the potential Stores - Google gives these privileges to the OEMs that built the devices and them only.
Android 12 will add a mechanism to get these capabilities but it's currently not clear how (whether it's a permission on first run, or whether it's going to be available to a single app like the SMS related permissions).
Almost. Just that it's the OEMs that choose to implement AOSP default privilege scheme to please Google so it gives them access to Play Store and all the other Google apps.
IMHO the leverage is all on the OEM side, they just choose to focus on hardware and allow Google to manage the software.
Independent stores is something that was not really a thing before Android so we are figuring out as we go.
Debian third party repos probably come close, but that is for tech savvy folk that know that they are doing. Now design that for your grandma.
Only apps placed in /system/priv-app can install other apps in the background. The only way to add an app there is to be Google or a phone manufacturer, or be an end user, root your phone, and modify the filesystem (directly or through Magisk mounts). Users of unrooted phones can't install apps with the ability to manage other apps.
Having an F-Droid version that costs nothing but has a donation link and a Play Store version that is not free is a common monetization pattern for open source projects on Android. See also:
The problem is this is a very inefficient donation: A third of it goes to a greedy for-profit corporation that actively causes societal harm.
If you're using Play Store credit for it, sure, nobody but Google is paying the bill. But for everyone else who buys the app, it's a pretty poor donation method.
> The problem is this is a very inefficient donation:
How is it inefficient? Google gave me that money for free, and I sent 70% of it to the project and 30% back to Google.
> A third of it goes to a greedy for-profit corporation that actively causes societal harm.
Also wrong. Less than a third of it goes to anybody but the app publisher. Of the 30% that doesn't go to the app publisher, some portion goes to the payment processor (usually card processor or mobile service provider, only Google if you pay with credits).
> But for everyone else who buys the app, it's a pretty poor donation method.
They can also donate via F-Droid, as I showed in my post. The fact that it costs anything at all on the Play Store encourages users to get the app from the author directly or from F-Droid, both of which give the app away for free and can show preferred donation links. They get to benefit from wide distribution and discovery via Play Store and better monetization via donation links. Compare to iOS, where the open source authors are screwed.
Luckily, new grassroots mobile platforms are sprouting up. I ordered a PinePhone[0] to tinker with. One can dream that a robust mobile Linux community will one day flourish, free from these corrupt monopolies.
Yeah, these stores should really have a mode where you opt-out from their advertising and billing services. Instead they should just issue the developer an invoice for bandwidth / store costs and not try to leech on their earnings.
Until there's a big run on some app, the developer didn't expect the enormous popularity and increase in cost and then they blog about how Google is basically bankrupting them.
Assuming the app is 10 MB, 100 million users (out of 2.5 billion Android users) download it once (not 10 times as you suggested), that's one million gigabytes of traffic.
Using the cheapest Google Cloud Storage egress rate of $0.08/GB, that's $80000 for each update the app pushes out.
Wireguard is 7.6MB. I thought even smaller since the article mentions the kernel extension was only around 4000 lines of code, but I guess the Android app is a bit more complex or pushed up by static dependencies and icons and stuff.
At 10MB and $0.08/GB (which is really high FWIW, cloud providers overcharge for bandwidth like crazy), the cost per user is $0.0008. Meanwhile with ads on your own website you can get paid something like $0.002 per user. So if you could distribute the app on your own website and put an ad on it, you would get paid $120,000 for having a hundred million people download it for free. Even more if you use P2P distribution.
But by forcing you to use their store, you lose money.
Which is why it makes sense to distribute updates P2P. I'm a little surprised that nobody has already written an update framework that does this for desktop applications -- if the applications themselves are signed with a key contained in the original download then you can securely receive an update from any host, which means that each client only has to upload the package an average of once (i.e. it costs them on average a fraction of a penny in bandwidth), and the same for the original source.
Some games already do this because they're so large, but it would make a lot of sense to factor it out so that multiple applications could use it.
If you're optimizing for bandwidth costs, I certainly wouldn't be using Google Cloud Storage or AWS, either. You're paying a premium for egress traffic with both of them.
This is kind of a false dichotomy, though. I doubt anyone would be developing their own CDN from scratch to distribute their app. In a world where other companies are allowed to enter the app distribution market and compete with Apple and Google, competition could finally drive costs down. There's no reason that instead of giving Google 30% of your revenue, you couldn't go with a company that is able to distribute your application more efficiently and at a lower cost to you.
The premise was "these stores should really have a mode where you opt-out from their advertising and billing services. Instead they should just issue the developer an invoice for bandwidth / store costs".
At that point, the (expensive) GCS rates are exactly what you'd get.
WireGuard is a great example on how to do marketing for developers. It starts with technical elegance, something that speaks to us. Then great transparency and communication with no bullshit. And finally a lot of hard work.
With that in hand, the project will be propagated automatically through organizations where developers have a say in the decision making process.
I have mixed feeling about this: it looks like the author believes only him can implement it right [1].
This not how internet protocols development work. The spec should be enough, including security considerations. And multiple competing and interoperable implementations should be seen as a good thing in my opinion.
> And multiple competing and interoperable implementations should be seen as a good thing in my opinion.
How is that a good thing? We all understand and agree how IPv4 and IPv6 works (mostly), and how HTTP works, and how (mostly) the networking layer works.
Introducing more competing standards leads to a complete mess, have you seen USB lately? USB-4 and its optional components, USB 4 gen 2x2 and USB 4 Gen 3X2 but there's also USB 4 Gen 3x1 and Gen 3x2 as well as 3x3 and 3x4, except I am lying about the last two, or maybe the first two? I can't remember the standards are confusing.
Oh, that USB-C cable bricked your Nintendo Switch? Oh the Raspberry PI screwed up their type-c implementation?
Yup, competing standards are amazing, especially when they compete with themselves!
I agree with what you're saying partially, but at times you do need someone who can make a decision and be the decider of how things work.
Do you really think you could type in this textarea today without people deciding that? I am sure of the 100's of processes involved in using a computer, writing in this text area, clicking "post" (http, browser, the OS, kernel, drivers, even electricity itself, ISPs, etc etc) somebody made a decision and that was that.
We couldn't use the internet without a person being a dictator somewhere in the chain.
Ipv4, 6, html, css, and javascript were all implemented many different ways, and while sure it was annoying for web developers, the alternative was everyone uses google's browser. That's pretty much how it is now and I don't like it.
I think there is a reason for that, and this is a topic that calls into question more than just computers but human nature itself.
The older web was dominated by competing standards and companies trying to get the "edge" (pun intended), as shenanigans are afoot trying to keep 'your browser' in the lead. IE6 and those days were absolutely horrible.
Of course, the downside (or upside, depending how you view it) is that whatever Google does is now the standard. AMP? Standard. Web APIs? Our implementation is how it is.
Whether we're better off or not remains to be seen. But it sure beats having 20 different types of "USB" standards on the front of my PC from 15 different stakeholders.
At least today when I buy my new external HDD it uses USB, I plug it in, and it "just works". We wouldn't be saying that intrinsically if there were loads of competing standards.
(Whose to say the Linux kernel wouldn't be involved in a fight between $competingComapnies trying to cripple each other? We see tricky things in the kernel from time to time, See [1] and [2])
I am not advocating for competing standards. I am advocating for open standards and competing implementations.
Both of your examples point to competing standards: IE6 was a tentative to fork the web standards by Microsoft. The 20 USB form-factors are different connector standards (even if they all implement the same wire protocol).
> > And multiple competing and interoperable implementations should be seen as a good thing in my opinion.
> How is that a good thing? We all understand and agree how IPv4 and IPv6 works (mostly), and how HTTP works, and how (mostly) the networking layer works.
And each platform has its own implementation. The specification is the same, the implementation is different in each case.
It's not the same TCP stack in Windows as it is on a Mac. There are multiple TCP implementations that exist for Linux. Each browser implements it's own HTTP stack.
> Introducing more competing standards
The GP isn't suggesting there should be more competing standards, the GP is suggesting there should be more competing implementations of the same standard.
> have you seen USB lately
USB is a mess. I don't think anyone will disagree with what a fustercluck USB-C + USB3 are.
> Oh the Raspberry PI screwed up their type-c implementation?
Raspi foundation screwed up in the reading of the spec, implemented an error, identified the error, and have resolved it. The implication in the comment is that people cannot be trusted to perform their own implementations of standards, and need to acquire implementations from the one true source. If that were the reality, the cost of the RPi4 would probably be higher.
> Oh, that USB-C cable bricked your Nintendo Switch?
This is particularly tragic. The Nintendo Switch doesn't have a USB-C port. It has a port that is dangerously similar to USB-C. 100% on Nintendo for doing this, and absolutely not the fault of the consumer who sees a port that looks like, and generally works with, USB-C, but is not. Nintendo absolutely should have done better here.
I haven't seen that Wireguard has a single developer. Sure there is tight control of the protocol (which is a good thing), but the various implementations are being worked on by different people.
I you read the thread on NetBSD mailing list I linked to, that was exactly my concern: the spec does not seem to be enough to implement the protocol according to the original author but he seems reluctant to give details.
And I do not consider NetBSD core team as amateur, frankly.
I actually just got done reading the thread. That was an interesting read.
This has happened a few times. First with TunSafe, I think it also happened with CloudFlare's WG implementation, etc. The idea that a third party unsupported implementation shouldn't count.
I think this is a case of the message being lost in the tone. As a user of Wireguard, I definitely don't want to think about whether this is an official implementation. But having many competing implementations is exactly what would cause confusion (imagine a news article talking about how someone overcame a Wireguard exploit to get into a network).
It's like having 20 different apps that claim to be compatible with Signal. I'd have no idea which ones have gotten the same amount of rigorous testing. Fragmentation in these kinds of areas (especially when the original project is itself open source and hasn't stagnated) can often make things worse by causing even a little bit of doubt or hesitation.
Fine? The spec is not enough to implement the protocol. Right now, it's not meant to be implemented from its spec. The spec documents what the protocol is doing, because you want to know that in order to analyze it. It's not meant to facilitate clean-room interop.
WireGuard isn't an IETF protocol. In fact, it's a repudiation of IETF protocol design.
Right now, you should use WireGuard implementations Jason endorses, and avoid implements he expresses concerns about.
Slightly off-topic, but related because this happens to me on wireguard VPN through their (excellent) app.
It seems like the VPN connection is not shared to devices if I allow them to connect to my phone's hotspot. This is annoying, because I have a number of devices that ephemerally use the hotspot, and for which it is quite a hassle (impossible) to individually set-up and whitelist a keypair. Is this something that would be fixed with the inclusion of Wireguard as an android native VPN protocol?
A lot faster than OpenVPN? How did you measure it? In my experience the handshake is faster, but I haven't measured anything so I wouldn't know with certainty.
74 comments
[ 2.6 ms ] story [ 67.1 ms ] threadNeat. I might try that.
https://news.ycombinator.com/item?id=21268389
And also, they put up a big sign telling everyone it's dangerous to go to North Dakota so stay out.
That's such an apt analogy, considering that Google Play Protect will helpfully offer to remove sideloaded apps every chance it gets, citing security.
For all the crap Google does, you really don't have to make things up :/
If I buy a LG phone, can I install the Samsung or Huawei store and use the features that the Play Store has without rooting my phone or using a weird ROM?
Why is it that if I want to use an app store that works on every Android device like F-Droid, I need to root my phone to have some feature parity with the Play Store?
Because silently replacing software on your phone is a very problematic safety vector.
To the point where Apple doesn't allow granting that to anyone ever.
Why can't I do what I want with my computer???
Device manufacturers are of course allowed to ship with alternative app stores, though Google is also trying to interfere with those decisions by holding access to Google Play Services as ransom, even if the practice was previously deemed illegal by the European Union.
https://www.theverge.com/2020/8/13/21368395/fortnite-epic-ga...
https://ec.europa.eu/commission/presscorner/detail/en/IP_18_...
Just _your pet_ store doesn't get it because silently replacing app packages would be a horrible security hole for software. Nevertheless, F-Droid will be able to do just that with Android 12.
This must be stopped.
The third-party stores will get these capabilities with Android 12.
> app stores cannot compete with the Play Store on feature parity
The response was:
> that is not true at all
There are plenty of follow up remarks that then clarify that it is infact true in some cases (e.g. F-Droid today) and not true in others (e.g. Samsung store today).
One of the claims made is that it's a security issue to allow alternative stores to silently replace software on your phone (also known as auto updates), and also that this feature is coming in Android 12.
It sounds like Android 11 does not allow a fair level playing field (for what may be justifiable security concerns), and Android 12 throws those security concerns out of the window.
Can someone with knowledge on the subject help clarify?
Also, as far as I know, Google hasn't used the security excuse for not implementing it. I just assumed that this wasn't going to get prioritized over OS features that enable Google to make more money.
Installing apps silently (as an app store) requires so-called "Privileged" Android premissions currently. Privileged permissions are only attainable by apps that are preinstalled on Android distribution - which means that Samsung/Huawei/other stores can get it, but it's not available for apps that aren't part of original OS distribution.
So the playing field isn't level for ALL the potential Stores - Google gives these privileges to the OEMs that built the devices and them only.
Android 12 will add a mechanism to get these capabilities but it's currently not clear how (whether it's a permission on first run, or whether it's going to be available to a single app like the SMS related permissions).
IMHO the leverage is all on the OEM side, they just choose to focus on hardware and allow Google to manage the software.
Independent stores is something that was not really a thing before Android so we are figuring out as we go.
Debian third party repos probably come close, but that is for tech savvy folk that know that they are doing. Now design that for your grandma.
https://play.google.com/store/apps/details?id=net.gcompris.f... vs. https://f-droid.org/packages/net.gcompris.full
https://play.google.com/store/apps/details?id=com.mkulesh.mi... vs. https://f-droid.org/packages/com.mkulesh.micromath.plus
When Google gives me free Play Store credit, I often "donate" it this way.
If you're using Play Store credit for it, sure, nobody but Google is paying the bill. But for everyone else who buys the app, it's a pretty poor donation method.
How is it inefficient? Google gave me that money for free, and I sent 70% of it to the project and 30% back to Google.
> A third of it goes to a greedy for-profit corporation that actively causes societal harm.
Also wrong. Less than a third of it goes to anybody but the app publisher. Of the 30% that doesn't go to the app publisher, some portion goes to the payment processor (usually card processor or mobile service provider, only Google if you pay with credits).
> But for everyone else who buys the app, it's a pretty poor donation method.
They can also donate via F-Droid, as I showed in my post. The fact that it costs anything at all on the Play Store encourages users to get the app from the author directly or from F-Droid, both of which give the app away for free and can show preferred donation links. They get to benefit from wide distribution and discovery via Play Store and better monetization via donation links. Compare to iOS, where the open source authors are screwed.
I think that is only with respect to App / Play Store policy? Otherwise every part of Smartphone has seen substantial price reduction.
[0] https://en.wikipedia.org/wiki/PinePhone
Using the cheapest Google Cloud Storage egress rate of $0.08/GB, that's $80000 for each update the app pushes out.
At 10MB and $0.08/GB (which is really high FWIW, cloud providers overcharge for bandwidth like crazy), the cost per user is $0.0008. Meanwhile with ads on your own website you can get paid something like $0.002 per user. So if you could distribute the app on your own website and put an ad on it, you would get paid $120,000 for having a hundred million people download it for free. Even more if you use P2P distribution.
But by forcing you to use their store, you lose money.
Using a CDN will drive down your delivery costs.
Some games already do this because they're so large, but it would make a lot of sense to factor it out so that multiple applications could use it.
This is kind of a false dichotomy, though. I doubt anyone would be developing their own CDN from scratch to distribute their app. In a world where other companies are allowed to enter the app distribution market and compete with Apple and Google, competition could finally drive costs down. There's no reason that instead of giving Google 30% of your revenue, you couldn't go with a company that is able to distribute your application more efficiently and at a lower cost to you.
At that point, the (expensive) GCS rates are exactly what you'd get.
With that in hand, the project will be propagated automatically through organizations where developers have a say in the decision making process.
This not how internet protocols development work. The spec should be enough, including security considerations. And multiple competing and interoperable implementations should be seen as a good thing in my opinion.
[1] http://mail-index.netbsd.org/tech-net/2020/08/thread1.html#0...
How is that a good thing? We all understand and agree how IPv4 and IPv6 works (mostly), and how HTTP works, and how (mostly) the networking layer works.
Introducing more competing standards leads to a complete mess, have you seen USB lately? USB-4 and its optional components, USB 4 gen 2x2 and USB 4 Gen 3X2 but there's also USB 4 Gen 3x1 and Gen 3x2 as well as 3x3 and 3x4, except I am lying about the last two, or maybe the first two? I can't remember the standards are confusing.
Oh, that USB-C cable bricked your Nintendo Switch? Oh the Raspberry PI screwed up their type-c implementation?
Yup, competing standards are amazing, especially when they compete with themselves!
I agree with what you're saying partially, but at times you do need someone who can make a decision and be the decider of how things work.
Do you really think you could type in this textarea today without people deciding that? I am sure of the 100's of processes involved in using a computer, writing in this text area, clicking "post" (http, browser, the OS, kernel, drivers, even electricity itself, ISPs, etc etc) somebody made a decision and that was that.
We couldn't use the internet without a person being a dictator somewhere in the chain.
The older web was dominated by competing standards and companies trying to get the "edge" (pun intended), as shenanigans are afoot trying to keep 'your browser' in the lead. IE6 and those days were absolutely horrible.
Of course, the downside (or upside, depending how you view it) is that whatever Google does is now the standard. AMP? Standard. Web APIs? Our implementation is how it is.
Whether we're better off or not remains to be seen. But it sure beats having 20 different types of "USB" standards on the front of my PC from 15 different stakeholders.
At least today when I buy my new external HDD it uses USB, I plug it in, and it "just works". We wouldn't be saying that intrinsically if there were loads of competing standards.
(Whose to say the Linux kernel wouldn't be involved in a fight between $competingComapnies trying to cripple each other? We see tricky things in the kernel from time to time, See [1] and [2])
[1]: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-L...
[2]: https://www.phoronix.com/scan.php?page=news_item&px=Linux-59...
Both of your examples point to competing standards: IE6 was a tentative to fork the web standards by Microsoft. The 20 USB form-factors are different connector standards (even if they all implement the same wire protocol).
> How is that a good thing? We all understand and agree how IPv4 and IPv6 works (mostly), and how HTTP works, and how (mostly) the networking layer works.
And each platform has its own implementation. The specification is the same, the implementation is different in each case.
It's not the same TCP stack in Windows as it is on a Mac. There are multiple TCP implementations that exist for Linux. Each browser implements it's own HTTP stack.
> Introducing more competing standards
The GP isn't suggesting there should be more competing standards, the GP is suggesting there should be more competing implementations of the same standard.
> have you seen USB lately
USB is a mess. I don't think anyone will disagree with what a fustercluck USB-C + USB3 are.
> Oh the Raspberry PI screwed up their type-c implementation?
Raspi foundation screwed up in the reading of the spec, implemented an error, identified the error, and have resolved it. The implication in the comment is that people cannot be trusted to perform their own implementations of standards, and need to acquire implementations from the one true source. If that were the reality, the cost of the RPi4 would probably be higher.
> Oh, that USB-C cable bricked your Nintendo Switch?
This is particularly tragic. The Nintendo Switch doesn't have a USB-C port. It has a port that is dangerously similar to USB-C. 100% on Nintendo for doing this, and absolutely not the fault of the consumer who sees a port that looks like, and generally works with, USB-C, but is not. Nintendo absolutely should have done better here.
I haven't seen that Wireguard has a single developer. Sure there is tight control of the protocol (which is a good thing), but the various implementations are being worked on by different people.
And I do not consider NetBSD core team as amateur, frankly.
This has happened a few times. First with TunSafe, I think it also happened with CloudFlare's WG implementation, etc. The idea that a third party unsupported implementation shouldn't count.
I think this is a case of the message being lost in the tone. As a user of Wireguard, I definitely don't want to think about whether this is an official implementation. But having many competing implementations is exactly what would cause confusion (imagine a news article talking about how someone overcame a Wireguard exploit to get into a network).
It's like having 20 different apps that claim to be compatible with Signal. I'd have no idea which ones have gotten the same amount of rigorous testing. Fragmentation in these kinds of areas (especially when the original project is itself open source and hasn't stagnated) can often make things worse by causing even a little bit of doubt or hesitation.
WireGuard isn't an IETF protocol. In fact, it's a repudiation of IETF protocol design.
Right now, you should use WireGuard implementations Jason endorses, and avoid implements he expresses concerns about.
It seems like the VPN connection is not shared to devices if I allow them to connect to my phone's hotspot. This is annoying, because I have a number of devices that ephemerally use the hotspot, and for which it is quite a hassle (impossible) to individually set-up and whitelist a keypair. Is this something that would be fixed with the inclusion of Wireguard as an android native VPN protocol?