일반 센서 API

1. 소개

애플리케이션 개발에서 센서 데이터는 지리 위치, 걸음 수 카운트, 헤드 트래킹과 같은 새로운 사용 사례를 가능하게 하기 위해 점점 더 많이 활용되고 있습니다. 특히 모바일 장치에서는 새로운 센서가 지속적으로 추가되고 있어 이러한 경향이 두드러집니다.

센서 데이터를 웹에 노출하는 것은 그동안 매우 느리고 임시방편적인 방식이었습니다. 이미 웹에 노출된 센서는 소수에 불과합니다. 노출되더라도, 그 활용 가능성을 제한하는 방식(예: 너무 상위 수준의 추상화만을 노출하거나 성능이 충분하지 않은 등)으로 제공되는 경우가 많습니다. 각 센서마다 API가 크게 달라, 웹 애플리케이션 개발자의 인지적 부담이 증가하고 개발이 느려집니다.

Generic Sensor API의 목표는 센서 API 전반의 일관성을 높이고, 고성능 저수준 API를 통해 고급 사용 사례를 지원하며, 명세와 구현 과정을 단순화함으로써 새로운 센서를 웹에 더 빠르게 노출할 수 있도록 하는 것입니다.

Generic Sensor API를 기반으로 하는 구체적인 센서 목록, 적용 가능한 사용 사례, 코드 예시는 [GENERIC-SENSOR-USECASES]와 [MOTION-SENSORS] 해설 문서에서 확인할 수 있습니다.

2. 범위

이 섹션은 비규범적입니다.

이 명세의 범위는 현재 디바이스 센서의 데이터를 웹에 노출하기 위한 기본 요소(primitives) 정의로 한정됩니다.

원격 센서나 개인 영역 네트워크(예: Bluetooth)에 연결된 센서를 노출하는 것은 본 명세의 범위를 벗어납니다. 이 분야의 작업이 성숙해질 경우, 공통적인 저수준의 기본 요소가 발견된다면, 이 명세 역시 그에 따라 업데이트될 수 있습니다. 그러나 이는 구현에 거의 또는 전혀 영향을 주지 않을 것입니다.

본 명세는 현재 센서 탐색 API(sensor discovery API)는 제공하지 않습니다. 이는 현재 사용자 에이전트에서 지원하는 센서 수가 한정적이기 때문에 별도의 API 도입이 타당하지 않기 때문입니다. § 3 하드웨어 기능 탐지 참고와 같이 기능 감지를 이용하는 것으로 현재로서는 충분합니다. 차기 버전에서 이러한 API가 정의될 수 있으며, 현재의 API 또한 이를 염두에 두고 설계되었습니다.

3. 하드웨어 기능 탐지에 대한 참고

이 섹션은 비규범적입니다.

기능 감지는 확립된 웹 개발 모범 사례입니다. 관련 자료 역시 온·오프라인에 풍부하게 존재하며, 이 섹션의 목적은 기능 감지 자체를 논의하는 것이 아니라, 하드웨어 의존 기능 감지 맥락에 해당 개념을 적용하는 데 있습니다.

아래는 기능 감지 예시입니다:

이 간단한 예시는 사용자 에이전트가 특정 센서 유형에 대한 인터페이스를 노출하는지 확인하는 방법을 보여줍니다. 오류를 견고하게 처리하는 방법은 이 예시를 참고하세요.

if (typeof Gyroscope === "function") {
    // run in circles...
}

if ("ProximitySensor" in window) {
    // watch out!
}

if (window.AmbientLightSensor) {
    // go dark...
}

// etc.

이러한 방법은 API의 존재 및 일부 특성에 대한 정보는 알 수 있지만, 실제로 해당 API가 하드웨어 센서와 연동되어 있는지, 그 센서가 잘 동작하는지, 여전히 연결되어 있는지, 또는 사용자가 접근을 허용할 것인지 등은 알 수 없습니다. 마지막의 경우, Permissions API [PERMISSIONS]를 통해 확인할 수 있습니다.

이상적인 시나리오라면, 기반 하드웨어의 상태 정보가 미리 제공될 수 있겠지만, 실제로는 두 가지 문제가 있습니다. 첫째, 하드웨어에서 이러한 정보를 얻는 데는 성능 저하와 배터리 소모가 발생하며, 이는 중요한 실행 경로에 영향을 줄 수 있습니다. 둘째, 하드웨어의 상태는 시간이 지나며 변화할 수 있습니다. 사용자가 권한을 취소하거나, 센서와의 연결이 끊기거나, 운영체제가 특정 배터리 상태 이하에서 센서 사용을 제한할 수 있습니다.

따라서 효과적인 전략은, 원하는 센서에 대한 API의 존재 유무를 확인하는 기능 감지와, 다음을 포함하는 방어적 프로그래밍을 결합하는 것입니다:

Sensor 객체를 인스턴스화할 때 발생하는 오류를 확인
그 객체에서 발생하는 오류 이벤트를 청취
위 모든 경우를 원활히 처리하여 센서를 사용할 수 있을 경우에는 사용자 경험이 향상되고, 만약 사용할 수 없는 경우에도 사용자 경험이 저하되지 않도록 처리

다음 코드는 가속도계 센서를 견고하게 생성하는 방법을 보여줍니다. 웹 애플리케이션은 상황에 맞게 알림 표시, 다른 센서 선택, 다른 API로 대체 등 다양한 오류 처리 옵션을 선택할 수 있습니다.

let accelerometer = null;
try {
    accelerometer = new Accelerometer({ frequency: 10 });
    accelerometer.addEventListener('error', event => {
        // Handle runtime errors.
        if (event.error.name === 'NotAllowedError'){
            console.log('Permission to access sensor was denied.');
        } else if (event.error.name === 'NotReadableError' ){
            console.log('Cannot connect to the sensor.');
        }
    });
    accelerometer.addEventListener('reading', () => reloadOnShake(accelerometer));
    accelerometer.start();
} catch (error) {
    // Handle construction errors.
    if (error.name === 'SecurityError'){
        console.log('Sensor construction was blocked by the Permissions Policy.');
    } else if (error.name === 'ReferenceError'){
        console.log('Sensor is not supported by the User Agent.');
    } else {
        throw error;
    }
}

4. 보안 및 개인정보 보호 고려사항

사용자가 인지한 위협을 어떻게 전달할지는 구현자에게 맡깁니다. 그러나 완화책 구현은 필수입니다.

센서 측정값은 민감한 데이터이며, 악의적인 웹 페이지로부터 다양한 공격의 대상이 될 수 있습니다. 완화 전략을 논의하기 전에, 센서의 주요 개인정보 및 보안 위협 유형을 간략히 나열합니다. [MOBILESENSORS]에서는 주요 위협을 위치 추적, 도청, 키 입력 감시, 기기 핑거프린팅, 사용자 식별로 분류하고 있으며, 이 분류가 본 명세에도 적합합니다.

센서가 상호 결합되거나, 다른 기능과 함께 쓰이거나, 시간이 흐르면서 함께 활용되는 경우, 특히 데이터 상관관계 및 핑거프린팅을 통한 사용자 식별 위험이 커질 수 있습니다. 이 JavaScript API를 사용하는 웹 개발자는 이러한 정보가 다른 정보와 어떻게 결합될 수 있는지, 개인정보 위험이 무엇인지 고려해야 합니다. 장기간 데이터가 수집될 때의 잠재적 위험도 고려해야 합니다.

센서 측정값의 미세한 차이와 이벤트 발생 속도는 사용자 식별을 위한 핑거프린팅 가능성을 제공합니다. 사용자 에이전트는 웹 애플리케이션 개발자에게 허용되는 이벤트 빈도를 제한하여 위험을 줄일 수 있습니다.

센서 판독값의 정확도를 최소화하는 것은 일반적으로 핑거프린팅 위험을 감소시킵니다. 사용자 에이전트는 필요 이상으로 상세한 센서 데이터를 제공하지 않아야 하며, 각 센서 유형별로 개별적인 평가가 필요합니다.

동일 API를 사용하는 JavaScript 코드가 동일 기기의 여러 창(context)에서 동시에 이용되는 경우, 해당 코드가 두 컨텍스트에 걸쳐 사용자를 연결할 수 있으며, 이는 의도치 않은 추적 메커니즘을 초래할 수 있습니다.

사용자 에이전트는 센서가 사용 중일 때 사용자가 인지할 수 있도록 표시하거나, 해당 센서를 비활성화할 기회를 제공하는 것이 바람직합니다. 또한 과거 및 현재의 센서 사용 패턴 확인을 허용할 수도 있습니다.

센서를 활용하는 웹 개발자는 자신의 애플리케이션이 개인정보보호에 미치는 영향을 전반적으로 평가해야 합니다.

기기에서 동작 중인 모든 센서를 감지할 수 있다면, 그 자체가 식별자로 활용되어 핑거프린팅에 악용될 수 있습니다.

특정 센서 조합을 통해 장치 간 외부(band 외) 통신 채널이 형성될 위험도 있습니다.

센서는 잠재적으로 여러 장치 간 사용자 연계 및 추적에 활용될 수 있습니다.

4.1. 개인정보 및 보안 위협 유형

이 섹션은 비규범적입니다.

4.1.1. 위치 추적

이 위협 유형에서 공격자는 센서 측정값만 사용해 GPS나 기타 위치 센서 없이도 디바이스의 위치를 파악할 수 있습니다. 예를 들어, 가속도계 데이터로 통계 모델을 통해 이동 궤적을 추정 한 뒤, 맵 매칭 알고리즘으로 예측 위치(반경 200m 이내)를 얻는 경우가 이에 해당합니다 [MOBILESENSORS].

4.1.2. 도청

자이로스코프 측정값으로 음성을 복원하는 것은 도청 공격의 예입니다. [GYROSPEECHRECOGNITION] 참고.

4.1.3. 키 입력 감시

센서 측정값으로 많은 사용자 입력을 추정할 수 있는데, 이는 모션 센서를 이용한 사용자 PIN, 비밀번호, 잠금 패턴(터치 클릭, 스크롤, 확대/축소 포함) 공격 사례를 포함합니다. 보통 머신러닝 알고리즘이 이러한 사용자 정보를 추출하는 데 활용됩니다. [STEALINGPINSVIASENSORS] 참고.

4.1.4. 기기 핑거프린팅

센서가 제공하는 정보로 해당 센서를 사용하는 기기를 고유하게 식별할 수 있습니다. 모든 센서 모델은 제조상의 미세한 차이를 갖고 있고, 이러한 차이가 각 모델의 고유성을 만듭니다. 이런 제조상 차이와 결함이 기기 핑거프린팅에 쓰일 수 있습니다 [ACCELPRINT] [MOBILESENSORS].

4.1.5. 사용자 식별

