브라우저 기반 파일 변환: 작동 방식과 파일이 비공개로 유지되는 이유

서버 기반 변환기에 파일을 업로드하면 세 가지 일이 일어난다. 파일이 네트워크를 통해 당신이 통제하지 않는 IP 주소로 이동한다. 그 서버의 프로세스가 파일을 디코딩한다. 그런 다음, 사이트의 보존 정책에 따라 파일은 몇 분에서 영원히 디스크에 남는다.

똑같은 일을 브라우저 탭에서 하면, 파일은 당신 기기의 RAM을 결코 떠나지 않는다. 디코더는 브라우저 엔진이 강제하는 WebAssembly 샌드박스 내에서 실행된다. 네트워크는 절대 건드려지지 않는다.

이것은 정책의 차이가 아니라 아키텍처의 차이다. 서버 기반 변환기는 파일을 삭제하겠다고 약속할 수 있다. 브라우저 기반 변환기는 애초에 파일을 받지 않기 때문에 유출할 수 없다.

아키텍처

클라이언트 사이드 변환을 가능하게 하는 네 개의 레이어:

레이어 1: 파일 접근

파일을 브라우저 탭에 드롭하면, DragEvent 또는 <input type="file">이 JavaScript에 File 객체를 제공한다. File은 파일의 내용이 아니다. 이름, 크기, MIME 타입, 그리고 필요할 때 디스크에서 메모리로 바이트를 읽어오는 메서드(file.arrayBuffer())를 가진 참조다.

그 메서드가 호출되기 전까지는 제로 바이트가 이동한다. 파일은 당신의 파일 시스템에 그대로 있다. 브라우저의 파일 선택기는 OS 레벨의 대화상자다. 웹 페이지는 사용자가 명시적으로 선택한 File 객체만을 본다.

레이어 2: 형식 감지

모든 파일의 처음 몇 바이트는 그 형식을 확실하게 식별한다. JPEG은 FF D8 FF로 시작한다. PNG는 89 50 4E 47로 시작한다. HEIC 파일은 오프셋 8에 heic 또는 heif 브랜드를 가진 ftyp 박스를 포함한다.

파일의 헤더(일반적으로 처음 32바이트)를 읽는 것만으로도 확장자와 관계없이 실제 형식을 확인하기에 충분하다. 이 검사는 어떤 디코더도 픽셀 데이터를 건드리기 전에 실행된다. 헤더가 일치하지 않으면 파일은 즉시 거부된다. 낭비되는 CPU도, 디코딩 도중에 혼란을 주는 오류 메시지도 없다.

레이어 3: 디코딩

원시 바이트는 디코더를 통해 픽셀이 된다. 어떤 디코더를 사용할지는 형식에 달려 있다:

JPEG, PNG, WebP, BMP: 브라우저는 이러한 형식의 네이티브 디코더를 내장하고 있다. createImageBitmap()은 압축된 바이트를 플랫폼의 코덱(Windows의 Windows Imaging Component, macOS의 Core Graphics, Linux/ChromeOS의 Skia)에 전달하고 원시 픽셀 데이터를 반환한다. 이 경로는 빠르고, OS가 지원하는 경우 하드웨어 가속되며, 추가 코드가 필요 없다.
HEIC: Safari를 제외한 어떤 브라우저도 HEIC 네이티브 디코더를 내장하고 있지 않다. 우리의 변환기는 C 라이브러리인 libheif를 WebAssembly로 컴파일하여 번들한다. .wasm 바이너리(압축 시 ~1.2 MB)는 한 번 다운로드되어 캐시된다. WASM 샌드박스 내에서 완전히 HEIF/HEIC 파일을 원시 RGB 픽셀로 디코딩한다.
PDF: PDF.js(Mozilla의 PDF 렌더러)가 각 페이지를 요청된 해상도로 캔버스에 렌더링한다. 서버 사이드 렌더링은 없다. PDF가 브라우저를 떠나는 일은 없다.

모든 디코더는 메모리에서 읽고 메모리에 쓴다. 어떤 디코더도 소켓을 열지 않는다. 특히 WASM 샌드박스는 네트워크 요청을 할 수 없다: 브라우저는 WebAssembly 모듈에 네트워킹 API를 노출하지 않는다. C 코드가 socket()을 호출하더라도 샌드박스가 이를 가로챌 것이다.

레이어 4: 인코딩

