웹은 하드웨어 기능을 노출해야 합니까?

저는 최근에 웹의 미래에 대한 여러 브라우저 공급업체 간의 의견 차이, 특히 Chromium의 Project Fugu와 같이 웹 플랫폼 기능을 기본 플랫폼에 더 가깝게 만들기 위한 다양한 노력에 관심을 갖고 있습니다.

주요 입장은 다음과 같이 요약할 수 있습니다.

• Google(Intel, Microsoft 및 Samsung과 같은 파트너와 함께)은 Fugu에 있는 것과 같은 과다한 새로운 API를 사용하여 공격적으로 추진하고 혁신하고 있으며 Chromium에서 제공합니다.
• Apple은 보안 및 개인 정보 보호 문제를 제기하는 많은 새로운 API를 표시하면서 보다 보수적인 접근 방식을 추진하고 있습니다.
• 이것은(iOS에서 브라우저 선택에 대한 Apple의 제한과 함께) Apple이 웹의 진행 속도를 늦추고 있다고 주장하면서 Safari를 새로운 IE로 지정하는 입장을 만들었습니다.
• Mozilla는 이 점에서 Google보다 Apple에 더 가깝습니다.

이 기사에서 내 의도는 Google과 식별된 주장, 특히 Project Fugu 리더 Alex Russell의 플랫폼 인접 이론에 있는 주장을 살펴보고 해당 주장에 제시된 증거를 살펴보고 아마도 제 결론에 도달하는 것입니다.

특히 WebUSB(Project Fugu의 특정 논란의 여지가 있는 API)에 대해 자세히 알아보고 이에 대한 보안 주장이 가치가 있는지 확인하고 대안이 나타나는지 확인하려고 합니다.

플랫폼 인접성 이론

앞서 언급한 이론은 다음과 같은 주장을 합니다.

• 소프트웨어는 더 나은 컴퓨팅 버전이기 때문에 웹으로 이동하고 있습니다.
• 웹은 운영 체제에서 추상화된 플랫폼인 메타 플랫폼입니다.
• 메타 플랫폼의 성공은 우리가 대부분의 컴퓨터에서 수행할 것으로 기대하는 작업을 수행하는 데 기반을 두고 있습니다.
• 기본 플랫폼에서 동일한 보안 문제를 무시하면서 보안상의 이유로 웹 메타 플랫폼에 인접 기능을 추가하는 것을 거부하면 결국 웹의 관련성이 점점 줄어들 것입니다.
• Apple과 Mozilla는 바로 그 일을 하고 있습니다. 웹에 인접한 컴퓨팅 기능을 추가하는 것을 거부하여 "웹을 호박색으로 변환"합니다.

나는 열린 웹을 관련성 있게 유지하려는 저자의 열정과 관련이 있으며, 새로운 기능으로 웹을 향상시키는 데 너무 느려지면 관련성이 없어질 것이라는 우려에 공감합니다. 이것은 앱 스토어와 다른 벽으로 둘러싸인 정원을 싫어하기 때문에 증대됩니다. 그러나 사용자로서 나는 반대의 관점에 공감할 수 있습니다. 내가 탐색하는 웹사이트가 어떤 웹사이트를 할 수 있는지 없는지 알 수 없을 때 때때로 어지럽고 플랫폼 제한과 감사가 위안이 된다는 것을 알게 됩니다.

메타 플랫폼

"메타 플랫폼"이라는 용어를 이해하기 위해 저는 이론에서 그 이름을 사용하는 이유를 살펴보았습니다. Java와 Flash는 둘 다 밀레니엄 전환기의 제품입니다.

Java 또는 Flash를 웹과 비교하는 것이 혼란스럽습니다. 이론에서 언급한 바와 같이 Java와 Flash는 모두 당시 브라우저 플러그인을 통해 널리 배포되어 브라우저 플랫폼을 기반으로 하는 대체 런타임이 되었습니다. 오늘날 Java는 주로 서버와 Android 플랫폼의 일부로 사용되며 둘 다 언어를 제외하고는 공통점이 많지 않습니다.

오늘날 서버 측 Java는 아마도 메타 플랫폼일 것이며 node.js는 서버 측 메타 플랫폼의 좋은 예이기도 합니다. API 세트, 플랫폼 간 런타임 및 패키지 에코시스템입니다. 실제로 node.js는 이전에는 플랫폼의 일부로만 가능했던 더 많은 기능을 항상 추가하고 있습니다.

클라이언트 측에서 C++ 기반 크로스 플랫폼 프레임워크인 Qt는 별도의 런타임과 함께 제공되지 않으며 단지 UI 개발을 위한 (좋은!) 크로스 플랫폼 라이브러리일 뿐입니다.

