비밀번호가 찍힌 스크린샷을 Gyazo에 올린 뒤, 해시·세션·이미지 글자는 무엇이 남는가

운영이 데이터베이스 비밀번호를 만들고, 터미널을 한 장 찍습니다. 클라이언트가 자동으로 올리고, 채팅창에 gyazo.com/…가 뜹니다. 상대는 눌러서 바로 봅니다. 파일보다 빠릅니다. 내 쪽에서 메시지를 지우면, 그림은 이미 나갔고 링크는 더 이상 붙어 있지 않으니 끝난 것처럼 보입니다. 2026년 9월 11일부터 16일까지 Helpfeel은 이 길을 끝까지 적었습니다. 이미지 호스팅 계정 자체와, 그림 옆에 쌓인 메타데이터는 채팅창이 비워져도 같이 비지 않습니다.

앞글에서는 화면 공유와 스크린샷에서, 비밀번호와 # 뒤의 키는 누가 보는가를 다뤘습니다. 그쪽은 이 기기의 PNG, 스크린샷 앨범, 회의 녹화에 남는 픽셀입니다. 이 글의 질문은 바뀝니다. 스크린샷이 이미 Gyazo에 올라간 뒤, 계정 쪽 비밀번호 해시와 로그인 세션, 이미지 메타데이터의 Image ID와 OCR 글자가 공지가 지목한 어느 항목에 남는가. 키를 일회용 링크로 바꾸면 형태는 여전히 s.html?id=…#…입니다. 만들기와 읽기 모두 가입이 없습니다. MyPassGen 도구는 열면 바로 씁니다. 어떤 취약점을 어떻게 쓰는지 설명하지 않습니다. Helpfeel 2026년 9월 16일 영문 공지와 같은 날 일본어 공지에 이미 적힌 항목, 그리고 내 계정에서 열 수 있는 갤러리만 대조합니다.

호스팅에 올리면, 그림 한 장이 아니다

Gyazo는 스크린샷, GIF, 짧은 화면 녹화용 클라우드 이미지 호스팅입니다. 클라이언트가 화면을 잡아 올리고, 공유할 수 있는 링크를 돌려줍니다. Helpfeel은 공지에서 「images」를 Gyazo로 잡아 저장한 모든 내용으로 정의합니다. 스크린샷, GIF, 동영상을 포함합니다. 무료 계정은 웹에서 최근 몇 장만 보는 경우가 많습니다. 옛 그림이 서버에서 지워지지는 않습니다. 완전한 주소를 가진 사람은 열 수 있습니다. The Hacker News가 옮긴 도움말 페이지의 말은 이렇습니다. 기본 설정에서 보호는 링크 자체입니다. 링크가 「추측하기에 충분히 길다」는 말과, 링크가 한 번 샌 뒤에도 보호된다는 말은 다릅니다.

「웹페이지가 지금 만들고 있는 비밀번호를 올렸는가」와는 다른 길입니다. MyPassGen 생성 페이지는 Network에서 평문을 업무 데이터로 보내지 않았는지 확인할 수 있습니다. 내가 올린 PNG는 이미지 호스팅 자신의 인터페이스로 갑니다. 호스팅이 저장하는 것은 픽셀만이 아닙니다. 계정 쪽에는 이메일, 비밀번호 해시, 로그인 세션이 있습니다. 그림마다 Image ID, 업로드 IP, User-Agent, EXIF 위치, OCR로 뽑은 글자가 붙습니다. 채팅 기록을 지워도 호스팅 데이터베이스의 그 행은 지워지지 않습니다.

앞글에서 클립보드를 다룰 때, 비밀번호는 생성 페이지를 떠나 시스템 클립보드로 갔습니다. 스크린샷은 화면을 떠나 이 기기의 파일이 됩니다. 다시 올리면 남의 서버로 갑니다. 세 잔여물은 「이미 보냈다 / 이미 비밀번호를 바꿨다」와 같지 않습니다. 가리지 않은 티켓 스크린샷을 이미지 호스팅에 넣는 일은, 비밀번호를 메일 본문에 쓰는 일과 같은 종류의 문제입니다. 수신자가 보는 것은 내가 건넨 사본입니다. 이메일 본문에 임시 비밀번호를 쓰면, 보낸편지함·전달·휴대폰 미리보기에 무엇이 남는가를 보세요.

Helpfeel이 9월 16일 공지에 적은 숫자

