IE8 팀 블로그

변화에 대한 대응: IR8 RC 1 에서 Getter/Setter 구문 업데이트

HK Yoo — Fri, 17 Apr 2009 07:35:00 GMT

프로그램 관리자로서 기능의 사양에 대한 글을 쓰는 것은 (꼭 필요한 사항이기 때문에) 정말 즐거운 일입니다. 어떤 사양에 대해서도 프로그램 관리자는 특정 설계의 장점과 단점의 조화 (영어), 고객의 요청에 대한 배려,이용 가능한 피드백이나 원격 측정법 정보 (영어) 등에 대해서 주의 깊게 심사 숙고합니다. 이러한 정보에 근거하여, 무엇을 어떻게 만들지에 대한 가설을 세웁니다. 최선의 계획을 세우기 위한 노력에도 불구하고, 초기에는 불가능했던 몇가지 가설들이 개발과정 중에 변경됩니다. 이렇게 자주 일어나는 변경 영역 중 하나가 웹 표준에 관한 사양입니다. 따라서 현재의 상황을 재평가하고, 필요하면 제품을 변경하기 위해 스케줄에 여유를 가지고 준비했습니다.

개발 주기의 중간 쯤에 웹 표준의 변경에 대응하는 것은 여러가지 이유에서 도전적인 작업입니다. 개발자의 입장에서 엄밀하게 말하면, 기능 변경은 항상 대가를 수반합니다. 일반적으로 그 대가는 검토하여 수정하는데 시간이 필요한 일련의 제품 버그입니다. 그리고 기준이 되는 표준이 변경될 가능성이 있기 때문에 위험이 따릅니다. 변경을 검토할 때는 항상 그 영향을 주의 깊게 심사숙고 해야 합니다.

이 글에서는 웹 표준의 진화에서 최근의 중요한 사건과 Internet Explorer 8 이 어떻게 대응하는지를 설명합니다. 이 글에서는 개발 기간 중의 웹 표준 변경에 대응한다는 복잡한 난제에 대해 독특한 시점을 제공하며, 동시에 곧 출시될 릴리스 후보에서의 변화를 알려드리는 좋은 기회도 될 것입니다.

ECMAScript 3.1

ECMAScript (영어) 는 JavaScript 정의 표준이지만, 최신 업데이트는 10 년 전이었습니다. 그러나 올 초, “ECMAScript 3.1”로 알려진 개정판이 표준화를 위해 급속한 전진을 했습니다. Internet Explorer 8 개발에 착수한 시점에서는 ECMAScript 의 새로운 버전 책정이 나와서, 우리의 개발계획과 통합하는 충분한 시간적 여유가 있다고 예상했습니다. 최근 ECMAScript 3.1 의 급속한 진전으로, 그러한 예상이 가능하게 되었습니다. 특히 ECMAScript 3.1 드래프트 (영어) 에 포함된 기능에 대해 호환성이 없는 것을 Internet Explorer 8 에 탑재하지 않도록 주의를 기울였습니다.

ECMAScript 3.1 에는 웹 개발을 쉽고 보다 강력하게 만들기 위해, 많은 JavaScript 언어 확장이 포함되어 있습니다. 이러한 기능의 하나가 JSON 지원으로, IE 8 의 네이티브 JSON API 를 ECMAScript 3.1 드래프트에 포함된 JSON API 와 동일하게 해야 한다고 결정했습니다. 또 주목할 만한 기능은 드래프트에 포함된 getters 와 setters 지원이었습니다.

DOM 프로토타입

최근 수개월간, JavaScript 프로토타입 개념을 DOM 에 도입 (영어) 하기 위해, DOM 과 JavaScript 의 호환성을 더 높이기 위한 기능을 연구했습니다. DOM 속성을 이용하여, 실력 있는 웹 개발자는 HTML 요소나 새로운 기능을 가진 DOM 개체를 쉽게 확장할 수 있습니다. 보다 고도의 라이브러리나 추상화 층을 개발하거나 또는 기본 제공 속성이나 메서드를 독자적으로 구현한 것과 바꾸는 것도 가능합니다. 이것은 유력한 JavaScript 전문가와 많은 사람들에게 가장 강력하게 요구되던 프로그래밍 기능의 하나입니다. 이 기능의 매우 중요한 부분 중 하나가 DOM 의 getter/setter 속성 (영어) 입니다.

버전 3.1 이전의 ECMAScropt 에는 getter/setter 속성 개념은 포함되어 있지 않았습니다. 그러나 일부 JavaScript 의 구현에서는 몇가지 IE 이외의 주요한 브라우저와 프로그래밍환경에서 지원된 (영어) API 를 사용하여 지원되었습니다. 우리가 DOM 프로토타입 지원을 위한 작업을 시작 했을 때에는 사실상의 표준 (de facto)이 되는 getter/setter API 를 구현하는 일이 었습니다.

ECMAScript 3.1에서는 초기 단계에서 getter/setter 속성을 포함하는 것이 결정되었지만, 사실상의 표준 대신보다 유연성 높은 API 를 사용합니다 (영어)(Word 형식). 이 결정은 이미 사실상 표준 getter/setter API 를 지원하는 브라우저를 포함한, 모든 주요한 브라우저 공급업체가 동의했습니다. ECMAScript 3.1 책정은 전진했지만, 일부 브라우저 공급업체에는 변화가 생겨, 우리는 중대한 선택을 해야만 했습니다. 예상하지 못한 변환에 대해, ECMAScript 3.1 의 DOM 에의 getter/setter API 구현을 추구해야 할지, 아니면 현재 완성된 기능으로 출시하고, ECMAScript 3.1 API 는 이후 버전에 포함해야 할지 고민했습니다.

그 대답은 웹 개발자에서 무엇이 최선인지를 생각했습니다. 개발자는 상호 운용성 (영어)을 필요로 하고, ECMAScript 3.1 에서 보여준 것처럼, getters/setters 를 지원하여 장기적인 상호 운용성이 제공됩니다. Beta 2 공개는 불과 몇 주 전에 결정되었고, 릴리스 품질을 저하시킬 수는 없었습니다. 게다가 Beta 2에서는 기능을 삭제하는 것 (RC1 까지 그대로 둠)보다는 현재의 구현 (사실상의 표준 getter/setter) 대로 출시하고 웹 개발자에게 유효성 검사 받아서 버그를 잡는 것이 중요하다고 판단했습니다. 피드백을 주신 것에 감사드리며, 이렇게 하여 호환성에 대응할 수 있는 충분한 시간을 가질 수 있었습니다.

표준이 우선

Internet Explorer 8 릴리스 후보에서는 단지 고품질의 DOM 속성 구현하는 것 뿐만 아니라, getter/setter 구현을 ECMAScript 3.1 드래프트 표준에 따라서 구현하도록 변경할 수 있던 것을 기쁘게 생각합니다. 출시를 앞두고, JavaScript 엔진이나 DOM 은 ECMAScript 3.1 의 확장된 모든 기능을 지원하지는 않지만, 웹 개발자가 Internet Explorer 8 의 DOM 대상으로 getters 와 setters 를 추가하여 기술한 코드는 앞으로도 계속 기능합니다. 왜냐하면 그러한 코드는 웹 표준에 근거하기 때문입니다.

IE8 의 새로운 기능들에 기대가 큽니다. 시작하는데 도움을 드리기 위해 DOM 프로토타입과 getter/setter를 소개하는 글을 썼습니다. (새로운 구문은 곧 출시될 릴리스 후보 버전에서 일반적으로 이용 가능합니다)

아마 알고 계실지도 모르지만, MSDN 도 Internet Explorer 8 에서 프로토타입 이용 가능(영어)이 반영되었습니다.

DOM 속성과 getters/setters 에 의해, 매우 세련된 프로그래밍 가능성이 커집니다. 앞으로 블로그에서 IE8에서는 어떠한 시나리오가 가능하게 되는지 세부 사항을 설명할 예정입니다. 기능을 사용하여 이미 세련된 시나리오를 구현하고 있다면, 꼭 댓글을 남겨 주세요.

변화에 대한 대응이라는 주제로 돌아와서, 먼저 웹을 위한 가장 좋은 사양이라고 생각했던 것이 제품 개발 도중에 변경될 수도 있습니다. Internet Explorer 8 의 DOM 의 getters/setters에 대한 제 경험이 그것을 개인적으로 증명하고 있습니다. IE8 를 완성한 후에도 우리는 적확한 정보를 수집하고, 고객의 피드백에 귀를 기울여 제품을 적절하고 유용하게 변경할 예정입니다. 우리 팀은 웹 표준과 상호 운용성을 달성하기 위해서 웹 표준 지원에 많은 노력을 하고 있으며, 최종적으로는 웹 개발자의 생산성 향상에 기여할 것입니다. ECMAScript 3.1 채용은 그것을 위한 커다란 전진입니다.

-Travis Leithead
프로그램 관리자

* 1/15 업데이트: 위에서 소개한 링크에서 참조할 수 있는 몇가지 예에는 속성 기술자가 “getter”속성과 “setter”속성이 된 경우가 있기 때문에 주의해 주십시오. 이러한 기술자는 최근에서야 “get”과 “set”으로 단순화 되었습니다. (이것은 ES3.1 언어 이외 부분과의 일관성 때문) 이 변경은 현재의 프로그램 이전에는 반영되었지만, 문서 업데이트는 작업 중입니다.

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오.

업데이트 일: 2009 년 1 월 13 일

영어 원본 : Responding to Change: Updated Getter/Setter Syntax in IE8 RC 1 (영어)

사용자 보조: IE8 RC의 ARIA 지원 강화

HK Yoo — Fri, 17 Apr 2009 05:59:00 GMT

Internet Explorer 의 프로그램 관리자인 Tony Ross 입니다. IE 팀은 IE8 를 가능한 가장 사용하기 쉬운 웹 브라우저가 될 수 있도록 개발하고 있습니다. 또 상호 운용성을 향상하여, 웹 개발자가 편리하게 이용할 수 있도록 주력하고 있습니다. 동적인 웹 컨텐츠에의 사용자 보조를 구현하는 구문인 ARIA 지원 강화를 위해서 RC (릴리스 후보)에서 변화된 것을 소개합니다. 이전의 IE에서 구현되었던 것과 현재 구현 가능한 것, 그리고 이런 변화가 전체적으로 어떤 의미가 있는지 소개합니다.

이전 IE에서 구현되었던 것

ARIA 지원은 Beta 1에서 추가되었지만, 브라우저 모드에 의존하는 구문의 상위가 존재했었습니다. IE8 표준모드에서는 표준 정의된 구문을 사용하여 스크립트에서 ARIA 특성에 액세스 할 수 있었습니다:

value = elm.getAttribute("aria-checked");

IE7 모드와 Quirks 모드 등의 상호교환모드에서는 특성 이름을 camelCased에서 지정해야 했습니다.

value = elm.getAttribute("ariaChecked");

구문의 차이는 미묘하게 보일지 모르지만, 이 차이는 IE 특성과 속성 취급 방법의 결과입니다. 속성은 스크립트의 개체로서 존재하며, elm.property 에 속합니다. 개발자의 편의를 위해 IE 는 특성을 속성에 자동적으로 대응시킵니다. 네이티브 특성의 이름에 대시가 포함되어 있으면, IE 는 허용 가능한 속성 구문을 구성하도록 조정합니다:

value = elm.ariaChecked;

이 조정이 없는 경우, 각각의 대시는 스크립트 인터프리터에 의해 마이너스 기호로서 다루어집니다.

value = elm.aria-checked; //대시를 포함한 속성에 액세스 하고 싶다

value = elm.aria – checked; //스크립트의 인터프리터에는 대시가 이와 같이 보인다

이전 버전의 IE 와 상호교환 모드의 IE 8 은 속성과 특성의 양쪽 모두에서 같은 이름을 사용합니다. 그 결과, 속성 이름의 조정은 getAttribute 구문에도 같이 영향을 줍니다. 이 조정은 ARIA 에 포함된 것 뿐만이 아니고, 모든 대시를 포함한 이름의 네이티브 특성에 적용됩니다. IE 는 인식할 수 없는 특성은 바꾸지 않고, 이름을 “foo-bar”와 같이 그대로 남깁니다. IE8 표준모드는 속성과 특성에서 각각 이름을 유지하기 때문에 전체적으로 이러한 충돌을 피할 수가 있습니다.

현재 구현 가능한 것

처음에는 위와 같은 문제에 대처하기 위한 IE7 모드나 Quirks 모드에서의 표준 ARIA 구문 지원은 실시하지 않았습니다. 이러한 모드에서는 이전 버전과의 호환성이 가장 중요하기 때문에 그 동작의 변경에는 신중했습니다.

그 이후, ARIA 를 위한 다른 구문을 갖는 것에 대해 우려하는 피드백을 받았습니다. 이 피드백은 웹 개발자, 사용자 보조 기술의 공급업체, 표준에 대해 커뮤니티 멤버들로 부터 전해졌습니다. 그들의 우려는 주로 IE8 표준모드에 대응하지 않는 페이지에 대한 것으로 이러한 페이지에서 ARIA 를 지원하려면, 지원 대상의 구문 중 하나를 선택하거나 또는 양쪽 구문을 지원하기 위해서 노력해야 한다는 것이었습니다.

이러한 피드백에 근거하여, IE 의 ARIA 핸들링을 다시 한번 증명했습니다. 오래된 버전의 IE에서는 ARIA 를 지원하지 않습니다. ARIA 특성은 미지의 것으로 취급되어, 그 이름을 camelCase 표기에 변경하지 않습니다. 이것은 이 버전에서는 스크립트가 표준화 된 구문을 사용하여 ARIA 를 조작할 수 있는 것을 의미합니다. 다만 Microsoft Active Accessibility (MSAA)(영어) 와 같은 API 를 경유하여 정보가 공개되지 않습니다.

피드백을 검토하는 과정에서 이러한 정보를 추가한 결과, IE8 의 동작을 최선의 선택사항으로 변경하기로 결정했습니다. 어떤 모드에서도 IE8 는 ARIA 특성 이름에 포함된 대시를 유지합니다. 이 변경의 일부로서 앞에서 말한 것과 같은 충돌을 피하기 위해, camelCase 표기의 ARIA 속성을 열거했습니다. IE8 의 ARIA 지원을 위해서는 표준화 된 구문만 잘 사용하면브라우저 모드에는 관계없게 되었습니다.

value = elm.getAttribute("aria-checked");

변경의 의미

웹 개발자 대상

변경에 의해, ARIA 이용이 쉬워집니다. 복수의 ARIA 구문 지원이 필요 없습니다 .

단일 구문은 IE8 의 모든 모드를 통해서 기능합니다
단일 구문은 다른 브라우저와의 상호 운용성이 있습니다
단일 구문은 표준과 일치합니다

최종 사용자 대상

이 변경에 의해, IE8 의 모든 모드에서 ARIA 규격이 지원되어, 더 많은 사이트가 IE8 에서 액세스하기 쉬워질 것입니다.

ARIA

변경에 의해, 개발자가 다른 구문에 주위를 기울일 필요가 없고, 표준화된 ARIA 구문 보급에 도움이 될 것입니다. .

결론

IE 8에서는 Beta 1에서 복수 구문에 의해 ARIA 를 지원했지만, 표준과의 일치를 위해 하나로 줄였습니다. 이러한 변경으로 개발자, 최종 사용자, 그리고 ARIA 자신에게 종합적으로 좋은 영향을 줄 것이라고 믿습니다. 이러한 결정에 대해 항상 중요한 역할을 해주시는 커뮤니티의 피드백에 감사드립니다.

Tony Ross
프로그램 관리자

업데이트 일: 2009 년 1 월 16 일

영어 원본 : Accessibility: Improved ARIA Support in the IE8 RC (영어)

IE8 보안 VII: ClickJacking 방지

HK Yoo — Fri, 10 Apr 2009 05:02:25 GMT

Internet Explorer 8을 계획했었을 때, 보안팀은 현실에 일어나는 일반적인 공격과 공격자가 무엇을 다음 주의대상으로 하는지 경향을 분석했습니다. IE8 개발 과정에서 새로운 종류의 위협이 있는 곳을 알기 위해서, 보안연구 커뮤니티와 긴밀히 협력했습니다. 가장 흥미로운 웹 응용 프로그램의 취약성 중 하나는 보안연구가 Jeremiah Grossman 이 웹 취약성의 "잠자는 거인 (영어)"이라고 부른 Cross Site Request Forgery (영어)(RSRF)입니다. Jeremiah 가 보여준 것처럼, 일반적인 해결 방법이 존재하지 않기 때문에 CSRF 공격을 막는 것은 어렵습니다. 브라우저 보안모델의 구조적인 기반은 여러 웹 사이트가 동시에 상호작용 가능하여, 무관한 웹 사이트 사이를 끊김 없이 이동할 수 있도록 설계되었습니다. 그러나 이것들은 확실히 CSRF 공격이 이용하려는 기능 그 자체입니다. 최종 사용자 PC에서 개인적인 정보나 그 외의 높은 가치의 정보 저장 장소가 인기 있는 웹 응용 프로그램의 변화에 따라, CRSF 공격 (영어) 또는 그 외의 웹 응용 프로그램의 취약성으로 이어질 수 있습니다.

Internet Explorer 8 을 설계할 때 , CSRF 공격에 대한 브라우저의 공격 대상영역을 증대되지 않도록 세심한 주위를 기울였습니다. 일례로서 IE8 의 새로운 XdomainRequest 개체 (영어) 는 서버의 명시적인 허가 아래에서 크로스 도메인의 통신을 허가하지만, 새로운 유형의 CSRF 가 가능하지 않는 특정 제한을 포함합니다. 최종 사용자가 이용하지 않을 때는 민감한 정보를 취급하는 웹 사이트에서 로그오프 하거나 독립된 InPrivate Browsing 세션을 사용하여 CSRF 공격의 위협을 줄일 수 있습니다. (InPrivate 세션의 Cookie 저장 영역은 비어 있는 상태에서 시작되어, 저장된 Cookie 가 CSRF 공격으로 재사용되지 않습니다)

그렇지만 궁극적으로는 웹 응용 프로그램은 CSRF 취약성을 방지하도록 구축되어야 합니다. 최선으로 설계된 웹 응용 프로그램에서는 피해자인 사용자가 의도적으로 송신한 것인지 부정한 리퀘스트를 식별할 수 있는 챌린지 토큰 (영어) 이나 거기에 유사한 방법을 사용하여, 자신을 보호합니다. 하지만, 챌린지 토큰이나 거기에 유사한 방법은 취약성에 빠지기 쉽습니다. 가장 큰 취약성은 크로스 사이트 스크립팅(XSS)(영어)입니다. 토큰으로 보호된 웹 응용 프로그램에 크로스 사이트 스크립팅의 취약성이 있으면, 보안 토큰이 탈취되어 CSRF 공격이 가능해집니다. 다행히, Internet Explorer 8 에는 XSS 필터나 그 외의 기능 (영어) 이 있어, CSRF 를 막기 위한 챌린지 토큰의 탈취에 사용될 XSS 공격 방지에 도움이 됩니다.

작년 가을, 연구원인 Robert Hansen 과 Jeremiah Grossman 은 ClickJacking (영어) 으로 알려진, CSRF를 가능하게 하는 제 2의 요소를 공개했습니다. ClickJacking 은 사용자가 눈치채지 못하도록 애매하게 숨겨진 웹 요소를 클릭하도록 속이는데 사용되는 다중 테크닉(multiple technique) (영어)을 포함한 용어로 의도하지 않는 매매거래가 발생할 수 있습니다. 악성의 ClickJacking 공격은 사용자에 거래 확인을 요구하고 CSRF 를 막으려는 구조를 회피합니다. 예를 들면, Cookie 를 인증에 사용하고, 한번의 클릭으로 구입을 할 수 있는 단순한 웹 쇼핑몰 (영어)에 대해 생각해 봅시다.

악의가 있는 사이트 (영어)를 웹의 어딘가에서 생성하여 , 정상적인 쇼핑몰에서 표적이 되는 페이지를 IFRAME 에 의해서 꺼냅니다. 그리고 프레임내의 중요한 요소를 혼동하기 쉬운 텍스트나 이미지로 가립니다.

사용자가 속아서, 웹 쇼핑몰 페이지라고 생각하지 못하고 클릭할지도 모릅니다. 이 때 사용자가 쇼핑몰에 로그인 한 상태였을 경우, 의도하지 않는 주문이 발생합니다.

분명히, 이것은 매우 단순한 ClickJacking 공격으로, 보다 세련된 종류의 공격도 존재합니다.

ClickJacking에 대해서는 다양한 완화책 (영어) 이 만들어졌지만, 어떤 완화책에도 호환성이나 사용자 경험에 영향 혹은 기존 표준에 대한 변화의 필요성 등 절충되는 조건이 있습니다. 현시점에서, 가장 단순하고 가장 넓게 이용되는 ClickJacking 공격을 깨기 위한 메커니즘은 frame-busting 으로 공격받기 쉬운 페이지가 프레임내에서 표시되지 않도록 하는 단순한 동작을 의미 합니다. 그러나 전형적인 frame-busting (영어) 의 메커니즘은 스크립트에 의존, 그 결과 다양한 방법으로 회피됩니다.

12 월 초순에 다른 브라우저 공급업체에 개시한 것처럼, Internet Explorer 8 출시 후보에는 공격받기 쉬운 페이지를 프레임내에 표시되지 않도록 선언하여 웹 응용 프로그램이 ClickJacking 위험성을 줄일 수 있는 새로운 옵트인 메커니즘을 도입했습니다.

웹 개발자는 페이지가 프레임내에 표시되지 않도록 제한하기 위해서, X-FRAME-OPTIONS 라는 이름의 HTTP 응답 헤더를 HTML 페이지와 함께 송신할 수 있습니다. X-FRAME-OPTIONS 값에 DENY 토큰이 포함되어 있으면, 그 페이지가 프레임내에 포함된 경우에 IE8 는 페이지의 표시를 실시하지 않습니다. 값에 SAMEORIGIN 토큰이 포함되어 있으면, X-FRAME-OPTIONS 머리글을 포함한 페이지의 원래 서버와 프레임의 톱 레벨 문맥의 원래 서버가 다른 경우에 IE 는 페이지 표시를 하지 않습니다. 예를 들어, http://shop.example.com/confirm.asp 가 DENY 지시 자식을 포함하고 있으면, 부모 프레임 장소가 어디에 있는지 그 페이지 서브 프레임에는 표시되지 않습니다. 그것과는 대조적으로, X-FRAME-OPTIONS 머리글에 SAMEORIGIN 토큰이 포함된 페이지는 바르게 http://shop.example.com 를 원래 서버로 하는 페이지의 프레임내에 표시할 수 있습니다.

X-FRAME-OPTIONS 의 정책에 의해 표시가 차단되었을 경우, 제한된 설명과 프레임을 새로운 윈도우에서 열기 위한 링크가 표시된 로컬의 오류 페이지가 나타납니다. 서브 프레임 대신 새로운 윈도우에서 표시되면, 컨텐츠는 ClickJacking의 영향을 받지 않습니다.

