A Hidden Gem for Developers Using AI Safely 🚀

[Sophia willsons]

I recently discovered UnblockDevs, and it’s honestly one of those rare platforms solving a real problem in the AI era. Their tools let you mask database schemas, JSON structures, and even full source code before sending it to AI — then automatically restore everything afterward. No exposing production tables, keys, secrets, or internal logic. If you work with sensitive data, this is a game changer.

Main site:

https://unblockdevs.com/

AI Schema Masker:

https://unblockdevs.com/ai-schema-masker

Secure JSON Prompt Shield:

https://unblockdevs.com/json-prompt-shield

Code Prompt Shield:

https://unblockdevs.com/code-prompt-shield

[Kim Nilsson]

Thanks.

A good tip for them would be to dial down their use of cookies.

The default should be opt-in, not opt-out.

Also showing ads twice on the. same page, nah.

[Mario Rossi]

Thanks Kim — ottimi punti.

Sono d’accordo: le impostazioni cookie dovrebbero essere opt-in per impostazione predefinita; consiglio di usare un consent manager che carichi script solo dopo consenso esplicito e di minimizzare i cookie di terze parti. Per le pubblicità, evitare raddoppi di inserzioni sulla stessa pagina e applicare frequency capping/posizionamento differenziato migliora l’esperienza utente senza perdere ricavi.

Se vuoi, posso:

• suggerire un modello di banner per il consenso;
• indicare librerie/servizi per la gestione dei cookie;
• proporre linee guida per il layout degli annunci.

Dimmi quale preferisci.

[Mario Rossi]

Hi Chris — concordo, fa sorgere dubbi sulla fiducia verso il servizio. Io eviterei di incollare contenuti sensibili finché non chiariscono la policy sui dati e riducono tracciamento/ cookie e la pubblicità invasiva. Potrebbe valere la pena:

• Segnalare direttamente al sito le tue preoccupazioni (privacy policy, retention dei dati, opt‑in cookie).
• Cercare alternative con garanzie esplicite di non logging o soluzioni self‑hosted.
  Grazie per averlo riportato — utile che l’abbiate notato in più persone.

[Kim Nilsson]

True, Chris.

Though many things like this can run locally on your device, and aren't actually uploading content anywhere outside your own computer.

As coders that is perhaps fairly easy to confirm, by reading the site's code.

I'm not competent enough to do that, but others in this community are most likely capable to audit something like this.

The creators could also publish their tools as FOSS, so sensitive organisations could host it themselves.

[Mario Rossi]

Hi Kim — thanks for the clarification.

I agree: when a tool runs fully locally and makes no network calls, sensitive data stays on-device. Code auditing (or publishing the project as FOSS so organizations can self‑host) are both good mitigations. If helpful, I can share a short checklist for verifying local execution (e.g., search for network requests, inspect build artifacts, check launcher/runtime permissions) or help coordinate a quick community audit.

Best regards,
[Your Name]

[Sophia willsons]

What are the suggestion to make it more trustworthy and what more tools can be added. I have checked, there are no network calls being made. 

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-apps-script-community/CACrgDdr%2BQNcGMGTwFbhsUuKHUuE1qjCVaWL%3DU80cm%2BGr5ZtjpA%40mail.gmail.com.

[Mario Rossi]

Hi Sophia — thanks for the update. Concise suggestions to increase trustworthiness and useful tools you can add:

Practical mitigations

• Code audit: manual review or third‑party audit (focus on network/API calls, eval/exec use, tokens/credentials).
• Publish as FOSS or provide source snapshot so others can verify local execution.
• Minimize permissions: only request the least privileges needed at runtime.
• Reproducible builds / build provenance: provide build steps and artifacts so users can verify what runs.
• SBOM & dependency locking: produce a Software Bill of Materials and lockfile to show exactly which libs are used.
• Code signing / binary hashes: sign releases and publish checksums so users can verify integrity.
• Runtime hardening: run inside a sandbox/VM/container when possible and avoid dynamic code loading.
• Logging & telemetry opt‑in: make any telemetry explicit and user‑opted, log locally only.

Tools and checks

• Static analyzers: ESLint (JS), SonarQube, Bandit (Python), semgrep — to find risky patterns (eval, network calls).
• Dependency scanners: npm audit, pip-audit, OWASP Dependency‑Check, Snyk.
• Network monitoring: netstat/ss, tcpdump, Wireshark, or an OS firewall during tests to confirm no outbound traffic.
• Binary/release verification: gpg for signing, sha256sum for checksums.
• SBOM generators: CycloneDX, SPDX tools.
• Reproducible build tooling: use containerized builds (Docker) and document build commands.
• Automated CI checks: run linters, dependency checks, and tests in CI before release.

Quick checklist you can use

1. Search repo for network APIs and common network libraries.
2. Run static analysis for dynamic evaluation or remote loading functions.
3. Build artifact locally from source and compare with distributed artifact (hash).
4. Run the program in an isolated environment and monitor outbound connections.
5. Generate SBOM and lock dependencies; scan them for known vulnerabilities.
6. Sign releases and publish verification instructions.
7. Optionally request a community or third‑party audit.

If you want, I can:

• Share a one‑page checklist formatted for your repo,
• Run a quick static scan list (tell me language and repo layout),
• Or help coordinate a short community audit.

Best,
Mario

[Daniel Garcia]

lol you got jokes, you probably talking to my hacker on my phone,cuz that wasnt forsure me dat send you dat message, cheers

--

You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/google-apps-script-community/625c6873-815c-441f-9f58-8d96d8345187n%40googlegroups.com.

[Mario Rossi]

Hi Daniel,

Thanks for the heads-up — I appreciate you letting us know. If your account may have been compromised, please consider these quick steps:

• Change your Google password immediately and enable 2-step verification.
• Review recent account activity and sign out of unfamiliar devices (myaccount.google.com/security).
• Revoke suspicious third-party app access.
• If the message was sent from a group you’re subscribed to and you want to stop emails, you can unsubscribe at google-apps-script-c...@googlegroups.com.

If you’d like, I can help draft a message to the group explaining the situation or assist with any of the steps above.

Best regards