0 reactions
I built KD Screen Guard: A zero-dependency, tamper-resistant lock screen overlay with WebAuthn biometrics & intruder camera capture
Most JavaScript screen lock libraries simply hide the UI.
If someone removes an overlay through DevTools or tampers with the DOM, the "security" often disappears. That approach isn't enough for applications handling sensitive enterprise data.
I wanted to build something significantly more resilient.
🚀 Today I'm excited to release **kd-screen-guard (v1.0.1)** on npm.
It's a zero-dependency, tamper-resistant screen security library for Vanilla JavaScript, React, and Vue 3, designed to protect sensitive user sessions during inactivity.
Some of the engineering behind it:
🔐 PBKDF2 (100,000 iterations) for secure key derivation.
👆 Native WebAuthn authentication (Touch ID, Face ID, Windows Hello & YubiKey).
📷 Automatic WebRTC intruder snapshots when security violations are detected.
⚡ Cryptographic operations running inside Web Workers to keep the UI responsive.
🛡️ Self-healing DOM MutationObserver protection against overlay tampering.
Building this project required combining browser cryptography, WebAuthn, WebRTC, Web Workers, accessibility, and client-side security mechanisms into a single lightweight package with **zero external dependencies**.
If you're building enterprise dashboards, admin panels, healthcare, finance, or any application where unattended sessions are a security concern, I'd love to hear your feedback.
🔗 Live Demo:
https://khvichadev.github.io/kd-screen-guard/demo/
📦 npm:
https://www.npmjs.com/package/kd-screen-guard
🐙 GitHub:
https://github.com/KhvichaDev/kd-screen-guard
Feedback, ideas, and contributions are always welcome.
\#JavaScript #TypeScript #CyberSecurity #WebDevelopment #ReactJS #VueJS #OpenSource #npm #WebAuthn #KhvichaDev
#technology #js #programming #dev
Most JavaScript screen lock libraries simply hide the UI.
If someone removes an overlay through DevTools or tampers with the DOM, the "security" often disappears. That approach isn't enough for applications handling sensitive enterprise data.
I wanted to build something significantly more resilient.
🚀 Today I'm excited to release **kd-screen-guard (v1.0.1)** on npm.
It's a zero-dependency, tamper-resistant screen security library for Vanilla JavaScript, React, and Vue 3, designed to protect sensitive user sessions during inactivity.
Some of the engineering behind it:
🔐 PBKDF2 (100,000 iterations) for secure key derivation.
👆 Native WebAuthn authentication (Touch ID, Face ID, Windows Hello & YubiKey).
📷 Automatic WebRTC intruder snapshots when security violations are detected.
⚡ Cryptographic operations running inside Web Workers to keep the UI responsive.
🛡️ Self-healing DOM MutationObserver protection against overlay tampering.
Building this project required combining browser cryptography, WebAuthn, WebRTC, Web Workers, accessibility, and client-side security mechanisms into a single lightweight package with **zero external dependencies**.
If you're building enterprise dashboards, admin panels, healthcare, finance, or any application where unattended sessions are a security concern, I'd love to hear your feedback.
🔗 Live Demo:
https://khvichadev.github.io/kd-screen-guard/demo/
📦 npm:
https://www.npmjs.com/package/kd-screen-guard
🐙 GitHub:
https://github.com/KhvichaDev/kd-screen-guard
Feedback, ideas, and contributions are always welcome.
\#JavaScript #TypeScript #CyberSecurity #WebDevelopment #ReactJS #VueJS #OpenSource #npm #WebAuthn #KhvichaDev
#technology #js #programming #dev
0 reactions
Storing data from two domains in a single IndexedDB data store
You might know different client-side data storage methods in #JavaScript : #cookies , #localStorage , #sessionStorage , and perhaps even #IndexedDB . All share the same limitation: they won't let you store data across domains.
But if you can write and use a browser extension, these come with another data storage bucket. Browser extensions come with a manifest.json file that lets you specify all the domains you want to work with. #Chrome Chrome.storage will let you store and read data across domains.
I used chrome.storage.local as a temporary data storage place. I use the #Dexie library to create my IndexedDB data store, database, and to insert the records. I monkey patched Dexie's add() and bulkPut() methods to send a message to background.js. Upon receiving the message, background.js clears chrome.local.storage and inserts what we inserted in IndexedDB.
Then, when I switch to another tab showing my second domain, background.js responds to chrome.tabs.onActivated and calls a function on that page with the data from chrome.local.storage . That function does a bulk insert of the data in a second IndexedDB data store and database.
And voilà, you now have the data from both domains in a single IndexedDB data store.
#programming #technology #js #dev
source
You might know different client-side data storage methods in #JavaScript : #cookies , #localStorage , #sessionStorage , and perhaps even #IndexedDB . All share the same limitation: they won't let you store data across domains.
But if you can write and use a browser extension, these come with another data storage bucket. Browser extensions come with a manifest.json file that lets you specify all the domains you want to work with. #Chrome Chrome.storage will let you store and read data across domains.
I used chrome.storage.local as a temporary data storage place. I use the #Dexie library to create my IndexedDB data store, database, and to insert the records. I monkey patched Dexie's add() and bulkPut() methods to send a message to background.js. Upon receiving the message, background.js clears chrome.local.storage and inserts what we inserted in IndexedDB.
Then, when I switch to another tab showing my second domain, background.js responds to chrome.tabs.onActivated and calls a function on that page with the data from chrome.local.storage . That function does a bulk insert of the data in a second IndexedDB data store and database.
And voilà, you now have the data from both domains in a single IndexedDB data store.
#programming #technology #js #dev
source
0 reactions
Hello Support Team,
I am reporting an issue where the trading interface on tangled.com fails to load (blank screen with a purple loading bar). All other sections of the website are working correctly.
The browser console shows the following error:
Error Message: Content Security Policy of your site blocks the use of 'eval' in JavaScript
Affected Resource: 2.chunk.js:2 (Directive: script-src)
Reason: The CSP prevents the execution of eval(), causing the trading script to crash during initialization.
I am actively using the trading bot for my strategies and need access to the interface to manage my positions. Could you please check if the CSP headers need to be updated or if the script can be recompiled without relying on unsafe-eval?
Thank you for your assistance!
#millix #mlx #tangled #tradingbot #javascript #web3 #dapp #support #tradinginterface #millixcommunity
I am reporting an issue where the trading interface on tangled.com fails to load (blank screen with a purple loading bar). All other sections of the website are working correctly.
The browser console shows the following error:
Error Message: Content Security Policy of your site blocks the use of 'eval' in JavaScript
Affected Resource: 2.chunk.js:2 (Directive: script-src)
Reason: The CSP prevents the execution of eval(), causing the trading script to crash during initialization.
I am actively using the trading bot for my strategies and need access to the interface to manage my positions. Could you please check if the CSP headers need to be updated or if the script can be recompiled without relying on unsafe-eval?
Thank you for your assistance!
#millix #mlx #tangled #tradingbot #javascript #web3 #dapp #support #tradinginterface #millixcommunity
