Summary

  • Internet Explorer 5는 사이트가 제공한 그림을 즐겨찾기에 표시했다. Microsoft는 1999년 Windows 95·98의 IE 5에서 잘못 만든 아이콘을 처리할 때 발생하는 문제를 공개하고 패치를 냈으며, 피해 고객 보고는 없다고 밝혔다.
  • W3C의 2005년 초안은 페이지가 아이콘을 직접 지정하는 방식을 선호했다. 현행 HTML 표준은 선언이 없을 때 /favicon.ico를 찾을 수 있게 하고, 2026년 Edge 설명은 같은 호스트의 다른 문서 아이콘이 저장된 페이지에 붙는 경우를 보여 준다.

1999년의 즐겨찾기 목록에는 이미 사이트가 건넨 작은 그림이 들어갈 수 있었다. Internet Explorer 5가 이를 표시하려면 외부에서 받은 파일을 읽어야 했다. Microsoft가 5월 27일 발표한 보안 공지는 특별히 조작한 즐겨찾기 아이콘이 검사되지 않은 버퍼를 넘어서 Windows 95 또는 98의 IE 5에서 코드를 실행할 수 있다고 밝혔다. 패치가 나왔고, 회사는 피해 고객 보고가 없다고 했다. 문패만큼 작은 파일도 프로그램 안으로 들어오는 문이었다.

몇 년 뒤에는 보안보다 소유권에 가까운 질문이 나왔다. 아이콘을 사이트의 정해진 루트 위치에 두면 브라우저는 찾기 쉽다. 하지만 누가 그 주소를 쓸지 관습이 먼저 결정해 버린다. W3C의 2005년 초안은 사이트 관리자가 자신의 URL 공간을 정해야 한다고 지적했다. 공유 도메인 아래 한 페이지만 운영하는 사람은 루트에 파일을 놓을 권한이 없을 수도 있다. 자기 방 문패를 달려고 건물 전체 열쇠를 구하라는 셈이다.

초안은 페이지 문서에 link rel="icon"을 적고 원하는 그림을 직접 가리키라고 권했다. 당시 초안의 고정 경로 표기는 /favicon이고, 현재 HTML 표준의 대체 경로는 /favicon.ico다. 경로 표기는 달라졌지만 질문은 남았다. 아이콘을 페이지 작성자가 고르는가, 브라우저가 익숙한 장소에서 추측하는가.

현행 표준은 두 선택을 함께 둔다. 아이콘은 페이지 또는 사이트를 나타낼 수 있다. 여러 개가 선언되면 브라우저가 유형, 미디어 조건, 크기를 따져 고른다. HTTP(S) 문서에 icon 링크가 없다면 /favicon.ico를 시도할 수 있다. 예전의 shortcut icon 표기도 역사적 이유로 남아 있다. 더 정확한 길을 만들었지만 오래된 지름길은 막지 않았다.

그 지름길이 엉뚱한 명찰을 가져올 수 있음을 Microsoft의 2026년 3월 Edge 설명이 구체적으로 보여 준다. 새 탭의 저장된 사이트 아이콘은 정확한 URL의 캐시, 같은 호스트의 캐시, favicon 서비스, 첫 글자 순서로 찾는다. Microsoft의 예시에서는 같은 호스트에 HTML 페이지와 PDF가 있다. 정확한 항목이 비면 PDF 아이콘이 홈페이지 즐겨찾기에 나타날 수 있다. 링크는 제자리에 있고 명찰만 옆방에서 왔다.

1999년에는 아이콘 파일을 읽는 방식이 문제였다. 2026년에는 어느 문서의 그림인지 판단하는 방식이 문제다. 작은 그림이 독자의 길찾기를 맡는 순간 출처도 중요해졌다. 페이지가 직접 선언한 그림, 호스트 전체에서 찾은 그림, 이웃 페이지가 캐시에 남긴 그림은 같은 증언이 아니다.