들어가길 거부하는 방들

"제일 중요한 기능은 앱이 할 수 있는 걸 보고, 사양하는 그거야."

거부가 기능이다

Firekeeper 는 접근성을 쥐고 있어. 즉 네 비밀번호 관리자의 포커스된 요소를 읽을 수 있어. OS 의 어떤 것도 안 막아. '할 수 있음' 과 '함' 사이에 서 있는 유일한 건 앱이 안 하기로 고르는 거고 — 그 선택은 의도로 남는 게 아니라 강한 거부로 코드에 쓰여야 해. 보안 텍스트 필드가 제일 명확한 케이스야: 포커스된 요소가 보안 필드면, Firekeeper 는 맥락을 안 읽고, 클립보드를 안 건드리고, 삽입을 아예 거부해.

거부의 두 계층

계층 1 — 보안 필드 감지 (OS 가 알려줌):
    맥락 안 읽음, 클립보드 안 건드림, 삽입 안 함. 완전 정지.

계층 2 — 앱 거부목록 (네가 정함):
    비밀번호 관리자, 뱅킹 앱, 유저가 사적이라 표시한 뭐든.
    받아쓰기가 거기선 그냥 작동 안 함.

계층 1 은 기계적이야: macOS 가 보안 필드를 표시하고, 넌 그 표시를 존중해. 계층 2 는 판단이야: 어떤 앱은 한 필드만이 아니라 전체가 민감하고, 유저가 '여긴 절대' 라고 말할 수 있어야 해. 둘 다 거부고, 둘 다 삽입 직전에 예의 바르게 확인되는 대신 제일 이른 지점에 — 맥락이 읽히기 전, 타깃 캡처 단계에 — 강제돼야 해. 문 앞의 경비가 금고 앞의 경비를 이겨.

왜 격하가 아니라 거부인가

솔깃한 중간 지대는 '보안 필드에선 받아쓰되 맥락 읽기만 건너뛰기' 야. 저항해. 민감한 맥락에서 부분 작동은 앱이 여전히 거기서 활성이고, 여전히 타깃을 쥐고, 여전히 건드리면 안 되는 걸 건드리는 데서 버그 하나 거리란 뜻이야. 완전 거부가 추론하기 더 단순하고, 검증하기 더 단순하고, 유저한테 설명하기 더 단순해: 비밀번호 필드에선 작동 안 함, 아예, 설계상. 방에서 절대 행사 안 하는 능력은 그 방에서 오용될 수 없어.

거부를 마지막이 아니라 제일 이른 경계에서 강제해. 규칙이 '보안 필드를 절대 안 읽음' 이면, 확인은 타깃 캡처에 속해 — 맥락이 모이기 전 — 읽기 자체의 조건이 아니라. 늦게 확인되는 거부는 민감한 게 이미 건드려진 창을 남겨. 문에서 거부하면 위험한 코드가 아예 안 돌아.

거부 없는 능력은 아직 안 쓴 신뢰일 뿐이야. 접근성 가진 모든 앱이 키로거일 수 있어; 도구와 스파이웨어를 가르는 건 전적으로 적어두고 강제하는 거부야. 네 앱이 침해적 권한을 쥐고 그걸로 안 하겠다고 사양하는 명시적 목록이 없으면, 유저는 네 아키텍처가 아니라 네 의도를 믿는 거고 — 의도는 리팩터를 못 견뎌.

Code

민감한 게 건드려지기 전, 캡처 시점에 거부·swift

func snapshot() -> TargetSnapshot? {
    guard let front = NSWorkspace.shared.frontmostApplication else { return nil }

    // 계층 2 — 유저/앱 거부목록: 여기선 아예 작동 안 함.
    if denylist.contains(front.bundleIdentifier ?? "") { return nil }

    let element = focusedElement()

    // 계층 1 — 보안 필드: 맥락을 읽기 전에 거부.
    if isSecureTextField(element) {
        return TargetSnapshot(secure: true)   // 거부를 하류로 전달
    }

    // 이제야 — 비-보안, 비-거부목록 타깃에서 — 맥락을 읽음.
    return TargetSnapshot(app: front, element: element,
                          selection: selectedText(element), secure: false)
}
// 삽입, 클립보드 처리, 맥락 수집 전부 `secure` 를 존중함.

Exercise

침해적 권한으로 지을 앱에 대해, 거부 목록을 써: 할 수 있는데도 절대 안 할 구체적인 것들. 그다음 각 거부가 어디서 강제되는지 정하고 — 민감한 데이터가 이미 읽힌 후에 강제되는 게 있는지 확인해.

Hint

좋은 거부 목록은 구체적이고 확인 가능해('보안 필드 절대 안 읽음', '거부목록 앱에서 절대 작동 안 함'), 모호하지 않아('프라이버시를 존중함'). 강제 지점이 그걸 진짜로 만들어: 데이터가 메모리에 들어온 후 확인되는 거부는 이미 실패한 거야, 그다음 버려도. 모든 거부를 위험한 경로를 통째로 건너뛸 수 있는 제일 이른 경계로 밀어.

들어가길 거부하는 방들

거부가 기능이다

거부의 두 계층

왜 격하가 아니라 거부인가

Code

External links

Exercise

Progress

댓글 0