나는 3,000년 전부터 있었던 느낌의 사람임. 프레임 내비게이션이 나쁜 관행인지에 대해 격렬하게 논쟁하던 시절을 기억함 (iframe이 아니라 프레임임). 프레임을 아는 사람이 혹시 있으면 반가움. AJAX가 나오기 전에는 HTTP 204를 활용해 페이지 새로고침 없이 서버로 메시지를 보내는 방법을 직접 썼음. 2000년대 초반에는 이미지 맵도 작업함 이미지 맵 참고: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/map. 드림위버로 지도 경계선을 여러 날 동안 그려서 클릭 가능한 국가 지도를 완성한 적도 있음. 드림위버 템플릿은 버전 컨트롤을 안 써서 업데이트하다가 수정사항 다 날리고 복구 불가능한 상황도 많았음. input type=image으로 이미지 클릭 위치를 백엔드에서 처리하던 기억도 있음. 모션 JPEG을 이용해 페이지에 스트리밍 업데이트도 구현했고, 아직도 크롬에서는 되고 파이어폭스에서는 약간 불안정함. IE에서 PNG 알파 블렌딩 문제 해결하려고 여러 방법을 시도하다가 결국 ActiveX 버전으로 좀 써먹었으나, 결국 플랫 디자인 유행하면서 필요 없어짐. 네비게이션은 JAVA, Flash, Silverlight까지 다 써봤음. 스페이서 GIF, 조건부 주석, Firebug 등장 이후 개발환경이 얼마나 편해졌는지도 생생하게 기억함. 언제 나이가 들었는지 모르게 시간이 흘렀던 경험임
예전 프레임으로 웹 소프트웨어를 개발했는데 딱히 문제를 느끼지 못했음. 사람들은 접근성을 이야기하지만 구체적으로 어디가 문제인지 아직까지도 잘 모르겠음
IE6의 모든 괴상한 버그와 한계 속에서 지원을 요청하는 고객사를 위해 일했던 기억임. 디자이너가 포토샵으로 둥근 모서리 디자인을 넘기면 매번 한숨 쉴 수밖에 없었음. 그 당시에는 반응형이라는 게 사실 데스크탑 해상도 여러 개 대응하는 정도였음. 모서리를 이미지로 잘라 테이블 셀에 직접 배치해야 했음. 이런 수작업을 하면서 개발자의 정신력이 크게 강화됨을 느낌
포토샵 slice 툴로 이미지를 세밀하게 나누고 gif로 내보낸 후 HTML 테이블에 정확하게 배치하려 애썼던 때를 기억함. 800x600 해상도에 최적화된 디자인이 많았던 시절임. 이 모든 추억이 시간 속에 녹아 사라진 느낌임
지금도 프레임을 몇 번씩 방문하는 사이트가 있음. Open Group/POSIX 사이트는 여전히 프레임을 사용 중임
프레임을 이용해 웹챗을 만든 적이 있음. 위에는 무한 로딩되는 채팅창, 아래에는 input box가 있었고, 메시지 보낼 때는 204로 새로고침을 막았음. 위쪽 프레임에는 user list가 있는 오른쪽 프레임을 reload하는 작은 script도 보낼 수 있었음. 2000년 즈음에 친구 몇 명과 함께 사용했음
전에 순수 marquee 태그만으로 애니메이션을 구현한 사이트를 만들었음. JavaScript는 전혀 사용하지 않았고, 누군가에게 보여주면 다들 놀람 https://udel.edu/~ianozi/
marquee 태그 안 본지 20년은 된 것 같은데, direction 파라미터로 수직 스크롤도 가능하다는 사실을 몰랐던 것 같음
marquee 태그로 제일 좋아하는 트릭은 중첩해서 쓰는 것임. 방향을 다르게 하면, 안쪽 marquee를 반대 방향과 같은 속도로 맞추면 순간 정지했다가 움직이는 효과를 낼 수 있음. 속도를 다르게 하면 더 복잡한 움직임도 구현 가능했음. 이 방법이 제대로 작동하려면 inner marquee에 최대 너비를 설정해줘야 했던 기억임
예전에 blink 태그가 워낙 싫어서 사용하던 브라우저(아마 Netscape)의 바이너리 파일에서 'blink'를 'blonk'로 바꿔서 더 이상 깜박이지 않게 만든 적 있음
나는 이런 식의 바이너리 트윅을 주로 Slack 클라이언트에서 자주 함(Electron 앱이라 엄청 쉬움). 내가 싫어하는 기능(예: 알림 숨기기, 입력 중 신호 차단하기 등)도 쉽게 없앨 수 있음
누군가 blonk 태그를 썼으면 이제는 blonking이 생겼을지 모름. 꽤 재미있는 해킹 같음
바이너리 수정이 꽤 재미있음. "__gnu_warning"를 "__gnu_whining"으로 바꿔서 gets() 경고성 메시지를 없애곤 했음. 버퍼 오버런은 그럴 수도 있지만 대충 만드는 코드에서는 굳이 신경 안 씀
marquee 태그를 HTML 인젝션 테스트에 매우 유용하게 씀. 거의 아무도 안 쓰는 움직이는 태그라 공격이 먹혔는지 바로 알아볼 수 있음. 비기술자에게도 텍스트가 움직여야 하지 말아야 할 때 움직이는 걸 보여주면 bold 같은 것보다 훨씬 쉽게 위험성을 이해시킬 수 있음
HTML 정화(sanitization)할 때, 이스터에그 용으로 marquee만 화이트리스트에 남겨두고 나머지는 거의 다 막음
Hacker News를 커스텀 aggregator로 보고 있는데, 이 글을 통해 HTML 인젝션에 취약하다는 걸 알아냄. 2020년 글이 화면을 marquee로 돌아다니고 있었음
"야수는 복수의 소용돌이 구름에 둘러싸여 등장할 것. 불신자의 집이 파괴되고, 그들의 태그는 끝날 때까지 깜박일 것이다.” – The Book of Mozilla, 12:10 (about:mozilla)라는 멘트와 함께 지금 Mozilla도 사라지는 중이라는 생각을 함. 마치 종말 느낌임
나는 아직도 Firefox를 기본 브라우저로 사용 중임
대학 기숙사 플로어 웹사이트를 내 컴퓨터에서 돌린 시절을 떠올림. marquee로 997단어 분량의 긴 메시지를 올려뒀었는데, 거기에는 여자, 우울, 철학 등 여러 얘기를 주절주절 적음. 메시지 끝에 ! 표시가 있었고, 그게 숨겨진 페이지로 링크되어 있었음. 결국 누군가 view source로 긴 내용을 읽어보다가 그 페이지 찾아냈음
내 친구가 항상 본인 미들네임에 blink 태그를 둘러서 escaping 누락 및 잠재적 xss 여부를 빠르게 테스트하곤 했음. 예전엔 이런 단순한 방식도 취약점 발견에 꽤나 효과적이었음
Hacker News 의견
예전에 아래 링크와 같은 사이트가 있었던 기억이 있음 https://web.archive.org/web/20201111125145/https://danq.me/2020/11/11/blink-and-marquee/
나는 3,000년 전부터 있었던 느낌의 사람임. 프레임 내비게이션이 나쁜 관행인지에 대해 격렬하게 논쟁하던 시절을 기억함 (iframe이 아니라 프레임임). 프레임을 아는 사람이 혹시 있으면 반가움. AJAX가 나오기 전에는 HTTP 204를 활용해 페이지 새로고침 없이 서버로 메시지를 보내는 방법을 직접 썼음. 2000년대 초반에는 이미지 맵도 작업함 이미지 맵 참고: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/map. 드림위버로 지도 경계선을 여러 날 동안 그려서 클릭 가능한 국가 지도를 완성한 적도 있음. 드림위버 템플릿은 버전 컨트롤을 안 써서 업데이트하다가 수정사항 다 날리고 복구 불가능한 상황도 많았음. input type=image으로 이미지 클릭 위치를 백엔드에서 처리하던 기억도 있음. 모션 JPEG을 이용해 페이지에 스트리밍 업데이트도 구현했고, 아직도 크롬에서는 되고 파이어폭스에서는 약간 불안정함. IE에서 PNG 알파 블렌딩 문제 해결하려고 여러 방법을 시도하다가 결국 ActiveX 버전으로 좀 써먹었으나, 결국 플랫 디자인 유행하면서 필요 없어짐. 네비게이션은 JAVA, Flash, Silverlight까지 다 써봤음. 스페이서 GIF, 조건부 주석, Firebug 등장 이후 개발환경이 얼마나 편해졌는지도 생생하게 기억함. 언제 나이가 들었는지 모르게 시간이 흘렀던 경험임
예전 프레임으로 웹 소프트웨어를 개발했는데 딱히 문제를 느끼지 못했음. 사람들은 접근성을 이야기하지만 구체적으로 어디가 문제인지 아직까지도 잘 모르겠음
IE6의 모든 괴상한 버그와 한계 속에서 지원을 요청하는 고객사를 위해 일했던 기억임. 디자이너가 포토샵으로 둥근 모서리 디자인을 넘기면 매번 한숨 쉴 수밖에 없었음. 그 당시에는 반응형이라는 게 사실 데스크탑 해상도 여러 개 대응하는 정도였음. 모서리를 이미지로 잘라 테이블 셀에 직접 배치해야 했음. 이런 수작업을 하면서 개발자의 정신력이 크게 강화됨을 느낌
포토샵 slice 툴로 이미지를 세밀하게 나누고 gif로 내보낸 후 HTML 테이블에 정확하게 배치하려 애썼던 때를 기억함. 800x600 해상도에 최적화된 디자인이 많았던 시절임. 이 모든 추억이 시간 속에 녹아 사라진 느낌임
지금도 프레임을 몇 번씩 방문하는 사이트가 있음. Open Group/POSIX 사이트는 여전히 프레임을 사용 중임
프레임을 이용해 웹챗을 만든 적이 있음. 위에는 무한 로딩되는 채팅창, 아래에는 input box가 있었고, 메시지 보낼 때는 204로 새로고침을 막았음. 위쪽 프레임에는 user list가 있는 오른쪽 프레임을 reload하는 작은 script도 보낼 수 있었음. 2000년 즈음에 친구 몇 명과 함께 사용했음
전에 순수 marquee 태그만으로 애니메이션을 구현한 사이트를 만들었음. JavaScript는 전혀 사용하지 않았고, 누군가에게 보여주면 다들 놀람 https://udel.edu/~ianozi/
marquee 태그로 제일 좋아하는 트릭은 중첩해서 쓰는 것임. 방향을 다르게 하면, 안쪽 marquee를 반대 방향과 같은 속도로 맞추면 순간 정지했다가 움직이는 효과를 낼 수 있음. 속도를 다르게 하면 더 복잡한 움직임도 구현 가능했음. 이 방법이 제대로 작동하려면 inner marquee에 최대 너비를 설정해줘야 했던 기억임
예전에 blink 태그가 워낙 싫어서 사용하던 브라우저(아마 Netscape)의 바이너리 파일에서 'blink'를 'blonk'로 바꿔서 더 이상 깜박이지 않게 만든 적 있음
나는 이런 식의 바이너리 트윅을 주로 Slack 클라이언트에서 자주 함(Electron 앱이라 엄청 쉬움). 내가 싫어하는 기능(예: 알림 숨기기, 입력 중 신호 차단하기 등)도 쉽게 없앨 수 있음
누군가 blonk 태그를 썼으면 이제는 blonking이 생겼을지 모름. 꽤 재미있는 해킹 같음
바이너리 수정이 꽤 재미있음. "__gnu_warning"를 "__gnu_whining"으로 바꿔서 gets() 경고성 메시지를 없애곤 했음. 버퍼 오버런은 그럴 수도 있지만 대충 만드는 코드에서는 굳이 신경 안 씀
marquee 태그를 HTML 인젝션 테스트에 매우 유용하게 씀. 거의 아무도 안 쓰는 움직이는 태그라 공격이 먹혔는지 바로 알아볼 수 있음. 비기술자에게도 텍스트가 움직여야 하지 말아야 할 때 움직이는 걸 보여주면 bold 같은 것보다 훨씬 쉽게 위험성을 이해시킬 수 있음
HTML 정화(sanitization)할 때, 이스터에그 용으로 marquee만 화이트리스트에 남겨두고 나머지는 거의 다 막음
Hacker News를 커스텀 aggregator로 보고 있는데, 이 글을 통해 HTML 인젝션에 취약하다는 걸 알아냄. 2020년 글이 화면을 marquee로 돌아다니고 있었음
"야수는 복수의 소용돌이 구름에 둘러싸여 등장할 것. 불신자의 집이 파괴되고, 그들의 태그는 끝날 때까지 깜박일 것이다.” – The Book of Mozilla, 12:10 (about:mozilla)라는 멘트와 함께 지금 Mozilla도 사라지는 중이라는 생각을 함. 마치 종말 느낌임
대학 기숙사 플로어 웹사이트를 내 컴퓨터에서 돌린 시절을 떠올림. marquee로 997단어 분량의 긴 메시지를 올려뒀었는데, 거기에는 여자, 우울, 철학 등 여러 얘기를 주절주절 적음. 메시지 끝에 ! 표시가 있었고, 그게 숨겨진 페이지로 링크되어 있었음. 결국 누군가 view source로 긴 내용을 읽어보다가 그 페이지 찾아냈음
내 친구가 항상 본인 미들네임에 blink 태그를 둘러서 escaping 누락 및 잠재적 xss 여부를 빠르게 테스트하곤 했음. 예전엔 이런 단순한 방식도 취약점 발견에 꽤나 효과적이었음
이 코멘트는 현재 공사 중임. 자주 들러서 업데이트 확인 바람
방문자 카운터랑 방명록은 어디에 있는지 궁금함
이 페이지는 어떤 브라우저에 최적화되었는지 궁금함
[NEW] 표시를 잊지 않길 바람