Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

"Privileged" APIs: Solving user privacy concerns.

30 views
Skip to first unread message

Rick Waldron

unread,
Mar 15, 2012, 12:15:16 PM3/15/12
to dev-webapi
I've been following both the Battery API and Embedded Browser API
discussions and the idea of a "privileged app" has been repeated several
times. Creating stunted APIs is not the solution to privacy concerns - it
will only doom the web to be a less capable platform and native apps will
win. Nail in coffin. Game over.

Perhaps if the focus was less on "how to choke this API into a state of
complete uselessness", why not simplify the design process and put the
decision in the user's hand...


"This app would like to access your device's Battery information. No
personal or private information will be used" (Yes,No)

"This app would like to embed a web browser. No personal or private
information will be used" (Yes,No)


Geolocation and WebRTC are already doing this - so there is a precedent.
Millions of users see things like this every day when they "Login in using
Facebook", etc.


Rick

Ben Francis

unread,
Mar 15, 2012, 12:19:35 PM3/15/12
to Rick Waldron, dev-webapi
Hi Rick,

The permissions model is being discussed over on dev-webapps if you're
interested https://lists.mozilla.org/listinfo/dev-webapps

Ben
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>



--
Ben Francis
http://tola.me.uk

Rick Waldron

unread,
Mar 15, 2012, 12:19:59 PM3/15/12
to dev-webapi
Post Script...


I should note that the Embedded Browser API actually already suggests doing
this, I just think it's important to *not* suffocate the emerging APIs when
the precedent already exists.

Rick

Rick Waldron

unread,
Mar 15, 2012, 12:20:22 PM3/15/12
to Ben Francis, dev-webapi
Ben, I am and thanks for the link :)

On Thu, Mar 15, 2012 at 12:19 PM, Ben Francis <b...@krellian.com> wrote:

> Hi Rick,
>
> The permissions model is being discussed over on dev-webapps if you're
> interested https://lists.mozilla.org/listinfo/dev-webapps
>
> Ben
>
> On Thu, Mar 15, 2012 at 4:15 PM, Rick Waldron <waldro...@gmail.com>wrote:
>
>> I've been following both the Battery API and Embedded Browser API
>> discussions and the idea of a "privileged app" has been repeated several
>> times. Creating stunted APIs is not the solution to privacy concerns - it
>> will only doom the web to be a less capable platform and native apps will
>> win. Nail in coffin. Game over.
>>
>> Perhaps if the focus was less on "how to choke this API into a state of
>> complete uselessness", why not simplify the design process and put the
>> decision in the user's hand...
>>
>>
>> "This app would like to access your device's Battery information. No
>> personal or private information will be used" (Yes,No)
>>
>> "This app would like to embed a web browser. No personal or private
>> information will be used" (Yes,No)
>>
>>
>> Geolocation and WebRTC are already doing this - so there is a precedent.
>> Millions of users see things like this every day when they "Login in using
>> Facebook", etc.
>>
>>
>> Rick

Panos Astithas

unread,
Mar 16, 2012, 4:52:36 AM3/16/12
to Rick Waldron, dev-webapi
On Thu, Mar 15, 2012 at 6:15 PM, Rick Waldron <waldro...@gmail.com>wrote:

> I've been following both the Battery API and Embedded Browser API
> discussions and the idea of a "privileged app" has been repeated several
> times. Creating stunted APIs is not the solution to privacy concerns - it
> will only doom the web to be a less capable platform and native apps will
> win. Nail in coffin. Game over.
>
> Perhaps if the focus was less on "how to choke this API into a state of
> complete uselessness", why not simplify the design process and put the
> decision in the user's hand...
>
>
> "This app would like to access your device's Battery information. No
> personal or private information will be used" (Yes,No)
>

The battery API discussion suggested that there are possibilities for
fingerprinting users via (versions of) this API, so I don't think this
would be an honest assertion.

Panos
0 new messages