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
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 tried
On Sat, Mar 21, 2015 at 10:47 PM, Florian Bösch pya...@gmail.com 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
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 mou...@lamouri.fr 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
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 WebApps
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.
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 input type=file—that
On Fri, Sep 5, 2014 at 11:14 AM, Mounir Lamouri mou...@lamouri.fr 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 input
type='file'
On 04 Sep 2014, at 23:18, Marcos Caceres mar...@marcosc.com 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
On Friday, September 5, 2014, Kostiainen, Anssi anssi.kostiai...@intel.com
wrote:
On 04 Sep 2014, at 23:18, Marcos Caceres mar...@marcosc.com
javascript:; 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
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 not
On 04 Sep 2014, at 13:48, Mounir Lamouri mou...@lamouri.fr 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
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 will
Hello,
On Thu, Sep 4, 2014 at 8:23 PM, Edward O'Connor eocon...@apple.com 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
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
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
to
On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres mar...@marcosc.com 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
--
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 4:24 PM, Florian Bösch pya...@gmail.com wrote:
On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres mar...@marcosc.com 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
On Thu, Sep 4, 2014 at 1:50 PM, Florian Bösch pya...@gmail.com 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
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,
On 02 Sep 2014, at 16:51, Mounir Lamouri mou...@lamouri.fr 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
On Tue, Sep 2, 2014 at 6:51 AM, Mounir Lamouri mou...@lamouri.fr 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
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
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:
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
27 matches
Mail list logo
