Public Profile editing section, specifically the email and location fields. This is where users manage what personal information appears on their publicly visible Snapchat profile.
The app saves whatever you typed anyway, even though you never confirmed it. It’s fixed now.
You know that moment when you carefully set an app's permissions to "Ask every time"? When you go into Settings, find that app, and make sure it only gets access to your microphone or camera when you explicitly allow it? You feel good about it. You're in control, right?
Yeah, about that.
I've been testing Android's one-time permission system, particularly with apps like WhatsApp. I set the microphone permission to "Ask every time" because I wanted tight control over when the app could listen. But what I discovered was something that doesn't quite match what Android's documentation promises.
Guess what? There's a gap. A small one, but it matters.
Here's the thing most people don't know: when you close an app after granting one-time permission, Android doesn't always revoke it instantly.
Think about it. You finish a WhatsApp call, swipe the app away from your recent apps, and assume that's it - permission gone. According to Android's documentation, that should be exactly what happens. Close the app, lose the permission.
But in reality, there's a window of about 30-60 seconds where the app can still access that permission without asking you again. It just... keeps using it. Like you never closed it at all.
Yes. Completely.
Android's own documentation is crystal clear about this. Here's how one-time permissions are supposed to work:
While the app is visible and in use: It can access the requested resource.
If sent to background: It may still access the resource briefly.
If completely closed: The permission is revoked immediately.
That last part is key. "Immediately." Not "in about a minute." Not "after a short delay." Immediately.
But that's not what actually happens.
I started simple. Set WhatsApp's microphone permission to "Ask every time." This is a common setting for anyone who wants control over app access to sensitive features.
First call (Person A): When Person A called me via WhatsApp, I was prompted to grant microphone access. I selected one-time access, took the call, everything worked as expected.
Closing the app: After the call ended, I completely closed WhatsApp from the recent apps list. No background activity. According to Android's documentation, this should have removed the granted permission immediately.
Second call (Person B): About 30-60 seconds later, Person B called me. This is where things got strange - WhatsApp started the call without asking for microphone access again. It simply reused the previous permission silently, even though the app had been fully terminated.
Although my test was with WhatsApp (a Meta app), this isn't unique to it. Any Android app that requests runtime permissions for camera, microphone, files, or media can be affected. This means it potentially impacts apps from Meta, Google, Microsoft, and many other developers.
If Android itself doesn't enforce the re-prompt immediately after app closure, every app benefits from this short-lived permission reuse. It's a system-level behavior, not an app-specific exploit.
If you want to test this, here's exactly what I did:
You'll likely see that the app gets access without showing the permission prompt. If you wait longer than about a minute, the permission prompt will reappear as expected.
Consistent and repeatable.
One-time permissions exist to give users control. When you select "Ask every time," you're explicitly saying you want to approve each use of that sensitive resource. The expectation is clear: every time means every time.
But this timing gap creates a disconnect between what users believe is happening and what's actually happening. During that 30-60 second window after closing an app, it can still access your microphone or camera without notifying you. For someone who chose "Ask every time" specifically to avoid silent access, this behavior runs counter to their intent.
It's worth understanding that this appears to be how Android handles the cleanup of one-time permissions at a system level, rather than something individual apps are doing deliberately. The delay might exist for technical reasons - perhaps to handle edge cases or improve user experience in certain scenarios. But regardless of why it exists, users who rely on "Ask every time" for privacy control should know it's there.
This article is written simply to help people better understand how app permissions work in practice, particularly with Android's one-time permission system. Many users reasonably assume that closing an app immediately revokes its one-time permissions, but that isn't always how things function behind the scenes. By sharing this, my goal is only to increase awareness so users can make more informed decisions about the permissions they grant and understand the actual behavior of the "Ask every time" setting. Understanding these details allows people to use their devices with clearer expectations and greater confidence.
You know that moment when you're careful about app permissions? When you go into Settings, find that sketchy app, and revoke its access to your camera, location, or files? You feel good about it. You're in control, right?
Yeah, about that.
I've been using Google Gemini since it launched. I gave it access to pretty much everything - camera, files, location, the works. Recently, I decided to clean things up. Went into Android settings, revoked all of Gemini's permissions, deleted the app, and reinstalled it fresh.
Guess what? Gemini still had access to everything.
Here's the thing most people don't know: Gemini doesn't actually need your permission if you've already given it to the Google app.
Think about it. The Google app comes pre-installed on almost every Android phone. During setup, you probably granted it a bunch of permissions without thinking twice. Camera, microphone, location, files - whatever it asked for, you said yes because it's Google and you need it to work.
Gemini just... uses those permissions. Like a roommate who takes your Netflix login without asking.
The Google app and Gemini are separate apps in your phone's app list. They show up as two different entries with two different permission screens. But when you revoke Gemini's permissions, nothing actually happens. It keeps accessing your stuff through the Google app's permissions, and Android doesn't stop it or even tell you it's happening.
Yes. Completely.
Google's own documentation is crystal clear about this. It's called the "Application Sandbox" - every app is supposed to be isolated from every other app. Permissions are app-based, not developer-based.
Here's how it's supposed to work: If you give Facebook access to your camera, Instagram can't automatically use it too. Even though Meta owns both apps, Instagram has to ask you separately. That's the rule.
Gemini breaks that rule.
According to Android's permission documentation, when you uninstall an app, all its permissions are revoked. When you reinstall it, it must ask again. Gemini doesn't. It just quietly inherits whatever the Google app already has.
Google's own admission (that nobody reads):
📄 How Gemini manages mobile permissions - Buried in the documentation, Google quietly explains that Gemini uses Google app permissions. Most users will never see this.
Android's official security policies:
📄 Android Application Sandbox - "The Android platform uses the Linux user-based protection model to isolate app resources... This isolates apps from each other and protects apps and the system from malicious apps."
📄 Request App Permissions - "Beginning with Android 6.0 (API level 23), users grant permissions to apps while the app is running, not when they install the app... The user can grant or deny each permission."
📄 Google Play Policy on Permissions - "You should only request permissions that are necessary to implement critical features of your app... You may not use permissions to undisclosed or unimplemented features."
This article is written simply to help people better understand how app permissions work in practice, particularly in the case of Google and Gemini. Many users reasonably assume that removing permissions from an app or reinstalling it resets its access, but that isn’t always how things function behind the scenes. By sharing this, my goal is only to increase awareness so users can make more informed decisions about the permissions they grant and how different apps may rely on shared system access. Understanding these details allows people to use their devices with clearer expectations and greater confidence.
Facebook Creator Studio's Instagram account linking system. Creator Studio lets you manage Instagram messages and comments from desktop by connecting your Instagram account to a Facebook Page.
The disconnection only removed the visible link. The backend authorization stayed active, so I could keep accessing everything like nothing changed. It’s fixed now.
Facebook's like visibility privacy setting. Users can choose "Only Me" to hide the number of likes on their posts from everyone else. This setting is supposed to keep engagement numbers private.
The privacy setting only applies to the regular post view. When the same content shows up as a Reel, Facebook ignores the setting completely.
TikTok's privacy settings for disabling tags and mentions. Users can turn this off to prevent others from tagging or mentioning them in videos and comments.
The setting exists in the UI and appears to work, but the backend completely ignores it. Every attempt to tag or mention someone with this disabled still works.
TikTok acknowledged the issue after I reported it and pushed a fix. The setting now properly blocks tags and mentions when disabled. It’s fixed now.
ChatGPT's message cap enforcement for GPT-4o users. OpenAI limits how many messages you can send with GPT-4o in a session to manage costs and resources.
The model switches to GPT-3.5 for the extra messages, but you keep the full conversation context and bypass the intended limit.
Reported to OpenAI via Bugcrowd. They confirmed the issue but marked it as a duplicate since another researcher had already reported it. No bounty, but they acknowledged the finding. It’s fixed now.