센서 측정값은 예를 들어 스마트폰 또는 웨어러블 장치의 모션 센서 데이터로 개별 보행 패턴을 추론하여 사용자를 식별하는 데 사용할 수 있습니다.

4.2. 완화 전략

이 섹션은 비규범적입니다.

이 섹션에서는 본 명세서의 규범 섹션에 명시된 일부 완화 전략을 상위 수준에서 소개합니다.

4.2.1. 보안 컨텍스트

센서 측정값은 Secure Contexts 명세 [POWERFUL-FEATURES]에서 네트워크 공격자에게 고가치 목표로 지정되었습니다. 따라서 본 명세서 또는 확장 명세에서 정의된 모든 인터페이스는 보안 컨텍스트에서만 이용 가능합니다.

4.2.2. 권한 정책

사용자가 익숙하지 않은 컨텍스트와 센서 판독값을 공유하는 것에 대한 프라이버시 위험을 방지하기 위해, 센서 판독값은 다음 문서가 사용이 허용된 정책 제어 기능을 해당 센서 타입에 대해 사용할 수 있을 경우에만 제공됩니다. 더 자세한 내용은 [PERMISSIONS-POLICY]를 참고하세요.

4.2.3. 포커스된 영역

센서 판독값은 활성 문서에 대해서만, 해당 문서의 포커스 및 출처 확인이 true를 반환할 경우 제공됩니다.

이 방식은 항해 가능한(navigable) 요소에 초점이 맞춰지고 포커스를 획득한 요소가 포함될 때 스키밍(정보 유출) 공격의 위험을 완화하기 위한 것입니다. 예를 들어, 사용자가 iframe 내에서 타사 결제 서비스를 사용하여 게임 내 구매를 할 때 등이 해당됩니다.

4.2.4. 가시 상태

센서 판독값은 활성 문서의 가시 상태가 "visible"일 때만 제공됩니다.

4.2.5. 권한 API

센서 판독값에 대한 접근은 Permissions API [PERMISSIONS]로 제어됩니다.

4.3. 개별 사용 사례별 완화 전략

각 센서 유형은 해당 센서가 가능하게 하는 사용 사례와 위협 프로파일을 고려해 개별적으로 평가되어야 합니다. 아래에 소개하는 완화 전략 중 일부는 특정 센서에서 효과적이지만, 일부 사용 사례에는 방해되거나, 완전히 사용이 불가능할 수도 있습니다.

참고: 이러한 완화 전략은 항상 또는 일시적으로 적용될 수 있습니다. 예를 들어 사용자가 특정 작업을 수행할 때, 위협 수준을 높이는 다른 API가 사용 중일 때 등 상황에 따라 다를 수 있습니다.

4.3.1. 최대 샘플링 빈도 제한

사용자 에이전트 및 확장 명세는 센서 유형의 최대 샘플링 빈도를 정의하여 특정 위협을 완화할 수 있습니다.

상한값 설정은 센서 유형, 보호하고자 하는 위협 유형, 공격자의 예상 리소스 등에 따라 달라집니다.

최대 샘플링 빈도 제한은 저지연 또는 고밀도 데이터를 필요로 하는 사용 사례에는 제약이 됩니다.

4.3.2. 센서 완전 중지

이는 마지막 수단이지만, 일시적으로 적용하면 매우 효과적일 수 있습니다. 예를 들어 사용자가 다른 출처([rfc6454])에서 인증 정보를 입력할 때나 별도의 애플리케이션에서 입력 중이라면, 패스워드 스키밍 시도를 차단할 목적으로 쓸 수 있습니다.

4.3.3. 전달되는 측정값 수 제한

최대 샘플링 빈도 제한의 대안으로, 센서 측정값이 웹 개발자에게 전달되는 횟수를 제한할 수 있습니다. 샘플링 빈도와 관계없이, 저지연을 요구하는 사용 사례에서는 샘플링 빈도를 높이면서도 데이터 제공량은 제한할 수 있게 됩니다.

중간 측정값을 버리면 특정 필터에 의존하는 사용 사례 등은 불가능하거나 제약이 있습니다.

4.3.4. 정확도 낮추기

센서 측정값이나 측정값 타임스탬프의 정확도를 감소시키는 것도 위협 완화에 도움이 될 수 있습니다. 사용자 에이전트는 필요 이상으로 정밀한 센서 데이터를 제공하지 않아야 합니다.

구체적 센서 구현에서는 임계값 검증 알고리즘을 정의하여 최근 측정값과 차이가 적은 새로운 측정값은 버릴 수 있습니다.

구체적 센서 구현에서는 측정값 양자화 알고리즘을 정의하여, 디바이스 센서에서 받은 센서 측정값의 정밀도를 낮출 수도 있습니다.

참고: 이 두 가지 전략은 서로 보완관계에 있는 경우가 많습니다. 임계값 검증만 실행하는 구현은 너무 정밀한 측정값이 노출될 수 있고, 오직 반올림만 하는 경우에는 원시 측정값이 여러 값으로 라운딩될 때 공격자에게 더 정밀한 정보를 제공할 수 있습니다.

참고: 센서 측정값의 가공 연산이나 타임스탬프 간 차이 등을 이용하면 부정확도가 추가로 증가할 수 있으므로, 이 전략이 일부 사용 사례에는 영향을 줄 수 있습니다.

참고: 센서 측정값에 무작위 바이어스를 도입하는 방법은 유사한 효과를 보이지만, 추가된 노이즈를 쉽게 필터링할 수 있으므로 실제로는 권장되지 않습니다.

4.3.5. API 사용 현황 사용자 알림 유지

사용자 에이전트는 현재 또는 과거 API 사용에 대해 사용자가 알 수 있도록 처리할 수 있습니다.

참고: 이는 실제 센서 측정값 로그를 남긴다는 의미가 아니며, 로그 자체가 별도의 문제를 발생시킬 수 있습니다.

5. 개념

5.1. 센서

디바이스 센서라는 용어는 디바이스의 기반이 되는 실제 물리적 센서 인스턴스를 의미합니다.

디바이스 센서는 물리적 양을 측정하고, 환경에 대한 정보를 제공하는 센서 판독값을 제공합니다.

각 센서 판독값은 디바이스 센서가 시간 t_n에 측정한 물리적 양의 값들로 구성되며, 이 때의 시간을 판독값 타임스탬프라 부릅니다.

디바이스 센서가 공간적 측정(예: 가속도, 각속도)을 하는 경우, 반드시 로컬 좌표계에서 측정되어야 하며, 이는 디바이스 센서의 센서 판독값에 대한 기준 좌표계를 의미합니다. 이처럼 센서 판독값을 제공하는 디바이스 센서를 공간 센서라 부릅니다.

공간 센서는 측정 가능한 직교 축의 수에 따라 단일축, 이중축 또는 삼중축일 수 있습니다.

스칼라 물리량(예: 온도)은 로컬 좌표계가 필요하지 않습니다.

모바일 기기에서 일반적으로 쓰이는 로컬 좌표계는 카르테시안 좌표계로, 디바이스의 화면을 기준으로 정의됩니다. X, Y축은 화면과 나란하며, Z축은 화면 표면에 수직입니다.

플랫폼 센서라는 용어는 사용자 에이전트가 하나 이상의 디바이스 센서로부터 특정 센서 유형의 센서 판독값을 가져오기 위해 상호작용하는 플랫폼 인터페이스를 가리킵니다.

플랫폼 센서는 기반 플랫폼(예: 네이티브 센서 프레임워크)에서 정의될 수도 있고, 사용자 에이전트가 디바이스 센서에 직접 접근 가능한 경우 사용자 에이전트가 정의할 수도 있습니다.

구현 관점에서 플랫폼 센서는 해당 디바이스 센서의 소프트웨어 프록시로 취급할 수 있습니다. 기반 플랫폼이 지원한다면 동일 디바이스 센서와 동시에 상호작용하는 여러 개의 플랫폼 센서가 존재할 수 있습니다.

간단한 경우, 플랫폼 센서는 하나의 디바이스 센서에 대응하지만, 만약 소프트웨어적으로 센서 퓨전을 통해 합성된 센서 판독값을 제공한다면, 플랫폼 센서는 해당 센서 퓨전에 관여한 여러 디바이스 센서 집합에 해당합니다.

센서 판독값과 실제로 측정되는 물리량 간 불일치는 보정을 통해 수정할 수 있으며, 이는 제조 단계에서 이뤄질 수 있습니다. 일부 센서는 미확인 오차를 보상하기 위해 동적 보정이 필요할 수 있습니다.

참고: 센서 퓨전으로 생성된 플랫폼 센서는 가상 또는 합성 센서라 불리기도 합니다. 그러나 본 명세에서는 이 둘을 실질적으로 구분하지 않습니다.

5.2. 센서 유형

다양한 센서 타입은 온도, 기압, 심박수, 혹은 조도와 같은 다양한 물리적 수량을 측정합니다.

이 명세에서는 고수준과 저수준 센서 타입을 구분합니다.

구현 방식에 의해 특징지어지는 센서 타입은 저수준 센서라고 불립니다. 예를 들어, 자이로스코프는 저수준 센서 타입입니다.

구현 방식과 관계없이 측정값의 이름을 가진 센서는 고수준 센서라고 합니다. 예를 들어, 위치 센서는 사용자의 위치 정보를 제공하지만 이 데이터가 어떻게 수집되는지는 의도적으로 불투명하게 처리됩니다 (데이터는 GPS 칩, 셀 방식 삼각측량, 와이파이 네트워크 등 여러 원천 또는 그 조합으로 얻을 수 있음) 그리고 구체적이고 구현 특화된 여러 휴리스틱에 따라 달라집니다. 고수준 센서는 일반적으로 저수준 센서에 알고리즘을 적용하거나—예를 들어, 만보계는 자이로스코프 출력만으로 만들 수 있음—센서 퓨전을 이용하여 만들어집니다.

즉, 고수준과 저수준 센서 타입의 구분은 다소 임의적이며 그 경계가 흐릿한 경우가 많습니다. 예를 들어, 대기압을 측정하는 기압계는 대부분의 경우 저수준으로 간주되지만 실제로는 압전 센서와 온도 센서의 센서 퓨전의 산물입니다. 구성 센서를 노출하는 것은 실용적이지 않으며; 압전 센서의 온도 같은 정보는 실질적으로 중요하지 않습니다. 고도기를 예로 들면, 압력 기반 고도계는 같은 분류에 속하지만, 구체적이지 않은 고도계—기압계 혹은 GPS 신호를 통해 데이터를 얻는—는 명백히 고수준 센서 타입으로 분류될 것입니다.

구분이 다소 모호하므로, 이 명세의 확장(자세한 내용은 § 10 확장성 참고)은 대상 센서 타입에 대한 고수준과 저수준 센서의 도메인별 정의를 제공할 것을 권장합니다.

