'허니몬의 IT 이야기'에 해당되는 글 397건

허니몬의 IT 이야기
문제의 발단은 의외로 간단한 곳에 있었다.

익스플로러에서 LGTelecom.com 에서 쿠키를 사용하는 것을 차단하고 있었기 때문이었다.
쿠키 사용 차단을 해제하고 허용을 하니 정상적으로 변경이 진행된다.

하단부에 보면 인터넷 옆에 눈 표시 옆에 금지 표시가 되어있는 것을 볼 수가 있다. 이 부분을 더블클릭해서 "설정" 부분에서 클릭하니 정상적으로 된다. 쿠키가 차단되어 있으면, 로그인도, 그에 대한 반응도 아무것도 안되는 조악함이란... OTL...


오늘 오전(10:44에 연락옴)에 LGT 개발부에서 전화가 왔다. 자신들 쪽에서는 잘 된다고 한다.
그러나 중요한 건,
내 컴퓨터에서는 안되었던 것이고, 그 이유를 내가 찾았다는 거.


회원등록되어있는 내 이메일로 설정방법을 알려준다고 했는데 감감무소식이다. 어이없다..ㅡㅅ-);;

이게 ㅡㅅ-);; LGT의 응대수준이라면 매우 실망스런 상황이다... 쩝...

왜 이래? 아마추어같이?
허니몬의 IT 이야기/프로그래머, '코드 엔지니어'
관련 내용 : http://java.sun.com/developer/media/deepdivejdk7.jsp



JDK 7 버전이 릴리즈 된지 얼마 되지 않았다.

Host: Ed Ort, Senior Staff Information Engineer, Sun Microsystems
Guest: Danny Coward, Chief Architect for Client Software at Sun Microsystems

두 사람이 나누는 대담을 통해 JDK 7 에 깊이 빠져들어가보자.


JDK 7 : Top 5 New Features

#1 : Modularity
#2 : Multi-Language
#3 : New Garbage Collectors
#4 : Nio.2 File System APIs
#5 : Swing API Additions

#1 : Modularity
// Declaring that a class belongs to a module:
module M;
package P;

public class Foo {...}

//Defining a module in a module-info.java file

module M @1.0 {
requires N @2.1;
requires L @0.5;
}
Java SE 7 : Project Jigsaw
  • Low Level Modularity System in JDK 7
  • Breaking Up the JDK 7 Code
  • Packaging Format
  • Uses Java Language Modularity(JSR 294) // ㅡㅅ-);; JSR 은 뭐지?
http://openjdk.java.net/projects/jigsaw
http://jcp.org/en/jsr/detail?id=294

아래에 나오는 내용은 "Coin Project"란다.


String animal ="...";
   
    if ( animal.equals("dog")) {
        takeForWalk(animal);
    } else if ( animal.equals("cat")) {
        leaveMilkFor(animal);
    } else if ( animal.equals("mouse")) {
        cleanCageFor(animal);
    } else {
        leaveOutside(animal);
    }
※  JDK 7 에서는 switch 에서 case에 char 타입 이외에 String 타입도 사용이 가능하게 됩니다. 조건문이 쉬워지는군요.
    String animal = "...";
   
    switch(animal) {
    case "dog" : takeForWalk(animal);
    case "cat" : leaveMilkFor(animal);
    case "dog" : cleanCageFor(animal);
    default : leaveOutside(animal);
    }

※ Exception 처리
try {
        doWork(file);
    } catch ( IOException ioe ) {
        logger.log(ioe);
        throws ioe;
    } catch ( SQLException sqle ) {
        logger.log(sqle);
        throws sqle;
    }
  JDK 7 에서는 이렇게 가능하다. Ed Ort 씨 처럼 Ah~~ha~~!!
try {
        doWork(file);
    } catch ( final IOException | SQLException ex ) {
        logger.log(ex);
        throws ex;
    }

※ 다음은 Genericㄴ 사용법 : 아직 본인은 generics 사용법에 대해서 익숙하지 못하다. ㅡㅅ-);;;
Map<String, List<String>> anagrams = new HashMap<String, List<String>>();
JDK 7 에서는 이렇게 된다고 한다. ㅡㅅ-)b
Map<String, List<String>> anagrams = new HashMap<>();

