# Privacy & Security Assessment — mithal.space
**Prepared for:** Ghaymah Systems remote technical exam
**Target:** https://mithal.space/ ("مثال" — Arabic-first search engine)
**Date:** 28 July 2026

---

## ⚠️ A note on methodology (read this first)

This assessment was produced using an automated content-fetch tool, not a live browser session. That means two things worked and one didn't:

- ✅ I could retrieve and read the **rendered page content** of the homepage, `/privacy`, and `/about` pages.
- ✅ I could confirm the site **loads correctly over HTTPS** (the fetch only succeeds over a valid TLS connection).
- ❌ I could **not** read raw **HTTP response headers** or **cookie jar contents**, because my sandboxed environment blocks direct network requests to arbitrary hosts (confirmed: a direct `curl -I` to mithal.space was rejected by my own egress proxy with `host_not_allowed`, not by mithal.space itself).

**For an exam that will likely be graded on genuine DevTools evidence**, you should personally open Chrome/Firefox DevTools and confirm the items marked 🔲 below, then paste in screenshots. I've done the analysis and structure for you and filled in everything I could verify independently (⬜→✅) — you just need to capture the header/cookie screenshots to make it fully authoritative.

**How to get the exact values (5 minutes):**
1. Open `https://mithal.space/` in Chrome → `F12` → **Network** tab → reload → click the top `mithal.space` request → **Headers** tab → screenshot *Response Headers*.
2. **Application** tab → **Cookies** → `https://mithal.space` → screenshot the table (likely empty, per their own claim).
3. **Security** tab → confirm the padlock/certificate details.
4. **Network** tab → filter by `Img/JS/XHR`, reload, and scan the request list for any calls to `google-analytics.com`, `googletagmanager.com`, `facebook.net`, `doubleclick.net`, `hotjar.com`, etc.

---

## 1. DevTools Inspection Findings

### 🔒 HTTPS
- The site is served exclusively over HTTPS; the fetch could not have succeeded otherwise. ✅
- 🔲 **To confirm manually:** certificate issuer, validity dates, and whether `http://` auto-redirects to `https://` (check via the Security tab / a manual `http://mithal.space` visit).
- 🔲 **To confirm manually:** whether `Strict-Transport-Security` (HSTS) is present in the response headers — this is what actually *enforces* HTTPS for returning visitors rather than just offering it.

### 🍪 Cookies
- The site's own privacy policy explicitly states it does **not** use cookies for tracking and does not use `localStorage` for monitoring.
- No cookie-consent banner or cookie-setting script was visible in the extracted page content, which is consistent with that claim.
- 🔲 **To confirm manually:** open Application → Cookies. If the table is empty (or contains only a non-identifying, session-only cookie with no expiry), that corroborates the "no tracking cookies" claim. Note down any cookie name, `Secure`/`HttpOnly`/`SameSite` flags if any do exist.

### 🎯 Trackers / Third-Party Scripts
- No references to common third-party trackers (Google Analytics, Meta Pixel, Hotjar, etc.) appeared in the extracted homepage/about/privacy content, matching the site's claim of "no third-party trackers."
- **Finding worth flagging in your report:** the footer links to the site's affiliated projects — `ghaymah.systems` and `muejam.com` — carry static **UTM attribution parameters** (`utm_campaign=organic&utm_medium=search&utm_source=mithal.space`). This isn't user-tracking (the tag is identical for every visitor), but it *is* a form of referral/marketing attribution, and it's worth noting as a minor inconsistency with an otherwise absolutist "zero tracking" positioning.
- 🔲 **To confirm manually:** the Network tab request list is the authoritative source — check for *any* outbound request to a third-party analytics/ad domain on page load and on search.

### 📋 HTTP Response Headers
- Not independently retrievable from my environment (see methodology note).
- 🔲 **To confirm manually — check specifically for:**
  - `Strict-Transport-Security`
  - `Content-Security-Policy`
  - `X-Content-Type-Options: nosniff`
  - `X-Frame-Options` / `frame-ancestors` (in CSP)
  - `Referrer-Policy`
  - `Permissions-Policy`
  - `Server` / `X-Powered-By` (whether they leak stack/version info)

---

## 2. Privacy Assessment Report (One Page)

**Subject:** Mithal (مثال) — Arabic-first, privacy-positioned search engine
**Operator:** Ghaymah Systems, in partnership with Muejam

**Summary judgment:** Mithal's *stated* privacy posture is strong and unusually explicit for a search engine, and nothing observable in its public-facing content contradicts those claims. The main gaps are (a) claims that are currently unverifiable without live infrastructure access, and (b) one minor practice — attribution parameters on outbound links — that sits in tension with a "zero tracking, full stop" message.

**Stated commitments (from `/privacy` and `/about`):**
- No search query logging; no IP address retention; no device fingerprinting; no cross-site tracking cookies; no third-party trackers (explicitly names Google Analytics and Meta Pixel as things it refuses to embed).
- No personal information collected (no name/email/phone required).
- Frames itself explicitly against "surveillance capitalism" and names data-selling, behavioral profiling, and government data requests as practices it rejects.
- Claims to be open-source and auditable ("GitPasha" repository referenced), which — if true and the repo is public and current — is the single strongest form of verifiability a privacy claim can have, since it lets outsiders check the "no logging" promise against actual code rather than a policy document.

