Nobody stole a password. Someone clicked Allow.
That's consent phishing. It skips your password and your MFA, because you hand over the access yourself on a real Google or Microsoft screen. Before You Allow steps in at that moment and tells you, in plain English, what you're about to hand over and what it's worth to whoever ends up holding it.
One request. Two ways of reading it.
The request as the consent screen shows it, and the briefing the extension puts next to it. The briefing is generated by the same code that runs in the extension. Try Allow. Nothing happens, it's a demo.
Ten fictional examples across Google, Microsoft 365, GitHub and Slack. Pick one, or use the arrows. None of the apps are real and no account is connected.
The app's request Sample consent screen, not a real one
The buttons in this sample don't grant anything.
Your briefing As the extension shows it
The consent screen lists permissions. This is the same request read as consequences, which is the part people actually need before they click.
Three questions, in this order.
The consent screen already lists the permissions. The problem is that a permission tells you what an app can do, not what it means when the wrong person is holding it.
What you're connecting
The app, the account it wants, whether the publisher has been verified, and whether the access keeps going after you close the tab.
ASKWhat you're handing over
The permissions, grouped into what it can see, what it can change and what it can do as you. Plus the fine print, like MFA not applying and access surviving a password change.
DOWhat someone who gets in could reach
What those permissions are worth to whoever ends up holding them. Forwarding rules, invoice fraud from your real address, password resets for your other accounts.
VALUE“Manage forwarding and delegates on your Gmail”
A quiet forwarding rule, so a copy of every email keeps arriving even after you revoke the app.
That's the Ask&Do framework (ASK, DO, VALUE) applied to one very specific click. Consequence, not permission.
It reads the request. It doesn't read you.
Plus the app name on the page and any unverified-app warning. That's the whole input.
It never sees inside the account. It only sees what the app is asking for.
No server, no account, no analytics. Nothing leaves the browser.
Google, Microsoft (work or school and personal), GitHub and Slack.
Just signing in with Google gets a small green pill, not the full briefing.
It explains the request. It doesn't vouch for the app, block anything, or know what the app does afterwards.
Not in the Chrome Web Store yet, so it installs the developer way.
About two minutes. Works in Chrome, Edge, Brave and other Chromium browsers.
- Download the zip and unzip itPut the folder somewhere you'll keep it. The browser loads the extension from that folder, so don't delete it afterwards.
- Open
chrome://extensionsand turn on Developer modeIt's a switch in the top right. In Edge it'sedge://extensions, toggle on the left. - Click Load unpacked and pick the unzipped folderThe one with
manifest.jsonin it. The ampersand icon appears in your toolbar. - That's itNext time an app asks to connect to your Google, Microsoft, GitHub or Slack account, the briefing appears next to the Allow button. Click the toolbar icon any time to try the demo or review what's already connected.
James Linton
Social engineering researcher and speaker. Best known as the email prankster who got replies from White House officials and bank CEOs by pretending to be their colleagues, and who has spent the years since working out why that stuff works.
That thinking became Ask&Do, a framework for reading any request as what it asks, what it gets you to do, and what that's worth to the person asking. Before You Allow is the framework applied to one click. Built on his own time, in his own name, and free.