중요한 정보를 취급하는 anti-CSRF 페이지를 보호하기 위해서 X-FRAME-OPTIONS 지시 자식을 사용하여 웹 개발자는 IE 8 사용자의 웹 응용 프로그램을 통한 공격을 즉시 줄일 수 있습니다. ClickJacking 위협에 대한 호환성이 높고 배포 하기 쉬운 방법으로 X-FRAME-OPTIONS 지시 자식이 다른 브라우저에도 구현되기를 기대합니다. 장기적으로 보면 보안연구가나 웹 표준화 조직은 브라우저에서 구현되는 웹 응용 프로그램의 보안정책의 설계가 진화를 계속한다고 예상합니다. 그들과 함께, 장래의 ClickJacking방어를 차기 버전의 브라우저는 보다 큰 보안정책 기능의 문맥 내에 형태 만드는 작업에 참여할 수 있기를 기대하고 있습니다.

감사합니다.
Eric Lawrence
프로그램 관리자

업데이트 일: 2009 년 1 월 27 일

영문 원본 : IE8 Security Part VII: ClickJacking Defenses

브라우저 성능 평가의 일반적인 문제

HK Yoo — Fri, 10 Apr 2009 04:59:00 GMT

IE 팀에서 브라우저 성능을 담당하고 있는 프로그램 관리자 Christian Stockwell 입니다.

웹 사이트와 웹 브라우저의 전체적인 성능을 측정하는 일은 사용자가 경쟁 관계에 있는 브라우저를 비교하기 위해서, 개발자가 다운로드 시간이나 응답을 최적화하기 위해서, 브라우저 공급업체가 코드 변경과 성능 변화의 관련성을 조사하기 위해, 그리고 웹 사이트 성능에 대해 관심 있는 모든 사람들에게도 중요한 일입니다.

이 글은 브라우저 성능 테스트에 영향을 주는 문제나 브라우저 성능을 효율적으로 측정하기 위한 기술에 대해 기술할 예정입니다.

브라우저 성능 측정

일반적인 성능 테스트의 접근 방식은 특정 벤치마킹 제품군 (패키지)에 집중합니다. 이것은 유효한 측정 방법이지만 소수를 타겟으로 하는 벤치마크만을 의존하기 때문에 사용자가 느끼는 성능을 잘못 이해할 가능성이 있습니다. 브라우저 성능을 측정하는 가장 정확한 방법에는 실제로 잘 행해지고 있는 브라우징 시나리오측정이 포함되어야 합니다. 실제 사이트에서 측정하면, 다른 벤치마크에서는 추출할 수 없는 요소를 포착할 수 있어 종합적인 측면에서의 성능을 알 수 있습니다. 실제 사이트에 대해서 브라우저 테스트를 실시하는 것은 몇가지 중요한 도전이 필요하지만, 이 글은 우리가 개발 과정에서 IE 성능을 효율적으로 측정하기 위해 사용한 해결 방법을 보여줍니다.

먼저, 성능 벤치마크를 유효하게 실시한다는 것은 생각보다 많은 어려움이 있다는 것을 미리 말해 두고 싶습니다. IE 팀은 매일 수천개의 독립적 테스트를 여러 서버에서 실시하기 위해, 수백 대의 데스크톱과 랩톱에서 유효성 검사와 성능 측정을 위한 실험 환경을 구축하기 위한 작업에 많은 노력을 했습니다. 그리고 성능 데이터 안정성, 정밀도 명확성을 개선하기 위한 새로운 아이디어를 매일 만들었습니다. .

브라우저 성능 측정의 도전 중 하나는 브라우저가 사용되는 방법이 방대하다는 것입니다. 사용자는 매일 다양한 사이트를 브라우즈징하며, 그 중에는 Flicker 와 같은 컨텐츠량이 많은 사이트에서 Google과 같이 최소화된 사이트도 포함되어 있습니다. Windows Live Hotmail 과 같은 상호작용 목표 AJAX 사이트도 방문하고, Craigslist와 같이 단순하고 정적인 HTML 사이트도 방문합니다. 또한 미션 크리티컬한 응용 프로그램에서 업무용으로 사용하는 사람도 있습니다.

이러한 각각의 카테고리 사이트 성능은 많은 경우 브라우저내의 다른 하부구조에 의존합니다. 예를 들어 이미지가 많은 사이트에서는 브라우저의 다운로드와 이미지의 배포 속도에 의존합니다. 대조적으로, 단순한 사이트의 성능은 HTML 렌더링 속도가 주요한 요소가 됩니다. 다른 예로서 AJAX 웹 사이트의 성능은 JavaScript 엔진과 CSS 엔진, DOM가 얼마나 긴밀히 통합되었는지, 각각의 하부구조가 속도 이상으로 중요한 요소입니다. Flash 나 Silverlight 와 같은 타사의 컨트롤이 포함되어 있으면, 많은 경우 성능은 컨트롤이 얼마나 효율적으로 브라우저와 통합되었는지 관련합니다.

여기서 소개하는 접근 방식은 IE8에서 행해진 성능 개선 배경과 관련되었으며, 또 우리의 개발 공정에 대해 알려드릴 것입니다. 이것들을 통해서, 이 글에서 브라우저와 사이트의 성능을 측정하여 검토하는 방법을 향상시키기 위한 아이디어를 찾기 바랍니다.

캐싱 동작(Caching Behavior)

모든 브라우저는 기본적으로 네트워크에 의존하며, 어떠한 테스트에서도 성능 측정을 충분히 실시하려면 그 현실이 반영되어야 합니다.

브라우징 성능에 영향을 줄 수 있는 인터넷 성질 중 하나는 인터넷을 구성하는 다양한 수준의 서버 컨텐츠 저장 방법입니다. 이러한 저장 동작은 캐싱이라 불립니다.

브라우징 성능 측정에서는 www.microsoft.com 을 표시할 때 브라우저는 이 컨텐츠를 회사내의 프록시 서버나 로컬 서버, 전세계의 수많은 서버 등 여러 서버에 요청합니다 .

브라우징 스피드를 향상하고, 웹 페이지를 제공하는 작업을 분산화하기 위해, 표시한 페이지의 일부를 일시적으로 저장하여, 다른 사용자가 그 일부를 보다 빨리 취득할 수 있도록 합니다. 예를 들어 여러분이 아침에 제일 먼저 뉴스를 보기위해, www.msnbc.com (영어)를 방문하는 경우, 먼저 회사의 프록시 서버에 요청합니다. 프록시 서버는 최종적으로 원격지 서버에서 페이지를 취득전에 로컬 서버에 그 요청을 중계합니다. 페이지 취득이 완료하면, 프록시 서버 또는 로컬 서버는 컨텐츠의 일부를 저장합니다. 이 때 동료인 Tracy 가 10 분 늦게 출근하여 www.msnbc.com (영어) 에 액세스하면, 원격지 서버 대신 프록시 서버에서 직접 컨텐츠를 취득하여, 사이트를 표시하는데 필요한 시간이 현저히 단축되어 Tracy 는 매우 행복해집니다.

마찬가지로 여러 브라우저에서 성능을 측정하는 경우, 캐싱 영향을 고려하는 것이 중요합니다. 예를 들어 첫번째 브라우저의 10 개 탭에서 10개의 다른 웹 사이트를 연 뒤, 두번째 브라우저에서도 같은 10 개의 탭을 열면, 두번째 브라우저가 빠르다는 다른 결과를 얻을 수 있습니다. 실제로는 이러한 차이는 주로, 브라우저가 처음에 페이지를 요청했을 때에 컨텐츠가 가까운 서버에 저장되어 있는지에 따라 달라집니다..

서버가 어떻게 캐시 하는지를 엄격히 제어하는 것은 어렵지만, 성능 측정의 일반적인 원칙은 어떠한 경우도 한번의 측정으로 끝내서는 안됩니다. 상위에서의 캐싱 영향을 따로 측정하려는 것이 아니면, 성능 데이터의 수집을 시작하기 전에 측정하고자 하는 사이트를 한 번은 방문해야 합니다. 실제로는 프록시는 사용자 에이전트 (브라우저) 마다 컨텐츠를 캐시하므로, 테스트를 원하는 사이트의 각각을 테스트 하는 모든 브라우저로 방문해야 합니다.

여기까지의 캐시 동작 소개는 단순화 한 것입니다. 보다 자세한 정보가 필요하면, 동작이 세부 사항에 해설된 중요한 리소스가 다수 있어, HTTP 프로토콜 규격 자체도 그 하나입니다. HTTP 프로토콜 규격 (영어) 가 매우 좋은 자료입니다.

샘플 양

정확하게 말하면, 브라우징 성능에 영향을 주는 요소는 매우 다방면에 걸쳐있기 때문에 성능 측정 횟수에 따라 그 결과에 큰 차이가 있는 경우가 있습니다.

앞에서 얘기한 것과 같이, 성능 측정의 일반적 원칙은 어떠한 경우도 한 번의 측정으로 끝내서는 안됩니다. 이 원칙을 「어떤 경우에도 충분한 회수 측정을 해야 한다」라고 확장하고 싶습니다. 「충분한 회수」가 무엇을 의미하는지에 대해는 신뢰구간이나 표준편차, 그 외의 통계학상의 흥미로운 응용에 근거한 여러 가지 의견이 있습니다.

우리가 수집한 다수의 성능 데이터에 관해서는 대부분의 경우, 실용적인 접근 방식을 채용하여 비교적 복잡한 과제를 피할 수 있었습니다. 유효성 검사 환경에서는 7~ 10 회의 반복으로 안정성있는 데이터 집합을 수집합니다. 다만 유효성 검사하는 환경 제어가 보다 불충분한 경우는 보다 많은 회수가 필요합니다.

성능 데이터를 수집되면, 결론을 이끌기 위해 결과를 요약해야 합니다 . 산술평균 (영어), 조화평균 (영어), 기하평균 (영어), 또는 그 외의 어떠한 방법을 사용하는 경우여도 데이터 요약 방법에 따라 결과가 달라 질 수 있다는 것을 충분히 이해하고 있어야 합니다.

예로서 두 개의 브라우저에서 단일 웹페이지를 표시하는 테스트에서 수집된 점수 데이터입니다.

	Browser A	Browser B
Sample 1	1.0	2.0
Sample 2	1.0	2.0
Sample 3	1.0	2.0
Sample 4	1.0	2.0
Sample 5	10.0	4.0
Arithmetic Mean	2.8	2.4
Geometric Mean	1.6	2.3
Harmonic Mean	1.2	2.2

억지로 맞춘 듯한 이 예에서 명확한 점은 데이터를 어떻게 요약하는지에 따라서 데이터 해석이 바뀐다는 것입니다. 이 예에서는 산술평균은 브라우저 B 가 브라우저 A 보다 빠르다고 보여주는 것에 반해, 기하평균과 조화평균에서는 그 반대의 결과가 나왔습니다.

대역폭 경쟁(Bandwidth Competition)

네트워크를 다른 사용자와 공용하는 것은 분명히 웹 브라우저가 같은 동작을 하는데 보다 많은 시간을 필요로 합니다.

Microsoft 와 같은 대기업에서 일을 하는 경우의 이점 중 하나는 직원이 다수이기 때문에 특정 현상을 측정가능하고 신뢰할 수 있습니다. 예를 들어 페이지 다운로드에 필요로 하는 시간을 하루 동안의 통계를 살펴보면 많은 Microsoft 직원은 오전 8 시에서 오전 9 시의 사이에 일을 시작하여 오후 5 시에서 오후 6 시의 사이에 퇴근하는 것이 확실합니다.

그 이유로서 명확하게 말할 수 있는 것은 많은 Microsoft 직원은 하루 종일 거의 끊임없이 네트워크에 액세스합니다. MSDN 를 참조하거나 SharePoint 문서를 읽거나 최신 Xbox 게임 테스트를 실시하는 등의 대역폭을 함께 사용합니다. 그러한 공유는 브라우저 성능을 측정하려면 회사 전체가 업무를 시작하여 전자 메일을 송신하기 시작하는 오전 9 시 대신, 오전 6 시에 가는 것이 일관된 결과를 확실히 얻을 수 있는 것을 의미합니다.

기업에 따라서 가능한 네트워크 구성 종류도 폭넓기 때문에 대역폭 경쟁 영향을 예상하는 일은 어렵습니다. 결과를 왜곡하지 않도록 권장하는 방법은 직장에서 성능 데이터를 수집하는 경우에는 주요 업무 시간 이외로 성능 데이터 수집을 하는 것입니다.

자택에서 성능 데이터의 수집을 실시하는 경우도 가족이나 주변 사람과 대역폭을 공유하는 것이 됩니다. 그러한 경우, 영업시간이나 또는 이른 아침 등 다른 사람이 브라우징을 많이 하지 않는 시간대에 맞춰 측정하면 좋을 것입니다.

리소스 경쟁

컴퓨터 리소스에 대한 응용 프로그램 사이의 경쟁도 대역폭의 경쟁과 같이 브라우징 성능에 크게 영향을 줍니다.

여러 응용 프로그램이 동일한 외부 응용 프로그램이나 플랫폼에 의존하는 경우, 이것은 특히 틀림없는 사실입니다. 예를 들어, 안티 바이러스 제품에는 여러 브라우저와 다른 방법으로 통합가능 하지만, 그 성능에 주는 결과는 불명확합니다.

두개의 브라우저를 병렬하여 테스트 하면, 정확하지 않은 결과가 되는 경우가 있습니다. 예를 들어, Windows 플랫폼에서는 아웃 바운드의 소켓 요청은 동시에 10개 까지 제한됩니다. 게다가 요청은 접속 요청이 성공 또는 실패할 때까지 차례를 대기합니다. 두 개의 브라우저를 병렬하여 테스트하면 이러한 제한에 쉽게 이릅니다. 그 결과, 어느 쪽이든 한쪽의 브라우저가 수 밀리초 빨리 실행을 시작하여 우위가 되는 결과가 나옵니다.

여기에서는 두개의 단순한 예를 들었지만, 그 이외에도 문제는 확실히 존재합니다. 이것에 대해 보다 세부 사항에는 논하지 않지만, 브라우징 성능을 측정할 때의 복수 응용 프로그램의 실행에 대해서 명료한 조언이 있습니다.

최악의 경우에도 다른 응용 프로그램에서의 영향을 줄이기 위해 다음 두 단계를 거쳐야 합니다.

작업 표시의 우측 통지 영역에만 표시되는 것을 포함하여, 열려 있는 모든 응용 프로그램을 종료한다.
이것은 다른 응용 프로그램이 네트워크를 사용하지 않기 위해 특히 중요합니다.
커멘드 프롬프트에서 다음의 코맨드를 실행하면, 테스트시의 시스템동작을 줄일 수 있습니다.

서버 상호작용(Server Interaction)

컴퓨터나 네트워크 리소스 공유에 의한 간섭을 넘어도 성능 결과는 액세스 대상의 서버 내부적인 동작으로 영향을 받습니다.

성능 측정의 포괄적인 원칙의 하나는 테스트를 통해서 일정한 상태를 유지하는 일입니다. 캐시 관리에서는 성능 데이터 수집 전에 상위의 서버를 기존 상태에 해야 하는 일로 또 네트워크에서는 외부적인 요소의 영향을 줄이기 위해 일정한 환경에서 테스트를 하도록 노력합니다.

벤치마크에 영향을 주는 응용 프로그램 설계 특성의 예로서 온라인 뱅킹 응용 프로그램을 채택합시다. 보안상의 이유로, 뱅킹 응용 프로그램은 적절한 자격 정보가 제시되었을 경우에만 계정 정보에의 액세스를 허가합니다. 두 개 (또는 그 이상)의 브라우저를 이 온라인 뱅킹 웹 사이트에서 벤치마크 테스트 한다면, 어떤 브라우저에 대해서도 응용 프로그램을 확실히 동일한 상태로 하는 것이 중요합니다. 설계상, 대부분의 온라인 뱅킹 응용 프로그램은 동시에 두 개의 세션에서 사용자가 로그인 할 수 없습니다. 한편으로 로그인 하면, 한편에서는 로그 아웃 됩니다. 두번째 브라우저 테스트를 시작하기 전에 웹 응용 프로그램 상태를 초기화 하는데 실패하면, 서버 기반의 응용 프로그램은 두번째 요청을 분석하여, 최초의 세션을 종료하고 새로운 세션을 시작하기 위해 여분의 시간이 필요합니다.

이와 같이 시작 처리와 종료 처리는 벤치마크에 영향을 줍니다. 이것은 온라인 뱅킹 응용 프로그램에 한정된 것은 아니기 때문에 이러한 요소를 없애도록 해야 합니다. 더 일반적으로 말하면, 성능 테스트에 사용하기 전에 대상이 되는 사이트의 동작을 이해해야 합니다.

관찰자 효과(Observer Effect)

많은 분야에서 측정하는 작업 자체가 측정 대상을 변화시키는 잠재적인 가능성이 있습니다. 이 현상은 관찰자 효과 (영어) 라 부릅니다.

특정 브라우징 시나리오 측정 작업을 편의상, 수많은 프레임워크의 한쪽을 사용할 수가 있습니다. 이러한 프레임워크는 전형적으로는 개발자나 기술자를 대상으로 합니다. 그러한 프레임워크의 일례로서는 Jiffy (영어) 가 있습니다.

어떠한 인프에서든 측정 결과에 직접 영향을 준다면, 주의 깊게 액세스 하여 측정에 사용하는 프레임워크에 의한 성능 변화를 부르는 잠재적 가능성을 최소화해야 합니다.

여담이지만, IE 팀에서는 내부적인 테스트에 ETW 트레이스 로그인 인프라 구조를 사용하고 있습니다. 이것은 ETW 가 확장성 높은 로그인 인프라 구조로, 결과를 왜곡하는 관찰자 효과의 가능성을 최소화할 수 있기 때문입니다.

컴퓨터 구성(Machine Configuration)

사람과 마찬가지로, 엄밀하게 동일한 두 개의 컴퓨터는 존재하지 않습니다.

앞에서 얘기와 같이, IE 성능 유효성 검사 환경에서는 매일 성능 테스트를 실행하는 대량의 컴퓨터를 보유하고 있습니다. 유효성 검사 환경의 유연성을 최대로 하기 위해, IE8 의 초기에 일관된 성능 데이터집합을 만들어 내기 위한 기획했습니다. 이러한 컴퓨터는 연번의 직렬화Serialization) 넘버가 붙어있고, 같은 조립 라인으로 생산되어 각각의 구성요소는 "완전히 동일" 이었습니다. 이러한 노력에도 불구하고, 컴퓨터에서 수집된 데이터는 다양하기 때문에 다른 컴퓨터에서의 성능 결과를 직접 비교 하는 일은 피했습니다.

이것은 놀라운 일은 아니지만, 다른 플랫폼간에 브라우저 성능은 가지각색이 되므로, 모든 브라우저의 테스트를 단일의 컴퓨터에서 실행해야 한다는 것을 알아 주셨으면 합니다.

Cold Start vs. Warm Start

브라우저를 시작하는데 필요한 시간의 총합은 브라우저 관할 외의 여러가지 요소에 의존합니다.

캐시 동작과 같이, 브라우저를 시작하는 스피드는 외부 요소의 영향을 받기 쉽습니다. 이것은 특히 첫번째 브라우저 실행에서 현저하게 나타납니다. 브라우저가 웹 사이트에 전환을 시작하기 이전에 우선 자기 자신의 파트를 메모리에 로드하기 위한 시간이 소요되는 동작이 필요합니다. 첫번째 브라우저의 실행에서는 얼마나 많은 부분이 이미 메모리에 읽히고 있는지를 정확하게 아는 일은 어렵습니다. 특히 IE에서는 많은 구성요소가 다른 프로그램과 공유되기 때문에 매우 어렵습니다.

일관성이 있는 데이터를 수집하기 위해서는 테스트의 시작 전에 대상이 되는 브라우저를 각각 한 번 실행한 후 종료합니다. 브라우저에 필요한 구성요소의 일부를 운영 체제가 메모리에 로드하는 동작을 하는 다른 응용 프로그램이 없으면, 결과의 정확함과 일관성은 향상합니다. Windows Superfetch (영어) 와 같은 평상시 잘 사용하는 브라우저에 유리하게 될지도 모르는 기능을 특히 고려하면, 브라우저 사이의 비교도 공정하게 할 수 있습니다.

웹 사이트 컨텐츠

웹 사이트는 항상 변화합니다. 유감스럽게도 성능 테스트를 시도하는 동안도 그 예외가 아닙니다.

IE 팀의 성능 유효성 검사 환경에서는 모든 웹 사이트의 컨텐츠는 테스트 기간 중 캐시된 상태가 되어 있었습니다. 캐시 동작의 영향 중 하나는 테스트 매회 반복하여 브라우저에 정확하게 같은 컨텐츠가 제공됩니다. 실제로는 이것이 그렇게 빈번히 일어나는 일이 아닙니다.

일례이지만, 뉴스 사이트는 화제가 널리 알려지는 것에 따라 컨텐츠를 업데이트합니다. Facebook 나 MySpace 를 두 번 방문하면, 친구가 새로운 사진을 추가하거나 상태를 업데이트 하면, 완전히 다른 경험이 얻을 수 있습니다. 광고는 많은 웹 사이트에서는 빈번히 변경되므로, 즐겨 찾기의 사이트를 두 번 표시하면, 틀림없이 차이가 납니다.

유효성 검사 환경이 아니면, 이러한 변경을 제어하는 일은 어렵습니다. 이것에 대한 접근 방식은 확실히 존재합니다. Fiddler 와 같은 도구를 사용하여 브라우저가 받는 컨텐츠를 조작하는 것이 가능합니다. 그렇지만 이러한 접근 방식은 성능 결과에 영향을 줄 가능성이 큽니다. 결과적으로, 현실적인 해결 방법은 샘플 양에 대해 지적했을 때의 조언과 같습니다. 페이지를 몇차례 표시할 때 마다 매우 무거운 광고가 표시되는 경우, 유효성 검사가 있는 일련의 결과를 얻기 위해서 측정을 상당 회수 반복해야 합니다 .

웹 사이트 설계

웹 사이트는 액세스 마다 변화할 뿐만 아니라, 다른 브라우저에는 각각 완전히 다른 버전의 웹 사이트가 제작자에 의해서 준비된 경우도 있습니다.

테스트 마다 웹 서버에서 확실히 같은 컨텐츠가 제공되도록 하는데 귀찮은 문제의 하나는 다른 브라우저에 대해서 분명하게 다른 코드를 반환하는 그러한 사이트입니다. 많은 경우, 그러한 차이는 사용자가 다른 웹 사이트를 방문했을 때의 경험을 정당하게 반영한다고 생각하여 브라우징 성능 측정에서는 차이를 무시해야 합니다.

그렇다고는 해도 웹 사이트가 제공하는 기능이 브라우저 간에 광범위하게 다르기 때문에, 브라우저 간의 비교가 의미를 만들어내지 않는 경우도 있습니다. 예를 들어, 최근 고객이 웹 사이트 이용에 IE8 를 사용하면 경쟁 관계의 다른 브라우저를 사용했을 경우보다 시간이 걸린다는 보고를 받아, 조사한 일이 있습니다. 조사의 결과, 그 웹 사이트는 IE 를 사용하면 IE 이외를 사용했을 경우에 비해 보다 리치한 기능을 제공하는 프레임워크를 사용한다는 것을 알았습니다. 다행히도 웹 사이트는 그러한 리치한 기능에 의존하지 않았기 때문에 프레임워크의 사용법을 조금 변경하여, 어느 브라우저에서도 같은 속도로 동작하도록 할 수 있었습니다.

