惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

月光博客
月光博客
SecWiki News
SecWiki News
爱范儿
爱范儿
Jina AI
Jina AI
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Apple Machine Learning Research
Apple Machine Learning Research
Vercel News
Vercel News
S
SegmentFault 最新的问题
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
GbyAI
GbyAI
V
V2EX
博客园 - 司徒正美
WordPress大学
WordPress大学
Y
Y Combinator Blog
B
Blog RSS Feed
H
Help Net Security
C
Check Point Blog
P
Proofpoint News Feed
Google DeepMind News
Google DeepMind News
Application and Cybersecurity Blog
Application and Cybersecurity Blog
B
Blog
Help Net Security
Help Net Security
罗磊的独立博客
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
H
Heimdal Security Blog
大猫的无限游戏
大猫的无限游戏
Security Latest
Security Latest
Cisco Talos Blog
Cisco Talos Blog
Blog — PlanetScale
Blog — PlanetScale
A
Arctic Wolf
T
The Blog of Author Tim Ferriss
P
Proofpoint News Feed
The Register - Security
The Register - Security
F
Fortinet All Blogs
S
Securelist
Microsoft Security Blog
Microsoft Security Blog
O
OpenAI News
P
Privacy & Cybersecurity Law Blog
C
Cybersecurity and Infrastructure Security Agency CISA
The GitHub Blog
The GitHub Blog
云风的 BLOG
云风的 BLOG
AWS News Blog
AWS News Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
I
InfoQ
T
Threat Research - Cisco Blogs
Martin Fowler
Martin Fowler
D
Docker
C
Cisco Blogs
C
CERT Recently Published Vulnerability Notes
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant Common SOC 2 Failures (Real World) Stop Vibe-Checking Your AI App: A Practical Guide to Evals How to Use SonarQube and SonarScanner Locally to Level Up Your Code Quality Your Next To-Do App Is Dead — I Replaced Mine with an OpenClaw AI Sign a Nostr event in 60 lines of Python using coincurve — no nostr-sdk, no nbxplorer, no rust toolchain ITGC Audit Explained Like You’re in Big 4 Patch Tuesday abril 2026: Microsoft parcha 163 vulnerabilidades y un zero-day en SharePoint Stop scraping everything: a better way to track competitor price changes Listing on MCPize + the Official MCP Registry while routing payments OUTSIDE the marketplace — how I kept 100% of my x402 revenue Building an AI-Powered Risk Intelligence System Using Serverless Architecture Why We Ripped Function Overloading Out of Our AI Toolchain Testing AI-Generated Code: How to Actually Know If It Works SaaS Churn Is Killing Your Business. Here Is What to Do About It (Without a Support Team) The Speed of AI Is No Longer Linear - And Self-Improving Models Are Why How to Implement RBAC for MCP Tools: A Practical Guide for Engineering Teams From Standard Quote to Persuasive Proposal: AI Automation for Arborists I built a CLI that scaffolds complete multi-tenant SaaS apps Axios CVE-2025–62718: The Silent SSRF Bug That Could Be Hiding in Your Node.js App Right Now The dashboard that ended our friendship Data Pipelines Explained Simply (and How to Build Them with Python) The Hidden Cost of AI Systems Nobody Talks About. undefined vs undeclared, and how typeof behaves Switching from file-based jobs to NATS/Kafka in Rust without changing code io_uring Adventures: Rust Servers That Love Syscalls Why Agentic AI is Killing the Traditional Database The POUR principles of web accessibility for developers and designers Quantum Neural Network 3D — A Deep Dive into Interactive WebGL Visualization How To Install Caveman In Codex On macOS And Windows Automation Pipeline Reliability: Why Your Workflow Breaks When Nobody Is Watching I Built an 'Open World' AI Coding Agent — It Works From ANY Folder From Freelancing to Product: A Tech Service Company's SaaS Transformation China's AI Giants: Adding Tencent Hunyuan & ByteDance Doubao to AI University (74 Providers) On the Vibe Coders and Their Lies clerk: Auto-Summarize Your Claude Code Sessions AI Weekly — 2026/04/10–04/17 | The Model Lockdown Is Here, but the Toolchain Is the Real Battleground AI 週報 — 2026/04/10–2026/04/17 模型封鎖潮來了,但工具鏈才是真戰場 Maybe this is how Open-Source apps are born... 🚀 Fine-Tune LLMs with LoRA and QLoRA: 2026 Guide tRPC v11 + Next.js App Router: End-to-End Type Safety Without the Boilerplate ShadCN UI in 2026: Why I Stopped Installing Component Libraries and Started Owning My Components SaaS Billing in React Server Components: Stripe + Supabase Without a Single `useEffect` Join our DEV Weekend Challenge — $1,000 in Prizes Across TEN winners! Submissions Due April 20 at 6:59 AM UTC. Implementing FSRS Spaced Repetition in Flutter + Supabase — Adding Memory Science to an AI Learning App "I Texted My Localhost From the Train — Claude Code Fixed the Bug Before I Got Home" I Built a Sales Prep AI and It Went Deeper Than Expected Design to Code #2: One JSON, Eleven Outputs Solving the 100M-Row Problem: A Summary Table Pattern for High-Volume Push Notification Logs Flutter Web With Wasm: What Actually Changes For Developers I Built 50 Royalty-Free Soundtracks for My Side Project in a Weekend Using AI Music Generation The Vibe Coding Security Checklist: 7 Things to Check Before You Ship Stop Letting Googlebot Guess Fix Your React App's SEO Right Desconstruindo o Streaming do LinkedIn: Como Criar um Engine de Extração de Vídeo de Alta Performance com HLS e FFmpeg (EDA Part-1) EDA (Exploratory Data Analysis) Explained With Real Life — Why Looking at Your Data Is the Most Important Step in Machine Learning Brand Relationship Management at Scale: Our 4-Touch Outreach System for 200+ Brands Why String.fromEnvironment() Might Return an Empty String in Dart JGuardrails 1.0.0 — Hardening Java LLM Apps Against Jailbreaks, Toxicity, and Prompt Injection Plan and Schedule a Full Week of Threads Content From One Claude Conversation Coding Cat Oran Ep3, Five Tables Changed Everything Updated: BFF Pattern I'm done watching freelancers get buried by 200 proposals. So I'm building the alternative. This is my first post BFS Algorithm in Java Step by Step Tutorial with Examples Tracking LLM Pricing Monthly: An Open Dataset for 22 AI Models How We Measure Content ROI on a Comparison Site: Revenue Attribution Without Perfect Data Introducing Nova AI Ops: The AI-Native Operating System for SRE Teams I built a free desktop video downloader for Windows — Grabbit How Talkie OCR Helps Vision-Impaired & Dyslexic Users Read the World Around Them VRCFaceTracking安装和iPhone面捕配置教程,有bug Even CrowdStrike Can't See Your Agents The Automation Gold Rush: What n8n Workflows and Claude Are Opening Up for Developers Right Now
Proposal on Play Store security measures (alternative to Google's mandatory "developer verification")
Indigotime · 2026-05-11 · via DEV Community

What Google claims to be doing for the sake of security is, in fact, not really related to security. Let me explain why.

Before diving into details, we should first clarify what "security for whom" and "from whom" are Google's measures supposed to protect according to their statements. If we sum up all the official statements and publications by Google on this topic, they say that security is provided for end users of applications against malicious actors who create and publish harmful or phishing applications. For a moment, let's pretend this is indeed true. What follows from this?

The primary goal of most malicious applications is to collect data that may be of interest to various attackers. These interests could be commercial or economic motives for fraud, extortion, blackmail, and industrial espionage; or political ones, such as assisting censorship, identifying unfriendly individuals for subsequent shaming or reprisal. Data of users who may be of interest in these contexts include various passwords and keys, private correspondence, geolocation information, browser history, and usage patterns of applications.

Now let's ask ourselves: what would we do if we were Google and genuinely wanted to protect users according to these statements? I would answer this question as follows:

  1. Introduce mandatory declaration of public keys and certificates which automatically trusted by the application. Without this, users may have a false sense of security, believing that as long as their system store only trusted CA certificates, no application can use embedded MITM (Man-in-the-middle) certificates or keys to intercept and send data through their servers.

  2. Introduce mandatory declaration of hardcoded addresses of web services used by the application. Currently, when we examine Android permissions for applications, we only see abstract and non-specific permissions for internet access. We cannot selectively grant permission only for certain parts of the addresses used by the application. In some cases, this might be justified, but at least Google should require to provide a list of hardcoded addresses used by an application before publishing it in the Google Play Store for security checks through Google Safe Browsing.

As we can see, such measures are not being taken at the moment. Maybe I have misunderstood something or misinterpreted Google's statements, and in reality, they were more focused on protecting developers of these applications? However, this is unlikely because the process itself would require developers to provide exactly those data that are most sought after by the same fraudsters and other malicious actors.

Perhaps Google is simply trying to enforce the rules for using the services utilized by applications? It's likely not the case, as requiring developers to publicly declare hardcoded addresses of websites and services would also address this issue at least for applications on Google Play Store. If Google were indeed aiming to remove applications from Google Play that violate their service usage rules, including those prohibiting the use of alternative client applications, they would undoubtedly have done precisely this. However, as we can see, no such action is being taken.

Bellow I will provide an illustrative example of why Google's so-called "security measures" would not improve the situation in any way.

There is an app called Telega that positions itself as an alternative Telegram client capable of functioning even under conditions where Telegram is blocked in Russia.

According to source, this is achieved by using a proxy server working with the MTProto protocol. The address of this proxy server is hardcoded within the application itself. Additionally, the public keys used to connect to this proxy server are also hardcoded and differ from those used by the official Telegram client.

This means that whoever controls this proxy server can read chats of users who use this app. Please note this: I am not talking about some obscure third-party application hosted on a one-day website, with links to which scammers spread through sophisticated and hard-to-trace schemes. I am talking about an app that is still available in the Google Play Store.

And even though I don't know how reliable the source information is, the very fact of such accusations or suspicions itself indicates that users cannot verify them, which is a problem in itself.

If the information from the source is false, it clearly demonstrates how easy it is to accuse a legitimate application of malicious actions.

But if the information from the source is true, it clearly shows the complete helplessness of the Play Store against such threats. Imagine if these so-called "Google security measures" had already been introduced. What would have prevented this application from being published on Google Play Store? Were the developers lacking funds to pay a fee? They could have managed it. Would there have been any issues with providing government identification? None existed then, as the developer account stated the official name of the legal entity. Who can guarantee that this is just a single case and that similar situations do not already exist among popular client applications for social networks, messaging services, and other platforms on Google Play Store? The answer is - nobody, and even after implementing these so-called "security measures", the answer will not change.

Now let's try to imagine what would have changed if Google had indeed required developers to publicly declare the hardcoded web addresses used by their applications and explicitly declare trusted public keys and certificates used by them. Or even better, in the declaration of public keys and certificates, it would be mandatory to specify which web addresses they correspond to (with a possibility for wildcard entries).

Firstly, attempting to publish this app would have raised many suspicions and questions, and it would likely not have been published on Google Play Store.

Secondly, if these data were declared in the application manifest, it would allow various antivirus programs, security scanners, and even Google Play Protect to quickly detect such patterns or at least consider them suspicious, regardless of where the app was downloaded from.

Finally, with future versions of Android, this approach could potentially enable more flexible permission handling, specifically by first requesting access to a list of declared addresses and only afterward, if the user requires, in run-time requesting access to non-declared resources directly when the application attempts to access them.

Unlike the "security measures" that Google is currently introducing, this would look like something very close to a final solution on user control over data streams sent by mobile applications.

Based on the public discussions I have observed on this topic, it seems that many experts, users, and other stakeholders who oppose Google's so-called "security measures" simply call for Google not to implement them or urge pressure to be applied to Google in favor of not taking such actions.

However, I believe that for such pressure to be successful, it is not enough just to show opposition to these measures; there should also be an alternative proposal offering other, more effective solutions to the same problem that Google is trying to address. Moreover, this alternative must be so compelling that it renders Google's security measures untenable for criticism. The aim is not to immediately convince Google to adopt this proposal and implement it but to sow doubt about their arguments. If there exists a viable solution to this problem that genuinely protects user safety, but Google chooses another course of action that appears to be against developers and users' interests, the "we do this for your safety" argument becomes invalid. Even for those who are not deeply familiar with the issue, this argument begins to look like "we do this simply because we can, but we mislead you about security to deceive you".

In fact, my "alternative proposal" has already been mentioned earlier in this text: adding the technical capability to declare hardcoded public keys, certificates, and web addresses. If it is currently not possible to implement this directly in the application manifest, then at least it should be done on the level of requirements and capabilities for publishing applications to the Google Play Store. However, if it is feasible, it would be advisable to introduce corresponding fields specifically in the manifest for future versions of Android, making this security mechanism work regardless of where the app was downloaded from.

Even in its current form, this proposal somewhat undermines the argument that "malicious and fraudulent applications are somehow only present on devices from external sources while everything is safe in Google Play Store". If Google has reasons for being against implementing such a mechanism in their own Play Store but continues to insist on their "security measures" with the requirement of providing government identification, it would already appear odd and somewhat dishonest.