mir.pe (일반/밝은 화면)
최근 수정 시각 : 2024-12-10 13:15:01

Microsoft Edge/레거시

엣지 레거시에서 넘어옴
파일:상위 문서 아이콘.svg   상위 문서: Microsoft Edge
{{{#!wiki style="margin:-10px" <tablebordercolor=#808080><tablebgcolor=#808080> 파일:WWW 아이콘.svg 서비스를 종료한
웹 브라우저 		}}}
{{{#!wiki style="margin: 0 -10px;"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="border: 0px solid; margin-bottom: -15px;" 		파일:mosaic browser logo.png
Mosaic 		파일:넷스케이프 네비게이터 아이콘.svg
Netscape 		파일:마이크로소프트 엣지 레거시 로고.svg
Edge
Legacy 		파일:스윙 브라우저 아이콘.png
스윙
브라우저 		파일:Opera Classic logo.png
Opera Classic 		파일:cooooolnovo.png
Coolnovo
현재 서비스 중인 웹 브라우저
}}}}}}}}} ||
{{{#!wiki style="margin: -10px -10px" <tablealign=center><tablebordercolor=white,#1f2023> 파일:Internet Explorer 아이콘.svg Internet Explorer
관련 문서 		}}}
문제점 · 버전
Microsoft Edge( 레거시)
{{{#!wiki style="margin: -10px -10px" <tablealign=center><tablewidth=320><tablebordercolor=white,#1f2023> 파일:마이크로소프트 엣지 레거시 로고.svg 엣지 레거시
Edge Legacy 		}}}
<colbgcolor=#0078d7> 개발사 Microsoft
분류 웹 브라우저
엔진 EdgeHTML
플랫폼 Microsoft Windows
최신 버전[1] Microsoft Windows
44.19041.610.0
관련 사이트 파일:홈페이지 아이콘.svg [2] | Microsoft Edge 레거시란 무엇인가요?

1. 개요2. 상세
2.1. 차크라코어2.2. 보안
2.2.1. 해킹 방어 기능
2.2.1.1. ActiveX를 포함한 각종 레거시 기술들의 지원 제거2.2.1.2. 유니버설 윈도우 앱2.2.1.3. AppContainer 샌드박스2.2.1.4. 64비트 프로세스
2.2.2. 메모리 손상 방어
2.2.2.1. 제어 흐름 보호 (Control Flow Guard)
2.2.3. 바이너리 주입 보호
2.2.3.1. 모듈 코드 통합 강제 기능
2.2.4. 스마트스크린 필터를 통한 드라이브-바이 다운로드 공격 방어
2.2.4.1. 드라이브 바이 다운로드 공격2.2.4.2. 스마트스크린 필터 개선
2.2.5. 플래시 콘텐츠 자동 일시 정지2.2.6. Windows Hello 지원
2.2.6.1. 웹 인증: 패스워드 없이 작동하고, 2단계 인증 지원
2.2.7. TCP Fast Open, TLS False Start, TLS 1.3
2.2.7.1. TLS 1.3으로의 여정2.2.7.2. TCP와 TLS의 전체 핸드 쉐이크2.2.7.3. TLS False Start와 TCP Fast Open으로 1-RTT 지원2.2.7.4. TLS 1.3으로 0-RTT 지원
3. 버전
3.1. 20.102403.2. 25.10586
3.2.1. EdgeHTML 13의 기능 업데이트3.2.2. 차크라 엔진 기능 업데이트3.2.3. 지원 플랫폼 확장3.2.4. 새로운 사용자 기능들
3.3. 38.14393
3.3.1. 마이크로소프트 확장 기능3.3.2. 접근성 기능 강화3.3.3. 새로운 기능3.3.4. 효율, 보안, 성능, 호환성 강화3.3.5. 기업용 기능
3.4. 40.150633.5. 41.162993.6. 42.171343.7. 44.177633.8. 44.183623.9. 44.19041
4. 장단점들
4.1. 장점4.2. 단점
5. 점유율
5.1. 대한민국에서의 상황
6. 단종7. 여담

[clearfix]

1. 개요

EdgeHTML 엔진 기반의 웹 브라우저. 후속은 Chromium 기반의 Microsoft Edge다. Microsoft는 2021년 3월 9일 Microsoft Edge 레거시의 지원을 종료했다.

2. 상세

Edge는 마이크로소프트가 현대 웹 디자인과의 호환성을 극대화하기 위해 기존 인터넷 익스플로러에 사용되던 렌더링 엔진인 Trident(mshtml.dll)를 하위호환을 고려하지 않고 바닥부터 개조하여 만들어낸 렌더링 엔진인 EdgeHTML(edgehtml.dll)을 기반으로 만들어진 새로운 웹 브라우저다.

파일:external/az648995.vo.msecnd.net/fixesandremovedcode.png 파일:external/az648995.vo.msecnd.net/vendorprefixes1-298x300.png

간단하게 말하자면 엣지는 인터넷 익스플로러와 완전히 다른 브라우저다. 비유를 굳이 하자면, 집을 이사하지는 않았지만 안에 있는 각종 물건과 가구와 붙박이장까지 죄다 빼버리고 인테리어를 처음부터 다시 짜는 수준의 변화가 있었다.[3] 그 변화의 폭이 어느 정도인지를 확인하려면 위의 그림을 확인하면 좋다. IE 11은 11뿐만이 아니라 10, 9, 8, 7[4], 심지어 5.x까지 지원하기 위한 하위 호환 코드들을 그대로 가지고 가고 있다. 하지만 엣지는 이 하위 호환을 위한 코드를 전부 날려버리고, 심지어 바로 이전 브라우저인 IE 11과의 호환을 위한 코드까지 남김없이 뜯어낸 뒤 WebKit 또는 Gecko와 비슷한 현대적인 방식으로 렌더링을 하고, 심지어 WebKit 전용 API까지 다수 끌어오면서 웹 표준을 따라 최근 만들어진 사이트들을 표시할 때 깨지거나 오류가 나는 상황을 최소화하는 것을 목적으로 하고 있다. 특히 Gecko의 경우 모질라 재단이 넷스케이프 4의 지저분한 코드를 보고 경악해서 다 버리고 2년 동안 새로 개발한 엔진이라는 측면에서 Edge의 렌더링 엔진인 EdgeHTML와 비슷한 면이 있다.

이것은 곧 MS가 드디어 ActiveX를 버린 브라우저를 만들었다는 뜻이기도 하다. ActiveX를 위시한 IE 6~8 방식의 웹 디자인은 해외에서도 그 문제가 심각하기 때문이다. 특히 기업용 웹페이지 및 소프트웨어( ERP 등)가 IE 6~8을 요구하는 경우가 많다고 하며, 이런 부분 때문에 MS가 함부로 IE 6~8 코드나 ActiveX를 버리지 못한 측면이 크다. IE 9 이래로 IE는 이 시절의 IE에 비하면 훨씬 더 나아졌고 상당 부분 웹 표준을 따라가고 있지만, 아직 기본적인 원리는 IE 5.x 내지는 IE 6~8 시절을 따라가고 있어 종종 오류가 나기도 했고, 반대로 웹페이지 쪽에서 사용자의 브라우저를 IE로 인식하는 바람에 웹 표준을 지키는 IE 10이나 IE 11을 사용함에도 불구하고 IE 6~8 방식으로 코드를 보내주면서 문제가 생기기도 했었다. Edge는 이를 막기 위해 레거시 코드를 통째로 날리고, 오히려 WebKit과의 호환성을 증대하는 방향으로 하여 최신의 방식으로만 코드를 받고 표기하는 것을 목표로 한다. 심지어 User agent도 크롬 변종인 것처럼 작성되었다.

앞서 살펴본 바와 같이 엣지는 완전히 새로운 브라우저이기 때문에, ActiveX로 떡칠되어 있는 온라인 뱅킹이나 인강 등의 서비스를 전혀 사용할 수 없다. 때문에 IE 11을 남겨두는 방식으로 호환성 문제를 간단하게 해결하였다. 아직 IE의 구식 코드를 필요로 하는 사이트가 많고, 이런 사이트들이 많을 수록 호환성 문제로 업그레이드하지 않을 사람들이 많아질 것을 MS가 모를 리가 없기 때문에, Windows 10에서도 IE 11은 여전히 있다. 다만 Windows 10의 기본 브라우저는 Edge이며, IE 11은 어디까지나 레거시 프로그램으로서 시작 메뉴의 보조프로그램 폴더로 들어가야 사용할 수 있다고 한다.

따라서 Edge가 차기 웹 브라우저로서 꾸준히 업데이트될 예정인 것과는 달리, IE는 더 이상의 기능 변경 및 개선 없이 보안 패치만 해줄 예정이다. 하지만 레거시 지원을 위해 여전히 남아있기는 하다.

일단 Windows 10의 기술지원이 계속되는 한 IE 11이 보안 패치라는 이름의 호흡기는 계속 붙들고 있을 것이다. 인터넷 익스플로러 지원 주기 정책 FAQ에 따르면 어떤 윈도우 버전에서 이용가능한 인터넷 익스플로러의 가장 최근판은 그 윈도우 버전의 지원중단 기간까지 사후지원(이미 말했듯, 보안 문제 해결 정도에 그친다)을 해 주는데, Windows 10에 들어서서 새로운 Windows를 개발하는 대신 macOS 비슷하게 Windows 10의 신규 버전을 지속적으로 업데이트하는 것으로 정책이 바뀌었다.[5] 레드스톤 같은 업데이트가 지속되는 한 Windows 10의 지원 기간은 사실상 무한정이고, 그동안 IE 11에 대한 지원도 무한히 계속된다는 것이다.

