Jak naprawdę działa Privio

Co to właściwie jest

Privio to strażnik prywatności dla Maca. Pilnuje wybranych aplikacji, stron i plików - a otwiera je dopiero, gdy potwierdzisz, że to Ty (odciskiem palca albo hasłem Maca).

Wyobraź sobie portiera w budynku. Nie zna Twojego hasła i nie ma kluczy do Twojego mieszkania - ale stoi przy drzwiach i wpuszcza tylko wtedy, gdy ochrona (system macOS) potwierdzi, że to naprawdę Ty. Privio jest właśnie takim portierem: sam z siebie niczego nie „wie” o Twoich sekretach, tylko prosi zaufane części systemu, żeby Cię rozpoznały.

Ma pięć zadań (modułów), które poznasz dalej: chowanie aplikacji, blokowanie stron WWW, „zasłonę prywatności” na ekran, szyfrowany sejf na pliki i blokadę Maca, gdy odejdziesz. Wszystko dzieje się na Twoim komputerze - nic nie jest wysyłane do internetu.

Z czego jest zbudowane - i dlaczego akurat to

Każdy klocek Privio wybrano z konkretnego powodu. Oto najważniejsze technologie prostym językiem: co to jest, po co i dlaczego to, a nie coś innego.

Co się z czym łączy

Privio prawie nic nie robi „samo”. Zamiast tego rozmawia z zaufanymi częściami systemu macOS - każda odpowiada za co innego. Kliknij element, żeby zobaczyć, o co Privio go prosi.

Co się dzieje krok po kroku

Wybierz sytuację, a rozłożę ją na czynniki pierwsze - łącznie z tym, którą część systemu Privio wtedy angażuje (fioletowe znaczniki).

Jak działają mechanizmy w środku

Kilka pytań, które prędzej czy później się pojawiają - z uczciwymi odpowiedziami, także o granicach tego, co w ogóle da się zrobić na Macu.

Warsztat: jak w ogóle powstaje taka apka

Od tego miejsca schodzimy głębiej - z każdym rozdziałem coraz bardziej „pod maskę”, aż zobaczysz dokładnie, jak Privio jest zrobione w środku. To część dla ciekawskich: nie musisz jej czytać, żeby korzystać z aplikacji.

Czego się używa

Z czego składa się projekt: dwa „produkty” (targety)

Target to jedna rzecz, którą kompilator ma wyprodukować. Privio ma dwa - i to jest fundament całej reszty przewodnika:

tak buduje się i uruchamia projekt (z dokumentacji projektu)

# Wygeneruj projekt Xcode z pliku tekstowego project.yml
xcodegen generate

# Zbuduj aplikację
xcodebuild -project Privio.xcodeproj -scheme Privio build

# Uruchom testy „mózgu” (PrivioCore) - bez klikania
xcodebuild -project Privio.xcodeproj -scheme PrivioCoreTests test

Swift w pigułce: klocki, z których zbudowany jest kod

Żeby czytać kod Privio, wystarczy poznać garść pojęć. Nie musisz umieć ich pisać - wystarczy je rozpoznawać.

Stałe, zmienne i typy

let to wartość, która się nie zmienia (jak napis na tabliczce), var to taka, którą można zmieniać. Każda wartość ma typ - czym jest: tekstem (String), liczbą (Int), prawdą/fałszem (Bool), datą (Date) czy unikalnym identyfikatorem (UUID).

Trzy sposoby na „paczkę danych”

Sources/PrivioCore/Models/ProtectedApp.swift - prawdziwa paczka danych (struct)

public struct ProtectedApp {
    public var bundleIdentifier: String     // stały identyfikator apki
    public var displayName: String          // nazwa pokazywana użytkownikowi
    public var protectionEnabled: Bool      // czy chronimy tę apkę

    // Wartość opcjonalna: „liczba sekund ALBO nic”.
    public var lockAfterInactivity: TimeInterval?
}

Opcjonalne wartości: „coś albo nic” (znak ?)

Znak zapytania po typie oznacza, że wartości może w ogóle nie być (po polsku „nic” to nil). To bardzo ważny pomysł: Swift zmusza programistę, żeby obsłużył przypadek pustki - nie da się przez przypadek użyć „niczego” jak zwykłej liczby. Stąd w kodzie Privio tyle znaków ?: to jawne „uwaga, tu może nic nie być”.

