| 방법 | 플랫폼 중립성 | 브라우저 중립성 | 사용성 | 즉시 적용 가능 | 서버측 수정 | 비고 |
|---|---|---|---|---|---|---|
| Java signed applet | High (일부분 플랫폼 의존성 있을 수 있음) | High | 실행 시 애플릿 로딩 시간 문제 해결 필요 | Y(?) | minimal | Initech이 개발 완료(?) 이미 상용화되어 있음 |
| Flash (FLEX) + Java signed applet | Medium (일부분 플랫폼 의존성 있을 수 있음. 플래시 플레이어 필요) | High | 애플릿 로딩 시간 문제 | Y | minimal | Initech이 개발 완료 및 시연(2005) |
| xpcom(C++) | Medium(플랫폼 별 재 컴파일 필요) | Low(gecko 계열 브라우저) | High | Y | minimal | Softforum, Initech(?) : 현재 개발 버전은 배포/설치 방법 개선 필요. 우체국에서 2005년 사용, 농협 사용 중(?), 기업 은행/KIPA 현재 사용 중 |
| xpcom(Python, Javascript) | High | Low(gecko 계열 브라우저) | High | N | minimal | 성능? |
| Flash | Medium (일부분 플랫폼 의존성 있을 수 있음. 플래시 플레이어 필요) | High | N | minimal | 아직 개발된 적 없음 | |
| 구 Mozilla/Netscape plugin | Medium(플랫폼 별 재 컴파일 필요) | Medium (except MS IE) | High | N | minimal | 90년대 말 실제 사용( 흔적) |
| 신 Mozilla plugin | Medium(플랫폼 별 재 컴파일 필요) | Medium (Gecko, Opera, Safari, Konqueror) | High | N | minimal | |
| https + signText for Firefox and CAPICOM for MS IE | High | Low(gecko 계열 브라우저 + MS IE) | plain text only | N | rather extensive | Spain에서 사용 중. SEED 사용 불가, 3DES 사용, OpenCA에서도 사용 |
플래시 플레이어의 배포는 몇몇 오픈 소스 플레이이 개발 노력에도 불구하고 실질적으로 Adobe에 달려 있음. 현재, 최신 플래시 플레이어 9판은 오직 Windows와 Mac OS X용으로만 배포되고 있음. 리눅스용 9판은 2007년 초에나 나올 예정이고, 다른 소수 OS나 소수 아키텍처용으로는 아예 나오지 않을 가능성도 있음. 따라서, 플래시 기반 애플릿의 플랫폼 독립성을 극대화하려면 널리 쓰이는 플래시 플레이어 버전에서 돌아가도록 개발해야 함. 또, 그렇다고 해도 플래시 플레이어가 없는 플랫폼에서는 사용 불가
Java signed applet에서 SEED 처리 속도 향상과 스마트 카드 지원을 위해서 native method를 사용하면 (사용이 불가피하다면) 플랫폼 의존성이 생길 수 있음. 이 문제를 피할 수 있는 한 가지 방안은 native method를 쓰지 않는 플랫폼 중립적인 공통 모듈과 native method를 쓰는 플랫폼 의존적인 모듈 두 개로 나누는 것임. '이른바' 주요 플랫폼(Windows 인텔 32/64bit, Linux 인텔 32/64bit, Mac OS X PPC/Intel)에는 플랫폼 의존적인 모듈을 배포하고, 다른 플랫폼에는 공통 모듈만을 배포할 수 있음. 공통 모듈에서는 플랫폼 의존 모듈이 존재하면 그를 써서 SEED를 처리하고, 없을 경우에는 성능이 상대적으로 뒤떨어지는 공통 모듈에 포함된 SEED 처리 루틴을 사용하도록 할 수 있을 것임. 스마트 카드의 경우에는 플랫폼 의존 모듈이 없을 경우에 그 사용을 불가능하게 하면 될 것임. 단, 앞서 언급한 바와 같이 Java에서 native method를 쓰지 않고도 스마트 카드 사용에 문제가 없다면 이 문제는 발생하지 않음.
위의 표에서 정리한 대로 xpcom 방식은 gecko 계열 브라우저에서만 동작한다는 문제가 있음. netscape plugin 방식은 gecko 계열 브라우저 이외에도 Opera, Safari, Konqueror 등을 지원한다는 상대적 장점이 있음. 하지만, xpcom을 이용한 모듈과 netscape plugin 방식은 공히 각 플랫폼 별로 재컴파일해 주어야 하므로, 플랫폼 중립성에 문제가 있음. 개발자 입장에서는 단순하게 컴파일을 다시 하는 일일 수도 있지만 (따로 시험이 필요 없다고 한다면), 배포자(예를 들어, 은행)는 수많은 OS와 프로세서 조합 (여러 'small device'들을 포함한) 각각을 위한 모듈을 배포해 주지 않을 것임은 자명함. 따라서, 이 방법은 그다지 바람직하지 못 함.