Edge가 Windows 10의 기본 브라우저라고 하지만, 사실 Windows 10의 Enterprise LTSB/LTSC 에디션에는 Edge가 제공되지 않는다. Enterprise LTSB/LTSC 에디션은 기업체 등 '시스템의 안정성을 고도로 유지해야 되는 곳'을 겨냥한 것으로 꼭 필요한 보안 패치 이외에는 신규 업데이트는 거의 하지 않으며, 이것이 빠른 업데이트와 신속한 변화를 하는 엣지 브라우저와 어울리지 않기 때문에 LTSB/LTSC의 기본 브라우저는 IE 11이다.[6] 이런 사용자들 때문이라도 IE를 완전히 버릴 수는 없는 상황이다.

하지만, Windows 10의 특정 업데이트 버전에서 인터넷 익스플로러가 제거될 가능성도 배제할 수 없다. 앞에서 거론된 macOS의 경우에도 초창기의 기본 브라우저는 믿을 수 없게도 Internet Explorer였다. 그 이후로 20년에 가까운 시간을 macOS 10 버전에서 여전히 뭉개고 있었지만 기본 브라우저는 Safari로 바뀌었고, Internet Explorer는 서드파티 브라우저로 밀려난 뒤 지금은 완전히 사라져버렸다.

여담으로 Windows 7/ Windows 8.1의 IE 11과 Windows 10의 IE 11은 약간의 차이가 있다. 예를 들어 8.1의 경우 '소스 보기'를 할 때 소스 보기 창이 열리지만, 10의 경우 개발자 도구가 열린다. 또한 8.1의 IE 11과는 달리 우측 메뉴에 스마일 버튼이 있는데 MS에게 피드백을 보내는 기능이다. 또한 HTTP/2와 TLS 1.3(21H1 이후)도 Windows 10의 IE 11에서만 지원하는데, 사실 이는 시스템 라이브러리를 같이 사용하기 때문이다.

2.1. 차크라코어

차크라코어 GitHub 페이지

사트야 나델라 체제 이래로 마이크로소프트가 꽤 많은 서비스들을 오픈소스로 전환하기 시작했고, EdgeHTML 엔진 역시 협력사의 커밋을 받는 등 상당히 개방적인 태도를 보이고 있어서, 한동안 EdgeHTML 및 엣지 브라우저가 오픈소스로 전환할 것이라는 관측이 있었다. 엣지 팀에서는 당장은 이들을 오픈소스로 전환할 계획은 없다고 밝혔으나, 결국 2015년 12월 5일에 IE 및 엣지의 자바스크립트 엔진인 차크라를 오픈소스로 전환한다는 발표가 있었다.

파일:external/az648995.vo.msecnd.net/chakra-componentization.png

아직 윈도우가 오픈소스가 아니기 때문에 엔진에서 일부를 잘라낸 후 "차크라코어"라는 이름을 붙여 공개하기는 했지만, 위의 그림을 보면 사실상 엔진의 대부분을 공개했다. 브라우저 및 유니버설 윈도우 플랫폼 관련 부분 및 구형 API의 연결 부분만 잘라냈을 뿐, 브라우저의 내부 구조 및 여러 활용 방법과 관련이 있는 대부분의 API들이 전부 공개되었기 때문이다. 2016년 1월 현재 우선 과제 중 하나는 무려 리눅스 포팅으로, 우분투 리눅스 15.04 x64 버전에 차크라코어를 옮기는 것을 목적으로 하고 있다.

본인의 개발 실력과 영어 능력이 뒷받침 된다는 전제 하에 .NET과 함께 좋은 마이크로소프트 입사 도구라는 말이 있다. 비교적 새롭게 오픈 소스로 공개된 기획이기 때문에 손을 댈 여지도 많고, 개발 커뮤니티의 분위기 역시 비교적 우호적이기 때문에, 꾸준하게 의미 있는 커밋을 할 수 있다면 엣지 팀에서 먼저 관심을 가지고 입사원서도 쓰지 않았는데 스카웃 해 갈 수도 있다는 것이다.

2.2. 보안

보안에 있을 때에는 Internet Explorer 11에서도 10보다 많은 것이 향상되었던 것처럼 Microsoft의 최근 몇 년간의 행보는, Memory Corruption 류의 취약점을 활용하는 해킹에 대한 방어도 옛날보다 꽤나 적극적으로 하는 것을 보여주고 있다. 이번 Edge 브라우저에서도 역시 새로운 보안 기능이 많이 추가되었다. 아래의 내용들은 모두 오른쪽 각주의 링크에서 공식적으로 발표된 내용에 기반한 것이다.[7]

2.2.1. 해킹 방어 기능

2.2.1.1. ActiveX를 포함한 각종 레거시 기술들의 지원 제거
엣지 레거시에서는 어도비 플래시를 제외한 ActiveX, VML(Vector Markup Language), VBScript, BHO(Browser Helper Objects)가 지원되지 않는다.

VML은 1998년 IE5에서 처음 소개된 XML을 기반으로 하는 벡터 마크업 언어이다. 이는 지금은 SVG의 존재로 인해 쓸모 없는 것이 되었기 때문에, 단지 기존 IE와의 호환성 때문에 남아 있던 것이므로 제거하는 것이다.

VBScript는 자바스크립트에 밀려 이젠 거의 쓰는 곳이 없을 뿐더러, 작년에는 CVE-2014-6332와 같이 지금도 다양한 Exploit Kit에서 쓰고 있는 심각한 취약점도 있었기 때문에 마찬가지로 제거하는 것이다.

BHO는 ActiveX와 비슷한 측면으로 보면 된다. 이 역시 1997년에 소개된 오래된 기능으로, 브라우저가 서드파티 COM 오브젝트를 로딩하는 것인데 지금까지 다양한 확장 기능 개발에 쓰여왔다. 대표적으로 툴바를 들 수 있다. ActiveX의 경우, 이를 제거하는 대신 더 보안성이 향상되고 HTML/자바스크립트 기반의 다른 확장 기능 모델을 추가한다는 내용이다. 아직 발표되지는 않았으나 오래 안 가서 소개될 것이라 생각된다.

이는 IE에서만 지원하는 오래된 것들을 모두 제거하고, 보안성에 있어서도 문제가 되어 왔던 것들을 제거함으로서 상당히 큰 발전이라고 할 수 있다. 구글의 경우에도 NaCl(Native Client) 등의 고급 기술을 개발해서 샌드박스 내에서 서드파티 바이너리(확장기능 등)를 실행하는 것을 어렵사리 구현하고 있는데, ActiveX와 같이 아무런 부가적인 보안 요소 없이 그대로 로컬 액세스 권한을 주는 것은 지금 시대에서는 심각하게 뒤떨어진 것이다. 이를 마이크로소프트도 예전부터 인식하고 있었으나 호환성으로 인해 쉽게 제거하지 못하였는데 이제 엣지라는 별개의 브라우저로 개발하게 되면서 이를 모두 제거할 수 있는 일종의 기회를 얻었다고 볼 수 있다. 물론, Protected Mode 같은 샌드박스가 적용된 이후의 IE에서는 ActiveX 역시 예외 없이 낮은 Integrity Level로 코드가 실행되기 때문에 기본적인 보안은 된다.
2.2.1.2. 유니버설 윈도우 앱
엣지는 유니버설 윈도우 앱 기반으로 개발되었다. 이는 유니버설 윈도우 플랫폼(UWP) 기반으로 동작하는 애플리케이션으로, Windows 8에서 처음 소개된 것이다. 이름 그대로 모바일 기기와 데스크톱 PC 등을 모두 아우르는 앱을 개발하는 것인데, 엣지는 이 유니버설 앱으로 개발되었다. 언뜻 보면 이는 보안과는 별 관계는 없어 보이지만, 유니버설 윈도우 앱의 경우 애플리케이션에서 구현을 따로 하지 않아도 기본적으로 적용되는 보안 모델이 별개로 존재한다. 쉽게 말해서 마치 OS X 처럼 애플리케이션이 동작할 때 기본으로 샌드박스가 한 층 추가된다고 보면 된다. OS X 애플리케이션을 개발할 경우 개발자가 샌드박스에 필요한 멀티프로세스 구조나 Broker와의 IPC 등에 대한 것을 별도로 직접 구현하거나 하지 않아도 자동으로 그렇게 동작한다. 실제로 엣지를 실행하고 처음 프로세스를 확인해 보면 Integrity Level이 AppContainer인 것을 볼 수 있다. 반면 Internet Explorer의 경우 그냥 일반적인 프로그램이기 때문에 처음 실행되는 Broker 프로세서의 Integrity Level은 보통의 기본 유저 권한인 Medium이다.

다만 실제로 이로 인한 보안성을 이렇게 간단하게 나타낼 수는 없고, 무조건 보안성이 강화되었다고도 볼 수 없다. 현재 IE11 전환을 위한 것으로 추측되는 Medium 권한의 browser_broker.exe라는 프로세스가 따로 동작하고 있고 기존에 Broker(처음 실행한 프로세스)의 자식 프로세스로 Renderer 프로세스가 생성되었던 것과 달리 엣지의 경우 렌더러 프로세스가 RuntimeBroker.exe라는 Medium Integrity Level을 가지는 새로운 프로세스의 자식으로 생성된다. 아예 렌더링을 위한 프로세스는 프로그램 자체가 분리되어 MicrosoftEdgeCP.exe라는 이름으로 존재한다. 어찌 됐든 브라우저라는 프로그램은 로컬 리소스에 액세스가 필요하다. 파일을 다운로드해서 저장한다든지 등이 그 예시이다. 그리고 MicrosoftEdgeCP.exe(Content Process)에서 웹 서버와의 소켓 통신을 개별적으로 직접 하고 있는 모습을 볼 수 있다.

