
## Re-Engineering the Web Browser

Modern web browsers have become bloated operating systems of their own, consuming gigabytes of RAM and constantly sending telemetry to advertising networks. At RebelRoot, we set out to build a web experience that puts the user back in control.

<Quote
  content="We wanted a browser that does exactly what it is designed to do: load pages instantly and respect user data, without the corporate baggage."
  author="RebelRoot Core Dev Team"
  cite="https://rebelroot.org"
/>

## Technical Architecture: Hybrid Native Core

Instead of packing a full Chromium rendering engine (Blink) which would bloat the download size by 80MB+, Omni Browser is built on a customized native Android WebKit integration. This hybrid architecture pairs the rendering efficiency of native system libraries with custom middleware hooks written in Kotlin.

By decoupling the layout renderer from networking and session persistence, we are able to intercept data leaks before they are committed to local databases or sent over the network.

## Intercepting Storage & Fingerprinting Attempts

Traditional WebViews allow pages to read device metrics (fingerprinting) and set tracking cookies unimpeded. Omni Browser introduces a secure sandbox model that intercepts and overrides standard Web storage APIs. We inject a custom JavascriptInterface at page initialization to monitor storage mutations:

<Code
  code="
package com.rebelroot.omnibrowser.security

import android.webkit.JavascriptInterface
import android.webkit.WebView
import org.json.JSONObject

class SecureStorageBridge(private val webView: WebView) {

    // Overrides window.localStorage.setItem and window.sessionStorage.setItem
    @JavascriptInterface
    fun onStorageWrite(type: String, key: String, value: String): Boolean {
        // Evaluate key against known tracking payloads or entropy markers
        if (isPotentialTrackerKey(key) || value.length > 512) {
            logBlockedAttempt(key, type)
            return false // Block write operation
        }
        return true // Allow write
    }

    private fun isPotentialTrackerKey(key: String): Boolean {
        val pattern = Regex(&quot;(?:_utm|_ga|_fbp|fingerprint|device_id|uid|visitor_id)&quot;, RegexOption.IGNORE_CASE)
        return pattern.containsMatchIn(key)
    }

    private fun logBlockedAttempt(key: String, type: String) {
        // Native logging and UI shield indicator update
        System.out.println(&quot;Blocked suspected tracking write to &quot; + type + &quot;: &quot; + key)
    }
}
"
  language="kotlin"
/>

## Granular Cookie Isolation Policy

To prevent cross-site tracking, Omni Browser isolates cookies at the domain level. Standard browsers share cookie jars globally, making it easy for tracking scripts to stitch user sessions across different domains. 

Omni Browser partitions storage using strict sandbox policies, so cookies created by third-party widgets are scoped solely to their originating iframe and never leaked to the host page document:

- **Third-Party Partitioning**: If a social share button attempts to read cookies, it receives a sandboxed, ephemeral jar containing zero reference data.
- **Local Persistence Controls**: All session cookies are automatically cleared from the local database upon tab termination unless explicitly whitelisted by the user.



## Re-Imagining Digital Literature

The traditional publishing ecosystem is broken. Distribution platforms take massive cuts, enforce draconian digital rights management (DRM), and dictate content policies. Authors are left dependent, and readers lose actual ownership of the books they buy.

MOCNovel restores digital sovereignty. Built on local-first principles, it acts as a private bookshelf and a robust self-publishing portal.

<Quote
  content="Digital literature should be just as permanent and private as a physical book on a shelf. We don't believe in expiring licenses or platform lock-in."
  author="RebelRoot Publishing Working Group"
  cite="https://rebelroot.org"
/>

## Technical Architecture: Local-First Parsing Engine

EPUB files are essentially zipped archives containing HTML files, CSS sheets, and XML metadata files. Most reading applications rely on remote cloud renderers or server-side parser daemons to display book chapters. This architecture centralizes reading history and metadata.

