4 ms·

Well, it's a good idea, but it needs a big, fat "hey, this might/will probably break stuff in the app you're authorizing" button. Apps usually request that stuf

by cheald 15y ago

Well, it's a good idea, but it needs a big, fat "hey, this might/will probably break stuff in the app you're authorizing" button. Apps usually request that stuff for some reason, and the vast majority of users don't have enough understanding of the systems to know which permissions are safe to revoke. Best case, things silently break and the user doesn't care. Worse case, things break and the user blames the developer and malign the application. You know how important the star ratings are in the mobile markets? You know how much effort developers put into managing the user experience, knowing that their app's success lives or dies based on their ability to keep from offending the luddites among their userbase? This is great for power users who understand and accept the risks inherent in doing something like this, but it's an awful idea for just about anyone except developers who understand what those permissions are actually used for.

chadrs 15y ago
I have to disagree. First, I actually do have this warning in the README. Second, if the app breaks when it doesn't have enough permissions, that's really just the laziness of the app developer. Handle the error gracefully if you really need the permission, and prompt for it again, explaining what you need it for.
- cheald 15y ago
  The app "breaking" isn't necessarily as cut-and-dried as "Threw an unhandled exception". Functionality that fails to work as the user expected (because the user revoked a key permission enabling that functionality) is "broken", and results in bug reports, which results in developer time spent trying to reproduce an issue that was introduced because the user violated one of the basic assumptions in the app. You should still be checking your returns, but you can check a return, see that the value didn't come back as expected, handle it gracefully, and still deliver a "broken" user experience. I appreciate the idea and the impetus for it - a lot - but the end result for something like this is broken apps to one degree or another.
  - bigiain 15y ago
    I see it as being very similar to something like noflash - if I choose to install and run noflash it "breaks" some websites. Sometimes that's exactly what I wanted it to do - sometimes it's collateral damage, and when/if I notice it I can go in and whitelist something I broke to make it work again. Unless you're worried that somehow this extension will get sneaky-loaded without the user understanding what it does, I find it hard to see your argument as anything but alarmism... (Having said that, I've never written a Facebook app, and have no personal experience with that demographic - I could be easily convinced that popular Facebook app developers do get the sort of customers who complain that their critical "RanchVille" app - which they got for free - is broken with a blank screen and needs fixing _immediately_, oh and BTW hurry up, it's getting cold in this blackout!)
    - cheald 15y ago
      Flashblock is a great example of the problem. Google Music wouldn't work on my wife's computer, causing a lot of frustration for her, until I noticed the flashblock icon. Google was using a hidden div with a flash player to play the music. When Flashblock shows a big placeholder rather than the Youtube video, you know what's happening. It's not always obvious, though, and it takes someone who knows that Flash players are often used for this sort of thing to solve the problem. If I wasn't home, my wife would have just assumed that the product didn't work on her computer and given up on it.
      - uxp 15y ago
        I agree with your point. Even I took a few seconds longer wondering why Google Music didn't run on my version of Chrome until I correctly guessed that there was a hidden flash player somewhere I couldn't see, and I'm a developer myself. But, I do think the other side of the argument still stands. If someone decides to use a 25 pound sledge hammer to frame a house, that person shouldn't get mad when on occasion his tools end up causing more frustration than the project he's working on. Whitelisting tools like Flashblock/Clicktoflash or NoScript are sledge hammers to the web. When it's just a few things littered here and there on a site that is widely non-flash based, it's not a problem to take everything out at once. Fine tuning at that point requires a bit more care and a lot more effort, but it's hardly the fault of the plugin developer when it doesn't work in every case. Toggle it on off and see if it works, and move on.
bigiain 15y ago
I'm not entirely sure that's a valid objection for something who's installation instructions include "clone this git repo, then open chrome in developer mode". Perhaps before it becomes a point'n'click install there might need to be more explanation about what might break, but anyone capable of installing it in its current form _ought_ to be capable of working out it's various means of breakage...
- cheald 15y ago
  I agree in this case. If it's a git repo, not a problem. But, it's not the first time I've seen this issue raised, and the common response is "heck yeah, I want to do that!" It's not inconceivable to imagine that someone packages this into a mass-usable extension eventually. One Google search led me here: https://chrome.google.com/webstore/detail/mlnhcepfaddcopbeggpobodmmodilgmc https://chrome.google.com/webstore/detail/mlnhcepfaddcopbegg... People, in general, don't understand what the permissions they're granting (and ergo, revoking) do, and what why they are needed (or what fails to work when they are revoked). It's a broken solution to a broken problem - permissions aren't granular enough, but permissions that are too granular get the TL;DR treatment from users. Developers have abused the permissions structure (usually under the "just in case" rather than "active abuse" justification), and users don't understand it, and the middle ground is that it's a giant mess that can't be unraveled without breaking a lot of things in the process. I'd love to see some process by which an app could pass a string that says "This is why we need this permission, here's what happens if we don't have it", and then let the user select or deselect it, having been fully informed of the consequences. Additionally, exposing that UI to the user will encourage developers to write robust code that deals with that permission not being present.
  - bigiain 15y ago
    "It's a broken solution to a broken problem" Sure. That doesn't mean we need to accept Facebook's status quo - which resolves the inevitable brokenness in the direction of: "Oh well, your privacy and that of your friends is the price you have to pay to let poorly written apps to work." We should at least have the option to choose: "I'll have a little more control over my privacy and a bit more respect for my friends, and if that means the new social-media-viral-casual-gaming-sensation-de-jour fails to work for me 'cause it thought it could spam my friends and didn't properly check for success (or intentionally crashed on failure), then that's fine too, maybe I'll do something else with that time."