여하튼 이런 것이 가능한 이유는 위에서 언급했다시피 유니버설 윈도우 앱은 기본적으로 유니버설 윈도우 플랫폼이라는 플랫폼 위에서 동작하도록 되어 있기 때문이다. OS X의 경우에도 순수 커널 아래에서 동작하는 바이너리들이 샌드박스 내에서 동작하는 것이 아니라, XNU 커널 위에 또 다른 플랫폼을 쌓아 올리고, 이 플랫폼이 샌드박스를 구현하고, 개발자들은 그 새로운 플랫폼 대상으로 애플리케이션을 개발하는 식으로 하기 때문에 가능한 것이다. 즉 샌드박스 구조에 비유하면 UWP와 같은 플랫폼이 알아서 Broker 역할을 하는 것이다. 다만 OS X는 예전부터 이렇게 동작하는 것이 기본 옵션이었고 개발자들도 오랫동안 그렇게 개발해왔기 때문에 거의 모든 애플리케이션이 이렇게 동작하고 있지만, 윈도우는 윈도우 8에 와서야 소개했기 때문에 아직 적용이 늦다는 차이뿐이다. 물론 아직까지도 윈도우는 이렇게 개발하는 것이 기본이 아니기 때문에 대부분의 응용 프로그램은 샌드박스 내에서 안전하게 동작하는 것이 아니라 지금까지처럼 '날것'으로 실행될 것이다.
2.2.1.3. AppContainer 샌드박스
인터넷 익스플로러 7에서 보호 모드라는 보안 모델을 소개했다. 이는 기본적으로 Integrity Level이라는 Windows의 새로운 권한 모델을 기반으로 하는 것인데, Windows XP 이하의 운영체제에서는 이런 것이 존재하지 않았고 Windows Vista에서 처음으로 소개되었다. 따라서 정확히는 Vista 이상(더 정확히는 UAC가 켜져 있을 때만)에서 동작하는 인터넷 익스플로러 7부터 보호모드가 적용되었다. 이는 샌드박스 모델인데, 브라우저가 페이지를 렌더링하는 데에 쓰는 프로세스를 따로 분리하여 이 분리한 프로세스의 권한을 낮게 주는 것이라고 보면 된다. 즉 제 3자가 만든 HTML 페이지에서는 IE의 취약점을 이용하는 악의적인 자바스크립트 코드 등이 있을 수 있는데, 이를 실행하면서 취약점이 발생하기 때문에 이런 렌더링 관련 작업은 따로 자식 프로세스를 생성하여 그 안에서 처리한다. 그러면 만약 여기서 취약점이 발생한다고 해도 이 프로세스 자체로는 권한이 낮기 때문에, 시스템의 중요 파일 등에 접근을 할 수 없으며 더 높은 Integrity Level을 가지는 프로세스에 (악성)코드 삽입 등을 하는 것도 불가능하며 그 외에도 시스템의 다양한 리소스들에 접근을 할 수 없다. 따라서 취약점으로 임의 코드 실행을 할 수 있다고 해도 해커가 시스템에 해를 끼치는 것에 한계가 있다.

이러한 보호 모드는 IE10부터 향상된 보호 모드(EPM)로 다른 보안 기능도 추가하면서 더욱 발전하였고 지금까지 계속 적용되어 왔다. Windows 8에서는 위에서 언급한 Integrity Level의 종류(System, High, Medium, Low, Untrusted)에 AppContainer를 하나 더 추가하였는데, 이는 이름에서 알 수 있다시피 앱으로 개발된 애플리케이션들이 기본으로 이 권한으로 동작한다. EPM은 Windows 8 이상에서 브라우저가 동작할 때 렌더링 프로세스를 AppContainer 권한으로 실행하도록 한다. 다만 이는 실제로 브라우저가 App으로 개발되어 동작하는 것과는 다르다. App으로 개발한 애플리케이션은 그냥 실행하면 권한 자체가 기본적으로 AppContainer가 되고 App 플랫폼 내의 샌드박스에서 기본적으로 동작한다. 그러나 이 경우는 브라우저를 실행하면 처음 실행한 프로세스(Broker)의 Integrity Level은 그대로 Medium이다. 따라서 이는 App 플랫폼에 의한 것이 아닌 IE가 직접 구현한 샌드박스 모델에서 AppContainer 권한을 사용한 것뿐이다.

즉 정확히는 이는 이미 IE10부터 적용이 되어 있었으나, 엣지에서 변경된 점은 IE10/11에서 EPM이 옵션으로 되어 있었기 때문에 기본값이 아니었던 점을 바꾸어 이제는 무조건 기본으로 적용하도록 바뀌었다. 당연히 이로 인해 보안성은 훨씬 더 강화되었다. 지금까지 이를 기본값으로 하지 못한 이유는 이 샌드박스라는 것은 치명적인 단점으로 ActiveX와 같은 기존의 플러그인 실행에 문제가 생기기 때문이다. 샌드박스는 로컬 리소스에 액세스하는 것을 제한하는 기능인 반면 ActiveX는 로컬 리소스에 거의 제한 없이 액세스할 수 있는 기능이다. 따라서 페이지를 샌드박스 내에서 실행하는 경우 ActiveX와 같은 플러그인이 정상적으로 실행될 수가 없다. 다만 이는 곧 EPM의 적용은 ActiveX의 원천 차단을 의미하기 때문에 마이크로소프트에서도 당연히 이를 해결하기 위해 샌드박스와 호환이 되는(로컬 파일에 액세스하지 않는다거나) ActiveX 플러그인의 경우 EPM 내에서 실행을 할 수 있도록 하는 새로운 기능을 추가했었다. 물론 이는 기존의 ActiveX 플러그인을 그대로 사용할 수 있다는 것은 아니고, 다시 빌드해야 한다는 단점은 있었으나 Flash 등의 중요 플러그인은 이런식으로 호환되게 사용할 수 있었다. 물론 대부분의 ActiveX 플러그인은 로컬 리소스에 액세스해야 하는 경우가 대부분이기 때문에 호환되게 할 수 없다.

엣지는 ActiveX와 같은 플러그인을 아예 제거해버렸기 때문에 샌드박스를 강제 적용하는 것에 아무런 문제가 없고, 따라서 이렇게 기본으로 지원을 하게 된 것이다. 이는 ActiveX라는 플러그인의 자체적인 보안과는 별개로, 이렇게 서드파티 바이너리를 아무런 보안 없이 네이티브로 실행하는 기능을 브라우저에서 제거해야 하는 또 다른 이유였다고 할 수 있다. PWN2OWN과 같은 대회에서도 브라우저를 해킹할 때 샌드박스도 우회해야 해킹을 한 것으로 인정하는 만큼 샌드박스라는 보안 모델의 중요성은 이루 말할 수 없으며, 심지어 Adobe Reader 같은 소프트웨어도 자체적으로 샌드박스를 구현하고 있을 정도다.
2.2.1.4. 64비트 프로세스
인터넷 익스플로러도 64비트 운영체제에서 64비트로 동작하는 것을 지원하였으나, 옵션으로 64비트 프로세스 사용 설정을 따로 해야 하는 경우가 있었다. Broker Process는 64비트인 반면 실제로 핵심적인 처리를 하는 Renderer Process들은 32비트인 경우가 많았다. 한국에서는 반대로 64비트 실행을 해제해야 하는 경우가 많은데, ActiveX가 32비트용밖에 없기 때문이다. 엣지는 64비트 운영체제인 경우 기본적으로 64비트 프로세스로 동작을 하게 되어 보안성이 향상되었다. 64비트인 경우 보안에 있어서 이점이 되는 부분은 ASLR(Address Space Layout Randomization)에 있어서 32비트보다 훨씬 더 큰 entropy를 가지는 랜덤성이 가능하다는 점이다. 이는 애플리케이션이 적재되는 Base Address에 랜덤성을 부여하는 기능으로, Windows Vista에서 처음 소개된 이후로 exe의 옵션으로 설정할 수 있던 시대를 지나 지금은 강제로 적용하고 있다.

기본적으로 Windows에서 32비트 프로세스의 경우 프로세스 주소 공간이 2^32(0x00000000 ~ 0xFFFFFFFF)로 제한이 되고, 여기서 커널 공간을 제외하면 0x00000000 ~ 0x7FFFFFFF까지의 메모리에만 액세스가 가능하다. (※이는 PAE 등의 기능으로 달라질 수 있으나 기본 설정을 기준으로 설명하였다) 즉 32비트 주소 공간에서는 주소가 위치할 수 있는 경우의 수도 그 만큼 작으므로 추측이 비교적 쉽다. 물론 쉽다고는 하나 32비트라고 해도 이를 실제로 Brute-forcing하여 공격하는 경우는 사실 거의 없다. 32비트의 경우의 수도 사실 엄청나게 많은 편이고, 브라우저 같은 경우 원격 코드 실행 시에 기회는 사실 1번뿐이기 때문이다. 다만 Heap-spray와 같이 원하는 힙 메모리가 위치할 주소의 예측이 어느 정도 가능한 요소가 있는 경우는 예외다. 실제로 여기서 말하는 64비트 전환 시의 이점은 사실 프로세스의 Base Address에 관한 것이라기보다 힙 메모리에 관한 내용이다. 그러나 64비트의 경우 2^64 라는 어마어마한 주소 공간을 사용할 수 있고 이는 사실상 추측이 불가능한 entropy로 ASLR을 적용할 수 있다. 물론 x86_64(x64) 아키텍처에서는 2^48만 사용하지만 이 역시 32비트에 비하면 엄청나다.

2.2.2. 메모리 손상 방어

2.2.2.1. 제어 흐름 보호 (Control Flow Guard)
Visual Studio 2015에 적용된 기능으로, 컴파일시 포인터 기반 간접 점프를 확인하는 기능이다. 메모리 손상 취약점의 목표는 해커가 원래 프로그램 코드 중 간접 점프 코드를 통해 자신이 원하는 새로 넣은 코드로 점프해 악성코드를 실행하는 것이다. 제어 흐름 보호는 이런 점프 목적지를 원래 코드 함수 시작점으로 제한해 메모리 손상 취약점을 방어해 해커의 의도를 무력화시키려는 것이다. 엣지를 컴파일할 때 이 기능을 넣고 컴파일했다고 한다. IE에도 적용된 기능이다.

2.2.3. 바이너리 주입 보호

