읽지 못하는 릴레이에도 여전히 보이는 것

브라우저와 Tinfoil 사이에는 저희의 작은 서버, 릴레이가 있습니다. 릴레이의 역할은 누가 요청하는지 확인하고, 저희의 Tinfoil 키로 바꿔 넣고, 한도에서 사용량을 차감하는 것입니다. 메시지는 릴레이에 도달하기 전에 엔클레이브의 키로 암호화되므로 릴레이는 메시지를 읽을 수 없습니다. 하지만 “읽을 수 없다”가 “아무것도 보지 않는다”는 뜻은 아니며, 그 차이는 정확히 짚어 둘 가치가 있습니다.

보는 것

• 누가 요청하는지: 계정 또는 키이며, 무엇이든 전달하기 전에 이를 확인합니다.
• 언제, 얼마나: 각 요청의 시각과 크기, 그리고 답변의 크기.
• 어느 엔클레이브가 답했는지: Tinfoil이 응답 헤더에 모델 엔클레이브를 명시하며, 릴레이는 이를 읽어 요청의 요금을 매깁니다.
• IP 주소(호스팅 업체를 통해).
• 워크스페이스가 요금 계산을 위해 덧붙이는 두 가지 힌트: 요청이 웹 검색을 사용했는지, 그리고 이미지가 몇 장이며 얼마나 큰지.

보지 못하는 것

작성한 글, 첨부한 파일, 받은 답변. 또한 어떤 모델을 요청했는지도 볼 수 없고 어느 엔클레이브가 답했는지만 알 수 있으며, 토큰이 암호문 안에 있으므로 토큰 수를 셀 수도 없습니다.

읽을 수 없는 것에 요금 매기기

그래서 릴레이는 크기로 요금을 매깁니다. 이 글을 쓰는 시점에는 요청 3바이트와 답변 130바이트를 각각 토큰 하나로 계산합니다. 두 값 모두 높게 잡는 쪽으로 정했으며, 답변한 모델의 가격으로, 모델을 알 수 없을 때는 가장 비싼 모델의 가격으로 계산합니다. 이미지는 크기로 따지면 약 100배 과대 계산되므로 워크스페이스가 따로 알리며, 이미지 한 장당 입력 토큰 3,000개로 요금을 매깁니다.

릴레이는 워크스페이스의 힌트를 확인할 수 없습니다. 수정된 클라이언트라면 요금을 덜 내려고 검색 힌트를 빼거나, 요청에서 이미지가 차지하는 부분을 실제보다 크게 주장할 수 있습니다. 이렇게 해서 생길 수 있는 비용은 1인당 및 전체 일일 예산으로 제한되며, 각 요청 전의 확인으로 한 번의 초과도 제한됩니다. 저희는 요금을 정확히 매기기 위해 요청을 읽는 대신 이 방식을 택했습니다.

전달하는 것과 보관하는 것

• 릴레이는 Tinfoil 자체 호스트로만, 그리고 암호화 헤더가 있는 본문만 전달합니다. 따라서 릴레이가 다른 곳을 향하게 하거나 평문을 통과시키게 할 수는 없습니다.
• Tinfoil에서 온 헤더 중 세 개만 돌려주고 나머지는 버립니다.
• 로그에는 경로 이름, 상태 코드, 소요 시간만 남습니다. 프롬프트, 답변, 계정 ID, 키는 절대 남지 않습니다. 테스트로 이를 확인합니다.
• 투명성 페이지를 위해 요청과 실패 건수를 일별 합계로 집계하며, 개인별로는 아무것도 남기지 않습니다.

이 모든 것을 밝히는 이유

개인정보 보호 약속이 흔히 느슨해지는 곳이 바로 메타데이터입니다. 시각, 크기, 신원은 그것만으로도 많은 것을 말해 줄 수 있습니다. 읽지 못하는 릴레이는 읽을 수 있는 릴레이보다 분명히 나아진 것이지만, 여전히 언제, 얼마나, 어디에서 작업하는지는 압니다. 하시는 일에 그 점이 중요하다면, 위협 모델에서 각 부분을 누가 볼 수 있는지, 개인정보 페이지에서 각각이 얼마나 오래 보관되는지 확인하세요.