※ 다음은 Operator
Object anObject;
    ...
    if (anObject == null ) {
        s = "nothing";
    } else {
        s = anObject.toString();
    }
   
    int i;
    ...
    if ( anInteger == null ) {
        i = -1;
    } else {
        i = anIntegerr;
    }
JDK 7 에서는 이렇게 바뀐다고 한다. " ?:  " 요놈인 건데... ㅡㅅ-)> 요건 뭐가 좋은거지? ?: == null 인건가?
   String s = anObject?.toString() ?: "nothing";
    int i = anInteger ?:-1;


#2 : Multi-Language  : supporting non-Java languages at the VM level
JVM에서의 실행속도를 높인다는 건가? Bytecode를 역동적으로!? 메소드 핸들러를 가볍게!? 최적화를 변동적으로?
Broadening the JVM to Accelerate Runtimes
  • Bytecode for Dynamic Invocation
  • Lightweight Method Handles
  • A Variety Of Other Possible Optimizations
JRuby is the Pioneer
The DaVinci Project
http://openjdk.java.net/projects/mlvm

#3 : New Garbage Collectors - Garbage First,
Predictably Low Pauses + Few Full Garbage Collectors + Good Throughput
Greate for a Wide Variety of Application

#4 : Nio.2 File System APIs
DirectorySearchOperations 라는 클래스가 추가된 듯 하다. 자바로 새로운 파일 시스템을 사용해볼 기회가 있었어야 말이지..ㅡㅅ-);; 흠...
  • New Filesystem API File Notifications Directory Operations
  • Asynchronous I/O

#5 : Swing API Additions
  Java의 Swing API에 대한 불만은 여전히 있었고, ㅡㅅ-);; 추가되었다는 내용을 봐도 불만은 여전히 유지가 될 것 같다. 사용자가 필요에 따라서 자신이 디자인한 부분에 대해서 적용할 수 있도록 해주면 좋지 않을까? ㅡㅅ-)~ 현재 나는 조용히 쓰라는 대로 써야지. ㅎㅎ.
JSR 296 : Swing Application Framework
http://jcp.org/en/jsr/detail?id=296

JDK 7 과 관련된 홈페이지(MileStone)
JDK 7 Milestones Homepage
http://openjdk.java.net/projects/jdk7/milestones/
openJDK Project Homepage
http://openjdk.java.net/project/jdk7/
JDK 7 Project Homepage
https://jdk7.dev.java.net/
The Planetarium Blog
http://blogs.sun.com/theplanetarium/

허니몬의 IT 이야기

이메일 접수 완료.

ㅡㅅ-) 다음 응대를 기다려 보겠다.
허니몬의 IT 이야기

OpenID 서비스 중 하나인 MyID 서비스를 이용하고 있는 허니몬.


● OpenID :
  하나의 ID로, 한번의 로그인으로 여러 서비스를 일일이 가입할 필요없이 사용하게 하는 인증 서비스 표준

● URL을 닮은 이유 :
  실제 존재하는 페이지(예를 들어 자신의 블로그 페이지나 싸이월드 페이지)만 ID로 허용하기 때문에, ID를 받는 쪽에서 좀 더 신뢰할 수 있는 근거가 되고(없는 페이지는 부적절한 ID로 처리), 그 신뢰 수준에 맞는 권한을 허용할 수 있게 됩니다.
- 그렇다면 DNS에 대한 검색 기능도 제공을 해야하겠네 : 허니몬 주 -

● OpenID는 스팸메일 걱정이 없다 :
  OpenID는 개인정보의 노출여부를 내가 통제할 수 있기 때문에, 중요한 Email을 노출하지 않을 수 있다.

● 개인정보의 노출여부를 통제할 수 있다는 뜻 :
  ID 자체는 아무 개인정보를 표현하지 않는다. 다만 ID와 관련해서, 방문하는 사이트에서 사용자에게 필요한 정보를 요청할 수 있다. 이때, 요청된 정보에 대한 전달여부는 전적으로 사용자가 결정한다.

● 메일주소를 계정으로 받는 서비스와의 차이점 :
  OpenID 는 한 서버에만 암호를 저장하고, 한군데만 가입절차를 밟으면, 이후 지원 서비스의 이용시 가입절차가 거의 없다.