공지는 별도 표시가 없으면 일본 표준시라고 적습니다. 2026년 9월 11일, 제삼자가 Gyazo 이미지 업로드 서버의 취약점을 이용해 시스템에서 임의 명령을 실행했습니다. 그날 밤 Helpfeel이 이상을 발견하고 대응을 시작했습니다. 9월 12일 새벽, 확인된 진입점을 끊고 무단 연결을 끊었으며, 같은 날 취약점 수정을 마쳤습니다. 9월 14일 조사는 정보가 무단 공개됐음을 확인하고, 이미지 배포 중단을 포함한 예방 조치를 취했습니다. 9월 15일 「대응이 끝난 뒤 새로 올린」 이미지의 배포를 재개하고, 일본 개인정보보호위원회에 보고서를 냈습니다. 9월 16일 이 설명을 공개했습니다.

사용자 정보 쪽에서, 무단 공개가 확인된 기록은 약 2362만 건입니다. 항목은 사람마다 다릅니다. 공지가 적은 목록에는 이름 또는 닉네임, 이메일, 비밀번호 해시, 사용자 ID, 기기 ID, 로그인 세션 ID, 연결돼 있을 때 X(구 Twitter) 연동 토큰, 연결돼 있을 때 Google SSO 이메일, 프로필, 언어, 가입 시각, 최근 로그인 시각, 구독 요금제, 청구 상태(신용카드 번호 등 결제 수단 정보는 제외), 이용 통계가 있습니다. 2362만 건에는 이메일을 등록하지 않은 익명 계정도 들어 있습니다. Helpfeel은 「몇 명의 자연인 개인정보가 공개됐는지」를 아직 집계 중이라고 적습니다. 결제 정보(카드 번호 포함)는 무단 공개되지 않았다고 확인했다고 씁니다.

이미지 메타데이터 쪽에서, 약 4.9억 건이 공개된 것으로 확인됐습니다. 주로 2019년 1월 및 그 이전에 등록된 그림이며, 전체 이미지 관련 데이터의 약 14.4%입니다. 별도로 약 240만 장의 메타데이터가 「특정 선별 조건」으로 꺼내져 마찬가지로 공개됐습니다. Helpfeel은 두 묶음이 겹치는지는 쓰지 않았고, 둘째 묶음에 더 최근 그림이 들어 있는지도 쓰지 않았습니다. 메타데이터 항목에는 그림 주소를 만드는 Image ID, 업로드 당시 출발 IP, User-Agent, 그림에 들어 있을 경우 EXIF 위치, 그림에서 뽑은 OCR 글자, 그림 제목, 출처 URL과 기타 메타데이터, 비공개 그림의 비밀번호 해시, 관련 정보가 있습니다. 조사는 이번 접근으로 그림 본문이 사라진 것은 확인하지 못했습니다. Helpfeel과 Cosense의 구조는 Gyazo와 다르며, 현재까지 두 시스템이 이번 사건으로 정보를 공개한 것은 확인되지 않았습니다. 그 안에 끼워 둔 Gyazo 그림은 배포 중단으로 열리지 않을 수 있습니다.

비밀번호 해시, 세션 ID, 외부 연동 토큰

비밀번호 해시는 로그인 칸의 그 한 줄 평문이 아닙니다. 서버가 「다음에 입력한 것이 같은 줄인가」를 맞추는 저장 형태입니다. 해시가 샌다고 상대가 당장 원문을 읽는 것은 아닙니다. 영원히 못 읽는 것도 아닙니다. 그래서 Helpfeel은 모든 Gyazo 사용자에게 비밀번호 변경을 요구합니다. 이 비밀번호나 비슷한 비밀번호를 다른 서비스에도 썼다면 그쪽도 바꿉니다. 「이미지 호스팅에만 중요하지 않은 비밀번호를 썼다」와 같은 문장이 아닙니다. 재사용했다면, 호스팅 해시는 다른 사이트 로그인 칸의 재료입니다. 이 기기에서 흔한 약한 비밀번호 목록과 대조하는 일은, 공개 목록에 걸렸다는 것만 증명합니다. 어떤 유출에 들어간 적은 없다고 증명하지 않습니다. 기기에서 유출 목록만 대조하는 것과 전체 유출 조회는 무엇이 다른가를 보세요.