원시 픽셀은 <canvas> 요소의 2D 컨텍스트로 들어간다. canvas.toBlob() 또는 canvas.toDataURL()이 브라우저의 내장 인코더를 호출하여 JPG, PNG, WebP 출력을 생성한다. 인코더는 플랫폼 네이티브 코드다: 당신의 OS가 스크린샷을 저장할 때 사용하는 것과 동일한 코드 경로다.

출력은 Blob으로, 메모리 내 바이트 버퍼다. 다운로드 링크에 전달되거나 JavaScript로 구축된 ZIP 아카이브에 패킹된다. 어떤 시점에서도 어떤 바이트도 네트워크 소켓에 닿지 않는다.

브라우저가 강제하는 것

웹 페이지는 브라우저가 엔진 레벨에서 유지하는 샌드박스 내에서 실행된다. 이것은 정중한 합의가 아니다. 프로세스 격리에 의해 강제된다:

렌더러 프로세스: JavaScript 엔진, DOM, WASM 런타임은 직접적인 파일 시스템이나 네트워크 접근이 없는 샌드박스화된 프로세스에서 실행된다. IPC를 통해 브라우저 프로세스와 통신한다.

사이트 격리: 현대 브라우저는 각 출처를 자체 렌더러 프로세스에 배치한다. file-convert-factory.org의 파일들은 다른 어떤 도메인에서 실행 중인 JavaScript에서도 볼 수 없다.

WASM 샌드박스: WebAssembly 모듈은 평평한 선형 메모리 버퍼만을 인식하며, 그 외에는 아무것도 없다. 파일 시스템 API도, fetch도(JavaScript에서 명시적으로 가져오지 않는 한), DOM이나 다른 브라우저 API에 대한 접근도 없다. 손상된 WASM 모듈이 할 수 있는 최악의 일은 자신의 메모리를 손상시켜 탭을 충돌시키는 것이다.

서버 사이드 변환기는 서버 OS에서 특권 프로세스로 실행된다. 디스크에서 읽고, 디스크에 쓰고, 네트워크 연결을 열고, 자식 프로세스를 생성할 수 있다. 보안 모델은 서버 운영자의 능력과 의도에 달려 있다. 브라우저 샌드박스는 브라우저 엔진의 정확성에만 의존하며, 브라우저 샌드박스는 소프트웨어에서 가장 엄격하게 감사되는 보안 경계 중 하나다.

서버 기반 변환기가 약속하는 것(과 약속하지 않는 것)

서버 기반 변환기가 본질적으로 악의적인 것은 아니다. 많은 팀들이 선의로 운영하고 있다. 문제는 구조에 있다:

업로드 단계는 복사다. 이제 파일이 두 곳에 존재한다. 한 사본은 당신이 통제하고, 다른 하나는 누군가 다른 사람이 통제한다.
삭제는 약속이다. "24시간 후에 파일을 삭제합니다"는 로그 라인, 크론 잡, 백업 시스템, 그리고 서버 접근 권한이 있는 모든 직원을 신뢰하는 것을 의미한다. 이 중 어느 것도 외부에서 검증할 수 없다.
메타데이터가 파일과 함께 이동한다. 사진의 EXIF 데이터(GPS 좌표, 카메라 일련번호, 타임스탬프)는 파일 바이트의 일부다. 파일이 업로드되면, 메타데이터도 업로드된다. EXIF 프라이버시 가이드는 거기에 무엇이 있는지, 그리고 어떻게 제거하는지 정확히 다룬다. 간단히 말해: 이 사이트의 모든 변환기는 픽셀을 디코딩하고 재인코딩하기 때문에 이미지 데이터가 아닌 모든 것을 제거한다.
HTTPS는 파이프를 보호하지만, 엔드포인트는 보호하지 않는다. TLS는 전송 중인 업로드를 암호화한다. 파일이 도착한 후에 무슨 일이 일어나는지에 대해서는 아무것도 하지 않는다.

브라우저 기반 변환기의 프라이버시 보장은 더 좁지만 더 강력하다. 그것은 말한다: 당신의 파일이 기기를 떠나지 않는 이유는 그렇게 할 코드 경로가 존재하지 않기 때문이다. 이것은 검증 가능하다. 파일을 변환하는 동안 DevTools의 네트워크 탭을 열어보라. WASM 바이너리가 한 번 로드된 후, 그 이후로는 아무것도 없다. 제로 바이트 업로드. /api/convert 요청 없음. WebSocket 트래픽 없음. 변환은 완전히 렌더러 프로세스 내에서 발생한다.