scott_s 15y ago
Apps usually request that stuff for some reason, and the vast majority of users don't have enough understanding of the systems to know which permissions are safe to revoke. Breaking the app is the point of doing this. It's often not clear that, say, a FB app will post, as the user, to their own stream. I think most people don't want this, and want the app to break if it tries. You're thinking of "safety" from the perspective of perserving application behavior, not perserving user data and identity.
- cheald 15y ago
  You're absolutely right - the point is to break the app. This is great if the user breaks the apps in exactly the ways they want, but my point is that users rarely understand the scope of the app, and may (and likely will) end up revoking permissions that break functionality they want. For example. I sign up with Foobar's Widgets with my Facebook account, and manually deny the "publish_stream" permission, because I just want to browse Foobar's widgets, and I don't want Foobar posting mean things about my mom on my stream behind my back. Three weeks later, I come across a really boss widget, and see the "Share this widget with your friends on Facebook!" button. "Neat!", I think, and click the button. That fires off a job that gets stuck into a background queue (because doing external applications work in your web app directly is a recipe for self-DDOSing), and the worker pops the job, tries to run it, fails because the publish_stream permission is missing, logs the error, and closes the job. I, the user, go to Facebook, expecting to see the widget there, but it's not there. I'll just assume it's lag. Things are slow sometimes. But it never shows up. I'm left with the assumption that it's Foobar's fault, for having a buggy "Share to Facebook" button. The problem is that by putting permission revocation in the hands of the users without any documentation on what those permissions are used for, you leave it open to each user to assume what those permissions are used for. Imagination runs wild, the user freaks out and revokes the permission, things break, and people go home unhappy. The case where this is absolutely needed is where an application is known to engage in some behavior that is undesirable, and you want to be able to prevent it from doing so. However, that's doable via the Facebook application permissions panel already, so I'm not sure that this is a big win. By placing it up front as a part of the authorization process, you're inviting people to break things in ways that they can't really see at the time of authorization. I don't think the solution is "always trust the developer". There are bad developers out there writing abusive apps, and we need the tools to deal with them. The solution is also not "fully rely on the user to evaluate and grant/revoke permissions", because most users can't be bothered to read anything longer than your average tweet. Developers need better ways to tell people why they need permissions, and users need more powerful tools to cut out permissions that they know are resulting in abusive behaviors.

by cheald 15y ago

chadrs 15y ago

I have to disagree. First, I actually do have this warning in the README. Second, if the app breaks when it doesn't have enough permissions, that's really just the laziness of the app developer. Handle the error gracefully if you really need the permission, and prompt for it again, explaining what you need it for.

cheald 15y ago
The app "breaking" isn't necessarily as cut-and-dried as "Threw an unhandled exception". Functionality that fails to work as the user expected (because the user revoked a key permission enabling that functionality) is "broken", and results in bug reports, which results in developer time spent trying to reproduce an issue that was introduced because the user violated one of the basic assumptions in the app. You should still be checking your returns, but you can check a return, see that the value didn't come back as expected, handle it gracefully, and still deliver a "broken" user experience. I appreciate the idea and the impetus for it - a lot - but the end result for something like this is broken apps to one degree or another.
- bigiain 15y ago
  I see it as being very similar to something like noflash - if I choose to install and run noflash it "breaks" some websites. Sometimes that's exactly what I wanted it to do - sometimes it's collateral damage, and when/if I notice it I can go in and whitelist something I broke to make it work again. Unless you're worried that somehow this extension will get sneaky-loaded without the user understanding what it does, I find it hard to see your argument as anything but alarmism... (Having said that, I've never written a Facebook app, and have no personal experience with that demographic - I could be easily convinced that popular Facebook app developers do get the sort of customers who complain that their critical "RanchVille" app - which they got for free - is broken with a blank screen and needs fixing _immediately_, oh and BTW hurry up, it's getting cold in this blackout!)
  - cheald 15y ago
    Flashblock is a great example of the problem. Google Music wouldn't work on my wife's computer, causing a lot of frustration for her, until I noticed the flashblock icon. Google was using a hidden div with a flash player to play the music. When Flashblock shows a big placeholder rather than the Youtube video, you know what's happening. It's not always obvious, though, and it takes someone who knows that Flash players are often used for this sort of thing to solve the problem. If I wasn't home, my wife would have just assumed that the product didn't work on her computer and given up on it.
    - uxp 15y ago
      I agree with your point. Even I took a few seconds longer wondering why Google Music didn't run on my version of Chrome until I correctly guessed that there was a hidden flash player somewhere I couldn't see, and I'm a developer myself. But, I do think the other side of the argument still stands. If someone decides to use a 25 pound sledge hammer to frame a house, that person shouldn't get mad when on occasion his tools end up causing more frustration than the project he's working on. Whitelisting tools like Flashblock/Clicktoflash or NoScript are sledge hammers to the web. When it's just a few things littered here and there on a site that is widely non-flash based, it's not a problem to take everything out at once. Fine tuning at that point requires a bit more care and a lot more effort, but it's hardly the fault of the plugin developer when it doesn't work in every case. Toggle it on off and see if it works, and move on.

