6 ms·

This is a no-win situation. MS expends an inordinate amount of effort on back compatibility, and much kudos to them. But it vastly increases their attack surf

by gumby 3y ago

This is a no-win situation. MS expends an inordinate amount of effort on back compatibility, and much kudos to them. But it vastly increases their attack surface. Likewise many of the worst things about the unfairly maligned C++ come from a hardcore position on back compatibility: as much as possible, old code, and even old C code, should continue to compile and work as expected, even to the point of linking old binaries to which you’ve lost the source code. Most people don’t go to that effort and just invalidate old stuff in the name of maintenance, reliability, and security. Whichever branch cut you take you’re going to cause a problem for somebody. If not, nobody is using your code.

jarm0 3y ago
Yes, that's definitely one side of the problem and I'm not chasing too much backwards-compatibility. My biggest concern in this particular situation is that there is no way (with Android, at least) to pull-back/cancel/rollback release and everything is blocked behind Google's review process. Why isn't it just possible to "yank" problematic release and continue showing previous release as the latest version. That would solve most of the issues within context of this problem.
- imchillyb 3y ago
  Rollbacks allow malicious actors to /simply-easily/ circumvent device security and user preference. To allow rollbacks is to /significantly/ increase the attack surface of a device.
  - jarm0 3y ago
    What do you mean by that? Are you effectively trying to say that allowing upgrades does not have any risk of attack surface? I'm pretty sure that updating things have also a pretty high risk on introducing new previously non-existing security issues into your code-base/product.
  - rany_ 3y ago
    Not necessarily, Google has access to the developer's private key they use for signing their APKs so they could just make a fake release that has a bigger version number than the current version whenever a rollback is needed. No change is needed on Android itself, it's a Google Play issue.
