Re: Proposal for a Permissions API

On 2014/09/04 13:33, Marcos Caceres wrote:
> ...
> A developer can then have a "Let's get started!" screen, where they explain why they need each feature before they request it.  
> ...
> Absolutely. I the above, a dev could still ask for each API as needed. Like:
>
> "Ok, let's get your camera working. We need you to grant us access to it". 
>
> <Get user media> 
>
> "Great! will you want to geotag your videos? If so, confirm the prompt. You can always turn this off in the app later."
>
> <geolocation> 
>
> (or a checkbox-like option in their app - this can be enabled during recording even!) 
>
> "fullscreen" is just a button in the UI: works just like it does today. 
>
> None of the above e require all permissions to be asked at once. 
>
> There is a great article that discusses this approach:
> http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-for-ios-permissions/
I strongly support this approach. I want to know what functionality an
app is going to provide me in return for each of the permissions I
grant. I want to be able to selectively use those features whose
required permissions I am willing to give to the app's developer.

The Android up-front all-or-nothing approach is a disaster that results
in it being much too easy to give unintended permissions and much too
easy for apps to sneakily ask permissions for things they should not be
doing. Let's not repeat it on the Web platform.

What about the fingerprinting that a permissions API would enable?

Regards

    -Mark

-- 
注意:この電子メールには、株式会社エイチアイの機密情報が含まれている場合
が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情
報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし
たら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and
privileged information from HI Corporation. If you are not the intended
recipient, any disclosure, photocopying, distribution or use of the
contents of the received information is prohibited. If you have received
this e-mail in error, please notify the sender immediately and
permanently delete this message and all related copies.

Received on Tuesday, 9 September 2014 00:19:26 UTC