bigiain 15y ago

I'm not entirely sure that's a valid objection for something who's installation instructions include "clone this git repo, then open chrome in developer mode". Perhaps before it becomes a point'n'click install there might need to be more explanation about what might break, but anyone capable of installing it in its current form _ought_ to be capable of working out it's various means of breakage...

cheald 15y ago
I agree in this case. If it's a git repo, not a problem. But, it's not the first time I've seen this issue raised, and the common response is "heck yeah, I want to do that!" It's not inconceivable to imagine that someone packages this into a mass-usable extension eventually. One Google search led me here: https://chrome.google.com/webstore/detail/mlnhcepfaddcopbeggpobodmmodilgmc https://chrome.google.com/webstore/detail/mlnhcepfaddcopbegg... People, in general, don't understand what the permissions they're granting (and ergo, revoking) do, and what why they are needed (or what fails to work when they are revoked). It's a broken solution to a broken problem - permissions aren't granular enough, but permissions that are too granular get the TL;DR treatment from users. Developers have abused the permissions structure (usually under the "just in case" rather than "active abuse" justification), and users don't understand it, and the middle ground is that it's a giant mess that can't be unraveled without breaking a lot of things in the process. I'd love to see some process by which an app could pass a string that says "This is why we need this permission, here's what happens if we don't have it", and then let the user select or deselect it, having been fully informed of the consequences. Additionally, exposing that UI to the user will encourage developers to write robust code that deals with that permission not being present.
- bigiain 15y ago
  "It's a broken solution to a broken problem" Sure. That doesn't mean we need to accept Facebook's status quo - which resolves the inevitable brokenness in the direction of: "Oh well, your privacy and that of your friends is the price you have to pay to let poorly written apps to work." We should at least have the option to choose: "I'll have a little more control over my privacy and a bit more respect for my friends, and if that means the new social-media-viral-casual-gaming-sensation-de-jour fails to work for me 'cause it thought it could spam my friends and didn't properly check for success (or intentionally crashed on failure), then that's fine too, maybe I'll do something else with that time."

scott_s 15y ago

Apps usually request that stuff for some reason, and the vast majority of users don't have enough understanding of the systems to know which permissions are safe to revoke. Breaking the app is the point of doing this. It's often not clear that, say, a FB app will post, as the user, to their own stream. I think most people don't want this, and want the app to break if it tries. You're thinking of "safety" from the perspective of perserving application behavior, not perserving user data and identity.

cheald 15y ago
You're absolutely right - the point is to break the app. This is great if the user breaks the apps in exactly the ways they want, but my point is that users rarely understand the scope of the app, and may (and likely will) end up revoking permissions that break functionality they want. For example. I sign up with Foobar's Widgets with my Facebook account, and manually deny the "publish_stream" permission, because I just want to browse Foobar's widgets, and I don't want Foobar posting mean things about my mom on my stream behind my back. Three weeks later, I come across a really boss widget, and see the "Share this widget with your friends on Facebook!" button. "Neat!", I think, and click the button. That fires off a job that gets stuck into a background queue (because doing external applications work in your web app directly is a recipe for self-DDOSing), and the worker pops the job, tries to run it, fails because the publish_stream permission is missing, logs the error, and closes the job. I, the user, go to Facebook, expecting to see the widget there, but it's not there. I'll just assume it's lag. Things are slow sometimes. But it never shows up. I'm left with the assumption that it's Foobar's fault, for having a buggy "Share to Facebook" button. The problem is that by putting permission revocation in the hands of the users without any documentation on what those permissions are used for, you leave it open to each user to assume what those permissions are used for. Imagination runs wild, the user freaks out and revokes the permission, things break, and people go home unhappy. The case where this is absolutely needed is where an application is known to engage in some behavior that is undesirable, and you want to be able to prevent it from doing so. However, that's doable via the Facebook application permissions panel already, so I'm not sure that this is a big win. By placing it up front as a part of the authorization process, you're inviting people to break things in ways that they can't really see at the time of authorization. I don't think the solution is "always trust the developer". There are bad developers out there writing abusive apps, and we need the tools to deal with them. The solution is also not "fully rely on the user to evaluate and grant/revoke permissions", because most users can't be bothered to read anything longer than your average tweet. Developers need better ways to tell people why they need permissions, and users need more powerful tools to cut out permissions that they know are resulting in abusive behaviors.