8 ms·

Either that's not entirely truthful, or the app permission system is totally broken... Need to find out when you last opened the app? "Get running apps"...?

jagger27 11y ago
I don't even understand why they need local access to figure this out. Poll the web API for last_login and be done with it. Surely they're already tracking and storing this kind of data on their end.
- fsargent 11y ago
  It's so they can quickly switch between the most recently used maps application like Waze or Google Maps for drivers.
  - deleted 11y ago
    [deleted]
  - alanh 11y ago
    Please don’t state speculation as fact.
    - andrewstuart2 11y ago
      What makes you think they don't/didn't work for Uber? Seems a bit speculative to me.
      - hk__2 11y ago
        OP should provide a source for their statement. But if you want to go this way, their LinkedIn profile shows they never worked for Uber.
  - Buge 11y ago
    But StavrosK just claimed it doesn't work that way. He said that it will only tell you about instances of your own app, not others (such as Waze or Google Maps).
- rhizome 11y ago
  Does the app log in every time it starts up, or does it just have a stored access token that is simply supplied with future requests regardless of whether it's been 5 hours or 5 months?
  - iofj 11y ago
    Given what the uber app does when it starts up (show you a map of your locations, with data from a few uber cars moving across it), I'd bet the app essentially contacts the servers immediately when it starts. The only this would get them is "how many times did a user try to get an uber without data connectivity" ...
    - lwf 11y ago
      And even then, you could keep that record in local storage.
    - rhizome 11y ago
      Contacting servers is one thing, logging in is another. No authentication conversation needs to occur if the auth model is based on access tokens like generic OAuth flow.
- Zombieball 11y ago
  Doesn't uber have tight integration with other apps that could be running? e.g. Google maps? I assume the handoff from Google Maps doesn't require any kind of check to running apps from Uber, but I am curious if it is something along these lines.
  - takno 11y ago
    It does. The main reason I ended up uninstalling uber was because I didn't like it polluting my directions searches with adverts which didn't tell me anything I couldn't already have gotten from the driving directions
- bkjelden 11y ago
  Why make a network call if the device can give you that information locally?
  - jonathankoren 11y ago
    First, you're making a network call anyway, because that's what apps do, so the data is implicit. You simply group by user id and subtract the timestamps of the requests. But let's say for some reason, you can't collect app-open timestamps. What could you possibly want to do with it locally? Say, "Hey it's been x days since you last used me. Thanks for coming back!"? These are stats you want in aggregate, which means sending the data back to the servers for actual data analysis. You're not going to do that analysis -- or any analysis -- on the device, since there's nothing to compare to.
    - bkjelden 11y ago
      Yes, but if the data of when the app was last opened is needed to make more network calls, or to just show the user something in general, you're looking at a network call with round trip latency and a success rate <100%, vs. a device call that takes <1ms and succeeds every time.
      - jonathankoren 11y ago
        Put the last opened time on the initial authorization response. We could go round and round like this. Give me a concrete use case, because for the life of me I can't come up with one that isn't simply superfluous chrome.
    - deleted 11y ago
      [deleted]
  - sangnoir 11y ago
    Because Uber's primary functionality depends on network calls. To me, it's pretty obvious they want to find out if you opened the Lyft app recently.
dlubarov 11y ago
This page has more detail on Android's permissions model: http://developer.android.com/guide/topics/security/permissions.html#perm-groups http://developer.android.com/guide/topics/security/permissio... I don't really understand the point of having fine-grained permissions (like READ_CONTACTS), when the user only sees broader permission groups. Can someone shed light on this?
- theoduino 11y ago
  "Simplified Permissions" is a relatively new feature of the Play Store and only gives you general permission categories. It was probably changed from the older specific permissions to make it less complex for people who didn't care as much. Note that PackageInstaller still shows all permissions, which is used when clicking on an apk or using a 3rd party app store (like F-Droid). Due to backwards compatibility, this can't be changed easily at the OS level.
