"세션이 할 수 있는 걸 끄는 것과, 그게 누구인지 얼마나 확신하는지를 낮추는 건 같은 게 아냐."
런처 credential 은 힘이 줄었지, 덜 신뢰되는 게 아니다
family PIN 이 승인된 뒤, Native Launcher 는 device-scoped, read-only catalog credential 을 받아. launch catalog 를 읽을 수 있고 정확히 하나를 쓸 수 있어. 자기 device-local recents 와 favorite flag. 어떤 mutation endpoint 도 못 부르고, 그 write 는 repository·service·다른 principal 의 preference 를 절대 안 건드려. 이게 깔끔하게 된 capability 감소야 — 런처는 완전히 인증됐고(PIN 을 거쳤어), 그냥 작고 무해한 surface 로 scope 졌을 뿐. 강한 정체성, 작은 힘.
read-only lock 은 auth 와 직교한다
같은 아이디어가 travel 에 안전한 둘러보기 모드를 줘. revocable Web read-only lock 이 세션의 모든 mutation 을 꺼 — 호텔에서 그냥 둘러보고 싶을 때, 또는 누군가한테 sightseeing view 를 쥐여줄 때 유용 — 인증을 전혀 약화 안 하고. lock 은 세션이 할 수 있는 걸 낮추지; 세션이 누구인지 시스템이 얼마나 확신하는지는 안 낮춰. 이건 독립된 두 다이얼이고, 뭉치는 게 흔한 실수야. 'read-only' 가 절대 '덜 인증됨'으로 구현되면 안 돼. 완전히 검증되면서 동시에 일부러 무력할 수 있어.
비밀과 static 파일은 자기 lane 에 남는다
위생 규칙 둘이 contract 를 마무리해. 첫째, 비밀 — credential, 비밀 담은 명령 출력, session token — 은 API 응답·audit detail·로그·런처 캐시에 절대 안 들어가. 절대 이동 안 하는 비밀은 전송 중에도 기기에 rest 로도 못 새. 둘째, static 파일은 선언된 build root 에서만 serve 되고, single-page-app fallback 은 임의의 파일시스템 후보가 아니라 애플리케이션 shell 을 반환해 — 그래서 조작된 path 가 build 디렉터리를 걸어 나가 보면 안 될 걸 못 읽어. 둘 다 같은 본능이야. 위험한 것을 정확히 속한 곳에 가둬.