이 예와 같이 웹 사이트가 프레임워크의 제공하는 확장기능을 사용하지 않고, 사이트를 업데이트 할 수 있는 경우도 있지만, 많은 경우 브라우저의 종류에 의존하여 완전히 다른 사용자 경험을 제공합니다. 이러한 웹 사이트의 평가는 대체로 경우에 따라 다르지만, 이러한 사이트는 브라우저 성능보다 사이트 개발자의 의도가 성능에 크게 반영되므로, 일반적으로는 직접적인 비교에는 해당하지 않는다고 생각합니다.

브라우저를 구별하는 사이트를 식별하는 것이 단순하지는 않습니다. 게다가 이 경우 웹 개발자는 조사 담당자를 제어할 수 있습니다. 웹 개발자는 프로파일러나 디버거, 그 외의 도구를 사용하여, 브라우저마다 웹 사이트가 완전히 다른 경험을 제공하기 위한 식별 방법을 자유롭게 결정할 수가 있습니다.

조사 담당자나 보다 기술에 경험이 많지 않은 사용자는 이용해 보고 분명하게 시각적으로나 동작이 다른 사이트에서 여러 개의 브라우저 성능 측정은 피해야 합니다. 그러한 사이트를 사용한 테스트에서는 브라우저 성능을 웹 사이트 설계의 영향에서 분리하는 일은 어렵습니다.

「페이지가 표시되었습니다」

「페이지가 표시되었습니다」라는 표시의 의미를 정확하게 정의할 수 있을까요. 복잡하고 인터랙티브 AJAX 사이트에서는 어떻습니까.

성능 측정에 대해 놀라울 정도 귀찮은 문제 증 하나는 페이지 전환으로, 「완료」란 무엇을 의미하는지를 정의하는 일입니다. 이 귀찮은 문제는 웹 사이트가 복잡하고 비동기적이며, 한층더 심각합니다. 브라우저가 페이지 전환을 완료된 것을 보여주는 표지로서 HTML "onload"(영어) 이벤트를 사용하는 웹 개발자도 있습니다.그러나 이 이벤트의 정의는 유감스럽게도 브라우저에 따라서 다른 해석이 됩니다.

IE 팀 내부에서는 여러가지 사이트에서의 페이지 로드를 측정하기 위해서 내부적인 이벤트 기록을 이용하고 있습니다. 이 기록은 IE 에 특화된 것으로, 브라우저 마다의 페이지 로드 성능을 측정하기 위한 크로스 브라우저의 간단한 해결책이 되지는 않습니다. 사이트 개발자가 각각의 시나리오의 「완료」를 정의하는데 도움이 되는 Jiffy (영어) 또는 Episodes (영어) 와 같은 프레임워크는 존재하지만, 일반 사용자에게 폭넓게 받아 들여지는 것이 아닙니다.

특정 코드 수준에 의한 식별 대신, 브라우저 진행률 표시기 (모래시계, 푸른 점, progress bar, 텍스트 박스나 그 외의 사용자 인터페이스 요소)를 페이지의 다운로드 완료 통지에 사용하는 사람도 있습니다. 그러나 이러한 요소는 어떠한 표준에도 잘 다뤄지지 않고, 브라우저 제조자는 이것을 언제 표시할지 (또 표시하지 않을지도) 독자적으로 결정할 수 있습니다.

이러한 현실에 직면한 다음 조사 담당자나 사용자에게 사용하도록 권장할 수 있는 것은 실제 웹 페이지의 동작에 대응하는 것을 확인할 수 있는 방법은 브라우저의 진행률 표시기를 사용하는 것입니다. 예를 들어 특정 웹 페이지가 얼마나 신속하게 로드 되는지 테스트한다면, 최초의 로드 시에 브라우저의 진행률 표시기를 사용해 봅니다. 만약 진행률 표시기가 완료되기 전에 웹 페이지가 로드되어, 읽기 조작 가능하게 된 것처럼 보인다면, 인디케이터는 무시하고 페이지의 보이는 방법을 측정을 위해서 사용합니다. 또는 다양한 브라우저 사이에 페이지 다운로드의 속도를 초기적으로 평가하는 것 뿐이면, 진행률 표시기로 충분할지도 모릅니다. 실제 페이지 로드와 브라우저 인디케이터의 표시가 얼마나 일치하는지를 평가하지 않으면 성능 측정 시에 인디케이터를 신뢰해야 할 것인지 판단할 수 없습니다.

브라우저 애드온

브라우저 테스트를 할 때에 애드온을 동작시키면, 브라우저 성능만을 테스트한다고 말할 수 없습니다.

4 월에 쓴 글에서 말한 것처럼, 애드온은 브라우저 성능에 매우 큰 영향을 줍니다. Microsoft 의 데이터 경로를 통해서 받은 데이터에서는 수십 개의 애드온이 설치된 브라우저는 드물지 않고, 아마 Mozilla corporation 에서 저와 같은 입장의 사람들도 그들의 브라우저에 대해 같이 말할 것입니다.

이러한 애드온은 모두 브라우저 안에서 독자적인 활동을 실행합니다. 이 영향에 대해 일화적으로 설명하면, 자주 사용하는 브라우저가 있는 사용자가 다른 브라우저에서도 평소 사용하는 브라우저보다 빠르다고 느끼는 것은 단지 새로운 브라우저는 깨끗한 상태이기 때문이라는 것을 알았습니다. 예를 들어, 많은 애드온이 설치된 Firefox 사용자가 IE 로 변경하면 성능이 크게 향상되었다고 느끼고, IE사용자가 Firefox 로 이행했을 경우도 같은 성능 향상을 느낍니다. 이 결과는 결코 모순된 것이 아니고, 브라우저 애드온 영향의 크기를 반영합니다.

결과적으로, 우리의 성능 유효성 검사 환경에서는 깨끗한 브라우저의 설치와 일반적으로 잘 사용되는 애드온을 설치한 브라우저를 모두 테스트 했습니다. IE8 로 애드온을 무효로 하려면, "도구" 메뉴를 클릭하여 "애드온 관리" 를 선택합니다. 애드온 관리 화면에서는 우선 "표시" 에서 "모든 애드온" 을 선택하고, 다음에 표시된 애드온을 한개씩 무효로 합니다. 또는 커멘드라인이 익숙하다면, 애드온을 무효로한 IE 를 "iexplore.exe -extoff" 커멘드로 실행 할 수 있습니다.

대부분의 브라우저 배급업체는 브라우저를 업그레이드해도 애드온이 계속 올바르게 기능하도록 보장하기 노력하고 있습니다. 그러나 어떠한 성능 향상이어도 단지 하나의 애드온 때문에 엉망이 되어버릴 수도 있기 때문에 위의 같은 절차를 밟는 일은 매우 중요합니다.

글이 조금 길어졌지만, 우리가 IE 의 성능을 측정할 때의 몇가지 기술을 여러분의 요구에 따라 이용해주시기를 바랍니다. 또 우리가 성능 테스트에 대해 어떠한 생각을 가지고 있는지 이해하고, 브라우징 성능 프로세스와 접근 방식을 보다 이해하게 되었으리라 생각합니다. 마지막으로 IE8 제공 과정에서 어떠한 노력을 하고 있는지 조금이라도 알아 주시면 감사하겠습니다.

Christian Stockwell
프로그램 관리자

업데이트 일: 2009 년 1 월 23 일

영문 원본 : Common Issues in Assessing Browser Performance

Internet Explorer 8과 안정성(Reliability)

HK Yoo — Fri, 27 Mar 2009 08:57:44 GMT

전체에서도 시스템의 일부에서도 안정적으로 동작하는 기술을 개발하는 것이 저희들의 목표이며, 신뢰할 수 있는 컴퓨팅의 중요한 부분입니다. 고객과 파트너는 언제, 어디서나 어떤 장치에서도 신뢰할 수 있는 기술과 서비스를 기대합니다. 우리는 기술과 서비스의 안정성을 향상시키는 일에 항상 집중하고 있습니다.

Internet Explorer 의 안정성이란, 브라우저가 언제나 신속히 실행하고, 신속하게 동작하여 인터넷에 확실히 접속할 수 있고, 크래쉬나 멈추지 않고 웹 사이트를 표시하는 것을 의미합니다. 대부분의 사용자는 자신의 브라우저가 크래쉬 되어도 그 후 신속하게 복귀하여, 정상적으로 웹을 표시하기를 바랍니다. 사용자는 문제의 원인이 불완전한 애드온에 있는지, 웹 사이트가 불완전한지 대해서는 관심이 없습니다. 안정성을 향상시키기 위해 Internet Explorer 8 을 성능, 복구, 디스플레이 등 모든 면에서 강력한 브라우저가 되도록 많은 노력을 거듭했습니다. 여기에서는 특히 다음과 같은 점에 대해 설명합니다.

Looselycoupled Internet Explorer

부드러운 브라우징 성능을 얻기 위해서 브라우저의 각 구성요소를 분리하는 도움이 되는 아키텍처상의 기능입니다.

크래쉬 자동 복구 기능

이 기능은 크래쉬가 발생하면 가능한 신속하게 원래의 브라우징 상태를 복구할 수 있도록 설계되었습니다.

Windows 오류 보고

Internet Explorer 의 안정성을 개선하기 위한 정보를 이용자가 우리에게 제공할 수 있는 방법입니다.

Looselycoupled Internet Explorer

가장 중요한 성과의 하나가 Looselycoupled Internet Explorer (LCIE)로 불리는 기능으로, 이 아키텍처의 특징은 브라우저의 구성요소, 특히 프레임을 탭에서 분리하는 것이 쉽습니다. LCIE 는 나중에 이야기할 자동 복구 기능을 포함한 몇가지 기능의 기초가 됩니다.

만약 Beta 1 공개 때에 읽지 않았다면, 프레임 윈도우를 분리하는 방법을 언급한 글을 먼저 읽으시기를 권장합니다. 이 기능은 대체로 Google chrome 와 동등한 것으로, 탭을 각각 다른 프로세스로서 배포하여, 탭에서 크래쉬가 발생해도 브라우저 이외 부분이 포함되지 않도록 설계되었습니다. 그림에서 보이는 것과 같이 밝은 부분이 프레임 영역에서, 회색 부분이 탭 영역이 됩니다.

Beta 1에 탑재한 이 기능을 바탕으로, 한층 더 안정성과 성능을 향상시키기 위해, Internet Explorer Beta 2 용의 LCIE 의 개발을 계속하고 있습니다.

Beta 2에서는 다음과 같은 변화가 있습니다.

프레임 프로세스 병합

실행 속도를 향상시키기 위해, 실행시의 프로세스를 줄였습니다. 브라우저를 실행 할 때마다 2 프로세스 (프레임을 위해 1 , 탭을 위해서 1)를 실행하는 것이 아니라, 먼저 Internet Explorer 를 실행할 때 1 개의 프레임의 프로세스만을 실행합니다. 이후 실행에서는 새로운 탭 프로세스를 실행하거나 기존의 탭 프로세스를 이용하여 새로운 탭을 엽니다.

여러 세션에서 웹 브라우징에 익숙한 사용자, 예를 들어 여러개의 웹 메일에 동시에 로그인 하는 경우 등은 "-nomerge" 커멘드를 실행하여 이 기능을 무효화할 수 있습니다.

탭 프로세스 증가

동작중의 Internet Explorer 세션은 많은 경우, 3 개 또는 그 이하의 탭을 열고 있는 경우가 많습니다. Internet Explorer 8 Beta 2에서는 3개의 탭 프로세스를 효율적으로 처리할 수 있습니다. 3 이라는 숫자 값은 컴퓨터의 처리 능력에 의존하며, 보다 강력한 컴퓨터의 경우, 어느 정도는 이 숫자 값이 증가하기도 합니다. 프로세스를 증가시키면, 문제가 발생한 프로세스를 유효하게 분리할 수 있습니다. 각각의 탭이 다른 프로세스로 구동된 경우, 각각의 탭에서 표시된 웹 사이트는 완전하게 분리됩니다.

가상 탭(Virtual tab)

"hot swap" 라 불리는 탭에 관한 내부처리 기능을 추가했습니다. 지금까지 보호 모드는 프로세스 별로 동작했습니다. 예를 들면, Internet Explorer 7 인 사이트를 신뢰하는 사이트에 추가합니다. 이 사이트에 신뢰하는 사이트에 없는 다른 사이트로 링크가 있는 경우, 이 링크를 클릭하면 새로운 윈도우가 열립니다.

프레임 윈도우에서 탭을 분리하는 LCIE 를 탑재한 Internet Explorer 8 beta 1에서 이 동작을 개선했습니다. 이 분리 기능에 의해서, 지금까지와 같이 다른 윈도우를 열지 않고, 같은 윈도우안에 새로운 탭을 열 수 있습니다.

가상 탭에 의해서, 탭 별로 적절한 유효성 검사 수준의 프로세스로 변경가능하기 때문에 보호 모드와 그렇지 않은 모드를 같은 탭에서 안내할 수 있습니다. 이것은 단순한 "조작성 향상" 이며, 가상 탭은 보호 모드의 유효 / 무효를 전환 할 때의 조작을 편리하게 하는 것 이외에 보안이나 보호 모드의 동작 자체에는 전혀 영향이 없습니다.

여러 개의 프로세스와 가상 탭에 의해서 브라우저의 각 부분을 분리하는 LCIE 의 능력은 Internet Explorer 의 성능과 안정성을 향상시킵니다.

자동 복구 기능(Automatic Crash Recovery)

크래쉬 발생시, 자동 복구 기능은 가능한 한 신속하게, 원래의 브라우징 상태를 복구하도록 설계되었습니다. 문제를 특정 탭에 국소화하기 위해서 LCIE 기술이 이용됩니다. Internet Explorer 8 beta 1에서 크래쉬가 발생했을 때, 다음과 같은 도움말 풍선을 본 적이 있을지도 모릅니다.

이것이 "탭 복구 기능" 입니다. 이것에 의해 트러블은 문제가 발생한 탭으로 한정되었습니다. 브라우저expression body 는 소멸하지 않고, 신속하게 원래의 웹 사이트가 다시 표시됩니다.

이러한 현상이 발생했을 경우, 탭에 관한 각종 정보는 저장되어 복구 시에 이용됩니다. Internet Explorer beta 1에서는 다음의 정보가 유지 됩니다.

- 현재 URI

- 탐색 로그 (전/ 후 검색 기록)

- 탭 순서

- 어느 탭이 활성화되었는지

크래쉬가 발생하면 문제가 발생한 탭 프로세스는 닫혀지고, 새로운 탭 프로세스를 시동하여, 보관되었던 정보가 복원됩니다. 여러 웹 사이트에서 이 기능은 유효하게 동작하지만, 폼을 이용하고 있는 사이트나 로그온이 필요한 사이트의 경우, 정상적으로 동작하지 않을 수도 있습니다.

Internet Explorer beta 2에서는 다음과 같은 점에서 크게 개선되었습니다.

세션 쿠키(Session cookie)

세션 쿠키는 웹 사이트가 사용자를 인증하기 위해서 이용됩니다. 세션 쿠키는 일시적인 쿠키로, 그 수명은 세션중에서만 입니다. 웹 사이트에 로그온하면, 일반적으로는 로그온 안에 사용자를 식별하기 위해 유일 토큰을 포함한 세션 쿠키가 제공됩니다. 웹 사이트 내를 이동하는 경우, Internet Explorer 는 이 세션 쿠키를 송신하고, 웹 사이트는 토큰을 조사하여 사용자가 인증되었는지 판정할 수 있습니다. 연속적으로 이용되는 쿠키와는 달리, 세션 쿠키는 하드 디스크에는 기록되지 않습니다.

Internet Explorer 8 beta 2 는 세션 쿠키의 복구를 가능하게 하지만, 하드 디스크에 기록하는 것은 아닙니다. Internet Explorer 8 beta 2 는 세션 쿠키의 복사를 프레임 프로세스에 저장합니다. 탭에 크래쉬가 발생했을 경우, 프레임 프로세스에서 탭 프로세스에 복원에 필요한 정보 (예를 들면 Web 메일, 블로그, SNS 등)가 자동적으로 다시 써집니다.

세션 쿠키의 복원은 탭의 크래쉬가 발생했을 때에 만 행해지는 점에 주의해야 합니다. 대부분의 경우 크래쉬의 영향은 탭에만 머문다고 생각하지만, 만약 브라우저 전체가 크래쉬 했을 경우, 세션 쿠키는 없어집니다. 이러한 현상은 탭의 분리 기능에 대응하지 않는 애드온에 기인할 가능성이 높다고 생각할 수 있습니다.

폼 데이터(Form data)

Internet Explorer 8 beta 2에서는 폼에 입력한 데이터 복원도 가능합니다. 전자 메일이나 블로그의 글이나 댓글과 같이 HTML 폼에 입력한 정보도 복구할 수 있습니다.

LCIE 에 의한 탭의 분리 기능에 의해서, 자동 복구 기능은 데이터를 재입력하지 않아도 크래쉬 직전 상태를 복구할 수 있습니다. LCIE 와 자동 복구 기능 연동은 매우 혁신적으로 매우 훌륭한 크래쉬에서의 복구 수단을 제공합니다.

Windows 오류 보고 (Watson)

크래쉬나 멈추는 경우를 만났을 때 ,"Microsoft 에 정보를 송신 합니다" 라는 선택사항이 봤던 적이 있을지도 모릅니다. 보내진 정보를 우리가 어떻게 이용하고 있는지에 대한 의문을 가지고 있었을지도 모릅니다.

단적으로 말하면, 우리는 보내진 정보를 매일 확인하고 있습니다. 이러한 데이터는 매우 중요한 것이기 위해, 진지하게 보고서를 작성합니다. 그 뿐만 아니라, 현재 전세계로 어떠한 문제가 발생하는지 알 수 있어 그 원인을 한층 더 특정할 수도 있습니다. 실제로 오류 보고에 의해서 수정되는 사례도 있습니다.

Internet Explorer 가 크래쉬 또는 멈춰서, Windows 오류 보고의 송신을 선택했을 경우, 현상 발생시에 문제의 프로그램이 어떠한 상태에 있었는가 하는 정보가 모아집니다. Internet Explorer 가 크래쉬 했을 때에 어떠한 동작을 하고 있었는지, 어떠한 애드온이 로드되어 있었는지를 확인할 수 있습니다. 확인 담당의 프로그래머를 위해 메모리 덤프와 호출 스택도 송신합니다. 여러분이 Windows 용 응용 프로그램이나 Internet Explorer 용의 애드온을 생성한 프로그래머라면, 왓슨 데이터 취득하여 (영어) 여러분의 응용 프로그램의 품질을 개선할 수도 있습니다.

Windows 오류 보고에서는 유사한 문제를 일반적으로 같은 근본 원인을 가지는 현상으로서 "buckets" 에 정리합니다. Internet Explorer 의 프로그램코드에 기인하여 자주 문제가 발생한 경우, 코드를 수정하고 있습니다. Internet Explorer 8에서는 우리는 왓슨에 의해서 송신되는 모든 정보 가운데, 상위 50 % (Internet Explorer 7에서 계속 발생하는 문제 포함)를 집중적으로 수정했습니다.

Microsoft 는 고객이 오류 리포트를 송신할 때의 프라이버시 보호에 대해서 전력을 기울이고 있습니다. 오류 발생시에 생성되는 보고용 데이터는 문제 해결에 필요한 최소한으로 합니다. 오류 리포트에는 어떠한 개인정보도 포함되지 않고, Microsoft 에 정보가 보내지기 전에 사용자 확인이 요구됩니다. Microsoft 는 오류 리포트의 송신자를 특정하지 않습니다 (송신자가 과거에 유사한 사례가 있는지를 확인하는 것을 선택했을 경우를 제외합니다). 비록, 문제 해결을 위해 보다 세부 사항정보가 필요한 경우에도 Microsoft 의 개발자는 고객을 확인할 수 없습니다.

Internet Explorer 8 beta 2 준비

LCIE 와 자동 복구 기능, 여러 가지 문제 수정하여 Internet Explorer 8 beta 2 는 충분히 신뢰할 수 있는 브라우저입니다. Internet Explorer 8 beta 2 가 공개되면 이 점에 꼭 주목해 주십시오.

영문 원본 :IE8 and Reliability

업데이트 일: 2008 년 7 월 28 일

Cookie 차단 이상의 프라이버시보호 : 주의해야 할 타사 컨텐츠(Third-Party Content)

HK Yoo — Fri, 27 Mar 2009 08:56:16 GMT

이전 글에서는 일반적인 안정성 확보를 위한 행동 지침 (영어)과 제품의 세부 사항 (XSS Filter 와 안정성 (영어))에 대해 설명했습니다. 프라이버시 확보는 신뢰할 수 있는 컴퓨팅에서 중요한 위치를 차지합니다. 이 글에서는 타사 컨텐츠에 대한 웹에서의 프라이버시를 다룹니다.

웹 서핑을 하는 대부분의 사람들이 주소 표시줄에 표시된 URL과 현재 보고 있는 사이트가 같은 것이라고 생각합니다. 그러나 현재 웹 사이트는 많은 다른 웹 사이트에서 내용을 가져옵니다. 정확한 용어를 사용하면, 사용자가 직접 열람하는 사이트 (주소 표시줄에 URL 가 표시되는 사이트)를 퍼스트 파티 (first-party) 사이트, 퍼스트 파티 사이트가 도입한 내용을 제공하는 사이트 (이쪽은 사용자가 선택하지 않았습니다)를 타사 (third-party) 사이트라고 부릅니다.

퍼스트 파티 사이트를 열람할 때, 여러분이 이 사이트를 어떻게 이용하는지에 대한 정보를 수집할 수 있다는 것은 알고 계시리라 생각합니다. 그러나 많은 사용자는 타사 사이트에서도 같은 정보를 수집하는 것이 기술적으로 가능하다는 것은 모르고 있습니다. 어느 사이트가 정보를 수집하는지, 이 정보를 현재 어떻게 이용하고 있는지, 이 정보를 앞으로 어떻게 이용할지에 대해 일반 사용자들은 정확한 지식이 없습니다.

타사 사이트 식별

현재 웹 사이트의 대부분이 실제로는 다른 여러개의 웹 사이트를 모자이크로 조합하거나 또는 매쉬업 됩니다. 이것은 프라이버시 리포트 (Internet Explorer 7 의 [페이지] 단추 또는 Internet Explorer 6 의 [표시]에서 [웹 페이지 프라이버시 정책] 을 선택합니다)를 실행하면 확인할 수 있습니다.

주소 표시줄에는 현재 표시되는 퍼스트 파티 사이트의 주소가 표시되는데 , 이 대화상자에는 다른 웹 사이트 (타사 사이트 포함)의 주소가 모두 표시됩니다. 브라우저는 현재의 웹 페이지 컨텐츠를 표시하기 위해, 모든 웹 사이트에 액세스합니다.