서로 다른 센서 타입에서의 측정값은 센서 퓨전이라는 과정을 통해 결합될 수 있습니다. 이 과정은 더 높은 수준 혹은 더 정확한 데이터를 제공하지만(종종 지연 시간이 증가함) 예를 들어, 삼축 자력계의 측정값은 가속도계의 측정값과 결합되어 올바른 방향을 제공합니다.

스마트 센서와 센서 허브에는 내장 컴퓨팅 리소스가 포함되어 있어 하드웨어 차원에서 보정 및 센서 퓨전을 수행할 수 있으며, 이를 통해 CPU 리소스를 절감하고 배터리 소모를 낮출 수 있습니다.

센서 퓨전은 하드웨어에서 수행할 수 없거나, 애플리케이션 특화된 퓨전 알고리즘이 필요할 경우 소프트웨어에서도 수행할 수 있습니다.

5.3. 기본 센서

Generic Sensor API는 가장 일반적인 사용 사례를 쉽게 구현하도록 설계되었으면서 복잡한 요구도 지원합니다.

현재 대부분의 디바이스는 동일 센서 유형의 디바이스 센서가 여러 개 존재하지 않습니다. 유사 디바이스 센서의 집합이 필요한 사례는 드물고, 대개 2-in-1 노트북의 가속도계처럼 특정 센서 유형에 한정됩니다.

따라서 API는 각 유형별로 디바이스의 기본(종종 유일한) 센서와 쉽게 상호작용할 수 있게 해주며, 대응되는 Sensor 서브클래스 인스턴스를 생성하면 곧바로 사용할 수 있습니다.

주어진 유형의 특정 센서를 명확히 지정하지 않은 경우 기본 센서는 사용자 에이전트가 선택합니다.

만약 기반 플랫폼이 기본 센서를 찾는 기능을 제공한다면, 사용자 에이전트는 플랫폼이 제공하는 센서를 사용해야 하며, 그렇지 않다면 디바이스 내 센서 중 어느 것이 기본 센서인지 자체적으로 결정할 수 있습니다.

기본 가속도계의 변경 감지:

let sensor = new Accelerometer({ frequency: 30 });

sensor.onreading = () => { ... }
sensor.start();

참고: 본 명세의 확장에서는 기본 센서의 정의가 의미 없을 경우 이를 정의하지 않을 수 있습니다. 예를 들어 위치 센서 유형에 대해 명시적으로 기본 센서를 정의하는 것은 무의미합니다. 왜냐하면 해당 인터페이스의 구현은 여러 백엔드를 사용할 수 있기 때문입니다.

동일 유형의 디바이스 센서가 여러 개 존재할 수 있는 경우, 명세 확장에서 각 센서를 고유하게 식별하는 방법을 정의해야 합니다.

예: 좌후면 타이어 압력 확인:

var sensor = new DirectTirePressureSensor({ position: "rear", side: "left" });
sensor.onreading = _ => console.log(sensor.pressure);
sensor.start();

5.4. 샘플링 빈도 및 보고 빈도

본 명세에서 플랫폼 센서의 샘플링 빈도란 하위 디바이스 센서로부터 센서 판독값을 얻는 빈도를 의미합니다. 이런 판독값을 얻는 방식은 구현 정의적입니다.

플랫폼 센서의 샘플링 빈도는 디바이스 센서의 실제 샘플링 속도와 반드시 일치하지 않으며, 본 명세에서 이는 불투명(opque)합니다.

참고: 센서 판독값용 시스템 레벨 API 및 하드웨어 인터페이스는 폴링 기반일 수도 있고 이벤트 기반일 수도 있습니다. 폴링 기반 디바이스 센서의 경우, 플랫폼 센서의 샘플링 빈도는 시스템 또는 하드웨어에서 새로운 값을 요청하는 속도입니다. 이벤트 기반 디바이스 센서라면, 플랫폼 센서가 요청한 샘플링 빈도를 시스템/하드웨어에 전달하며, 해당 빈도 이하로 이벤트가 발생합니다. 판독값이 변하지 않으면 이벤트는 발생하지 않을 수 있습니다.

디바이스 센서는 플랫폼 센서에서 받아들일 수 있는 샘플링 빈도 경계를 최소 샘플링 빈도와 최대 샘플링 빈도 형태로 제공할 수 있습니다. 플랫폼 센서의 샘플링 빈도는 디바이스 센서의 최소 샘플링 빈도 미만이거나 최대 샘플링 빈도를 초과할 수 없습니다.

플랫폼 센서의 샘플링 빈도는 연결된 아이템 집합 내 [[frequency]] 값으로 산출되며, 계산 방식은 구현 정의적이지만, 산출 결과값은 반드시 플랫폼 센서의 센서 유형 최소, 최대 샘플링 빈도 및 디바이스 센서의 최소, 최대 샘플링 빈도 내에 존재해야 합니다.

참고: 예를 들어 사용자 에이전트는 주어진 [[frequency]] 값 세트에 대해 최소공배수 방식으로 샘플링 빈도를 산출하고, 플랫폼에서 정한 샘플링 빈도로 상한 처리할 수 있습니다.

구체 Sensor 객체의 보고 빈도란 이 객체에서 "reading" 이벤트가 발생되는 속도를 의미합니다.

Sensor 객체는 사용자 에이전트가 플랫폼으로부터 얻는 속도 이상으로 새로운 판독값에 접근할 수 없으므로, 보고 빈도는 절대 플랫폼 센서의 샘플링 빈도를 초과할 수 없고, 이는 곧 디바이스 센서가 제공하는 최대 샘플링 빈도를 초과하지 않습니다(명시된 경우).

보고 빈도는 아래 같은 경우 Sensor의 [[frequency]]와 다를 수 있습니다:

요청한 [[frequency]]가 Sensor의 플랫폼 센서에서 get a platform sensor’s sampling bounds를 호출해 얻은 범위를 벗어나는 경우.
운영체제/하드웨어의 필터로 인해 디바이스 센서가 이전에 보고된 값과 차이가 충분히 크지 않은 판독값을 자동으로 폐기하는 경우.
Sensor 인스턴스의 센서 유형에 임계값 확인 알고리즘이 실패하여 플랫폼 센서의 최신 판독값이 업데이트되지 않는 경우.

5.5. 센서 판독값 노출 조건

사용자 에이전트는 센서 판독값을 노출할 수 있다는 다음 모든 조건이 참일 때만 Document document에 노출할 수 있습니다:

document의 관련 설정 객체는 보안 컨텍스트입니다.
document의 가시성 상태가 "visible"입니다.
document에 대한 포커스 및 출처 확인이 true를 반환합니다.
특정 조건: 확장 명세는 해당 센서 타입에 대해 더 엄격한 요구사항을 위해 새로운 조건을 이 목록에 추가할 수 있습니다.

Note: 위 조건들 외에도, Sensor 하위 클래스는 생성자에서 센서 정책 제어 기능 확인 연산을 호출하고, § 7.1.7 Sensor.start()는 센서 접근 요청을 호출합니다. 이 점검들은 § 4.2 완화 전략에 설명된 대응 전략에 해당합니다.

Note: 하드웨어 리소스를 해제하기 위해, 사용자 에이전트는 기반이 되는 플랫폼 센서가 새로운 판독값에 대한 알림을 일시 중지하도록 요청할 수 있으며, 해당 센서 판독값을 노출할 수 있을 때까지 알림을 중지할 수 있습니다.

6. 모델

6.1. 센서 유형

센서 유형에는 다음의 연관된 데이터가 있어야 한다:

하나 이상의 확장 센서 인터페이스.
비어 있지 않은 순서 있는 집합의 연관된 강력한 기능 이름 (powerful feature names)이며, 센서 권한 이름이라고 한다.

참고: 여러 센서 유형이 동일한 이름을 공유할 수 있다.
비어 있지 않은 순서 있는 집합의 연관된 정책에 의해 제어되는 기능 토큰으로, 센서 기능 이름이라고 한다.
권한 폐기 알고리즘.
최소 샘플링 주파수 (양수). 이는 구현 정의이거나, 확장 명세에 의해 정의된다. 둘 다 정해진 경우 더 큰 값을 사용한다.
최대 샘플링 주파수 (양수). 이는 구현 정의이거나, 확장 명세에 의해 정의된다. 둘 다 정해진 경우 더 작은 값을 사용한다.

최소 샘플링 주파수는 최대 샘플링 주파수보다 커서는 안 된다.

센서 유형은 다음의 연관된 데이터를 가질 수 있다:

기본 센서.
임계값 확인 알고리즘으로, 두 개의 별도의 센서 측정값을 인자로 받아 플랫폼 센서의 최신 측정값 맵을 업데이트할 만큼 충분히 다른지 판별한다.
측정값 양자화 알고리즘으로, 센서 측정값을 받아 더 낮은 정밀도의 센서 측정값을 반환한다.
가상 센서 유형.

6.2. 센서

현재 브라우징 컨텍스트의 플랫폼 센서는 다음을 가져야 한다:

연관된 집합의 활성화된 센서 객체들, 처음에는 비어 있음;
연관된 최신 측정값 맵 (최신의 센서 측정값을 저장)
연관된 센서 유형.

새로운 센서 측정값이 플랫폼 센서에 대해 취득되고, 사용자 에이전트가 센서 측정값을 노출할 수 있다면 현재 navigable의 active document에 대해 사용자 에이전트는 최신 측정값 업데이트를 해당 플랫폼 센서와 센서 측정값을 인자로 하여 호출한다.

최신 측정값 맵 안에는 엔트리가 있고, 그 키값이 "timestamp"이며 값은 측정값 타임스탬프를 밀리초 단위의 고해상도 현재 시간으로 표현한 값이다.

최신 측정값["timestamp"]는 초기에는 null로 설정되며, 최신 측정값 맵이 이전 측정값을 캐시하지 않은 경우에 해당한다.

그 외 엔트리들은 최신 측정값 맵에서 플랫폼 센서로 측정된 여러 값의 값을 담고 있다. 이러한 엔트리의 키는 속성의 식별자와 일치해야 하며, 이는 센서 유형이 연관된 확장 센서 인터페이스에서 정의된다. 속성 getter의 리턴 값은 확장 센서 인터페이스를 구현하는 객체와 속성의 식별자를 인자로 최신 측정값에서 값 가져오기를 호출하여 쉽게 얻을 수 있다.

모든 최신 측정값 엔트리의 값은 처음에 null로 설정된다.

플랫폼 센서의 샘플링 범위 구하기 를 위해, 플랫폼 센서 platformSensor가 주어졌을 때:

minimumFrequency를 platformSensor의 센서 유형의 최소 샘플링 주파수로 설정한다.
만약 platformSensor에 연결된 디바이스 센서에 최소 샘플링 주파수가 있다면, minimumFrequency를 이 값과 minimumFrequency 중 더 큰 값으로 설정한다.
maximumFrequency를 platformSensor의 센서 유형의 최대 샘플링 주파수로 설정한다.
만약 platformSensor에 연결된 디바이스 센서에 최대 샘플링 주파수가 있다면, maximumFrequency를 이 값과 maximumFrequency 중 더 작은 값으로 설정한다.
튜플 (minimumFrequency, maximumFrequency)을 반환한다.

이 예제는 위에서 설명된 모델의 가능한 구현을 보여준다.

아래 다이어그램에서는 여러 활성화된 Sensor 객체가 두 개의 다른 브라우징 컨텍스트에서 하나의 디바이스 센서와 상호 작용함을 보여준다.

Generic Sensor Model

"idle" 상태의 Sensor 객체는 플랫폼 센서의 활성화된 센서 객체에 포함되지 않으므로 해당 디바이스 센서와 상호 작용하지 않는다.

이 예제에서는 플랫폼 센서 인스턴스가 각 브라우징 컨텍스트마다 존재한다.

최신 측정값 맵은 동일한 Sensor 객체들이 같은 브라우징 컨텍스트 내에서 공유하며, 해당 플랫폼 센서의 요청된 샘플링 빈도와 동일한 속도로 갱신됩니다.

7. API

7.1. Sensor 인터페이스

[SecureContext, Exposed=(DedicatedWorker, Window)]
interface Sensor : EventTarget {
  readonly attribute boolean activated;
  readonly attribute boolean hasReading;
  readonly attribute DOMHighResTimeStamp? timestamp;
  undefined start();
  undefined stop();
  attribute EventHandler onreading;
  attribute EventHandler onactivate;
  attribute EventHandler onerror;
};

dictionary SensorOptions {
  double frequency;
};

Sensor 객체는 연관된 플랫폼 센서를 가진다.

구체적인 Sensor 객체는 또한 연관된 센서 유형을 가지며, 이는 센서 유형 중 해당 인터페이스를 확장 센서 인터페이스에 가진 것이다.

작업 소스는 이 명세에서 언급된 작업에 대하여 센서 작업 소스이다.

다음 예제에서는 먼저 사용자 에이전트가 센서 측정값에 접근하는 권한이 있는지 확인한 후, 가속도계 센서를 생성하고 이벤트 리스너를 추가하여 이벤트를 받는다. 플랫폼 센서의 활성화, 오류 조건 및 새 센서 측정값 알림 이벤트에 대응한다. 이 예제는 플랫폼 센서를 제공하는 장치의 최대 가속도 합을 측정하고 기록한다.

해당 이벤트 핸들러 이벤트 유형은 Sensor 인터페이스의 이벤트 핸들러 속성에 대해 Event handlers 섹션에서 정의된다.

navigator.permissions.query({ name: 'accelerometer' }).then(result => {
    if (result.state === 'denied') {
        console.log('Permission to use accelerometer sensor is denied.');
        return;
    }

    let acl = new Accelerometer({frequency: 30});
    let max_magnitude = 0;
    acl.addEventListener('activate', () => console.log('Ready to measure.'));
    acl.addEventListener('error', error => console.log(`Error: ${error.name}`));
    acl.addEventListener('reading', () => {
        let magnitude = Math.hypot(acl.x, acl.y, acl.z);
        if (magnitude > max_magnitude) {
            max_magnitude = magnitude;
            console.log(`Max magnitude: ${max_magnitude} m/s2`);
        }
    });
    acl.start();
});

7.1.1. 센서 수명주기

참고: 위 다이어그램의 노드는 Sensor 객체의 상태를 나타내며, 이는 기본 플랫폼 센서 또는 디바이스 센서의 가능한 상태와 혼동해서는 안 된다.

7.1.2. Sensor 가비지 콜렉션

Sensor 객체의 [[state]] 값이 "activating"이고 "activated" 이벤트, "reading" 이벤트, 또는 "error" 이벤트에 대한 이벤트 리스너가 하나라도 등록되어 있다면 해당 객체는 가비지 콜렉션되어서는 안 된다.

Sensor 객체의 [[state]] 값이 "activated"이고 "reading" 이벤트 또는 "error" 이벤트에 대한 이벤트 리스너가 하나라도 등록되어 있다면 해당 객체는 가비지 콜렉션되어서는 안 된다.

Sensor 객체의 [[state]] 값이 "activated" 또는 "activating"일 때 가비지 콜렉션된다면, 사용자 에이전트는 이 객체를 인자로 하여 센서 객체 비활성화를 호출해야 한다.

7.1.3. Sensor 내부 슬롯

Sensor 의 인스턴스는 아래 표에 설명된 내부 슬롯과 함께 생성된다:

내부 슬롯	설명 (비규범)
`[[state]]`	`Sensor` 객체의 현재 상태. 값은 "idle", "activating", 또는 "activated" 중 하나이며, 초기 상태는 "idle"이다.
`[[frequency]]`	연관된 플랫폼 센서의 샘플링 주파수 계산 및 이 `Sensor` 객체에 대해 보고 빈도의 상한선을 정의하는 데 사용되는 Hz 단위의 double 값. 초깃값은 null이다.
`[[lastEventFiredAt]]`	`Sensor` 객체의 관찰자에게 전달된 가장 최근 센서 측정값의 고해상도 타임스탬프(단위 ms / 기준 시간 이후 경과 시간)이며, 초기값은 null이다.
`[[pendingReadingNotification]]`	새 센서 측정값이 보고된 후 관찰자에게 알림이 필요한지 여부를 나타내는 boolean 값으로, 초기값은 false이다.

7.1.4. Sensor.activated

activated getter의 동작은 다음과 같다:

this.[[state]] 값이 "activated"라면 true를 반환한다.
그 외에는 false를 반환한다.

7.1.5. Sensor.hasReading

hasReading getter의 동작은 다음과 같다:

timestamp를 최신 측정값에서 값 가져오기를 this 및 "timestamp"를 인자로 호출한 결과로 설정한다.
timestamp가 null이 아니면 true를 반환한다.
그 외에는 false를 반환한다.

7.1.6. Sensor.timestamp

timestamp getter의 동작은 다음과 같다:

global을 this의 relevant global object로 설정한다.
unsafeTimestamp를 최신 측정값에서 값 가져오기를 호출하여 this 및 "timestamp"를 인자로 넘겨 결과로 설정한다.
unsafeTimestamp가 null이면 null을 반환한다.
그 외에는 상대적 고해상도 시각을 unsafeTimestamp와 global을 인자로 하여 반환한다.

7.1.7. Sensor.start()

start() 메서드의 동작은 다음과 같다:

this.[[state]] 값이 "activating" 또는 "activated"라면 return 한다.
this.[[state]] 값을 "activating"으로 설정한다.
다음 하위 절차를 병렬로 실행한다:
1. permissionState를 센서 접근 요청을 this 인자로 하여 호출한 결과로 설정한다.
2. permissionState 값이 "denied"라면:
  1. e를 "NotAllowedError" DOMException 예외 생성 결과로 설정한다.
  2. 오류 알림을 this와 e를 인자로 하여 테스크 큐에 등록한다.
  3. Return.
3. connected를 센서 연결을 this와 this의 관련 전역 객체를 인자로 호출한 결과로 설정한다.
4. connected 값이 false라면
  1. e를 "NotReadableError" DOMException 예외 생성 결과로 설정한다.
  2. 오류 알림을 this와 e를 인자로 하여 테스크 큐에 등록한다.
  3. Return.
5. 센서 객체 활성화를 this를 인자로 하여 호출한다.

7.1.8. Sensor.stop()

stop() 메서드의 동작은 다음과 같다:

this.[[state]] 값이 "idle"이면 return 한다.
this.[[state]] 값을 "idle"로 설정한다.
다음 하위 절차를 병렬로 실행한다:
1. 센서 객체 비활성화를 this를 인자로 하여 호출한다.

7.1.9. Sensor.onreading

onreading 은(는) EventHandler 타입이며 새 측정값이 사용 가능할 때 알림을 위해 호출된다.

7.1.10. Sensor.onactivate

onactivate 은(는) EventHandler 타입이며, this.[[state]] 값이 "activating"에서 "activated"로 전이될 때 호출된다.

7.1.11. Sensor.onerror

onerror 은(는) EventHandler 타입이며, 추상 또는 IDL 연산에서 발생한 오류를 동기적으로 처리할 수 없을 때마다 호출된다.

7.1.12. 이벤트 핸들러

다음은 이벤트 핸들러(및 해당 이벤트 핸들러 이벤트 타입) 로, Sensor 인터페이스를 구현하는 객체가 속성으로 지원해야 한다:

이벤트 핸들러	이벤트 핸들러 이벤트 타입
`onreading`	`reading`
`onactivate`	`activate`
`onerror`	`error`

7.2. SensorErrorEvent 인터페이스

[SecureContext, Exposed=(DedicatedWorker, Window)]
interface SensorErrorEvent : Event {
  constructor(DOMString type, SensorErrorEventInit errorEventInitDict);
  readonly attribute DOMException error;
};

dictionary SensorErrorEventInit : EventInit {
  required DOMException error;
};

SensorErrorEvent 인스턴스는 Event의 생성자(constructor)에 명시된 단계에 따라 생성됩니다.

error 속성은 초기화된 값을 반환해야 합니다. 이 속성은 DOMException 객체를 나타내며, SensorErrorEventInit에 전달된 값을 참조합니다.

8. 추상 연산

8.1. 센서 오브젝트 초기화

input: sensor_instance, Sensor 객체; options, SensorOptions 딕셔너리 인스턴스
output: 없음

각 key → value 쌍을 options에서 반복합니다.
1. 연관된 지원되는 센서 옵션이 key를 포함하지 않으면
  1. "던진다(Throw)" "NotSupportedError" DOMException을(를).
만약 options["frequency"] 가 존재하면
1. sensor_instance.[[frequency]] 를 options["frequency"]로 설정합니다.
참고: 요청한 options["frequency"] 값이 보장되지 않습니다. 적용될 수 있는 제약에 대해서는 § 5.4 샘플링 빈도와 보고 빈도를 참조하세요.

8.2. 센서 정책 제어 기능 확인하기

input: sensor_type, 센서 타입
output: 관련된 센서 기능 이름이 모두 사용 허용됨이면 true, 그렇지 않으면 false를 반환합니다.

feature_names에 sensor_type과 연관된 센서 기능 이름을 할당합니다.
각 feature_name을 feature_names에서 반복합니다.
1. 활성 문서(active document)가 해당 정책 제어 기능 feature_name을(를) 사용이 허용되지 않았다면,
  1. false를 반환합니다.
true를 반환합니다.

