PrivacyPage.hpp

1. Overview

The PrivacyPage.hpp header defines the PrivacyPage class, a GTKmm (GTK4) UI component responsible for managing device privacy controls and process monitoring within BastionGuard. The page focuses primarily on webcam/device access protection, background monitoring, and user-controlled blocking/unblocking workflows.

Functionally, PrivacyPage provides:

  • User interface for enabling/disabling privacy protection
  • Integration with a background daemon or script for device control
  • Real-time monitoring of processes accessing protected devices
  • Automatic and manual refresh of device/process status
  • Permission alert popups and queued notifications
  • Persistent storage of privacy enablement state
  • Asynchronous logging of privacy-related events

2. Dependencies and Includes

#include <gtkmm.h>
#include <thread>
#include <atomic>
#include <vector>
#include <string>
#include <set>
#include <queue>
#include <filesystem>
  • gtkmm.h – GTK4 widgets, signals, and main loop integration
  • <thread> – background monitoring thread management
  • <atomic> – lock-free synchronization between UI and worker threads
  • <vector> – device and process list containers
  • <set> – tracking of already-known processes
  • <queue> – alert/popup queuing (implementation-level)
  • <filesystem> – device and system path inspection utilities

3. Class Declaration and Scope

class PrivacyPage : public Gtk::Box

The class derives from Gtk::Box, allowing it to be embedded as a page within notebooks, stacks, or container-based navigation layouts.

4. Public Interface

4.1 Constructor / Destructor

PrivacyPage();
~PrivacyPage();

The constructor initializes the privacy control interface, prepares background monitoring resources, and loads persisted state. The destructor is responsible for stopping background threads, disconnecting timers, and releasing system resources.

5. UI Components

PrivacyPage exposes a composite layout composed of control widgets, status indicators, and a scrollable process view.

5.1 Header and Main Controls

Gtk::Label  lbl_title_;
Gtk::Switch switch_webcam_;
Gtk::Button btn_refresh_;
Gtk::CheckButton chk_auto_refresh_;
  • lbl_title_ – section title label
  • switch_webcam_ – master toggle for enabling/disabling privacy protection
  • btn_refresh_ – manual refresh trigger
  • chk_auto_refresh_ – enables/disables automatic refresh

5.2 Process and Device View

Gtk::ScrolledWindow scroller_;
Gtk::TextView txt_processes_;

Scrollable text view used to present currently active processes and devices interacting with protected resources.

5.3 Status Indicator

Gtk::Label lbl_status_;

Displays operational status, warnings, and feedback messages related to privacy enforcement.

6. Internal State and Data Model

std::thread monitor_thread_;
std::atomic<bool> monitor_running_{false};
std::set<std::string> known_processes_;
sigc::connection auto_refresh_conn_;
std::atomic<bool> toggle_busy_{false};
std::atomic<bool> devices_blocked_{false};
  • monitor_thread_ – background worker for device/process monitoring
  • monitor_running_ – atomic flag controlling thread lifecycle
  • known_processes_ – cache of already-detected processes to avoid duplicates
  • auto_refresh_conn_ – timer connection for scheduled refresh
  • toggle_busy_ – guards against concurrent toggle operations
  • devices_blocked_ – indicates whether devices are currently blocked

7. User Actions (Callbacks)

void on_toggle_privacy();
void on_refresh_clicked();
void setup_auto_refresh_toggle();
void manual_unlock_devices();
  • on_toggle_privacy() – handles enable/disable requests from the main switch
  • on_refresh_clicked() – triggers a manual device/process refresh
  • setup_auto_refresh_toggle() – configures automatic refresh behavior
  • manual_unlock_devices() – restores access to blocked devices on user request

8. Internal Logic

8.1 Background Script Execution

void run_privacy_script_async(bool unblock);

Executes a privacy management script in the background. Depending on the unblock flag, the script enables or disables access to protected devices without blocking the UI thread.

8.2 Daemon and Device Control

bool is_daemon_active();
void start_privacy_daemon();
void unblock_devices_local();
  • is_daemon_active() – checks whether the privacy daemon/service is running
  • start_privacy_daemon() – launches the background service if required
  • unblock_devices_local() – restores local device access

8.3 State Persistence

void save_privacy_state(bool enabled);
bool load_privacy_state();

Persists and restores the privacy enablement state across application restarts.

8.4 Detection and Monitoring

std::vector<std::string> detect_active_devices();
void start_monitor_thread();
void monitor_loop();
  • detect_active_devices() – enumerates currently active/accessible devices
  • start_monitor_thread() – initializes and starts background monitoring
  • monitor_loop() – main worker loop that detects access attempts and state changes

8.5 Alerts and Notifications

void show_permission_popup(const std::string& process_name);
void show_next_alert();

Manages user notifications when new processes request access to protected devices. Alerts may be queued and displayed sequentially to avoid overwhelming the user.

8.6 Logging

void write_log(const std::string& msg);

Writes privacy-related events and actions to an asynchronous logging facility for auditing and troubleshooting.

9. Auto-Update (Scheduled Refresh)

sigc::connection auto_refresh_conn_;

Automatic refresh is controlled through a GTK timer connection. When enabled via chk_auto_refresh_, periodic updates invoke update_process_list() to keep the UI synchronized with system state.

10. Settings Storage

Privacy enablement state is persisted using save_privacy_state() and load_privacy_state(). The storage backend and file location are implementation-defined and should ensure durability and atomic updates.

11. Helper Functions and Filesystem Layout

The page relies on <filesystem> utilities and external scripts/daemons to manage device access. Any paths used for scripts, sockets, or configuration files should be validated and restricted to trusted directories.

12. Runtime and Security Considerations

  • Thread safety: atomic flags and controlled thread lifecycle must be used consistently to prevent race conditions between UI and background monitoring.
  • Privilege boundaries: device blocking/unblocking and daemon management may require elevated privileges and must be carefully audited.
  • UI responsiveness: long-running operations are offloaded to background threads to avoid blocking the GTK main loop.
  • Alert flooding: queued popups should be rate-limited to avoid overwhelming users during high activity.
  • Auditability: logging via write_log() should include sufficient contextual information for forensic analysis.
Published on:
Last updated on: