Hacker News Reader

Comment by drdaeman | Hacker News Reader

> To better ensure privacy, Android P restricts access to mic, camera, and all SensorManager sensors from apps that are idle.

Good. Now, if only permissions could be granted temporarily (e.g. "allow for this session", which auto-revokes after 5-60 minutes of not using the application), it'll be perfect.

> We will also enable encryption of Android backups with a client-side secret.

Is this about BackupManager? Awesome if so. (BTW, have anyone ever heard of any alternative BackupTransports, besides Google Drive?)

> Android P also gives the user control over access to the platform's build.serial identifier by putting it behind the READ_PHONE_STATE permission.

IMHO, they should've really split that in two different permissions and deprecate READ_PHONE_STATE. Device identifiers (including SIM card identities) and phone state ("someone's calling") are two different things.

View on HN

FYI, what you're calling phone state (someone's calling) is actually call state (https://developer.android.com/reference/android/telephony/Te...) which does not require READ_PHONE_STATE. That permission seems mostly used for things like protecting SIM card identities.

"Good. Now, if only permissions could be granted temporarily (e.g. "allow for this session", which auto-revokes after 5-60 minutes of not using the application), it'll be perfect."

This would be nice.

Yes. There's so many apps that want to manage my SMSes just so they can authorise. It's a nice and convenient feature, but they only need to authorise once. Why should they have permission to manage my SMSes for days and weeks and years afterwards? Short-term permission would be nice, and should be the default. If the app needs the permission for a second session, then it should potentially receive it permanently.

There is API specifically for that - https://developer.android.com/reference/android/telephony/Sm...

I'm torn about this. Every time an app has used this API, it's been a delight. And yet I hesitate to encourage more people to use SMS as auth!

This is available only on Android O and the adoption is not encouraging. Hopefully, P will have a much better uptake.

Does restricting access to the mic from idle programs also conveniently prevent any competition to Google Assistant?

That's kind of unsettling because it seems Google is doing a lot of data collection through their home speakers.

An anecdote:

I got a little creeped out at assistant / home and disabled all the tracking. Almost immediately my Android phone started harassing me to turn permissions back on through my phone. And Google Home refused to do anything with tracking off. It responded to all wake prompts with "you need to change settings".

I'm sure this being Android you'll be able to whitelist apps to allow background data collection. You'll just need to find the right setting.

Hotword detection has been a private API since it was introduced. You can't use it unless your app is signed by Google. Android P doesn't seem to change this at all.

Not really, you will just need a foreground service, which you would have needed anyway.

Google has been pretty fair as far as Android APIs go, even the API analyzing your current view hierarchy is open to anybody to implement (IIRC there is of course a big permission dialog to show before allowing an app to use it)

I'd like to see baseline Android block clipboard access from background apps a la Copperhead OS.

How about requesting clipboard access in the first place?

> Now, if only permissions could be granted temporarily

This flow would be much nicer but you can go in and revoke a permission later in App Permissions (not sure how many people know this).

I know. This is what I do every time there's an app that needs accidental one-time camera or GPS access, but not a trustworthy enough to be granted those permanently. Like a banking app that can show me nearby ATMs when I need one (but then I don't want to even theoretically permit my bank to obtain my location outside of this scenario).

Not convenient, as it requires a) not forgetting to revoke when done and b) a series of taps.

> Like a banking app that can show me nearby ATMs when I need one

Android needs an intent for "get current location" rather than "always have access to location". Apps don't need camera permission to let the user capture one image from the camera, only to autonomously control the camera themselves. Similarly, an Android app should have the ability to request one current location fix, for this kind of purpose, and have that trigger an interactive request with a map. (That also makes it easy to do "look for ATMs near where I'm going to be this afternoon".)

Better yet, the app could expose a "points of interest" interface, and then Google Maps or another maps app could make those points of interest available.

Great idea !

You would not even need any change to the OS itself, just a new intent implemented by all locations apps.

I'm curious, does anyone have a list of apps that would have legitimate use of sensor data in the background?

What about a baby monitor app? Is the app considered backgrounded when the screen is off?

I was hoping we could use old phones as IP cameras with the screen turned off. I hope apps that are last in the foreground can continue to access camera and microphone and sensors with the screen turned off -- at least when connected to power.

Fitness apps.

Yup, these will now have to run a foreground service or be part of the platform.

I recently wrote an Android Wear app for someone who wanted sensor data recorded in the background for legitimate medical research.

I would assume upgrading to P will break that app.

Prolly not for wear apps. Those are all about biometric data collection...

Quantified self apps e.g. Human, Moves.

I personally enjoy exploring long-running GPS logs of myself. Interesting patterns, hotspots, etc.

(not sure if those two apps cover that in particular, but yeah - quantified self in any form is a perfect example)

A "Google Assistant" competitor.

1. Apps that track sensor data to determine sleep quality or other nonstandard movement calculation (and thus can't use alternative step counting API's)

2. I'm working on an app that constantly records audio in the background and later allows me to search for things I might have said throughout the day

3. Apps that track location long-term, like the defunct Moves app. Sure it kills the battery and is a major privacy concern so it should be opt-in, but I personally love this functionality and I'm sad there doesn't seem to be a modern equivalent (Google Maps location history is less accurate and there's no good API). Apps that record location short-term like MapMyRun do not solve the same problem.

... I'm sure there's other use cases. I kind of feel like the only developers allowed to really innovate on mobile anymore are Google (and Apple) themselves. Bad developers abusing privacy/battery/data have made it so Google/Apple have to lock down anything interesting. It's frustrating, because the current state of affairs is definitely better than the free-for-all it used to be, but I wish I had more control to override what my own device is able to do.

Sounds like all these apps can use a foreground service to do that.

Am I missing something ?

The only case I see this change not covering is apps like Cerberus. They would need to ask their users to go to settings and hide their notification. Not the nicest UX, but that's a pretty rare use case.

Define foreground/background.

If I’m using Strava and Spotify I don’t want either to stop working when I switch to the user interface of the other one.

A foreground service needs to display a notification.

Not really an issue for Spotify since media apps want to display the media notification anyway.

For other apps, the idea is that foreground services should be visible to the user. One of the reasons would be this very capability to access sensors.

Another difference between foreground and background is that a background service is eligible to be killed on low memory events.

#2 sounds super interesting to me. Is it open source?

Well it's also my first foray into Android development since Google Glass years ago, so not much good source to share. Maybe someday if I get it in a state where it works and isn't too embarrassing, I may open source it.

Regardless it's encouraging to hear that other people find this interesting, most of the feedback has been along the lines of "that's so creepy/illegal"

#2 sounds brilliant, so many times I've wished I could Ctrl+F for things in conversations I had earlier in the day.

Isn't #2 likely to be illegal in many states?

For #2, how do you avoid recording all the things people around you are saying throughout the day? Custom microphone to minimise picking up surrounding sounds? Some kind of speaker recognition to identify and isolate your own voice (does that work when you have a cold)?

And if you're not avoiding recording other people, how do you succinctly notify everyone in capture range that you are recording them?

This seems problematic from a standpoint of social norms and etiquette. In public/shared space contexts people know they can be heard by bystanders, but that is very different from being recorded and having your utterances indexed for later retrieval.

We are developing an app that does #3 (Smarter Time) and manage it with a foreground service. The constant notification is slightly annoying for some users, but overall it works well and does not use too much battery (after tons of tweaks and optimizations)

Reply on news.ycombinator.com