2.2.3.1. 모듈 코드 통합 강제 기능
EdgeHTML 13부터 엣지에서 로드하는 모든 동적 라이브러리는 WHQL 인증을 받아야 한다. 윈도우 유저들이 설치하는 거의 대부분의 드라이버는 마이크로소프트에서 WHQL 인증을 받는데, 이는 대부분 드라이버가 관리자 권한을 가지기 때문이다. 이것을 똑같이 브라우저 동적 라이브러리에도 적용시킨다고 보면 된다. 엣지는 WHQL 인증을 받은 라이브러리만 로드하고, 아닌 라이브러리들은 막는다. 이 기능을 프로세스 단에서 할 수도 있고, 커널 단에서 할 수 있는데, 프로세스 단에서 하면 프로세스가 감염됐을 때 기능이 작동하지 않을 수 있다는 단점이 있다. 그래서 윈도우 커널 단에서 라이브러리를 확인해 프로세스가 감염되어도 커널에서 프로세스를 강제로 꺼버릴 수 있고, 프로세스에서 커널에 접근하기도 힘들어 이 기능을 유지할 수 있다.

2.2.4. 스마트스크린 필터를 통한 드라이브-바이 다운로드 공격 방어

2.2.4.1. 드라이브 바이 다운로드 공격
스마트스크린 필터는 URL 평판과 앱 평판을 기반하여 악성 URL을 차단하고, 악성 프로그램을 받지 못하게 하는 기능이다. 그래서 많은 악성 웹사이트에 사용자들의 접근을 막아 브라우저를 안전하게 한 기능이다. 그래서 드라이브-바이 다운로드(Drive-By download) 공격이라는 것이 생겼는데, 이는 기존의 잘 알려진 웹사이트를 해킹해 자신의 악성코드를 사이트에 올리고, 그 웹사이트에 접속한 사용자들을 취약점을 통해 감염시키는 공격이다. 이렇게 하면 평판 기반 방어는 그 사이트가 잘 알려진 웹사이트이기 때문에 성공적으로 방어할 수 없다. 이런 드라이브-바이 다운로드 공격은 보통 취약점 킷(익스플로잇 킷; 여러 취약점들을 동시에 노리는 코드)을 통해 이뤄지며, 많은 사용자들이 모든 프로그램을 제때 업데이트하지 않기 때문에 성공할 확률이 높다. 특히 현재 추세가 아래와 같이 이런 취약점 킷 공격이 많아지고 있는 추세라 사용자들이 더욱 위험해질 수 있다.
파일:external/az648995.vo.msecnd.net/smartscreen-1.png
그래서 윈도우 디펜더, 엣지, 인터넷 익스플로러, 빙, EMET 등의 툴들을 통해 수집된 악성 신호들을 실시간으로 스마트스크린 필터에 적용해 이런 취약점 킷 공격을 방어하는 것이다. 실제로, 이 기능을 통해 HanJuan EK라는 취약점 킷이 디펜더와 EMET에 잡히자마자 스마트스크린 필터에 등록되고, 조사를 통해 이 취약점 킷이 어도비 플래시 플레이어 제로데이 취약점을 이용한다는 것을 알아냈다. 이 취약점은 CVE-2015-0313로 명명되었다.
2.2.4.2. 스마트스크린 필터 개선
이런 드라이브-바이 다운로드 공격을 방어하기 위해서는 이런 공격들이 웹페이지가 렌더링 되기 전에 탐지되고 차단되어야 한다. 이는 브라우저 성능에도 미칠 수 있기 때문에, 스마트스크린 필터는 작은 캐쉬 파일에 악성 파일을 기록하고, 그걸 기반으로 드라이브-바이 다운로드 공격을 방어한다. 새로운 악성코드가 계속 나오기 때문에, 당연히 이 캐쉬 파일은 주기적으로 업데이트된다.
URL이 악성으로 판명되면 다음과 같이 대문짝만하게 웹페이지가 위험하다고 알려준다.
파일:external/az648995.vo.msecnd.net/smartscreen-2-1024x674.png

또한, 프레임 단위 경고 기능을 추가해, 위험한 광고 프레임만 차단하고 나머지 정상적인 부분들은 렌더링하는 기능도 추가했다. 그래서 일부만 문제가 있어도 전체 내용을 보지 못하던 경험을 개선했다고 한다.
파일:external/az648995.vo.msecnd.net/smartscreen-3-1024x674.png
만약에 스마트스크린 필터가 오탐했다고 생각되면 자세한 정보 링크를 통해 경고 페이지를 확장해 우회할 수 있지만 추천하지는 않는다. 프레임 단위로 차단되었을 경우에는 안전하지 않은 콘텐츠 뱃지를 눌러서 똑같이 우회할 수 있다. 그리고 기존의 스마트스크린 설정과 컨트롤들(그룹 정책 포함)은 새 드라이브-바이 다운로드 공격 보호 기능을 자동으로 추가했다.

2.2.5. 플래시 콘텐츠 자동 일시 정지

안전하고 좋은 성능과 안정적인 브라우저를 제공하기 위해 플래시의 리소스와 전력을 조정했다. 1주년 업데이트부터 웹페이지에서 중요하지 않은 플래시 콘텐츠는 자동으로 일시정지된다.

애니메이션이나 광고같은 주변부 콘텐츠는 유저가 콘텐츠를 재생하도록 클릭을 하지 않는 이상 일시정지된 상태로 있을 것이다. 이로 인해 전체 콘텐츠를 재생하는 것 보다 전력 소모가 감소하고 성능이 향상될 것이다. 비디오나 게임같은 페이지 중심에 있는 콘텐츠는 일시정지되지 않는다.

또한 웹 표준의 기능을 더더욱 강화시켜 더 안전하고 성능이 향상된 경험을 플래시 없이 사이트들이 제공할 수 있도록 노력한다고 한다. 웹 표준을 사용할 때 배터리 수명이 늘어나고 CPU 부하와 메모리 소모가 감소한다고 한다. 개발자들은 웹표준을 통해 모든 브라우저와 모바일 같은 플래시를 쓸 수 없는 장치에서 사이트들이 잘 작동하게 만들 수 있다.

2.2.6. Windows Hello 지원

빌드 2016에서 마이크로소프트 엣지가 전 세계에서 처음으로 안전하고 쉽게 웹에서 인증을 할 수 있게 Windows Hello를 지원하는 브라우저가 될 것이라고 발표되었다. 이는 웹 인증 (이전에는 FIDO 2.0 Web API로 불림)의 초기 구현에 의해 작동하고, FIDO Alliance와 W3C 웹 인증 작업 그룹에서 이들 API를 표준화하기 위해 작업하고 있다고 한다. 테스트 드라이브 데모에서 이를 체험해볼 수 있다.

기존 패스워드에 많은 문제점들이 있는데, 많은 사람들이 모든 사이트들에 대해 강력하고 전부 다 다른 패스워드를 쓰지 않는다는 것이다. 보통 기억하기 쉽게 만들거나 모든 계정들에 대해 같은 패스워드를 사용한다. 또, 패스워드를 바꾸더라도 "123456"이나 "password" 같은 쉬운걸로 바꾸는 경우가 많다. 해커들은 보통 사회 공학적 기법, 피싱, 키로깅 기법으로 개인 컴퓨터에서 패스워드를 빼내게나, 패스워드를 저장한 사이트를 장악해서 빼내는 경우가 많다. 만약에 패스워드가 여러 사이트에서 동시에 사용된다면, 한 계정만 해킹해도 다른 계정들도 위험해진다.

하지만 이 기술을 통해 인증을 위해 유저가 더 이상 패스워드를 기억하지 않아도 되고, 서버가 저장하지 않아도 된다. 웹 인증과 Windows Hello를 결합해서 생체인식 기술과 비대칭 암호화를 통해 구현한다고 한다. 유저를 인증하기 위해서, 서버가 브라우저에 평문 텍스트 문구을 먼저 보낸다. 엣지가 유저를 Windows Hello로 식별할 수 있다면, 시스템이 유저에 할당된 개인키로 문구에 서명하고 인증서를 서버로 보낸다. 만약에 서버가 이 인증서를 공개 키로 인증서를 확인할 수 있다면, 유저에서 온 것을 확인할 수 있고, 유저를 안전하게 인증할 수 있다.
파일:external/winblogs.azureedge.net/Hello.png
이 키들은 강력한 계정들을 제공할 뿐만 아니라 추측할 수 없고, 원본 외에서 다시 사용될 수 없다. 공개키는 그 자체로 의미 없고, 개인키는 공유되지 않기 때문이다. Windows Hello로 더 좋은 유저 경험을 제공할 뿐만 아니라, 패스워드 추측, 피싱, 키로깅, 서버 데이터베이스 공격으로 계정을 탈취할 수 없다.
2.2.6.1. 웹 인증: 패스워드 없이 작동하고, 2단계 인증 지원
FIDO Alliance에 참가해 웹에서 패스워드를 제거하고 강력한 계정을 생성할 수 있도록 여러 기업들과 같이 작업을 하고 있다고 한다. FIDO Alliance의 주 목표는 이런 인터페이스들을 표준화해, 웹사이트들이 Windows Hello와 다른 생체 인식 기술들을 모든 브라우저에서 사용할 수 있게 하는 것이다. FIDO Alliance는 FIDO 2.0 제안을 W3C에 제출했고, 새로 생긴 웹 인증 작업 그룹은 이들 API를 W3C 웹 인증 표준안에 넣기 위해 이들 API를 표준화하고 있다.
파일:external/winblogs.azureedge.net/FIDO-300x169.jpg
웹 인증 표준안은 다음 2가지 인증 시나리오를 정의하고 있다: 패스워드 없이 인증, 2단계 인증. 패스워드 없이 인증하는 경우는, 유저가 웹페이지에 로그인하기 위해 유저 이름이나 패스워드 없이 - Windows Hello만으로 로그인할 수 있다. 2단계 인증의 경우는, 유저가 유저 이름과 패스워드로 로그인하지만, Windows Hello가 2단계 인증을 해 전체적인 인증을 강력하게 할 수 있다.

전통적인 패스워드 인증은 유저가 패스워드를 생성하고 서버에 알려줘서 서버가 패스워드를 해시화해 저장한다. 유저, 또는 패스워드를 취득한 공격자는 똑같은 패스워드를 어느 장치에서나 서버에 인증하기 위해 쓸 수 있다. 하지만 웹 인증 표준안은 비대칭 키 인증을 사용한다. 비대칭 키 인증에서는, 유저 컴퓨터가 비밀 키와 공개 키로 구성된 강력한 암호화 키 쌍를 생성해, 공개 키를 서버에 제공하고, 개인 키를 컴퓨터의 TPM 같은 전용 하드웨어에 저장해 컴퓨터에서 다른 곳으로 이동할 수 없게 한다. 이 방식은 클라이언트와 서버 둘 다에 대한 공격을 방어할 수 있다 - 다른 곳에서 공격자가 인증하려는 클라이언트 공격은 성립되지 않고, 서버를 공격해도 공개키 리스트만 얻을 수 있다.

마이크로소프트 엣지는 현재 웹 인증 스펙의 초기 구현을 지원한다 - 사실, 최근 작업안이 업데이트되어 현재 구현을 벗어나있고, 표준안 프로세스를 지나면서 스펙이 계속 변경될 것이다. 그래서 현재 API들은 ms-prefix가 붙어있고, 이들 API들은 미래에 바뀔 가능성이 높다. 그래서 표준안이 만들어질 때까지 API들을 업데이트해 변경점을 제대로 지원할 것이다.

웹 인증 API들은 매우 간단한다 - 두 메서드: window.webauthn.makeCredential와 window.webauthn.getAssertion로 구현된다. 이를 지원하려면 서버와 클라이언트 모두 수정을 해야 한다.

1903 업데이트를 위한 Insider Preview (Slow/Fast)에서 Windows Hello를 통한 Microsoft Account 로그인을 지원한다. Edge에서 Microsoft Account 접속 후 설정하면 된다. 피드백 허브 퀘스트

2.2.7. TCP Fast Open, TLS False Start, TLS 1.3

밑에 설명할 TCP Fast Open, TLS False Start, TLS 1.3으로 성능과 보안 두마리 토끼를 다 잡을 수 있다고 한다. TCP Fast Open은 about:flags 설정에서 켤 수 있다. AdGuard에서의 버그는 Adguard측의 업데이트로 픽스되었다.
2.2.7.1. TLS 1.3으로의 여정
금융 정보 같은 중요한 정보들은 인터넷에서 움직일 때 보안이 충족되어야 하고 안정성이 보장되어야 한다. 웹 상의 보안 네트워크 트래픽 절반 이상이 TLS로 채워져있고, 매일 이 숫자는 늘어나고 있다. 현대적인 암호화 자체는 매우 빠르지만, 페이지 리소스를 가져오기 전에 연결을 활성화하기 위해서 키교환을 해야 한다. 각각의 네트워크 상의 추가적인 교환은 연결을 만드는데 한 "왕복 시간"(RTT) 만큼 느리게 만든다.
현재 표준에서, TCP 위의 TLS는 교환을 위해 서버 사이에 여러 번 왕복(3-RTT)해야 한다 - 첫번째는 TCP, 두번째는 TLS - 처음 HTTP GET 명령 같은 유용한 정보를 처음 보내기 전에 반드시 수행되어야 한다. 이는 사이트가 콘텐츠를 여러 도메인에 나눴을 때 더 문제가 된다. 대게, 암호화를 하면 페이지 로딩 시간에 수백 밀리초 정도가 추가된다. 연구자들은 250ms 지연도 사용자들이 다른 웹사이트로 넘어가게 만들 수 있다고 한다.

TLS 1.3은 개발자들이 암호화된 콘텐츠를 전달하면서 이런 지연 시간을 제거할 수 있게 한다. 이 뜻은 현대 암호화와 지속적으로 개선되는 TCP 스택을 계속 사용하면서 성능과 보안을 다 충족시킬 수 있다는 것이다. TLS 1.3은 표준화 과정을 밟고 있고, IETF는 2016년 여름에 발표될 것으로 예상가고 있다. 하지만 TLS 1.3 없이도, TCP Fast Open과 TLS False Start 옵션으로 지연 시간을 3-RTT에서 1-RTT로 줄일 수 있다. 페이지 로딩 시간을 50ms만 줄여도 더 나은 웹서핑을 즐길 수 있다는 것을 고려해보면 된다.
2.2.7.2. TCP와 TLS의 전체 핸드 쉐이크
현재 TCP와 TLS 표준은 서버에 3번 왕복해야 한다 (3-RTT). 첫 번째 왕복은 TCP 연결 인수를 교환하기 위해 필요하다. 두 번째 왕복에서, 클라이언트와 서버가 연결의 키와 인수를 교환하기 위해 클라이언트 Hello와 서버 Hello로 시작하는 TLS 메시지를 교환한다. 마지막 왕복에서는 TLS 핸드 쉐이크 무결성을 확인하기 위해 클라이언트와 서버 완료 메시지를 교환한다.
파일:external/winblogs.azureedge.net/Full-handshake-diagram.png
2.2.7.3. TLS False Start와 TCP Fast Open으로 1-RTT 지원
TLS False Start 옵션은 클라이언트가 암호화된 데이터를 첫 번째 TLS 왕복 직후에 바로 보낼 수 있다. 이를 통해 TLS 기준 1-RTT, TCP 연결 기준 2-RTT로 줄일 수 있다. 이미 엣지에 강력한 암호화 스위트를 탑재하고 TLS False Start 옵션이 켜져있다.
파일:external/winblogs.azureedge.net/False-start-diagram.png
다음 향상점은 RFC 7413에 정의된 TCP Fast Open 과정에 있다. RFC는 "Fast Open 쿠키"를 포함한 새로운 TCP 옵션을 정의했다. "Fast Open을 사용 가능한" 클라이언트가 처음 서버에 연결하면, 초기 TCP SYN 메시지에 빈 쿠키를 집어넣어서 서버가 응답에 유효한 쿠키를 넣어서 보낼 수 있게 한다. 이후 연결들에서 클라이언트는 쿠키를 TCP SYN 메시지 안에 넣어서 데이터를 즉시 보낸다. 만약에 서버가 데이터가 무결하다고 인식하면, 데이터를 받고 앱에 보낼 것이다. TCP Fast Open이 켜져 있으면, 연결이 완성되기 전에 데이터를 보내서, 응답이 즉시 돌아올 것이다. TCP Fast Open과 TLS False Start를 조합하면, 최초 TCP 핸드 쉐이크에 키 교환이 동시에 이뤄질 것이다. 이는 HTTP 트래픽이 시작하기 전에 1-RTT만큼만 걸린다는 것을 의미한다.
파일:external/winblogs.azureedge.net/TFS-TFO-Diagram-1024x562.png
2.2.7.4. TLS 1.3으로 0-RTT 지원
TCP Fast Open about:flags 설정에서 지원한다. 주소 창에서 about:flags라 치면 TCP Fast Open 설정을 관리할 수 있다. 현재는 기본값으로 꺼져 있고, 더 많은 텔레메트리 데이터를 수집하기 위해 조정할 수 있다고 한다.
파일:external/winblogs.azureedge.net/about-flags.png
다음 단계는 TLS 1.3으로 1-RTT에서 0-RTT로 향상시키는 것이다. 0-RTT를 안전하게 실현하는 것은 어렵다 - 모든 0-RTT 해법들은 클라이언트에서 키와 암호화된 데이터를 서버에서 오는 피드백을 기다리지 않고 바로 보내야 한다. 최소한, 공격자가 메시지를 잡아내고 다시 볼 수 있다는 것이다. 이 뜻은 이 기능은 굉장히 조심스럽게 사용되어야 한다는 것이다. 또한, Hello 메시지에 식별자를 평문 텍스트에 넣어서 개인 정보를 침해하는 방법이나 최초 암호화가 서버 공개키에 의존하는 방법이어서 다음 연결이 위험한 경우 같은 잠재적인 장애물들이 있다. IETF 작업 그룹은 이런 문제들에 대해 의논하고 있고, 그것들이 해결되면 이 기능이 2016년 여름에 구현될 것이고, 표준안은 몇달 뒤에 발표될 것이다.
파일:external/winblogs.azureedge.net/TLS-13-TFO-diagram.png
HTTP/2, TLS 1.3, TCP Fast Open, TLS False Start로 엣지에 0-RTT 경험을 전달하고 있다. 또한 상호 운용 가능한 TLS 1.3 솔루션을 제공하기 위해 표준안에 참여하고 있다.

3. 버전

3.1. 20.10240

2015년 3월 30일에 테크니컬 프리뷰의 10049 빌드를 통해 엣지가 처음으로 대중에 공개되었다. 발표회에서 밝혔던 필기 기능, 리딩 리스트 기능, 코타나 연동 등의 기능들이 전부 사용 가능한 상태로 풀렸다. 첫 번째 정식 버전인 20.10240.16384.0은 7월 29일에 윈도우 10과 함께 공개되었다.

파일:external/az648995.vo.msecnd.net/Countdown-to-Windows-10-Edge-image-1024x601.jpg

3.2. 25.10586

두번째 정식 버전인 25.10586 버전이 2015년 11월 12일부터 Windows 10 1511 업데이트와 함께 배포되었다. ObjectRTC 지원, 탭 미리보기 기능, 미디어 캐스팅 기능 등의 향상점이 있다.

3.2.1. EdgeHTML 13[8]의 기능 업데이트

HTML 기능을 강화했다. 다음 사진은 HTML5Test라는 곳에서 즉정한 HTML5 표준 지원 정도를 나타내고 있는데, 7월에 나온 EdgeHTML 12보다 56점이 상승했다.
파일:external/az648995.vo.msecnd.net/HTML5Test-300x98.png

3.2.2. 차크라 엔진 기능 업데이트

