전부터 도대체 키보드 보안 프로그램을 왜 강제로 깔아야 하는지에 대해 불만이 많았었어요. 간단하게 랜덤하게 표시되는 숫자판을 보여주고 마우스로 클릭하게 하면 훨씬 직관적일 것 같았거든요.

그런데 최근 국민은행의 경우 이런 인터페이스가 도입되었더군요.
모든 은행이 다 그런지는 모르겠지만 일단 이런 시도는 정말 환영할 만한 것 같아요.

사용자 삽입 이미지

아직은 인터페이스가 썩 편하지는 않고 입력키 자체도 화면 분석하면 금방 해킹이 가능한 형태라서 썩 좋다고 볼 수는 없지만 조금 더 다듬는다면 그놈의 키보드 보안 모듈은 사라지게 될 수 있겠죠.

제발 그러길 바래요.
신고
Posted by gongdo

네이버 실버라잇 카페에 올라온 질문(http://cafe.naver.com/mssilverlight/166)에 대한 나름대로의 생각이에요.



사용자 리소스에의 무제한적인 접근.
이것이 바로 ActiveX가 훌륭한 기술임에도 불구하고 사방팔방에서 뭇매를 맞게된 가장 큰 원인이죠.
ActiveX에 대해 오해가 생기지 않도록 얘기하자면 엄청나게 길어지겠지만, 과감하게 압축해서 얘기해볼께요. 다소 엉뚱한 주장이 들어가더라도 이해해 주세요.

ActiveX는 애초에 HTML의 한계를 벗어난 동적인 웹애플리케이션을 작성하기 위한 시도였어요. 무려 10년도 전에 이미 지금 말하는 RIA라는 것에 대한 고민과 하나의 해답이었던거죠.

시장의 흐름을 캐치하고 빠르게 ActiveX를 발표한 것 까진 좋았는데, MS가 늘 그래왔듯이 초기에는 거대한 구멍투성이의 기술이었고 이를 애초의 목적인 동적인 UI 구성에 사용하는게 아니라 갖가지 악의적인 구멍으로 사용되어 버렸죠.

해외에서는 진작에 이런 문제점들과 플랫폼 종속적인 한계 때문에 최강의 기술이었던 ActiveX를 사용하기 보다는 다소 불편한 DHTML, JavaScript, CSS 등의 기술들을 더 선호하게 되고 급기야 구글맵으로 유명해진 AJAX를 탄생시키게 되었죠.

반면 국내에서는 해외와 달리 일반 유저의 IE 의존도가 99% 이상이었기 때문에 애초에 플랫폼을 고려할 필요가 전혀 없었고 보안 문제는 누구 하나 지적하는 일 조차 없었어요. 국내 개발자들을 탓하는게 아니에요. 보안... 당장 한달 걸릴 일을 1주일만에 해내라고 닥달하는데 누가 신경이나 쓸 수 있었겠어요? 여하튼.

그런 와중에 ActiveX의 무분별한 사용을 어느정도 제어하기 위해 XP SP2가 출시되었지만 국내는 이미 ActiveX 중독 말기환자였고 정상적으로 ActiveX를 꼭 필요한데만 사용하는게 아니라 사용자에게 'ActiveX 설치 어쩌고 나오면 예를 누르세요', '팝업이 막히면 풀어주세요' 이따위 대응을 하게 되었던 거죠.

이 점은 강력하게 개발자를 성토할 수 있어요. 분명히 중독에서 치료될 수 있는 기회였는데 스스로 거부한 셈이죠. 여하튼.

이런 역사(?)때문에 ActiveX가 웹애플리케이션의 전부인양 생각하게 되었고 웹애플리케이션이 사용자 리소스에 접근하는데 아무런 거리낌이 없게 되었지만, 단정적으로 얘기해서 웹애플리케이션은 사용자 리소스에 접근 할 수 없고 접근 해서도 안되는 거에요!

ActiveX에 대해 정리하자면,
1. ActiveX는 동적인 UI 구성 등을 기존 윈도 개발자가 빠르게 접근할 수 있도록 도와주기 위해 나온 기술이다.
2. 하지만 그 무한한 접근권한 때문에 원래 의도와는 달리 철저하게 악용되는 기술이 되어 버렸다.
3. 그런 문제 때문에 ActiveX의 무분별한 사용을 줄이고 다른 방법으로 웹애플리케이션을 구현하게 되었는데 국내에는 중독에서 헤어나오지 못했다.
4. 그 결과 국내에서 ActiveX를 통해 사용자 리소스에 접근하는 것에 대해 아무런 의문도 문제점도 느끼지 못하게 되었다.

이에요.

다음 실버라잇으로 넘어가서, MS는 어느 매체에서도 실버라잇으로 ActiveX를 대체할 거라고 발표한 적은 없어요.

다시 한번 강조하지만 실버라잇과 ActiveX는 개미 눈꼽만큼도 비교할 만한 기술이 아니에요.

비교한다면 실버라잇, Flex(플래쉬도 아닙니다), JavaFX인지 뭔지(이쪽은 관심이 없어서 이름도 잘 몰라요;;;) 이 정도 되겠고요.

심지어 DHTML도 실버라잇과 비교할만한 기술은 아님과 동시에 DHTML, CSS, JavaScript, AJAX 등의 기존 기술은 실버라잇과 함께 사이좋게 연동할 수 있는 평행한 관계라고 보면 되겠습니다.

Q. 그럼 도대체 실버라잇을 왜써요?
A. 좋은 질문이죠. 한마디로 압축하자면 실버라잇은 RIA를 구현하기 위한 기술이에요.

Q. 그럼 기존에 플래쉬도 Flex도 있는데 뭐하러 써요? 머리아프게?
A. 실버라잇은 프리젠테이션의 표현을 XAML이라는 XML로 완전히 공개적으로 제공하며 따라서 프리젠테이션의 교환, 다시말해 디자이너와 개발자와의 협업이 훨씬 더 유연해질 수 있어요. 그리고 이 XAML은 일반적으로 컴파일되지 않고 공개되므로 다른 웹애플리케이션, 다른 서비스들과 동일한 코드를 가지고 연동할 수 있어서 디자이너-개발자 수준을 떠나 서비스-서비스 수준의 협력이 가능해요.

단순히 기능적인 면만 살펴봐도 이미지 리소스와 동영상 리소스에 대한 런타임 자체의 지원이 실버라잇 쪽에 압도적으로 우세하고 특히 실버라잇은 완전한 클라이언트 기술로 서버 사이드에는 아무런 제약이 없기 때문에 Flex처럼 별도의 라이센스 서버나 라이센스된 코덱 같은 추가적인 낭비가 필요 없어요.

이 외에도 말하자면 엄청나게 많지만 이쯤하죠. 자세한 검색은 셀프.

Q. 그건 그렇다치고 그러니까 왜 내가 만든 실버라잇 프로그램으로 사용자 리소스에 접근 못해요? 우리 서버랑 통신도 해야되고 백도어도 만들어야 되고 파일 업/다운도 해야되는데...
A. ActiveX 편을 다시 복습하시기 바래요. 그리고 지금 백도어 까는걸 자랑이라고 하는거니? 응? 응? 응?

추가적으로 TCP통신 기능에 관해서는 Silverlight 1.1 개발팀에서 심각하게 그 방법을 제시하기 위해 노력한다고 MS의 로렌스 모로니씨에게 '직접' 들었어요.(맞아요, 자랑하는거에요. 히히 싸인도 받았지롱~) 실버라잇 개발 로드맵 상에도 WCF 기술이 포함되는 것은 거의 확정적이라고 보고 있으니 이 부분에 대해서는 조금 기다려야겠고, 지금 당장 필요하다면 서버사이드에 프록시를 만들어 연동할 수도 있어요.

Q. 에고... 그럼 파일 업/다운은요?
A. 옙. 돼요. 실버라잇은 사용자 리소스에 대한 접근과 크로스 도메인(외부 주소)에 대한 접근을 아주 철저하게 막고 있지만 몇 몇 애플리케이션 개발에 필수적인 수단은 제공해요.

예를 들어 파일 업로드를 위해 파일 목록을 얻어야 한다면 그 파일 목록을 개발자 코드가 지 꼴리는대로 검색해서 가져갈 수 있는게 아니라 사용자에게 업로드할 파일을 선택하는 다이얼로그를 띄워서 사용자가 직접 선택하게 되어 있고 다운로드 역시 다른 곳에 악용될 수 있는 시스템 폴더(C, C:\Windows, C:\Windows\System32) 따위에 명시적으로 접근할 수 있는게 아니고 실버라잇 웹애플리케이션에 종속적이고 암시적이며 다른 애플리케이션에 고립된 영역에 저장돼요. 만약 사용자가 저장을 원한다면 마찬가지로 저장할 위치를 결정하는 다이얼로그를 통해서만 가능하죠.

Q. 아 짱나 그냥 ActiveX 쓸래요.
A. 옙, 그러세요. 한가지 안좋은 소식이 있다면 VISTA 이후로 ActiveX가 예전처럼 지 꼴리는대로 사용자 리소스를 헤집을 수 있게 놔두지 않을거에요. 아직 레거시 지원때문에 이런저런 유도책을 제공하고 있긴 하지만 단언코 말하건대 ActiveX의 사용자 리소스 접근은 결국 막히게 될거에요. 뭐, 그때까지 생명연장의 꿈을 꾸는 것도 나쁘진 않겠죠. 모름지기 개발자는 꿈을 품고 살아야하니까요. ^-^

그냥 라이브 타이핑(?)하다 보니 말이 막나간 점도 있긴 하지만, 이 긴 문장들은 단 하나의 문장으로 요약할 수 있겠어요.

웹앱(Web Application)은 웹앱이요 데스크탑앱은 데스크탑앱이로소이다.

P.S.1. 혹시나 또 오해가 있을까 말해두지만, 질문 올리신 네오군님을 공격하기 위한 설명이 아니에요;; 나름대로 재미있게 쓴답시고 저렇게 쓴거니까 삐지지 마세요.
P.S.2. 추가적인 의견 대환영~♥

신고
Posted by gongdo


티스토리 툴바