The app would be restricted to environments certified by Apple or Google. Then the app can apply features like trusted time to implement client-side rate limiting.
If the app wants to take advantage of mandatory hardware attestation, it has to require Android 13 or later. This would undermine somewhat the promise that the app supports a wide range of devices. Even banks don't currently enforce Android 13+.
> On Android 12 and lower, the MEETS_STRONG_INTEGRITY verdict only requires hardware-backed proof of boot integrity and does not require the device to have a recent security update. Therefore, when using the MEETS_STRONG_INTEGRITY, it is recommended to also take into account the Android SDK version in the deviceAttributes field.
The current policy trend in the EU is definitely not based on the principle of each user evaluating their own risk. On the contrary, service providers like financial institutes and identity providers have the responsibility to keep users safe, and more and more regulation will be made. The natural consequence is restricting which platforms are supported.
> The current policy trend in the EU is definitely not based on the principle of each user evaluating their own risk.
Yes and if you look back this is not new. Just look at the extraordinary restrictions that apply to:
- What houses you can build,
- What vehicle you can drive,
- What food you can grow and sell.
The result is real estate has become unaffordable for younger people, our car industry is being annihilated, and the agriculture sector hold by a string.
The digital realm enjoyed an unusual level freedom until now because the silent and boomer generations in charge in the EU understood nothing about it.
Now that the EU is getting involved in "computers" we are starting to understand why peasants have been protesting in Brussels and calling those people insane for decades.
I really have to wonder where in the EU you live. In Vienna, I got to buy an apartment in my mid-twenties by just saving up, which was easy, as many apartments are rent-capped and there's lots of cheap social housing. I got to enjoy free university, allowing me to get a high paying job. I get to use very cheap all electric state-subsidized rental car offerings if I need them, which is rare since we have federally good rail and bus coverage. And I enjoy affordable meat, dairy and vegetables all sourced from inside my country.
Austria's courts also ruled ages ago that rooting your own device cannot be a legal reason for OEMs like Samsung to refuse warranty coverage, since you can run whatever software you want on hardware you bought.
Maybe your country sucks? Don't blame it on the EU.
> apartments are rent-capped
> cheap social housing
> free university
> high paying job
> very cheap all electric state-subsidized rental car offerings
> affordable meat, dairy and vegetables
And here we can simply examine the tax structure and conclude that the problem isn't whether the country sucks, but whether the side you're on sucks.
After all, how can housing be affordable for ordinary workers if they have to subsidize from their own pocket free university, cheap housing, electric cars, high wages, and everything else for the privileged class?
> Maybe your country sucks?
And maybe your country sucks too. It is just North Korea is also the best country to live in (if you're Kim Jong Un).
I earn good money, but I pay 50% taxes on my income and another 20% VAT on almost anything I buy.
I'm okay with this, but don't try to tell me that I'm not paying for the privileges we all get to enjoy here.
High income earners are the net payers here who disproportionally pour taxes into the system, so everyone can take part in these subsidized schemes. How this basic concept eludes you is beyond me.
Yes congratulation, you get to benefit from a lot of regulated and subsidized things: housing, education and transportation.
While enjoying a high paying job in probably a still very unregulated domain (computers/internet related).
This is not about one country vs another.
The problem is you cannot have a society with everybody winning on both fronts unfortunately. You also need people making, cleaning stuff, growing food, cooking, etc. Not everybody can live in the capital with "very cheap all electric state-subsidized rental car" and Vienna is probably not food self sufficient...
No, but Austria is. And our farmers enjoy much support through subsidies - from the EU and our own budget - and social protections, often having better and cheaper health care than most other Austrians, since they are insured under their very own social insurance law (BSVG), contrary to other employees (ASVG) and self-employed (GSVG).
Farmers also enjoy very high levels of respect and appreciation here, even in Vienna.
> While enjoying a high paying job in probably a still very unregulated domain (computers/internet related).
Calling Information Technology an 'unregulated domain' in the EU when we're all busy implementing NIS2 regulation and preparing for the Cyber Resilience Act entering into force soon seems disingenuous.
> And our farmers enjoy very high levels of subsidies
Yes, thanks. This was my original point "the agriculture sector hold by a string". It is by design unsustainable and if you cut those "high levels of subsidies" it collapses.
> Calling Information Technology an 'unregulated domain' in the EU when we're all busy implementing NIS2 regulation and preparing for the Cyber Resilience Act entering into force soon seems disingenuous.
I do not understand what you're trying to communicate with "hold by a string" - we subsidize our farmers because we do not want to completely wreck our local agricultural supply chains just because food from, say Brazil, would be theoretically cheaper today. Another factor is that we actually have the ability to properly enforce quality standards if the food is produced within our jurisdiction.
This is no different to subsidizing public transport, because having this infrastructure local and autonomous is just strategically important enough for the tax payer to finance it. Would you say that public transport in EU capitals is "holding on by a string"?
Bad money drives out good money only if there is a legal tender law such that both have to be accepted for the same nominal value. In this case, good money is hoarded because it cannot be traded for its true value.
It's the security of the ecosystem, where the interests of app vendors are fundamental: content distributors can count on enforcing DRM, and banks are relying on the camera used for KYC actually being a camera and not a virtual device.
GPL licenses have allowed so-called "mere aggregation", where separate programs are distributed together. Such programs don't have to be all covered by GPL.
On the other hand, if parts are intimately tied to each other such that they are effectively a single program, GPL applies to the whole.
The FSF commentary explains that the judgment depends both on the mechanisms and the semantics of the co-operation. Technical implementation details don't make programs separate if they are intimately designed to work together: "But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
So they either have to license their SDK with a GPLv3 compatible license as well, or have to change the license of the client to a non-GPL one.
In the latter case, IIUC their CLA (https://cla-assistant.io/bitwarden/clients) allows to do change the license unilaterally. (Not a legal expert, so please correct me if I am wrong.)
If so, then I feel strengthened again in my conviction that permissive licenses (as well as closed-source licenses) and CLAs are bad for both users and developers and should be avoided, if possible.
Server-side solutions don't catch all cheats. They can block actions that are impossible according to the game rules but they cannot prevent clients from disclosing too much information to the player about other players, or automating actions that are technically possible, like using aimbots.
You can definitely handle some of those situations server side (the key word being "some") with enough engineering effort.
In regards to player positions: check which player locations are occluded and wouldn't be visible through the geometry, then only send the valid ones for each player. Of course, doing this on high tick servers could prove to be computationally intensive.
In regards to aimbots: the clients already send you information about where they're looking so that it can be displayed to other players. Attach some mouse movement metrics and from that you'll sometimes be able to infer the most naive aimbots instantly.
> In regards to player positions: check which player locations are occluded and wouldn't be visible through the geometry, then only send the valid ones for each player. Of course, doing this on high tick servers could prove to be computationally intensive.
What's your tolerance on this? Too low and players will complain that other players pop into view and kill them in the event of latency. Too high and cheaters still have access to the most valuable cases of information, when there's a chance for one player to get the drop on the other.
What about strategy games which rely on their lockstep simulation for performance? How would an RTS work if it's sending the locations of 100s of units in real time versus just player actions. Do you want to have to implement prediction and deal with warping in such a game?
1) be fair and decide upon some value that should cover most cases, make the outliers suck it up, like some games kick those with higher pings
2) don't be fair and base the threshold of visibility on some predictions about the movement of the entities in the following ticks, based on their probable movement speeds, as well as the ping times of the each player; the player with the higher ping value might receive the position of the other about 10 frames earlier before they round a corner - imperfect, but should still avoid ESP across the map
3) don't be fair, base this tolerance on hidden metrics about how trustworthy each of the players is considered, based on whatever data about them you can get, a bit like hidden ELO - you can probably game or abuse this system with enough effort, but it shouldn't make a difference in the lives of most legit players, since it shouldn't matter whether a model that you're about to see was rendered 5 or 10 frames before you actually did
4) enforce regional matchmaking by default and only show servers with acceptable ping times for your system (if any at all)
As for RTS games, that should be even simpler - most have some sort of a fog of war mechanic. Given that, you could probably come up with some data structure to represent everything that's visible to your side (like an octree) and send all of the models within it, without worrying about checking individual positions.
As for warping: the exact same way as in any online game, probably by some interpolation. If you receive a position from the server, the entity should be visible at a certain position, if you do not, then it shouldn't be visible (or maybe send the position in which it should disappear, with an additional flag). If you don't get the data for a while, handle it however you would stale data - like ARMA 3 does with entities just standing around or other games with them running in place, which is pretty funny.
Interestingly, given it was one of the strategy games I was thinking of when I made that comment, the Paradox devs for CK3 commented on why they use a lockstep architecture and not sharing the state of the game by server decided POV in their dev diary a couple of days after: https://forum.paradoxplaza.com/forum/threads/anatomy-of-a-ga...
Of course I don't believe that it'll work 100% of time time, since nothing will.
Fighting against cheating in online games is going to be a constant arms race.
That's not to say that detecting most of the naive implementations isn't worthy of the effort.
It won't always work consistently but it should be pretty obvious when someone is lerping between two quaternions. Then, you can build upon that and attempt to detect small bits of random noise that'd be applied upon said interpolation and go from there.
This is what Valorant does and just does not work. People saying "yeah game dev are lazy, why not everything is done server side" this is really a naive view of game dev.
The short version is that you can't have a great experience for online games if you try to create a client as a dumb terminal.
I didn't mean to say they're lazy. I generally dislike the studios but developers there are brillant, usually.
I was thinking that studios were being cheap. Why invest in a proper server infrastructure if you can make clients install abusive software... Maybe I'm wrong but it always looked to me that way.
Don't disclose to the client anything not in their view.
I know this is sometimes impossible and/or too costly to implement but it should be possible to find a compromise that prevents most of the blatant cheaters, eventually.
Also helpers like: In any score event, for randomly selected players, analyze the last actions taken.
You just cannot trust the clients. People will find creative ways of reading the memory of their own hardware, whatever you do.
> Don't disclose to the client anything not in their view.
Either full of edges cases (how do you efficiently compute visibility, and can you prevent models from popping in as a result of latency) or computationally expensive[0]. Valorant, CSGO, League of Legends, Dota 2 are some of the games that I know about that implement server-side occluding to minimise the impact of wallhacks, but eventually a client will still need information like the position of an audio cue such as footsteps that cheats can make use of.
> can you prevent models from popping in as a result of latency
Can you do that well enough on the client? The client can add some prediction on where someone is moving, but so can the server. And enemies killing you due to lag is happening already with current architectures.
To build on this: I was able to implement AES and OCB mode by just reading papers without any code in them. I was, however, not able to implement GCM reliably even by translating a "simple" reference C implementation into scheme. Sure, it worked, but even after 2 rewrites it still did not produce the same output as the simple reference implementation for some edge cases.
All this was done on a just-for-fun basis, but it ended up just making me frustrated so I stopped trying.
