The Permissions API moved to the WebAppSec WG, and there's an open
call for comments on publishing its FPWD:
https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0131.html.
It would probably make more sense to discuss in that group.
On Sat, Mar 21, 2015 at 2:47 PM, Florian Bösch wrote:
>
On Sat, Mar 21, 2015 at 10:47 PM, Florian Bösch wrote:
> 2) MRI scans show that user attention dramatically drops when presented
> with a security prompt:
> http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/
>
It's also likely the case that (
On 2015-03-21 22:47, Florian Bösch wrote:
Time to revise this topic. Two data points:
1) Particularly with pointerlock (but also with other permission prompts
> that sneak up on the user) I often get the complaint from users along the
> lines of "I tried your stuff, but it didn't work." or "I t
Time to revise this topic. Two data points:
1) Particularly with pointerlock (but also with other permission prompts
that sneak up on the user) I often get the complaint from users along the
lines of "I tried your stuff, but it didn't work." or "I tried your stuff,
but it asked me to do X, I don't
On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri wrote:
> On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
>> I'm generally supportive of this direction.
>>
>> I'm not sure that that the PermissionStatus thing is needed. For
>> example in order to support bluetooth is might be better to make the
>
On Tue, 16 Sep 2014, at 06:50, Frederick Hirsch wrote:
> [cross posted to DAP]
>
> I’d like to point out that work such as this would be allowed under the
> W3C Device APIs WG charter [1] if this is of interest (not being sure of
> current plans):
Arthur, would that work be aligned with the WebAp
[cross posted to DAP]
I’d like to point out that work such as this would be allowed under the W3C
Device APIs WG charter [1] if this is of interest (not being sure of current
plans):
[[
The scope of this Working Group is this creation of API specifications for a
device’s services that can be e
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
On Friday, September 5, 2014, Kostiainen, Anssi
wrote:
> On 04 Sep 2014, at 23:18, Marcos Caceres > wrote:
>
> > Absolutely, we should be addressing them at the API level.
>
> I guess you mean each API should address this in a way that fits the
> design of the particular API the best?
Correct.
On 04 Sep 2014, at 23:18, Marcos Caceres wrote:
> Absolutely, we should be addressing them at the API level.
I guess you mean each API should address this in a way that fits the design of
the particular API the best?
And something like permissions.js could then be used to abstract away the
di
On Fri, Sep 5, 2014 at 11:14 AM, Mounir Lamouri wrote:
> Note that the Permissions API model isn't requiring all APIs to abide by
> its model. Having no permissions at all for an API is a decent model if
> possible. For example, having a permission concept for type='file'> doesn't make much sens
On Fri, 5 Sep 2014, at 03:23, Edward O'Connor wrote:
> We should be avoiding adding features to the platform that have to
> resort to explicit permissioning. Instead of adding features which
> require prompting for permission, we should be designing features—like
> drag & drop or —that don't requir
On Thu, Sep 4, 2014 at 1:50 PM, Florian Bösch wrote:
>
> Well, the motivation to ask for permission up front is so that you later
> don't have to pester the user. Everytime you poll a user, there's a
> possibility he'll not see the prompt (happens to me pretty frequently in
> chrome and firefox)
On Thu, Sep 4, 2014 at 10:36 PM, Jeffrey Walton wrote:
> A site that continually prompts the user could negatively affect the
> user experience. If the designers of the site appreciate the fact,
> then they might ask for fewer permissions. They might even segregate
> functionality into different
On Thu, Sep 4, 2014 at 4:24 PM, Florian Bösch wrote:
> On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres wrote:
>
>> This sets up an unrealistic straw-man. Are there any real sites that would
>> need to show all of the above all at the same time?
>
> Let's say you're writing a video editor, you'd l
--
Marcos Caceres
On September 4, 2014 at 4:24:56 PM, Florian Bösch (pya...@gmail.com) wrote:
> On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres wrote:
>
> > This sets up an unrealistic straw-man. Are there any real sites that would
> > need to show all of the above all at the same time?
>
On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres wrote:
> This sets up an unrealistic straw-man. Are there any real sites that would
> need to show all of the above all at the same time?
Let's say you're writing a video editor, you'd like:
- To get access to the locations API so that you can
On September 4, 2014 at 4:14:57 PM, Florian Bösch (pya...@gmail.com) wrote:
> This is an issue to use, for a user.
>
> - http://codeflow.org/issues/permissions.html
> - http://codeflow.org/issues/permissions.jpg
This sets up an unrealistic straw-man. Are there any real sites that would need
t
This is an issue to use, for a user.
- http://codeflow.org/issues/permissions.html
- http://codeflow.org/issues/permissions.jpg
- In firefox it's a succession of popup
It's also an issue to use for a developer, because the semantics and
methods for requesting, getting, being denied and m
Hello,
On Thu, Sep 4, 2014 at 8:23 PM, Edward O'Connor wrote:
> Mounir wrote:
>
>> Permissions API would be a single entry point for a web page to check
>> if using API /foo/ would prompt, succeed or fail.
>
> It would be a mistake to add such an API to the platform. A unified API
> for explicit
Hi,
Mounir wrote:
> Permissions API would be a single entry point for a web page to check
> if using API /foo/ would prompt, succeed or fail.
It would be a mistake to add such an API to the platform. A unified API
for explicit permissioning is an attractive nuisance which future spec
authors wil
On 04 Sep 2014, at 13:48, Mounir Lamouri wrote:
> On Thu, 4 Sep 2014, at 01:33, Kostiainen, Anssi wrote:
>> Given there's good discussion going on at the Paris meeting right now [4]
>> and the topic is on the agenda, I’m expecting more input from the meeting
>> participants on how to proceed.
>
On Thu, 4 Sep 2014, at 01:33, Kostiainen, Anssi wrote:
> Given there's good discussion going on at the Paris meeting right now [4]
> and the topic is on the agenda, I’m expecting more input from the meeting
> participants on how to proceed.
Could you share here the outcome of that discussion if no
On 02 Sep 2014, at 16:51, Mounir Lamouri wrote:
> TL;DR:
> Permissions API would be a single entry point for a web page to check if
> using API /foo/ would prompt, succeed or fail.
>
> You can find the chromium.org design document in [1].
[...]
Thanks for the strawman proposal. I think your v1
On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
> I'm generally supportive of this direction.
>
> I'm not sure that that the PermissionStatus thing is needed. For
> example in order to support bluetooth is might be better to make the
> call look like:
>
> permissions.has("bluetooth", "fitbit")
I welcome this proposal because the permission dialog creep is certainly
worrying.
Opponents of some kind of permission management have pointed out that
collated dialogs tend to just get ignored by users and blindly approved (as
an example they list Android permission handling).
While that may be
Hi Mounir,
Have you considered making this return a promise, as per Nikhil's proposal:
https://github.com/w3c/push-api/issues/3#issuecomment-42997477
p.s. I will bring your idea to the trust & permissions in the open web
platform meeting, we're holding in Paris this week, see:
http://
On 9/2/14, 9:51 AM, Mounir Lamouri wrote:
required PermissionName name;
Glad to see "required" being put to good use. ;)
interface PermissionManager {
IDL nit: This needs Exposed=(Window,Worker)
[NoInterfaceObject, Exposed=Window,Worker]
And parens.
-Boris
On Tue, Sep 2, 2014 at 6:51 AM, Mounir Lamouri wrote:
> # Straw man proposal #
>
> This proposal is on purpose minimalistic and only contains features that
> should have straight consensus and strong use cases, the linked document
> [1] contains ideas of optional additions and list of retired idea
TL;DR:
Permissions API would be a single entry point for a web page to check if
using API /foo/ would prompt, succeed or fail.
You can find the chromium.org design document in [1].
# Use case #
The APIs on the platform are lacking a way to check whether the user has
granted them. Except the Noti
30 matches
Mail list logo