● 국내사이트에서는 아직 지원하는 곳이 많지 않다 :
  국내 웹 2.0 신생 서비스들에서는 지원을 하고 있지만, 우리나라의 경우에는 웹 2.0에 대한 사람들의 관심이 그다지 높지 않다는 국가적 특색을 가지고 있어서, 실제로 어떻게 될지 여부는 알 수 없다. ㅡㅅ-);;

● 네이버나 다음, 싸이월드 같이 자신들의 회원을 많이 보유한 포털의 경우 오픈아이디를 빠른 시일 안에 지원할까? :
  포탈의 성격과 정책에 따라 다르지만, 일반적으로 로그인 기반의 포탈은 자신의 로그인 기반을 더욱 강화할 수 있기 때문에, 지원하는 서비스가 많아 질수록 유리할 것이다. 다만, 각 포탈이 사용자를 자신의 서비스들만 쓰도록 묶어두는 정책을 취하려고 할 경우-우리나라라면 가능성이 높음 -, 지원을 보류한다고 함.

● "지원하는 서비스가 많아질수록 유리하다?"는 것에 대한 설명 :
  특정 포탈 ID로 접근 가능한 서비스가 타 업체의 서비스들로까지 확장되기 때문에 포탈 ID에 대한 가치가 높아질 수 있을 것이라는 판단, Facebook, 아마존, 트위터 등의 OpenID 지원 사례 확인

● 아이디와 비밀번호를 별도로 입력하는 이유 :
  아이디는 인증이 필요한 서비스에게 알려주는 것이고, 암호는 아이디를 인증해주는 업체에 알려주는 것이다. OpenID에서는 두 업체를 분리하기 때문에 필연적으로 따로 입력하게 된다. OpenID는 편리성과 보안성을 분리해서 운영할 수 있게 해준다. 따라서, 보안수준이 높은 인증 서비스로 인증을 하면서도, 서비스의 편리성을 위해서 서비스 별로 자동로그인 등을 제공하면 된다. 기존의 방식은, 편리성와 안정성을 한 업체에서 제공하기 때문에, 둘 중 하나를 포기해야하는 경우가 많다.



  OpenID의 인증방식의 핵심은 사용자가 자신의 정보노출 여부를 직접 결정할 수 있다는 것이다. 더불어서 중복되는 가입절차를 줄이면서, 자신의 정보노출의 횟수를 줄이고, 노출횟수가 줄어들면서 개인정보에 대한 보안성을 높일 수 있다.  자신이 이용하려는 서비스에서 개인정보를 요청할 경우에는, 사용자가 그 서비스가 요청하는 정보수준을 확인하고, 노출을 스스로 결정하는 사용자 주권을 확립할 수 있을 것이다.

  하지만, 개선되어야할 부분으로는, 아직 우리나라에서는 OpenID에 대한 사용자들의 인식이 부족하고, OpenID의 사용을 권장할 수 있을 만큼 매력적인 서비스가 존재하지 않고 있는 상황이라는 것이다. 다양한 웹서비스들에서는 자신들의 서비스들을 거대한 통합페이지를 구축하여 사용할 수 있는 형태로, 사용자들을 자신들의 서비스 울타리 안에 가두려 하는 모습을 보이고 있는 상황이다. ㅡㅅ-);; 이건 결단코, 뮤직온에서 내 아이디에 대한 접근을 내가 할 수 없기 때문에 하는 이야기다. 아직도 OTl.... 접근 안된다.
  우리나라의 비상식적인 서비스의 폐쇄성으로 인해서, OpenID의 사용이 활성화되지 못하고 있지만, 어느정도의 가능성은 가지고 있는 것으로 보여진다. 면접을 보기로 한 회사는, 이런 OpenID를 인증해주는 신뢰할 수 있는 업체로서 성장하는 것을 목표로 하고 있는 것일까? ㅡㅅ-)?
  단순히 회사 업무만으로는 모르겠다는 말이다. 이래놓고 면접보자고 하면, 나는 대체 어떤 컨셉을 가져야하는거야?
허니몬의 IT 이야기

출처 : http://openid.or.kr/9

 내일의 면접을 위해... ㅡㅅ-);; 급 벼락치기 공부중입니다.


(최신 국내 OpenID FAQ 를 커뮤니티 위키에 정리했습니다.)

Q. OpenID 란 뭐죠? 한마디로 간단히 설명해주세요.

하나의 ID, 한번의 로그인으로 여러 서비스를 일일이 가입할 필요없이 사용하게 하는 인증 서비스 표준입니다.
(기술적인 내용은 [위키피디아 OpenID] [ OpenID 스펙 홈페이지]를 참고하십시오.)