MOCNovel is built to decompress and parse books entirely on the client-side. We utilize browser-native ZIP decompression (via WebAssembly-backed compression libraries) and native DOMParsers to extract XML paths dynamically.

## Decrypting and Parsing EPUB Packages

When a user imports an ebook into MOCNovel, the engine performs the following processing pipeline in the browser:

1. **Locate the Package Entry Document**: Read `META-INF/container.xml` to find the path to the `.opf` package file.
2. **Extract Metadata & Manifest**: Parse the `.opf` file to discover book details (title, author, rights) and index the locations of all HTML chapters.
3. **Resolve Spine Order**: Sequence the HTML pages according to the spine declaration so the reader can scroll sequentially.

Here is how the parsing engine resolves the package path without sending the file to any server:

<Code
  code="
// Client-side extraction of EPUB manifest OPF path using native DOMParser
async function getOPFFilePath(zipArchive) {
  // Read container.xml from the zipped package
  const containerFile = await zipArchive.file(&quot;META-INF/container.xml&quot;).async(&quot;string&quot;);
  
  const parser = new DOMParser();
  const xmlDoc = parser.parseFromString(containerFile, &quot;text/xml&quot;);
  
  // Find the rootfile element containing the full-path attribute
  const rootfile = xmlDoc.getElementsByTagName(&quot;rootfile&quot;)[0];
  if (!rootfile) {
    throw new Error(&quot;Malformed EPUB container: OPF file path not found&quot;);
  }
  
  const opfPath = rootfile.getAttribute(&quot;full-path&quot;);
  return opfPath; // Returns e.g. 'OEBPS/content.opf'
}
"
  language="javascript"
/>

## Offline Annotation & Progress Synchronization

MOCNovel uses an offline-first database (using IndexedDB wrappers or native SQLite bindings) to cache reading positions, bookmark offsets, and custom page highlights.

The database structure maps annotations using standard EPUB canonical fragment identifiers (EpubCFI) rather than character offsets. This ensures annotations remain perfectly aligned even if the user resizes text dimensions or changes page styling:

```sql
CREATE TABLE annotations (
  id TEXT PRIMARY KEY,
  book_hash TEXT NOT NULL,
  cfi_range TEXT NOT NULL,
  highlight_color TEXT,
  note_content TEXT,
  created_at INTEGER NOT NULL,
  FOREIGN KEY(book_hash) REFERENCES books(hash)
);
```

By storing bookmarks local-first, readers retain absolute custody over their reading notes and habits, with optional peer-to-peer sync options using end-to-end encrypted tunnels.



## Simplifying Independent E-commerce

Adding e-commerce to a static website usually requires loading heavy, tracking-laden third-party widgets or maintaining a complex backend database. These solutions introduce security vulnerabilities, drag down performance, and profile visitors.

CampCart provides an alternative: a zero-dependency, secure shopping cart widget running purely in the browser.

<Quote
  content="We wanted to prove that you can build a complete, highly-responsive shopping cart experience using purely static files and client-side cryptography."
  author="RebelRoot Front-End Developers"
  cite="https://rebelroot.org"
/>

## Under the Hood: Pure Client-Side State

CampCart relies on a robust JavaScript state machine that manages product entries, quantities, and price calculations on the client. It persists cart items in `localStorage` securely to preserve the shopping state across page reloads.

Because static sites do not have a server to dynamically calculate prices and generate tokens, they are traditionally prone to price-tampering attacks — where a malicious user edits client-side JS values to checkout with cheaper amounts.

## Solving Price-Tampering via Cryptographic Signing

To thwart client-side manipulation without running an active database server, CampCart uses cryptographic payload verification. 

When you initialize your static store, product definitions (including IDs, titles, and unit prices) are declared alongside a pre-computed signature generated by your publishing suite using a private key. 

