#indexeddb — Public Fediverse posts

Je continue à faire évoluer Imagilire Libre : l’application passe à IndexedDB avec Dexie pour un stockage local plus solide et plus fiable.
J’ai aussi ajouté l’export/import des paramètres et du dictionnaire syllabique personnalisé.
🔒 Les données restent stockées localement sur l’appareil. Aucune n’est transmise aux serveurs Imagilire.

https://imagilire.fr/imagilire-libre

#Imagilire #ImagilireLibre #AccessibilitéNumérique #IndexedDB #Dexie #ViePrivée

Công cụ quản lý LocalStorage, SessionStorage, Cookies và IndexedDB mới cho Chrome!
Tính năng:
- Sửa đổi JSON dễ dàng
- Quản lý IndexedDB toàn diện
- Chuyển đổi giữa các tài khoản người dùng nhanh chóng
- Đồng bộ hóa trên nhiều thiết bị
#EasyLocalStorageManager #LocalStorage #SessionStorage #Cookies #IndexedDB #ChromeExtension #SvelteJS #ManifestV3 #Freemium #CloudSync
#CôngCụQuảnLý #TrìnhDuyệt #PhátTriểnWeb #TínhNăngMới #ĐồngBộHóa #TàiKhoản #NgườiDùng #ThiếtBị #Chrome #Extension #Svelte #Mani

My esteemed followers, you have posted a total of 375,809 statuses to the #fediverse. 22% of you have posted in the last 24h. You are a chatty bunch! ;-)

Check out my new #sideproject: *fedi-followers*. A privacy-friendly fediverse #followers explorer as #localonly #staticwebapp, decentrally hosted on the #ipfs. See who's actually following (and unfollowing) you over time and much more.

https://fedi--followers-data0-one.ipns.dweb.link/

#decentralization #mastodev #esmodules #importmaps #nobuild #indexeddb #preact

My esteemed followers, you have posted a total of 375,809 statuses to the #fediverse. 22% of you have posted in the last 24h. You are a chatty bunch! ;-)

Check out my new #sideproject: *fedi-followers*. A privacy-friendly fediverse #followers explorer as #localonly #staticwebapp, decentrally hosted on the #ipfs. See who's actually following (and unfollowing) you over time and much more.

https://fedi--followers-data0-one.ipns.dweb.link/

#decentralization #mastodev #esmodules #importmaps #nobuild #indexeddb #preact

I've built a thing.

Sometimes my follower count seemingly fluctuates at random. To understand why, I dug into the #MastodonAPI and created "fedi-followers":

A privacy-friendly #fediverse #followers explorer as local-only static web app, decentrally hosted on the #ipfs. See who's actually following (and unfollowing) you over time and much more.

https://fedi--followers-data0-one.ipns.dweb.link/

#mastodev #javascript #webapp #staticwebapp #nobuild #esmodules #importmaps #indexeddb #preact #htm

I've built a thing.

Sometimes my follower count seemingly fluctuates at random. To understand why, I dug into the #MastodonAPI and created "fedi-followers":

A privacy-friendly #fediverse #followers explorer as local-only static web app, decentrally hosted on the #ipfs. See who's actually following (and unfollowing) you over time and much more.

https://fedi--followers-data0-one.ipns.dweb.link/

#mastodev #javascript #webapp #staticwebapp #nobuild #esmodules #importmaps #indexeddb #preact #htm

"Encryption at Rest" for JavaScript Projects