Q. URL 처럼 생겼죠?

URL 맞습니다. 다만, 좀더 쓰기 편하게 하기 위해서 최대한 중복되는 부분 (http:// 및 기본 도메인명) 등을 생략한 것 입니다. URL 로 했을 때의 장점중 하나는, 실제 존재하는 페이지 (이를 테면, 나의 블로그페이지나 싸이월드 페이지) ID 로 허용하기 때문에, ID 를 받는 쪽에서 좀더 신뢰할 수 있는 근거가 되고 (없는 페이지는 부적절한 ID 로 처리합니다.), 그 신뢰 수준에 맞는 권한을 허용할 수 있게 됩니다. 물론, 내 블로그가 나의 ID 라면, 보통, 한줄답변에 이름,암호,홈피url 등을 적는 대신, 내 블로그 URL 만 남기면 되고, 한줄 답변을 받는 사이트에서도 차후에 관리할 수 있는 근거가 확보되기 때문에, 스팸 답변등의 부작용에 대처할 수 있습니다. 또한가지 이슈는 기술적인 필요로, 명함에 비유할 수 있겠습니다. 보통 명함에는 회사 전화번호가 적혀 있으므로, 필요시, 그 사람의 신분을 확인하기 위해서 그 회사에 전화를 걸어 볼 수 있습니다. 비슷한 원리로, ID 를 검증하고 싶은 사이트는 그 URL (ID) 의 페이지에서 알아낸 인증 서버에게 인증을 의뢰하게 됩니다.


Q. MS에서 이전에 시도한 Passport Service와 무엇이 다르죠?

Passport 서비스의 기능과 유사합니다. 가장 큰 차이점은 ID 인증을 MS 가 독점했기 때문에, 독점력 행사에 대한 우려때문에 지원 업체가 늘어나지 않았습니다. 또한, 오직 MS 만을 신뢰해야만 하는데 반해서, OpenID 는 인증 업체를 사용자와 서비스가 필요한 신뢰수준에 따라 선택할 수 있기 때문에 독점의 부작용이 없습니다.


Q.개인도매인을 이미 갖고 있는 경우에도 오픈아이디 ID는 별도로 설정해야 하나요?

OpenID 는 개방형 표준 기술 이기때문에 필요하면, 개인 도메인을 받는 서버에서 직접 인증 서버를 운영할 수 도 있습니다. 그 과정을 대신하게 하고, 개인이 직접하는 것 보다는, 전문 업체의 것을 이용하면 ID 에 대한 신뢰도 좀더 확보됩니다. 특정 오픈아이디 서비스를 인증서버로 쓰려면, 개인 도메인 소유 여부와 관계없이 그 오픈아이디 서비스 계정은 만드셔야 합니다. 물론, 지원 서비스들에 방문할때 개인 도메인을 ID 로 사용하되, 인증은 특정 오픈아이디 서비스 의 계정을 통해서 하도록 설정할 수 있습니다. (일반적인 방법은내 URL 을 OpenID 쓰기)


Q.오픈아이디가 스팸메일을 걱정하지 않아도 된다는데 왜 그런거죠?

 email ID 로 사용하는 경우, email 이 많은 사이트에 노출되기 때문에 많이 쓸수록 스팸메일 공격대상이 됩니다. 하지만, OpenID 는 개인정보의 노출여부를 내가 통제할 수 있기 때문에, 중요한 email 을 전혀 노출하지 않을 수 있습니다.


Q.(위의 질문에 이어) 개인정보의 노출여부를 통제할 수 있다는건 뭔가요??

ID 자체는 아무 개인정보를 표현하지 않습니다. 다만, ID 와 관련해서, 방문하는 사이트에서 사용자에게 필요한 정보(e-mail )를 요청할 수 있습니다. 이때 요청된 정보의 전달여부는 전적으로 사용자가 결정합니다.


Q.별도의 ID 대신 메일주소를 받는 서비스들도 많습니다. 이보다 편리한 점이 무엇인가요?

메일주소를 ID 로 쓰는 별도의 계정일 뿐입니다. 따라서 e-mail id 로 쓰는 사이트도, 암호는 따로 받습니다. 따라서, 암호가 여러 사이트에 반복 기재되기 때문에 보안상 취약합니다. 또한, 한군데만 암호를 변경하면 되므로, 암호를 좀더 자주 좀더 변경할 수 있고, 좀더 어려운 암호 한개로 유지 할 수 있으므로, 보안상 더욱 안전합니다. 또한, 매번 가입절차(최소한 암호 정하고, 메일 검증 받기)를 반복합니다. OpenID 는 한 서버에만 암호를 저장하고, 한군데만 가입절차를 밟으면, 이후 지원 서비스의 이용시 가입절차가 거의 없습니다. email은 노출되면 스팸이 많아지지만, 오픈아이디는 스팸 염려가 없습니다.


Q. 오픈아이디(서비스명이 정해지면 수정할 것)로 가입할 수 있는 사이트가 아직 몇 개 없는 것 같은데요?

대부분 해외 사이트들 이지만, 많이 늘어나고 있습니다국내 서비스 주로 웹2.0 신생서비스들입니다.


Q. 한 사람이 오픈아이디를 여러개 가질 수 있나요? 다수의 오픈아이디를 갖게 된다면, 여러개의 아이디와 비밀번호를 갖고 있는 것과 유사한 문제가 발생하지 않을까요?

가질 수 있지만, 제한된 숫자만 가지게 됩니다. 기존의 경우, 내가 가입하는 사이트마다 계정을 추가로 만들어야 하므로, (잠깐이라도) 사용하는 사이트가 늘어날 수록 계속 증가하게 되며, 결국 몇개의 사이트에 어떤 아이디(같은 ID 로 가입이 항상 보장되지도 않습니다.)로 가입했는지도 관리가 안됩니다. OpenID 의 경우, 꼭 필요하다면 용도와 신뢰수준등의 갯수에 비례해서만 증가 할 것입니다. 이를테면, 전자상거래용, 블로그나 미니홈피용, 댓글용 등 용도별로만 하나씩 가지면 되겠죠.


Q. 네이버나 다음, 싸이월드 같이 자신들의 회원을 많이 보유한 포털의 경우 오픈아이디를 빠른 시일안에 지원할까요?

포탈의 성격과 정책에 따라 다릅니다만, 일반적으로 로그인 기반의 포탈은 자신의 로그인 기반을 더욱 강화할 수 있기 때문에, 지원하는 서비스가 많아 질수록 유리할 것입니다. 다만, 각 포탈이 사용자를 자신의 서비스들만 쓰도록 묶어두는 정책을 취하려고 할 경우, 지원을 보류할 수 있습니다. 다음에서는 이미 다음 오픈아이디와 다음 블로그를 통해서 오픈아이디를 제공하고 있습니다.


Q. (위 질문에 대해) "지원하는 서비스가 많아질수록 유리하다?" 무슨 말인지 모르겠어요. 좀더 설명해주세요.

특정 포탈 ID 로 접근 가능한 서비스가 타 업체의 서비스들로 까지 확장 되기 때문에 포탈 ID 에 대한 가치가 높아 질 수 있을 것이라는 판단입니다.


Q. 왜 비밀번호랑 아이디를 따로 입력해야해요? 너무 불편해요!

적절한 비유가 있습니다. 예전에 은행 창구에 가서 중요한 거래를 할때, 비밀번호를 창구직원에게 알려주셨죠. 조금 찜찜했지만, 최근에는 창구직원이 비밀번호 입력 키보드를 제시 하면서 본인이 직접 입력하도록 합니다. 그것이 귀찮으셨나요 ? 같은 원리로 보시면 됩니다.

ID 는 인증이 필요한 서비스에게 알려주는 것이고, 암호는 ID 를 인증해 주는 업체에 알려주는 것입니다. OpenID 에서는 두 업체를 분리하기 때문에, 필연적으로 따로 입력하게 됩니다. 두 업체를 분리해서 얻는 잇점은, 보다 신뢰할 수 있는 업체(인증업체)에만 암호를 알려주면 되기때문에 모든 서비스에 일일히 암호를 알려주는 것보다 보안상 보다 안전합니다. 두번째 이유는 전자상거래등의 경우, 암호 인증은 신뢰할 수 없기 때문에, 인증서등의 강한 인증 수단을 이용하는데, 이경우도 OpenID 인증업체를 인증서 기반의 업체로 바꾸면 그대로 사용할 수 있습니다. , 암호는 여러 인증방법중 하나일 뿐입니다.

보안상 주의 하실 점은, 암호를 넣으실때 반드시 해당 페이지의 URL 이 인증제공 업체의 것인지 확인하셔야 하며, OpenID 에서 ID 와 비밀번호를 함께 받을 수는 없기 때문에, 어떤 사이트에서 그러한 로그인 폼을 제시한다면, 악의적인 의도를 의심하셔야 합니다.

OpenID 는 편리성과 보안성을 분리해서 운영할 수 있게 해줍니다. 따라서, 보안수준이 높은 인증 서비스로 인증을 하면서도, 서비스의 편리성을 위해서 서비스 별로 자동로그인 등을 제공하면 됩니다. 기존의 방식은, 편리성과 안전성을 한 업체에서 제공하기 때문에, 둘 중 하나를 포기해야 하는 경우가 많습니다.

이부분에 대해서 좋은 포스트를 하나 소개합니다.


Q. 오픈아이디를 지원하는 사이트의 경우, 제 오픈아이디로 로그인하면 기존의 서비스(블로그처럼 내 공간이 있는)를 불편없이 사용할 수 있게 되나요? 기존 서비스 내에서도 새로운 인증 절차를 거쳐야 하나요?

서비스별 정책에 따라 달라집니다. 다만, 블로그 처럼 내가 로그인해서 체류하는 시간이 길고, 그 블로그 시스템/서비스를 비교적 신뢰하고 있다면, 그 블로그 URL ID 로 사용하고 인증기능을 제공하는 경우가 가장 편할 수 있습니다. 초기 단계에는 기존 서비스에서 확실히 불편했던 부분, 이를 테면, 방문객에게 간단히 코멘트를 남기도록 하고 싶지만, 스팸때문에 가입을 시킬 수 밖에 없었던 경우에 OpenID 인증으로 교체한다면, 방문객은 추가 가입없이 코멘트를 남길 수 있고, 사이트는 가입절차를 강요하지 않으므로 좀 더 많은 방문객의 참여를 이끌어 낼 수 있습니다.


Q. 사이트에 오픈아이디로 로그인하는 것과 가입한 후 회원아이디로 로그인 하는 것에 차이가 있나요? 혹시 오픈아이디로 로그인했기 때문에 차별을 받지는 않나요?

일반적인 사이트를 말씀하시는 것이라면, 역시 각 사이트의 정책에 따라 다릅니다. 정확히 말씀드리면, OpenID 와 사이트 자체 ID 와의 차별이라기 보다는, 일반적으로는 어떤 OpenID 제공 서비스의 ID 냐에 따라서 ID 의 신용도가 영향을 받습니다. , 한국신용평가가 인증하는 ID 와 개인이 인증하는 ID 의 신뢰도가 같을 수는 없을 것이고, 그에 따라 사이트에서도 대접이 달라 질 수 밖에 없겠죠. 재미있는 것은, 사이트에서 인증서등의 높은 보안 수준의 ID 를 제공할 수 없을 경우, 자체 ID 보다 외부의 높은 수준의 인증기관이 제공하는 ID 를 더 신뢰할 것입니다.


Q. "지금 이 순간에도 구글과 네이버, 다음은 이메일과 아이디를 통해, 당신을 훔쳐보고 있다." (어떤 블로그에서) OpenID는 이 문제를 더 심각하게 만들지는 않나?

e-mail 이나 ID 의 기술적인 문제는 아닙니다. 원칙적으로는 웹상에 어떤 기록을 남길때, 저자의 ID (e-mail 포함한) 도 본인의 동의를 얻어서 노출되어야 합니다. (물론, 그것도 법적으로 보장 되어야 합니다.) 다만 대개 검색엔진에 노출되는 경우는, 본인이 사이트에서 e-mail 또는 ID 노출을 (암묵적으로) 승인 했거나, 또는 신뢰할 수 없는 사이트에 ID 를 알려준 경우이다. 이것은 마치 자신의 실명을 노출시키면서 사회적인 행위를 할 경우, 그를 통한 평판이 쌓이는 것이나 마찬가지이다. 좋은 평판이 쌓일 수도 있고, 나쁜 평판이 쌓일 수도 있다. 다만, 여러개의 ID 를 적절히 사용하면 되며, 결국, ID 로 행한 행동으로 인한 결과는 그 ID 의 가치로 되돌아오는 것이므로, 오히려 인터넷 자체 정화장치로 작동할 것이다.


Q. 어차피 사이트마다 똑같은 ID, password를 쓰고 있어요. 이 서비스에 따로 가입할 필요가 있나요?

새로운 사이트 마다, 가입절차는 계속 반복되어야 합니다. 이 서비스는 반복되는 가입절차가 필요 없습니다. 또한, 같은 ID/password 를 다수의 사이트에 알려주는 것은, 노출의 가능성을 점점 증가 시키는 것입니다. 그래서, 결국, 가입하는 사이트 수와 함께 보안상 점점 위험해 지거나, 몇몇 신뢰할 수 있는 서비스만 사용하므로서, 사용할 수 있는 서비스 수를 제한하거나 둘중 한가지를 선택해 야만 합니다. 새로운 방식에서는 가장 신뢰할 수 있는 한 사이트에 만 알려주고, 그 사이트를 통해서만 인증을 하되, 사용하는 사이트의 수가 증가하더라도 암호를 추가 노출하지 않기 때문에 보다 많은 서비스를 안전하게 접근할 수 있습니다.


Q. OpenID 서비스가 어떠한 이유로 중지되었을때(사고 혹은 임의적중지) - 본질적으로 이는 하나의 서비스 이므로 - 너무 많은 걸 잃을 것 같은데요? 이 서비스가 최소한 제가 죽을때까지 유지될 것이라는 보장이 없는 상태(감시자는 누가 감시하지와 비슷한 문제일수도...)에서 위험하지 않을까요?

다른 모든 서비스와 마찬가지로 서비스 제공업체의 신뢰성과 직접 관련된 문제입니다. 다만, OpenID 기능상의 차이점은 ID 는 그대로 유지한채 인증 제공업체를 교체할 수 있습니다. 이를 테면, 내가 직접 보유하고 있는 개인도메인을 ID 로 사용하면서 인증업체는 A 사를 이용하다가, A 사가 중지된 경우 B 사의 것으로 교체할 수 있습니다.


Q. 나의 OpenID 서버가 해킹되면 이 서비스로 가입한 사이트들 전부 뚫려버리는 거 아닌가요?

가능합니다. 하지만, 이것은 포탈 ID 가 노출되면, 그 포탈에서 가입한 서비스스 전부가 접근되는 것과 같습니다. 결국, 이 방식 자체의 문제라기 보다는, 인증 서버를 제공하는 업체의 신뢰도 문제입니다. 이런 질문을 하고 싶습니다. 현재, 공인 인증서를 발급하는 금융결제원 같은 기관이 해킹되면 어떻하죠 ? 결국 여러분이 선택한 인증 서비스의 신뢰수준에 맞는 서비스에만 사용하실 것을 권장합니다.


Q. 우리 사이트에 OpenID를 적용하면 뭐가 좋아지죠?

  • 사이트 이용자 수가 늘어납니다 : 2005년 일본이 시행한 비자 면제기간 동안 일본 여행객수가 20% 증가했습니다.
  • 이용자의 신뢰도를 쉽게 확인할 수 있으므로 신뢰할 수 있는 이용자의 사이트 이용을 증가시킬 수 있습니다.
  • 이렇게 잠재회원 수가 늘어남에 따라 가입 회원 수도 따라서 늘어납니다.
  • (이용자 승인 하에) 필요한 이용자 정보를 제공받아 보다 정확한 맞춤 정보를 제공할 수 있습니다.
  • (이용자 승인 하에) 필요할 때에 가장 최신의 이용자 정보를 받을 수 있으므로, 이용자 정보의 저장/관리 비용이 절감됩니다.

사용자가 동기부여되지 않은 채 입력한 개인정보는 아무 자산이 안되며, 가입 강제는 잠재적인 고객을 포기하는 일일 뿐입니다

1 ··· 51 52 53 54 55 56 57 ··· 80
블로그 이미지

Email : ihoneymon@gmail.com 안녕하세요, 꿀괴물 입니다. ^^ 멋진 비행을 준비 하는 블로그 입니다. 만능형 인간이 되어 많은 이들에게 인정받고, 즐겁고 행복하게 살기를 간절히 원합니다!! 달콤살벌한 꿀괴물의 좌충우돌 파란만장한 여정을 지켜봐주세요!! ^^

허니몬