로그인 세션 ID는 다른 층입니다. 사이트는 페이지를 열 때마다 비밀번호를 다시 묻지 않습니다. 로그인에 성공한 뒤 남는 세션이 「이미 본인」임을 증명합니다. 세션 ID가 열람된 데이터베이스에 들어가면, 상대가 손에 넣을 수 있는 것은 아직 유효한 출입증일 수 있습니다. 로그인 칸을 다시 거치는 길이 아닙니다. 공지는 인증 관련 정보를 「무효화하고 제한」했다고 적습니다. 세션 ID가 모두 만료됐는지, 새 IP 로그인의 인증번호가 재전송을 막기에 충분한지는 쓰지 않았습니다. 앞글에서 AI 세션을 다룰 때, Okta는 만료되지 않은 토큰을 skeleton key라고 불렀습니다. 비밀번호 변경은 아직 살아있는 세션을 막지 못합니다. 비밀번호와 인증번호를 바꾼 뒤에도, 브라우저의 AI 로그인 세션으로는 누가 들어가나를 보세요. Gyazo 쪽은 지금 옛 기기가 로그인을 유지하는지, 공지 이후 내가 직접 비밀번호를 바꿨는지를 기준으로 보세요. 「무효화했다고 썼다」를 내가 다시 로그인하는 일로 바꾸지 마세요.

X 연동 토큰과 Google SSO 이메일은 셋째 층입니다. 토큰은 연결된 계정을 대신 방문하는 데 쓰입니다. 이메일은 호스팅 신원과 Google 로그인을 묶습니다. Helpfeel은 이번 사건과 관련된 수상한 메일과 메시지에 주의하라고 요구합니다. 피싱 메일은 실제 이메일, 실제 닉네임, 실제 「Gyazo를 썼다」는 사실을 가지고 씁니다. 호스팅에서 외부 연결을 끊는 일, 비밀번호를 바꾸는 일, 세션을 확인하는 일은 세 가지입니다. 기억나는 한 가지만 하면, 나머지 두 가지는 상대 손에 남을 수 있습니다.

Image ID와 「추측할 수 없는 링크」

공지는 Image ID를 「이미지 URL을 만드는 정보」로 적습니다. 제삼자가 이를 써서 허가 없이 해당 그림을 보고 접근할 수 있다고도 적습니다. Helpfeel은 이 때문에 일부 그림의 열람을 잠시 멈췄습니다. 어떤 그림이 멈췄는지, 내 캡처가 영향 집합에 들어갔는지를 사용자가 어떻게 판단하는지는 쓰지 않았습니다. 무료 계정은 웹에서 최근 몇 장만 넘기는 경우가 많습니다. 「목록에 안 보인다」고 서버에서 사라진 것은 아닙니다. 주소를 맞출 수 있는 사람은 열 수 있습니다.

도움말 페이지는 이런 링크를 「추측하기에 충분히 길다」고 적습니다. 추측할 수 없다는 말은, ID 자체가 한꺼번에 빠져나가지 않는다는 전제에 기대 있습니다. 4.9억 건의 메타데이터에 Image ID가 들어 있다는 것은, 「추측할 수 없다」는 전제의 일부를 빼 간 것과 같습니다. 주로 2019년 1월 및 그 이전 묶음과, 특정 조건으로 골라 낸 약 240만 장입니다. 2018년에 사내 주소나 테스트 비밀번호가 찍힌 터미널 스크린샷을 한 장 올렸다면, 오늘 채팅 기록에는 그 링크가 없을 수 있습니다. 메타데이터의 ID는 같은 그림을 다시 맞출 재료가 될 수 있습니다.

공지는 또 확인합니다. 제삼자가 비공개 그림을 가리키는 목록을 손에 넣었습니다. Helpfeel은 일부 비공개 그림이 열람됐을 가능성을 배제할 수 없다고 적고, 조사는 계속된다고 씁니다. 유료 기능의 「나만 보기」나 비밀번호 잠금이 상대하는 것은 「링크를 모르거나 비밀번호를 모르는 행인」입니다. 이미 데이터베이스에 들어가 비공개 목록까지 가진 사람 앞에서, 도움말 페이지의 「너만 볼 수 있다」는 그 자리에서 대조할 수 있는 약속이 아닙니다. 비공개 그림의 비밀번호도 해시 형태로 메타데이터 목록에 나옵니다. 계정 비밀번호 해시와 같습니다. 먼저 「상대가 오프라인으로 처리할 재료를 하나 더 가졌다」로 보세요. 「해시니까 안전하다」로 보지 마세요.

OCR 글자: 픽셀 속 비밀번호가 글자가 된다