**Strengths:**
1. **Verifiability-by-design intent.** Explicitly says privacy "should not require trust — it should be verifiable," and points to open-source code. This is a meaningfully stronger stance than a typical privacy policy, *if* the repository is genuinely public, current, and matches production.
2. **No account/PII requirement.** Nothing to search requires sign-up, so there's no persistent identity to link queries to.
3. **Narrow, explicit "what we don't collect" list** rather than vague language — easier to hold accountable than boilerplate.

**Weaknesses / open questions:**
1. **Policy vs. infrastructure gap.** A privacy policy is a promise, not a technical control. Claims like "no IP logging" and "no persistent logs" are not independently verifiable from the outside without server-side transparency (e.g., a real, current, deployed open-source repo; a published audit; a warrant canary).
2. **Outbound UTM tagging** on footer links to Ghaymah/Muejam is a small but real inconsistency with "zero tracking" absolutism — it's referral attribution, not user tracking, but a maximally strict privacy stance would avoid even that.
3. **No visible transparency report or update log.** The policy states it is "permanent," but doesn't reference version history, a canary, or third-party audit results — all standard trust-building mechanisms among privacy-focused competitors (e.g., DuckDuckGo publishes independent audits and a detailed transparency page).
4. **Header/cookie posture unverified in this assessment** — see Section 1. A search engine can honestly not track *users* while still having weak transport-security headers, which is a separate (but related) risk surface.

**Overall:** Mithal's privacy *messaging* is best-in-class in tone and specificity; its privacy *proof* is currently policy-based rather than technically demonstrated to an outside auditor. Closing that gap (open, current source code; published security headers; a real audit) would move it from "trust us" to "verify us," which is the standard it sets for itself.

---

## 3. Comparison: Mithal vs. Google Search vs. DuckDuckGo

| Privacy Dimension | **Mithal** | **Google Search** | **DuckDuckGo** |
|---|---|---|---|
| Search query logging | Claims none, tied to no query | Logs and retains queries, linked to Google account/ad profile if signed in | Claims no logging of personal search history |
| IP address handling | Claims no permanent storage | Retained and associated with account/ad ID | Does not use IP to build user profiles (per policy) |
| Cross-site tracking cookies | Claims none used | Extensive first- and third-party tracking (DoubleClick, ad cookies) | Blocks third-party trackers by default via its browser/extension; search itself sets minimal cookies (e.g., saved settings, non-identifying) |
| Personalized/behavioral ad targeting | None (no ad profile business model implied) | Core business model — profile-based ad targeting | Contextual (keyword-based) ads only, not behavioral profiles |
| Business model transparency | Framed as community/cultural mission (Arabic-first), funding model less explicit | Advertising revenue, extremely well documented (10-K filings, ad platform docs) | Ad-supported via contextual (non-tracking) ads; monetization model publicly explained |
| Independent verification | Claims open-source code; no published third-party audit found | Subject to regulatory audits (GDPR enforcement actions, antitrust rulings) but not "open" by design | Publishes detailed privacy practices and has been the subject of independent tracker-blocking research; source apps partially open |
| Regional/political framing | Explicit stance against "foreign surveillance" and government data requests to Arab users | Complies with valid legal/government data requests globally | Publishes clear policy on government data requests (does not have data to hand over for search history) |

**Takeaway:** Mithal and DuckDuckGo occupy a similar "no-tracking-by-design" positioning and both contrast themselves against Google's ad-driven, profile-based model. DuckDuckGo currently has the edge in *demonstrated* trust (longer track record, third-party research coverage, detailed public documentation), while Mithal's differentiator is its Arabic-first mission and its stated (but not yet independently confirmed) open-source verifiability.

---

## 4. Three Recommended Security Improvements for Mithal

1. **Harden and publish HTTP security headers.**
   Explicitly set `Strict-Transport-Security` (with a long max-age and `preload`), a restrictive `Content-Security-Policy` (blocking inline scripts/unapproved origins — which also technically enforces the "no third-party trackers" promise instead of just asserting it), `X-Content-Type-Options: nosniff`, `Referrer-Policy: no-referrer` (or `strict-origin-when-cross-origin`), and `Permissions-Policy` to disable unused browser features (camera, geolocation, microphone). This turns privacy *claims* into privacy *controls* a browser will enforce.

2. **Remove or neutralize outbound tracking parameters.**
   Strip the static UTM parameters from footer links to `ghaymah.systems` and `muejam.com`, or route them through a referrer-stripping internal redirect. This closes the one observable gap between "we do zero tracking" messaging and actual link behavior, and also prevents leaking "came from mithal.space search" context to third-party analytics on the destination sites via the query string/referrer.

3. **Publish independent, verifiable proof of the no-logging claim.**
   Since Mithal already claims to be open-source, make the repository genuinely public, current, and clearly mapped to the production deployment; commission an independent third-party security/privacy audit (similar to what DuckDuckGo and Brave Search publish); and consider a signed transparency report or warrant canary. This converts the strongest part of Mithal's pitch — "privacy should be verifiable, not trusted" — from a stated principle into something an examiner (or any user) can actually check, rather than relying solely on the policy page's word.