자바스크립트 최적화를 위한 asm.js가 이제 기본으로 켜져 성능 향상이 있었다고 한다. 그리고 자바스크립트 최신 표준인 ES2016 지원을 확대해 Kangax EX6에서 가장 높은 점수를 보유하던 시기도 있었으나, 애플의 Safari 10 버전이 공식출시와 함께 100% 를 찍으면서 그 영광도 옛말이 되었다. 크롬등도 이미 97%의 지원률을 보이는 상황에서 엣지는 그보다 낮은 지원률을 기록하고 있다.
파일:external/az648995.vo.msecnd.net/kangaxes6.png
참고로 FF는 FireFox, CH는 Chrome을, SF는 Safari를 지칭한다.
about:flags에 다음과 같은 자바스크립트 기능들을 프리뷰로 제공한다.

3.2.3. 지원 플랫폼 확장

EdgeHTML 13은 PC, 폰, Xbox One에도 지원된다. <picture> element와 extended srcset로 적응형 이미지를 폰에 보여줄 수 있고, WebGL과 GamePad API로 Xbox One의 브라우저에서 게임을 즐길 수 있다.
파일:external/az648995.vo.msecnd.net/EdgeHTMLVersions.png

3.2.4. 새로운 사용자 기능들

Edge 25로 버전업을 했으며(렌더링 엔진 EdgeHTML는 13), 탭 프리뷰, 즐겨찾기와 읽기 목록 동기화, 무선 멀티미디어 캐스팅 등을 지원한다.
파일:external/az648995.vo.msecnd.net/cuoco.jpg
그 외에도 윈도우 커널의 코드 통합 강제 기능을 넣고, 스마트 스크린 필터를 업데이트해 드라이브-바이 다운로드(Drive-By download) 공격을 보호한다고 한다.

3.3. 38.14393

2016년 8월 2일에 정식 배포되었다. 윈도우 스토어에서 브라우저 확장기능 설치, 수 많은 새 기능들, 전력 소모와 보안 향상 등을 했다. 그리고 브라우저들 중 처음으로 HTML5Accessibility.com에서 100% 점수를 받은 접근성이 좋은 브라우저다.

3.3.1. 마이크로소프트 확장 기능

윈도우 참가자들에게 몇 개의 확장 기능을 프리뷰로 제공하면서 확장 기능 플랫폼을 제공하려고 했다. 이제 1주년 업데이트로 완전히 공개되었다.
파일:external/winblogs.azureedge.net/extensions.png
AdBlock, Adblock Plus, Amazon, Evernote, LastPass, 마이크로소프트 번역, Office Online, Pinterest, Pocket 등의 확장 기능들을 윈도우 스토어에서 제공한다. 이 외에도 미래에 다른 확장 기능들을 높은 퀄리티로 계속 윈도우 스토어에 제공할 것이라고 한다. 확장 기능은 마이크로소프트 엣지 메뉴의 "확장 기능"을 선택하거나 윈도우 스토어에서 찾을 수 있다.

3.3.2. 접근성 기능 강화

그동안 접근성 기능 지원에 대한 로드맵과 작업을 해온 결과 EdgeHTML 14에서 HTML5Accessibility 브라우저 벤치마크에서 100점을 맞을 정도로 접근성 기능 지원이 좋은 브라우저가 되었다고 한다.

파일:external/winblogs.azureedge.net/html5a11y-1024x338.png

중요한 몇 가지 향상점들과 수백 개의 버그 픽스를 통해 키보드와 스크린 리더 같은 접근성 기술로 내비게이션이 쉬워졌고, PDF 파일 지원 강화와 주소 바 추천 및 즉각적인 답변에 대한 내레이터 지원, 그리고 탭, 창, 즐겨찾기 같은 일상적인 브라우저 기능들에 대한 넓은 범위의 향상을 이끌어냈다. 또한 렌더링 엔진에 새롭게 만든 접근성 아키텍처를 탑재해, 개발자들이 HTML5 기반 접근성 사용자 경험을 만들 수 있게 되었다. 또한 사이트들과 다른 브라우저 벤더들이 HTML5 Accessibility 테스트 스위트를 자동으로 실행할 수 있도록 오픈소스 툴을 개발했다고 한다.

3.3.3. 새로운 기능

크롬에 있는 기능으로, 자주 사용하는 사이트들과 웹 앱들을 클릭 한 번으로 가기 위해 탭을 고정시킬 수 있다 - 아무 탭이나 우클릭 후 "고정"을 선택하면 된다.
파일:external/winblogs.azureedge.net/pinned-tabs.png
고정된 탭들을 언제나 탭 행의 시작점에서 사이트 아이콘만 보일 것이다. 마이크로소프트 엣지 창에 있는 고정된 탭들은 앱을 닫아도 다시 열 때 보일 것이다. 링크를 클립보드로 복사하면, 주소 바에 우클릭 하고 우클릭 메뉴에 "붙여넣고 바로 이동"를 누르면 바로 그 사이트로 갈 것이다.
파일:external/winblogs.azureedge.net/paste-and-go.png
링크말고 다른 것을 클립보드에 복사하면 대신 "붙여넣고 검색" 옵션을 볼 것이다. 엣지에서 웹사이트들일 알림을 보낼 수 있게 되어, 웹용 스카이프, 슬랙, 왓츠앱 같은 즐겨찾는 사이트에서 즉시 메시지나 업데이트를 볼 수 있다.
파일:external/winblogs.azureedge.net/web-notification.png
그리고 항상 사이트가 알림을 보내기 전에 엣지가 권한을 물어볼 것이고, 마이크로소프트 엣지의 설정이나 윈도우 10의 액션 센터에서 알림을 우클릭 해서 알림을 관리할 수 있다. 손가락을 쓸어서 뒤로/앞으로 가기를 할 수 있다. 터치스크린 PC나 윈도우 10 모바일 장치에서, 손가락으로 좌우로 밀면 히스토리의 전후 페이지로 가게 된다. 웹 상의 아무 사진이나 우클릭 후 “Ask Cortana”를 선택하면 연관된 정보나 사진들을 알아내서 더 많은 정보들을 제공할 것이다.
파일:external/winblogs.azureedge.net/ask-cortana-1-300x286.png 파일:external/winblogs.azureedge.net/ask-cortana-2-300x264.png 파이어폭스, 크롬, 인터넷 익스플로러에서 즐겨찾기를 가져올 수 있다. 다른 브라우저에서 즐겨찾기를 가져올 때, 이미 있던 즐겨찾기와 섞이지 않고 다른 폴더 안에 분리될 것이다. 즐겨찾기는 허브의 새 "트리" 디스플레이를 통해 더 쉽게 관리할 수 있다. 또한 폴더들을 확장하고 축소해서 안의 콘텐츠를 보고 싶은 만큼 볼 수 있다. 또한 즐겨찾기 탭의 즐겨찾기가 이름 순으로 정렬되어있고, 드래그 앤 드롭으로 재정렬 하거나 폴더 사이를 옮길 수 있다. 즐겨찾기 바에서 우클릭 해 디스플레이 아이콘만 보이게 하거나, 아이템의 이름을 바꾸거나, 새 폴더를 만들 수 있다. 엣지를 닫아도 진행중인 다운로드에 대한 알림을 보내준다. 그에 따라 엣지를 닫아도 다운로드를 완료할 수 있게 해준다. 또한 기본으로 다운로드된 파일들을 저장할 곳을 설정할 수 있다. "설정"을 열고, "고급 설정"을 선택한 후, "다운로드" 및의 새 옵션들을 볼 수 있다. 마이크로소프트 엣지에 폴더 째로 드래그 앤 드롭으로 OneDrive, Dropbox, Google Drive 같은 곳에 폴더를 업로드할 수 있다. 폰의 앱으로 새 탭을 열었을 경우에 엣지가 자동으로 관리한다. 만약에 앱에서 링크를 클릭해 새 탭을 열고, 뒤로 가기 버튼을 누르면 자동으로 탭을 닫고, 앱으로 돌아갈 것이다. 자동으로 탭들을 닫아 탭 리스트가 최소한으로 관리된다. 홀로렌즈에서 탭 위에 시선을 두면 PC와 같이 페이지의 썸네일 프리뷰를 볼 수 있다. 그것 말고도 더 많은 기능들을 보고 싶으면 "..." 메뉴를 열고 "새로운 기능과 팁"을 누르면 된다.

3.3.4. 효율, 보안, 성능, 호환성 강화