Rust에도 동일하게 적용됩니다. 이것은 언어이자 패키지 관리자이지만 사전 설치된 런타임에 의존하지 않습니다.

클라이언트 측 애플리케이션을 개발하는 다른 방법은 주로 플랫폼에 따라 다르지만 Flutter 및 Xamarin과 같은 일부 플랫폼 간 모바일 솔루션도 포함됩니다.

기능 대 시간

이론의 주요 그래프는 2D 기능 대 시간 축에서 메타 플랫폼의 관련성을 보여줍니다.

위에서 언급한 Qt, Xamarin, Flutter 및 Rust와 같은 플랫폼 간 개발 프레임워크와 node.js 및 Java/Scala와 같은 서버 플랫폼에 대해 이야기할 때 위의 그래프가 어떻게 의미가 있는지 알 수 있습니다.

그러나 위의 모든 것은 웹과 중요한 차이점이 있습니다.

3차원

앞에서 언급한 메타 플랫폼은 실제로 기능 경쟁에서 호스트 OS와 경쟁하고 있지만 웹과 달리 신뢰 와 배포 에 대해 독단적이지 않습니다. 제 생각에는 위 그래프에서 누락된 3차원입니다.

Qt와 Rust는 WebAssembly를 통해 배포되거나, 호스트 OS에 직접 다운로드 및 설치되거나, Cargo 또는 Ubuntu와 같은 Linux 배포와 같은 패키지 관리자를 통해 관리되는 앱을 만드는 좋은 방법입니다. React Native, Flutter 및 Xamarin은 모두 앱 스토어를 통해 배포되는 앱을 만드는 적절한 방법입니다. node.js 및 Java 서비스는 일반적으로 도커 컨테이너, 가상 머신 또는 기타 서버 메커니즘을 통해 배포됩니다.

사용자는 대부분 자신의 콘텐츠를 개발하는 데 무엇이 사용되었는지 알지 못하지만 배포 방식은 어느 정도 알고 있습니다. 사용자는 Xamarin과 node.js가 무엇인지 알지 못하며, Swift 앱이 언젠가 Flutter 앱으로 대체된다면 대부분의 사용자는 이에 대해 신경 쓰지 않을 것이며 이상적으로는 그렇게 해서는 안 됩니다.

그러나 사용자 는 웹을 알고 있습니다. 사용자는 Chrome이나 Firefox에서 "탐색"할 때 "온라인" 상태이며 반드시 신뢰하지 않는 콘텐츠에 액세스할 수 있다는 것을 알고 있습니다. 그들은 소프트웨어를 다운로드하고 설치하는 것이 위험할 수 있으며 IT 관리자가 차단할 수 있다는 것을 알고 있습니다. 사실, 웹 플랫폼에서는 사용자가 현재 "웹을 탐색 중"이라는 사실을 아는 것이 중요합니다. 그렇기 때문에 예를 들어 전체 화면 모드로 전환하면 사용자에게 명확한 프롬프트와 복귀 방법에 대한 지침이 표시됩니다.

웹은 투명하지 않지만 호스트 OS와 명확하게 분리되어 있기 때문에 성공한 것입니다. 임의의 웹사이트가 하드 드라이브의 파일을 읽지 못하도록 하는 브라우저를 신뢰할 수 없다면 아마 어떤 웹사이트에도 가지 않을 것입니다.

또한 사용자는 컴퓨터 소프트웨어가 "Windows"인지 "Mac"인지, 휴대전화가 Android인지 iOS 기반인지 여부, 현재 앱 을 사용 중인지 여부(iOS 또는 Android의 경우 및 Mac OS의 경우 어느 정도)를 알고 있습니다. . OS 와 배포 모델 은 일반적으로 사용자에게 알려져 있습니다. 사용자는 OS와 웹이 서로 다른 작업을 수행하고 서로 다른 신뢰 수준을 신뢰합니다.

따라서 웹은 고유한 배포 모델을 고려하지 않고는 플랫폼 간 개발 프레임워크와 비교할 수 없습니다.

반면에 웹 기술은 Electron 및 Cordova와 같은 프레임워크와 함께 플랫폼 간 개발에도 사용됩니다. 그러나 그것들은 정확히 "웹"이 아닙니다. Java 또는 node.js와 비교할 때 "웹"이라는 용어는 "웹 기술"로 대체되어야 합니다. 그리고 이러한 방식으로 사용되는 "웹 기술"이 반드시 표준 기반이거나 여러 브라우저에서 작동할 필요는 없습니다. Fugu API에 대한 대화는 Electron 및 Cordova와 다소 관련이 있습니다.

네이티브 앱