Enum, który niesie dane

Sources/PrivioApp/App/AppModel.swift - lista akcji wymagających autoryzacji

enum SensitiveAction {
    case disableProtection            // wariant bez danych
    case removeApp(name: String)      // wariant, który niesie nazwę apki
    case pauseWebsiteProtection(minutes: Int)
}

Dzięki temu „usuń aplikację X z ochrony” to jedna, sprawdzana rzecz - a nie luźny tekst, w którym łatwo o literówkę.

Domknięcia: funkcja podana jak wartość

Czasem chcemy przekazać „co ma się stać później”. W Swift robi się to domknięciem (closure) - kawałkiem kodu w klamrach, który można gdzieś podać i wywołać, gdy przyjdzie czas. Privio łączy tak moduły:

Sources/PrivioApp/App/PrivioApp.swift - „gdy trzeba zablokować, zrób to”

// proximity dostaje przepis na akcję; wykona go, gdy odejdziesz od Maca
proximity.onLockProtectedApps = { model.lockAllForProximity() }

Jak apka robi kilka rzeczy naraz - i nie plącze się

Prawdziwy problem: w tej samej chwili może przyjść kilka zdarzeń (włączyłeś apkę, minął minutnik, ekran się zablokował). Gdyby wszystkie naraz grzebały w stanie blokad, powstałby chaos. Oto jak Swift temu zapobiega.

async / await: poczekaj, nie zamrażając

Niektóre rzeczy trwają (np. czekanie na odcisk). Słowo async oznacza „ta funkcja może poczekać”, a await - „tu czekamy na wynik”. W trakcie czekania apka nie zamarza - dalej reaguje na Ciebie. To najważniejszy nowoczesny wzorzec w całym kodzie.

Task: uruchom pracę w tle

Task { ... } to „zrób to obok, nie blokując reszty”. Tak Privio nasłuchuje strumienia zmian stanu albo odlicza minutniki bezczynności (lekkie „uśpienie” zamiast ciągłego sprawdzania).

actor: strażnik jednego stanu

To sedno. actor wygląda jak zwykły obiekt, ale ma supermoc: obsługuje tylko jedno zgłoszenie na raz. Nawet jeśli pięć zdarzeń przyjdzie równocześnie, ustawią się w kolejce - więc stan blokad nigdy się nie „rozjedzie”. Cały mózg Privio to jeden taki strażnik:

Sources/PrivioCore/Enforcement/InProcessEnforcementService.swift

// „actor” = obiekt, który pilnuje swojego stanu; obsługuje po kolei
public actor InProcessEnforcementService: EnforcementControlling {
    private var state: EnforcementState            // cały ulotny stan tutaj
    private var subscribers: [UUID: AsyncStream<EnforcementState>.Continuation] = [:]
    // ...monitor, kontroler apek, uwierzytelnianie - wstrzyknięte z zewnątrz
}

AsyncStream: strumień „migawek” do UI

Gdy stan się zmienia, strażnik nie „woła” UI. Zamiast tego nadaje kolejne migawki całego stanu, a UI je łapie w pętli for await i przerysowuje się. To jak transmisja: nadawca nie wie, kto ogląda - po prostu wysyła kolejne klatki.

Architektura: jak jedna granica trzyma to wszystko w ryzach

Teraz połączmy kropki. Cała siła Privio bierze się z jednej zasady: UI i mózg rozmawiają wyłącznie przez wąską, ściśle określoną granicę - „szew” (seam).

1. Kontrakt (protokół)

Najpierw spisujemy, czego UI może chcieć od mózgu - jako listę obietnic, bez wnikania, jak są spełniane:

Sources/PrivioCore/Enforcement/EnforcementControlling.swift

// Umowa: „ktokolwiek to zrobi, udostępni te działania”
public protocol EnforcementControlling: AnyObject, Sendable {
    func stateUpdates() async -> AsyncStream<EnforcementState>   // strumień migawek
    func authenticate(appID: UUID, preferPassword: Bool) async -> Bool
    func lock(appID: UUID, reason: ActivityEvent.Reason) async
}

2. Wykonawca (actor), który dostaje współpracowników z zewnątrz