When a user initiates checkout:
1. The widget bundles the items, counts, and prices into a payload.
2. The payload and the signatures are sent to our lightweight, stateless payment forwarding API.
3. The API verifies the cryptographic signatures against the store owner's public key. If a price value doesn't match the signature, the checkout transaction is instantly rejected.

Here is how the verification signature is verified inside the serverless API:

<Code
  code="
// Web Crypto API method to verify static store product details
async function verifyProductSignature(publicKeyPem, productPayload, signatureBase64) {
  const enc = new TextEncoder();
  const rawKey = pemToDer(publicKeyPem);
  
  const publicKey = await window.crypto.subtle.importKey(
    &quot;spki&quot;,
    rawKey,
    { name: &quot;RSASSA-PKCS1-v1_5&quot;, hash: &quot;SHA-256&quot; },
    false,
    [&quot;verify&quot;]
  );

  const data = enc.encode(JSON.stringify({
    id: productPayload.id,
    price: productPayload.price,
    currency: productPayload.currency
  }));

  const signature = Uint8Array.from(atob(signatureBase64), c => c.charCodeAt(0));
  
  return await window.crypto.subtle.verify(
    &quot;RSASSA-PKCS1-v1_5&quot;,
    publicKey,
    signature,
    data
  );
}

// Helper to convert PEM string back to binary DER
function pemToDer(pem) {
  const pemHeader = &quot;-----BEGIN PUBLIC KEY-----&quot;;
  const pemFooter = &quot;-----END PUBLIC KEY-----&quot;;
  const pemContents = pem.substring(pemHeader.length, pem.length - pemFooter.length);
  const cleanPem = pemContents.replace(/\s+/g, &quot;&quot;);
  return Uint8Array.from(atob(cleanPem), c => c.charCodeAt(0)).buffer;
}
"
  language="javascript"
/>

## Performance Benchmarks

By eliminating database handshakes and network overhead during browsing:
- **Time-to-Interactive (TTI)**: Remains under 0.2 seconds on standard mobile devices.
- **Payload Weight**: The entire CampCart engine is a single file weighing under 12KB (minified and gzipped).
- **Integrations**: Mounts as a native Web Component (`<camp-cart>`), making it compatible with any static site builder.



## Reclaiming Your Infrastructure

Trusting third-party SaaS providers with your critical sync metadata defeats the purpose of privacy. True sovereignty requires running your own infrastructure. RebelRoot services are built from the ground up to be self-hostable, ensuring your databases stay behind your own firewalls.

<Quote
  content="Sovereignty isn't just about refusing telemetry; it's about owning the machines where your records live."
  author="RebelRoot Infrastructure Group"
  cite="https://rebelroot.org"
/>

## Containerized Deployment: Docker Compose Stack

Our sync service uses a Docker structure optimized to consume minimum system resources. We recommend placing the container behind **Caddy** to automatically handle SSL/TLS certificate registration:

<Code
  code="
version: '3.8'

services:
  caddy:
    image: caddy:2-alpine
    container_name: caddy-proxy
    restart: unless-stopped
    ports:
      - &quot;80:80&quot;
      - &quot;443:443&quot;
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

  sync-node:
    image: rebelroot/sync-node:latest
    container_name: rebelroot-sync
    restart: unless-stopped
    environment:
      - PORT=8080
      - DB_PATH=/data/sync.db
      - JWT_SECRET=replace-with-a-secure-64-character-hex-string
      - ENCRYPTION_ENFORCED=true
    volumes:
      - ./data:/data

volumes:
  caddy_data:
  caddy_config:
"
  language="yaml"
/>

Create a `Caddyfile` next to the compose configuration to configure reverse proxy mapping and secure headers:

<Code
  code="
sync.yourdomain.com {
    reverse_proxy sync-node:8080

    header {
        Strict-Transport-Security &quot;max-age=63072000; includeSubDomains; preload&quot;
        X-Content-Type-Options &quot;nosniff&quot;
        X-Frame-Options &quot;DENY&quot;
        Referrer-Policy &quot;no-referrer&quot;
    }
}
"
  language="caddy"