기본적인 전력 효율, 보안, 성능, 호환성에 대해 지속적으로 투자했다고 한다. EdgeHTML 14에서, 자바스크립트 타이머 실행 주기를 줄이는 방식으로 백그라운드 탭 효율을 향상시켜 몇몇 경우에 90%까지 에너지 소모를 줄였다고 한다. 또한 불필요한 플래시 콘텐츠를 사용자가 클릭해 재생할 때까지 일시 정시시켜 플래시 효율정을 높였다고 한다. 그리고 플래시를 분리된 프로세스로 만들어, 플래시가 너무 많은 리소스를 쓰거나 충돌하면, 엣지가 웹사이트의 나머지 부분에 영향을 주지 않고 플래시를 끌 수 있다고 한다.
브라우저에 노출되는 커널 컴포넌트를 줄이고 플래시와 콘텐츠 프로세스에서 호출 가능한 커널 콜 리스트를 만들고 강제하는 기능인 커널 공격 보호 기능을 엣지에 탑재했다고 한다. 또한 플래시가 분리된 AppContainer에서 돌아가기 때문에 플래시 취약점과 연동된 위험들을 줄일 수 있었다고 한다. 브라우저 렌더링 엔진은 몇 개의 다른 서브시스템들로 만들어지는데, 이는 각각의 페이지의 부하가 다르게 걸리게 했다. EdgeHTML 14에서, 더 빠른 경험을 위해 핵심 컴포넌트들이 더 빠르고 효율적으로 작동하게 하도록 성능을 측정하고 다듬었다고 한다. 밑의 애플과 구글에서 만든 벤치마크들에서도 엣지가 일관되게 이기고 있는 것을 볼 수 있다.
파일:external/winblogs.azureedge.net/performance.png
제품의 일반적인 튜닝과 더불어, 차크라 자바스크립트 엔진에서 함수들의 메모리 최적화와 이벤트 핸들러들의 지연 파싱, 그리고 frame.contentDocument, iframe.contentWindows, scriptElement.src, requestAnimationFrame 같은 일반적인 자바스크립트 API 성능 최적화와 콜백 오버헤드 감소 같은 성능 향상을 통해 많은 잘 알라젼 프레임워크들과 코딩 패턴들에서 더 좋은 경험을 할 수 있게 되었다.
마지막으로, 키보드와 스크롤바 액션들 같은 스크롤링을 UI 쓰레드에서 완전히 분리시켜 개선했다고 한다. 이는 복잡한 페이지들이 로딩과 렌더링하느라 바쁜 와중에도 터치, 터치패드, 마우스 휠, 키보드로 문서를 스크롤할 수 있다는 것이다. 작년부터 상호 운용성(렌더링 엔진을 개발자들이 실제로 쓰고 있고 현재 유명한 브라우저들이 지원하는 "상호 운용 가능한 부분"에 대한 API를 맞추기)에 대해 집중했다고 한다. 1월부터, 마이크로소프트 엣지에서 사이트들이 "그냥 작동하도록" 자체적으로 평가를 했다고 한다.
11월의 EdgeHTML 13부터, IE11보더 현대 웹에 더 호환이 잘되어 구글 크롬과 비슷한 수준까지 올라갔다고 한다. 이 철학은 이전의 수동으로 관리되는 호환성 리스트보다 더 많은 웹 사이트에 적용할 수 있다고 한다.
EdgeHTML 14에도 똑같은 방식을 적용해, 윈도우 참가자 프로그램들과 마이크로소프트 엣지 개발의 툴을 통해 받은 개발자들과 소비자들의 직접적인 피드백과 어마어마한 인터넷 스케일 데이터를 통해 같은 전략 아래에서 만들었다고 한다.
파일:external/winblogs.azureedge.net/compatibility-1024x680.png
Edge 14는 많은 새 HTML5 표준, 미디어 포맷, 그리고 자바스크립트 기능들을 포함해, HTML5Test에서 파이어폭스와 맞먹고, 사파리를 충실히 제치고 있다고 한다(최초 배포인 EdgeHTML 12부터). HTML5Test는 웹 플랫폼을 만드는 표준들의 부분집합의 존재 유무를 테스트하고 있다. 복잡한 벤치마크는 아니지만, 플랫폼 추이를 알 수 있고, 현대 렌더링 엔진들이 얼마나 핵심 기술들의 상호 운용 가능한 부분들을 커버하는지 알 수 있다고 한다.
EdgeHTML 14의 새 기능들은 다음과 같다.

3.3.5. 기업용 기능

모든 윈도우 10 소비자들에게 더 빠르고, 효율적이고, 호환성이 좋고, 안전하고, 생산성이 좋은 브라우징 경험을 제공한다. 기업용 소비자들을 위한 다음 기능들을 추가했다: 조직들이 엣지를 기본 브라우저로 쓰고, 하위 호환성이 필요한 사이트들에 대해서만 인터넷 익스플로러 11로 내려가게 할 수 있다. "당신의 조직이 이 사이트를 인터넷 익스플로러로 열도록 설정했습니다"가 더 이상 기본으로 나오지 않고, 인터넷 익스플로러를 쓰는 사이트를 엔터프라이즈 모드 사이트 리스트에 추가해 제한할 수 있다. 또한 소비자 피드백을 기반으로 다른 관리 정책들을 "사용자"와 "컴퓨터" 정책에 둘 다 추가시켰다.

3.4. 40.15063

2017년 4월 11일에 배포될 예정인 Windows 10 버전 1703 (크리에이터 업데이트, 레드스톤 2)에 포함되는 Microsoft Edge이다. WebRTC 지원이 개선되고 각종 악성코드의 치명적인 유포 경로로 활용되는 Adobe 플래시 플레이어 차단 기능이 강제적으로 활성화되도록 개선되었다. 설정뿐만이 아니라 about:flags를 이용해도 절대 해제할 수 없다. 이 버전에서는 브라우저 렌더링 엔진이 EdgeHTML 15로 버전업이 되었다.

또한 크리에이터 업데이트를 미리 받아서 확인한 결과, 다양한 기능들이 추가되어 있다. 예를 들어 이전에 강제 종료로 인해 탭이 복구될 경우, 탭을 바로 보여주지 않고 '모두 닫고 탭을 새로 시작하겠습니까?'라고 묻는다.

한편 Internet Explorer도 변화가 생겼는데, 노골적으로 '제발 윈도우 사용자라면 엣지 좀 써주세요'라는 의미로 새 탭 옆에 엣지 띄우는 버튼이 생겼다.

3.5. 41.16299

Windows 10 버전 1709(레드스톤 3)에 업데이트되었다. 브라우저 렌더링 엔진이 EdgeHTML 16으로 올라갔다.

몇몇 UI가 조금 개편되었으며 가장 큰 특징은 공유 기능과 전체화면, 나레이터 기능, GIF의 재생속도 조절이나 일시정지 기능 등이 업데이트되었다. 이 버전부터 FLAC 오디오를 지원한다. 그리고 플래시 플레이어를 다시 활성화할 수 있게 되었다.

맨 위부분이 반투명해졌다.

3.6. 42.17134

Windows 10 버전 1803( 레드스톤 4)에 업데이트되었다. 브라우저 렌더링 엔진이 EdgeHTML 17으로 올라갔다.

HTML5Test가 476에서 492점으로 크게 올랐다.[9]

3.7. 44.17763

Windows 10 버전 1809( 레드스톤 5)에 업데이트되었다. 브라우저 렌더링 엔진이 EdgeHTML 18으로 올라갔다.

3.8. 44.18362

Windows 10 버전 1903에 업데이트되었다. 브라우저 렌더링 엔진은 EdgeHTML 18을 유지했다. 이미 크로뮴 버전으로 넘어갔기에 보안 업데이트만 하는 것으로 보인다.

3.9. 44.19041

Windows 10 버전 2004에 업데이트되었다. 브라우저 렌더링 엔진은 EdgeHTML 18을 유지했다. 20H2를 설치하면 크로뮴 엣지로 전환된다.

4. 장단점들

4.1. 장점

4.2. 단점

5. 점유율

시장 점유율은 매우 낮았다.

파일:external/mspoweruser.com/Capture.jpg
2017.5 자료

StatCounter자료에는 2017년 상반기에 3.64%의 점유율이다. 2018년 8월에는 그나마 얼굴을 보일 수 있는 4.24%로 올랐으나 아직 갈 길이 멀고도 멀다.[15]

기술적으로 뛰어난 브라우저이고 OS기본 탑재라는 막강한 버프가 있는데도 불구하고 점유율이 낮은 이유는,
1) 크롬이나 파이어폭스 같은 경쟁자와 비교하여 '압도적인' 성능상 우위가 있는 것도 아니고,
2) 파이어폭스 플러그인이나 크롬 익스텐션 등 부가기능에 길들여진 사용자로 하여금 새로운 브라우저를 사용할 유인을 못 주고 있고,
3) MS가 기존의 IE와 Active X를 스스로 포기함으로써 오히려 유저들이 MS의 브라우저를 계속 쓸 이유가 없어진 것에 있다.

즉 크롬, 파이어폭스, IE는 각각 플러그인, 익스텐션, Active X라는 오랜시간 축적된 다양한 추가기능으로 그 추가기능을 사용하기 위해 유저를 그 브라우저 사용에 묶어두는 효과(진입장벽)가 있는데, Edge는 사실상 제로 베이스에서 시작한 새로운 브라우저로 전의 IE와 호환도 되지 않아서 예전 IE유저들을 Edge에 묶어두는 유인도 없을 뿐 아니라, 크롬과 파이어폭스 등에 비해 성능상 압도적으로 뛰어난 것도 아니어서 애매한 브라우저가 되었다는 데 있다.

Windows 10에서는 기본(Default) 브라우저가 Edge인데도 점유율이 처참한 것은, Windows 10을 설치한 유저들이 Edge를 키고 구글 크롬이나 파이어폭스 등의 다운로드 페이지로 가서 Edge를 외면하고 새 브라우저를 설치한다는 것인데, Edge를 공짜로 줘도 외면한다는 것이다.

IE와 넷스케이프가 경쟁하던 WWW(월드 와이드 웹) 인터넷의 초창기 시절에는, 특정 브라우저에 특화된 기술및 플러그인같은 축적된 진입장벽이 없던 시절이었으니 유저들은 아무 브라우저나 써도 되었고, 이로써 인터넷 초기 때는 OS 끼워팔기만으로 시장 점유율을 늘릴 수 있었으나, 지금은 그게 쉽지 않다는 뜻이다. MS는 Edge를 출시하고 IE를 지원종료한 순간부터 제로 베이스로 경쟁해야 하는 셈. 하지만 사람들이 익숙한 브라우저를 버리고 Edge로 갈아탈 이유를 찾아보기 힘든 것이다. 국내 금융기관이나 관공서를 이용하려면 Active X를 위한 IE 사용이 필수되므로 어떻게든 IE 사용은 남겨둘 필요가 있다. 따라서 주사용 브라우저(크롬, 파이어폭스 등)와 부사용 브라우저 IE를 혼용하는 국내 유저들이 많은데, 이 중에서 엣지를 사용하는 경우는 여전히 찾아보기 힘들다.

그리하여 주사용 브라우저를 엣지로 바꾸어, 주사용 브라우저 (엣지) + 부사용 브라우저 (관공서혹은 뱅킹용 IE) 로 사용을 전환하는 것도 고려할 수 있다. 기존에는 주사용 브라우저를 크롬이나 파이어폭스로 사용하였던 유저라면, 최근의 엣지의 성능향이 두드러지고 있고, 브라우저 로딩 속도도 엣지가 스무스할 뿐 아니라, 즐겨찾기를 IE와 공유하여 '실시간'으로 동기화한다는 것의 장점으로 엣지로 전환하는 것도 고려할 만하다. 이는 Win10 ver 1703 이후 생긴 기능이다.[16] 다만 아직까지 Edge에서는 쓸만한 Add-on 확장기능이 부족한 편이라, 만약 현재 쓰고 있는 크롬이나 파이어폭스의 확장기능이 Edge에 없어서 갈아타지 못하고 있다면, 향후 비슷한 기능이 Edge에 생긴다면 갈아타는 것도 고려할 만하다.