- tadfisher 11y ago
  It wasn't always this way. The individual permissions used to be displayed to the user directly; newer releases of the Play Store have "streamlined" this permissions prompt so that users see general permissions "groups", and some permissions (such as INTERNET) are considered "not dangerous", requiring a click on the "See all permissions" button to view everything the app requests. I imagine it's because Google recognized the general insanity of the system, and presenting fewer "scary" permissions improved conversion rates. Then they threw the whole system out with Android 6.0, moving to a much more sane flow for everyone involved, where the user is able to grant or deny individual permissions at runtime.
  - profeta 11y ago
    > system is broken and UI is confusing, protect nothing from user even if working right. > leave system broken but hide UI so nobody cares. hopefully, it is just incompetence, not evil.
    - newjersey 11y ago
tadfisher 11y ago
Yes, it is broken, which is why it no longer exists in the install-gating form starting with Android 6.0.
habosa 11y ago
Sure on Lollipop it doesn't work anymore but they could be trying to get some of this information from phones on KitKat and below, which are a solid chunk of the market.
spacemanmatt 11y ago
It could be both. The app permission system is almost totally broken.
on_and_off 11y ago
I remember having to use GET_TASKS a couple of years ago (before Lollipop) on a well known app (tenths of millions of users). IIRC, I needed to identify a couple of states : - when the user is on the lockscreen. - when the user is in another app. - when the user is in our app. - when the screen is off. There were business reason behind this for a complex feature, nothing to do with the user's data. The Android team does not want android devs to access to their own app UI state because 'the business logic should not have to depend on that' ... Fair enough in theory but in practice there are a couple of times when you just need it. For example even the Chromecast sample uses a ugly hack to access this piece of information (put a timer behind start/stop activity events). I remember that a coworker had to revamp this piece of code recently for Marshmallow but I don't remember the details. Google finally has a working permission model with Marshmallow : protect the private data behind popups, everything else is fair game. It is not perfect by any means since users still tend to click yes on any popup ... but that's the best we can do IMO.

jagger27 11y ago

I don't even understand why they need local access to figure this out. Poll the web API for last_login and be done with it. Surely they're already tracking and storing this kind of data on their end.

fsargent 11y ago
It's so they can quickly switch between the most recently used maps application like Waze or Google Maps for drivers.
- deleted 11y ago
  [deleted]
- alanh 11y ago
  Please don’t state speculation as fact.
  - andrewstuart2 11y ago
    What makes you think they don't/didn't work for Uber? Seems a bit speculative to me.
    - hk__2 11y ago
      OP should provide a source for their statement. But if you want to go this way, their LinkedIn profile shows they never worked for Uber.
- Buge 11y ago
  But StavrosK just claimed it doesn't work that way. He said that it will only tell you about instances of your own app, not others (such as Waze or Google Maps).
rhizome 11y ago
Does the app log in every time it starts up, or does it just have a stored access token that is simply supplied with future requests regardless of whether it's been 5 hours or 5 months?
- iofj 11y ago
  Given what the uber app does when it starts up (show you a map of your locations, with data from a few uber cars moving across it), I'd bet the app essentially contacts the servers immediately when it starts. The only this would get them is "how many times did a user try to get an uber without data connectivity" ...
  - lwf 11y ago
    And even then, you could keep that record in local storage.
  - rhizome 11y ago
    Contacting servers is one thing, logging in is another. No authentication conversation needs to occur if the auth model is based on access tokens like generic OAuth flow.
Zombieball 11y ago
Doesn't uber have tight integration with other apps that could be running? e.g. Google maps? I assume the handoff from Google Maps doesn't require any kind of check to running apps from Uber, but I am curious if it is something along these lines.
- takno 11y ago
  It does. The main reason I ended up uninstalling uber was because I didn't like it polluting my directions searches with adverts which didn't tell me anything I couldn't already have gotten from the driving directions
