الملفات
ghaymah-exam-Mohamed-Ashraf…/q3-mithal.space-privacy-assessment/mithal_privacy_security_assessment.md

12 KiB

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 → F12Network tab → reload → click the top mithal.space request → Headers tab → screenshot Response Headers.
  2. Application tab → Cookieshttps://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.


  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.