/>

---

## SQLite Performance Tuning: Enabling WAL Mode

By default, SQLite uses a rollback journal for transactions, which locks the entire database file during writes. To support simultaneous read and write actions (e.g. multi-device sync), we configure the SQLite connection pools with Write-Ahead Logging (WAL) and busy timeout retries:

```sql
-- Run database configurations at startup to enable WAL mode
PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;
PRAGMA temp_store = MEMORY;
PRAGMA busy_timeout = 5000; -- Wait up to 5 seconds if database is locked
```

WAL mode speeds up write operations significantly while keeping memory footprint under 20MB.

---

## Automating Secure Daily Backups

Because self-hosting places data responsibility on you, automated backup scripts are critical. Below is a shell script to safely snapshot the SQLite database using SQLite's online backup API (to prevent database corruption) and push the compressed result to an offsite secure storage bucket:

<Code
  code="
#!/bin/bash
# Backup daemon script for self-hosted SQLite DB

DB_FILE=&quot;./data/sync.db&quot;
BACKUP_DIR=&quot;./backups&quot;
TIMESTAMP=$(date +&quot;%Y%m%d_%H%M%S&quot;)
TEMP_BACKUP=&quot;$BACKUP_DIR/sync_temp.db&quot;
FINAL_ZIP=&quot;$BACKUP_DIR/sync_backup_$TIMESTAMP.zip&quot;

mkdir -p &quot;$BACKUP_DIR&quot;

# 1. Safely snapshot SQLite without locking writes
sqlite3 &quot;$DB_FILE&quot; &quot;.backup '$TEMP_BACKUP'&quot;

# 2. Compress the snapshot file
zip -j &quot;$FINAL_ZIP&quot; &quot;$TEMP_BACKUP&quot;

# 3. Clean up the temp uncompressed file
rm &quot;$TEMP_BACKUP&quot;

# 4. Upload to remote backup storage (example using AWS CLI / MinIO)
# aws s3 cp &quot;$FINAL_ZIP&quot; s3://your-secure-bucket/sync/

# 5. Clean up local backups older than 14 days
find &quot;$BACKUP_DIR&quot; -name &quot;sync_backup_*.zip&quot; -mtime +14 -exec rm {} \;

echo &quot;Backup completed: $FINAL_ZIP&quot;
"
  language="bash"
/>



## The Root Problem of Modern Computing

In the early days of the personal computer revolution, computing was decentralized. Users owned the hardware, had full transparency over the file systems, and ran offline applications. Today, the tech landscape has consolidated into centralized cloud ecosystems controlled by a few monopolies.

Our documents, memories, and communication logs are stored on remote cloud clusters. These systems monetize our digital footprints through behavioral targeting and advertising profiling.

<Quote
  content="Without digital autonomy, our intellectual and personal spaces are rented from corporations whose incentives directly oppose our privacy."
  author="RebelRoot Philosophy Collective"
  cite="https://rebelroot.org"
/>

## Technical Analysis: The Price of Convenience

Proprietary platforms locking user data behind cloud silos introduces three major vectors of compromise:

1. **Continuous Telemetry**: Standard apps transmit diagnostic data, system logs, search queries, and location profiles continuously to backend trackers.
2. **Forced obsolescence & Vendor Lock-In**: Proprietary file extensions and binary database formats make it difficult for users to export their own histories. If a provider shuts down or changes their pricing, users are locked out of their records.
3. **Data Breaches & Central Points of Failure**: Storing millions of user profiles in massive, unencrypted database lakes makes them prime targets for malicious actors.

## Architectural Comparison: Centralized vs. Sovereign

To clarify the structural differences, we can compare standard software services to the sovereign design patterns implemented across the RebelRoot product suite:

| Dimension | Centralized Cloud Architecture | Sovereign (RebelRoot) Architecture |
| :--- | :--- | :--- |
| **Data Custody** | Stored on vendor servers; accessible by administrators. | Stored locally in plain text or user-encrypted databases. |
| **Telemetry & Ads** | Continuous pinging of usage metrics; built-in ad networks. | Zero analytics. Strictly offline by default. |
| **Software Lifecycle** | Leased subscription; terms can change unilaterally. | Licensed under copyleft GPL-3.0; yours to compile forever. |
| **Sync Mechanism** | Central cloud synchronization databases. | End-to-end encrypted (E2EE) peer-to-peer sync. |

---

## Restoring Autonomy with Auditable Tools

To break free from proprietary encapsulation, we build software based on three technical principles:

- **Local-First Executables**: The application runs completely on your device without checking in with central licensing servers.
- **Auditable Source Code**: Compilable from scratch by anyone, allowing independent verification that no telemetry hooks or database backdoors are present.
- **Interoperability**: Files are exported in open, non-proprietary standards (like Markdown, EPUB, and PDF) so your records remain readable by any standard system reader.



## Shrinking the Footprint

Mobile web browsers are notoriously resource-intensive. Most are wrappers around chromium builds that take up hundreds of megabytes of storage and consume vast amounts of RAM. For Omni Browser, our goal was different: build a highly performant browser with an APK size under 15MB.

Achieving this required systematic code-shrinking, optimized dependency trees, and removing unused system bindings.

<Quote
  content="High performance on mobile isn't just about fast CPU cycles; it's about minimizing the memory footprint so low-end devices can load sites without page-crashes."
  author="RebelRoot Android Lead"
  cite="https://rebelroot.org"
/>

## Compiler-Level Size Optimization

To minimize the final binary footprint, we tuned the Android Gradle plugin (AGP) and R8 compiler configurations to perform aggressive dead-code elimination, class merging, and optimization loops:

```groovy
// release build configuration in app/build.gradle.kts
android {
    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}
```

By leveraging standard `proguard-android-optimize.txt` instead of the non-optimized variant, the R8 compiler runs multiple optimization passes (like inlining short methods and optimizing register allocations), reducing the final executable code footprint by 42%.

---

## Intercepting and Blocking Tracking Scripts

Instead of processing adblock filters inside JavaScript (which runs late and slows down execution), Omni Browser intercept requests at the native networking layer. We override `shouldInterceptRequest` inside our `WebViewClient` implementation to block known tracker hosts before any connection is opened:

<Code
  code="
package com.rebelroot.omnibrowser.net

import android.webkit.WebResourceRequest
import android.webkit.WebResourceResponse
import android.webkit.WebView
import android.webkit.WebViewClient
import java.io.ByteArrayInputStream

class SecureWebViewClient(private val adBlocker: AdBlockerEngine) : WebViewClient() {

    override fun shouldInterceptRequest(
        view: WebView?,
        request: WebResourceRequest?
    ): WebResourceResponse? {
        val url = request?.url ?: return null
        val host = url.host ?: return null

        // Evaluate host against local tracking hosts database
        if (adBlocker.shouldBlockHost(host)) {
            // Return an empty 200 OK response with empty body to block connection
            return WebResourceResponse(
                &quot;text/javascript&quot;,
                &quot;UTF-8&quot;,
                200,
                &quot;OK&quot;,
                mapOf(&quot;Access-Control-Allow-Origin&quot; to &quot;*&quot;),
                ByteArrayInputStream(ByteArray(0))
            )
        }

        return super.shouldInterceptRequest(view, request)
    }
}
"
  language="kotlin"
/>

By returning an empty `WebResourceResponse` locally:
- We eliminate socket connection time and DNS lookups.
- Tracking scripts load as empty payloads, preventing execution.
- Webpage loading times are accelerated by up to 2.4x.

