Re: Allow ... centralized dialog up front
Usually games (especially 3D applications) would like to get capabilities that they can use out of the way up front so they don't have to care about it later on. On Sat, Feb 2, 2013 at 11:59 AM, Keean Schupke wrote: > I didn't think of that. The app would have to maintain its own set of > permission flags updated by the callback. I am not sure that's easier than > just chaining an anonymous function... But I guess that's a programming > style issue. > > Cheers, > Keean. > On 2 Feb 2013 10:47, "Florian Bösch" wrote: > >> And you can have the *the* callback (singular, centralized) as >> onAPIPermissionChange just fine. >> >> If you want to improve things for the user and the developer, you can't >> go with a solution that doesn't make it any easier for the developer. Your >> solution will be ignored, nay ridiculed. If you want developers to play >> along, you've got to give them some carrot as well. >> >> >> On Sat, Feb 2, 2013 at 11:43 AM, Keean Schupke wrote: >> >>> There are benefits to the user, in that it allows all permissions to be >>> managed from one place. >>> >>> I am not sure I like the idea of making the popups an application thing. >>> I think it should be decided by the browser. In any case you would still >>> need the ...Allow callbacks as the user may have gone to the permission >>> review/edit page and disabled some permissions since the app started. >>> >>> Cheers, >>> Keean. >>> >>> Cheers, >>> Keean. >>> On 2 Feb 2013 10:27, "Florian Bösch" wrote: >>> On Sat, Feb 2, 2013 at 11:16 AM, Keean Schupke wrote: > I think a static declaration is better for security, so if a > permission is not there I don't think it should be allowed to request it > later. Of course how this is presented to the user is entirely separate, > an > the UI could defer the request until the first time the restricted feature > is used, or allow all permissions that might be needed to be reviewed and > enabled/disabled in one place. > That kills any benefit a developer could derive. The very idea is that you can figure out up front what your user is gonna let you do, and take appropriate steps (not adding parts of the UI, presenting a suitable message that the application won't work etc.) as well as that if a user has agreed up front, that you can rely on that API and don't need to double-check at every step and add a gazillion pointless onFeatureYaddaYaddaAllowCallback handlers. >>> >>
Re: Allow ... centralized dialog up front
I didn't think of that. The app would have to maintain its own set of permission flags updated by the callback. I am not sure that's easier than just chaining an anonymous function... But I guess that's a programming style issue. Cheers, Keean. On 2 Feb 2013 10:47, "Florian Bösch" wrote: > And you can have the *the* callback (singular, centralized) as > onAPIPermissionChange just fine. > > If you want to improve things for the user and the developer, you can't go > with a solution that doesn't make it any easier for the developer. Your > solution will be ignored, nay ridiculed. If you want developers to play > along, you've got to give them some carrot as well. > > > On Sat, Feb 2, 2013 at 11:43 AM, Keean Schupke wrote: > >> There are benefits to the user, in that it allows all permissions to be >> managed from one place. >> >> I am not sure I like the idea of making the popups an application thing. >> I think it should be decided by the browser. In any case you would still >> need the ...Allow callbacks as the user may have gone to the permission >> review/edit page and disabled some permissions since the app started. >> >> Cheers, >> Keean. >> >> Cheers, >> Keean. >> On 2 Feb 2013 10:27, "Florian Bösch" wrote: >> >>> On Sat, Feb 2, 2013 at 11:16 AM, Keean Schupke wrote: >>> I think a static declaration is better for security, so if a permission is not there I don't think it should be allowed to request it later. Of course how this is presented to the user is entirely separate, an the UI could defer the request until the first time the restricted feature is used, or allow all permissions that might be needed to be reviewed and enabled/disabled in one place. >>> That kills any benefit a developer could derive. The very idea is that >>> you can figure out up front what your user is gonna let you do, and take >>> appropriate steps (not adding parts of the UI, presenting a suitable >>> message that the application won't work etc.) as well as that if a user has >>> agreed up front, that you can rely on that API and don't need to >>> double-check at every step and add a gazillion pointless >>> onFeatureYaddaYaddaAllowCallback handlers. >>> >> >
Re: Allow ... centralized dialog up front
And you can have the *the* callback (singular, centralized) as onAPIPermissionChange just fine. If you want to improve things for the user and the developer, you can't go with a solution that doesn't make it any easier for the developer. Your solution will be ignored, nay ridiculed. If you want developers to play along, you've got to give them some carrot as well. On Sat, Feb 2, 2013 at 11:43 AM, Keean Schupke wrote: > There are benefits to the user, in that it allows all permissions to be > managed from one place. > > I am not sure I like the idea of making the popups an application thing. I > think it should be decided by the browser. In any case you would still need > the ...Allow callbacks as the user may have gone to the permission > review/edit page and disabled some permissions since the app started. > > Cheers, > Keean. > > Cheers, > Keean. > On 2 Feb 2013 10:27, "Florian Bösch" wrote: > >> On Sat, Feb 2, 2013 at 11:16 AM, Keean Schupke wrote: >> >>> I think a static declaration is better for security, so if a permission >>> is not there I don't think it should be allowed to request it later. Of >>> course how this is presented to the user is entirely separate, an the UI >>> could defer the request until the first time the restricted feature is >>> used, or allow all permissions that might be needed to be reviewed and >>> enabled/disabled in one place. >>> >> That kills any benefit a developer could derive. The very idea is that >> you can figure out up front what your user is gonna let you do, and take >> appropriate steps (not adding parts of the UI, presenting a suitable >> message that the application won't work etc.) as well as that if a user has >> agreed up front, that you can rely on that API and don't need to >> double-check at every step and add a gazillion pointless >> onFeatureYaddaYaddaAllowCallback handlers. >> >
Re: Allow ... centralized dialog up front
There are benefits to the user, in that it allows all permissions to be managed from one place. I am not sure I like the idea of making the popups an application thing. I think it should be decided by the browser. In any case you would still need the ...Allow callbacks as the user may have gone to the permission review/edit page and disabled some permissions since the app started. Cheers, Keean. Cheers, Keean. On 2 Feb 2013 10:27, "Florian Bösch" wrote: > On Sat, Feb 2, 2013 at 11:16 AM, Keean Schupke wrote: > >> I think a static declaration is better for security, so if a permission >> is not there I don't think it should be allowed to request it later. Of >> course how this is presented to the user is entirely separate, an the UI >> could defer the request until the first time the restricted feature is >> used, or allow all permissions that might be needed to be reviewed and >> enabled/disabled in one place. >> > That kills any benefit a developer could derive. The very idea is that you > can figure out up front what your user is gonna let you do, and take > appropriate steps (not adding parts of the UI, presenting a suitable > message that the application won't work etc.) as well as that if a user has > agreed up front, that you can rely on that API and don't need to > double-check at every step and add a gazillion pointless > onFeatureYaddaYaddaAllowCallback handlers. >
Re: Allow ... centralized dialog up front
On Sat, Feb 2, 2013 at 11:16 AM, Keean Schupke wrote: > I think a static declaration is better for security, so if a permission is > not there I don't think it should be allowed to request it later. Of course > how this is presented to the user is entirely separate, an the UI could > defer the request until the first time the restricted feature is used, or > allow all permissions that might be needed to be reviewed and > enabled/disabled in one place. > That kills any benefit a developer could derive. The very idea is that you can figure out up front what your user is gonna let you do, and take appropriate steps (not adding parts of the UI, presenting a suitable message that the application won't work etc.) as well as that if a user has agreed up front, that you can rely on that API and don't need to double-check at every step and add a gazillion pointless onFeatureYaddaYaddaAllowCallback handlers.
Re: Allow ... centralized dialog up front
I think a static declaration is better for security, so if a permission is not there I don't think it should be allowed to request it later. Of course how this is presented to the user is entirely separate, an the UI could defer the request until the first time the restricted feature is used, or allow all permissions that might be needed to be reviewed and enabled/disabled in one place. Cheers, Keean. On 2 Feb 2013 09:45, "Florian Bösch" wrote: > I thought this was obvious but maybe not. Of course I had in mind that: > > - A user gets some centralized place to "manage his sites" > - He can change permissions > - If the sites preferences change, the permissions pop up again. > - Some way for the user to re-engage the permission dialog for the site > he's on on his own. > > But none of this is in the domain of a standard really, it's up to the > vendors how to best structure their UX. > > Now, indexability/markup, I kinda like that. I've thought (at times) to > create a news site or search crawler that looks for examples of > technologies. And sometimes I wish I could google filter out pages that > entertain certain technologies when searching for something. It would be a > nice semantic. > > Now there are still use-cases that might occur where a developer wants to > group a bunch of permissions up front, and later come with a different > bunch. Or where a developer derives the set of permissions he'll need from > the set of permissions his frameworks/libraries advise. Which would favor a > permission API. On the other hand most developers would probably be happy > to state permissions once for the page, and the markup could just be a > "remote-control" for the API. > > > On Sat, Feb 2, 2013 at 10:38 AM, Keean Schupke wrote: > >> I would like the permissions to be changeable. Not a one time dialog that >> appears and irrevocably commits me to my choices, but a page with >> enable/disable toggles I can return and review the permissions and change >> at any time. >> >> How about instead of a request API the required permissions are in tags >> so they can be machine readable on page load. >> >> The browser can read the required permissions tags as page load and >> create a settings page for the app where each permission can be toggled. >> >> This had the advantage that search engines etc can include permission >> requirements in searches. (I want a diary app that does not use my >> camera...) >> >> Cheers, >> Keean. >> >> Cheers, >> Keean. >> On 2 Feb 2013 09:09, "Florian Bösch" wrote: >> >> I do not particularly care what research you will find to support the >> UI-flow that the existence of a requestAPIs API will eventually give rise >> to. I do say simply this, the research presented, and pretty much common >> sense as well easily shows that the current course is foolhardy and ungainy >> on both user and developer. >> >> >> On Sat, Feb 2, 2013 at 3:37 AM, Charles McCathie Nevile < >> cha...@yandex-team.ru> wrote: >> >>> ** >>> On Fri, 01 Feb 2013 15:29:16 +0100, Florian Bösch >>> wrote: >>> >>> Repetitive permission dialog popups at random UI-flows will not solve >>> the permission fatique any more than a centralized one does. However a >>> centralized permission dialog will solve the following things fairly >>> effectively: >>> >>> - repeated popup fatique >>> >>> >>> Sure. And that is valuable in principle. >>> >>> - extension of trust towards a site regardless of what they ask for (do >>> I trust that Indie game developer? Yes! Do I trust google? No! or vice >>> versa) >>> >>> >>> I don't think so. As Adrienne said, as I have experienced myself, >>> without understanding what the permission is for trust can be reduced as >>> easily as increased. >>> >>> - make it easy for developers not to add UI-flows into their >>> application leading to things the user didn't want to give (Do we want a >>> menu entry "save to local storage" if the user checked off the box to allow >>> local storage? I think not.) >>> >>> >>> - make it easy for developers to not waste users time by pretending to >>> have a working application, which requires things the user didn't want to >>> give. (Do we really want to offer our geolocated, web-camera using chat app >>> to users who didn't want to give permission to to either? I think not. Do >>> we want to make him find that out after he's been entering our UI-flow and >>> been pressing buttons 5 minutes later? I think not.) >>> >>> These are not so clear. As a user, I *do* want to have applications to >>> which I will give, and revoke, at my discretion, certain rights. Twitter >>> leaps to mind as something that wants access to geolocation, something I >>> occasionally grant. for specific requests but blanket refuse in general. >>> The hypothetical example you offer is something that in general it seems >>> people are happy to offer to a user who has turned off both capabilities. >>> >>> I think the ability for a page to declare permission requests in a >>> standard way, the
Re: Allow ... centralized dialog up front
I thought this was obvious but maybe not. Of course I had in mind that: - A user gets some centralized place to "manage his sites" - He can change permissions - If the sites preferences change, the permissions pop up again. - Some way for the user to re-engage the permission dialog for the site he's on on his own. But none of this is in the domain of a standard really, it's up to the vendors how to best structure their UX. Now, indexability/markup, I kinda like that. I've thought (at times) to create a news site or search crawler that looks for examples of technologies. And sometimes I wish I could google filter out pages that entertain certain technologies when searching for something. It would be a nice semantic. Now there are still use-cases that might occur where a developer wants to group a bunch of permissions up front, and later come with a different bunch. Or where a developer derives the set of permissions he'll need from the set of permissions his frameworks/libraries advise. Which would favor a permission API. On the other hand most developers would probably be happy to state permissions once for the page, and the markup could just be a "remote-control" for the API. On Sat, Feb 2, 2013 at 10:38 AM, Keean Schupke wrote: > I would like the permissions to be changeable. Not a one time dialog that > appears and irrevocably commits me to my choices, but a page with > enable/disable toggles I can return and review the permissions and change > at any time. > > How about instead of a request API the required permissions are in tags so > they can be machine readable on page load. > > The browser can read the required permissions tags as page load and create > a settings page for the app where each permission can be toggled. > > This had the advantage that search engines etc can include permission > requirements in searches. (I want a diary app that does not use my > camera...) > > Cheers, > Keean. > > Cheers, > Keean. > On 2 Feb 2013 09:09, "Florian Bösch" wrote: > > I do not particularly care what research you will find to support the > UI-flow that the existence of a requestAPIs API will eventually give rise > to. I do say simply this, the research presented, and pretty much common > sense as well easily shows that the current course is foolhardy and ungainy > on both user and developer. > > > On Sat, Feb 2, 2013 at 3:37 AM, Charles McCathie Nevile < > cha...@yandex-team.ru> wrote: > >> ** >> On Fri, 01 Feb 2013 15:29:16 +0100, Florian Bösch >> wrote: >> >> Repetitive permission dialog popups at random UI-flows will not solve the >> permission fatique any more than a centralized one does. However a >> centralized permission dialog will solve the following things fairly >> effectively: >> >> - repeated popup fatique >> >> >> Sure. And that is valuable in principle. >> >> - extension of trust towards a site regardless of what they ask for (do I >> trust that Indie game developer? Yes! Do I trust google? No! or vice versa) >> >> >> I don't think so. As Adrienne said, as I have experienced myself, without >> understanding what the permission is for trust can be reduced as easily as >> increased. >> >> - make it easy for developers not to add UI-flows into their application >> leading to things the user didn't want to give (Do we want a menu entry >> "save to local storage" if the user checked off the box to allow local >> storage? I think not.) >> >> >> - make it easy for developers to not waste users time by pretending to >> have a working application, which requires things the user didn't want to >> give. (Do we really want to offer our geolocated, web-camera using chat app >> to users who didn't want to give permission to to either? I think not. Do >> we want to make him find that out after he's been entering our UI-flow and >> been pressing buttons 5 minutes later? I think not.) >> >> These are not so clear. As a user, I *do* want to have applications to >> which I will give, and revoke, at my discretion, certain rights. Twitter >> leaps to mind as something that wants access to geolocation, something I >> occasionally grant. for specific requests but blanket refuse in general. >> The hypothetical example you offer is something that in general it seems >> people are happy to offer to a user who has turned off both capabilities. >> >> I think the ability for a page to declare permission requests in a >> standard way, the same as applications and extensions, is worth pursuing, >> because there are now a number of vendors using stuff that seems to only >> differ by syntax. >> >> The user agent presentation is a more complex question. I believe there >> is more research done and being done than you seem to credit, and as >> Hallvord said, I think this is an area where users evolve too. >> >> For the reasons outlined already in the thread I don't think an >> Android-style "here are all the requests" is as good a solution in practice >> as it seems, and there is a need for continued research as we
Re: Allow ... centralized dialog up front
I would like the permissions to be changeable. Not a one time dialog that appears and irrevocably commits me to my choices, but a page with enable/disable toggles I can return and review the permissions and change at any time. How about instead of a request API the required permissions are in tags so they can be machine readable on page load. The browser can read the required permissions tags as page load and create a settings page for the app where each permission can be toggled. This had the advantage that search engines etc can include permission requirements in searches. (I want a diary app that does not use my camera...) Cheers, Keean. Cheers, Keean. On 2 Feb 2013 09:09, "Florian Bösch" wrote: I do not particularly care what research you will find to support the UI-flow that the existence of a requestAPIs API will eventually give rise to. I do say simply this, the research presented, and pretty much common sense as well easily shows that the current course is foolhardy and ungainy on both user and developer. On Sat, Feb 2, 2013 at 3:37 AM, Charles McCathie Nevile < cha...@yandex-team.ru> wrote: > ** > On Fri, 01 Feb 2013 15:29:16 +0100, Florian Bösch > wrote: > > Repetitive permission dialog popups at random UI-flows will not solve the > permission fatique any more than a centralized one does. However a > centralized permission dialog will solve the following things fairly > effectively: > > - repeated popup fatique > > > Sure. And that is valuable in principle. > > - extension of trust towards a site regardless of what they ask for (do I > trust that Indie game developer? Yes! Do I trust google? No! or vice versa) > > > I don't think so. As Adrienne said, as I have experienced myself, without > understanding what the permission is for trust can be reduced as easily as > increased. > > - make it easy for developers not to add UI-flows into their application > leading to things the user didn't want to give (Do we want a menu entry > "save to local storage" if the user checked off the box to allow local > storage? I think not.) > > > - make it easy for developers to not waste users time by pretending to > have a working application, which requires things the user didn't want to > give. (Do we really want to offer our geolocated, web-camera using chat app > to users who didn't want to give permission to to either? I think not. Do > we want to make him find that out after he's been entering our UI-flow and > been pressing buttons 5 minutes later? I think not.) > > These are not so clear. As a user, I *do* want to have applications to > which I will give, and revoke, at my discretion, certain rights. Twitter > leaps to mind as something that wants access to geolocation, something I > occasionally grant. for specific requests but blanket refuse in general. > The hypothetical example you offer is something that in general it seems > people are happy to offer to a user who has turned off both capabilities. > > I think the ability for a page to declare permission requests in a > standard way, the same as applications and extensions, is worth pursuing, > because there are now a number of vendors using stuff that seems to only > differ by syntax. > > The user agent presentation is a more complex question. I believe there is > more research done and being done than you seem to credit, and as Hallvord > said, I think this is an area where users evolve too. > > For the reasons outlined already in the thread I don't think an > Android-style "here are all the requests" is as good a solution in practice > as it seems, and there is a need for continued research as well as > implementations we can test. > > cheers > > Chaals > > > > > > On Fri, Feb 1, 2013 at 3:22 PM, Charles McCathie Nevile < > cha...@yandex-team.ru> wrote: > >> On Fri, 01 Feb 2013 15:16:04 +0100, Florian Bösch >> wrote: >> >> On Fri, Feb 1, 2013 at 3:02 PM, Adrienne Porter Felt < >> adriennef...@gmail.com> wrote: >> >>> My user research on Android found that people have a hard >>> time connecting upfront permission requests to the application feature that >>> needs the permission. This meant that people have no real basis by which to >>> allow or deny the request, except for their own supposition. IMO, this >>> implies that the better plan is to temporally tie the permission request to >>> the feature so that the user can connect the two. >>> >> In some circumstances this works, in others, it does not. Consider that >> not every capability has a UI-flow, and that some UI flows are fairly >> obscure. More often than not a page will initiate a flurry of permission >> dialogs up front to get it out of the way. Some of the UI-flows to use a >> capability happen deep inside an application activity and can be severely >> distracting, or crippling to the application. >> >> If a developer wants to use the blow-by-blow popup dialogs, he can still >> do so by simply not calling an API to get done with the business up front. >> But for those who kn
Re: Allow ... centralized dialog up front
I do not particularly care what research you will find to support the UI-flow that the existence of a requestAPIs API will eventually give rise to. I do say simply this, the research presented, and pretty much common sense as well easily shows that the current course is foolhardy and ungainy on both user and developer. On Sat, Feb 2, 2013 at 3:37 AM, Charles McCathie Nevile < cha...@yandex-team.ru> wrote: > ** > On Fri, 01 Feb 2013 15:29:16 +0100, Florian Bösch > wrote: > > Repetitive permission dialog popups at random UI-flows will not solve the > permission fatique any more than a centralized one does. However a > centralized permission dialog will solve the following things fairly > effectively: > > - repeated popup fatique > > > Sure. And that is valuable in principle. > > - extension of trust towards a site regardless of what they ask for (do I > trust that Indie game developer? Yes! Do I trust google? No! or vice versa) > > > I don't think so. As Adrienne said, as I have experienced myself, without > understanding what the permission is for trust can be reduced as easily as > increased. > > - make it easy for developers not to add UI-flows into their application > leading to things the user didn't want to give (Do we want a menu entry > "save to local storage" if the user checked off the box to allow local > storage? I think not.) > > > - make it easy for developers to not waste users time by pretending to > have a working application, which requires things the user didn't want to > give. (Do we really want to offer our geolocated, web-camera using chat app > to users who didn't want to give permission to to either? I think not. Do > we want to make him find that out after he's been entering our UI-flow and > been pressing buttons 5 minutes later? I think not.) > > These are not so clear. As a user, I *do* want to have applications to > which I will give, and revoke, at my discretion, certain rights. Twitter > leaps to mind as something that wants access to geolocation, something I > occasionally grant. for specific requests but blanket refuse in general. > The hypothetical example you offer is something that in general it seems > people are happy to offer to a user who has turned off both capabilities. > > I think the ability for a page to declare permission requests in a > standard way, the same as applications and extensions, is worth pursuing, > because there are now a number of vendors using stuff that seems to only > differ by syntax. > > The user agent presentation is a more complex question. I believe there is > more research done and being done than you seem to credit, and as Hallvord > said, I think this is an area where users evolve too. > > For the reasons outlined already in the thread I don't think an > Android-style "here are all the requests" is as good a solution in practice > as it seems, and there is a need for continued research as well as > implementations we can test. > > cheers > > Chaals > > > > > > On Fri, Feb 1, 2013 at 3:22 PM, Charles McCathie Nevile < > cha...@yandex-team.ru> wrote: > >> On Fri, 01 Feb 2013 15:16:04 +0100, Florian Bösch >> wrote: >> >> On Fri, Feb 1, 2013 at 3:02 PM, Adrienne Porter Felt < >> adriennef...@gmail.com> wrote: >> >>> My user research on Android found that people have a hard >>> time connecting upfront permission requests to the application feature that >>> needs the permission. This meant that people have no real basis by which to >>> allow or deny the request, except for their own supposition. IMO, this >>> implies that the better plan is to temporally tie the permission request to >>> the feature so that the user can connect the two. >>> >> In some circumstances this works, in others, it does not. Consider that >> not every capability has a UI-flow, and that some UI flows are fairly >> obscure. More often than not a page will initiate a flurry of permission >> dialogs up front to get it out of the way. Some of the UI-flows to use a >> capability happen deep inside an application activity and can be severely >> distracting, or crippling to the application. >> >> If a developer wants to use the blow-by-blow popup dialogs, he can still >> do so by simply not calling an API to get done with the business up front. >> But for those who know their application will not work without features X, >> Y, Z, A, B and C there is no point. They already know their app is not >> going to work. They already know they would have to pester the user 6 times >> with successive popups. They already know that they will severely distract >> the user or cripple themselves by making the user click trough 6 popups >> whenver it becomes necessary. They already know that 80% of their users >> will quit their page after the 3rd popup asking random questions. Why >> should there not be a way to prevent all that from happening? >> >> The stock answer (and I think it is too glib, and we should be thinking >> harder about this) is >> >> "because those who just want the