공지는 「그림에서 뽑은 OCR 글자」를 공개된 메타데이터에 넣습니다. The Hacker News가 옮긴 Gyazo 도움말 페이지는 이렇게 말합니다. OCR은 사용자가 직접 켜는 유료 기능이고, 켜면 그 계정의 그림을 스캔하며, 「OCR 결과는 너만 볼 수 있다」고 적혀 있었습니다. 검색되는 글자는 내보낼 수 있는 글자이고, 데이터베이스 항목에 들어갈 수 있는 글자입니다. 스크린샷 속 터미널 출력, 브라우저 주소창, 비밀번호 관리자의 보이는 결과 영역은 OCR에게 같은 종류의 픽셀입니다. 앞글에서 적었습니다. MyPassGen의 생성 결과는 점 마스킹이 아니라 보이는 글자로 나옵니다. 일회용 링크를 만들면 전체 s.html?id=…#…도 페이지에 표시됩니다. Network는 요청 줄에 # 뒤가 없음을 증명할 수 있습니다. 호스팅 OCR 항목에 없다는 증명은 아닙니다.

「누가 그 Gyazo 링크를 눌렀는가」보다 한 층이 더 있습니다. 링크를 누른 사람은 픽셀을 봅니다. 메타데이터를 가진 사람은 「password=」 뒤의 그 줄을 바로 검색할 수 있습니다. 그림마다 다시 열 필요가 없습니다. EXIF 위치는 다른 줄입니다. 휴대폰 스크린샷이나 카메라 사진에 위치가 들어 있으면, 메타데이터에 올릴 당시 장소가 남을 수 있습니다. 출발 IP와 User-Agent는 「누가 어느 기기에서」를 같은 행에 적습니다. 티켓을 내보내기 전에 가려야 하는 것은 채팅 본문의 휴대폰 번호만이 아닙니다. 스크린샷 픽셀 속 비밀번호와 키도 포함합니다. 티켓과 채팅 로그를 넘기기 전에, 반드시 가려야 할 항목을 보세요.

일회용 링크 전체가 찍힌 스크린샷을 호스팅에 올리면, 픽셀과 OCR이 뽑을 수 있는 주소 전체를 함께 넘기는 셈입니다. 키가 # 뒤에 있는 것은 HTTP 요청 줄만 막습니다. 그림을 보고 OCR을 돌리는 쪽은 막지 못합니다. 한 사람에게 오류만 보여 줘야 하면, 오류 자체만 가두고 결과 목록과 주소창은 피하세요. 키는 일회용 링크로 따로 보냅니다. 스크린샷과 같은 링크에 묶지 마세요.

대조표: 이 기기와 호스팅에 남는 것

방금 화면에 나온 테스트 비밀번호는, 「누가 다시 읽을 수 있는가」를 적어도 네 갈래로 나눌 수 있습니다. 차이는 알고리즘 이름이 아닙니다. 픽셀과 계정 항목이 어디에 복사됐는지입니다.

다섯째 줄과 앞의 네 줄을 섞지 마세요. 완전한 s.html?id=…#…를 스크린샷에 적어 올리면, OCR과 그림을 보는 사람은 여전히 자격 정보 전체를 가질 수 있습니다. 암호문을 맡긴 서비스만 키를 못 볼 뿐입니다. 번호와 키를 나누면, 전체 검색으로도 열 수 있는 완전한 링크가 나오지 않습니다. 완전한 링크는 여전히 비밀번호 자체처럼 다루세요. 이 기기에서 먼저 암호화한 뒤 올리는 것은 파일입니다. 「평문 스크린샷을 암호문 스크린샷으로 바꾼다」가 아닙니다. 픽셀이 한 번 찍히면, 호스팅은 그림으로 저장합니다.

그 자리에서 확인하기

아래 단계는 어떤 브랜드 약속에도 기대지 않습니다. 처음부터 끝까지, 실제 업무 계정에 로그인하지 않는 테스트 비밀번호와 테스트 스크린샷만 씁니다. 예를 들어 터미널에 orange-lake-7 한 줄을 적고 그 칸만 가둡니다. 지금 쓰는 마스터 비밀번호, 운영 API 키, 실제 일회용 링크로 연습하지 마세요.