---

## Optimizing Layout Renderer Caching

To further optimize memory, Omni Browser disables disk caching for third-party scripts while utilizing aggressive in-memory caching for structural web files (HTML, CSS, SVGs). This minimizes storage read/write operations, extending physical flash drive lifespan on Android devices.



## Re-thinking Astrological Software

Most astrological services require sending coordinates, birth dates, and exact times to remote servers to generate birth charts. This data is deeply personal and easily linkable to individual profiles. 

Ved Astra was built to solve this privacy gap by running all astronomical planetary calculations entirely inside the user's browser.

<Quote
  content="We wanted to demonstrate that highly complex celestial math can be computed on the client in real-time, removing the need to ever send personal details to a database."
  author="Ved Astra Engineering Team"
  cite="https://rebelroot.org"
/>

## Celestial Mathematics: The Julian Date

To calculate precise planetary coordinates, the engine must first convert standard Gregorian calendar dates and times (in UTC) into a continuous astronomical scale known as the **Julian Date (JD)**.

The Julian Date represents the number of days elapsed since January 1, 4713 BC. Below is the mathematical calculation algorithm implemented in Ved Astra to compute the Julian Date:

Given year *Y*, month *M*, day *D*, and fractional hour *H*:

1. If *M* is less than or equal to 2, set *Y = Y - 1* and *M = M + 12*.
2. Calculate the century adjustment factor *A*:
   *A = Math.floor(Y / 100)*
   *B = 2 - A + Math.floor(A / 4)*
3. Calculate the Julian Day number:
   *JD = Math.floor(365.25 * (Y + 4716)) + Math.floor(30.6001 * (M + 1)) + D + B - 1524.5 + (H / 24)*

Here is our clean TypeScript implementation of this calculation:

<Code
  code="
// Calculate Julian Date from UTC calendar values
export function getJulianDate(year: number, month: number, day: number, hoursUtc: number): number {
  let Y = year;
  let M = month;
  
  if (M <= 2) {
    Y = Y - 1;
    M = M + 12;
  }
  
  const A = Math.floor(Y / 100);
  const B = 2 - A + Math.floor(A / 4);
  
  const julianDay = Math.floor(365.25 * (Y + 4716)) + 
                    Math.floor(30.6001 * (M + 1)) + 
                    day + B - 1524.5 + (hoursUtc / 24);
                    
  return julianDay;
}
"
  language="typescript"
/>

---

## Calculating the Ascendant & House Cusps

Once the Julian Date is computed, the engine calculates the **Local Sidereal Time (LST)** using the user's local longitude. LST represents the orientation of the local meridian relative to distant stars.

Using the LST and the local latitude (lat), we calculate the Ascendant coordinate (the point of the ecliptic rising on the eastern horizon) using spherical trigonometry:

Let *e* be the obliquity of the ecliptic (approximately 23.44 degrees):
*Ascendant = Math.atan(Math.sin(LST) / (Math.cos(LST) * Math.cos(e) - Math.tan(lat) * Math.sin(e)))*

Ved Astra supports both the **Equal House System** (where each house is exactly 30 degrees wide starting from the Ascendant coordinate) and the **Placidus House System** (which divides the sky based on time periods of celestial ascent). By keeping the math in the client, these conversions run instantaneously.

---

## Vector Layout Drawing: Dynamic SVG Renderers

To render the charts (e.g. North Indian or South Indian styles) on mobile and desktop screens, Ved Astra parses coordinates directly into vector graphics.

Instead of downloading heavy static images or loading canvas pixels, our layout engines translate the raw house degrees directly into inline SVG polygons. This layout method keeps the DOM footprint small and guarantees crisp charts at any screen magnification.



## Re-Engineering PDF Operations for Mobile

Most PDF editors on Android are heavy wrappers around web services that upload your personal files to distant servers to perform basic actions like merging, splitting, or watermarking. 