bkjelden 11y ago
Why make a network call if the device can give you that information locally?
- jonathankoren 11y ago
  First, you're making a network call anyway, because that's what apps do, so the data is implicit. You simply group by user id and subtract the timestamps of the requests. But let's say for some reason, you can't collect app-open timestamps. What could you possibly want to do with it locally? Say, "Hey it's been x days since you last used me. Thanks for coming back!"? These are stats you want in aggregate, which means sending the data back to the servers for actual data analysis. You're not going to do that analysis -- or any analysis -- on the device, since there's nothing to compare to.
  - bkjelden 11y ago
    Yes, but if the data of when the app was last opened is needed to make more network calls, or to just show the user something in general, you're looking at a network call with round trip latency and a success rate <100%, vs. a device call that takes <1ms and succeeds every time.
    - jonathankoren 11y ago
      Put the last opened time on the initial authorization response. We could go round and round like this. Give me a concrete use case, because for the life of me I can't come up with one that isn't simply superfluous chrome.
  - deleted 11y ago
    [deleted]
- sangnoir 11y ago
  Because Uber's primary functionality depends on network calls. To me, it's pretty obvious they want to find out if you opened the Lyft app recently.

dlubarov 11y ago

This page has more detail on Android's permissions model: http://developer.android.com/guide/topics/security/permissions.html#perm-groups http://developer.android.com/guide/topics/security/permissio... I don't really understand the point of having fine-grained permissions (like READ_CONTACTS), when the user only sees broader permission groups. Can someone shed light on this?

theoduino 11y ago
"Simplified Permissions" is a relatively new feature of the Play Store and only gives you general permission categories. It was probably changed from the older specific permissions to make it less complex for people who didn't care as much. Note that PackageInstaller still shows all permissions, which is used when clicking on an apk or using a 3rd party app store (like F-Droid). Due to backwards compatibility, this can't be changed easily at the OS level.
tadfisher 11y ago
It wasn't always this way. The individual permissions used to be displayed to the user directly; newer releases of the Play Store have "streamlined" this permissions prompt so that users see general permissions "groups", and some permissions (such as INTERNET) are considered "not dangerous", requiring a click on the "See all permissions" button to view everything the app requests. I imagine it's because Google recognized the general insanity of the system, and presenting fewer "scary" permissions improved conversion rates. Then they threw the whole system out with Android 6.0, moving to a much more sane flow for everyone involved, where the user is able to grant or deny individual permissions at runtime.
- profeta 11y ago
  > system is broken and UI is confusing, protect nothing from user even if working right. > leave system broken but hide UI so nobody cares. hopefully, it is just incompetence, not evil.
  - newjersey 11y ago

tadfisher 11y ago

Yes, it is broken, which is why it no longer exists in the install-gating form starting with Android 6.0.

habosa 11y ago

Sure on Lollipop it doesn't work anymore but they could be trying to get some of this information from phones on KitKat and below, which are a solid chunk of the market.

spacemanmatt 11y ago

It could be both. The app permission system is almost totally broken.

on_and_off 11y ago

I remember having to use GET_TASKS a couple of years ago (before Lollipop) on a well known app (tenths of millions of users). IIRC, I needed to identify a couple of states : - when the user is on the lockscreen. - when the user is in another app. - when the user is in our app. - when the screen is off. There were business reason behind this for a complex feature, nothing to do with the user's data. The Android team does not want android devs to access to their own app UI state because 'the business logic should not have to depend on that' ... Fair enough in theory but in practice there are a couple of times when you just need it. For example even the Chromecast sample uses a ugly hack to access this piece of information (put a timer behind start/stop activity events). I remember that a coworker had to revamp this piece of code recently for Marshmallow but I don't remember the details. Google finally has a working permission model with Marshmallow : protect the private data behind popups, everything else is fair game. It is not perfect by any means since users still tend to click yes on any popup ... but that's the best we can do IMO.