1. Gyazo 웹이나 클라이언트의 갤러리를 열고, 오래된 것부터 최근까지 넘깁니다. 무료 계정 목록은 최근 몇 장만 보일 수 있습니다. 아직 가지고 있는 옛 링크로 한 번 더 엽니다. 열리면 「목록에 안 보인다」와 「서버에 없다」는 다릅니다. 테스트 비밀번호, 주소창, #가 찍힌 그림을 적고, 지울 수 있으면 지우고, 공유를 멈출 수 있으면 멈춥니다.
2. OCR이나 그림 안 검색을 켠 적이 있으면, 테스트 비밀번호의 그 몇 단어로 검색합니다. 걸리면 글자가 이미 검색 가능한 항목에 들어간 것입니다. 픽셀만이 아닙니다. Helpfeel은 OCR 글자를 공개된 메타데이터에 넣었습니다. 내가 검색할 수 있는 것은, 상대가 메타데이터를 가졌을 때도 문자열로 검색할 수 있습니다.
3. Gyazo 비밀번호를 바꿉니다. 이 비밀번호나 비슷한 비밀번호를 이메일, 드라이브, 코드 호스팅에도 썼다면 그쪽도 바꾸고, 새 무작위 비밀번호로 교체합니다. MyPassGen 비밀번호 생성의 랜덤 모드는 6–128자, 기본 16자, 8자 미만이면 약하다고 알립니다. 열면 바로 씁니다. 생성 결과는 업무 데이터로 올라가지 않습니다. 「호스팅은 중요하지 않으니 재사용해도 된다」로 이 단계를 건너뛰지 마세요.
4. 계정의 외부 연결을 봅니다. X, Google SSO. 끊을 수 있으면 끊습니다. 비밀번호를 바꾼 뒤, 다른 브라우저나 시크릿 창으로 다시 로그인해서 옛 창이 로그인을 유지하는지 봅니다. 공지는 인증 정보 무효화와 제한을 적었습니다. 지금 새로고침한 세션을 기준으로 보세요. 뉴스 제목으로 이 한 눈을 대체하지 마세요.
5. 이 기기에서 같은 테스트 스크린샷을 찾습니다. 데스크탑, 사진 앱, Pictures\Screenshots, 다운로드 폴더, 드라이브 동기화 폴더. 호스팅에서 지워도 이 기기와 드라이브에는 각 한 장이 남는 경우가 많습니다. 처리 방법은 파일을 클라우드에 넣기 전에, 평문은 누가 읽을 수 있고 암호는 어느 길로 보내야 하는가와, 스크린샷이 어디에 떨어지는지를 다룬 앞글을 보세요.
6. 같은 테스트 문장으로 MyPassGen 일회용 링크를 하나 더 만듭니다. 만료는 24시간, 읽기 횟수는 1로 둡니다. 채팅이나 티켓에는 우물정자 앞, s.html?id=…만 붙입니다. 키는 전화나 대면으로 말합니다. 열면 바로 씁니다. 가입은 없습니다. 번호만 있으면 수신자는 불완전한 링크를 봐야 합니다. 양쪽을 맞춰야 복호화됩니다. 읽은 뒤 클립보드를 덮어씁니다. #가 남은 주소를 동기화하는 브라우저 설정에 넣지 마세요. 결과 페이지 전체 화면을 어떤 이미지 호스팅에도 올리지 마세요.

회사 계정이면 반 걸음을 더합니다. 스크린샷이 기본으로 어느 호스팅에 올라가는지, 자동 업로드를 끌 수 있는지, 옛 그림을 한꺼번에 지울 수 있는지 묻습니다. MyPassGen은 어떤 호스팅이 사본을 더 저장했는지 대신 판단하지 않습니다. 방금 연 창을 믿으세요.

키를 넘겨야 할 때 통로를 나누는 법

일대일로, 상대가 지금 열 수 있으면, 호스팅에 들어가고 채팅 기록에 남고 OCR 항목에 붙는 스크린샷에 비밀번호를 넣지 마세요. 이 기기에서 비밀번호를 만든 뒤 일회용 링크로 감쌉니다. 일회용 링크를 만들 때 브라우저는 AES-256-GCM으로 암호화합니다. 평문 상한은 32 KB입니다. 읽기 횟수 기본값은 1, 상한은 10입니다. 만료는 1시간, 24시간, 7일, 또는 횟수만 세고 TTL 없음입니다. 서버는 암호문만 잠시 보관합니다. 키는 URL의 # 뒤에 두므로, 접속 로그와 Referer에는 이 조각이 보이지 않습니다. 화면과 호스팅 OCR은 봅니다. 그래서 결과 페이지를 찍지 마세요.

