Security isn’t something you sprinkle on at the end of development. It’s the quiet architecture underneath — the decisions you make about what your code shouldn’t be allowed to do.
With the next major ORGanizer release, we’re doubling down on that philosophy. The goal is simple: give both users and companies confidence that ORGanizer behaves exactly as expected, nothing more, nothing less.
Let’s dig into what’s coming.
Policy support: company-wide control without chaos
ORGanizer has always been about flexibility — but flexibility without guardrails becomes risk.
We’re introducing policy-based control over key features like:
- Login and credential storage
- Sync and local storage
- External calls
Enterprises will soon be able to centrally whitelist or blacklist specific features. That means your IT or InfoSec team can make ORGanizer fully compliant with company policy before it ever reaches a user’s browser.
No hidden toggles, no “trust me” code paths — just explicit, auditable policy.
Permission diet: trimming the fat
Browser extensions often fall into the trap of permission creep — asking for everything up front, just in case.
We’re changing that.
Soon, many permissions that are currently “mandatory” will become optional and requested only when needed.
If a feature needs a specific permission, you’ll be asked then, not before.
This “ask-when-needed” model reduces the trust barrier for new users and shrinks the overall attack surface.
Manifest V3 cleanup: less is more
Manifest V3, the latest browser extension framework, forces every developer to confront a hard truth: do you really need that permission?
The honest answer is often “no.”
So we’re pruning permissions — permanently removing some that no longer make sense in ORGanizer’s architecture.
It’s a chance to rewrite our extension with security as the starting point, not an afterthought.
Transparent by default: full logging and auditing
Security isn’t only about what you block — it’s also about what you can see.
ORGanizer will soon include a complete logging system showing:
- What external calls are made
- Why they’re made
- Who (which component or user context) triggered them
Anything ORGanizer brings in or sends out will be logged and available for auditing.
This means you’ll know exactly what happens under the hood — a step toward radical transparency in how browser extensions interact with the world.
Why this matters: lessons from the field
In recent months, the Salesforce ecosystem has seen its share of storms.
Attackers haven’t been breaking Salesforce itself — they’ve been going sideways, exploiting the tools and connected apps people trust.
- UNC6040 used voice phishing to trick employees into installing a malicious clone of Salesforce’s Data Loader, which then quietly exfiltrated data (Google Threat Intel)
- UNC6395 stole OAuth tokens via the Salesloft and Drift integrations, granting unauthorized access to Salesforce instances across multiple organizations (Google Cloud Security Blog)
- Salesforce itself has responded by tightening rules: starting September 2025, most users will be blocked from authorizing uninstalled connected apps (Salesforce Admin Blog)
The pattern is clear. Attackers don’t always need a platform exploit.
Sometimes, they just need a generous permission.
ORGanizer’s new architecture is designed to make that kind of abuse harder — not just for us, but for the entire ecosystem that relies on trustworthy integrations.
Building trust, one permission at a time
We’re not chasing headlines or compliance stickers. We’re chasing something rarer: trust you can verify.
With these updates, ORGanizer will:
- Ask for fewer permissions
- Log every external interaction
- Let companies enforce their own security policies
The plan is to publish detailed documentation with each release: which permissions were removed, which became optional, and how to configure your policy profiles.
Security isn’t static — it’s a process.
We’re excited to make ORGanizer part of the solution, not another risk vector.