8.3. 센서에 연결하기

input: sensor, Sensor 객체; global, 글로벌 오브젝트
output: sensor가 플랫폼 센서에 연결된 경우 true, 그렇지 않으면 false

platformSensor를 null로 설정합니다.
type에 sensor의 연결된 센서 타입을 할당합니다.
virtualSensorType에 sensor의 연결된 가상 센서 타입 또는 null(지정되지 않은 경우)을 할당합니다.
topLevelTraversable에 global의 navigable의 최상위 traversable을 할당합니다.
virtualSensorType이 null이 아니고, topLevelTraversable의 가상 센서 매핑 에 virtualSensorType이 있으면:
1. virtualSensor에 topLevelTraversable의 가상 센서 매핑[virtualSensorType]을 할당합니다.
2. virtualSensor의 측정값 전달 가능 플래그가 true면, platformSensor를 virtualSensor에 상응하는 플랫폼 센서로 설정합니다.
  
  참고: 측정값 전달 가능 플래그가 false이면 platformSensor는 null로 남아 있고, 이 알고리즘은 false를 반환합니다.
그렇지 않으면:
1. 해당 장치에 디바이스 센서가 한 개 있으며 type의 측정값 제공이 가능하면,
  1. platformSensor를 해당 플랫폼 센서로 설정합니다.
2. 디바이스 센서가 여러 개인 경우, 디바이스 센서 중 type의 측정값 제공이 가능하면,
  1. type이 기본 센서와 연관되어 있으면,
    1. platformSensor를 해당 플랫폼 센서로 설정합니다.
platformSensor가 null이면 false를 반환합니다.
bounds를 플랫폼 센서 샘플링 범위 가져오기의 결과로 할당합니다.
sensor.[[frequency]] 가 null인 경우, type에 따라 정의된 구현별(implementation-defined) 값으로 설정합니다.
sensor.[[frequency]] 값이 bounds[0]보다 작으면 bounds[0]으로 설정합니다.
sensor.[[frequency]] 값이 bounds[1]보다 크면 bounds[1]으로 설정합니다.
true를 반환합니다.

8.4. 센서 오브젝트 활성화

input: sensor_instance, Sensor 객체
output: 없음

sensor에 플랫폼 센서와 sensor_instance를 연결합니다.
센서의 활성 센서 오브젝트 집합에 sensor_instance를 추가합니다.
센서 설정 적용을 sensor에 대해 실행합니다.
활성 상태 알림을 sensor_instance로 태스크 큐에 등록합니다.

8.5. 센서 오브젝트 비활성화

input: sensor_instance, Sensor 객체
output: 없음

sensor_instance와 연관된 모든 태스크를 센서 태스크 소스와 연관된 태스크 큐에서 제거합니다.
sensor에 플랫폼 센서와 sensor_instance를 연결합니다.
만약 sensor의 활성 센서 오브젝트 집합이 sensor_instance를 포함하면,
1. sensor_instance를 sensor의 활성 센서 오브젝트 집합에서 제거합니다.
2. 센서 설정 적용을 sensor에 대해 실행합니다.
3. sensor_instance.[[pendingReadingNotification]] 을 false로 설정합니다.
4. sensor_instance.[[lastEventFiredAt]] 을 null로 설정합니다.

8.6. 일반 센서 권한 취소 알고리즘

input: permissionName, 강력한 기능 이름
output: 없음

Sensor 인스턴스 sensor별로 현재 realm에서 반복합니다:
1. sensor.[[state]] 값이 "idle"이면, 반복 계속.
2. sensor의 센서 타입의 센서 권한 이름이 permissionName을 포함하면:
  1. 센서 오브젝트 비활성화를 sensor로 실행합니다.
  2. exception에 "NotAllowedError" 예외 생성(NotAllowedError DOMException)을 할당합니다.
  3. 에러 알림을 sensor와 exception으로 태스크 큐에 등록합니다.

8.7. 센서 설정 적용

input: platformSensor, 플랫폼 센서
output: 없음

platformSensor의 활성 센서 오브젝트 집합이 비어 있으면,
1. platformSensor의 샘플링 빈도를 null로 설정한다.
2. 각 key → value 쌍을 platformSensor의 최신 측정값에서 반복한다.
  1. Set platformSensor의 최신 측정값[key]를 null로 설정한다.
3. 구현 정의 방식으로 platformSensor에서 센서 측정값을 더 이상 제공하지 않도록 업데이트한다.
4. 리턴한다.
platformSensor의 샘플링 빈도를 구현별 값(그 안의 [[frequency]] 값들에 근거하여)으로 설정합니다.
bounds를 플랫폼 센서 샘플링 범위 가져오기의 결과로 할당합니다.
단언(Assert): platformSensor의 샘플링 빈도가 bounds[0] 이상 bounds[1] 이하입니다.

8.8. 최신 측정값 업데이트

input: sensor, 플랫폼 센서; reading, 센서 측정값
output: 없음

type에 sensor의 연결된 센서 타입을 할당합니다.
type의 threshold check algorithm이 정의되어 있다면:
1. result에 type의 threshold check algorithm 실행 결과(reading, sensor의 최신 측정값 인수) 할당
2. result가 false이면, 이 단계들 중단
reading["timestamp"]가 존재하면:
1. 동일한 모노토닉 클럭을 사용하여, reading["timestamp"]를 구현별 방식으로 unsafe current time 값으로 변환합니다.
  
  참고: 이 단계는 서로 다른 time origin을 기준으로 했을지도 모르는 timestamp들을 연산 시 같은 모노토닉 클럭 기준 값으로 통일하기 위함입니다. [HR-TIME] 참고.
그렇지 않으면, set reading["timestamp"]를 unsafe shared current time으로 설정한다.

참고: 두 경우 모두 unsafe current time 값은 스크립트에 노출되지 않는다. Sensor.timestamp 은 항상 coarsened moment 값을 time origin 기준으로 반환한다.
각 key → value 쌍을 최신 측정값에서 반복한다.
1. Set 최신 측정값[key]를 reading의 해당 값으로 설정한다.
activated_sensors에 sensor의 활성 센서 오브젝트 집합을 할당합니다.
병렬로 아래 서브스텝 실행:
1. 각 s를 activated_sensors에서 반복,
  1. 최신 측정값 갱신 보고를 s로 수행

8.9. 최신 측정값 갱신 보고

input: sensor_instance, Sensor 객체
output: 없음

sensor_instance.[[pendingReadingNotification]] 이 true인 경우,
1. 리턴
sensor_instance.[[pendingReadingNotification]] 를 true로 설정합니다.
lastReportedTimestamp에 sensor_instance.[[lastEventFiredAt]] 값을 할당
lastReportedTimestamp가 설정되어 있지 않다면,
1. 새 측정값 알림을 sensor_instance로 태스크 큐에 등록합니다.
2. 리턴
단언(Assert): sensor_instance.[[frequency]] 가 null이 아님.
단언(Assert): sensor_instance.[[frequency]] 가 0보다 큼.
reportingInterval에 1 / sensor_instance.[[frequency]] 값을 할당
timestampDelta에 최신 측정값["timestamp"] - lastReportedTimestamp 값을 할당
timestampDelta가 reportingInterval 이상인 경우
1. 새 측정값 알림을 sensor_instance로 태스크 큐에 등록합니다.
2. 리턴
deferUpdateTime에 reportingInterval - timestampDelta의 결과를 할당
이벤트 루프 돌리기를 deferUpdateTime 길이만큼 수행
sensor_instance.[[pendingReadingNotification]] 이 true인 경우,
1. 새 측정값 알림을 sensor_instance로 태스크 큐에 등록합니다.

8.10. 새 측정값 알림

입력: sensor_instance, Sensor 객체입니다.
출력: 없음

sensor_instance.[[pendingReadingNotification]] 을 false로 설정합니다.
sensor_instance.[[lastEventFiredAt]] 에 최신 측정값["timestamp"]를 설정합니다.
"reading"이라는 이벤트를 sensor_instance에 발생시킵니다.

8.11. 활성 상태 알림

입력: sensor_instance, Sensor 객체입니다.
출력: 없음

sensor_instance.[[state]] 를 "activated"로 설정합니다.
"activate"라는 이벤트를 sensor_instance에 발생시킵니다.
sensor를 sensor_instance와 연결된 플랫폼 센서로 설정합니다.
sensor의 최신 측정값["timestamp"]가 null이 아니면,
1. 새 측정값 알림을 sensor_instance로 태스크 큐에 등록합니다.

8.12. 오류 알림

입력: sensor_instance, Sensor 객체입니다.; error, DOMException입니다.
출력: 없음

sensor_instance.[[state]] 를 "idle"로 설정합니다.
"error"라는 이벤트를 sensor_instance에 SensorErrorEvent 를 이용하여 발생시키고, error 속성은 error로 초기화합니다.

8.13. 최신 측정값에서 값 가져오기

입력: sensor_instance, Sensor 객체입니다.; key, 값을 나타내는 문자열입니다.
출력: 센서 측정값 또는 null.

sensor_instance.[[state]] 가 "activated"이면,
1. readings에 sensor_instance와 연관된 플랫폼 센서의 최신 측정값을 할당합니다.
2. type을 sensor_instance의 연결된 센서 타입으로 할당합니다.
3. type의 측정값 양자화 알고리즘이 정의되어 있으면,
  1. readings을 type의 측정값 양자화 알고리즘을 readings로 호출한 결과로 설정합니다.
4. 확장 명세가 sensor_instance에 대해 로컬 좌표계를 정의하면,
  1. [COORDINATES-TRANSFORMATION]을 참고하여, readings의 값을 로컬 좌표계로 변환합니다.
5. readings[key]를 반환합니다.
그렇지 않으면 null을 반환합니다.

8.14. 센서 접근 요청

입력: sensor_instance, Sensor 객체입니다.
출력: 권한 상태.

sensor_type에 sensor_instance의 연결된 센서 타입을 할당합니다.
sensor_permissions에 sensor_type의 센서 권한 이름을 할당합니다.
각 permission_name을 sensor_permissions에서 반복합니다.
1. state에 permission_name 사용 요청 결과로 설정합니다.
2. state가 "denied"이면,
  1. "denied"를 반환합니다.
"granted"를 반환합니다.

8.15. 포커스 및 오리진 확인

입력: document, Document입니다.
출력: 불리언 값

origin에 document의 관련 설정 객체의 origin을 할당합니다.
focusedDocument에 document의 노드 네비게이블의 최상위 traversable의 현재 포커스 영역의 DOM anchor의 노드 document를 할당합니다.
focusedOrigin에 focusedDocument의 관련 설정 객체의 origin을 할당합니다.
origin과 focusedOrigin이 동일 오리진 도메인이면 true를, 아니면 false를 반환합니다.

9. 자동화