웹 플랫폼에 기능을 추가할 때 3차원인 신뢰 및 배포 모델을 무시하거나 가볍게 생각할 수 없습니다. 저자가 "새로운 기능으로 인한 위험에 대한 Apple과 Mozilla의 입장은 수용된 기존 기본 플랫폼 위험에 의해 거짓" 이라고 주장할 때 그는 웹과 기본 플랫폼을 신뢰와 관련하여 같은 차원에 놓고 있습니다.

물론 기본 앱에는 고유한 보안 문제와 과제가 있습니다. 그러나 이것이 여기와 같이 더 많은 웹 기능을 찬성하는 주장인지 모르겠습니다. 이것은 오류입니다. 결론은 기본 앱의 보안 문제를 수정해야 하며, 웹 앱은 OS 기능과 관련성 추격 게임에 있기 때문에 보안을 완화하는 것이 아닙니다.

네이티브와 웹은 3차원의 신뢰와 유통 모델을 고려하지 않고는 기능 면에서 비교할 수 없습니다.

앱 스토어 제한 사항

이론상 기본 앱에 대한 비판 중 하나는 iOS에서 브라우저 엔진 선택이 부족하다는 것입니다. 이것은 Apple에 대한 비판의 일반적인 스레드이지만, 여기에는 하나 이상의 관점이 있습니다.

비판은 특히 Apple의 앱 스토어 검토 지침의 항목 2.5.6에 관한 것입니다.

"웹을 탐색하는 앱은 적절한 WebKit 프레임워크와 WebKit JavaScript를 사용해야 합니다."

