Accessing User Data and Resources

원본 참고

유저의 프라이버시는 매우매우 중요한 문제입니다. 사람들이 당신의 app을 믿을 수 있도록, 프라이버시 관련 data와 resource를 요구하고서는 이걸 어떻게 쓰는지 투명하게 해야 합니다.

예로, 유저에게 access를 위한 permission을 요청하는 것이 있습니다

• 개인 정보 : 지역, 건강, 금융, 연락처, 기타 개인적인 식별 정보 등

• User-generated content : 이메일, 메시지, 캘린더정보, 사진, Apple Music에서의 활동기록 등

• 보호된 리소스 : 블루투스 기기, Wi-Fi 연결, 네트워크 등

• 장치 기능 : 카메라, 마이크 등

⚠️ 중요
iOS 14.5와 iPadOS 14.5 부터는 유저를 추적하거나 장치의 advertising identifier에 접근하기 위해 유저 permission을 요청하려면 AppTrackingTransparency framework을 사용해야 합니다

app을 새로 내거나 업데이트할 때, App store에 당신이 수집하는 프라이버시 관련 관행들과 데이터에 대해 자세하게 제공해야 합니다. 사람들은 이 정보를 보고 당신의 app을 다운받기 전에 결정하게 됩니다

🐰 Access Permission 요청하기

당신이 유저의 data나 보호된 리소스에 접근하려면 먼저, 유저의 permission을 얻어야 합니다

1. app에서 access가 명확히 필요할 때만 요청하라

사람들은 기본적으로 개인 정보를 요청하고 장치에 접근하려고 하면 의심합니다. (특히, 어디에 쓰일지 명확하지 않을 때)

이상적으로는, 유저가 당신의 app을 쓰다가 access가 필요한 feature를 사용할 때까지 permission 요청을 기다려야 합니다.

이런 방법도 있습니다
유저 위치 요청을 위해선, location 버튼을 사용하면 교묘하게(?) 유저의 위치 정보를 공유받을 수 있습니다

2. app 구동에 access가 필수적이라면 launch에서 요청하라

사람들은 app에서 자신들의 정보를 왜 필요로 하는지만 명확하다면 launch-time에 요청이 들어오는 것을 그렇게 싫어하진 않을 것입니다

만약 당신이 launch 하자마자 app tracking을 하길 원한다면, tracking을 걸기 전에 시스템이 제공하는 alert를 보여줘야 합니다

시스템은 개인정보에 접근하려는 당신의 요청을 볼 수 있도록 표준 alert를 제공합니다.
당신이 app에서 그 정보들이 왜 필요한지 명세하면, 시스템이 이걸 alert에서 보여줍니다. 사람들은 이것을 보고

3. 유저 data를 어떻게 쓸건지 명확하게 제시하라

app을 켜면 app 이름이 먼저 나오고, permission 승인/거부 버튼이 나오기 전에 usage description을 보여주는 표준 alert가 나옵니다

직설적이고 자세하며 이해하기 쉬운 말로, 짧고 완전한 문장을 목표하라

첫 글자는 대문자로 해서 수동적인 표현을 피하고 끝에 마침표를 찍어라

4. Location 버튼을 사용하라

iOS 15부터는 Core Location이 버튼을 제공합니다. 그래서 유저들이 자신들의 위치에 대한 "임시 권한"을 줄 수 있습니다
비록 버튼의 외형은 app의 UI에 따라 달라질 수 있습니다만, 이것은 언제나 이게 location 공유하는 것임을 즉시 알 수 있게 전달합니다

Location 버튼은 app에게 device location 정보 취득을 위한 임시 권한을 부여합니다. app에 권한 상황(authorization status?)이 없다면 Location 버튼을 탭하는 것이 표준 alert에서 "한 번만 허용"을 고르는 것과 같은 효과를 줍니다
만약 유저가 이전에 "이 앱에서 항상 허용"을 골랐다면 이미 허용 상태이므로 Location 버튼을 누른다고 권한 상황이 바뀌지 않습니다.

유저가 처음 app을 열어서 Location 버튼을 tap하면, 시스템이 표준 alert를 띄웁니다. 이 alert에는 Location 버튼이 임시권한만을 허용함을 설명하고, 위치 정보 공유가 시작할 때 나타날 Location indicator를 상기시켜 줍니다

사람들이 버튼의 action을 확인한 후, app에게 device 위치에 대한 임시권한을 주고자하면 버튼을 tap하게 됩니다. 비록 이 임시권한은 app이 종료되면 만료되지만, 다음에 또 Location 버튼을 만나더라도 이걸 누르면 어떤 action이 발생하는지는 이미 이해하고 있을 것입니다

5. app 내 특정 feature를 위해 위치 정보 임시공유하려면 Location 버튼을 고려하라

예로, 당신의 app은 유저가 메시지에 위치 정보를 넣거나, 상점을 찾는 등의 상황을 도울지도 모릅니다
만약, 유저가 app에게 "한번만 허용"을 많이 준다는 사실을 당신이 알고 있다면, alert없이 위치를 공유할 수 있도록 Location 버튼을 고려해볼만 합니다

6. UI와 어울리기 위해 customizing하는 것을 고려하라

• app의 기능과 잘 맞는 시스템 제공 title을 선택하라
  예) "현재 위치" or "나의 현재 위치 공유하기"

• 속이 채워져 있거나 테두리가 그려진 glyph를 선택하라

• 배경색과 title, glyph 색을 골라라

• 버튼의 코너 둥글기 정도를 정하라

유저들이 Location 버튼을 인식하고 신뢰할 수 있도록 다른 시각적 요소들은 customize 할 수 없다.
이 시스템은 또한, Location 버튼이 읽기 쉽도록 contrast가 낮은 색 조합을 쓰거나 반투명도를 너무 높이지 않도록 개발자에게 경고합니다.
이런 문제들을 교정하는 것에 더해, 개발자는 버튼 안에 들어갈 text도 잘 작성할 책임이 있습니다. 예로, 버튼 text는 어떤 accessibility text size에서든, 어떤 언어로 쓰이든 짤리지 않고 버튼 안에 잘 들어가야 합니다

⚠️ 중요
만약 시스템이 당신이 customizing한 Location 버튼에서 일관된 문제를 발견한다면, 유저가 tap을 하더라도 당신의 app에게 위치권한을 주지 않을 것입니다.
비록 그 버튼이 다른 action들은 수행할 수 있을지라도, Location 버튼이 제대로 동작하지 않으면 유저들은 당신의 app 전체에 대한 신뢰를 잃을지도 모릅니다.

🐯 ShazamKit App에서 마이크 사용하기

ShazamKit은 음성인식 프레임워크입니다
iOS 15부터 ShazamKit을 이용하여 아래 feature들을 가능케 할 수 있습니다

• 현재 흘러나오는 음악에 대응되는 graphics를 제공하여 UX를 강화

• 청각 장애인을 위해 오디오로부터 실시간 자막이나 수화를 만들어 낼 수 있음

• app 내 경험을 가상 content와 동기화(무슨 말..?)

만약 app이 오디오 샘플을 얻기 위해 device의 마이크가 필요하다면, 접근권한을 요청해야 합니다.
다른 종류의 권한 요청과 마찬가지로, 당신이 왜 이 권한을 요청하는지 유저가 쉽게 이해할 수 있도록 도와야 합니다

ShazamKit을 enable하는 feature를 위해 마이크 권한을 얻었다면, 아래 가이드라인을 따라야 합니다

1. 가능한 빨리 녹음을 멈춰라

유저들은 음성인식을 위해 app에게 녹음 권한을 허용할 때, 마이크가 계속 켜져있길 원하지 않습니다.
프라이버시 보호를 위해, 필요한 정도의 샘플을 얻었다면 빨리 녹음을 중지시켜야 합니다

2. app이 인식한 노래를 iCloud에 저장하도록 opt-in 하게하라

만약 당신의 app이 인식한 노래를 iCloud에 저장할 수 있다면, 이 action을 처음 승인하기 위한 방법을 제공하십시오. 비록 Music 인식 제어 app과 Shazam app 모두가 인식된 노래의 소스로써 당신의 app을 보여주지만(?), 사람들은 iCloud에 content를 저장하는 app을 제어할 수 있음에 고마워합니다(?)

Even though both the Music Recognition control and the Shazam app show your app as the source of the recognized song, people appreciate having control over which apps can store content in their library.

🐼 alert 띄우기 전에 custom 메시지 보여주기

이상적으로는, 유저가 문맥을 다 파악하여 당신의 app이 왜 권한을 요청하는지 이미 알고 있어야 한다 (하지만 실제로는...음..)
만약 추가적인 detail을 제공하는게 필수적이라면, alert가 뜨기 전에 custom 메시지를 보여주는 방법이 있다

시스템 alert를 띄우는 것이 custom 메시지 screen에서 할 수 있는 유일한 작업이게 하라

유저들은 alert 전에 띄우는 메시지를 delaying 전략으로 오해할 수 있습니다. 그러므로 이 메시지를 빠르게 치우고 alert를 볼 수 있게끔 만들어야 합니다

만약 프라이버시 권한요청 전에 custom screen을 띄운다면, 이 screen에는 "alert를 띄운다"는 딱 하나의 action만 가능하게 해야 합니다
버튼에 "Continue"나 "Next"같은 title은 괜찮은데 실제론 그렇지 않으면서 권한선택을 한 것처럼 오해를 불러 일으키는 "Allow"같은 title은 사용하면 안된다

🐶 Tracking 요청 분명하게 말하기

app tracking은 민감한 주제입니다. 어떤 경우에는, tracking이 왜 필요한지, 어떤 이득이 있는지 명확하게 묘사하는 custom 메시지를 보여주는게 타당할지도 모릅니다

혼란을 주거나 오해를 유발하는 custom 메시지 금지

사람들은 때때로 이 메시지들을 읽지 않고 alert를 빠르게 넘깁니다. 그런 막넘김 행위를 악용하는 custom 메시지 screen은 App Store Review에 의해 reject으로 이어집니다

reject을 유발하는 몇가지 금지된 custom 메시지 디자인이 있습니다. 몇가지 예로는 incentive를 제공하거나, "Allow"라는 단어가 들어가서 요청처럼 생겼거나, alert 이미지를 넣어놨거나, 팝업으로 뜨는 alert 뒤에 배경으로 보이도록 주석 표시 같은 걸 해놨거나 하는 경우가 있습니다