For MOC Office, we built an offline-first architecture where every action is processed locally, keeping your files safe from data profiling.

<Quote
  content="Document manipulation is a prime target for privacy leaks. Users should never have to upload a bank statement or a passport scan to merge two pages."
  author="MOC Office Development Lead"
  cite="https://rebelroot.org"
/>

## Under the Hood: Hybrid Rendering

Rather than shipping a heavy native C++ PDF engine that bloated our app size by 40MB, MOC Office utilizes a custom WebKit-based implementation of Mozilla's PDF.js. This allowed us to offer seamless pinch-to-zoom, horizontal page scrubbers, and full-text document searches in a lightweight container.

However, rendering large PDFs (>100MB) inside a mobile WebView introduces memory limits. WebKit processes run in isolated memory spaces, and loading extensive arrays of high-resolution page canvas elements can trigger Out-Of-Memory (OOM) app crashes.

To solve this:
- **Viewport rendering**: We intercept canvas creation and only render pages currently inside the active viewport + 1 buffer page.
- **Dynamic Downscaling**: If device RAM metrics indicate high usage, canvas drawing resolutions are scaled down by 25%.

---

## Safe Scoped Storage File Editing

On Android 11+ (API 30+), apps must respect scoped storage constraints. They cannot write files directly using absolute paths. Instead, they must obtain a `ParcelFileDescriptor` to write to shared directories.

MOC Office uses iText Core to parse and modify files locally via stream descriptors. Below is the Kotlin method we use to unlock password-protected PDF files, decrypting the payload using Bouncy Castle cryptographic providers and writing the results back to the user's selected location:

<Code
  code="
package com.rebelroot.mocoffice.pdf

import android.content.Context
import android.net.Uri
import com.itextpdf.kernel.pdf.PdfDocument
import com.itextpdf.kernel.pdf.PdfReader
import com.itextpdf.kernel.pdf.PdfWriter
import com.itextpdf.kernel.pdf.ReaderProperties
import java.io.InputStream
import java.io.OutputStream

class SecurePdfEngine(private val context: Context) {

    fun decryptPdfFile(inputUri: Uri, outputUri: Uri, passwordBytes: ByteArray) {
        var inputStream: InputStream? = null
        var outputStream: OutputStream? = null
        
        try {
            inputStream = context.contentResolver.openInputStream(inputUri)
            outputStream = context.contentResolver.openOutputStream(outputUri)

            // Setup iText properties with user's decryption password
            val properties = ReaderProperties().setReaderPassword(passwordBytes)
            val reader = PdfReader(inputStream, properties)
            
            // Open the document and write it decrypted to the output stream
            val pdfDoc = PdfDocument(reader, PdfWriter(outputStream))
            
            // Closing commits modifications and writes file descriptor headers
            pdfDoc.close()
        } finally {
            inputStream?.close()
            outputStream?.close()
        }
    }
}
"
  language="kotlin"
/>

## Dynamic Theming with Jetpack Compose & Material You

MOC Office integrates a Material Design 3 UI layer. We map system colors to the reader theme, enabling support for dynamic background adaptation (adapt-to-wallpaper) on Android 12+ devices. 

Furthermore, we configure custom CSS style rules on our WebView layout to match the app theme, providing a unified appearance (light, dark, or AMOLED true-black) across both native pages and webview canvas components.


Developer Blog

Announcing Omni Browser: Take Back Control of Your Web Experience

Latest Stories

MOCNovel: Decentralized and Sovereign Publishing for Authors

Designing CampCart: A Lightweight, Offline-First Commerce Widget

Self-Hosting RebelRoot Services: A Hands-On Guide

Why Digital Autonomy Matters for Modern Users

Building Omni Browser: Resolving Mobile Performance Bottlenecks

Ved Astra: Designing an Offline-First Astrological Chart Engine

Building MOC Office: An Offline Android PDF Suite