이것은 반경쟁적인 것처럼 보일 수 있으며 iOS가 얼마나 제한적인지에 대해 저만의 유보가 있습니다. 그러나 항목 2.5.6은 나머지 앱 스토어 리뷰 지침의 맥락 없이 읽을 수 없습니다(예: 항목 2.3.12:

"앱은 '새로운 기능' 텍스트에서 새로운 기능과 제품 변경 사항을 명확하게 설명해야 합니다."

앱이 장치 액세스 권한을 받은 다음 외부의 모든 웹 사이트에서 코드를 실행할 수 있는 자체 프레임워크를 포함할 수 있다면 앱 스토어 검토 지침의 해당 항목은 의미가 없습니다. 앱과 달리 웹 사이트는 모든 개정판에서 기능과 제품 변경 사항을 설명할 필요가 없습니다.

이것은 브라우저가 아직 표준으로 간주되지 않는 프로젝트 Fugu의 기능과 같은 실험적 기능을 제공할 때 더 큰 문제가 됩니다. 누가 브라우저를 정의합니까? 앱이 웹 프레임워크를 제공하도록 허용함으로써 앱 스토어는 본질적으로 "앱"이 감사되지 않은 코드를 실행하거나 제품을 완전히 변경하도록 허용하여 스토어의 검토 프로세스를 우회합니다.

웹 사이트와 앱의 사용자로서 둘 다 컴퓨팅 세계에서 공간이 있다고 생각하지만 가능한 한 많이 웹으로 이동할 수 있기를 바랍니다. 그러나 웹 표준의 현재 상태와 Bluetooth 및 USB와 같은 것에 대한 신뢰와 샌드박싱의 차원이 해결되지 않는 방법을 고려할 때 앱이 웹에서 콘텐츠를 자유롭게 실행하도록 허용하는 것이 사용자에게 얼마나 유익한지 모르겠습니다. .

Appiness의 추구

다른 관련 블로그 게시물에서 동일한 작성자가 네이티브 앱에 대해 이야기할 때 이 중 일부를 언급합니다.

"'앱'이 된다는 것은 단순히 임의적이고 변경 가능한 OS 규칙 집합을 충족하는 것입니다."

나는 "앱"의 정의가 임의적이며 그 정의가 앱 스토어 정책을 정의하는 사람에 달려 있다는 개념에 동의합니다. 그러나 오늘날 브라우저에서도 마찬가지입니다. 웹 애플리케이션이 기본적으로 안전하다는 게시물의 주장도 다소 자의적입니다. "브라우저란 무엇인가"라는 모래에 누가 선을 그을까요? 브라우저가 내장된 Facebook 앱은 "브라우저"입니까?

앱의 정의는 자의적이지만 중요합니다. 저수준 기능을 사용하는 애플리케이션의 모든 개정판은 내가 신뢰할 수 있는 누군가 에 의해 감사된다는 사실이, 그 누군가가 임의적일지라도, 앱을 있는 그대로 만듭니다. 그 누군가 가 내가 지불한 하드웨어의 제조업체라면 훨씬 덜 임의적입니다. 내 컴퓨터를 구입한 회사는 해당 컴퓨터에 대해 더 낮은 기능을 가진 감사 소프트웨어입니다.

모든 것이 브라우저가 될 수 있습니다

Apple 앱 스토어가 본질적으로 하는 일인 "브라우저란 무엇인가?"라는 선을 긋지 않고도 모든 앱은 자체 웹 엔진을 제공하고 사용자가 인앱 브라우저를 사용하여 모든 웹사이트를 탐색하도록 유인하고 모든 추적 코드를 추가할 수 있습니다. 앱과 웹사이트 간의 3차원적 차이를 무너뜨리고자 합니다.

iOS에서 앱을 사용할 때 현재 내 작업이 Apple과 확인된 앱 제조업체의 두 플레이어에게 노출되어 있다는 것을 알고 있습니다. Safari 또는 Safari WebView에서 웹 사이트를 사용할 때 내 작업이 현재 보고 있는 웹 사이트의 최상위 도메인 소유자와 Apple에 노출됩니다. 알 수 없는 엔진이 있는 인앱 브라우저를 사용하면 앱 제조업체인 Apple과 최상위 도메인 소유자에게 노출됩니다. 이렇게 하면 앱 소유자가 외국 웹사이트에서 내 모든 클릭을 추적하는 것과 같이 피할 수 있는 동일 출처 위반이 발생할 수 있습니다.

"Only WebKit"이라는 단어가 너무 가혹하다는 데 동의합니다. 사용자 브라우징을 추적하기 위한 백도어를 생성하지 않는 브라우저의 대체 정의는 무엇입니까?

애플에 대한 다른 비판

이 이론은 Apple의 기능 구현 거부가 개인 정보 보호/보안 문제에만 국한되지 않는다고 주장합니다. 여기에는 Safari가 아닌 Chrome에서 구현된 많은 기능이 실제로 표시되는 링크가 포함되어 있습니다. 그러나 아래로 스크롤하면 Chrome이 아닌 Safari에서 구현된 상당한 양의 다른 기능도 나열됩니다.

이 두 브라우저 프로젝트는 우선 순위가 다르지만 "축소하면 게임이 명확해집니다"라는 범주의 진술과 웹을 호박색으로 만들려는 Apple에 대한 가혹한 비판과는 거리가 있습니다.

또한 it's hard라는 제목의 링크는 보안/개인 정보 보호 문제가 충족되면 기능을 구현할 것이라는 Apple의 진술로 이어지기를 원하지 않습니다 . 이 링크를 해당 제목과 함께 넣는 것은 오해의 소지가 있다고 생각합니다.

Google이 기능 구현 및 웹 발전에 대해 Apple보다 훨씬 더 낙관적이라는 보다 균형 잡힌 진술에 동의합니다.

권한 프롬프트

Google은 신뢰할 수 있는 웹 활동의 경우와 같이 때때로 큰 성공을 거두면서 사용자, 개발자 및 플랫폼 간의 신뢰를 중개하는 새로운 방법을 개발하면서 3차원에서 오랫동안 혁신적인 방법을 사용합니다.

그러나 여전히 장치 API와 관련된 3차원 작업의 대부분은 권한 프롬프트에 초점을 맞추고 더 무섭게 만들거나 타임 박스 권한 부여 및 차단 목록 도메인과 같은 작업에 중점을 둡니다.

이 예에서 종종 볼 수 있는 "무서운" 프롬프트는 사람들이 잠재적으로 악의적으로 보이는 페이지로 이동하지 않도록 하기 위한 것처럼 보입니다. 너무 노골적이기 때문에 이러한 경고는 개발자가 더 안전한 API로 이동하고 인증서를 갱신하도록 권장합니다.

장치 액세스 기능의 경우 웹 개발자가 사용할 수 있는 수정 없이 참여를 방해하고 책임을 사용자에게 전가하기보다는 참여를 권장하고 참여가 안전한지 확인하는 프롬프트를 제공할 수 있기를 바랍니다. 나중에 자세히 설명합니다.

나는 Mozilla와 Apple이 "구현을 거부"하기보다는 최소한 그 분야에서 혁신을 시도해야 한다는 주장에 동의합니다. 하지만 아마도 그들은? 예를 들어, Apple의 isLoggedIn은 미래의 장치 API가 기반으로 할 수 있는 3차원에서 흥미롭고 관련성 있는 제안이라고 생각합니다. 예를 들어, 현재 웹사이트가 사용자.

WebUSB

다음 섹션에서는 WebUSB에 대해 자세히 살펴보고 이것이 무엇을 허용하는지, 3차원에서 어떻게 처리되는지 확인하겠습니다. 신뢰 및 배포 모델이란 무엇입니까? 충분합니까? 대안은 무엇입니까?

전제

WebUSB API는 차단 목록에 없는 장치 클래스에 대한 USB 프로토콜에 대한 전체 액세스를 허용합니다.

Arduino 보드에 연결하거나 Android 전화를 디버깅하는 것과 같은 강력한 작업을 수행할 수 있습니다.

이 API가 이전에 달성하는 데 매우 비쌌던 일을 달성하는 데 어떻게 도움이 되는지에 대한 Suz Hinton의 비디오를 보는 것은 흥미진진합니다.

예를 들어 교육용 하드웨어/소프트웨어 프로젝트에서 플랫폼이 더 개방적이고 빠르게 반복할 수 있는 방법을 찾았으면 합니다.

재미있는 느낌

그러나 여전히 WebUSB가 가능하게 하는 것과 USB의 기존 보안 문제를 볼 때 우스꽝스러운 느낌이 듭니다.

USB는 권한 프롬프트가 있어도 웹에 노출된 프로토콜로서 너무 강력하게 느껴집니다.

그래서 더 연구했습니다.

Mozilla의 공식 견해

나는 David Baron이 Mozilla의 공식 표준 입장에서 Mozilla가 WebUSB를 거부한 이유에 대해 말한 것을 읽는 것으로 시작했습니다.

"많은 USB 장치가 USB 프로토콜을 통한 잠재적으로 악의적인 상호 작용을 처리하도록 설계되지 않았고 이러한 장치가 연결된 컴퓨터에 상당한 영향을 미칠 수 있기 때문에 USB 장치를 웹에 노출시키는 보안 위험도 크다고 생각합니다. 의미 있는 정보에 입각한 동의를 얻기 위해 사용자를 노출시킬 위험이 있거나 최종 사용자에게 적절하게 설명하는 것까지 광범위합니다."

현재 권한 프롬프트

이 게시물을 게시할 때 Chrome의 WebUSB 권한 프롬프트는 다음과 같습니다.

특정 도메인 Foo가 특정 장치 Bar에 연결하려고 합니다. 무엇을 하려면? 어떻게 확실히 알 수 있습니까?

프린터, 카메라, 마이크, GPS 또는 심박수 모니터링과 같이 더 많이 포함된 WebBluetooth GATT 프로필에 대한 액세스 권한을 부여할 때 이 질문은 비교적 명확하며 장치 보다는 콘텐츠 또는 작업 에 중점을 둡니다. 주변기기에서 내가 원하는 정보 또는 주변기기로 수행하려는 작업에 대한 명확한 이해가 있으며 사용자 에이전트는 이 특정 작업이 처리되도록 중재하고 확인합니다.

USB는 일반

특수 API를 통해 노출되는 위에서 언급한 장치와 달리 USB는 콘텐츠에 따라 다릅니다. 사양 서문에서 언급했듯이 WebUSB는 더 나아가 키보드나 외부 드라이브와 같이 잘 알려진 장치 등급이 아니라 알려지지 않았거나 아직 발명되지 않은 장치 유형을 위해 의도적으로 설계되었습니다.

따라서 프린터, GPS 및 카메라의 경우와 달리 WebUSB가 있는 장치에 연결할 수 있는 페이지 권한을 부여하면 콘텐츠 영역에서 무엇을 허용하는지 사용자에게 알려주는 프롬프트가 생각나지 않습니다. 특정 장치에 액세스하는 코드를 감사합니다.

Yubikey 사고 및 완화

얼마 전의 좋은 예는 Chrome의 WebUSB가 USB 전원 인증 장치의 데이터를 피싱하는 데 사용된 Yubikey 사건입니다.

이것은 보안 문제가 해결되었다고 하기 때문에 특정 기기 및 특정 클래스 집합을 차단하는 것을 포함하여 Chrome 67에서 Chrome의 완화 노력에 대해 자세히 살펴보고 싶었습니다.

클래스/장치 차단 목록

따라서 현재 매우 일반적인 권한 프롬프트에 추가하여 야생에서 발생한 WebUSB 악용에 대한 Chrome의 실제 방어는 특정 장치 및 장치 클래스를 차단하는 것이었습니다.

이것은 새로운 기술이나 실험을 위한 간단한 솔루션일 수 있지만 WebUSB가 대중화되면 달성하기가 점점 더 어려워질 것입니다.

WebUSB를 통해 교육 기기를 혁신하는 사람들이 어려운 상황에 처할까봐 두렵습니다. 프로토타입을 완성할 때쯤이면 브라우저 버전과 아무 관련이 없는 보안 문제를 기반으로 하는 브라우저 버전과 함께만 업데이트되는 끊임없이 변화하는 비표준 차단 목록 세트에 직면할 수 있습니다.

이 문제를 해결하지 않고 이 API를 표준화하는 것은 결국 API에 의존하는 개발자에게 역효과가 날 것이라고 생각합니다. 예를 들어, 누군가가 동작 감지기용 WebUSB 응용 프로그램을 개발하는 데 주기를 보낼 수 있지만 보안상의 이유나 OS가 동작 감지기를 처리하기로 결정하여 동작 감지기가 차단된 클래스가 되어 전체 WebUSB 작업이 쓰레기.

보안 대 기능

플랫폼 인접성 이론은 어떤 면에서 기능과 보안을 제로섬 게임으로 간주하며 보안 및 개인 정보 보호 문제에 대해 너무 보수적이면 플랫폼이 관련성을 잃게 될 것이라고 생각합니다.

아두이노를 예로 들어보자. Arduino 통신은 WebUSB로 가능하며 주요 사용 사례입니다. Arduino 장치를 개발하는 사람은 이제 사이트가 WebUSB를 사용하여 장치에 액세스하려고 시도하는 새로운 위협 시나리오를 고려해야 합니다(일부 사용자 권한이 있음). 사양에 따라 이 장치 제조업체는 이제 "서명된 펌웨어만 수락하도록 장치를 설계"해야 합니다. 이것은 펌웨어 개발자에게 부담을 더하고 개발 비용을 증가시킬 수 있지만 사양의 전체 목적은 그 반대입니다.

WebUSB가 다른 주변기기와 다른 점

브라우저에서는 사용자 상호 작용과 합성 상호 작용(웹 페이지에서 인스턴스화한 상호 작용) 사이에 분명한 차이가 있습니다.

예를 들어, 웹 페이지는 링크를 클릭하거나 CPU/디스플레이를 깨우기 위해 스스로 결정할 수 없습니다. 그러나 외부 장치는 가능합니다. 예를 들어, 마우스 장치는 사용자를 대신하여 링크를 클릭할 수 있고 거의 모든 USB 장치는 OS에 따라 CPU를 깨울 수 있습니다.

따라서 현재 WebUSB 사양에서도 장치는 몇 가지 인터페이스를 구현하도록 선택할 수 있습니다. 예를 들어 adb용 디버그 및 포인터 입력용 HID, ADB를 이용하는 악성 코드 사용, 키로거가 되어 사용자 대신 웹사이트 탐색 악용 가능한 펌웨어 플래싱 메커니즘.

해당 장치를 차단 목록에 추가하는 것은 ADB 또는 기타 허용된 형태의 플래싱을 사용하여 손상된 펌웨어가 있는 장치에 대해 너무 늦을 것이며, 장치 제조업체는 장치와 관련된 보안 수정을 위해 브라우저 버전에 전보다 훨씬 더 의존하게 만들 것입니다.

정보에 입각한 동의 및 콘텐츠

사전 동의 및 USB의 문제는 이전에 언급한 바와 같이 USB(특히 일반 WebUSB 사용 사례에서)가 특정 콘텐츠가 아니라는 것입니다. 사용자는 프린터가 무엇인지, 카메라가 무엇인지 알고 있지만 대부분의 사용자에게 "USB"는 케이블(또는 소켓)에 불과합니다. USB가 프로토콜이며 웹사이트 간에 이를 가능하게 하는 것이 무엇인지 아는 사용자는 거의 없습니다. 및 장치 수단.

한 가지 제안은 "이 웹 페이지가 장치를 인계하도록 허용"과 같은 "무서운" 프롬프트를 표시하는 것이었습니다(이는 겉보기에 무해해 보이는 "연결을 원함"을 개선한 것임).

그러나 프롬프트가 나오는 것처럼 두려운 것은 브라우저가 친밀하게 알지 못하는 USB 주변 장치에 대한 원시 액세스로 수행할 수 있는 가능한 일의 폭을 설명할 수 없으며, 그렇다면 제정신이 아닌 사용자는 "예"를 클릭하지 않을 것입니다. ”, 버그가 없다고 완전히 신뢰하는 장치와 악의적이지 않은 최신 상태라고 진정으로 신뢰하는 웹 사이트가 아니라면 말입니다.

가능한 프롬프트는 "이 웹 페이지가 잠재적으로 컴퓨터를 인계할 수 있도록 허용"입니다. 나는 이와 같은 무서운 프롬프트가 WebUSB 커뮤니티에 도움이 될 것이라고 생각하지 않으며 이러한 대화 상자에 대한 지속적인 변경은 커뮤니티를 혼란스럽게 만들 것입니다.

프로토타이핑 대 제품

나는 이것에 대한 가능한 예외를 볼 수 있습니다. WebUSB 및 다른 프로젝트 Fugu API의 전제가 제품 등급 장치가 아닌 프로토타이핑을 지원하는 것이라면 모든 것을 포괄하는 일반 프롬프트가 의미가 있을 수 있습니다.

하지만 이를 실행 가능하게 하려면 다음이 이루어져야 한다고 생각합니다.

1. 프로토타이핑에 대한 기대치를 설정하는 사양의 언어를 사용하십시오.
2. 사용자가 브라우저 설정에서 수동으로 활성화하도록 하는 것과 같이 일부 옵트인 제스처 후에만 이러한 API를 사용할 수 있도록 합니다.
3. 유효하지 않은 SSL 인증서에 대한 것과 같은 "무서운" 권한 프롬프트가 있습니다.

위의 항목이 없으면 이러한 API가 프로토타입이 아닌 실제 제품을 위한 것이라고 생각하고 피드백이 유지됩니다.

대안 제안

원래 블로그 게시물에서 내가 동의하는 부분 중 하나는 "아니오"라고 말하는 것만으로는 충분하지 않다는 것입니다. 웹 세계의 주요 플레이어는 유해하다는 이유로 특정 API를 거부하는 사람들도 공격을 하고 이러한 기능이 중요한 방식을 제안해야 합니다. 사용자와 개발자에게 안전하게 노출될 수 있습니다. 나는 주요 선수를 대표하지 않지만 겸손하게 가려고 합니다.

나는 이것에 대한 답이 신뢰와 관계의 3차원에 있다고 믿으며, 그것은 허가 프롬프트와 차단 목록의 틀을 벗어납니다.

간단하고 검증된 프롬프트

내가 만들려는 주요 사례는 프롬프트가 주변 장치가 아니라 콘텐츠 또는 작업에 대한 것이어야 하며, 정보에 입각한 동의는 확인된 특정 매개변수 집합이 있는 특정 간단한 작업에 대해 부여될 수 있다는 것입니다. 장치 "인계" 또는 "연결"과 같은 일반적인 작업.

3D 프린터의 예

WebUSB 사양에서는 3D 프린터를 예로 들어 놓았으니 여기서는 사용하겠습니다.

3D 프린터용 WebUSB 응용 프로그램을 개발할 때 브라우저/OS 프롬프트에서 AutoDesk 3ds-mask가 CreatBot 3D 프린터로 모델을 인쇄할 수 있도록 허용하시겠습니까? , 미세 조정, 두께 및 출력 치수와 같은 일부 인쇄 매개변수가 포함된 브라우저/OS 대화 상자가 표시되고 인쇄될 항목의 미리보기가 표시됩니다. 이러한 모든 매개변수는 드라이브 바이 웹 페이지가 아닌 신뢰할 수 있는 사용자 에이전트에서 확인해야 합니다.

현재 브라우저는 프린터를 알지 못하며 프롬프트에서 일부 클레임만 확인할 수 있습니다.

• 요청하는 도메인에는 AutoDesk에 등록된 인증서가 있으므로 이것이 AutoDesk Inc라는 것이 어느 정도 확실합니다.
• 요청된 주변 장치는 스스로를 "CreatBot 3d 프린터"라고 부릅니다.
• 이 장치, 장치 클래스 및 도메인은 브라우저의 차단 목록에서 찾을 수 없습니다.
• 사용자는 일반적인 질문에 "예" 또는 "아니오"로 응답했습니다.

그러나 위의 세부 정보가 포함된 진실한 프롬프트와 대화 상자를 표시하려면 브라우저도 다음을 확인해야 합니다.

• 권한이 부여되면 수행되는 작업은 3D 모델을 인쇄하는 것뿐입니다.
• 선택한 매개변수(세련/두께/치수 등)가 적용됩니다.
• 인쇄될 내용의 확인된 미리보기가 사용자에게 표시되었습니다.
• 특정 민감한 경우, 이것이 사실 AutoDesk인지에 대한 추가 확인, 아마도 취소 가능한 단기 토큰과 같은 것일 수 있습니다.

위의 사항을 확인하지 않고 3D 프린터에 "연결" 또는 "인계"할 수 있는 권한이 부여된 웹 사이트는 버그(또는 종속성 중 하나의 악성 코드)로 인해 거대한 3D 모델 인쇄를 시작할 수 있습니다.

또한 상상한 완전한 웹 3D 인쇄 기능은 WebUSB가 제공할 수 있는 것보다 훨씬 더 많은 일을 할 수 있습니다(예: 다양한 인쇄 요청 스풀링 및 대기열). 브라우저 창이 닫히면 어떻게 처리됩니까? 가능한 모든 WebUSB 주변기기 사용 사례를 조사하지는 않았지만 콘텐츠/액션 관점에서 볼 때 대부분은 USB 액세스 이상을 필요로 할 것이라고 추측합니다.

위의 이유로 WebUSB를 3D 인쇄에 사용하는 것은 아마도 해킹되고 수명이 짧을 것이며 이에 의존하는 개발자는 어느 시점에서 프린터에 대한 "실제" 드라이버를 제공해야 할 것입니다. 예를 들어 OS 공급업체가 3D 프린터에 대한 기본 제공 지원을 추가하기로 결정하면 WebUSB와 함께 해당 프린터를 사용하는 모든 사이트의 작동이 중지됩니다.

제안: 운전자 감사 기관

따라서 "주변 장치 인계"와 같은 포괄적인 권한은 문제가 있으며 본격적인 매개 변수 대화 상자를 표시하고 결과가 존중될 것인지 확인하기 위한 정보가 충분하지 않으며 전송하고 싶지 않습니다. 웹에서 임의의 실행 파일을 다운로드하기 위해 안전하지 않은 여행을 하는 사용자.

그러나 내부적으로 WebUSB API를 사용하고 다음을 수행하는 감사 된 코드 조각, 드라이버가 있다면 어떻게 될까요?

• "인쇄" 명령을 구현했습니다.
• 페이지 외부 인쇄 대화 상자를 표시했습니다.
• 특정 USB 장치 세트에 연결됨;
• 페이지가 백그라운드에 있을 때(예: 서비스 워커에 있을 때) 또는 브라우저가 닫힌 경우에도 일부 작업을 수행했습니다.

이와 같은 드라이버에 대한 감사를 통해 드라이버가 수행하는 작업이 "인쇄"에 해당하는지, 매개변수를 준수하는지, 인쇄 미리보기를 표시하는지 확인할 수 있습니다.

나는 이것을 인증 기관과 유사하다고 생각합니다. 이는 브라우저 공급업체와 다소 단절된 웹 생태계의 중요한 부분입니다.

드라이버 신디케이션

브라우저/OS 공급업체가 자체적으로 드라이버를 감사하도록 선택할 수 있지만 드라이버는 Google/Apple에서 감사할 필요가 없습니다. SSL 인증 기관처럼 작동할 수 있습니다. 발급자는 매우 신뢰할 수 있는 조직입니다. 예를 들어 특정 주변 장치의 제조업체 또는 많은 드라이버를 인증하는 조직 또는 Arduino와 같은 플랫폼이 있습니다. (나는 Let's Encrypt와 유사한 조직이 등장한다고 상상합니다.)

사용자에게 다음과 같이 말하는 것으로 충분할 수 있습니다. "Arduino는 이 코드가 이 펌웨어로 Uno를 플래시할 것이라고 믿습니다"(펌웨어 미리보기 포함).

주의 사항

이것은 물론 잠재적인 문제가 없는 것은 아닙니다.

• 드라이버 자체는 버그가 있거나 악의적일 수 있습니다. 그러나 최소한 감사를 받았습니다.
• 그것은 덜 "webby"이고 추가적인 개발 부담을 생성합니다.
• 그것은 오늘날 존재하지 않으며 브라우저 엔진의 내부 혁신으로 해결할 수 없습니다.

기타 대안

다른 대안은 브라우저 간 웹 확장 API를 어떻게든 표준화 및 개선하고 Chrome 웹 스토어와 같은 기존 브라우저 추가 기능 저장소를 사용자 요청과 주변 장치 액세스 사이를 중재하는 일종의 드라이버 감사 기관으로 만드는 것입니다.

의견 요약

개방형 웹의 기능을 향상시켜 관련성을 유지하려는 저자, Google 및 파트너의 과감한 노력은 영감을 줍니다.

세부 사항을 살펴보니 Apple과 Mozilla의 웹에 대한 보다 보수적인 관점과 새로운 장치 기능에 대한 방어적인 접근 방식이 기술적인 장점이 있다고 봅니다. 개방형 하드웨어 기능에 대한 사전 동의가 있는 핵심 문제는 아직 해결되지 않았습니다.

Apple은 장치 기능을 활성화할 수 있는 새로운 방법을 찾기 위해 논의에서 더 앞으로 나올 수 있지만, 이것은 반경쟁적 관점이 아니라 수십 년 동안 Apple의 정체성의 일부였던 관점인 컴퓨팅에 대한 다른 관점에서 나온 것이라고 생각합니다.

프로젝트 Fugu, 특히 WebUSB에서 다소 개방적인 하드웨어 기능과 같은 것을 지원하기 위해 웹의 신뢰 모델 은 인증 기관 및 패키지 배포.

SmashingMag에 대한 추가 정보:

• 웹사이트 성능 개선이 지구를 구하는 데 도움이 되는 방법
• 광고 없는 웹을 향하여: 온라인 경제의 다양화
• 훌륭한 코드를 작성하는 것 이상의 미래가 있습니까?
• 웹 디자인에서 윤리 사용하기