Konkretna implementacja to nasz strażnik. Co ważne, on sam nie tworzy sobie czujnika odcisku ani monitora apek - dostaje je z zewnątrz (to się nazywa wstrzykiwanie zależności). Dzięki temu w testach można podać atrapy, a w trybie podglądu - nic.

szkic uproszczony na podstawie InProcessEnforcementService.init

InProcessEnforcementService(
    store: ConfigStore(),               // zapis ustawień na dysk
    monitor: WorkspaceAppMonitor(),     // słucha, która apka wyszła na wierzch
    controller: WorkspaceAppController(),// chowa/pokazuje apki
    authenticator: LocalAuthenticator() // Touch ID / hasło
)
// w testach zamiast tych „prawdziwych” podaje się atrapy - i logikę
// da się sprawdzić bez czytnika odcisku i bez klikania

3. Reaktywna pętla

UI ma jeden łącznik z mózgiem - AppModel - oznaczony jako @Observable (czyli „gdy się zmienię, odśwież widoki”). Cała pętla wygląda tak:

Bezpieczeństwo od środka

Tu jest sedno całego produktu. Zasada przewodnia: Privio ma jak najmniej wiedzieć i jak najmniej przechowywać - żeby nie było czego ukraść. Rozwiń, co Cię ciekawi.

let context = LAContext()
context.evaluatePolicy(.deviceOwnerAuthentication,
                       localizedReason: "odblokować aplikację") { ok, _ in
    // dostajemy tylko ok = prawda/fałsz; nigdy odcisku ani hasła
}

// AES-256, hasło podane przez stdin (nie w argumentach procesu)
hdiutil create -encryption AES-256 -stdinpass ... sejf.sparsebundle

Rozmowa z systemem: konkretne „drzwi”, z których korzysta Privio

Najgłębszy poziom: nazwy prawdziwych mechanizmów macOS, których Privio używa - i sprytne sztuczki, dzięki którym nie potrzebuje inwazyjnych uprawnień.

let center = NSWorkspace.shared.notificationCenter
// „powiadom mnie, gdy jakaś apka wyjdzie na wierzch”
observe(NSWorkspace.didActivateApplicationNotification)  { .activated($0) }
observe(NSWorkspace.didLaunchApplicationNotification)    { .launched($0) }
observe(NSWorkspace.didTerminateApplicationNotification) { .terminated($0) }

Anatomia startu: co się składa w całość przy uruchomieniu

Do tej pory patrzyliśmy na klocki osobno. Teraz zobaczmy moment, w którym wszystkie są łączone w jednym miejscu - to tu widać, jak apka jest naprawdę „zmontowana”.

Cała aplikacja ma jeden konstruktor (PrivioApp.init), który wykonuje starannie ułożoną kolejność kroków. Kolejność nie jest przypadkowa - każdy krok zależy od poprzedniego:

Sources/PrivioApp/App/PrivioApp.swift - skrócony montaż (init)

init() {
    PrivioFonts.registerAll()            // fonty gotowe, zanim UI policzy tekst
    AppLanguage.applyStartupOverride()   // język ustawiony przed wczytaniem napisów

    let store = ConfigStore()
    let initialState = EnforcementState.loaded(from: store)   // wszystko .locked
    let isSnapshot = ProcessInfo.processInfo.environment["PRIVIO_SNAPSHOT"] != nil

    // Mózg dostaje współpracowników z zewnątrz (w trybie podglądu: nil)
    let service = InProcessEnforcementService(
        store: store,
        monitor:       isSnapshot ? nil : WorkspaceAppMonitor(),
        controller:    isSnapshot ? nil : WorkspaceAppController(),
        authenticator: isSnapshot ? nil : LocalAuthenticator(),
        scheduler:     isSnapshot ? nil : RealInactivityScheduler(),
        webProxy:      isSnapshot ? nil : WebProxyServer(),
        initialState: initialState)

    let model = AppModel(service: service, initialState: initialState, catalog: catalog)
    // ...dalej: VaultController, ProximityController, spięcie domknięciami, scena
}

Trwałość i integralność: co przetrwa restart, a co znika

Wiemy już, że status blokad jest ulotny. Zejdźmy głębiej: jak dokładnie zapisywane są ustawienia, jak apka radzi sobie ze starszymi plikami i jak wykrywa, że ktoś przy pliku majstrował.