이와 같이 다른 사이트의 컨텐츠를 유용하게 하는 방법은 최근의 웹에서는 유익하고 강력한 일반적 방법입니다. 이러한 방법은 웹의 근간을 이루는 개념으로, 높이 평가되는 기능 (레스토랑 웹 사이트에 인터랙티브 지도를 찾거나 뉴스의 문서 내에 "공유하는" 라는 링크를 묻는)을 가능하게 합니다.

타사 사이트와 프라이버시

다른 웹 사이트에서 정보를 찾는 것은 동시에 프라이버시 유지에 영향을 줍니다. 이 문제의 좋은 예는 대부분의 사람들이 전자 메일에서 경험하고 있습니다. 많은 전자 메일 시스템은 불확실한 발신자가 보낸 전자 메일을 받을 때, 특수한 방법으로 이미지를 차단하여 (영어) , 다음과 같은 메시지를 표시합니다.

메시지 본문에는 일반적으로, 이미지가 보이지 않는 것을 나타내는 붉은× 마크와 「이미지를 다운로드 하려면 여기를 오른쪽 클릭해 주세요. 프라이버시 보호하기 위해, 메시지 내의 이미지는 자동적으로는 다운로드 되지 않습니다」라는 텍스트가 표시됩니다.

왜 전자 메일 시스템은 이러한 외부 이미지를 차단할까요? 이 송신자는 외부 이미지에 수신자 고유 정보 (예를 들면, 외부 이미지 파일 이름이나 주소에 수신자 주소를 포함하는 등)를 프로그래밍 할지도 모릅니다. 송신자는 특정 이미지가 다운로드 되었을 경우, 전자 메일이 도착한 것과 유효한 전자 메일 계정이 이 메일을 열었다는 것을 알게 됩니다. 이미지 파일을 다운로드하지 않으면, 수신자 정보가 확인되지 않아서, 불확실한 송신자로부터 프라이버시가 보호됩니다. 경우에 따라서는 임의로 보내지는 메일로부터 보호 받을 수 있습니다.

일반적으로, 컴퓨터가 웹 사이트에 요청하는 모든 웹 컨텐츠는 그 사이트에 통지됩니다. 이 기본적인 기술은 다른 퍼스트 파티 사이트에서 만나도 같을 타사제품의 컨텐츠를 포함한 사이트이면, 타사에 의한 방문자 추적을 가능하게 합니다. 여러 개의 웹 사이트가 같은 타사의 웹 사이트에서의 컨텐츠 (사진이나 문서의 전달 등)를 게재했을 경우, 이 타사 사이트는 어느 웹 사이트에서 어느 방문자가 열람했는지를 확인할 수 있습니다.

예를 들면, Site1.com 와 Site2.com 라는 전혀 관계가 없는 사이트가 MySyndicatedPhotos.com 에서 전달하는 이미지를 게재했다고 합니다. 어떤 사용자가 Site1.com, Site2.com 두 곳을 모두 열람했을 경우, 사용자 브라우저는 이러한 사이트에 포함되는 이미지를 취득하기 위해, MySyndicatedPhotos.com 를 호출합니다. MySyndicatedPhotos.com 는 같은 컴퓨터가 두 다른 사이트를 방문했다는 것을 (여러 가지 방법으로) 확인할 수 있습니다.

같은 타사 사이트의 컨텐츠를 표시하는 사이트를 방문하는 사용자가 있으면, 타사 사이트는 그 컨텐츠를 포함한 웹 사이트를 어떻게 사용자가 이동하는지 활동 소개를 확인할 수 있는 입장에 있습니다.

Cookie는 확실히 도움이 되는 기술이며, "Cookie 를 이용한 추적 (트래킹 Cookie)" (영어) 에 관련된 걱정과 혼란이 오랜 세월에 걸쳐 계속 되어 있지만, 사실 어떤 컨텐츠도 타사 사이트는 트래킹 Cookie와 같이 기능시킬 수 있습니다. 그 컨텐츠가 의도하는 내용 (사진, 문서, 로고, 특정 용도의 분석 이미지, 텍스트, 스크립트)과 추적에 이용될 가능성과는 기술적인 관련성은 없습니다. 모든 Cookie 를 차단해도 다른 컨텐츠가 사용자 행동을 분석할 수 있는 것에 주의해야 합니다. 타사의 컨텐츠는 그 선악과 관계 없이 이러한 방법으로 이용하는 것이 기술적으로 가능합니다.

무엇이 일어나고 있는지, 기술적으로 무엇이 가능한가 그리고 그 외의 의문

문제를 명쾌하게 하기 위해, 여러 다른 사이트에 컨텐츠를 제공하는 웹 사이트는 무엇이 가능한지에 대해 다루고 있지만, 다른 사이트에 컨텐츠를 제공하는 모든 사이트가 실제로 이와 같은 것은 아닙니다. 타사 사이트에 제공된 이용 가능한 정보를 어떻게 이용하고 있는지를 확인하는 것에는 몇가지 측면에서 매우 어렵습니다. 타사 사이트는 활동 내용을 안내하기 위해, 명확하게, 적절히, 눈에 띄도록 제시된 프라이버시 정책을 게재할 수 있습니다. 그러나 그 내용처럼 행동하지 않을지도 모릅니다. 정책에 위반하거나, 수집한 데이터가 들어간 노트 PC를 분실하거나 맬웨어에 감염되거나 수집한 정보를 공개하는 종업원을 고용하고 있을지도 모릅니다. 수집한 데이터를 제공하는 것을 조건으로 개업 자금을 조달했을지도 모릅니다.

이 글은 사용자를 추적하기 위한 고도의 기술이나 고도의 기술을 가지는 사용자가 흥미를 가진 추적에 대한 대응책에 대해는 언급하지 않습니다. 여기에서는 퍼스트 파티 사이트가 방문자의 개체 식별을 위해서 수집한 정보가 타사 사이트에도 이동한다는 기술적인 일반론을 주제로 합니다. (앞의 전자 메일의 경우나 여기 (영어)에서 논함) .예를 들어, 웹 페이지 프라이버시 정책의 대화상자에서 보이는 웹주소가 대부분의 경우 긴 개체 식별자(dentifiers)를 포함합니다. 이러한 안건을 논의하는데 적합한 장소가 있습니다. 예를 들면, 새로운 리치 디자인인 사이트의 웹 표준의 개발에 관한 IRC 최근 화제 (영어) 가 그렇습니다. 이것은 매우 길지만, Cookie 를 송신하거나 하지 않아도 추적된 사람들의 이야기 (영어) 나 Cookie 없이도 웹 상에서의 활동을 추적할 수 있는 누군가… USER AGENT 의 문자열, IP 주소, 화면 크기, Java Script 나 HTTP 의 액세스 설정에서 쉽게 사람들의 "지문" 을 채취할 수 있어 간단한 분석용 스크립트를 이용하여 AOL 가 유출시킨 "익명" 검색 정보에서 찾을 수 있습니다 .

웹 브라우징은 타사 사이트가 없어도, 익명성은 없고, 완전하게 비공개도 아닙니다. 예를 들면, 인터넷 접속을 (집, 호텔, 찻집, 학교, 직장) 제공하는 공급자는 컴퓨터가 어디에 접속했는지를 관찰할 수 있습니다. 일반적으로, 공급자는 사용 조건을 제시하기 위해, 사용자는 명확한 주의를 받은 다음, 조건을 수락했는지, 거부하는지를 선택할 수 있습니다. 컴퓨터에서 동작하는 모든 소프트웨어는 이 컴퓨터가 어느 사이트를 방문했는지를 확인할 수 있습니다. 이 기술은 사용자의 브라우징 저널을 복사하여 웹 사이트에 업로딩하여 다른 컴퓨터에서도 이용할 수 있도록 하는 도구 막대나 브라우저 저널 기능의 기본이 됩니다. 반복하지만, 사용 조건과 프라이버시 정책은 사용자에서 지금 있는 중요한 도구입니다. 웹 사이트는 방문자 정보를 확인할 수 있습니다(예를 들면, 대체 위치 (영어)) .또 사용 조건을 클릭하거나 선택하여 웹 사이트에 직접 정보를 전달합니다.

타사 사이트의 신용성

웹 브라우징에 익명성이 없고, 이러한 구조로 움직인다면, 무엇이 신용에 관한 문제일까요? 많은 사람들에서, 신용은 보안에서 시작됩니다. 어떤 사이트를 방문하면 잠재적으로 다른 웹 사이트의 악의가 있는 컨텐츠에 노출되는 보안적인 위험은 명백합니다. 신뢰할 수 있을 것 같은 컨텐츠로 구성된 것처럼 보이는 사이트를 방문해도 현실에서는 다른 사이트의 내용이 포함되어 있는 일이 있습니다. 이러한 예를 웹에서 찾는 것은 어렵지 않습니다. 일부 유력 사이트 (예 1 (영어) ,예 2 (영어) ,예 3 (영어))의 방문자에게도 발생하고 있습니다.

이와 같이 신용은 프라이버시도 포함합니다. 프라이버시에 관해서는 사용자 선택과 어떤 정보를 제공할지 컨트롤이 관련합니다. 현시점에서는 브라우징 활동 상태에 대한 정보를 웹 사이트가 수집하는 것을 사용자가 컨트롤할 수 없습니다. 그 결과, 방문한 사이트와 관계가 명시되어 있지 않은 사이트가 브라우징 경향을 분석하기 위한 모습을 사용자는 눈치채지 못합니다.

Internet Explorer (와 신뢰할 수 있는 컴퓨팅에 관련하는 Microsoft 의 모두)를 위해서 안내하는 지침에서는 이용자가 컨트롤 해야 합니다. 일반 이용자는 브라우저의 보안 및 보호 기능을 기대하며, 동시에 프라이버시 보호에 대해서도 높은 기대를 갖고 있습니다. 여기서 말하는 컨트롤과는 이용자에게 명확한 주의가 주어지는 것으로, 어떠한 사이트가 어떠한 사용 조건아래에서 정보를 공개할지 아는 것입니다. 컨트롤과는 동시에 사용자가 누구에게 어떤 정보를 공개하는지를 선택할 수 있는 것을 의미합니다. 정보 누설을 막는 것은 컨텐츠 차단을 의미하지만, 컨텐츠 차단은 페이지의 외형이나 기능에 영향을 미칠 가능성이 있습니다.

또한 책임에 대한 현안이 있습니다. 어느 쪽에도 같은 타사 사이트의 컨텐츠를 포함한 다른 사이트를 방문했을 때, 사용자 정보를 수집하는 것에 대하여, 누가 이것을 설명하고 누가 책임을 지는 것입니까? 오늘날의 웹에서는 그것이 완전히 명확하지 않습니다.

타사의 컨텐츠에 관련된 프라이버시와 신용 문제는 복잡하고 중요한 문제입니다. 이 블로그에서 논의되었듯이 신뢰할 수 있는 브라우징은 많은 근면한 도전과 다른 많은 노력 (상호 운용성의 확보 등)을 포함하여 협조와 절충을 요청합니다. 웹에서의 프라이버시는 단순한 cookie 의 차단에 머물지 않고 보다 많은 일과 관련합니다. 이것을 깨달을 수 있으면, 사용자는 프라이버시를 관리할 수 있게 되겠지요. 이후 다른 글에서 사용자가 자신의 정보를 관리하는 도움이 되는 Internet Explorer 8 의 기능에 대해 설명합니다.

Dean Hachamovitch
General Manager

영문 원본 :Privacy Beyond Blocking Cookies: Bringing Awareness to Third-Party Content

업데이트 일: 2008 년 8 월 25 일

호환 표시 기능(Compatibility View) 소개

HK Yoo — Fri, 27 Mar 2009 08:52:26 GMT

Internet Explorer 8 계획을 시작했을 때, 웹 사이트의 호환성을 유지하는 것을 공약으로 했습니다. 이 공약은 여전히 유효하고, Microsoft 의 상호 운용성에 관한 방침과도 일치하고, 우리의 성명 (영어) 에도 단기적인 영향을 주고 있는 것은 주목할 만합니다. 바꾸어 말하면, Internet Explorer 8 의 새로운 기능 중 가장 중요한 것은 호환성 확보이며 또 그것을 유지하는 것입니다.

Beta 2에서는 호환 표시로 불리는 새로운 기능을 탑재한다고 발표했습니다. 호환 표시는 이전 버전에서 디자인된 사이트를 Internet Explorer 8 이 적절히 표시하는 기능입니다.

호환 표시와 최종 사용자

웹 사이트가 최신의 웹 표준을 지원한다고 선언했을 경우, Intenret Exporer 8 은 그 선언을 존중하여 가장 표준에 맞는 메커니즘을 사용하여 이 사이트를 표시합니다. 대부분의 경우, 이것 때문에 문제는 없습니다. 그러나 드물게 「최신 표준을 사용하여 표시해 주세요」라는 선언이 사실은 「Internet Explorer 7 의 최신 표준으로 표시해 주세요」를 의미하는 경우가 있습니다. 이것은 호환 표시의 순서입니다.

드로잉 엔진에는 여러 가지가 변경되었지만, 알아 두어야 할 것은 다음과 같습니다.

일반 인터넷 사이트는 IE8 표준모드에서 표시됩니다.
호환 표시 기능의 변환 (IE7 표준모드와 IE8 표준모드)은 재시동 없이 즉시 실행됩니다.
호환 표시 기능은 도메인 단위로 기능합니다.

호환 표시를 컨트롤하는 새로운 사용자 인터페이스 단추는 탐색 모음 내의 주소 표시줄 우측 (업데이트 단추 근처)에 배포되어 Beta 1 의 Emulate IE7 단추를 대체합니다 .

표준모드에서의 표시중 과 같이 호환 표시로 전환하는 보다 좋은 결과를 얻을 수 있는 경우에만, Internet Explorer 는 이 단추를 표시합니다. Quirks 모드 혹은 인트라넷 사이트의 표시중 (다음에서 채택하지만, 이러한 경우는 이미 호환 표시 모드에서 표시) Internet Explorer 는 단추를 숨깁니다.

컴퓨터 처리 속도에 따라서는 호환 표시 단추를 선택한 후, 화면의 다시 읽기 포함을 확인할 수 있을지도 모릅니다. 어쨌든, 풍선 팁이 표시되어 현재 호환 표시 모드에서 동작중인 것을 알려줍니다. 또한 풍선 팁이 사라진 후도 호환 표시의 아이콘이 「누름」상태가 되어, 호환 표시로 동작중인 것을 확인할 수 있습니다.

에뮬레이션의 「효과 범위」는 단추를 누른 현재 표시중의 도메인으로 한정되어 실행 중 다른 프로세스나 탭에는 미치지 않습니다. 그리고, Internet Explorer 는 로컬 목록에 이 도메인 이름을 유지하기 때문에 같은 사이트를 방문했을 경우, 다시 단추를 누를 필요는 없습니다.

호환 표시와 엔터프라이즈

현재, 대다수의 기업용 웹 응용 프로그램은 Internet Explorer 7 이용을 전제로 합니다. 호환성을 유지하기 때문에 Internet Explorer 8 은 영역 판정에 근거하는 현명한 초기값을 설정해서 출시됩니다. 초기값에서는 인터넷의 모든 사이트는 Internet Explorer 8 표준모드 (호환 표시 무효)로 표시되어 인트라넷의 모든 웹 사이트는 Internet Explorer 7 표준모드 (호환 표시 유효)에서 표시됩니다.

몇가지 예를 봐 주세요.

jp.msn.com 이나 home.live.com 과 같은 인터넷에서 사이트를 표시하는 경우, 호환 표시는 초기값에서 무효가 됩니다. Internet Explorer 8 은 자신의 UserAgent 문자열을 "8" , 내부 버전을 "8" 이라고 인식하고, 표준 드로잉 모드를 Intenret Explorer 8 표준모드에서 전환하고, 웹 페이지를 표시합니다. http://192.168.0. 1 이라고 하는 IP 주소에 의한 지정도 같습니다. Internet Explorer 가 IP 주소를 내부 주소인가 외부 주소인가 분별할 수 없는 경우는 후자로 가정하여 동작합니다. 호환 표시에 의한 웹 사이트의 문제 수정은 이전의 Emulate IE7 단추를 이용한 것과 같습니다.

만약 http://myPortal 나 http://sharepoint/sites/mySite 라고 하는 로컬 인트라넷의 사이트로 이동했을 경우, Internet Explorer 는 자신의 UserAgent 를 "7" , 내부 버전을 "7" 이라고 인식하여, 표준 드로잉 모드를 Internet Explorer 7 표준모드에서 전환하고, 웹 페이지를 표시합니다. 이 편성은 Internet Explorer 7에서 정상적으로 표시되던 페이지를 Internet Explorer 8에서도 계속 이용하는 것을 가능하게 합니다.

완전을 기한다면, C:\Temp\MyWebPage.htm 라고 하는 로컬 페이지는 Internet Explorer 8 표준모드 (호환 표시 무효)로 표시하는 점에 주의할 필요가 있습니다.

[도구] 메뉴에 새롭게 추가된 항목은 이 기능의 세부 사항설정을 가능하게 합니다.

모든 인트라넷 사이트를 Internet Explorer 8 표준모드에서 표시하도록 설정할 수 있습니다. 모든 사이트를 Internet Explorer 7 표준모드에서 표시하는 것 (Emulate IE7 단추가 눌린 상태의 Internet Explorer 8 beta 1에서 같은 동작) 과 같이 정책을 설정할 수도 있습니다. 한층 더 항상 호환 표시 모드에서 표시해야 할 사이트를 사전에 등록하거나 호환 표시 단추를 눌러 등록한 목록을 편집할 수도 있습니다. Internet Explorer 8 의 UserAgent 스트링을 부정한 것으로 판단하여 차단하여, Quirks 모드에서 표시하는 페이지에 조우했을 경우, 현재 표시하는 문제의 사이트를 추가하는 본래의 기능은 특히 편리합니다.

이러한 새로운 기능의 모든 것이 그룹 정책으로 여러 가지 단추와 스위치를 조작하여 자세하게 설정할 수 있습니다. 대부분의 설정은 IEAK 를 이용하여 구성할 수도 있습니다.

호환 표시와 웹 개발자

최신의 웹 표준에 따라 DOCTYPE 선언에 의해서, 명시적으로 레이아웃 모드를 지정한 페이지를 생성했을 경우, Internet Explorer 는 예상대로 Quirks 인 DOCTYPE 는 Quirks 모드에 표준적인 DOCTYPE 는 Internet Explorer 8 표준모드에 관련됩니다. Beta 1 에서는 <META> 태그나 HTTP 머리글 (영어) , Internet Explorer 8 표준모드를 옵트 아웃(opt-out)할 수 있었습니다.

이용자가 웹 사이트를 최고 상태로 표시할 수 있어, 호환 표시 모드를 이용하지 않고 좋게 만들기 위한 가장 적절한 방법은 Internet Explorer 8 에 의한 테스트를 실시하여, 필요에 따라서 웹 사이트를 업데이트하는 것입니다. 이용자가 사이트를 표시하기 위해서 호환 표시 모드를 선택한 경우, 적절한 <META> 태그나 HTTP 머리글을 이용하고, 바람직한 레이아웃 모드에 "반환" 이 가능합니다. 새로운 content 값인 "IE=EmulateIE8" 는 이용 가능한 값의 목록을 완전하게 하여, 이 특별한 목적에 도움이 됩니다.

Content 설정 값

소개

IE=EmulateIE8

표준적인 DOCTYPE 의 경우, Internet Explorer 8 표준모드에서 표시합니다. Quirks DOCTYPE 의 경우, Quirks 모드에서 표시합니다. 이 태그를 사용하면, 클라이언트의 호환 표시 모드 설정을 무효로 하여, 표준적인 DOCTYPE 는 강제적으로 IE8 표준모드에서 표시합니다.

이 <META> 태그, 혹은 HTTP 머리글이 존재하는 경우, 이 사이트는 Internet Explorer 8 을 지원하기 위해서 업데이트된다고 보여, 이 값 이외의 클라이언트로 설정된 호환 표시 모드보다 우선됩니다. <META> 태그, 혹은 HTTP 머리글에는 다른 효과도 있습니다. 그 하나는 이 설정은 사용자가 장기간에 걸쳐 저장한 호환 표시의 웹 사이트 목록을 제거하는 트리거가 되어, 결과적으로 이 <META> 태그나 HTTP 머리글을 동시에 둘 필요가 없어집니다 (덧붙여서 브라우저 탐색 정보를 삭제하면 호환 표시를 위한 목록은 삭제됩니다) .또 하나는 <META> 태그 혹은 HTTP 머리글이 존재하는 경우, 명령 모음의 호환 표시 단추가 표시되지 않도록 , 대부분의 사용자가 호환 표시 목록에 사이트를 추가하여 효과적으로 관리할 수 있습니다.

User Agent 에 포함되는 새로운 태그는 호환 표시 모드를 이용하는 클라이언트 파악을 가능하게 합니다. Internet Explorer 8 표준모드의 태그도 존재합니다.

호환 표시 모드 :
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; SLCC1; Media Center PC 5.0; .NET CLR 3.5.21022)
최신의 Internet Explorer 8 의 UA String:
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; Media Center PC 5.0; .NET CLR 3.5.21022)

마지막으로, 이 기능에 대응한 개발자 도구의 업데이트도 완료했습니다. [브라우저모드] 메뉴에서는 서버나 웹 사이트에서 지정되는 동작 모드에 관련되지 않고, Internet Explorer 의 동작을 변경할 수 있습니다. 이 기능을 사용하면, Internet Explorer 8 표준모드에서 표시시켰을 경우, Internet Explorer 7 표준모드에서 표시시켰을 경우, Internet Explorer 8 의 호환 표시 모드에서 표시시켰을 경우의 동작을 확인할 수 있습니다.

[문서 모드] 는 [브라우저모드] 와는 독립해 존재해, 웹 사이트측에서 다른 DOCTYPE 나 <META> 태그를 사용했을 경우의 레이아웃의 변화를 확인할 수 있습니다.

요약

호환 표시 기능이 Emulate IE7 에 비해, 어떠한 점에서 개선되었는지 보았습니다.

만약 호환 표시 기능으로 문제를 해결할 수 없는 웹 사이트를 발견하면 연락을 주세요. Report a Webpage Problem (영어) 을 참조하시면 도움이 됩니다.

Scott Dickens
Lead Program Manager

영문 원본 : Introducing Compatibility View

업데이트 일: 2008 년 8 월 27 일

Internet Explorer 8 Developer Tools 생산성 향상

HK Yoo — Fri, 20 Mar 2009 10:28:31 GMT

지난 1 년간, Internet Explorer 개발시에 웹 개발자의 생산성 향상을 도모하기 위한 다양한 도구 (Web Development Tools for Internet Explorer (영어) 또는 Tools for Detecting Memory Leaks (영어))에 대한 글을 써 왔습니다. 이러한 도구는 Microsoft 내부/외부 파트너가 개발한 것입니다. 그 중의 하나 (IE Developer Toolbar) (영어)는 사이트를 IE에서 디버그 하는데 도움이 되고, 무료이며 가벼운 도구를 원하는 요구에 따라 IE 팀이 개발한 것입니다.

