Android’s open nature set it apart from the iPhone as the era of touchscreen smartphones began nearly two decades ago. Little by little, Google has traded some of that openness for security, and its next security initiative could make the biggest concessions yet in the name of blocking bad apps.
Google has announced plans to begin verifying the identities of all Android app developers, and not just those publishing on the Play Store. Google intends to verify developer identities no matter where they offer their content, and apps without verification won’t work on most Android devices in the coming years.
Google used to do very little curation of the Play Store (or Android Market, if you go back far enough), but it has long sought to improve the platform’s reputation as being less secure than the Apple App Store. Years ago, you could publish actual exploits in the official store to gain root access on phones, but now there are multiple reviews and detection mechanisms to reduce the prevalence of malware and banned content. While the Play Store is still not perfect, Google claims apps sideloaded from outside its store are 50 times more likely to contain malware.
This, we are led to believe, is the impetus for Google’s new developer verification system. The company describes it like an “ID check at the airport.” Since requiring all Google Play app developers to verify their identities in 2023, it has seen a precipitous drop in malware and fraud. Bad actors in Google Play leveraged anonymity to distribute malicious apps, so it stands to reason that verifying app developers outside of Google Play could also enhance security.
However, making that happen outside of its app store will require Google to take a page from Apple’s playbook and flex its muscle in a way many Android users and developers could find intrusive. Google plans to create a streamlined Android Developer Console, which devs will use if they plan to distribute apps outside of the Play Store. After verifying their identities, developers will have to register the package name and signing keys of their apps. Google won’t check the content or functionality of the apps, though.
Google says that only apps with verified identities will be installable on certified Android devices, which is virtually every Android-based device—if it has Google services on it, it’s a certified device. If you have a non-Google build of Android on your phone, none of this applies. However, that’s a vanishingly small fraction of the Android ecosystem outside of China.
Google plans to begin testing this system with early access in October of this year. In March 2026, all developers will have access to the new console to get verified. In September 2026, Google plans to launch this feature in Brazil, Indonesia, Singapore, and Thailand. The next step is still hazy, but Google is targeting 2027 to expand the verification requirements globally.
A Seismic Shift
This plan comes at a major crossroads for Android. The ongoing Google Play antitrust case brought by Epic Games may finally force changes to Google Play in the coming months. Google lost its appeal of the verdict several weeks ago, and while it plans to appeal the case to the US Supreme Court, the company will have to begin altering its app distribution scheme, barring further legal maneuvering.
Among other things, the court has ordered that Google must distribute third-party app stores and allow Play Store content to be rehosted in other storefronts. Giving people more ways to get apps could increase choice, which is what Epic and other developers wanted. However, third-party sources won’t have the deep system integration of the Play Store, which means users will be sideloading these apps without Google’s layers of security.
It’s hard to say how much of a genuine security problem this is. On one hand, it makes sense Google would be concerned—most of the major malware threats to Android devices spread via third-party app repositories. However, enforcing an installation whitelist across almost all Android devices is heavy handed. This requires everyone making Android apps to satisfy Google’s requirements before virtually anyone will be able to install their apps, which could help Google retain control as the app market opens up. While the requirements may be minimal right now, there’s no guarantee they will stay that way.
The documentation currently available doesn’t explain what will happen if you try to install a non-verified app, nor how phones will check for verification status. Presumably, Google will distribute this whitelist in Play Services as the implementation date approaches. We’ve reached out for details on that front and will report if we hear anything.
This story originally appeared on Ars Technica.
Source link
#Google #Android #App #Developers #Verify #Identity #Starting #Year
![Masochistic YouTuber Punishes Himself by Writing a First Person Shooter Entirely in COBOL
So: masochism. You might know that it takes its name from 19th-century Austrian nobleman and writer Leopold Ritter von Sacher-Masoch—and specifically from the content of his famous work, Venus in Furs, which catalogued the narrator’s submissive nature and fondness for experiencing pain and humiliation. Masoch himself was apparently not amused by the fact that his name became attached to such predilections—probably fair, given that the term was first used in a book entitled Psychopathia Sexualis, which also pioneered negging by speculating that Masoch himself “would have achieved real greatness had he been actuated by normally sexual feelings.” Happily, modern attitudes to the “S” part of BDSM are significantly more enlightened than they were in the 1880s and 1890s. In entirely unrelated news, a YouTuber by the name of icitry—whose bio on the site reads simply “try now, suffer later”—has written a whole first-person shooter in freaking COBOL. If you’ve never had to deal with COBOL, well, good for you, and you should probably keep it that way. The language is amongst the oldest computer languages, and was developed in the 1960s for managing business mainframes. It’s probably what drove poor Ginsberg in Mad Men out of his mind. COBOL remains in use today, largely in such legacy mainframes and other places where it’s not feasible to replace existing systems that, for all their foibles, still work.
One purpose for which it absolutely does not remain in use—and, in fact, has never been used—is programming first-person shooters. So why in the name of all that is good and holy would anyone do this to themselves? [embed]https://www.youtube.com/watch?v=qzpZQe7JT-o[/embed] In his video, icitry explains that the project started with him wondering, “What’s the dumbest but still technically possible language for writing a small FPS style game?” The answer was, yes, COBOL, and because the laws of the universe dictate that anything that can happen must happen, icitry got to work. Long, painstaking, tedious hours of work.
As he points out, COBOL is “old, verbose, missing most features even the shittiest modern languages have … and is definitely not created for game development.” All of this is true, although in fairness to COBOL, it was created at a time when people were still figuring out how programming should work and what a programming language should aim to be. Its earliest standard predated the idea of structured programming, although it soon attracted criticism from advocates of that concept— Edsger Dijkstra, in particular, famously hated the language and said its use “cripples the mind.” To modern eyes, just trying to parse a COBOL program is enough to induce a headache, let alone trying to write a game in it—but, miraculously, icitry manages to get his Wolfenstein 3D-esque project to work. He dodges COBOL’s complete lack of graphical functions by basically treating the game as what he calls a “frame generator”: his code computes the contents of each frame and uses a standard output function to write the results into a simple image format. This is rendered by ffplay—which, yes, is probably cheating, but not even old Leopold would try to write an entire graphics API from scratch in COBOL.
Elsewhere, icitry dodges COBOL’s lack of input management by using the console to input single characters to his game. He doesn’t so much dodge COBOL’s lack of any vector math functions—which are kind of important for a game where the entire gameplay loop revolves around calculating and manipulating 2D movement vectors—as he does just work around them by kinda writing them himself. And then, as if this wasn’t all enough self-punishment, he goes the extra mile by implementing DOOM engine functions like variable ceiling height. The whole project is a testament to mankind’s ingenuity, resourcefulness, and ability to withstand all manner of self-inflicted punishment. Watching the game run, you’d never guess it was written in a language so manifestly unsuited for the task at hand. Still! At least it’s not FORTRAN, right? Right?? *smash cut to an Austrian aristocrat at his desk with a copy of The Fortran Automatic Coding System for the IBM 704 and the DOOM source code* #Masochistic #YouTuber #Punishes #Writing #Person #Shooter #COBOLCOBOL,Doom,Wolfenstein 3D Masochistic YouTuber Punishes Himself by Writing a First Person Shooter Entirely in COBOL
So: masochism. You might know that it takes its name from 19th-century Austrian nobleman and writer Leopold Ritter von Sacher-Masoch—and specifically from the content of his famous work, Venus in Furs, which catalogued the narrator’s submissive nature and fondness for experiencing pain and humiliation. Masoch himself was apparently not amused by the fact that his name became attached to such predilections—probably fair, given that the term was first used in a book entitled Psychopathia Sexualis, which also pioneered negging by speculating that Masoch himself “would have achieved real greatness had he been actuated by normally sexual feelings.” Happily, modern attitudes to the “S” part of BDSM are significantly more enlightened than they were in the 1880s and 1890s. In entirely unrelated news, a YouTuber by the name of icitry—whose bio on the site reads simply “try now, suffer later”—has written a whole first-person shooter in freaking COBOL. If you’ve never had to deal with COBOL, well, good for you, and you should probably keep it that way. The language is amongst the oldest computer languages, and was developed in the 1960s for managing business mainframes. It’s probably what drove poor Ginsberg in Mad Men out of his mind. COBOL remains in use today, largely in such legacy mainframes and other places where it’s not feasible to replace existing systems that, for all their foibles, still work.
One purpose for which it absolutely does not remain in use—and, in fact, has never been used—is programming first-person shooters. So why in the name of all that is good and holy would anyone do this to themselves? [embed]https://www.youtube.com/watch?v=qzpZQe7JT-o[/embed] In his video, icitry explains that the project started with him wondering, “What’s the dumbest but still technically possible language for writing a small FPS style game?” The answer was, yes, COBOL, and because the laws of the universe dictate that anything that can happen must happen, icitry got to work. Long, painstaking, tedious hours of work.
As he points out, COBOL is “old, verbose, missing most features even the shittiest modern languages have … and is definitely not created for game development.” All of this is true, although in fairness to COBOL, it was created at a time when people were still figuring out how programming should work and what a programming language should aim to be. Its earliest standard predated the idea of structured programming, although it soon attracted criticism from advocates of that concept— Edsger Dijkstra, in particular, famously hated the language and said its use “cripples the mind.” To modern eyes, just trying to parse a COBOL program is enough to induce a headache, let alone trying to write a game in it—but, miraculously, icitry manages to get his Wolfenstein 3D-esque project to work. He dodges COBOL’s complete lack of graphical functions by basically treating the game as what he calls a “frame generator”: his code computes the contents of each frame and uses a standard output function to write the results into a simple image format. This is rendered by ffplay—which, yes, is probably cheating, but not even old Leopold would try to write an entire graphics API from scratch in COBOL.
Elsewhere, icitry dodges COBOL’s lack of input management by using the console to input single characters to his game. He doesn’t so much dodge COBOL’s lack of any vector math functions—which are kind of important for a game where the entire gameplay loop revolves around calculating and manipulating 2D movement vectors—as he does just work around them by kinda writing them himself. And then, as if this wasn’t all enough self-punishment, he goes the extra mile by implementing DOOM engine functions like variable ceiling height. The whole project is a testament to mankind’s ingenuity, resourcefulness, and ability to withstand all manner of self-inflicted punishment. Watching the game run, you’d never guess it was written in a language so manifestly unsuited for the task at hand. Still! At least it’s not FORTRAN, right? Right?? *smash cut to an Austrian aristocrat at his desk with a copy of The Fortran Automatic Coding System for the IBM 704 and the DOOM source code* #Masochistic #YouTuber #Punishes #Writing #Person #Shooter #COBOLCOBOL,Doom,Wolfenstein 3D](https://gizmodo.com/app/uploads/2026/06/cobol-fps-1280x853.png)

Post Comment