그나마 사파리보단 점유율이 높다고는 하지만 사파리는 macOS와 iOS에서만 사용 가능하다는 점을 감안하면 실질적으로는 사파리보다도 낮다.

5.1. 대한민국에서의 상황

파일:엣지야미안해.png

엣지가 나온 직후의 상황이다. 마이크로소프트 공식 스토어에서도 엣지로 상품을 구매할 수 없었다. 이후 결제 시스템이 외국과 같이 카드 번호만 입력하는 되는 방식으로 바뀌면서 결제는 가능해졌지만, 국내외겸용 카드로만 결제 가능하게 되었다.

사실 정보가 처음 나올 때만 해도 그렇게 많은 사람들이 긴장하지는 않았다. MS가 웹 표준을 표방하면서 액티브X 그만 쓰라고 개발자들에게 애원하면서도 레거시 지원 때문에 하위호환을 포기하지 못한 게 IE9 이래로 벌써 5년째이기 때문이다. 그러다가 2015년 4월이 되어서 서서히 새 브라우저의 윤곽이 드러나면서부터야 사람들도 이번엔 MS가 진심이라는 사실을 뒤늦게 깨달았다. 인사이더 프리뷰 빌드가 하나씩 나올 때마다 엣지와 IE의 차이점은 안드로메다행 급행열차를 타고 벌어져 나갔고, IE의 발전을 바라던 사람들의 관심과 함께 기존 보안 프로그램에 대한 걱정 또한 늘어갔다.

2015년 6월, 기존 방식에서 코드만 좀 바꿀 생각하고 뒷짐 지던 사람들이 뒤늦게 사태를 파악하고 충격과 공포에 빠지기 시작했다. 특히 오랜 경고에도 불구하고 끝내 액티브X를 비롯한 비표준 솔루션을 버리지 못한 은행 보안업계 측에서는 윈도우 10 발매를 한 달 앞두고 나서야 뒤늦게 당황하고 있었다.[17] 심지어 MS가 횡포를 부린다고 소설을 쓰기도 했다.[18] 당연하게도 멍청하지 않은 네티즌은 정부와 기자를 비난하고 있다. 또 공공기관 사이트에서 멀쩡히 출시일까지 발표한 윈도우 10 업그레이드 예약을 취소하라는 글을 올리기도 했다.

여기에 추가로 2015년 9월부터 구글 크롬 역시 현재 제한적으로 지원하고 있는 NPAPI 플러그인 지원을 중단하기 때문에, 이렇게 되면 윈도우 10 사용자들은 굉장히 곤란한 처지에 놓이게 된다. 엣지에서는 기존 플러그인이 작동하지 않으니 크롬을 사용하라고 할 수도 없는 일이고, 바탕화면에서는 제대로 보이지도 않아서 보조프로그램까지 들어가거나 엣지까지 한번 들어가서 열어야 하는 IE11을 통해 인터넷 뱅킹을 사용하는 방법을 일일이 알려줘야 하는 판이다. 컴퓨터에 능숙하지 않은 대부분의 사용자들에게는 엄청나게 불편할 수밖에 없다. 여기에 더해서 2015년도 하반기의 어도비 플래시의 허점을 통한 랜섬웨어 감염 사태까지 겹쳐서 대한민국의 인터넷 환경은 그야말로 혼돈 상태이다. IE의 플래시 플레이어는 업데이트 설정이 수동인 경우가 많았기 때문에 구버전 사용이 문제가 되었다. 다만 사태 자체는 어도비 플래시의 문제이기 때문에 IE만 가지고 뭐라 하기는 힘들다.

보안 업계의 회담 내용을 보면 적어도 일부 기업 및 기관에서는 장기적으로는 모든 보안을 HTML5로 해결할 계획이 있는 듯. 이러한 전환 과정은 굳이 엣지와 NPAPI 폐기 같은 악재들이 겹치지 않아도 진작에 밟았어야 할 과정인데, 브라우저 내에서 모든 민감한 보안 업무를 처리해버리면 사용자도 편하고 기업 측에서도 돈도 적게 든다. 굳이 앱이나 플러그인을 만들 필요 없이, 엣지뿐만이 아니라 크롬, 파이어폭스, 사파리, 심지어 IE11에서도 한 번에 모든 것을 해결할 수 있기 때문이다. 하지만 어떤 사정이 얽혀있든 간에 국내 기업들은 이런 가장 편한 방식을 진작에 시행하지 못했고, 결국 일러도 2015년 말까지는 IE11을 노인학대할 판이다.[19] 포기 안 하는 이유 중 하나가 실시간 이체 때문이다. 즉 이것까지 잡고 가려면 금융업계에 대격변이 곧 일어날 것이라는 소리다. 윈도우에서도 별도의 앱을 만들어서 하는 방법으로 하면 해결이 가능하다. 현재는 웹 브라우저기반으로 실시간 이체를 하게 하기 위해서 보안플러그인을 사용하는 것이다. 현재는 NEIS 및 업무관리 시스템, 에듀파인 등 대부분의 시스템이 IE11과 호환이 된다. 물론 ActiveX 플러그인을 사용하므로 엣지와는 호환이 안 된다.

그리고 많은 사람들이 예견했다시피 플러그인은 중단기적으로는 포기하지 않는 계획이 사실로 다가왔다. KISA의 보도자료에서 언젠가는 HTML5로 전환하도록 지금부터 업체를 선정하되 2015년 10월까지 모든 ActiveX 플러그인을 exe 플러그인으로 전환하여 12월부터 쭉 사용하겠다고 했는데, 제목부터 마치 곧 HTML5로 전환할 듯이 낚시를 걸어왔으니 미래는 안 봐도 뻔하다. 이렇게 되면 비 Windows 사용자의 접근성이 더 떨어지고(= 에뮬레이터 호환성이 낮아지고) 무엇보다도 보안성은 오히려 더 퇴행한다. 그런데 플랫폼 호환성에 대한 비난을 의식했는지, exe 플러그인뿐만 아니라 다른 OS용 플러그인도 지원하는 경우도 있다. 예를 들어 은행 웹을 우분투로 접속하면 deb 플러그인을 설치하라고 뜬다. 만약 대부분의 웹이 이런 식의 지원을 해주도록 바뀐다면, 적어도 호환성에서의 비판은 줄어들 것이다.

그런데 2015년 8월 말, KB국민은행이 최초로 플러그인을 일체 쓰지 않는 인터넷 뱅킹을 열었다. 문제는 엣지나 크롬이 아니면 이 뱅킹을 못쓰도록 UA를 가린다는 것이다. 2015년 9월 현재까지 국민은행만이 웹표준을 지키면서도 웹상에서 보안키보드와 공인인증서를 구현했는데, 사실 이렇게 되는 게 원래 맞는 것이다.

KEB하나은행의 경우 엣지 대응 업데이트를 하였으나 EXE 기반으로 업데이트가 되었다. 게다가 이 버전에서는 exe의 기능이 최소화되고 브라우저와 독립적으로 돌아가게 되면서 가상키보드가 의무화되었다. 덕분에 엣지에서는 플러그인은 플러그인대로 설치하고 물리키보드는 물리키보드대로 쓰지 못하고 무조건 마우스로 화상키보드 하나하나 클릭해야 한다.

이 외에도 NEIS도 대응이 안 되어 있는데, Adobe Air가 플래시기반이라서 그런 것인지 e교과서 다운로드가 엣지에서도 가능하다.

파일:Edge_ps.jpg

만약 '익스플로러에 최적화'된 사이트를 접속하려고 하면 접속이 불가능하다 뜨지만, 주소창에 about:flags를 입력 후 개발자 설정의 Microsoft 호환성 목록 사용을 체크 해제하면 엣지에서도 웬만한 이용은 가능해진다.

6. 단종

2020년 1월 15일, 크로뮴 엔진을 기반으로 한 새 Microsoft Edge가 정식 출시되었다. Microsoft는 2021년 3월 9일 Microsoft Edge 레거시를 지원 종료하기로 했고 그렇게 Edge 레거시는 역사 속으로 사라졌다. #

2021년 4월 13일 배포된 정기 업데이트(KB5001330)를 설치하면 제거된다. 이로써 MS의 자체 엔진 브라우저는 완전히 끝을 맺게 되었다. 따라서 1904x.928 버전부터는 Edge 레거시 없이 크로뮴 기반의 Microsoft Edge만 설치된다.

7. 여담



파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는
문서의 r970 판
, 2번 문단
에서 가져왔습니다. 이전 역사 보러 가기
파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 다른 문서에서 가져왔습니다.
[ 펼치기 · 접기 ]
문서의 r970 판 ( 이전 역사)
문서의 r 판 ( 이전 역사)

[1] Stable(안정화) 버전 기준 [2] Microsoft Edge 사이트로 리다이렉트된다. [3] 훗날 크로뮴 브라우저로 넘어가는 것을 완전히 이사하는 것으로 비유할 수 있을 것이다. [4] IE 6과 IE 7은 렌더링 방식이 거의 같아서 그런지 그냥 7로 통합시켰다. [5] # [6] ZDnet [7] # [8] 레이아웃 엔진 버전은 13, 브라우저 버전은 25 [9] # [10] Battle of the browsers: Edge vs. Chrome vs. Firefox vs. Safari vs. Opera vs. IE vs. Vivaldi - Digital Trends 2016.6.03 [11] # [12] # [13] 출처 - 클리앙 [14] # [15] # [16] 참고 [17] # [18] # 아카이브 [19] # [20] # [21] 관련 글 [22] 참고 [23] #, # [24] # [25] # [26] # [27] 영상 37분 27초

분류