Gdzie i co się zapisuje

Ustawienia trafiają jako zwykły plik JSON do ~/Library/Application Support/Privio/config.json. Zapisywana jest tylko konfiguracja (które apki, jakie timeouty, ustawienia modułów) - nigdy sekrety. Klucze i hasła mieszkają w Pęku kluczy i Secure Enclave, nie w tym pliku.

Po starcie wszystko jest zablokowane

Nie istnieje trwały zapis „to jest odblokowane”. Przy wczytywaniu każda apka wraca jako .locked - to celowe wzmocnienie bezpieczeństwa (restart = ponowne pytanie o Touch ID).

Sources/PrivioCore/Enforcement/EnforcementState.swift - budowa stanu startowego

public static func loaded(from store: ConfigStore) -> EnforcementState {
    let persisted = store.load()
    let apps = persisted.apps.map {
        // brak trwałego „unlocked" - startujemy zablokowani
        ProtectedAppSnapshot(app: $0, status: $0.protectionEnabled ? .locked : .unprotected)
    }
    return EnforcementState(apps: apps, configuration: persisted.configuration)
}

Zgodność wstecz: starszy plik nadal działa

Gdy w nowej wersji dochodzi nowe pole, stare pliki go nie mają. Dlatego dekodowanie jest defensywne: brakujące pole dostaje bezpieczną wartość domyślną zamiast wysypać wczytywanie. To dlatego w kodzie widać wzorzec „weź jeśli jest, w przeciwnym razie użyj domyślnej”.

wzorzec z EnforcementState.init(from:)

// „zdekoduj jeśli obecne, inaczej wartość domyślna" - stare pliki działają dalej
apps = try c.decodeIfPresent([ProtectedAppSnapshot].self, forKey: .apps) ?? []
protectionActive = try c.decodeIfPresent(Bool.self, forKey: .protectionActive) ?? true

Integralność: czy plik nie został podmieniony

Stan niesie flagę configIntegrityValid - Privio potrafi sprawdzić (skrótem kryptograficznym, HMAC), czy zapisany plik konfiguracji nie został zmieniony poza aplikacją. Jeśli coś się nie zgadza, apka może zareagować, zamiast ślepo ufać zmienionym danym.

Egzekwowanie od środka: co naprawdę robi „strażnik”

Najgłębsze spojrzenie na mózg. Aktor to nie tylko „stan” - to zestaw drobnych mechanizmów, które razem sprawiają, że blokowanie jest szybkie, spójne i nie wpada w pętle.

Sources/PrivioCore/Enforcement/InProcessEnforcementService.swift - pola aktora

public actor InProcessEnforcementService: EnforcementControlling {
    private var state: EnforcementState                   // cały ulotny stan
    private var foregroundBundleID: String?               // co jest teraz na wierzchu
    private var recentlyCancelled: [String: Date] = [:]   // anty-pętla po anulowaniu
    private let cancelCooldown: TimeInterval = 0.8
    private let maxActivityEntries = 200                  // limit historii zdarzeń
    private var monitorTask: Task<Void, Never>?           // nasłuch zdarzeń w tle
    private var systemTask: Task<Void, Never>?            // nasłuch zdarzeń systemu
}

Moduły poza szwem: dlaczego nie wszystko przechodzi przez mózg

Część funkcji świadomie NIE korzysta z „szwu” enforcementu. Powód jest prosty: one sterują bezpośrednio oknami systemu albo samym macOS, więc żyją w warstwie aplikacji, obok mózgu - nie w nim.

Testowalność: skąd wiadomo, że to naprawdę działa

Cała architektura z rozdziałów 8-9 ma jeden praktyczny cel: dać się sprawdzić automatycznie, bez klikania i bez prawdziwego sprzętu. Oto jak.

Dystrybucja i aktualizacje: jak apka trafia do użytkownika

Gotowy kod to jeszcze nie gotowy produkt. Oto jak Privio jest składane, podpisywane i aktualizowane.

Spójny wygląd: jak interfejs trzyma się kupy

Na koniec warstwa, którą widać najbardziej. Żeby apka wyglądała jak jedna całość, a nie zlepek ekranów, jej wygląd jest zbudowany na kilku wspólnych fundamentach - dokładnie tak samo, jak w web-devie robi się to zmiennymi CSS i komponentami.