offline centric apps

src/SUMMARY.md

@@ -18,4 +18,9 @@
   - [Upload files safely](./4everland/upload_files_safely.md)
   - [Custom Policy](./4everland/custom_policy.md)
   - [Rust sts](./4everland/rust_sts.md)
+
+# Linux
+
+- [Offline Centric Apps](./linux/Offline_centric_apps.md)
+- [Firejail](./linux/firejail.md)
 

src/home.md

@@ -1,4 +1,3 @@
 # Achieve Websites
 
 [Achieve](https://evidence.probiquery.now.sh/)
-

src/linux/Offline_centric_apps.md

@@ -0,0 +1,61 @@
+# Enhancing Privacy and Security in Offline App Design with WebAssembly
+
+Its a draft, will update it with more details.
+
+Introduction:
+
+In the realm of application development, a shift towards designing offline apps by default is imperative for enhanced privacy and security. One key consideration involves the separation of folders for online connections and those accessed by the application for computation, ensuring data privacy without compromising functionality.
+
+Specification:
+
+**Isolating Online Connection and App-Read Folders:**
+
+- How can we segregate folders for online connections and those read by the app for computation to prevent data transmission to the server?
+
+**Ensuring Data Privacy:**
+
+- How can we determine which software reads data without transmitting it to the server?
+
+**Interaction with Server in the Absence of Data Read:**
+
+- If the software is restricted from reading data, how will it interact with the server?
+
+## Two App Paradigm: `Online App` and `Offline App` with [intents](../rust/one_wallet_app.md) based communication.
+
+The `Online App` has access only to an `Online Folder`, whereas the `Offline App` has access to both an `Offline Folder` and an `Online Folder`.
+
+"In this framework, we introduce two distinct applications: the `Online App`, a publicly audited high-security app with internet access, serving as the gatekeeper for all `Offline Apps` compatible with it, and the `Offline App`, designed for user interaction without direct internet access. The `Offline App` operates in a sandboxed environment, utilizing technologies like [firejail](./firejail.md) for added security.
+
+**Communication Framework:**
+
+- The `Online App` provides an API endpoint with three fields for the `Offline App`: a data description, the data itself, and the function name of the WebAssembly (wasm) code. Custom wasm logic facilitates remote server communication, enhancing interoperability.
+
+**User Traceability:**
+
+- Data exchanged between the `Offline App` and `Online App` can be traced by users, offering transparency and the ability to maintain logs.
+
+**Differentiation from Browsers:**
+
+- Unlike browsers, where file reads are potentially transmitted to servers due to constant internet connectivity, the `Offline App` allow intermittent internet access, promoting the development of offline-centric applications.
+
+**Promoting Offline App Development:**
+
+- By eliminating the necessity for constant internet connection, developers are encouraged to create offline apps, enhancing user privacy. For instance, a code editor like VSCode only requires internet access for initial downloads. But currently, apps are free to connect to the internet all the time, you never know what is going on in the background. You can't use [Firejail](./firejail.md) because it completely disables the internet for the app. Open source helps, but as software has become highly complicated, security analysis of open source software is left to only a few developers.
+
+**Permission-Based Connection:**
+
+- Implementing permission-based connections and providing a user interface for monitoring data flow ensures better control and transparency.
+
+**Enhancing User Experience:**
+
+- To mitigate the need of constant monitoring, introduce regex-based file ignore functionality, similar to .gitignore, allowing users to specify files that are exempt from server access in the `Online Folder`.
+
+**Addressing Security Concerns:**
+
+- What if the data that goes to the `Online App` is encrypted or obscured, so that you can't trace what data is being sent? Encrypting or obscuring data sent to the `Online App` can be mitigated by only transmitting unobscured data or files. The `Online App` can verify the integrity of received data by comparing it to the original files in its designated folder.
+
+Conclusion:
+
+A privacy-centric approach to app development, emphasizing offline functionality and transparent communication, not only enhances security but also empowers users to have greater control over their data. By implementing features such as permission-based connections, user traceability, and file ignore options, we can strike a balance between functionality and safeguarding user privacy.
+
+A similar experiment to design crypto wallet using intents here: [One Wallet App](../rust/one_wallet_app.md)

src/linux/firejail.md

@@ -0,0 +1,35 @@
+# Firjail
+
+Firejail is a security sandbox program that provides several benefits, particularly in enhancing the security and isolation of applications on a Linux system. Here are some of the key benefits of using Firejail:
+
+1. **Isolation:**
+   - Firejail creates a secure sandbox environment for applications, restricting their access to the rest of the system. This isolation helps prevent unauthorized access to sensitive files, directories, and system resources.
+
+2. **Reduced Attack Surface:**
+   - By limiting an application's access to only necessary files and resources, Firejail reduces the potential attack surface. This makes it more difficult for malicious actors to exploit vulnerabilities within the application.
+
+3. **Network Segregation:**
+   - Firejail can control network access for sandboxed applications. This prevents unauthorized network communication and adds an additional layer of security, especially for applications that don't require internet access.
+
+4. **Capability Filtering:**
+   - Firejail allows for the fine-tuning of an application's capabilities. Unnecessary capabilities can be dropped, further restricting what actions an application can perform, thus minimizing potential security risks.
+
+5. **Privilege Dropping:**
+   - Firejail can drop unnecessary privileges when launching an application. This means that even if an attacker manages to compromise the application, they will have fewer privileges, limiting the potential damage.
+
+6. **Resource Control:**
+   - Firejail enables control over system resources allocated to sandboxed applications. This can prevent resource-intensive applications from consuming excessive CPU, memory, or other resources, contributing to a more stable system performance.
+
+7. **Compatibility:**
+   - Firejail is designed to be compatible with a wide range of applications without requiring modification to the application itself. This makes it a flexible and practical solution for enhancing the security of diverse software.
+
+8. **Ease of Use:**
+   - Firejail is relatively easy to use and can be employed with various applications through simple command-line options. This ease of use encourages administrators and users to implement sandboxing as part of their security practices.
+
+9. **Transparent Operation:**
+   - Firejail operates transparently, allowing users to run applications within a sandbox without requiring significant changes to their usual workflow. This makes it convenient to integrate into existing systems and processes.
+
+10. **Open Source and Actively Maintained:**
+    - As an open-source project, Firejail benefits from continuous development and improvement. Regular updates and contributions from the community ensure that the tool remains effective and up-to-date in addressing emerging security challenges.
+
+In summary, Firejail provides a robust and flexible sandboxing solution for Linux systems, offering enhanced security, isolation, and control over applications, ultimately contributing to a more resilient and secure computing environment.

src/rust/one_wallet_app.md

@@ -1,4 +1,4 @@
-## Signing transactions with another secure app
+# Signing transactions with another secure app
 
 [Link](https://substrate.stackexchange.com/questions/10156/signing-transactions-with-another-secure-app)
 
@@ -15,13 +15,15 @@ You can also use the wallet for transacting [web2 apps](https://www.toptal.com/e
 > One wallet for all your signing needs. 
 
 ## Leptos
+
 You can use [leptos](https://github.com/leptos-rs/leptos) for dapp with tauri.
 
 Isomorphic: Leptos provides primitives to write isomorphic server functions, i.e., functions that can be called with the “same shape” on the client or server, but only run on the server. This means you can write your server-only logic (database requests, authentication etc.) alongside the client-side components that will consume it, and call server functions as if they were running in the browser, without needing to create and maintain a separate REST or other API.
 
 [Actix in leptos](https://docs.rs/leptos_actix/latest/leptos_actix/)
 
 ## One time password
+
 ```
  https://docs.rs/libotp/latest/libotp/
 ```
@@ -83,11 +85,7 @@ Example:
 ```
 
 ## Building a cryptowallet in rust
+
 [Website](https://tms-dev-blog.com/build-a-crypto-wallet-using-rust/)
 
 [Github](https://github.com/tmsdev82/rust-eth-crypto-wallet-tutorial)
-
-
-
-
-