Hacker News 의견들
-
마지막으로 링크된 이슈를 내가 작성했는데, 묘한 데자뷔였음. 그때 문제를 파고들다가 꽤 이상한 동작을 발견했음
기본적으로 Firefox가 해당 웹사이트에 열린 탭 수의 4배만큼 favicon을 불러왔고, 탭을 열거나 닫을 때마다 반복됐음
https://aggressivelyparaphrasing.me/2022/12/12/why-does-my-l...
이 문제는 한참 전에 해결됐으니 증상은 비슷하지만 근본 원인이 다르거나, 아직 오래된 버전을 쓰는 사람들이 있는 걸 수도 있음- WordPress가 404를 정말 느리게 처리하나 봄. 내 로그만 봐도 봇들이 임의 URL로 취약점을 찔러보는 흐름이 꾸준한데, 그럼 제대로 동작하는 게 오히려 놀라움
-
오픈소스 프로젝트이고, GitHub에 기술적 쟁점에 대한 좋은 논의가 있음[1]. 탭을 수백 개 열어두는 식의 특정 사용자 행동과도 관련 있을 수 있지만, iOS 안에 브라우저를 끼워 넣는 복잡성도 분명 영향을 줄 듯함
모래상자에 굴착기를 집어넣어 조종하는 느낌임
[1] https://github.com/mozilla-mobile/firefox-ios/issues/12113- 이런 요청이 어떻게 웹 서버를 박살낼 정도가 되는지도 궁금함. 피드와 favicon을 요청하는 건데 둘 다 CDN으로 캐시할 수 있음
캐시하지 않더라도 HN에서 다른 페이지가 인기글로 올라갔을 때와 비교해 트래픽이 얼마나 크겠나 싶음. 낭비인 건 맞지만 그렇게까지 큰일 같지는 않음 - Chrome 탭을 수백 개 열어도 이런 일은 전혀 안 생김. iOS Safari에서 실수로 탭을 수백 개 열어둬도 이런 일은 없음
명백히 애플리케이션 버그인 걸 사용자 탓으로 돌리지 않았으면 함 - 제목을 보자마자 온 웹을 돌아다니는 LLM 스크레이퍼와 봇들이 떠올랐음. 곧 AIphone에서 직접 돌지도 모름
- iOS의 모든 브라우저는 Apple 브라우저 엔진을 쓰고, Android도 마찬가지라고 생각했음
말하자면 그냥 스킨인 줄 알았음
- 이런 요청이 어떻게 웹 서버를 박살낼 정도가 되는지도 궁금함. 피드와 favicon을 요청하는 건데 둘 다 CDN으로 캐시할 수 있음
-
iOS의 Firefox는 Apple이 휴대폰에서 다른 브라우저 엔진을 허용하지 않으니 Safari에 스킨만 씌운 거라고 생각했음
Android의 Firefox는 플러그인 지원 덕분에 훌륭하지만, 그래도 2021년 이전 UI가 더 좋았음- 형제 댓글들이 꽤 부정적이라 내 경험도 보태자면, 내부에서 무슨 일이 벌어지는지는 모르지만 적어도 재작성 전 몇 년 동안은 Android Firefox의 사용자 경험을 늘 좋게 봤음
휴대폰으로 웹을 보는 걸 좋아하지 않는데도 그나마 견딜 만하게 만들어줬음. 내부 문제는 내가 말할 수 없지만, 당연히 신경 쓸 만한 사안임 - Android의 Firefox는 내게 구세주 같음. 비결은 모바일에서도 uBlock Origin과 NoScript를 설치할 수 있다는 점임
이 둘 없이 웹을 보는 사람을 보면 충격을 받음. 사람들이 자기 주의력을 그렇게 많이 빼앗기도록 놔두는 게 터무니없을 정도임 - Android의 Firefox가 훌륭하진 않음. 수년 동안 사용자 에이전트에 휴대폰의 정확한 모델명이 들어갔음
무능해 보임. 수정하자면 표현이 좀 거칠었고, 특정 직원이 아니라 회사에 대한 말임. Google이 원하는 딱 그 상태임. 독점 문제에선 그럴듯한 부인 가능성을 주면서도 대안은 형편없게 만드는 것 - iOS는 브라우저가 운영체제가 제공하는 WebKit을 쓰도록 요구하지만, 자체 네트워킹 계층을 쓰거나 확장 기능처럼 스크립트 주입을 직접 하는 건 가능함. Orion이 그런 식임
iOS용 Firefox는 예전에 Alamofire를 네트워킹 엔진으로 썼지만 어느 시점에 NSURLSession/URLSession으로 바꿨음. iOS용 Chrome은 Chromium의 네트워킹 스택에서 분리된 Cronet을 쓰는데, 최근 개발은 따라가지 않아서 지금도 그런지는 모르겠음 - iOS의 Firefox는 Safari에 스킨을 씌운 게 맞음. 그래도 일부 추적/광고 콘텐츠는 피하니 어느 정도 다르게 동작하긴 함
그런데 그게 그렇게 골칫거리라면 favicon을 추가하면 됨. 참고로 나는 iOS에서 Firefox로 자주 테스트하지만 이 현상은 본 적 없음
- 형제 댓글들이 꽤 부정적이라 내 경험도 보태자면, 내부에서 무슨 일이 벌어지는지는 모르지만 적어도 재작성 전 몇 년 동안은 Android Firefox의 사용자 경험을 늘 좋게 봤음
-
이 사이트의 저자는 보통 멍청한 짓을 한 대형 상업 기업을 이야기할 때 꽤 애써서 이름을 가리는데, Firefox일 때는 실명을 씀. 흠
- 저자는 자기 고용주를 가림. 최종 사용자로서 발견한 건 이름을 그대로 씀
- 문제의 브라우저를 밝히지 않으면 글 자체가 의미 없어짐
- 피드로 계속 읽어온 입장에선 딱히 그렇지도 않고, 특정 경우에만 그럼
-
예전에 Internet Explorer에서도 비슷한 일이 있었던 기억이 남. favicon을 요청했는데 당시엔 설정해두지 않아서 404 페이지가 반환됐고, 그게 다시 favicon 요청을 유발하는 것처럼 보였음
-
흥미롭긴 함. 사용자 경험만 놓고 보면 iPhone용 Firefox는 정말 훌륭한 앱이고, 몇 년째 내가 선호하는 브라우저임
- 사실상 Safari 스킨이어도 그런가?
-
favicon이 개별 디렉터리의 일부인 건 아님. 그랬다면 멍청한 설계였을 것임
경로별 favicon은 실제로 기능처럼 들림- 실제로 기능임
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes... - 요즘은 아이콘을 지정하는 태그를 정의하면 꽤 쉬움. 파일이 올바른 위치에 있기를 기대하는 방식과는 다름
- 경로별 favicon이 필요한 사용 사례를 적어도 몇 가지 제시할 수 있나?
- 오래전에
pragma no-cache와 리퍼러 확인으로 구현한 적 있음. 완벽하진 않았지만 대부분의 사용자에게는 동작했음 - 그게 바로 글쓴이가 한 요지임
- 실제로 기능임
-
favicon 요청을 완전히 비활성화하는 방법은 https://stackoverflow.com/q/1321878/961353에 몇 가지 제안이 있음
-
iPhone에서 Firefox를 쓰고 있음. 미안함
그래도 아마 생성형 AI 가지고 이것저것 하는 것보다는 에너지를 덜 낭비할 것 같음 -
버그를 찾고 싶은 사람을 위해 코드 위치를 남김: https://github.com/mozilla-mobile/firefox-ios/tree/main/Brow...