 |
블로그를 방문해 주셔서 감사합니다! 어느덧 되돌아 보니 긴 시간이 한순간에 흘러가 버린 것만 같습니다. 하지만 개미와 같이 열심히 일한 덕분에 조금씩 성과가 나타나고 있습니다. 이런 노력이 계속된다면 좀 더 획기적인 결과와 우리는 만날 수 있을 것이라 기대합니다. |
[기사]이젠 Captcha마저 막을 수 없단 말인가? | 뉴스[기사]이젠 Captcha마저 막을 수 없단 말인가?
다수의 웹메일 계정 서비스업체들이 자동으로 메일계정을 생성하는 봇(bot) 소프트웨어를 막기 위한 기술을 적용하고 있지만 스패머들이 이를 간단히 무력화시키고 있는 것으로 드러났다.
스패머들은 무단 메일을 발송하기 위해 주로 핫메일, 야후와 같은 웹메일 서비스를 사용한다. 계정 1개당 한번에 보낼 수 있는 수가 제한돼 있기 때문에, 엄청난 양의 메일을 발송해야 하는 스패머들은 수천 개에 달하는 웹메일 계정을 등록해야 한다. 이 계정 등록과정을 자동으로 처리하는 소프트웨어가 바로 봇.
야후, 핫메일, 네이버 등 웹메일 업체들은 봇 소프트웨어의 자동 계정등록을 막기위해 계정 등록시 ‘Captcha(Completely Automated Public Test to tell Humans and Computers Apart)’ 테스트를 거치도록 하고 있다.
Captcha는 간단한 단어를 시각적으로 훼손시키고 복잡한 패턴의 배경화면 위에 보여준다. 메일 계정을 등록하려는 사용자는 해당 단어를 그대로 키보드로 입력해야 계정을 생성할 수 있다. Captcha가 보여주는 ‘일부러 훼손시킨 글자’는 사람은 쉽게 알아볼 수 있지만 컴퓨터(봇)는 알아보지 못한다. 따라서 봇을 사용할 수 없는 스패머는 자동으로 계정을 생성할 수 없게 되고, 스팸 메일 발송도 그만큼 어려워지게 되는 것이다.
스패머가 이 Captcha 테스트를 무력화 시킬 수 있다는 사실은 올초 보잉보잉 블로그(boingboing.net)를 통해 처음 드러났다.
먼저 스패머는 포르노 사이트를 만들어 광고를
해 방문자를 모은다. 그리고 무료로 포르노 컨텐트를 보여주기전에 Captcha 인증 단계를 거쳐 방문자에게 단어를 입력하도록 한다. 바로 이 부분이 Captcha 테스트를 통과하는 단계다.
즉 스패머가 여기에 적용해둔 스크립트는 웹메일 생성의 Captcha 테스트 단계와 포르노 사이트를 동기화시키고, 방문자가 입력한 Captcha 단어를 즉시 봇 소프트웨어로 전송, 결국 봇이 계정을 생성하도록 한다. 방문자는 Captcha 단어를 입력한 대가로 포르노 컨텐트를 무료로 액세스할 수 있게 된다.
이에 대해 컴퓨터 어쏘시에이츠(CA)의 사이먼 페리 부사장은 웹메일 서비스 업체들이 새로운 보안책을 개발할 때 마다 결국 이를 무력화시키는 방법이 개발된다면서 “보안이란 것은 움직이는 타겟을 맞추는 일과 같다”고 말했다.
그는 “하지만 보안이 발전되면 스패머는 그만큼 스팸메일을 발송하기가 어려워진다. (서비스 보안 개발은) 바로 그 수준을 점점 더 높여가는 과정”이라며 비록 무력화하는 방법이 발견됐다고 하지만 Captcha는 분명히 스패머들의 작업속도를 늦추고 있음을 강조했다.
페리는 “Captcha가 적용되기 전에 봇 소프트웨어는 하루에 100만개의 핫메일 계정을 생성했다. 하지만 지금 스패머들은 1만개의 계정을 생성하려면 1만명을 먼저 자기 사이트로 불러 모아야 한다. 이는 분명한 발전”이라고 말했다.
MS 핫메일과 야후는 Captcha 문제에 관한 언급을 거부했다
1532 comments
( 41946 views )
| [ 0 trackbacks ]
| permalink
( 3 / 1097 ) 
4-6. OPML(Outline Processor Markup Language) | 일반4-6. OPML(Outline Processor Markup Language)
OPML은 "다른 운영체제와 환경 위에서 동작하는 어플리케이션에서 outline으로 구조화된 정보의 교환을 허락하는 XML 기반의 문서 형식입니다.
2000년 9월 16일에 Dave Winer (UserLand 소프트웨어)는 새로운 XML 기반의 “Outline Processor Markup Language" 또는 OPML, 1.0 공고했습니다.
"이 OPML 형식의 목적은 아웃 라이너를 통하여 탐색되거나 제어가 가능한 아웃 라이너와 인터넷 서비스 사이에서 정보를 교환하는 길을 제공합니다.
이경우에 '아웃라인'은 각 이음매가 끈 가치와 함께 한 세트의 이름을 지어지는 속성을 포함하는 트리입니다.
OPML 디자인 목적은 방대한 양의 데이터는 쉽게 탐색하고, 편집이 가능하드록 형상화된 포멧이기 때문에 쉽게 읽을 수 있다. 따라서 단순하며, 자체적으로 문서화가 가능하며, 확장성이 매우 뛰어납니다.
보다 쉽게 설명하자면 여러 개의 블로그 사이트 RSS 또는 ATOM을 하나의 문서 파일로 만들어 놓은 XML이 파일이 OPML입니다.
OPML 문서의 예)
<?xml version="1.0" encoding="EUC-KR"?>
<opml version="1.0">
<head>
<title>나의 OPML 목록</title>
<dateCreated>2005-05-16T11:55:41</dateCreated>
<ownerName>userid</ownerName>
</head>
<body>
<outline text="자주보는목록">
<outline type="rss" text="SecureIIS" title="SecureIIS" xmlUrl="http://blogbridge.naver.com/post/postXMLList.jsp?blogId=invictusy"/>
<outline type="rss" text="제목없음" title="제목없음" xmlUrl="http://blog.naver.com/tb/gkdus2004/20010744338"/>
</outline>
</body>
</opml>
5. RSS 리더별 RSS, OPML, ATOM 지원상황
사용된 XML의 URL
RSS 0.92
http://fantomaster.com/fantomNews/feed/rss/
RSS 1.0
http://www.w3.org/2000/08/w3c-synd/home.rss
RSS 2.0
http://blog.daum.net/xml/rss/yyeosan
http://ecrm.dreamwiz.com/GEN/rss/hompy.rss
RSS ATOM 0.3
http://blog.daum.net/xml/atom/yyeosan
4-4. 차세대 컨텐츠 신디케이션을 위한 ATOM 표준화 | 일반4-4. 차세대 컨텐츠 신디케이션을 위한 ATOM 표준화
RSS의 확산과 더불어 컨텐츠 신디케이션의 중요도에 대한 인식과 새로운 기능, 그리고 표준화의 필요성이 대두되었습니다.
컨텐츠 신디케이션 표준화를 위한 많은 논의와 노력들이 진행되었으나, 사실상 병렬화된 다양한 포멧의 RSS 규격을 단일화 시키고 표준화 시키기 어렵다는 결론에 도달하게 되었고, 새로운 표준화를 위한 ATOM이라는 이름의 프로젝트로 구체화되기 시작하였으며, 이 표준화 활동을 어디에서 진행할 것인가에 대한 많은 노력들이 2003년을 거쳐 2004년 초까지 진행되었다.
이 과정에서 Atom 프로젝트 그룹과 표준화 활동을 유치하기 위한 경쟁이 W3C와 IETF에서 벌어지게 되었다. W3C에서는 웹 기술과 시맨틱 웹 기술과의 연관성, 그리고 웹 표준화 기구라는 대표성을 내세워 W3C에서 활동이 진행되길 요청하였고, IETF에서는 보다 자유로운 참여가 가능하다는 장점을 내세웠다. 결국 사용자들의 투표에 의해 보다 자유로운 멤버들의 참여가 가능한 IETF에서의 활동하기로 결정하고, Atom Publishing Format and Protocol (atompub) WG을 구성하여 2004년 말부터 활동을 시작하였다.
현재 IETF의 AtomPub WG에서는 “웹 리소스들(블로그, 온라인 저널 등)을 위한 효율적인 컨텐츠 관리 프로토콜 개발”이라는 커다란 목적을 가지고 크게 세가지의 표준 초안 개발 작업을 진행하고 있으며, 이중 자동발견 규격을 제외한 두가지 표준 초안에 대한 표준화 작업을 진행하고 있다.
-5. RSS 와 ATOM 의 스펙 비교
RSS 에서의 ITEM 신디케이션 포맷
대부분의 경우 블로그 업체들은 description 중 일부 요약본만 전송시켜 줌으로써, 전문을 보기 위해서 자사의 사이트를 방문하도록 유도한다.
따라서 뉴스리더 프로그램에서는 항상 2~3 줄의 간단한 요약만 확인이 가능하다.
ATOM 에서는 ITEM (Entry 로 표현된다.)
ATOM 도 SUMMARY 형태의 description 을 제공하기는 하지만,
4-1~3. RSS 버젼4-1. RSS 0.91
피드(feeds)는 channel로 구성된다. channel 은 title, link, description, (optional) language 로 구성되며, channel 의 또 다른 구성요소인 item 은 title, link, description 으로 구성된다.
4-2. RSS 1.0
RSS 1.0에서 RSS는 "RDF Site Summary"를 의미합니다.
RDF 문서의 XML 직렬화(serialization)와 같이 RDF 와 함께 사람들에게 알려졌다.
이번 스펙보다 많은 정보를 포함해야 하지만 본질적으로 배급되는 정보는 같다.
RSS 1.0은 RDF를 사용하고 XML-Namespaces( RSS Modules )을 이용하여 큰 마찰 없이 확장을 가능하게 해 줍니다. 모듈로써는 Dublin Core Module이 가장 잘 알려져 있습니다. RSS 1.0은 아래의 샘플 코드에서 보는 것 처럼 RSS 0.9x 와 거의 비슷하나 몇가지 다른 요소를 가지고 있습니다.
<rdf:RDF>...<rdf:RDF> Element를 사용한다.
RSS 1.0는 'http://purl.org/rss/1.0' ( Default Namespace ), 'http://purl.org/dc/elements/1.1/' ( Dublin Core )과 같이 Namespace를 사용한다.
Item Element가 Channel Element 밖에서 사용된다. ( RSS 0.9x 의 경우는 Channel Element 내부에 있슴 )
※item 레벨의 authors, publishing dates는 0.91에서는 제공되지 않는다.
4-3. RSS 2.0
RSS 1.0와 유사한 네임스페이스를 사용합니다.
하지만, RDF 는 아닙니다.
RSS 0.91 과 같이 2.0에서는 디폴트 네임스페이스가 없고, item은 channel에 포함됩니다.
RSS 0.92까지는 아이템의 수가 제한 되어 있었으나 RSS2.0에 오면서 숫자에 제한이 없어 졌습니다.
또한 아이템(item)에 해당하는 모든 요소(Element)는 선택사항입니다.
4. RSS 각 버전별 내용 | 일반4. RSS 각 버전별 내용
|
버전 |
제작 |
내용 |
현재상태 |
|
0.9 |
Netscape |
RSS의 초기 버전 |
1.0에 포함되어 사용하지 않음 |
|
0.91 |
UserLand |
간단한 구조 |
2.0으로 흡수되었으나 여전히 많은 곳에서 사용 기본적인 신디케이션에 이용 2.0으로 변경이 용이 |
|
0.92 0.93 0.94 |
UserLand |
0.91 보다 풍부한 메타데이터(metadata) 제공 |
RSS 2.0 포함 많이 사용되지 않으면 2.0 사용을 권고 |
|
1.0 |
RSS-DEV Working Group |
RDF를 기반 모듈을 통한 확장성 단일 벤더에 의해 조정되지 않음 |
안정된 핵심표준 주요 모듈 표준 개발 진행 중 RDF 기반의 Aplication 사용하거나 RDF 모듈이 필요할 경우 |
|
2.0 |
UserLand |
모듈을 통한 확정성이 있고 0.9x 버전에서 쉽게 이전 가능 |
안정된 핵심표준 주요 모듈 표준 개발 진행 중 일반적인 목적으로 이용, metadata-rich 신디케이션 |