lubesGordi 3y ago
The middle ground that I think helps everyone is, change your api and break compilation. Let devs fix the compile errors and use the api correctly, etc. But don't change the behavior of existing functions with the same signatures. As an api provider, do your best to make compilation mean something.
- izacus 3y ago
  This is exactly how Android works. But because API changes bring privacy and security improvements, scummy software used old compilation targets to abuse backwards compatibility to avoid complying with privacy and security practices. This is why Play slowly enforces apps to raise their compilation target and implement safer APIs. It's lagging for YEARS after API changes, so there's plenty of time to fix apps. The OP just decided to be lazy and wait for last two weeks.
  - jarm0 3y ago
    I'm the OP and wanted to clarify in case you missed some points - it is a legacy application which does not have any active dev teams on it and needs only developers attention when Google says so and as mentioned by multiple other commenters here the first time I got that e-mail from Google, was at 18th of August. I would not agree that I have been lazy, but instead trying to solve this problem in the time-constraints set by Google and failing to do so because of the inability to put a fix to production and/or pull back current release version. Of course I admit that there's always ways to improve quality assurance. There has been zero communication towards me from Google until two weeks until deadline. Yes, maybe if I would have logged into Play Console then there might have been some notifications, but there have been no reason to do so until that e-mail (I'm usually not involved with Android projects, otherwise I might have noticed similar warnings via other projects early on).
    - izacus 3y ago
      My mailbox shows Play comms warning about these changes in July, April and October 2022. And that's just a glance.
cogman10 3y ago
I just don't buy this as an excuse for google. The majority of applications deployed to android are targeting android's bytecode. They aren't natively compiled applications. The reason C++ presents insurmountable security problems is it's low level nature and the fact that once you have a native binary, you're done. But a bytecode for a language with memory safety? How would it be possible to not backport security fixes. The very nature of running such code is one where you are constantly recompiling the bytecode. Just to paint how absurd this position is for google. The JVM can still, today, execute and use classes targeting Java 1.0 (released in 1996). This isn't a security issue, this is a "google doesn't want to support the platform" issue. I'm more amenable to google clamping down on artifacts containing natively compiled code. However, a blanked "Your app was built targeting an old version of android, we won't support that anymore" is just ridiculous. Seems like a way for google to prune old apps from the store more than anything else. Especially since a policy like this is by it's nature one that shifts a large maintenance burden on android developers. After all, if you want the widest support for your application, you target the oldest version of android possible. Very few people target the latest version of android for fear it will lock out too many of their customers. If google was serious about security and making the latest android tech widely accessible, then they'd work towards decoupling the android runtime from the operating system version. There's no reason ART and the Dalvik runtime couldn't be distributed via google play like the rest of the android ecosystem. Removing the silly "you need android 17 to do this... opps your hardware manufacture isn't updating their hardware drivers." But then, that would cut into new device sales and we can't have that.
- pjmlp 3y ago
  > The JVM can still, today, execute and use classes targeting Java 1.0 (released in 1996 Only if you are lucky they don't depend on stuff that started being removed after Java 8, when deprecated for removal went into effect.
  - cogman10 3y ago
    That stuff, to be clear, is stuff in `sun.misc.Unsafe`. Plenty of libraries from that era didn't require unsafe code to accomplish their tasks. I'm more than happy if google decides to break people who used non-public android apis.
SenAnder 3y ago
I got the impression the author was mainly complaining about Google's role as arbiter of what software users may run. The problems from deprecating APIs are just what brought the author's attention to how vulnerable we've become to Google's whims.
Groxx 3y ago
There is no best win option, but you can also publish your app separately - these are Play Store requirements, not Android requirements. It's far from trivial in many cases, and it'll never get anywhere near as much use as the Play Store version... but it is nice to have an escape hatch.

by gumby 3y ago

jarm0 3y ago

Yes, that's definitely one side of the problem and I'm not chasing too much backwards-compatibility. My biggest concern in this particular situation is that there is no way (with Android, at least) to pull-back/cancel/rollback release and everything is blocked behind Google's review process. Why isn't it just possible to "yank" problematic release and continue showing previous release as the latest version. That would solve most of the issues within context of this problem.

imchillyb 3y ago
Rollbacks allow malicious actors to /simply-easily/ circumvent device security and user preference. To allow rollbacks is to /significantly/ increase the attack surface of a device.
- jarm0 3y ago
  What do you mean by that? Are you effectively trying to say that allowing upgrades does not have any risk of attack surface? I'm pretty sure that updating things have also a pretty high risk on introducing new previously non-existing security issues into your code-base/product.
- rany_ 3y ago
  Not necessarily, Google has access to the developer's private key they use for signing their APKs so they could just make a fake release that has a bigger version number than the current version whenever a rollback is needed. No change is needed on Android itself, it's a Google Play issue.

lubesGordi 3y ago

The middle ground that I think helps everyone is, change your api and break compilation. Let devs fix the compile errors and use the api correctly, etc. But don't change the behavior of existing functions with the same signatures. As an api provider, do your best to make compilation mean something.

izacus 3y ago
This is exactly how Android works. But because API changes bring privacy and security improvements, scummy software used old compilation targets to abuse backwards compatibility to avoid complying with privacy and security practices. This is why Play slowly enforces apps to raise their compilation target and implement safer APIs. It's lagging for YEARS after API changes, so there's plenty of time to fix apps. The OP just decided to be lazy and wait for last two weeks.
- jarm0 3y ago
  I'm the OP and wanted to clarify in case you missed some points - it is a legacy application which does not have any active dev teams on it and needs only developers attention when Google says so and as mentioned by multiple other commenters here the first time I got that e-mail from Google, was at 18th of August. I would not agree that I have been lazy, but instead trying to solve this problem in the time-constraints set by Google and failing to do so because of the inability to put a fix to production and/or pull back current release version. Of course I admit that there's always ways to improve quality assurance. There has been zero communication towards me from Google until two weeks until deadline. Yes, maybe if I would have logged into Play Console then there might have been some notifications, but there have been no reason to do so until that e-mail (I'm usually not involved with Android projects, otherwise I might have noticed similar warnings via other projects early on).
  - izacus 3y ago
    My mailbox shows Play comms warning about these changes in July, April and October 2022. And that's just a glance.

cogman10 3y ago

I just don't buy this as an excuse for google. The majority of applications deployed to android are targeting android's bytecode. They aren't natively compiled applications. The reason C++ presents insurmountable security problems is it's low level nature and the fact that once you have a native binary, you're done. But a bytecode for a language with memory safety? How would it be possible to not backport security fixes. The very nature of running such code is one where you are constantly recompiling the bytecode. Just to paint how absurd this position is for google. The JVM can still, today, execute and use classes targeting Java 1.0 (released in 1996). This isn't a security issue, this is a "google doesn't want to support the platform" issue. I'm more amenable to google clamping down on artifacts containing natively compiled code. However, a blanked "Your app was built targeting an old version of android, we won't support that anymore" is just ridiculous. Seems like a way for google to prune old apps from the store more than anything else. Especially since a policy like this is by it's nature one that shifts a large maintenance burden on android developers. After all, if you want the widest support for your application, you target the oldest version of android possible. Very few people target the latest version of android for fear it will lock out too many of their customers. If google was serious about security and making the latest android tech widely accessible, then they'd work towards decoupling the android runtime from the operating system version. There's no reason ART and the Dalvik runtime couldn't be distributed via google play like the rest of the android ecosystem. Removing the silly "you need android 17 to do this... opps your hardware manufacture isn't updating their hardware drivers." But then, that would cut into new device sales and we can't have that.

pjmlp 3y ago
> The JVM can still, today, execute and use classes targeting Java 1.0 (released in 1996 Only if you are lucky they don't depend on stuff that started being removed after Java 8, when deprecated for removal went into effect.
- cogman10 3y ago
  That stuff, to be clear, is stuff in `sun.misc.Unsafe`. Plenty of libraries from that era didn't require unsafe code to accomplish their tasks. I'm more than happy if google decides to break people who used non-public android apis.

SenAnder 3y ago

I got the impression the author was mainly complaining about Google's role as arbiter of what software users may run. The problems from deprecating APIs are just what brought the author's attention to how vulnerable we've become to Google's whims.

Groxx 3y ago

There is no best win option, but you can also publish your app separately - these are Play Store requirements, not Android requirements. It's far from trivial in many cases, and it'll never get anywhere near as much use as the Play Store version... but it is nice to have an escape hatch.