Generic Sensor API 및 확장 명세는 테스트 작성자에게 도전이 됩니다. 이 인터페이스를 온전히 테스트하기 위해서는 예측 가능한 방식으로 응답하는 물리 하드웨어 장치가 필요하기 때문입니다. 이러한 문제를 해결하기 위해 본 문서는 [WEBDRIVER2] 확장 명령을 정의하여, 가상 센서를 정의하고 제어할 수 있게 하였습니다. 이 가상 센서는 디바이스 센서처럼 동작합니다. 가상 센서는 특정 특성을 가진 장치를 나타내며, 그 측정값은 전적으로 사용자에 의해 정의될 수 있습니다.

9.1. 가상 센서

가상 센서는 디바이스 센서의 동작을 제어된 방식으로 시뮬레이션합니다. 하나 이상의 플랫폼 센서에 센서 측정값을 제공합니다.

가상 센서는 다음과 같은 데이터를 가집니다:

측정값 제공 가능 플래그 (불리언)
요청된 샘플링 빈도 (숫자). 일반 디바이스 센서의 실제 샘플링 빈도가 불투명한 것처럼, 가상 센서의 요청된 샘플링 빈도도 구현별 값으로, 최소 샘플링 빈도와 최대 샘플링 빈도 사이의 값입니다. 가상 센서가 어느 플랫폼 센서에도 측정값을 제공하지 않으면, 요청된 샘플링 빈도는 0입니다.

참고: 요청된 샘플링 빈도 값은 연결된 플랫폼 센서들이 샘플링 빈도를 요구하는지(센서별로 다를 수 있음) 또는 단순 폴링인지에 따라 달라질 수 있습니다. 이 경우 샘플링 빈도 요청이 없을 수도 있습니다.
최소 샘플링 빈도 (숫자). 가상 센서는 디바이스 센서와 같으므로, 이는 디바이스 센서의 최소 샘플링 빈도에 해당합니다.
최대 샘플링 빈도 (숫자). 가상 센서는 디바이스 센서와 같으므로, 이는 디바이스 센서의 최대 샘플링 빈도에 해당합니다.

가상 센서 타입은 특정 타입의 센서를 나타내는 문자열입니다.

타입별 가상 센서 메타데이터는 순서 있는 맵(ordered map)으로, 가상 센서 타입에서 가상 센서 메타데이터로 매핑됩니다. 이는 처음에는 비어 있으며, 확장 명세가 자신이 정의하는 센서 타입에 대해 하나 이상의 항목을 맵에 정의해야 합니다.

가상 센서 메타데이터는 구조체(struct)이며, 그 항목은 다음과 같습니다:

측정값 파싱 알고리즘

JSON Object를 받아 센서 측정값 또는 undefined를 반환하는 알고리즘입니다.

각 최상위 traversable에는 가상 센서 매핑이 있습니다. 이는 순서 있는 맵(ordered map)으로, 가상 센서 타입에서 가상 센서로 매핑됩니다.

참고: 가상 센서 매핑 구조체(struct)는 동일 타입의 모든 가상 센서에 공통적인 정보를 담습니다. 가상 센서는 가상 센서 생성이나 사용 시점마다 달라질 수 있는 데이터를 가집니다.

참고: 가상 센서 매핑은 각각의 top-level traversable에 연결되며, 특정 navigable에 연결되는 것이 아닙니다. 그 이유는 동일 센서 타입에 대한 플랫폼 센서가 동일 top-level traversable에 속하는 모든 navigable에서 동일한 가상 센서와 연결되어야 하기 때문입니다. 이는 실제 환경에서 하나의 하드웨어(또는 퓨전) 센서가 여러 navigable에 측정값을 제공하는 동작을 더 잘 모방합니다.

참고: 이러한 동작은 web-platform-tests를 통한 이 명세의 테스트를 도울 수 있습니다. testdriver.js를 통한 모든 WebDriver 통신은 테스트 하네스 프레임을 경유한다는 점도 참고하세요.

9.2. 확장 명령어

9.2.1. 가상 센서 생성

HTTP 메서드	URI 템플릿
POST	/session/{session id}/sensor

이 확장 명령어는 특정 가상 센서를 새로운 센서 타입으로 생성합니다. 동일 센서 타입의 Sensor 인스턴스에서 start()를 호출하면, 이 가상 센서가 디바이스 센서로 사용되며, § 9.2.4 가상 센서 삭제가 실행될 때까지 유지됩니다.

참고: 이 확장 명령어의 동작 덕분에, 동일 타입 Sensor 인스턴스들이 공존하며 서로 다른 디바이스 센서를 가질 수 있습니다. Sensor 인스턴스 sensor가 이 명령이 호출되기 전에 실제 하드웨어 센서에 연결되어 있었다면, 기존 센서를 계속 동작하고, 읽기 값도 계속 받습니다. 오직 센서 연결이 다시 호출될 때에만 가상 센서로부터 측정값을 받게 됩니다.

이 알고리즘에 사용되는 `parameters` 인자의 속성
파라미터 이름	값 타입	필수 여부
"`type`"	`String`	예
"`connected`"	`Boolean`	아니오
"`maxSamplingFrequency`"	`Number`	아니오
"`minSamplingFrequency`"	`Number`	아니오

원격 엔드 단계는 다음과 같습니다:

virtualSensorType을 "type" 프로퍼티 가져오기를 parameters에서 호출한 결과로 설정합니다.
virtualSensorType이 String이 아니면, error를 WebDriver error code invalid argument와 함께 반환합니다.
타입별 가상 센서 메타데이터에 virtualSensorType이 없으면, error를 WebDriver error code invalid argument와 함께 반환합니다.
topLevelVirtualSensorMapping을 현재 브라우징 컨텍스트의 최상위 traversable의 가상 센서 매핑으로 설정합니다.
topLevelVirtualSensorMapping에 virtualSensorType이 이미 있으면, error를 WebDriver error code invalid argument와 함께 반환합니다.
connected를 connected 프로퍼티를 true로, 기본값으로 가져오기 결과로 설정
maxSamplingFrequency를 maxSamplingFrequency 프로퍼티를 구현별 기본값으로 가져오기 결과로 설정
maxSamplingFrequency가 Number 타입이 아니거나, 값이 NaN, +∞, −∞라면 error를 WebDriver error code invalid argument와 함께 반환
minSamplingFrequency를 minSamplingFrequency 프로퍼티를 구현별 기본값으로 가져오기 결과로 설정
minSamplingFrequency가 Number 타입이 아니거나, 값이 NaN, +∞, −∞라면 error를 WebDriver error code invalid argument와 함께 반환
minSamplingFrequency 값이 maxSamplingFrequency보다 크면, error를 WebDriver error code invalid argument와 함께 반환
virtualSensor를 새로운 가상 센서로 생성합니다.
virtualSensor의 측정값 제공 가능 플래그를 connected로 설정합니다.
virtualSensor의 최소 샘플링 빈도를 minSamplingFrequency로 설정합니다.
virtualSensor의 최대 샘플링 빈도를 maxSamplingFrequency로 설정합니다.
topLevelVirtualSensorMapping[virtualSensorType] = virtualSensor로 설정합니다.
success를 데이터 null과 함께 반환합니다.

현재 브라우징 컨텍스트에서 ID가 23인 세션에 "ambient-light" 가상 센서를 생성하려면, 로컬 엔드는 다음과 같이 본문을 포함하여 /session/23/sensor로 POST 요청을 보냅니다:

{
  "type": "ambient-light",
  "maxSamplingFrequency": 60,
  "minSamplingFrequency": 5
}

주의: 하나의 가상 센서 타입 당 센서 타입은 최상위 이동 가능 컨텍스트에서 하나만 생성할 수 있으며, 그렇지 않으면 잘못된 인수 WebDriver 오류 코드가 반환됩니다.

9.2.2. 가상 센서 정보 조회

HTTP 메서드	URI 템플릿
GET	/session/{session id}/sensor/{type}

이 확장 명령은 가상 센서에 대한 정보를 가져오며, § 9.2.1 가상 센서 생성에서 생성된 센서에 대한 정보입니다.

성공을 반환하는 경우, 성공과 연관된 데이터는 다음과 같은 프로퍼티를 가지는 Object입니다:

프로퍼티 이름	값 타입	설명(비규범)
"`requestedSamplingFrequency`"	`Number`	가상 센서의 요청한 샘플링 주파수

Note: § 5.4 샘플링 및 리포팅 주파수에서 샘플링 주파수에 대한 제약과, 요청한 샘플링 주파수가 구현 정의 값이 되는 이유를 설명합니다. 일반적으로, 값은 가상 센서의 최소 샘플링 주파수와 최대 샘플링 주파수 범위 내에 있다고 가정하는 것이 안전합니다.

원격 끝 단계는 다음과 같습니다:

virtualSensorType을 type url 변수의 값으로 한다.
topLevelVirtualSensorMapping을 현재 브라우징 컨텍스트의 최상위 이동 가능 컨텍스트의 가상 센서 매핑으로 한다.
만약 topLevelVirtualSensorMapping이 포함하지 않는다면 virtualSensorType을, 에러를 WebDriver 에러 코드 invalid argument와 함께 반환한다.
virtualSensor를 topLevelVirtualSensorMapping[virtualSensorType]로 한다.
info를 새로운 Object로 한다.
프로퍼티 설정을 info에 대해 "requestedSamplingFrequency"와 virtualSensor의 요청한 샘플링 주파수로 호출한다.
성공을 data info와 함께 반환한다.

9.2.3. 가상 센서 읽기값 갱신

HTTP 메서드	URI 템플릿
POST	/session/{session id}/sensor/{type}

이 확장 명령어는 새로운 센서 측정값을 플랫폼 센서에서 사용할 수 있게 합니다.

참고: 가상 센서는 디바이스 센서처럼 동작하므로 여기서 생성되는 센서 측정값도 플랫폼 센서에 의해 처리됩니다. 예를 들어, 센서 타입의 임계값 확인 알고리즘이나 센서 측정값 노출 가능 여부에 따라 버려질 수도 있습니다.

이 알고리즘에 사용되는 `parameters` 인자의 속성
파라미터 이름	값 타입	필수 여부
"`reading`"	`Object`	예

원격 엔드 단계는 다음과 같습니다:

reading을 reading 프로퍼티 가져오기를 parameters에서 호출해 얻는 결과로 설정합니다.
reading이 Object 타입이 아니면, error를 WebDriver error code invalid argument와 함께 반환합니다.
virtualSensorType에 type URL 변수의 값을 할당합니다.
타입별 가상 센서 메타데이터에 virtualSensorType이 속하지 않으면, error를 WebDriver error code invalid argument와 함께 반환합니다.
metadata를 타입별 가상 센서 메타데이터[virtualSensorType]으로 설정합니다.
topLevelVirtualSensorMapping을 현재 브라우징 컨텍스트의 최상위 traversable의 가상 센서 매핑으로 설정합니다.
topLevelVirtualSensorMapping에 virtualSensorType이 없으면, error를 WebDriver error code invalid argument와 함께 반환합니다.
virtualSensor를 topLevelVirtualSensorMapping[virtualSensorType]로 설정합니다.
parsedReading을 metadata의 측정값 파싱 알고리즘에 reading을 호출한 결과로 설정합니다.
parsedReading이 undefined면, error를 WebDriver error code invalid argument와 함께 반환합니다.
구현별 방식으로 parsedReading이 virtualSensor에 연결된 플랫폼 센서들에서 얻을 수 있게 만듭니다.
success를 데이터 null과 함께 반환합니다.

9.2.3.1. 측정값 파싱 알고리즘

이 명세는 확장 명세가 타입별 가상 센서 메타데이터에서 사용하기 위해 가상 센서 메타데이터를 정의할 때 사용할 수 있는 몇 가지 알고리즘을 정의합니다.

9.2.3.1.1. 단일 값 숫자 측정값 파싱

입력: parameters, JSON Object; valueName, 문자열(string)
출력: 센서 측정값 또는 undefined

value를 get a property를 parameters와 valueName으로 호출한 결과로 설정합니다.
value가 Number 타입이 아니거나, 값이 NaN, +∞, −∞라면 undefined를 반환합니다.
reading을 새로운 센서 측정값으로 설정합니다.
Set reading[valueName]을 value로 설정합니다.
reading을 반환합니다.

9.2.3.1.2. XYZ 측정값 파싱

입력: parameters, JSON Object
출력: 센서 측정값 또는 undefined

x를 get a property를 parameters와 "x"로 호출한 결과로 설정합니다.
x가 Number 타입이 아니거나, 값이 NaN, +∞, −∞라면 undefined를 반환합니다.
y를 get a property를 parameters와 "y"로 호출한 결과로 설정합니다.
y가 Number 타입이 아니거나, 값이 NaN, +∞, −∞라면 undefined를 반환합니다.
z를 get a property를 parameters와 "z"로 호출한 결과로 설정합니다.
z가 Number 타입이 아니거나, 값이 NaN, +∞, −∞라면 undefined를 반환합니다.
reading을 새로운 센서 측정값으로 설정합니다.
Set reading["x"]를 x로 설정합니다.
Set reading["y"]를 y로 설정합니다.
Set reading["z"]를 z로 설정합니다.
reading을 반환합니다.

9.2.4. 가상 센서 삭제

HTTP 메서드	URI 템플릿
DELETE	/session/{session id}/sensor/{type}

이 확장 명령어는 주어진 타입의 가상 센서를 삭제합니다.

원격 엔드 단계는 다음과 같습니다:

virtualSensorType을 type URL 변수의 값으로 설정합니다.
타입별 가상 센서 메타데이터에 virtualSensorType이 없으면, error를 WebDriver error code invalid argument로 반환합니다.
topLevelVirtualSensorMapping을 현재 브라우징 컨텍스트의 최상위 traversable의 가상 센서 매핑으로 설정합니다.
Remove topLevelVirtualSensorMapping[virtualSensorType].
success를 데이터 null과 함께 반환합니다.

참고: 사용 중인 디바이스 센서가 더 이상 사용 가능하지 않을 때(예: 물리적으로 연결 해제되거나, UA와 무관한 요인으로 중단된 경우) 플랫폼 센서 및 Sensor 인스턴스의 동작은 명세되어 있지 않습니다. 구현체는 기존 Sensor 인스턴스 유지(새 측정값만 보고하지 않음), 센서 오브젝트 비활성화, 또는 플랫폼 센서가 오류 발생시켜 궁극적으로 오류 알림이 호출되는 등의 대응이 가능합니다.

10. 확장성

이 절은 비규범적입니다.

참고: 이 절과 그 하위 절은 확장 명세 작성자를 위해 의무적인 용어로 작성되었으나, 구현자 관점에서는 규범적이지 않습니다.

이 절에서는 본 명세가 다양한 센서 타입에 대한 API를 확장하는 방법을 설명합니다.

이러한 확장 명세는 하나의 센서 타입에 초점을 맞추고, 필요하다면 high 및 low 레벨을 각각 노출하는 것이 권장됩니다.

확장 명세는 센서 측정값에 캘리브레이션 과정이 적용되는지 여부를 정의하는 것이 권장됩니다.

확장 명세는 해당 센서 타입의 로컬 좌표계를 명시적 또는 Sensor 오브젝트마다 다르게 설정할 수 있도록 정의할 수 있습니다.

최신 확장 명세 목록은 [GENERIC-SENSOR-USECASES] 및 [MOTION-SENSORS] 문서를 참고하십시오.

10.1. 보안 및 프라이버시

확장 명세는 다음을 따라야 합니다:

일반적인 완화 전략을 준수해야 합니다.
상황별로 적용되는 완화 전략을 고려해야 합니다.
보안 및 프라이버시에 관한 자체 검토 설문 [SECURITY-PRIVACY-QUESTIONNAIRE]를 평가받아야 합니다.
특히, 센서가 동일 오리진 정책으로 통제되지 않는 새로운 통신 채널을 노출할 때 발생할 수 있는 동일 오리진 정책 위반에 대해 평가해야 합니다.

10.2. 명명 규칙

Sensor 인터페이스는 low-level 센서의 경우 관련 플랫폼 센서의 이름을 따라야 합니다. 예를 들어 자이로스코프에 해당하는 인터페이스는 Gyroscope로 명명하는 것이 좋습니다. Sensor 인터페이스 중 high-level 센서는 측정 물리량과 "Sensor"를 조합해서 명명합니다. 예: 거리를 측정하는 센서라면 ProximitySensor로 명명합니다.

Sensor 서브클래스의 센서 측정값 값은, 해당 값의 전체 이름으로 속성을 명명해야 합니다. 예를 들어 Thermometer 인터페이스는 센서 측정값의 값을 temperature 속성(즉 value나 temp가 아님)에 저장해야 합니다. 좋은 명명 규칙의 참고 자료는 Quantities, Units, Dimensions and Data Types Ontologies [QUDT]입니다.

10.3. 단위

확장 명세는 센서 측정값의 단위를 반드시 명시해야 합니다.

TAG의 API 디자인 원칙 [API-DESIGN-PRINCIPLES]에 따라 모든 시간 측정은 밀리초 단위이어야 하며, 다른 단위는 아래 우선순위 순서로(단, 온도는 켈빈보다 섭씨를 우선) 명시: SI, SI 유도 단위, 그리고 SI와 함께 사용이 허용된 비SI 단위. 자세한 설명은 SI Brochure [SI] 참고.

10.4. High-Level VS Low-Level 센서 노출

지금까지 센서를 웹 플랫폼에 노출하는 명세들은 고수준 센서 API에 집중해왔습니다. [GEOLOCATION-API] [ORIENTATION-EVENT]

이는 여러 이유로 적절한 접근이었습니다. 실제로 high-level 센서는:

개발자의 의도를 명확하게 전달합니다.
하드웨어 센서의 동작을 잘 몰라도 사용할 수 있습니다.
사용이 간편합니다.
브라우저가 성능 및 배터리 수명을 개선할 수 있도록 해줍니다.
노출 정보의 양과 종류를 줄여 일부 프라이버시 및 보안 문제를 방지할 수 있습니다.

그러나 가상/증강현실 등 다양한 최신 사용 예시에서는 성능상의 이유 등으로 low-level 센서 접근이 필요합니다.

low-level 접근을 제공하면 웹앱 개발자가 도메인별 제약을 활용하고 더욱 고성능의 시스템을 직접 설계할 수 있습니다.

Extensible Web Manifesto [EXTENNNNSIBLE]의 원칙을 따라, 확장 명세는 주로 low-level 센서 API를 노출하는데 집중해야 하지만, 필요성이 뚜렷할 때 high-level API도 함께 노출하는 것이 좋습니다.

10.5. 동일 타입 센서 다중 사용을 지양해야 할 때는?

동일 센서 타입의 Sensor 인스턴스를 동일 파라미터로 여러 개 생성하는 것은 하드웨어 자원 소모가 불필요하게 증가할 수 있으므로 권장되지 않습니다.

여러 관찰자가 새 센서 측정값 알림을 받고 싶을 때에는 동일 Sensor 인스턴스에 event listener를 추가하거나, onreading 이벤트 핸들러를 쓰는 것이 좋습니다.

반면, 여러 Sensors 인스턴스가 서로 다른 센서 타입 설정(예: frequency, 정확도 등)을 위해 만들어졌다면 이는 적절할 수 있습니다. 추가 설정은 확장 명세에서 정의될 수 있습니다.

10.6. 정의 요건

확장 명세는 § 6.1 센서 타입에 기술된 모든 연관 데이터를 반드시 정의해야 합니다.

아래는 확장 명세가 명시해야 할 연관 데이터 일부에 대한 상세 정보입니다.

확장 센서 인터페이스: 인터페이스(interface)로, 상속 인터페이스에 Sensor를 포함해야 하며, 생성 가능(constructible)해야 합니다. Constructor는 선택적 dictionary (이때 상속된 dictionary에 SensorOptions가 포함되어야 함)를 인자로 받습니다.

확장 센서 인터페이스는 지원 옵션의 집합(지원 센서 옵션)을 갖습니다. 확장 명세에서 따로 정의하지 않는 한, 지원 센서 옵션에는 "frequency" 하나만 포함됩니다.

UA는 확장 센서 인터페이스에서 지원하지 못하는 센서 옵션이 있다면 해당 지원 센서 옵션에서 제거해야 합니다.

확장 센서 인터페이스에서 센서 측정값을 노출하는 속성(attribute)은 읽기 전용(read-only)이어야 하며, 이들의 getter는 최신 측정값에서 값 가져오기를 this와 해당 속성 식별자로 호출한 결과를 반환해야 합니다.
센서 타입이 센서 퓨전을 표현하는 경우, 센서 권한 이름은 퓨전 소스 센서 타입에 연결된 값이어야 합니다.

확장 명세는 각 센서 타입에 대해 아래 정의를 추가로 명시할 수 있습니다.

dictionary (이때 상속 dictionary에 SensorOptions 포함)
기본 센서. 대부분의 장치는 각각의 타입마다 하나의 플랫폼 센서만 있으므로 기본 센서 정의가 쉽습니다. 여러 센서가 일반적인 타입에는 확장 명세에서 기본 센서를 굳이 정의하지 않는게 더 합리적일 수 있습니다.

10.7. 자동화

사용자 에이전트 자동화와 애플리케이션 테스트를 가능하게 하기 위해, 확장 명세에서는 다음을 권장합니다:

항목 하나 이상을 타입별 가상 센서 메타데이터에 추가합니다.
따라서 하나 이상의 가상 센서 메타데이터 인스턴스를 정의합니다.
센서 타입의 가상 센서 타입을 명시하며, 이는 해당하는 타입별 가상 센서 메타데이터 항목에서 사용하는 키 값과 일치해야 합니다.

확장 명세에서 § 10.10 예시 WebIDL에 설명된 근접 센서에 대해 아래와 같은 내용을 포함할 수 있습니다:

Proximity Sensor는 하나의 확장 센서 인터페이스 ProximitySensor와 연결된 센서 타입입니다. 해당 가상 센서 타입은 "proximity"입니다.
[...]

proximity reading parsing algorithm은 JSON Object parameters를 받아 단일 값 숫자 측정값 파싱을 parameters와 "distance" 인수로 호출해야 합니다.

타입별 가상 센서 메타데이터 맵(map)에는 키가 "proximity"이고 값이 가상 센서 메타데이터인 항목이 있어야 하며, 해당 reading parsing algorithm은 proximity reading parsing algorithm이어야 합니다.

10.8. Permission API 확장

각 센서 타입에 대한 Sensor 인터페이스 구현체는, 그 측정값을 관련 이름이나 PermissionDescriptor로 보호해야 합니다. low-level sensor는 자신의 인터페이스 이름을 이름으로 사용할 수 있습니다(예: "gyroscope", "accelerometer" 등). Fusion sensor는 퓨전 소스로 사용되는 각 센서에 대해 반드시 권한을 요청해야 합니다.

퓨전 데이터만으로 low-level 센서 측정값을 복구하는 것이 어렵더라도, 일부 원래 정보를 추론할 수 있습니다. 예를 들어, absolute나 geomagnetic orientation 센서를 사용하는 경우 사용자의 공간 방향을 쉽게 유추할 수 있습니다. 그러므로 이러한 센서는 지구 자기장과의 관계 정보를 제공하는 magnetometer 접근 권한을 반드시 요청해야 합니다. 반대로, 상대 방향 센서는 이런 정보를 노출하지 않으므로 magnetometer 권한을 요청할 필요가 없습니다.

Permission descriptors 를 사용해 정확도 또는 샘플링 빈도 같은 허용 최대 한계를 설정할 수도 있습니다. 아래는 가속도 센서에 대한 Permission API 확장 예시입니다.

dictionary AccelerometerPermissionDescriptor : PermissionDescriptor {
    boolean highAccuracy = false;
    boolean highFrequency = false;
};

10.9. Permissions Policy API 확장

각 센서 타입에 대한 Sensor 인터페이스 구현체는 (센서 퓨전이 없다면) 하나 또는 (있다면) 여러 개의 정책 제어 기능을 갖게 되며, 이 제어 기능은 해당 구현이 문서에서 사용할 수 있는지 여부를 판정합니다.

각 기능의 기본 허용 목록(allowlist)은 'self'입니다.

참고: 기본 허용 목록 'self'는 Sensor 인터페이스 구현의 동일 오리진 중첩 프레임 사용은 허용하지만, 제3자 컨텐츠에서는 센서 측정값 접근은 막습니다.

센서 기능 이름 집합(set)에는 관련 정책 제어 기능 토큰 모두가 포함되어야 합니다.

low-level sensor는 보통 자신의 인터페이스 이름을 정책 제어 기능 토큰으로 사용할 수 있습니다(예: "gyroscope", "accelerometer"). 확장 명세에서 달리 정의하지 않는 경우, 센서 기능 이름은 타입에 연결된 센서 권한 이름과 동일합니다.

가속도계(accelerometer) 기능을 제3자 오리진에 허용하려면, 프레임 컨테이너 요소에 allow 속성을 추가합니다:

<iframe src="https://third-party.com" allow="accelerometer"/></iframe>

HTTP 응답 헤더의 permission policy로 센서 사용 자체를 완전히 비활성화할 수도 있습니다:

Permissions-Policy: accelerometer=()

Fusion sensor는 퓨전 소스로 사용되는 센서들의 센서 기능 이름을 사용해야 합니다.

제3자 오리진에서 absolute orientation 센서가 필요로 하는 accelerometer, magnetometer, gyroscope 기능을 허용하려면:

<iframe src="https://third-party.com" allow="accelerometer; magnetometer; gyroscope"/>

10.10. 예시 WebIDL

다음은 proximity 센서에 대해 본 명세 확장을 위한 WebIDL 예시입니다.

[SecureContext, Exposed=Window]
interface ProximitySensor : Sensor {
    constructor(optional ProximitySensorOptions proximitySensorOptions = {});
    readonly attribute double? distance;
};

dictionary ProximitySensorOptions : SensorOptions {
    double min;
    double max;
    ProximitySensorPosition position;
    ProximitySensorDirection direction;
};

enum ProximitySensorPosition {
    "top-left",
    "top",
    "top-right",
    "middle-left",
    "middle",
    "middle-right",
    "bottom-left",
    "bottom",
    "bottom-right"
};

enum ProximitySensorDirection {
    "front",
    "rear",
    "left",
    "right",
    "top",
    "bottom"
};

11. 감사의 말

무엇보다도 Anssi Kostiainen에게 이 명세 개발 과정 전반에서 꾸준하고 헌신적인 지지와 기여에 대한 감사의 말을 전합니다. 또한 Mikhail Pozdnyakov, Alexander Shalamov, Rijubrata Bhaumik, Kenneth Rohde Christiansen에게도 귀중한 구현 피드백, 제안, 그리고 연구로 이 명세 작업에 도움을 주신 점을 감사드립니다.

Rick Waldron에게도 웹을 위한 generic sensor API 설계 논의를 이끌어주고, 이 API의 원형을 구상해주었으며, Johnny-Five 프로젝트에서의 피드백과 명세 개발 기간 내내 지속적으로 도움을 주신 것에 깊이 감사드립니다.

Boris Smus, Tim Volodine, Rich Tibbett에게 웹에서 센서를 일관적으로 노출시키는 초기 작업에 특별한 감사를 전합니다.

Anne van Kesteren에게는 직접적, IRC를 통한 끊임없는 도움에 감사를 표합니다.

Domenic Denicola, Jake Archibald에게도 도와주신 데 감사드립니다.

Frederick Hirsch, Dominique Hazaël-Massieux (HTML5Apps 프로젝트를 통해)에게도 행정적, 기술적 도움 모두에 감사를 표합니다.

Tab Atkins에게는 Bikeshed를 만들어주고 그 미묘한 차이점까지 설명해주신 수고에 감사합니다.

프라이버시와 보안을 주제로 Lukasz Olejnik, Maryam Mehrnezhad의 기여에 감사합니다.

다음 분들은 GitHub에서의 폭넓은 논의를 통해 본 명세에 크게 기여해주셨습니다: Anssi Kostiainen, Boris Smus, chaals, Claes Nilsson, Dave Raggett, David Mark Clements, Domenic Denicola, Dominique Hazaël-Massieux (HTML5Apps 프로젝트 참여), Francesco Iovine, Frederick Hirsch, gmandyam, Jafar Husain, Johannes Hund, Kris Kowal, Lukasz Olejnik, Marcos Caceres, Marijn Kruisselbrink, Mark Foltz, Mats Wichmann, Matthew Podwysocki, Olli Pettay, pablochacin, Remy Sharp, Rich Tibbett, Rick Waldron, Rijubrata Bhaumik, robman, Sean T. McBeth, Tab Atkins Jr., Virginie Galindo, zenparsing, 그리고 Zoltan Kis.

또한 아래 분들께도 특별히 감사드립니다: Anssi Kostiainen, Dominique Hazaël-Massieux, Erik Wilde, Michael[tm] Smith (편집상의 의견과 기여 포함)

일반 센서 API

개요

이 문서의 현황

1. 소개

2. 범위

3. 하드웨어 기능 탐지에 대한 참고

4. 보안 및 개인정보 보호 고려사항

4.1. 개인정보 및 보안 위협 유형

4.1.1. 위치 추적

4.1.2. 도청

4.1.3. 키 입력 감시

4.1.4. 기기 핑거프린팅

4.1.5. 사용자 식별

4.2. 완화 전략

4.2.1. 보안 컨텍스트

4.2.2. 권한 정책

4.2.3. 포커스된 영역

4.2.4. 가시 상태

4.2.5. 권한 API

4.3. 개별 사용 사례별 완화 전략

4.3.1. 최대 샘플링 빈도 제한

4.3.2. 센서 완전 중지

4.3.3. 전달되는 측정값 수 제한

4.3.4. 정확도 낮추기

4.3.5. API 사용 현황 사용자 알림 유지

5. 개념

5.1. 센서

5.2. 센서 유형

5.3. 기본 센서

5.4. 샘플링 빈도 및 보고 빈도

5.5. 센서 판독값 노출 조건

6. 모델

6.1. 센서 유형

6.2. 센서

7. API

7.1. Sensor 인터페이스

7.1.1. 센서 수명주기

7.1.2. Sensor 가비지 콜렉션

7.1.3. Sensor 내부 슬롯

7.1.4. Sensor.activated

7.1.5. Sensor.hasReading

7.1.6. Sensor.timestamp

7.1.7. Sensor.start()

7.1.8. Sensor.stop()

7.1.9. Sensor.onreading

7.1.10. Sensor.onactivate

7.1.11. Sensor.onerror

7.1.12. 이벤트 핸들러

7.2. SensorErrorEvent 인터페이스

8. 추상 연산

8.1. 센서 오브젝트 초기화

8.2. 센서 정책 제어 기능 확인하기

8.3. 센서에 연결하기

8.4. 센서 오브젝트 활성화

8.5. 센서 오브젝트 비활성화

8.6. 일반 센서 권한 취소 알고리즘

8.7. 센서 설정 적용

8.8. 최신 측정값 업데이트

8.9. 최신 측정값 갱신 보고

8.10. 새 측정값 알림

8.11. 활성 상태 알림

8.12. 오류 알림

8.13. 최신 측정값에서 값 가져오기

8.14. 센서 접근 요청

8.15. 포커스 및 오리진 확인

9. 자동화

9.1. 가상 센서

9.2. 확장 명령어

9.2.1. 가상 센서 생성

9.2.2. 가상 센서 정보 조회

9.2.3. 가상 센서 읽기값 갱신

9.2.3.1. 측정값 파싱 알고리즘

9.2.3.1.1. 단일 값 숫자 측정값 파싱

9.2.3.1.2. XYZ 측정값 파싱

9.2.4. 가상 센서 삭제

10. 확장성

10.1. 보안 및 프라이버시

10.2. 명명 규칙

10.3. 단위

10.4. High-Level VS Low-Level 센서 노출