Add WebKit site permission handling

[Andresshamis]

Meridian Explorer automation, posting through @Andresshamis.

Priority: P1
Type: privacy / security / feature
Ready status: ready

Problem statement

Meridian does not yet have an explicit per-site permission model or WebKit delegate flow for privacy-sensitive browser permissions such as camera, microphone, geolocation, notifications, autoplay, and popup/new-window behavior.

Why it matters for Meridian

Permission prompts are a browser trust boundary. Meridian should not rely on implicit WebKit defaults or ad hoc view code for privacy-sensitive access. The product scope calls for per-site permissions where WebKit supports them, and the threat model already treats permission prompts as part of user trust.

Evidence

• Sources/MeridianCore/WebKit/WebViewHost.swift sets webView.uiDelegate = context.coordinator, but the coordinator only implements createWebViewWith for target-frame-nil windows. It has no explicit media capture, permission, notification, autoplay, or durable popup decision handling.
• Sources/MeridianCore/Stores/BrowserStore.swift has no site permission state or approval/deny action model.
• Docs/ThreatModel.md lists user trust in permission prompts as an asset and explicitly calls out site permission state for camera, microphone, geolocation, notifications, popups, downloads, and autoplay as required follow-up.
• Docs/WebKitLimitations.md says fine-grained permission APIs vary by macOS/WebKit version and need explicit implementation/testing.
• Searches for existing open/closed issues around site permissions, popups, TLS/authentication, and WebKit permission handling found no dedicated issue.

Affected files/components

• Sources/MeridianCore/WebKit/WebViewHost.swift
• Sources/MeridianCore/Stores/BrowserStore.swift
• Future site permission/security models, likely under Sources/MeridianCore/Security/ or Sources/MeridianCore/Models/
• Browser UI for native permission prompts and per-site state
• Docs/ThreatModel.md
• Docs/WebKitLimitations.md
• Future unit and UI tests

Expected behavior

When web content requests a privacy-sensitive permission or popup/new-window behavior that WebKit exposes, Meridian should make an explicit origin-aware decision: allow, deny, ask, or use the safest documented fallback. Decisions should be represented in browser state, persist only non-sensitive site settings where appropriate, and never grant access silently because a delegate method was omitted.

Proposed direction

Add a small site permission model/service that records origin, permission kind, decision, and timestamp without storing secrets or browsing contents. Wire supported WKUIDelegate/WebKit permission APIs into this model. Treat unsupported or unavailable WebKit APIs conservatively and document the limitation. Keep download-specific permission/risk handling in issue #5.

Acceptance criteria

• A site permission model exists for camera, microphone, geolocation, notifications, autoplay, and popup/new-window behavior, with room to mark unsupported APIs explicitly.
• WebKit permission delegate callbacks supported by the current macOS/WebKit target route through a dedicated service or store action instead of inline view-only decisions.
• The default for unknown or unsupported permission requests is deny or ask, not silent allow.
• Popup/new-window requests are routed through an explicit policy path and preserve source origin context.
• Non-sensitive permission settings can be persisted later without storing cookies, credentials, tokens, private browsing data, or page contents.
• Threat model and WebKit limitations docs distinguish implemented permission handling from unsupported WebKit limitations.
• Unit tests cover policy defaults and at least one allow/deny path; UI or integration tests are planned or added once issue Add Xcode app project and UI test host #4 provides the app test host.

Dependencies/blockers

• No hard blocker for the model/service and unit tests.
• Full UI automation depends on issue Add Xcode app project and UI test host #4.
• Download-specific permission/risk behavior remains tracked by issue Implement WebKit download and external URL confirmation flows #5.

Suggested tests

• Unit tests for permission default decisions by origin and permission kind.
• Unit tests proving private browsing permission decisions are not persisted when persistence is added.
• WebKit fixture or UI tests for media/popup prompts once an app test host exists.
• Documentation test/review pass confirming unsupported WebKit permission APIs are listed rather than implied as supported.

[Andresshamis]

Meridian PR Agent automation, posting through @Andresshamis.

Claiming this issue for implementation.
Branch: security/site-permission-policy
Scope: first narrow site-permission slice: add explicit permission kinds/origin/decision policy models and store-facing request/decision flow, plus popup/new-window policy defaults where feasible without a UI test host.
Expected files/components: Sources/MeridianCore/Security/ site permission policy/model files, Sources/MeridianCore/Stores/BrowserStore.swift if needed, focused tests, Docs/ThreatModel.md, Docs/WebKitLimitations.md, and Docs/TestPlan.md if behavior wording changes.
Planned checks: swift test --filter SitePermission, swift test, swift build, bash -n script/build_and_run.sh, git diff --check, and ./script/build_and_run.sh --verify if feasible.
Notes: No existing issue #7 claim, permission branch, or permission PR found at claim time. This branch is stacked on PR #2 (feature/browser-shell-scaffold).

[Andresshamis]

Meridian PR Agent automation, posting through @Andresshamis.

Opened draft PR #10 for the first site-permission handling slice: #10

Scope covered:

• Added SitePermissionPolicy, sanitized origin/request/setting models, and profile-scoped allow/deny state.
• Routed WebKit camera/microphone media-capture permission callbacks through the store policy path.
• Routed pop-up/new-window requests through explicit site permission state instead of silent loading.
• Configured autoplay to require a user gesture by default.
• Documented current macOS WebKit limitations for geolocation and notifications.

Verification passed locally: swift test --filter SitePermission (7 tests), swift test (28 tests), swift build, bash -n script/build_and_run.sh, git diff --check, git diff --cached --check, and ./script/build_and_run.sh --verify. The verification-launched MeridianBrowser process was stopped.

Known limitation: end-to-end WebKit/UI fixture tests remain blocked on issue #4; PR #10 is stacked on PR #2 and remains draft.

[Andresshamis]

Meridian PR Agent automation, posting through @Andresshamis.

PR #10 is now realigned with current main after the Reviewer-blocking conflict. The branch is MERGEABLE / CLEAN, marked ready for review, and verified locally with swift test --filter SitePermission (7 tests), swift test (47 tests), swift build, bash -n script/build_and_run.sh, git diff --check, git diff --cached --check, and ./script/build_and_run.sh --verify.

Remaining limitation is unchanged: end-to-end WebKit/UI fixture coverage still depends on the issue #4 app/UI test host.

[Andresshamis]

Meridian Reviewer automation, posting through @Andresshamis.

PR #10 is merged into main as 28402e9.

What is now covered:

• Site permission policy/request/setting model with sanitized origins.
• Camera/microphone media-capture requests routed through the store policy path.
• Pop-up/new-window requests routed through explicit site permission state instead of silent loading.
• Autoplay configured to require a user gesture by default.
• Geolocation and notifications documented and denied conservatively as unsupported in the current macOS WebKit SDK.
• Unit coverage for policy defaults, sanitized origins, allow/deny settings, unsupported permissions, and private-profile session-only setting metadata.

Remaining issue #7 work:

• Durable persistence for non-sensitive site settings, while excluding private-profile session-only settings.
• UI/WebKit fixture tests for camera, microphone, and pop-up prompts once issue Add Xcode app project and UI test host #4 / PR Add Xcode app project and UI test host #12 provides a usable app/UI test host.
• Revisit geolocation and notification support only if a future public macOS WebKit API makes it safe.

Decision:

• Keep issue Add WebKit site permission handling #7 open. PR Add site permission policy boundary #10 satisfies the first implementation slice but not the full acceptance criteria.

[Andresshamis]

Meridian Explorer automation, posting through @Andresshamis.

Status update after PR #10 merged at 2026-05-08T23:05:18Z.

Completed for issue #7's first slice:

• SitePermissionPolicy and sanitized permission origin/request/setting models.
• Profile-scoped allow/deny state in the browser store path.
• WebKit camera/microphone media-capture delegate routing through explicit policy decisions.
• Popup/new-window handling through policy instead of silent loading.
• Autoplay remains gated by user gesture.
• Focused permission-policy tests plus full package test coverage reported by PR Agent and Reviewer.

Keep #7 open. Remaining work should avoid rebuilding the policy boundary and instead focus on WebKit/UI fixture coverage and any permission UI/storage refinements once issue #4's app/UI test host is available.

[Andresshamis]

Meridian PR Agent automation, posting through @Andresshamis.

Claiming the next focused issue #7 slice for implementation.
Branch: security/site-permission-persistence
Scope: persist non-sensitive site permission decisions through the existing session snapshot/persistence boundary, while excluding private-profile/session-only permission settings and preserving conservative unsupported-permission behavior.
Expected files/components: Sources/MeridianCore/Models/BrowserSessionSnapshot.swift, Sources/MeridianCore/Services/SessionPersistenceBoundary.swift, Sources/MeridianCore/Stores/BrowserStore.swift, focused tests in Tests/MeridianBrowserTests/, and related docs if behavior wording changes.
Planned checks: swift test --filter SitePermission, swift test --filter SessionPersistence, swift test, swift build, bash -n script/build_and_run.sh, git diff --check, and ./script/build_and_run.sh --verify if feasible.
Notes: No active issue #7 follow-up PR or remote branch was found. PR #12 remains separately blocked on signing-capable UI test launch proof.

[Andresshamis]

Meridian PR Agent automation, posting through @Andresshamis.

Opened PR #27 for the site-permission persistence slice: #27

Scope covered:

• Public-profile site permission allow/deny decisions now round-trip through BrowserSessionSnapshot and the SQLite session persistence path.
• Private-profile/session-only permission decisions are filtered by SessionPersistenceBoundary before disk writes and during repair-time scrubbing.
• Legacy session payloads without permission settings decode with an empty settings list.
• Docs now describe public permission persistence and private permission exclusion.

Verification passed locally: swift test --filter SitePermission (9 tests), swift test --filter SessionPersistence (10 tests), swift test (85 tests), swift build, bash -n script/build_and_run.sh, git diff --check, git diff --cached --check, and ./script/build_and_run.sh --verify. The verification-launched MeridianBrowser process was stopped.

Remaining issue #7 scope: site permission UI plus WebKit/UI fixture tests once issue #4 / PR #12 provides a signing-capable app test host.