Following a previous post (https://infosec.exchange/@xoron/113446067764347249), which can be summarized as: I'm tackling state management with an extra twist: integrating encryption at rest!

I created some updates to the WIP pull-request. The behavior is as follows.

- The user is prompted for a password if one isn't provided programmatically.
- This will allow for developers to create a custom password prompts in their application. The default fallback is to use a JavaScript prompt().
- It also seems possible to enable something like "fingerprint/face encryption" for some devices using the webauthn api. (This works, but the functionality is a bit flaky and needs to be fixed before rolling out.)
- Using AES-GCM with 1000000 iterations of PBKDF2 to derive the key from the password.
- The iterations can be increased in exchange for slower performance. It isn't currently configurable, but it might be in the future.
- The salt and AAD need to be deterministic and so to simplify user input, the salt as AAD are derived as the sha256 hash of the password. (Is this a good idea?)

The latest version of the code can be seen in the PR: https://github.com/positive-intentions/dim/pull/9

I'm keen to get feedback on the approach and the implementation before i merge it into the main branch.

#JavaScript #Encryption #IndexedDB #WebDevelopment #CryptoAPI #FrontendDev #ReactHooks #StateManagement #WebSecurity #OpenSource #PersonalProjects

"Encryption at Rest" for JavaScript Projects

Following a previous post (https://infosec.exchange/@xoron/113446067764347249), which can be summarized as: I'm tackling bottom-up state management with an extra twist: integrating encryption at rest!

I created some updates to the WIP pull-request. The behavior is as follows.

- The user is prompted for a password if one isn't provided programmatically.
- This will allow for developers to create a custom password prompts in their application. The default fallback is to use a JavaScript prompt().
- It also seems possible to enable something like "fingerprint/face encryption" for some devices using the webauthn api. (This works, but the functionality is a bit flaky and needs to be fixed before rolling out.)
- Using AES-GCM with 1000000 iterations of PBKDF2 to derive the key from the password.
- The iterations can be increased in exchange for slower performance. It isn't currently configurable, but it might be in the future.
- The salt and AAD need to be deterministic and so to simplify user input, the salt as AAD are derived as the sha256 hash of the password. (Is this a good idea?)

The latest version of the code can be seen in the PR: https://github.com/positive-intentions/dim/pull/9

I'm keen to get feedback on the approach and the implementation before i merge it into the main branch.

#JavaScript #Encryption #IndexedDB #WebDevelopment #CryptoAPI #FrontendDev #ReactHooks #StateManagement #WebSecurity #OpenSource #PersonalProjects

"Encryption at Rest" for JavaScript Projects

Following a previous post (https://infosec.exchange/@xoron/113446067764347249), which can be summarized as: I'm tackling state management with an extra twist: integrating encryption at rest!

I created some updates to the WIP pull-request. The behavior is as follows.

- The user is prompted for a password if one isn't provided programmatically.
- This will allow for developers to create a custom password prompts in their application. The default fallback is to use a JavaScript prompt().
- It also seems possible to enable something like "fingerprint/face encryption" for some devices using the webauthn api. (This works, but the functionality is a bit flaky and needs to be fixed before rolling out.)
- Using AES-GCM with 1000000 iterations of PBKDF2 to derive the key from the password.
- The iterations can be increased in exchange for slower performance. It isn't currently configurable, but it might be in the future.
- The salt and AAD need to be deterministic and so to simplify user input, the salt as AAD are derived as the sha256 hash of the password. (Is this a good idea?)

The latest version of the code can be seen in the PR: https://github.com/positive-intentions/dim/pull/9

I'm keen to get feedback on the approach and the implementation before i merge it into the main branch.

#JavaScript #Encryption #IndexedDB #WebDevelopment #CryptoAPI #FrontendDev #ReactHooks #StateManagement #WebSecurity #OpenSource #PersonalProjects

"Encryption at Rest" for JavaScript Projects

Following a previous post (https://infosec.exchange/@xoron/113446067764347249), which can be summarized as: I'm tackling state management with an extra twist: integrating encryption at rest!

I created some updates to the WIP pull-request. The behavior is as follows.

- The user is prompted for a password if one isn't provided programmatically.
- This will allow for developers to create a custom password prompts in their application. The default fallback is to use a JavaScript prompt().
- It also seems possible to enable something like "fingerprint/face encryption" for some devices using the webauthn api. (This works, but the functionality is a bit flaky and needs to be fixed before rolling out.)
- Using AES-GCM with 1000000 iterations of PBKDF2 to derive the key from the password.
- The iterations can be increased in exchange for slower performance. It isn't currently configurable, but it might be in the future.
- The salt and AAD need to be deterministic and so to simplify user input, the salt as AAD are derived as the sha256 hash of the password. (Is this a good idea?)

The latest version of the code can be seen in the PR: https://github.com/positive-intentions/dim/pull/9

I'm keen to get feedback on the approach and the implementation before i merge it into the main branch.

#JavaScript #Encryption #IndexedDB #WebDevelopment #CryptoAPI #FrontendDev #ReactHooks #StateManagement #WebSecurity #OpenSource #PersonalProjects

"Encryption at Rest" for JavaScript Projects

Following a previous post (https://infosec.exchange/@xoron/113446067764347249), which can be summarized as: I'm tackling state management with an extra twist: integrating encryption at rest!

I created some updates to the WIP pull-request. The behavior is as follows.

- The user is prompted for a password if one isn't provided programmatically.
- This will allow for developers to create a custom password prompts in their application. The default fallback is to use a JavaScript prompt().
- It also seems possible to enable something like "fingerprint/face encryption" for some devices using the webauthn api. (This works, but the functionality is a bit flaky and needs to be fixed before rolling out.)
- Using AES-GCM with 1000000 iterations of PBKDF2 to derive the key from the password.
- The iterations can be increased in exchange for slower performance. It isn't currently configurable, but it might be in the future.
- The salt and AAD need to be deterministic and so to simplify user input, the salt as AAD are derived as the sha256 hash of the password. (Is this a good idea?)

The latest version of the code can be seen in the PR: https://github.com/positive-intentions/dim/pull/9

I'm keen to get feedback on the approach and the implementation before i merge it into the main branch.

#JavaScript #Encryption #IndexedDB #WebDevelopment #CryptoAPI #FrontendDev #ReactHooks #StateManagement #WebSecurity #OpenSource #PersonalProjects

"Encryption at Rest" for JavaScript Projects

I'm developing a JavaScript UI framework for personal projects, and I'm tackling state management with an extra twist: integrating encryption at rest!

Inspired by this React Hook: Async State Management (https://positive-intentions.com/blog/async-state-management), I’m extending it to support encrypted persistent data. Here's how:

✨ The Approach:

Using IndexedDB for storage.

Data is encrypted before saving and decrypted when loading using the Browser Cryptography API.

Event listeners will also be encrypted/decrypted to avoid issues like browser extensions snooping on events.

The password (should never be stored) is entered by the user at runtime to decrypt the data. (Currently hardcoded for now!)

The salt will be stored unencrypted in IndexedDB to generate the key.

🔗 Proof of Concept:
You can try it out here: GitHub PR (https://github.com/positive-intentions/dim/pull/8). Clone or run it in Codespaces and let me know what you think!

❓ Looking for Feedback:
Have I missed anything? Are there better ways to make this storage secure?

Let's make secure web UIs a reality together! 🔒

#JavaScript #Encryption #IndexedDB #WebDevelopment #CryptoAPI #FrontendDev #ReactHooks #StateManagement #WebSecurity #OpenSource #PersonalProjects

"Encryption at Rest" for JavaScript Projects

I'm developing a JavaScript UI framework for personal projects, and I'm tackling state management with an extra twist: integrating encryption at rest!

Inspired by this React Hook: Async State Management (https://positive-intentions.com/blog/async-state-management), I’m extending it to support encrypted persistent data. Here's how:

✨ The Approach:

Using IndexedDB for storage.

Data is encrypted before saving and decrypted when loading using the Browser Cryptography API.

Event listeners will also be encrypted/decrypted to avoid issues like browser extensions snooping on events.

The password (should never be stored) is entered by the user at runtime to decrypt the data. (Currently hardcoded for now!)

The salt will be stored unencrypted in IndexedDB to generate the key.

🔗 Proof of Concept:
You can try it out here: GitHub PR (https://github.com/positive-intentions/dim/pull/8). Clone or run it in Codespaces and let me know what you think!

❓ Looking for Feedback:
Have I missed anything? Are there better ways to make this storage secure?

Let's make secure web UIs a reality together! 🔒

#JavaScript #Encryption #IndexedDB #WebDevelopment #CryptoAPI #FrontendDev #ReactHooks #StateManagement #WebSecurity #OpenSource #PersonalProjects

"Encryption at Rest" for JavaScript Projects

I'm developing a JavaScript UI framework for personal projects, and I'm tackling state management with an extra twist: integrating encryption at rest!

Inspired by this React Hook: Async State Management (https://positive-intentions.com/blog/async-state-management), I’m extending it to support encrypted persistent data. Here's how:

✨ The Approach:

Using IndexedDB for storage.

Data is encrypted before saving and decrypted when loading using the Browser Cryptography API.

Event listeners will also be encrypted/decrypted to avoid issues like browser extensions snooping on events.

The password (should never be stored) is entered by the user at runtime to decrypt the data. (Currently hardcoded for now!)

The salt will be stored unencrypted in IndexedDB to generate the key.

🔗 Proof of Concept:
You can try it out here: GitHub PR (https://github.com/positive-intentions/dim/pull/8). Clone or run it in Codespaces and let me know what you think!

❓ Looking for Feedback:
Have I missed anything? Are there better ways to make this storage secure?

Let's make secure web UIs a reality together! 🔒

#JavaScript #Encryption #IndexedDB #WebDevelopment #CryptoAPI #FrontendDev #ReactHooks #StateManagement #WebSecurity #OpenSource #PersonalProjects

"Encryption at Rest" for JavaScript Projects

I'm developing a JavaScript UI framework for personal projects, and I'm tackling state management with an extra twist: integrating encryption at rest!

Inspired by this React Hook: Async State Management (https://positive-intentions.com/blog/async-state-management), I’m extending it to support encrypted persistent data. Here's how:

✨ The Approach:

Using IndexedDB for storage.

Data is encrypted before saving and decrypted when loading using the Browser Cryptography API.

Event listeners will also be encrypted/decrypted to avoid issues like browser extensions snooping on events.

The password (should never be stored) is entered by the user at runtime to decrypt the data. (Currently hardcoded for now!)

The salt will be stored unencrypted in IndexedDB to generate the key.

🔗 Proof of Concept:
You can try it out here: GitHub PR (https://github.com/positive-intentions/dim/pull/8). Clone or run it in Codespaces and let me know what you think!

❓ Looking for Feedback:
Have I missed anything? Are there better ways to make this storage secure?

Let's make secure web UIs a reality together! 🔒

#JavaScript #Encryption #IndexedDB #WebDevelopment #CryptoAPI #FrontendDev #ReactHooks #StateManagement #WebSecurity #OpenSource #PersonalProjects

"Encryption at Rest" for JavaScript Projects

I'm developing a JavaScript UI framework for personal projects, and I'm tackling state management with an extra twist: integrating encryption at rest!

Inspired by this React Hook: Async State Management (https://positive-intentions.com/blog/async-state-management), I’m extending it to support encrypted persistent data. Here's how:

✨ The Approach:

Using IndexedDB for storage.

Data is encrypted before saving and decrypted when loading using the Browser Cryptography API.

Event listeners will also be encrypted/decrypted to avoid issues like browser extensions snooping on events.

The password (should never be stored) is entered by the user at runtime to decrypt the data. (Currently hardcoded for now!)

The salt will be stored unencrypted in IndexedDB to generate the key.

🔗 Proof of Concept:
You can try it out here: GitHub PR (https://github.com/positive-intentions/dim/pull/8). Clone or run it in Codespaces and let me know what you think!

❓ Looking for Feedback:
Have I missed anything? Are there better ways to make this storage secure?

Let's make secure web UIs a reality together! 🔒

#JavaScript #Encryption #IndexedDB #WebDevelopment #CryptoAPI #FrontendDev #ReactHooks #StateManagement #WebSecurity #OpenSource #PersonalProjects

What kind of #Moderation would you wish a #SocialMedia service like #Mastodon or #FireFish to have?

If you're familiar with #ActivityPub, can it be implemented with it?

I'm specifically looking for user moderation tools for #PeerToPeer #P2P solutions where service data can't be manually moderated by a central actor. The service data would exist until it is forgotten (no one is sharing it).

Profile and post data would be saved in browser database (#IndexedDB) and peer discovery would be handled by #HyperSwarm or similar. The whole service would be a #PWA, requiring zero server resources beyond loading the PWA, if possible.

Currently I have this:
- honor thread starter #blocklist (by hiding and not sharing those comments - individual clients could still show these and share, resulting in less effective moderation)
- allow thread starter to moderate their threads (don't know how to implement this, yet)
- allow post and comment editing (implement post version checking and automatic updates - again, a client might ignore updates or collect history, resulting in less effective moderation)
- profile reputation, automatic blocking based on reputation and shared blocklists, #whitelist and shared whitelists, blocklist and shared blocklists (see above); essentially a #WebOfTrust implementation
- visibility controls
- sharing controls (for service data; by default interactions and own data would be saved locally and shared to network; data that is offline isn't reachable)