저장소나 티켓에 입구를 남겨야 하면 통로를 나눕니다. 파일에는 담당자와 번호, 「키는 전화로」라는 문장만 넣습니다. 전화, 대면, 다른 메신저 계정이 # 뒤 조각만 가져갑니다. 한쪽만으로는 풀리지 않습니다. 제품 기본 분리가 아니라 사용법입니다. 만들기 페이지는 여전히 완전한 링크 하나를 내보냅니다. 일대일 전달에는 편합니다. 미리보기 카드를 그리는 채널에는 시험 링크로 미리보기가 횟수를 세는지 먼저 보세요. 일회용 링크를 슬랙이나 카카오톡에 보내면, 미리보기가 먼저 한 번 태우나를 참고하세요. 오류 스크린샷은 먼저 가리기를 거친 뒤, 올릴지 결정하세요.

32 KB를 넘는 키 묶음이나 내보내기 표는 일회용 링크에 억지로 넣지 않습니다. 파일 암호화를 씁니다. 브라우저에서 AES-256-GCM 스트림, 파일 하나 최대 5 GB, 출력은 .lock / .enc, 암호는 따로 보냅니다. 이 기기에서 먼저 암호화한 뒤 동기화하면, 상대는 암호문만 봅니다. 가리지 않은 터미널 스크린샷을 Gyazo에 미는 일과, 암호화하지 않은 .env를 드라이브에 미는 일은 같은 종류의 문제입니다. 「내가 본인이다」 또는 「이것이 키다」를 증명하는 그 한 장이, 이미 지웠다고 생각한 창을 떠납니다.

「옛 링크가 아직 열리는가」, 「OCR이 테스트 비밀번호를 아직 찾는가」, 「비밀번호만 바꾸면 갤러리가 비는가」 세 번을 확인하면, 이 글의 질문에 답할 수 있습니다. 채팅의 Gyazo 링크를 지워도, 계정 해시, 세션 ID, Image ID, 이미지 글자는 공지가 지목한 항목에 남을 수 있습니다. Helpfeel이 무효화한 것은 그들이 무효화할 수 있는 인증 재료입니다. 4.9억 건 메타데이터의 글자와 ID는 비밀번호를 한 번 바꾼다고 비지 않습니다. 갤러리와 재사용한 비밀번호는 확인 입구로 맞습니다. 「채팅을 지웠으니 끝났다」는 가정으로는 맞지 않습니다.

자주 묻는 질문

Gyazo 비밀번호를 바꿨으면 옛 스크린샷도 없어지나요?

다른 일입니다. 비밀번호 변경은 다음 로그인 칸과, 공식이 이미 무효화한 인증 재료에 영향을 줍니다. Image ID, OCR 글자, 옛 그림 본문은 「비밀번호 변경」 동작 안에 없습니다. 지금 옛 링크로 열리는지, 갤러리 검색에 걸리는지를 기준으로 보세요.

해시가 샌 것은 상대가 이미 내 평문 비밀번호를 안다는 뜻인가요?

당장 원문을 읽는다는 아니고, 계속 재용해도 된다는 뜻도 아닙니다. Helpfeel은 모든 사용자에게 비밀번호 변경을 요구하고, 같거나 비슷한 비밀번호를 다른 곳에도 썼다면 함께 바꾸라고 요구합니다. 먼저 비밀번호를 바꾼 뒤, 이 기기로 호스팅에 계속 로그인할지 정하세요. 「해시일 뿐」으로 변경을 건너뛰지 마세요.

그림이 비공개이거나 열람 비밀번호가 있으면, 올리지 않은 셈으로 봐도 되나요?

안 됩니다. 공지는 제삼자가 비공개 그림 목록을 가졌다고 확인하고, 일부 비공개 그림이 열람됐을 가능성을 배제할 수 없다고 적습니다. 비공개 비밀번호 자체도 해시 형태로 메타데이터 목록에 나옵니다. 비공개 설정이 막는 것은 행인입니다. 이미 데이터베이스에 들어간 사람이 아닙니다.

만들기와 읽기에 가입이 필요한가요? 잘못 지웠을 때 지원이 찾아 주나요?

가입은 없습니다. 만들기와 읽기는 방문객에게 공개입니다. 암호문이 횟수나 만료로 탄 뒤에는 서버 쪽 평문 백업이 없고, 되찾아 줄 지원 수신함도 없습니다. 통로를 잘못 보냈으면 비밀번호와 링크를 새로 만드세요. 같은 URL을 새로고침하며 돌아오는지 보지 마세요. 결과 페이지를 이미지 호스팅에 올려 다시 보내지도 마세요.