IE8 Developer Tools 는 Internet Explorer에서 개발자의 생산성 향상을 지원하는 다음 단계입니다. 이 글에서는 IE8 Beta 1에서 이용 가능한 도구를 소개해고, 그러한 도구에 관한 상세 정보를 알려드립니다.

통합화되어 사용하기 쉬운 Developer Tools

Internet Explorer 8에서는 개발도구를 쉽게 바로 사용할 수 있도록 디버그 과정을 간소화했습니다. 다른 디버그용 응용 프로그램을 찾아서 다운로드하여 설치할 필요가 없습니다. Shift 키를 누르고, F12 키를 누르거나 명령 모음의［개발도구］아이콘을 클릭하면, 바로 사용할 수 있습니다.

또, JScript 를 디버그 할 때 ,［ Script (스크립트 ) ］ 탭으로 전환하여［ Start Debugging (디버그 시작 ) ］ 단추를 누릅니다. 스크립트 디버깅 기능이 활성화되지 않은 경우에도 Internet Explorer 8은 알림 메시지를 보여주고, 페이지를 새로 갱신하면서 현재 IE 창에 대해서만 디버깅 기능을 활성화 합니다. 또, 페이지를 갱신하는 것과 대화상자를 표시하지 않으려면 인터넷 옵션 컨트롤 패널의 ［ Advanced (세부 사항 ) ］ 탭에서 Internet Explorer 의 스크립트 디버그를 유효하게 하면 됩니다.

다음은 디버거를 보여줍니다.

도구를 열고 있지 않은 경우에도 IE Developer Toolbar (영어)이 성능에 영향을 준다는 피드백을 받고, 그 문제를 해결하기 위한 설계를 했습니다. Beta 1 에서는 이 새로운 설계를 빌드하면서 IE 개발자 도구 모음의 새로운 기능을 모두 구현하는 것보다 새로운 시나리오 적용에 중점을 두었습니다. 결과적으로, IE 개발자 도구 모음이 많은 기능이 IE8 Beta 1에서는 이용할 수 없습니다. 그렇지만, 이후 Beta 버전에서는 새로운 기능을 추가하는 것과 동시에 개발자 도구 모음의 기능을 원래대로 하여, 이미 친숙한 기능을 사용할 수 있도록 할 예정입니다.

플랫폼의 비주얼 인터페이스

IE8 Developer Tools에서는 디버그 프로세스 간소화에 추가하여, 사이트에 관한 새로운 분석 관점이 제공됩니다. 단순히 관련된 Internet Explorer 의 내부표현을 표시할 수 있습니다. 예를 들어, 이 도구의 DOM 트리는 소스를 사용하는 것이 아니라, IE 가 내부에 생성한 트리를 사용하여 페이지를 표시합니다. 따라서, 스크립트 또는 트리를 변경하면, IE8에서도 업데이트한 트리가 표시됩니다. 요소의 스타일 정보를 표시하여, 다음과 같이 어느 규칙이 적용되는지 또는 어느 규칙이 기존의 스타일 속성을 지정할지를 훨씬 더 잘 이해할 수 있습니다.

검증 고속화

또, Internet Explorer 8 Developer Tools 는 IE 내부에서 사이트를 편집하여, 검증과 반복을 신속하게 실시할 수 있습니다. 예를 들어, 관심 있는 스타일 규칙이나 속성이 있으면, 그것을 유효화 또는 무효화하는 체크 박스를 클릭하거나 DOM 트리의 특성을 클릭하여, 그 자리에서 편집합니다.

이 도구를 사용하면, 이용 가능한 모든 표시 모드에 액세스가 쉽기 때문에 다른 모드를 빨리 테스트 할 수 있습니다.

변경 저장, 응용 프로그램 간의 변환, 페이지 업데이트를 할 필요가 없기 때문에 테스트, 디버그, 검증을 보다 빠르고 쉽게 실시할 수 있습니다.

그 외의 정보

Internet Explorer Developer Tools 에 대한 자세한 내용은 다음의 리소스를 참조해 주세요.

Internet Explorer 8 Beta 1 베타 버전을 다운로드하여 도구를 시험하고, 사용 소감을 보내 주세요.
Developer Tools 백서 (영어)
Developer Tools SDK 페이지 (영어)
데모 비디오 : 소개 (영어)(비디오 버전 )
데모 비디오 : 디버그 (영어)( 약 6 분 )
Internet Explorer 8 Beta 1 출시 노트

감사합니다.

John Hrvatin
프로그램 매니저
Internet Explorer

편집 : 「호환성 모드」의 이미지 업데이트

영문 원본 :Improved Productivity Through Internet Explorer 8 Developer Tools

업데이트 일: 2008 년 3 월 7 일

IE8 즐겨찾기 모음

HK Yoo — Fri, 20 Mar 2009 10:26:04 GMT

안녕하세요, Internet Explorer 의 User Experience 팀의 프로그램 매니저 헬렌입니다. IE8 의 즐겨찾기 모음을 소개하게 되어 영광입니다.

즐겨찾기 모음의 새로운 기능 :

지금까지 링크 막대라 부르던 즐겨찾기 모음에 새로운 기능이 추가되어 즐겨 찾기의 웹 사이트 정보를 빠르고 쉽게 표시할 수 있습니다. IE8 의 새로운 즐겨찾기 모음에는 한번만 클릭하면 바로가는 즐겨 찾기 링크가 있지만, 웹 조각(IE8 의 새로운 기능 )과 피드도 즐겨찾기 모음에 추가되어 탐색이 더욱 쉬워집니다. 즐겨찾기 모음의 웹 조각와 피드에서는 즐겨 찾기의 웹 사이트로 이동하지 않고 그 컨텐츠가 업데이트 되었는지 확인할 수 있습니다.

다음에 보이는 즐겨찾기 모음에는 피드, 피드를 보관한 폴더 및 웹 조각이 포함되어 있습니다.

웹 조각(WebSlice) 소개

제인이 이전에 그녀의 블로그 「Internet Explorer 8 의 새로운 기능 : Activities 와 WebSlice」에서 설명했듯이, 웹 조각(WebSlice)이라는 IE8 의 새로운 기능을 사용하면, 옥션 가격, 최신 뉴스 등, 즐겨 찾기의 웹 사이트에 업데이트 된 컨텐츠를 바로 표시할 수 있습니다. 웹 조각(WebSlice)이란, 구독할 수 있는 웹 페이지의 부분 (“Slice ”)입니다. 구독한 웹 조각은 즐겨찾기 모음에 바로 가기로서 표시됩니다.

웹 조각이 표시되는 것은 웹 조각을 지원하는 웹 페이지만이라는 것에 주의해 주세요. 현시점에서는 Ebay , Facebook , Stumble Upon 등의 웹 사이트가 웹 조각(WebSlice) 지원을 추가했습니다. 자신의 웹 사이트에 웹 조각 지원을 추가하는 방법은 Internet Explorer 8 Beta 1 백서 (영어)를 참조해 주세요.

웹 조각(WebSlice) 사용 방법

웹 페이지에서 웹 조각을 추가할 수 있는지를 확인하는 방법은 두가지 있습니다. 하나는 명령 모음에서 웹 조각 버튼의 색깔이 변합니다.

웹 페이지의 웹 조각에 마우스를 이동하면, 컨텐츠 옆에 웹 조각 아이콘도 표시됩니다. 이 아이콘은 즐겨찾기 모음에 추가할 수 있습니다. 다음에 예를 보여줍니다.

즐겨찾기 모음에 웹 조각을 추가하려면 명령 모음의 웹 조각 버튼을 클릭하거나 페이지의 웹 조각 아이콘을 클릭합니다.

IE8에서는 즐겨찾기 모음의 바로 가기 텍스트를 보면, 항목 상태를 알 수 있습니다. 웹 조각이 앞에서 사용한 뒤에 업데이트 되면, 텍스트가 굵은 글씨가 되고, 웹 조각의 유효기간이 다가오는 경우는 텍스트가 굵은 글씨의 기울임꼴, 유효기간이 끝나면 회색이 됩니다. 이 정보는 옥션 아이템을 체크하는 경우 등에도 많은 도움이 됩니다.

IE8 의 즐겨찾기 모음을 사용하면, 현재 열람하고 있는 웹 사이트에서 이동하지 않고 , 업데이트된 웹 조각의 컨텐츠를 미리 보기 할 수 있습니다. 즐겨찾기 모음의 웹 조각 바로 가기를 클릭하면, 웹 페이지를 미리 보기할 수 있고, 그 페이지를 클릭하면 그 웹 사이트로 이동할 수 있습니다.

웹 조각 미리 보기 ：

즐겨찾기 모음에 피드 추가

IE8에서는 즐겨찾기 모음에 피드를 추가할 수 있습니다. 피드를 구독하면, 컨텐츠가 업데이트 되었는지 즐겨찾기 모음에서 볼 수 있습니다.

아시는 바와 같이 피드를 구독하고, 즐겨찾기 모음에서 보려면 우선 [Feed Discovery (피드 탐색)] 를 클릭하여 피드를 표시한 후, 피드 페이지에서 [Subscribe to this Feed (이 피드 구독) ] 를 클릭합니다. 이 피드를 즐겨찾기 모음에서 보려면 [Add to Favorites (즐겨 찾기에 추가)] 를 클릭하여, [Monitor on Favorites Bar (즐겨찾기 모음에서 보기)] 를 클릭합니다. 즐겨 찾기 센터에서 즐겨찾기 모음에 피드 또는 피드의 폴더 전체를 드래그 엔드 드롭 할 수도 있습니다.

즐겨찾기 모음에서 피드의 바로 가기를 클릭하면, 기독의 피드 항목 (표준문자)과 미독의 피드 항목 (굵은 글씨)을 간단하게 구별할 수 있습니다.

그외 힌트와 바로 가기

[Add to Favorites (즐겨 찾기에 추가)] 를 사용하여 링크를 추가하는 것과 함께, 즐겨찾기 모음에 링크를 드래그 엔드 드롭 하거나 주소 표시줄에서 즐겨찾기 모음에 웹 페이지의 아이콘을 드래그 하거나 웹 페이지에서 즐겨찾기 모음에 링크를 직접 드래그할 수 있습니다.
즐겨찾기 모음의 항목을 정리하려면 항목을 드래그하여 이동하거나, 폴더를 생성하여 즐겨 찾기 링크, 웹 조각 및 피드를 폴더내에 드래그 엔드 드롭 합니다.
폴더내의 항목이 업데이트되면, 폴더 자체가 업데이트 상태로서 표시됩니다. 폴더를 열지 않아도 폴더가 굵은 글씨가 아닌 경우는 폴더내 항목이 업데이트 되지 않은 것을 알 수 있습니다.
즐겨찾기 모음을 사용한 탐색도 편리합니다. 즐겨찾기 모음의 첫번째 항목에 커서를 이동하려면 Alt 키와 B키를 같이 누릅니다.
즐겨찾기 모음은 일반적링크와 같이 탭과 윈도우 바로 가기를 지원합니다. 예를 들어, 즐겨찾기 모음의 항목 또는 폴더를 Ctrl키를 누르면서 클릭하거나 내부를 클릭하면, 이 항목 또는 이 폴더의 컨텐츠가 배경의 하나 또는 여러 개의 새로운 탭에서 열립니다.
마찬가지로 즐겨찾기 모음 항목을 Ctrl키를 누르면서 Shift키를 눌러 클릭하면, 전경의 탭에 이 항목이 열립니다.

이상은 IE8 즐겨찾기 모음을 사용하여 즐겨 찾기 웹 페이지 정보를 빠르고 간단하게 표시하는 방법을 소개했습니다.

IE8 Beta 1 을 시험해 주셔 감사합니다. 이 기능에 대한 여러분들의 피드백을 기다리겠습니다.

Helen Drislane
프로그램 매니저

영문 원본 :The IE8 Favorites Bar

업데이트 일: 2008 년 3 월 12 일

애드온 성능 설계

HK Yoo — Fri, 20 Mar 2009 10:22:43 GMT

최근 Internet Explorer 8 Beta 1 출시를 위해 개발중인 IE 팀은 성능에 심혈을 기울이고 있습니다. IE 향상을 위한 노력의 일환으로 실행한 조사에서, 몇가지 애드온에 성능상의 문제가 있다는 것을 알았습니다. 이 글에서는 우리가 발견한 공통의 테마를 이야기합니다.

우선 먼저 이 블로그에 관한 피드백을 IE Beta 뉴스 그룹이나 around the web (영어) 를 통해 주신 여러분에게 감사합니다. Internet Explorer 팀은 IE8 의 성능에 관해서 열심히 노력을 계속하고 있으며, 초기 단계에서 성과로 이어진 것을 매우 기쁘게 생각합니다. 아직 개선의 여지 (와 계획)는 있지만, IE8 Beta1 의 성능 개선에 관한 자세한 내용은 개발자 백서 (영어)를 참조해 주세요.

IE 의 애드온 개발이 처음으로, 참조가 필요한 경우에는 다음의 몇가지 링크에서 시작하는 것을 권장합니다.

Visual Studio 2005 의 브라우저 도우미 개체 개발 (영어)
안정된 브라우저 확장기능 생성 (영어)
애드온 개발 (영어)

대략적으로 말하면, 애드온 성능 문제는 일반적으로 두가지 영역에서 IE 사용자에 영향을 줍니다.

IE 윈도우 또는 각각의 탭 열기/닫기
브라우저 반응

윈도우나 탭이 열리고 닫히는 속도는 생성될 때마다 부하가 높은 일을 많이 실행하는 애드온에 크게 영향을 받습니다. 특별히 공통된 문제의 하나는 브라우저를 실행하거나 종료하는 동안에 애드온이 업데이트를 확인하는 것입니다.

레지스트리를 잘못 사용하면 반응을 느리게 만듭니다. 이것은 공통된 문제의 하나입니다. 애드온의 상당수는 부하가 높은 레지스트리 조작을 실행하지만, 이것은 Internet Explorer 반응을 저하시킬 가능성이 있습니다.

다음에서 이 두가지 영역을 설명하고, 애드온 성능을 설계할 때의 지침을 몇가지 소개합니다.

애드온 초기화와 업데이트 확인

원칙 1 : 무리하지 않음 : 힘든 일은 다른 스레드에 맡김
원칙 2 : 부스에 도착한 후 요금을 지불

시작할 때, Internet Explorer 는 레지스트리를 조사하여, 설치된 애드온을 확인합니다. 브라우저 도우미 개체 또는 도구 막대가 설치된 것을 IE 가 검색하면 CoCreateInstance 를 호출하여, 설치되어 유효한 애드온을 인스턴스화합니다. Internet Explorer 는 기본적으로 애드온을 인 프로세스 서버로서 생성하여, IE 의 메인 UI 스레드 중에서 실행합니다. 하위호환성을 위해 Internet Explorer 는 열린 각 탭에 대해서 이러한 단계에 따릅니다. 이 동작은 몇가지 이유 때문에 중요합니다. 그 이유는 애드온이 직면한 가장 일반적인 문제를 설명하면 이해하실 수 있을 것입니다.

무리를 하지 않는 : 힘든 일은 다른 스레드에 맡긴다

일반적으로 많은 애드온에서 공통된 경향의 하나는 온라인 컨텐츠와의 통합입니다. 라이브 데이터에 관해서 이 통합화를 유지하려면 항상 업데이트 메커니즘이 필요합니다. 조사한 결과에 따르면 많은 경우에 초기화 동안에 IE 가 제어를 애드온 SetSite 구현에 전달할 때, 애드온은 동기 업데이트 확인을 실행합니다. 다음은 Internet Explorer에서 애드온이 초기화되는 방법에 대한 설명으로, 이러한 종류의 업데이트 확인이 어떤 영향을 미치는지를 추측할 수 있습니다. 다음과 같은 흐름을 생각해 주세요.

IE 가 초기화 시작
Foo 도구 막대가 설치된 것을 IE 가 검색
IE 는 Foo 도구 막대의 SetSite 메서드 호출
업데이트 된 컨텐츠를 확인하기 위해, Foo 도구 막대는 http://foo.example.com 에 액세스
Foo 도구 막대는 IE 에 제어 반환
IE 는 초기화를 계속하여 사용자 홈 페이지 표시

문제가 이해 되셨나요? 단계 4를 생각해 주세요. 만약, Foo 도구 막대가 업데이트해야 할 컨텐츠를 다수 찾아내거나, 컨텐츠 서버와의 접속이 늦어지거나 또는 사용자가 오프라인으로 작업하면 어떻게 될까요? 대답은 (애드온은 UI 스레드의 문맥내에서 실행되므로 ) 도구 막대를 위해서, IE 가 장시간 반응하지 않게 되거나 실행과 종료의 소요 시간이 크게 늘어납니다. 보다 좋은 방법은 작업 스레드를 생성하여, 컨텐츠 업데이트를 비동기로 실시하는 것입니다.

추천 방법은 SHCreateThread (영어) (애드온을 C++ 로 개발 한 경우)를 다음과 같이 사용하는 것입니다.

STDMETHODIMP SetSite(IUnknown* pUnkSite)

{

if (pUnkSite != NULL && IsUpdateRequired())

{

SHCreateThread(Update, NULL, CTF_COINIT | CTF_PROCESS_REF, NULL);

}

else

{

// Release cached pointers and other resources here.

}

// Return the base class implementation

return IObjectWithSiteImpl<CHelloWorldBHO>::SetSite(pUnkSite);

}

DWORD WINAPI Update(LPVOID pParam)

{

DWORD dw = 1;

// Perform update here

return dw;

}

DWORD WINAPI IsUpdateRequired()

{

DWORD dw = 1;

// Perform a low-cost check here to verify that an update should be

// performed. This can be accomplished by checking a registry key.

return dw;

}

앞에서 말한 바와 같이, SetSite 는 신규 스레드를 생성하여 업데이트 메서드를 실행하는 것에 주의해 주세요. 이 방법을 이용하면, SetSite 가 장시간 UI 스레드를 차단할 위험이 없고, 애드온은 컨텐츠를 업데이트할 수 있습니다. 또, 적절한 빈도 (2 , 3 매일등 )로 업데이트 확인을 실시하여, 브라우저나 탭을 열 때마다 업데이트를 확인하는 부담을 사용자에게 주지 않고 애드온을 빠르게 업데이트 할 수 있습니다.

이 방법을 사용하면 장시간 계속되는 처리를 IE 메인 UI 스레드에서 제외할 수 있어 체감상의 성능을 향상시킬 수 있습니다. 다만, 작업 스레드 작업이 반드시 좋은 방법은 아니라는 것은 알고 있어야 합니다. 잠재적인 문제는 여러가지 있습니다. 예를 들어, 작업 스레드에서 이행하는 장점보다, 부하가 높은 스레드에 걸치는 많은 COM 호출 부하가 더 클 가능성이 있습니다.

부스에 도착하고 나서 요금을 지불한다

장시간의 조작을 작업 스레드에서 이행하는 것으로, UI 행을 회피할 수 있습니다. 그럼에도 불구하고, 애드온이 초기화될 때마다, 사용자는 지불할 필요가 없는 비용을 미리 선불해야 할 가능성이 있습니다. 사용자는 IE 를 실행 할 때에 업데이트 컨텐츠를 잘 이용하지 않는 경우가 자주 있습니다. 이러한 경우에서는 사용자와 컨텐츠 공급자 모두가 거기에 알맞은 이익이 없음에도 불구하고, 업데이트 확인에 수반하는 불필요한 비용을 지불합니다.

컨텐츠 업데이트를 실시하는 궁극의 방법은［업데이트 확인］메뉴 항목을 클릭하고, 사용자가 명시적으로 신규 컨텐츠를 요청할 때만 업데이트를 실시하는 방식입니다. 그렇지만, 이 해결책은 애드온 성능을 떨어트릴 가능성이 있기 때문에 많은 경우에 비현실적인 방법입니다. 예를 들어, 드롭 다운 메뉴를 클릭했을 때, 업데이트 컨텐츠가 다운로드되는 동안, 부수된 드롭 다운 메뉴의 표시를 잠깐이라도 기다려야 한다면, 참기 어려울 것입니다.

더 효과적인 방법으로 사용자 경험과 선불 비용의 균형을 맞추는 기술은 그 밖에 여러 가지 있습니다. 예를 들어, 도구 막대 개발자는 업데이트 확인을 SetSite에서 완전히 이동하여, 사용자가 처음 마우스를 도구 막대 위에 움직였을 때 또는 고정 스케줄에서 업데이트 확인하는 것이 좋을 수도 있습니다. 최적의 해결책은 애드온 마다 다르기 때문에 항상 크리에이티브한 것, 그리고, 가능한 사용자에게 고정된 부담을 주지 않도록 노력하는 것이 중요합니다.

거의 모든 경우에 SetSite 또는 OnDocumentComplete 처리기에서 많은 작업을 회피할 수 있는 방법이 있습니다. 이러한 영역에서 문제를 해결하고, 여분의 시간을 할애하는 것은 성능 문제를 회피하고, 사용자가 확실하게 애드온을 설치할 수 있는 아주 좋은 방법입니다.

레지스트리 사용

원칙 3 : 캐싱 활용
원칙 4 : 나쁜 버릇을 멈춘다 (플러시 금지 )

캐싱을 활용한다

레지스트리 사용에서 연상되는 것은 1996 년 즈음에 유행했던 마카레나 (영어)입니다. 단계를 알고 있는 사람은 극히 소수이지만, 춤을 잘 출 수 있는 사람은 훨씬 더 적었지만, 모두가 참여하는데 그 사실이 전혀 방해되지 않았습니다. 레지스트리의 과도한 사용은 Windows 응용 프로그램에서는 일반적이고, IE8에서는 레지스트리 액세스를 줄이기 위해서 상당한 노력을 했습니다.

레지스트리의 과도한 사용이 꺼려지는 것은 레지스트리 조작의 오버헤드가 중대한 문제가 될 가능성이 있기 때문입니다. 캐시 키의 개폐나 로드는 몇만 주기 분의 부하가 될 수 도 있습니다. 시작시에 각각의 애드온이 수백, 수천, 때로는 수만번 레지스트리에 액세스 하는 것은 비교적 보통이므로, 액세스 수가 누적하면 브라우저가 급속하게 늦어집니다.

다행히, 레지스트리 사용의 부하를 줄이는 것은 가능합니다. 무엇보다도 우선, 공통의 경우에서 최적화합니다. 애드온 실행중, 대부분의 레지스트리 값은 변경되지 않기 때문에 값을 한 번 로드하여 캐시에서 유지하면 각 레지스트리에의 액세스 회수를 크게 줄일 수 있습니다.

레지스트리에의 액세스는 배제할 수 없지만, 나머지 조작의 부하는 줄일 수 있습니다. 레지스트리의 완전 경로 (HKEY_LOCAL_MACHINE\Foo\Bar 등 )를 사용하여 키에 액세스 하는 것은 주어진 루트에서 대상 키까지의 계층수에 의해, 상대경로에 비해 2 , 3 배의 부하가 걸립니다. 애드온에서는 일반적으로, 설정 대부분이 키나 소수의 키 집합의 아래에 있습니다. 예를 들어, 애드온에서 IE 에서 사용되는 연결을 취득해야 합니다. 이 경우, 다음의 레지스트리키에 액세스해야 합니다 (HKEY_LOCAL_MACHINE 아래 ) .

\SOFTWARE\Microsoft\Internet Explorer\Capabilities\FileAssociations

\SOFTWARE\Microsoft\Internet Explorer\Capabilities\MIMEAssociations

\SOFTWARE\Microsoft\Internet Explorer\Capabilities\UrlAssociations

Win32 메서드 RegOpenKey 를 사용하면, 다음에 발췌한 것 같은 코드로 각 regkeys 에 액세스 할 수 있습니다 (예로서 FileAssociations 를 사용합니다) .

HKEY hk;

RegOpenKey(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\Internet Explorer\\Capabilities\\FileAssociations", &hk);

나머지 키는 HKEY_LOCAL_MACHINE 를 루트로 하여 같이 액세스 할 수 있습니다. 그렇지만, 이 경우 더 좋은 방법은 Capabilities 키의 핸들을 생성하여, 추가의 상대경로 RegOpenKey 조작을 실시해서, 나머지 값을 취득하는 것입니다. 그 방법은 다음과 같습니다 (다시, 예로서 FileAssociations 를 사용합니다 ) .

HKEY hkRoot;

RegOpenKey(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\Internet Explorer\\Capabilities", &hkRoot);

HKEY hkFileAssoc;

RegOpenKey(hkRoot, L"FileAssociations", &hkFileAssoc);

나쁜 버릇을 고치다(플러시 금지)

마지막으로, 레지스트리 값이 확실히 디스크에 써지도록,RegFlushKey 를 사용하는 애드온이 과거에 있었습니다. 상황에 따라서는 다른 탭이나 윈도우에서 실행중의 애드온 두가지의 인스턴스 간의 상태를 유지하기 위해서 이 처리를 실시합니다.

RegFlushKey 에 관한 MSDN 문서 (영어)에서 말한 것처럼, 이 API 를 사용할 필요는 거의 없습니다. 또한 레지스트리를 백업하는 모든 데이터가 확실히 디스크에 쓰여지도록 하기 위해,RegFlushKey 호출은 놀라울 정도로 부하가 높아질 가능성이 있습니다. 이 처리는 호출한 프로그램에 제어가 반환될 때까지 수백 밀리 초가 소요될 가능성이 있습니다. 그리고, 단점은 그 처리가 완료할 때까지, 레지스트리 액세스가 차단됩니다.

결과적으로,RegFlushKey 호출은 IE 에 영향을 줄 뿐만 아니라, 시스템 전체의 성능을 저하시킬 가능성이 있습니다. 인스턴스간의 동기에게 이 레지스트리를 사용하는 애드온은 레지스트리를 플러시하는 것보다도 상태 유지에 RegNotifyChangeKeyValue (영어)를 사용할 수 있습니다. 자세한 것은 다음에 있는 랠리·오스타만과 레이몬드·첸의 블로그 글을 참조해 주세요. 레지스트리 사용에 관한 것으로, 도움이 될 것 입니다.

심리적 성능 분석 또는「RegFlushKey 는 정말로 레지스트리키를 플러시 한다」 (영어) (랠리·오스타만)
레지스트리키 읽기 성능 비용 (영어) (레이몬드·첸)

애드온 성능 개선에 관한 말씀드린 내용이 지금까지 접한 공통 문제의 몇가지를 이해하는데 도움이 되기를 바랍니다.

Internet Explorer 의 에코시스템에 훌륭한 애드온을 제공해주어 감사합니다. 여러분의 피드백을 기다리겠습니다.

Christian Stockwell
프로그램 매니저
성능 담당

편집 : 다음의 행에 Root 를 추가 : RegOpenKey(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\Internet Explorer\\Capabilities", &hkRoot);

영문 원본 :Designing for Add-on Performance

업데이트 일: 2008 년 4 월 8 일

Internet Explorer 8 의 IT 관리자용 새로운 기능

HK Yoo — Fri, 20 Mar 2009 10:21:04 GMT

올랜도에서 개최된 Tech Ed IT Pro 2008 (영어) 에서 Internet Explorer 8 을 조직내에서 배포, 관리하기 위해, 몇가지 기능을 강화했다고 발표했습니다. Tech Ed IT Pro 2008에서 발표된 내용의 일부를 이 블로그에서도 공개합니다.

작년 2000 명 이상의 IT 관리자가 조직내에서 하드웨어와 소프트웨어를 배포, 관리하는데 있어 관심사와 우선 순위에 대해 조사했습니다. 이 결과에서 IT 관리자는 여러 가지 문제를 (30 가지 이상의 다른 사안들) 고심한다고 판명되었습니다. 많은 IT 관리자에서는 아래와 같은 사안을 보고해 주었습니다.

신기술 배포와 구현
업데이트와 업그레이드 관리
응용 프로그램 호환성
데이터, 네트워크, 시스템 보안

Internet Explorer 7 에는 강력한 배포와 관리의 사례가 있어, IT 관리자는 아래와 같은 기능을 이용할 수 있습니다.

Internet Explorer Administration Kit (영어) (IEAK)를 사용하여, 접속 설정등을 사전에 설정한 사용자 지정 빌드 생성과 브랜드화
그룹 정책 (영어) 에 의한 브라우저 설정 집중관리
Windows Update, Windows Server Update Services (WSUS), System Management Server (SMS), Active Directory 등에 의한 배포나 관리

배포와 관리에 추가하여, Internet Explorer 7에서는 보다 안전한 웹 브라우징과 기업내 데이터, 네트워크, 시스템 보호를 위한 몇가지 새로운 기능을 도입했습니다.

피싱 필터
ActiveX 옵트인
EV (Extended Validation)에 의한 인증

Internet Explorer 7 은 IT 관리자들의 관심에 대해 어느 정도 대처 가능했지만, 몇가지 점에서는 좀 더 개선 가능한 여지가 있었다고 생각합니다.

Tech Ed IT Pro 2008 에서 몇가지 새로운 기능에 대해 설명을 했습니다.

Slipstream지원

Internet Explorer 7 을 Windows XP 의 일부로서 배포가 어렵다는 피드백을 받았습니다. 다수의 IT 관리자가 Windows XP 표준에 Internet Explorer 7 이 포함 되기를 원하여, Windows Vista와 Windows Server 2008 에는 Internet Explorer 7 이 표준으로 탑재됩니다. Windows XP 의 경우, Windows XP 설치 후에 Internet Explorer 7 을 설치한 후 하드 디스크 이미지를 recapture 합니다. 이 조작에는 약 2 시간 정도가 소요됩니다.

Internet Explorer 8과 Windows Vista 환경에서는 「Slipstream」라고 불리는 기능을 이용하여, 작성된 이미지 파일에 Internet Explorer 8 을 통합할 수 있습니다. Slipstream 기능을 이용하면, 10 ~15 분 정도로 Internet Explorer 8 을 통합할 수 있습니다. Slipstream를 이용하여 배포하는 Internet Explorer 8 에는 최신의 누적 업데이트와 보안 업데이트를 포함할 수도 있습니다. Slipstream 기능에 대한 자세한 내용은 앞으로의 글을 기대해 주세요.

응용 프로그램 호환성과 Internet Explorer 8

이 블로그에서는 렌더링 모드를 기본값에 설정한 상태로 Internet Explorer 8 을 출시할 것인가 (영어)에 대해 활발한 토론을 했습니다. 웹 표준에 맞도록 설계된 웹 사이트가 적기 때문에 Internet Explorer 8 이 어떻게 사이트를 표시할지는 사용자와 웹 개발자에 제어를 맡기기로 했습니다.

IT 관리자는 사내 응용 프로그램이나 웹 사이트의 잠재적인 문제 해결에 도움이 되는 새로운 이벤트를 Application Compatibility Toolkit (ACT)에 추가했습니다. 새로운 그룹 정책 설정 항목을 추가하여 상호 호환성 문제에 대처할 수 있습니다. 우리는 보안, 성능, 안정성을 유지하면서 응용 프로그램이나 웹 사이트의 호환성 유지를 목적으로 계속 인트라넷에서 발생하는 문제를 신속하게 해결하기 위한 솔루션을 모색하고 있습니다.

Internet Explorer 8 보안

인터넷은 우리들의 일과 생활에 변화를 가져왔습니다. 우리들은 많은 시간을 인터넷을 하며 보내고 있는데, 이것이 악의적인 목적을 가진 사람들을 끌어들이는 원인이 되기도 합니다. 피싱 사기 사이트나 맬웨어를 설치하는 사이트 등, 웹은 위험한 장소가 되어가고 있습니다. 친구나 지인이 피싱 사기 사이트를 방문하거나 수상한 소프트웨어 설치를 막을 수 있는 사람은 아무도 없습니다. 컴퓨터를 잘 아는 친구가 뒤에서 지켜주지 않을 때에 그들에게 어떤 일이 일어날까요? 피싱 사기에 의해서 30 억 달러 이상의 손해가 발생하고 있다는 것을 알고 계신가요? Internet Explorer 8 은 피싱 사기와 같은 범죄로 부터 사용자를 지키기 위해서 중요한 역할을 완수합니다.

웹 브라우징을 안전하게 실시하기 위한 몇가지 방법을 이미 제시하고 있습니다.

IEAK 업데이트

Internet Explorer Administration Kit (IEAK)는 IT 관리자가 환경에 따라 Internet Explorer 의 사용자를 지정할 수 있습니다. Internet Explorer 6 및 7에서도 이 도구는 이용 가능하여 이미 친숙할지도 모릅니다. IEAK 8 은 마이너 버전업 입니다. IEAK 8 은 몇가지 문제를 개선하여, IEAK 의 성능을 향상시키기 위한 새로운 기능을 탑재했습니다. IEAK 8 은 Windows Vista 와 Windows Server 2008 에 대응하여, 액티비티, 웹 조각(Web Slice) 라는 새로운 기능을 지원합니다.

IEAK 8 의 세부 사항에 대한 정보는 이 블로그에서도 공개할 예정이오니 기대 주세요.

요약

2008 년 8 월 공개 예정인 Internet Explorer 8 Beta 2 에 위의 기능을 모두 탑재할 예정입니다. 현재, 순조롭게 개발이 진행되고 있어 모든 기능이 탑재 가능하지만, 일부 기능에 문제가 발생한다면, Beta 2 탑재를 보류하게 될 수 도 있습니다.

Internet Explorer 7 은 엔터프라이즈 또는 비즈니스환경에서의 배포와 관리가 뛰어난 브라우저였습니다. Internet Explorer 8 은 그것을 계승하여 한층 더 확장시켰습니다.

Jane Maliouta - IE Program Manager
James Pratt - IE Product Manager

영문 원본 :What's Coming in Internet Explorer 8 for IT Professionals?

업데이트 일: 2008 년 6 월 11 일

Internet Explorer 8 스마트 주소 표시줄 Part 1 : 쉽고 빠른 안내

HK Yoo — Fri, 20 Mar 2009 10:10:03 GMT

Internet Explorer 8 Beta 1에서 주소 표시줄에 대해서 실시한 몇가지 기술적인 안내 (도메인 하이라이트 기능, 여러 행 붙이기 기능, 클릭 동작 개선 등)을 이전에 채택했습니다. Internet Explorer 8 Beta 2는 탐색을 보다 쉽고 간단하게 한다는 데에 목표에 두고 크게 변경하였습니다.

Internet Explorer 8 Beta 2 를 실행하고, 주소 표시줄에 문자를 입력하면, Internet Explorer 8 은 방문한 적이 있는 사이트의 URL 뿐만 아니라, 제목이나 그 외의 속성에도 기초를 두고 결과를 반환합니다. 제목과 주소 (URL)의 각각 적합한 것을 표시하고, 한층 더 적합한 부분을 간단하게 확인할 수 있도록 하이라이트 표시를 하도록 형태가 업데이트 됩니다. 다음은 스크린 샷입니다.

새로운 드롭 다운 목록은 쉽게 시각적으로 (영어) 검색하며(영어), 그룹화 된 결과를 표시하고 (자세한 내용은 나중에 설명합니다) , 관련성 (relevancy) 알고리즘에 의해서 정렬이 실행되어 (이쪽도 자세한 내용은 나중에 설명합니다) , 입력 내용에 따라 교묘하게 하이라이트 합니다.

Internet Explorer 7 의 기능과 이 기능의 차이는 주목할 만합니다. 예를 들면, 저는 자주 축구 (풋볼이 좋을까요) 관람과 플레이를 하지만, 유감스럽게 Internet Explorer 7 은 축구 사이트에 쉽게 찾아 가는데 그다지 도움을 주지 않았습니다. "soccer" 라는 말에서 시작되는 도메인 이름을 가지는 사이트만 표시되기 때문에 (유일한 예외 (영어)는 있지만) , 제목 없이 어떤 페이지인지를 분별하는 것은 매우 어렵습니다.

Internet Explorer 8에서는 보다 많은 결과를 얻을 수 있을 뿐만 아니라, 어떤 사이트인지도 간단하게 알 수 있습니다. Internet Explorer 7 과 비교하면, 일목요연해 집니다. (이 스크린 샷에서는 검색 기록 부분을 배포합니다.)

Paul 이 지적했던 대로, 이 변경은 보다 적은 조작으로 흥미 있는 사이트를 찾는 시간을 절약하여 그 사이트에 많은 시간을 사용할 수 있다는 것을 의미합니다.

Internet Explorer 8에서 쉽게 찾기

Internet Explorer 8 의 스마트 주소 표시줄 제시된 자동 완성 항목은 여러 단어 검색도 지원합니다. 입력한 모든 단어에 합치된 검색 결과가 표시되어, 입력을 많이 하면 검색 결과가 보다 정선됩니다.

페이지 제목이나 주소, RSS 피드와 즐겨

찾기의 전체에서 검색이 가능하고, 로컬 이름이나 폴더 이름에서도 똑같이 검색할 수 있습니다. Feed 아이템을 위해서, 아이템 제목에서 검색할 수도 있습니다. Internet Explorer 는 기본값에서 접두어 분리 검색을 실시하여, "Be" 는 "Beijing" 에 적합하지만, "jing" 는 적합하지 않습니다 (접두어 분리 검색은 모든 단어의 전방에서 검색하는 것을 의미합니다) .

폴더 : 이미 사용하고 있는 태그

대부분의 사람들이 즐겨 찾기를 폴더로 분류하기 때문에 즐겨 찾기와 피드 폴더의 계층을 태그가 있는 시스템으로 간주할 수 있습니다. 즐겨 찾기 또는 피드의 폴더 이름을 입력하면, 그 폴더 하단에 있는 모든 즐겨 찾기 또는 피드가 선택 추천의 결과 집합으로서 돌아갑니다. 예를 들어 "restaurants" 를 검색했을 경우, Restaurants 폴더 안에 있는 모든 즐겨 찾기 항목은 제목이나 로컬 이름, URL 에 "restaurants" 가 포함되지 않아도 추천 결과로 표시됩니다.

가고 싶은 곳에 가기 위해서 새로운 드롭 다운 목록 사용

검색 결과는 다음의 6 개 섹션으로 그룹화 됩니다 : 입력한 주소, 제시된 자동 완성 항목 추천, 검색 기록, 즐겨 찾기, 피드, 키보드 바로 가기.Internet Explorer 는 각각의 섹션별 이용 가능한 검색 결과를 모두 표시합니다 (예외적으로 특정의 키 입력을 입력했을 때에 표시되는 키보드 바로 가기 섹션은 제외합니다 ) .이와 같이 간단하게 결과를 필터링하기 위해서 제어 문자 등을 기억할 필요도 없습니다. 다른 브라우저와 달리, Internet Explorer 8 은 RSS 피드와 피드에서 다운로드한 아이템을 읽었는지 안 읽었는지 표시합니다. 이것은 읽기는 했지만, 어디까지 읽었는지를 기억하지 못할 때에 도움이 됩니다. Internet Explorer 8 은 모든 것이 어디에서 왔는지 간단하게 분별할 수 있습니다.

입력한 주소(Typed Address)

맨 위의 섹션 (msnbc.com 가 제목 없이 표시된 부분)은 주소 표시줄에 수동으로 입력한 주소입니다. 이 섹션은 주소 표시줄의 아래에 직접 표시되어 머리부분이 없습니다. (OS 에 따라서 다른 결과가 나오는 것을 방지하기 위해) . Internet Explorer 는 5 개까지 입력된 주소를 표시하고, 결과는 알파벳 순서에 따라 정렬할 수 있습니다.

제시된 자동 완성 항목 추천(Autocomplete Suggestion)

제시된 자동 완성 항목 추천은 입력 내용에 근거하여 " 가장" 적절한 것으로, 항상 SHIFT+ENTER 바로 가기를 이용할 수 있습니다. 제시된 자동 완성 항목 추천은 beta 1에서 이용 가능한 Inline Autocomplete 기능을 대신합니다. 표시 방법은 다르지만, 본질적으로는 같은 기능이지만 가장 적절한 검색 결과를 결정하는 관련성 엔진 덕분에 좀더 똑똑해졌습니다. 제시된 자동 완성 항목 추천에 대해서는 앞으로 글을 쓸 예정입니다.

검색 기록(History)

웹 페이지를 브라우징할 때마다 (InPrivate 브라우징 모드 제외) , Internet Explorer 는 검색 기록이 있는 페이지 컬렉션의 일부로서 내부적인 "검색 기록" 저장소에 페이지를 씁니다. 드롭 다운 메뉴의 이 섹션은 그 컬렉션에서 적합한 상위의 것을 표시합니다. 즐겨 찾기나 피드를 클릭 했을 경우도 이전에 검색한 웹 사이트의 경우도 방문하는 모든 페이지가 최종적으로는 여기에 안정됩니다. 즉 대부분의 경우 (열람 검색 기록의 삭제한 직후 제외) , 검색 기록에서 선택된 몇가지 선택사항이 있어, 검색 기록의 맨 위에 있는 아이템은 Internet Explorer 8 의 제시된 자동 완성 항목 추천으로서도 선택됩니다. Internet Explorer 는 기본값에서는 상위 5 번까지의 적합한 검색 기록을 표시하고, 확장하면 최대 20 개까지 표시할 수 있습니다.

즐겨 찾기(Favorites)

여기는 입력 내용과 적합한 즐겨 찾기 항목이 표시되는 장소입니다. 최근, 방문한 즐겨 찾기 사이트는 검색 기록 항목에도 적합할지도 모릅니다. 주소 표시줄에 입력할 때, 즐겨 찾기의 로컬 이름, URL , 포함된 폴더 이름을 기본으로 검색해 주세요. Internet Explorer 는 기본값에서는 적합한 5가지 항목의 즐겨 찾기를 표시하고, 확장하면 최대 20 개까지 표시할 수 있습니다.

피드(Feed)

Internet Explorer 는 피드 (Feeds)와 피드 아이템을 표시합니다. 피드를 구독하는 것으로, 피드 아이템은 피드를 사용하여 다운로드한 문서입니다. 읽은 것, 안 읽은 것 모두,이 목록에 표시됩니다. 피드에 대해는 Internet Explorer 는 로컬 이름 (구독 시에 붙인 이름) , 피드가 표시됩니다. URL , 피드 발행자 이름, 포함된 폴더 이름에서 검색합니다. 피드 아이템에 대해는 그 제목을 검색합니다. 이것은 다수의 액티브한 피드를 구독하는 경우, 피드 섹션은 풍부한 정보원이 될 가능성이 있다는 의미합니다. Internet Explorer 는 기본값에서는 상위 5 번까지의 적합한 피드, 혹은 피드 아이템을 표시하고, 확장하면 최대 20 개까지 표시할 수 있습니다. (Internet Explorer 는 읽기 여부를 구별하지 않습니다)

키보드 바로 가기(Keyboard shortcut)

여기는 Internet Explorer 가 입력한 내용을 간단하게 수정하는데 사용할 수 있는 편리한 바로 가기를 표시합니다. 이 섹션을 배포하고 확인하려면, 섹션 하단의 아래로 향한 화살표를 클릭 해 주세요. 앞으로 이 블로그에서, 이 키보드 섹션의 세부 사항에 대해 설명할 예정입니다.

어느 섹션도 입력한 내용에 적합한 것이 없는 경우, 그 섹션은 완전하게 숨겨집니다. 섹션에 5개 항목 이상 표시할 수 있는 결과가 있는 경우, Internet Explorer 는 최초의 5개 항목만 표시하지만, 섹션의 표제행을 클릭하면 상위 20개 항목까지 표시됩니다. 다시 클릭하면 그룹은 닫힙니다. 그룹은 열린 상태로 있을 수 없기 때문에 드롭 다운을 닫고, 다시 열 때마다 기본값 5개 항목까지 표시됩니다.

불필요한 아이템을 드롭 다운 목록에서 직접 삭제

Internet Explorer 8에서는 드롭 다운 목록에서 보이는 어떤 것에서도 삭제할 수 있습니다. 입력한 주소 , 검색 기록, 즐겨 찾기, 피드나 피드 아이템을 목록에서 삭제할 수 있습니다. 목록에서 무엇인가를 삭제하면, (단지 목록에서 숨기는 것 과는 달리) 실제로 데이터를 삭제하기 때문에 예를 들면 정말로 즐겨 찾기 센터에서 삭제하는 것과 같은 확인을 합니다. 이것에 대한 주의점 - 휴지통 설정에서 [삭제 확인메시지 표시] 를 하지 않게 설정한 경우, 드롭 다운 목록 (과 즐겨 찾기 센터)은 즐겨 찾기 삭제를 확인하지 않습니다. 이것은 동시에 잘못해 삭제한 즐겨 찾기를 휴지통에서 회복할 수 있는 것을 의미합니다. 피드 아이템을 삭제했을 경우에는 Internet Explorer 는 그 아이템에 RSS 엔진이 다시 다운로드 하지 않도록 내부적인 마크가 붙여집니다 (원래 게시자가 그 아이템의 재발행을 제지한다는 의미는 아님) .

Internet Explorer 8 : Windows Search 에서 더 좋음

여기서 설명한 Internet Explorer 의 새로운 기능의 상당수는 빠르게 검색하여 결과를 표시하기 위한 검색 엔진으로서 이용하는 Windows Search에 의해서 가능합니다. Internet Explorer 8 의 사용자는 새로운 외형을 위해서 Windows Search 를 동작시킬 필요는 없지만, 드롭 다운 목록에 의한 최고의 사용자 경험을 위해 Windows Search 실행을 권장합니다. Windows Vista 의 사용자에서는 이미 Windows Search 3 이 동작하지만, Windows XP Service Pack 2 , Windows Server 2003 Service Pack 2 , Windows Server 2008 , Windows Vista Service Pack 1 사용자는 Windows Search 다운로드 사이트 (영어)에서 무료로 Windows Search 4 에 업데이트 할 수 있습니다.

다음 글에서는 Windows Search 유/무에 따른 Internet Explorer 8 동작에 대해 살펴보고, 또 일반적인 질문에 답변드리며, 새로운 드롭 다운 목록에서 가능한 흥미로운 사실을 알려드리겠습니다.

감사합니다. Internet Explorer 8 브라우징을 기대해 주세요.

Christopher Vaughan
Program Manager

Seth McLaughlin
Program Manager

영문 원본 :Improved Productivity Through Internet Explorer 8 Developer Tools

Internet Explorer 8 스마트 주소 표시줄 (Smart Address Bar) : 몇가지 기능

HK Yoo — Fri, 20 Mar 2009 10:04:39 GMT

전에 Internet Explorer 8 에 탑재된 새로운 스마트 주소 표시줄의 드롭 다운 목록 기능을 소개했습니다. 이번에는 많이 알려지지 않은 몇가지 세부 기능을 소개하고자 합니다.

Internet Explorer 8 의 스마트 주소 표시줄 자동 완성 항목(Autocomplete Suggestion)의 세부 사항

설치된 Windows Search 와 연동하여, Internet Explorer 8 은 어떤 사이트에 가려는지 정확하게 판단합니다. 찾고 있는 것과 가장 가깝다고 판단된 사이트는 "제시된 자동 완성 항목(Autocomplete Suggestion)" 이라 불립니다. 이 엔트리에는 SHIFT+ENTER 바로 가기 키가 적용되어, 가장 추천이 많은 사이트로 간단히 갈 수 있습니다. 그러나 어떻게 가장 관련성이 높은 사이트를 판단할까요?

여러분이 어떤 사이트에 가려는지 판단하기 위해서는 다양한 정보가 이용됩니다. Internet Explorer 8 은 현재 주소 표시줄에 입력하는 내용과 지금까지의 입력 내용이 다양한 분야에 대해서 어느 정도 적합한지 조합의 결과를 고려합니다. 예를 들면, 도메인의 완전한 적합은 URL 에 포함된 쿼리 스트링의 부분적인 적합보다 "가치" 가 있습니다. 이 알고리즘의 엄격한 판단조건을 공개할 예정은 없지만, 기본적으로 URL의 일부분은 다른 요소에 비해 중요시됩니다. 모든 적합 결과는 어떠한 형태로 결과의 일부로서 반환되지만 "보다 정밀도 높은" 적합 결과는 그 순서를 결정할 때에 유용하게 쓸 수 있습니다.

Internet Explorer 는 입력 내용을 기준으로 한 적합 결과를 한층 더 좁힙니다. 얼마나 특정 사이트로 이동하는지, 이전 드롭 다운 목록에서 선택하는지 (또는 선택하지 않았나) 등을 포함한 여러분이 원하는 사이트를 찾아내기 위한 데이터가 이용됩니다. 이러한 모든 것이 관련성 모델의 일부가 됩니다.

그러나 사용자에서 중요한 것은 무엇일까요? 검색 기록인가요, 즐겨 찾기인가요, 피드인가요? 검색 기록 정보는 다른 데이터의 상위 집합되는 경향이 있기 때문에 (방문 기록이 있는 모든 즐겨 찾기도 구독하는 피드도 최종적으로는 검색 기록 정보 내에 있습니다) , Internet Explorer 8 은 검색 기록 아이템에 최우선권을 주었습니다. 이용 가능한 검색 기록 정보에서 적합한 것이 없는 경우, 제시된 자동 완성 항목은 즐겨 찾기안에서 최적 사이트를 반환합니다. 즐겨 찾기에 적합한 것이 없는 경우, 가장 적합한 피드를 반환합니다.

이 기능은 Internet Explorer 8 beta 1에서 삭제된 인라인 자동 완성 항목(Inline Autocomplete)을 대체하기 위해 설계되었습니다. 인라인 자동 완성 항목(Inline Autocomplete)은 그다지 영리하지 않았습니다. 검색 기록 내용에서 키 입력 내용을 우선 완전 일치 조합을 실시하여, 결과를 알파벳 순서대로 정렬할 뿐입니다. Internet Explorer 8 의 제시된 자동 완성 항목은 기본적으로 같은 기능이지만 (Enter 대신에 현재는 Shift+Enter 를 사용) , 관련성을 이용하여 지금까지의 2/3시간에 원하는 주소를 찾을 수 있습니다.

Internet Explorer 8 스마트 주소 표시줄((IE8 Smart Address Bar) 검색

이미 알고 계실지도 모르지만, 주소 표시줄이든 검색창이든 입력하면 그 아래에 표시되는 드롭 다운 목록은 동일한 컨트롤입니다. 어디에 있는지에 따라 다소 외형은 다르지만, 모두 같은 코드에 의해서 동작합니다. 드롭 다운 목록의 동작에서 다른 점은 예를 들면 주소 표시줄의 아래에 표시되는 경우, 맨 밑에 키보드 바로 가기의 섹션이 표시되지만, 검색창의 경우, 퀵 픽 메뉴(QuickPick menu)가 표시됩니다.

주소 표시줄에 입력할 때에서도 드롭 다운 목록을 검색창 모드에서 전환할 수 있다는 것을 알고 계시나요? 의문 부호 뒤에 단어, 문자열, 숙어를 키 입력하면 검색창을 열었을 경우와 같이 동작합니다. 다만 예외가 있습니다. 바로 가기 키 섹션이 보이는 것과 퀵 픽 메뉴(QuickPick menu)가 없는 것입니다. 그 이외에는 같고, (가능하면) 기본값의 검색 공급자에서 검색 후보의 정보를 입수할 수 있어 Internet Explorer 8 은 입력한 주소와 검색 기록 정보에서 적합한 것만을 표시합니다. 만약 퀵 픽 메뉴(QuickPick menu)를 이용하지 않는다면, 이것은 빠르게 검색을 할 수 있는 훌륭한 방법입니다. 이것은 "xbox 360" 을 검색했을 때, Amazon Search에서 응답된 비주얼 서치 결과의 스크린 샷입니다.

Internet Explorer 7에서 여러 개 단어를 입력했을 경우에는 무엇인가를 검색한다고 가정하고, 입력한 내용을 설정된 자동 검색 공급자에 보냅니다. Internet Explorer 8에서 다음과 같은 경우는 "Find" ,"Search" ,"Go" 를 선두로 하여, 찾는 단어를 입력하고 Enter 를 칩니다. 주석： Internet Explorer 7 에서도 똑같이 동작합니다. "Find" 와 "Go" 는 주소 표시줄의 드롭 다운 목록을 서치 모드에는 바꾸는 것이 아니라, Enter 를 누르면 입력한 문자열을 검색 문자로서 취급하도록 Internet Explorer 에 전달합니다.

파일과 폴더 모드

Internet Explorer 8 에는 파일과 폴더 모드도 있습니다. 로컬 혹은 네트워크 경로를 입력하면 로컬(혹은 네트워크) 파일 혹은 폴더를 열거합니다. 이것은 빨리 로컬 리소스 검색 또는 실행하는 편리한 방법이지만, 다음을 기억해 두세요. Internet Explorer 는 많은 경우 파일, 디렉터리, 실행파일을 처리하기 위해서 Windows Shell 에 전달하지만, 이것은 Internet Explorer 가 파일 (예를 들면 컴퓨터의 위의 다양한 DLL 파일)을 어떻게 처리하는지 모르기 때문입니다. Internet Explorer 가 이해하는 파일포맷 (JPG , 텍스트 파일등)이면, 프레임내에서 열리는 경우도 있습니다. 파일과 폴더 모드에서는 Internet Explorer 8 를 아무 하이라이트 표시를 하지 않고, 키보드 바로 가기도 없습니다.

키보드에 의한 탐색

Internet Explorer 8 의 제시된 자동 완성 항목 드롭 다운 목록은 키보드 사용자에게 마우스 사용자와 같은 조작성을 얻을 수 있습니다. 드롭 다운 목록을 키보드로 조작하는 것은 매우 간단합니다.

윗쪽과 아랫쪽 화살표 키 ( ↑ 와 ↓)를 아이템의 이동에 사용할 수 있습니다. 화살표 키는 섹션 머리글을 뛰어넘을 수 있습니다.

- TAB 키를 섹션 머리글 사이를 이동하기 위해서 사용할 수 있습니다. TAB 키는 아이템을 뛰어넘습니다. 만약 마우스를 사용하지 않고 섹션 확장 또는 축소를 하는 경우는 TAB에서 이동한 후 Space 또는 Enter 를 눌러 주세요.

화살표 키와 TAB 키는 모두 드롭 다운 목록의 상하를 " 래핑" 할 수 있으므로, TAB 키를 계속 누르면, (역순은 Shift + TAB) , 그룹 머리글 사이를 순회 계속 시킬 수 있습니다. 직접 주소 표시줄에 포커스를 옮기려면 , ESC 키를 눌러 드롭 다운 목록을 닫습니다. 이것으로 TAB 키는 일반적인 동작으로 반환됩니다.

스크린 리더 이용시는 선택한 그룹명 뿐만이 아니고, 아이템 수도 로드할 수 있습니다. 특제 아이템 선택되었을 때, 페이지 제목과 URL 뿐만 아니라 그룹내의 위치도 로드할 수 있습니다.

드롭 다운 목록의 하단에 있는 키보드 바로 가기 섹션은 Internet Explorer 8에서 신속한 탐색을 행하기 위한 여러가지 키보드 조합을 표시합니다. 키보드 바로 가기 섹션의 바로 밑에 있는 화살표는 이 섹션을 확장 또는 축소했을 때의 머리글 행으로 간주됩니다. 이것은 키보드 바로 가기 섹션을 확장한 예입니다.

일례로서 Internet Explorer 8 의 주소 표시줄에 "microsoft" 라고 입력했습니다. Internet Explorer 는 이전에서 Ctrl + Enter 키 입력을 지원했지만, 지금까지 사용자에게는 잘 알려지지 않았습니다. 어떤 일이 일어날지를 간단하게 확인할 수 있고, 적절한 키 입력 조합을 선택하면 Internet Explorer 동작을 조정할 수 있습니다. 이 스크린 샷의 중간 정도에 선택사항 ("microsoft.net" 의 키보드 바로 가기 Ctrl + Shift + Enter)은 인터넷 옵션의 일반 탭에서 " 언어" 단추를 누르면 실행할 수 있는 사용자 지정 접미사를 선택한 경우에 표시됩니다. 이 설정 항목이 공백인 경우, 이 행은 표시되지 않습니다.

키보드 바로 가기 섹션은 상시 접혀진 상태가 기본값입니다(열린 상태에 고정할 수 없습니다) .대부분의 사용자는 항상 모든 키보드 바로 가기를 볼 필요가 없기 때문에 그렇습니다. 또 바로 가기는 언제나 같아서 한 번 학습하면, 그것들을 끊임 없이 떠올릴 필요가 없기 때문에 바로 가기 키를 자주 사용하는 고급 사용자는 UI 가 점유하는 면적이 가능한 작아지기를 원합니다.

키 입력 없이, 드롭 다운 목록 열기

제시된 자동 완성 항목 드롭 다운 목록은 키 입력을 하지 않아도 열 수 있습니다. 주소 표시줄의 오른쪽에 있는 아랫쪽 화살표를 클릭합니다.

Windows Search 가 설치된 경우, 각각의 그룹에 있는 상위 사이트. 가장 자주 읽고, 선택하고, 방문하는 장소, 사이트, 피드가 표시됩니다. Windows Search 가 설치 되지 않은 경우, 검색 기록과 즐겨 찾기 " 가장 최근 이용한" 목록이 표시됩니다.

Christopher Vaughan & Seth McLaughlin
Program Managers

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 또, 이 글 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경 될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오.

영문 원본 :The IE8 Smart Address Bar Part II: A Few More Features

업데이트 일: 2008 년 9 월 12 일

Internet Explorer 8 보안 6부 : Beta 2 업데이트

HK Yoo — Tue, 17 Mar 2009 11:54:52 GMT

Internet Explorer 8 Beta 2 가 공개되어, 개발 팀에서 몇가지 최신 보안에 관한 소규모 변경에 대한 업데이트 정보를 간단하게 전해드립니다. Internet Explorer 8 의 XSS 필터 기능을 설계한 개발자의 훌륭한 문서들의 링크도 안내합니다.

document.domain 제한

document.domain (영어) 속성은 우선 페이지를 제공하고 있는 서버의 완전 수식 도메인 이름을 반환합니다. 이 속성은 프레임상이 다른 호스트명의 페이지에서 공유할 수 있도록 도메인suffix를 매핑해야 합니다. 예를 들면, app1.expample.com 와 app2.example.com 에서 가동하는 두 프레임은 각각의 프레임에 공통의 example.com 를 document.domain 으로 설정하면, 서로에 대한 스크립트를 기술할 수 있습니다. 프레임이 도메인 속성에 상위 수준 도메인을 설정하거나 다른 suffix를 설정할 수 없습니다. 예를 들면, app1.example.com 에는 도메인 속성에 .com 또는 microsoft.com 를 설정할 수 없습니다. HTML5 제안에서는 지정된 도메인 속성에 매핑이 허가되는지를 판정하는 알고리즘 (영어)이 정식화되어 특히 매핑값이 현재값의 suffix로 할당됩니다.

Internet Explorer 7에서는 아래와 같은 호출은 성공합니다.

// document.domain 의 초기값은 app1.example.com

document.domain = "app1.example.com"; // 1. 초기값으로 설정된 도메인 속성

document.domain = "example.com"; // 2. " 애매한 " 도메인

document.domain = "app1.example.com"; // 3. " 엄밀한 " 도메인

Internet Explorer 8 또는 다른 브라우저에서는 3번째 매핑의 app1.example.com 는 이 시점의 값인 example.com 의 suffix가 아니기 때문에 예외가 발생합니다.

간단하게 말하면,애매한 document.domain 를 지정했을 경우, 다시 엄밀한 지정을 실시할 수 없습니다 .

다른 도메인에서 데이터를 상호 호환할 필요가 있는 웹 응용 프로그램은 document.domain 의 조정보다, 오히려 postMessage() (영어) 또는 XDomainRequest APIs (영어) 이용을 검토하는 것이 좋을 것입니다.

프레임 지정 제한

HTML5에서는 어떤 프레임이 다른 이름의 프레임이나 윈도우를 지정하기 위해서 Windows.open() (영어)을 호출할 때의 targetname 매개 변수의 사용이 허용되는 상황도 규정 (영어) 합니다.

이 규정은 윈도우 삽입에 관한 취약성을 줄이는데 도움이 된다는 의미합니다. 윈도우 삽입 공격에서는 브라우저 프레임 중에 악의적 웹 사이트가 신뢰할 수 있는 웹 페이지 프레임이나 팝업을 "하이잭" 하려고 기획합니다.

예를 들면 http://contoso.com 가 helpPage 라는 이름의 팝업 창을 여는 시나리오를 가정해 주세요.

window.open("helpTopic.htm", "helpPage", "height=200,width=400");

만약 http://evil.example.com 라는 다른 페이지가 이 윈도우를 뺏어가려는 경우는 다음과 같이 됩니다 :

window.open("spoof.htm", "helpPage", "height=200,width=400");

Contoso.com 의 helpPage 윈도우에 유도되는 대신에 spoof.htm 가 새로운 브라우저 창에서 열립니다. Internet Explorer 7과 8의 모든 윈도우에서 항상 주소 표시줄을 표시하는 것과 함께 이 새로운 제한에 의해서, 윈도우 삽입에 의한 위장 가능성은 더욱 적어집니다.

MIME 처리 :Sniffing opt out

IE8 Security Part V (영어) 에서 채택한 Internet Explorer 의 MIME-Sniffing 기능은 신뢰할 수 없는 컨텐츠를 전달하는 서버로 보안 문제를 일으킬 가능성이 있습니다. 거기서 특정 HTTP 응답에 대해서 MIME-Sniffing 기능을 무효로 하기 위한, 새로운 Content-Type 특성 ("authoritative" 라는 이름)을 알리고 있었습니다.

2개월에 걸쳐, Content-Type 에 새로운 특성을 사용하는 것이 서버 관리자에서 골칫거리라는 중대한 피드백을 받았습니다. 의견을 수용하여, 이 옵션을 재검토하여, 단독의 HTTP 응답 머리글에 바꾸기 했습니다. 새로운 X-Content-Type-Options 응답 헤더의 값에 nosniff 를 설정하여 송신하면, Internet Explorer 가 MIME Sniffing 기능에서 content-type 선언을 회피하는 것을 방지할 수 있습니다.

예를 들면, 다음과 같은 HTTP-response를 부여합니다.

HTTP/1.1 200 OK

Content-Length: 108

Date: Thu, 26 Jun 2008 22:06:28 GMT

Content-Type: text/plain;

X-Content-Type-Options: nosniff

<html>

This page renders as HTML source code (text) in IE8.

</body>

</html>

Internet Explorer 6과 7 은 이 텍스트를 HTML 로 해석합니다.

Internet Explorer 8 은 이 페이지를 일반 텍스트로서 드로잉합니다.

신뢰할 수 없는 내용을 호스트하고 있는 사이트에서는 X-Content-Type-Options: nosniff 머리글을 이용하여 text/plain 파일이 다른 무언가에 판정되지 않게 설정할 수 있습니다.

XSS 공격 Surface Reduction : Internet Explorer 8 표준모드에서의 CSS Expression 함수 무효화

"다이내믹 속성"으로 알려진 CSS 의 Expression 함수는 높은 수준의 처리 능력을 필요로 하는 독자 확장입니다. CSS Expression 함수는 또, 서버측의 XSS 필터를 피하기 위해 공격자에서도 일반적으로 이용됩니다.

Internte Explorer 8 Beta 2에서는 CSS Expression 함수는 Internet Explorer 8 표준모드에 지원되지 않습니다. 하위호환성을 유지하기 위해 Internet Explorer 7 상호교환모드와 Quirks 모드에서는 기존대로 지원됩니다. Internet Explorer 8 의 XSS 필터는XSS 어택의 일환으로서 CSS Expression 를 반영시키는 시도를 차단할 수 있지만, Internet Explorer 8 표준모드에서 이것들을 무효로 하는 것은 처리 능력의 점에서도 유리하여, 웹 표준 준거도 개선되어 한층 더 스크립트 인젝션에 대한 공격 Surface Reduction에도 연결됩니다.

Intetnet Explorer 8 의 XSS 필터의 세부 사항

Internet Explorer 8 의 XSS 필터의 디자이너인 David Ross 가 Secure Windows Initiative (영어) 에 XSS 필터의 구조와 구현의 세부 사항에 관한 기술 문서를 발표했습니다. XSS 필터가 어떻게 동작하는지 세부 사항에 흥미가 있는 분은 구독해 주십시오.

끝까지 읽어 주셔 감사합니다.

Eric Lawrence
Program Manager
Internet Explorer Security

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경 될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오.

영문 원본 :IE8 Security Part VI: Beta 2 Update

업데이트 일: 2008 년 9 월 2 일

Internet Explorer 8 보안 5부 : 통합 보호

HK Yoo — Tue, 17 Mar 2009 11:45:00 GMT

안녕하세요! 저는 인터넷 익스플로러 보안 프로그램의 책임자인 에릭 로렌스라고 합니다. 지난 화요일, 딘(Dean)이 신뢰성 높은 브라우저에 대한 저희의 생각을 포스팅했었죠. 오늘 저는 정말 기쁜 마음으로 인터넷 익스플로러 8의 보안을 위해 쏟아부은 엄청난 노력들에 대해 나눠보고자 합니다. 이 포스트의 길이로 짐작하시다 시피 이번 릴리즈를 위해 정말 많은 보안 관련 작업을 했습니다. 최종 사용자분들 IE8로 업그레이드를 하는 것만으로도 이 모든 보안 개선사항을 누리실 수 있고, 도메인 관리자분들은 그룹 정책과 IEAK를 이용해서 네트워크의 기본 보안 수준을 높일 수 있습니다. 웹 개발자 분들도 사용자 정보와 웹 애플리케이션을 안전하게 보호하는데 IE8에 새로 추가된 기능을 이용할 수 있고요.

인터넷 익스플로러8에 대해 기획하면서 MS의 보안팀은 현장에서 벌어지는 일반적인 공격 패턴에 대해 자세하게 관찰하여 장차 공격자들이 어떤 곳에 집중해서 공격해올지 추세를 살펴보았습니다. 보안 관련 기능들을 개발하면서 이번에 새로 추가된 강력한 기능(Activities 나 Web Slices 등의)들이 공격자들이 다음번에 노릴 표적이 되지 않도록 보안상 취약한 부분을 강화하느라 밤샘 근무도 마다하지 않았답니다. 처음의 계획에서는 좀 벗어난 얘기지만, 보안과 관련해서 다음과 같이 3가지 카테고리로 대처 방면을 구분해 보았습니다. 첫번째는 웹 애플리케이션의 취약점, 두번째는 브라우저 및 애드온의 취약점, 세번째로 사회공학적 분야, 이렇게 세 가지 방면으로 들어오는 공격에 대응하여 여러 단계의 장벽을 둘러 완벽하게 막을 수 있도록 하였습니다.

웹 애플리케이션 방어 크로스 사이트 스크립팅 공격 방어

지난 몇년간 크로스 사이트 스크립팅(XSS:Cross-Site Scripting) 공격이 버퍼 오버플로우형 공격을 추월해서 소프트웨어 취약점 공격의 가장 흔한 사례가 되어버렸습니다. XSS 공격은 웹 애플리케이션의 취약점을 공격하여 쿠키와 기타 데이터, 비공개 페이지의 정보나 신용 정보를 훔치고 장차 더 심각한 공격을 위한 준비로서 행해지고 있습니다.

IE8은 XSS 공격을 줄이고자 반사 공격(reflection)이라 불리우는 가장 일반적인 형태의 XSS 공격 패턴을 차단합니다. IE8의 XSS 필터는 추론 기반의 방어 코드로 공격 코드 주입 및 코드 실행을 방지합니다. 이 부분에 대해선 데이빗의 블로그 포스팅 - IE8 보안 4부 : XSS 필터를 보시면 더 자세하게 알수 있습니다.

XSS 필터는 이런 공격에 대한 좋은 방어책이지만, IE8에서만 제공됩니다. 따라서 웹 개발자분들은 사이트의 XSS 공격 취약점을 없애기 위해 부가적인 방어 작업을 해야 합니다. 사실 브라우저에서 XSS 공격을 탐지는 것보다 서버 단에서 막는게 더 쉽죠. 그저 사용자의 입력을 신뢰하지 않고 매번 확인과 검증을 수행하기만 하면 됩니다. 대부분의 웹 플랫폼 기술은 차단 기술을 제공하고 있습니다 ASP.NET 개발자라면 마이크로소프트 안티 XSS 라이브러리를 사용하는 것을 고려해보면 좋을 것입니다. XSS 쿠키 침해를 좀더 확실하게 막고자 한다면, 민감한 내용의 쿠키(사용자 인증등으로 사용되는)를 HttpOnly 속성으로 보호하는 것이 좋습니다.

안전한 매쉬업

XSS 필터로 브라우저가 한 서버에서 다른 서버로 이동할때 발생하는 반사 공격(reflection)을 경감시켜 줄 수는 있습니다. 하지만, Web 2.0시대가 열리면서 클라이언트 측 매쉬업을 사용하는 웹 애플리케이션이 점차 증가하고 있고 이 중 많은 매쉬업이 사용자에게 데이터 안정성을 제공해주지 못합니다. SCRIPT SRC 기술을 사용하여 써드파티의 스크립트를 바로 매쉬업 페이지에 포함시키게 되면, 써드파티의 스크립트는 해당 페이지의 DOM 객체와 HttpOnly 속성으로 보호받지 않은 쿠키를 완전히 통제할수 있게 됩니다.

이런 문제에 대처하려는 개발자 분들을 위해 IE8은 HTML5 cross-document messaging 기능을 제공하고 있습니다. 이 기능은 IFRAME으로 하여금 바깥쪽 DOM과는 격리한채로 다른 문서와 좀 더 안전하게 통신을 하도록 하고 있습니다. 또한 XDomainRequest 객체도 제공하고 있죠. 이는 다른 도메인으로부터 "공개"된 데이터를 보안 네트워크로 조회할수 있게 해줍니다.

Cross-document Messaging과 XDomainRequest 두 기능 모두 안전한 매쉬업을 작성하는데 도움을 줄 수 있습니다만, 좀 더 중요한 부분이 하나 남아있습니다. 이 기능 중 어느 것을 이용하여 서드파티의 프레임이나 서버에서 데이터를 받아오든 그 안에 script를 포함하는 문자열이 들어있을 수 있습니다. 호출자가 인지하지 못하게 DOM 객체에 그 문자열이 주입되면 바로 그것이 스크립트 주입 공격인 것입니다. 이런 상황에서 앞의 두 크로스 도메인 통신 기술과 함께 스크립트 주입 공격을 막을 2개의 신 기술을 소개 드립니다.

안전한 매쉬업 : HTML 방역

IE8 에는 window 객체에 toStaticHTML이라는 메서드 하나를 추가했습니다. HTML 코드로 이루어진 문자열이 이 함수를 거치게 되면, 잠재적으로 실행될 수 있는 스크립트 항목이 제거된 채로 리턴됩니다. 내부적으로 이 함수는 앞에서 언급한 서버측 기술인 마이크로소프트 안티 XSS 라이브러리와 동일한 기능을 수행합니다.

예제를 하나 살펴보죠. postMessage 함수 호출로 회신된 문자열에 대해 페이지 외양은 그대로 유지한채로 스크립트만 실행되지 않도록 해줍니다.

document.attachEvent('onmessage',function(e) { 
  if (e.domain == 'weather.example.com') {
      spnWeather.innerHTML = window.toStaticHTML(e.data);
  }
}

로 아래 함수가 호출되는 경우

window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");

그 결과 값으로 아래의 문자열이 리턴됩니다.

This is some <b>HTML</b> with embedded script following... !

안전한 매쉬업: JSON 방역

JSON(JavaScript Object Notation)은 경량의 자바스크립트 객체의 스트링 직렬화로서 매쉬업에서 두 컴포넌트간의 데이터 교환에 사용되곤 합니다. 그런데 참 안타깝게도 많은 매쉬업에서 JSON을 안전하지 않게 사용하곤 합니다. 자바스크립트의 eval 메서드를 사용해서 JSON 문자열을 다시 자바스크립트 객체로 복원하곤 하는데, 이런 방식은 잠재적으로 그 실행 중에 특정 스크립트 함수를 호출할 수 있습니다. 보안에 민감한 개발자라면 JSON 파서로 JSON 객체 안에서 실행 코드가 동작 하지 않도록 합니다만, 이 경우 성능상 불이익이 있습니다.

인터넷 익스플로러 8에서는 ECMA 스크립트 3.1 규격을 구현하여 네이티브 JSON 조작 함수(Douglas Crockford의 json2.js API를 사용합니다.)를 제공합니다. JSON.stringify 메서드로 자바스크립트 객체를 JSON 문자열로 바꾸어 리턴하고, 이와 반대로 JSON.parse 메서드로 JSON 문자열을 자바스크립트 객체로 변환합니다. 새로 추가된 네이티브 JSON 메서드들은 브라우저에 내장된 스크립트 엔진과 동일한 코드를 사용하므로 여타의 네이티브 하지 않은 구현체에 비해서 엄청난 성능 우위를 제공합니다. 결과 스트링에 DOM 에 주입 코드가 들어있더라도 앞에서 언급한 toStaticHTML 함수라면 스크립트 주입 공격을 막을 수 있습니다.

아래는 스크립트 주입 공격에 대한 JSON 및 HTML 방역 예제입니다.

<html>
<head><title>XDR+JSON Test Page</title>
<script>
if (window.XDomainRequest){
      var xdr1 = new XDomainRequest();
      xdr1.onload = function(){
           var objWeather = JSON.parse(xdr1.responseText);
           var oSpan = window.document.getElementById("spnWeather");
           oSpan.innerHTML = window.toStaticHTML("Tonight it will be <b>"
                             + objWeather.Weather.Forecast.Tonight + "</b> in <u>" 
                             + objWeather.Weather.City+ "</u>.");
      };
      xdr1.open("POST", "http://evil.weather.example.com/getweather.aspx");
      xdr1.send("98052");
}
</script></head>
<body><span id="spnWeather"></span></body>
</html>

날씨 정보 서비스가 아래와 같은 위험한 코드를 회신하더라도,

HTTP/1.1 200 OK
Content-Type: application/json
XDomainRequestAllowed: 1

{"Weather": {
   "City": "Seattle",
   "Zip": 98052,
   "Forecast": {
     "Today": "Sunny",
     "Tonight": "<script defer>alert('bang!')</script>Dark",
     "Tomorrow": "Sunny"
   }
}}

이를 잘 막아냅니다.

MIME 핸들링

웹서버에서 전송되는 모든 파일은 MIME 타입 (혹은 Content-type이라고도 하죠.)에 따르고 있습니다. 이것은 해당 컨텐츠가 어떤 컨텐츠인지 (이미지인지 텍스트인지 애플리케이션인지) 나타내 줍니다. 호환성을 이유로 인터넷 익스플로러에는 각 다운로드되는 리소스들의 컨텐츠 타입이 무엇인지 확인하는 MIME 스니핑 기능이 탑재되어 있었습니다. 가끔씩 인터넷 익스플로러가 웹서버에 정의된 MIME 타입과 다른게 판별하는 경우가 있습니다. 예를 들어 HTTP 응답 헤더에 Content-Type:text/plan 으로 회신된 파일이 HTML 문서라고 판별했다면, IE는 이 파일을 HTML로 렌더링 하기로 판단합니다. MIME 스니핑은 수많은 레거시 웹서버들 (html 문서를 text/plain으로 보내주기 때문입니다.) 와 호환되도록 하는 중요한 기능을 수행합니다.

하지만 아쉽게도 MIME 스니핑은 신뢰할수 없는 컨텐츠를 제공하는 서버의 경우엔 주요한 보안 문제를 야기합니다. 다음과 같은 경우를 가정해보죠. 사진 공유 서비스에 아무나 이미지 파일을 업로드 할 수 있는 상황에서, 공격자가 JPEG 파일을 가공하여 공격 코드가 내장된 이미지 파일을 업로드 했다면 불특정 다수의 피해자를 양산 할 수 있습니다. 사진 공유 사이트에서 일반 이미지 처럼 동작하지만 내장된 스크립트 역시 동작하는 위험한 파일을 사용자가 다운로드 받으면 이 코드가 피해자의 쿠키를 훔치거나 위조 페이지로 이동하는 등의 작업이 가능해집니다.

이런 문제에 대응하고자 우리는 인터넷 익스플로러 8의 MIME-type 판별 코드에 아래와 같은 수정을 가했습니다.

MIME 핸들링 : "Upsniff" 제한

우선 IE8에서 "upsniff"를 막아서 파일의 MIME type이 image/* 인데도 HTML/Script로 판별되는 것을 방지합니다. 파일에 스크립트가 내장되어 있으면, 서버가 아무리 이 파일을 이미지라고 선언해도 IE는 내장된 스크립트를 실행하지 않습니다. 이 변화로 인해 사진 공유사이트의 서버쪽 코드를 전혀 고치지 않고도 이에 대한 공격을 막을 수 있게 되었습니다. 이렇게 해도 호환성 문제를 최소화 할수 있는 것은 서버들이 image/* 컨텐츠 타입을 HTML이나 스크립트로 판별하는 경우가 드물기 때문입니다.

MIME 핸들링 : 스니핑 Opt-out

다음으론, 웹 애플리케이션에 MIME 스니핑을 opt-out 하는 기능을 제공합니다. Content-Type HTTP 응답에 authorutative=true 속성을 추가하면 인터넷 익스플로러는 MIME 스니핑을 수행하지 않습니다.

예컨대 아래와 같은 HTTP-response 에 대해

HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain; authoritative=true;

<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>

IE7 에서는 HTML로 해석되어 화면에 출력되지만,

IE8에서는 평범한 텍스트 파일로 출력됩니다.

신뢰할수 없는 컨텐츠를 제공하는 공공 사이트에선 헤더에 authoritative 속성만 추가해주면 text/plain으로 확정되어 아무것도 가로챌 수 없게 됩니다.

MIME 핸들링 : 강제 저장

마지막으로 신뢰할 수 없는 HTML 파일을 다운로드 하도록 웹 애플리케이션을 만들어야 할 경우 대해 신뢰할 수 없는 컨텐츠의 실행을 막아 여러분의 사이트 보안성이 유지되도록 하였습니다. 헤더에 X-Download-Options를 추가하고 noopen을 값을 세팅하면 해당 파일이 실행되는 대신 무조건 다운로드만 됩니다. 일단 다운로드 된 파일이 로컬에 저장되면 다음에 다시 실행되더라도 여러분의 사이트에 위해를 끼칠 수 없게 되어 스크립트 주입 공격을 막을 수 있게 됩니다.

HTTP/1.1 200 OK
Content-Length: 238
Content-Type: text/html
X-Download-Options: noopen
Content-Disposition: attachment; filename=untrustedfile.html

앞에서 나열한 일련의 웹 애플리케이션 방어 기능들을 모두 사용한다면 좀 더 안전한 웹 애플리케이션 개발이 가능해질 것입니다.

로컬 브라우저 방어

웹 애플리케이션에 대한 공격이 증가하면서 공격자들은 점차 일반 사용자의 로컬 컴퓨터를 표적으로 삼고 있습니다. 브라우저에 보안정책을 보다 효과적으로 강제하기 위해선 웹 애플리케이션, 개인 정보, 로컬 자원, 브라우저 자체에 대한 공격을 예방해야합니다. 그런 점에서 보호 모드, ActiveX Opt-in, Zone-Lockdown 같은 기술을 탑재한 인터넷 익스플로러 7은 중요한 발전이라 할수 있습니다. 이렇게 브라우저 공격이 난관에 부딛히자 공격자들은 브라우저의 추가 기능의 취약점에 집중하기 시작합니다.

인터넷 익스플로러 8에선 발전된 추가기능 보안, 공격 가능 지점 최소화, 개발 용이성 및 발전된 사용자 경험을 위해 많은 노력을 기울였습니다.

추가기능(Add-on) 보안

이 보안 블로그를 처음 시작할때 DEP/NX 메모리 보호에 관련된 시리즈로 시작했었습니다. 이 기능은 IE8이 윈도우 서버 2008, 윈도우 비스타 SP1, 윈도우 XP SP3 에서 실행될 때 자동으로 활성화 됩니다. DEP/NX 기술을 ASLR (Address Space Layout Randomization) 같은 기술과 결합하여 공격자가 버퍼오버런 같은 메모리 관련 취약점 공격을 쉽게 하지 못하도록 합니다. 무엇보다도 이 보호 기술이 인터넷 익스플로러 뿐만 아니라 같이 로딩되는 추가기능에도 동시에 적용된다는 점이 중요합니다. 여기에 관해선 이 블로그 시리즈의 첫 글 : IE8 보안 1부: DEP/NX 메모리 보호를 읽어보세요.

그 다음에 이어진 연재글에서 매트 크롤리(Matt Crowley)씨가 IE8 에서의 ActiveX 개선 사항 및 이전 버전의 브라우저에서 부터 이어진 ActiveX 보안 기능을 설명했었죠. 가장 중요한 개선사항은 "Per-Site ActiveX"라고 할수 있는데, 이는 ActiveX 컨트롤이 악성 코드로서 동작하지 않도록 해줍니다. IE8은 ActieveX 를 관리자 권한이 없이도 설치할 수 있도록 하였습니다. 도메인 관리자를 활성화 하기만 하면 대부분의 관리자 권한이 없는 사용자도 설치하고 사용할 수 있게 된거죠. 이 부분에 대해선 IE8 보안 2부: ActiveX 보안 개선을 읽어보시면 좋을 것입니다. ActiveX 개발자 분들의 경우엔 이 페이지를 참고하시면 사용자 보호에 큰 도움이 될 것입니다.

보호 모드

보호모드는 윈도우 비스타의 IE7에서 처음 선보인 기능으로, 인터넷 익스플로러와 그 위에서 동작하는 확장 기능에 소프트웨어의 취약점이 있더라도 악성코드가 사용자 몰래 설치되는 것을 방지하여 그 위험도를 줄여줍니다. 인터넷 익스플로러 8 에서는 상당수의 API를 보호 모드에 맞게 개선하여 애드온 개발자들이 보호모드에서 동작하는 브라우저 인스턴스를 쉽게 컨트롤하고 상호 작용 할 수 있도록 하였습니다. 이 개선점에 대해선 개선된 보호모드 API 백서를 보세요.

성능 향상과 애플리케이션 호환성을 위해 인트라넷 영역에선 기본 설정으로 IE8의 보호모드를 비활성화하도록 하였습니다. 원래에는 UX(사용자 경험)와 관련된 이유로 인트라넷 영역에서도 활성화되있었고 그런 이유로 보호 모드로 바뀌거나 보호 모드에서 벗어날 때 인터넷 익스플로러 7이 강제적으로 새 프로세스를 할당하고 새 창을 띄우곤 했었습니다.

인터넷 익스플로러의 유연한 구조 덕분에 한 브라우저 창에 보호 모드로 동작하는 창과 보호 모드로 동작하지 않은 창을 동시에 띄울 수 있게 되었습니다. 따라서 사용자가 혼란을 느끼지 않고도 쉽게 사용할 수 있게 되었죠. 물론 IE8 사용자나 도메인 관리자는 필요한 경우엔 보호 모드를 활성화 하도록 설정을 변경할 수 있답니다.

애플리케이션 프로토콜 알림

애플리케이션 프로토콜 핸들러는 (인터넷 전화 애플리케이션이나 스트리밍 미디어 플레이어 같은) 서드파티 애플리케이션을 브라우저 내에서 혹은 윈도우에 설치된 별도 애플리케이션을 바로 기동할 수 있게 해줍니다. 이것은 매우 강력한 기능이지만 아쉽게도 보안상 취약한 부분입니다. 인터넷에 떠돌아다니는 안전하다고 확인되지 않은 컨텐츠로 인해 보안 취약점이 발생할 수 있기 때문입니다.

사용자가 이 기능을 사용할지 선택 할 수 있도록 인터넷 익스플로러 8에선 애플리케이션 프로토콜을 실행하기 전에 사용자에게 이를 사용할지 알리게 됩니다.

이 부분에 대해 좀 더 잘 대처하시려는 애플리케이션 프로토콜 개발자분들은 MSDN의 Best Practice 문서를 따르시면 됩니다.

파일 업로드 컨트롤

역사적으로 HTML 파일 업로드 컨트롤(<input type="file">)은 수많은 정보 누출 취약점으로 지적되었습니다. 이 문제를 해결하기 위해 두가지 부분을 수정하였습니다.

사용자가 업로드 할 파일 경로를 직접 입력하도록 하고 키 눌림 정보를 훔치는 방식의 공격을 막고자 업로드 컨트롤의 파일 주소 표시 박스를 읽기만 가능하도록 변경했습니다. 이제 사용자는 파일 선택창을 띄워야만 업로드가 가능해집니다.

추가적으로 "업로드 될 파일의 로컬 디렉토리 경로 정보"를 표시하는 URLAction 기능이 "Disable"로 설정되었습니다. 그 결과, 로컬 파일 시스템에 대한 정보가 노출되는 잠재적 위험을 막을 수 있게 되었습니다. 예를 들어 서브밋 버튼을 누를 경우 인터넷 익스플로러 8에선 C:\users\ericlaw\documents\secret\image.png 이런 경로의 이미지 전체 경로를 보내는 것이 아니라 image.png 정보만 보내게 됩니다.

사회공학적 방어

브라우저가 지난 몇 년동안 많은 발전을 해 옴에 따라 웹상의 범죄자들은 사회공학적인 방법으로 사용자를 공격하기 시작했습니다. 잘 방어된 성벽을 공격하기보다 당당하게 성문앞에 다가와서 사용자들에게 자신이 믿게끔 속인다는 것이죠.

인터넷 익스플로러 8 에서는 여러 사이트들과 신뢰할만한 기관으로부터 제공된 정보를 바탕으로 사용자가 이런 경우에 잘못된 선택을 하지 않도록 도와주는 기능에 많은 노력을 기울였습니다.

주소 표시줄 개선

도메인 강조는 IE8 Beta 1에 추가된 신 기능으로 사용자로 하여금 쉽게 웹 주소(URL)를 인지하게 해줍니다. 도메인 이름이야 말로 URL에서 보안에 가장 중요한 부분이므로 이를 검은 글씨로 강조하고 사이트에서 관리하는 쿼리 스트링 같은 URL 문자는 회색으로 표시합니다.

EV SSL 인증서 등의 기술을 사용한 사이트에 대해선 사용자가 민감한 데이터를 사용자가 신뢰하는 사이트에만 제공되고 있음을 쉽게 인지 할 수 있도록 인터넷 익스플로러 8의 주소표시줄을 강조합니다.

SmartScreen® 필터

인터넷 익스플로러 7에서 피싱 필터가 처음으로 도입되어서 보고된 피싱사이트에 접속하려 할때 사용자가 인지할 수 있도록 했습니다. 인터넷 익스플로러 8에선 성공적으로 자리잡은 피싱 필터를 좀 더 개량한 SmartScreen® 필터가 도입되었습니다. SmartScreen® 필터는 피싱 사이트에 접속했다는 것을 알려주는 것 이상으로 악성코드가 배포된다고 알려진 사이트를 차단하거나 악성코드가 사용자의 컴퓨터에 공격을 시도하거나 개인정보를 침해할려고 하면 이를 사용자에게 알려줍니다. 사용자 컴퓨터에 대한 종합적인 보호를 위해 단독으로 동작하는 것이 아니라 윈도우 디펜더나 윈도우 라이브 원케어와 같은 기술과 결합하여 이를 수행합니다.

보다 자세한 내용은 이전의 포스트 : IE8 보안 3부 - 스마트스크린 필터를 보세요.

결론

보안은 신뢰성 있는 웹 브라우징의 핵심 사항입니다. 인터넷 익스플로러 8에 추가된 주요 개선 사항을 통해 웹 보안 전반에 진화를 이루었습니다. 악의 무리들이 "GG" 치고 나가지 않는 한 우리 IE팀은 웹 애플리케이션 보안성 증대와 사용자 보호를 위해선 불철주야로 노력하고 있습니다.

앞으로도 IEBlog에 자주 들르셔서 우리 팀이 안전하고도 믿을 수 있고 이용하기 편리한 브라우저를 만들어가는 과정을 지켜봐주세요.

8월에 출시될 베타 2도 기대해 주시구요!

에릭 로렌스
프로그램 매니저

* 역자 : 이글은 IE8 Security Part V: Comprehensive Protection (영문)을 NCHOVY 인터넷 스톰 센터에서 번역해 주셨습니다. 진심으로 감사의 말씀을 드립니다.

IE8 팀 블로그

변화에 대한 대응: IR8 RC 1 에서 Getter/Setter 구문 업데이트

ECMAScript 3.1

DOM 프로토타입

표준이 우선

사용자 보조: IE8 RC의 ARIA 지원 강화

이전 IE에서 구현되었던 것

현재 구현 가능한 것

변경의 의미

웹 개발자 대상

최종 사용자 대상

ARIA

결론

IE8 보안 VII: ClickJacking 방지

브라우저 성능 평가의 일반적인 문제

브라우저 성능 측정

캐싱 동작(Caching Behavior)

샘플 양

대역폭 경쟁(Bandwidth Competition)

리소스 경쟁

서버 상호작용(Server Interaction)

관찰자 효과(Observer Effect)

컴퓨터 구성(Machine Configuration)

Cold Start vs. Warm Start

웹 사이트 컨텐츠

웹 사이트 설계

「페이지가 표시되었습니다」

브라우저 애드온

Internet Explorer 8과 안정성(Reliability)

Loosely­coupled Internet Explorer

크래쉬 자동 복구 기능

Windows 오류 보고

Loosely­coupled Internet Explorer

프레임 프로세스 병합

탭 프로세스 증가

가상 탭(Virtual tab)

자동 복구 기능(Automatic Crash Recovery)

세션 쿠키(Session cookie)

폼 데이터(Form data)

Windows 오류 보고 (Watson)

Internet Explorer 8 beta 2 준비

Cookie 차단 이상의 프라이버시보호 : 주의해야 할 타사 컨텐츠(Third-Party Content)

타사 사이트 식별

타사 사이트와 프라이버시

무엇이 일어나고 있는지, 기술적으로 무엇이 가능한가 그리고 그 외의 의문

타사 사이트의 신용성

호환 표시 기능(Compatibility View) 소개

호환 표시와 최종 사용자

호환 표시와 엔터프라이즈

호환 표시와 웹 개발자

요약

Internet Explorer 8 Developer Tools 생산성 향상

통합화되어 사용하기 쉬운 Developer Tools

플랫폼의 비주얼 인터페이스

검증 고속화

그 외의 정보

IE8 즐겨찾기 모음

웹 조각(WebSlice) 소개

웹 조각(WebSlice) 사용 방법

즐겨찾기 모음에 피드 추가

그외 힌트와 바로 가기

애드온 성능 설계

애드온 초기화와 업데이트 확인

무리를 하지 않는 : 힘든 일은 다른 스레드에 맡긴다

부스에 도착하고 나서 요금을 지불한다

레지스트리 사용

캐싱을 활용한다

나쁜 버릇을 고치다(플러시 금지)

Internet Explorer 8 의 IT 관리자용 새로운 기능

Internet Explorer 8 스마트 주소 표시줄 Part 1 : 쉽고 빠른 안내

Internet Explorer 8에서 쉽게 찾기

폴더 : 이미 사용하고 있는 태그

가고 싶은 곳에 가기 위해서 새로운 드롭 다운 목록 사용

입력한 주소(Typed Address)

제시된 자동 완성 항목 추천(Autocomplete Suggestion)

검색 기록(History)

즐겨 찾기(Favorites)

피드(Feed)

키보드 바로 가기(Keyboard shortcut)

관련성 정렬(Relevancy Sorting)

Looselycoupled Internet Explorer

Looselycoupled Internet Explorer