Hacker News Reader

Hacker News

Comment by RedComet | Hacker News Reader

Full thread

RedComet

Volume creation date is pretty egregious. I don't see any reason that and Pasteboard changeCount should be so granular.

The "Installed Apps Probe" leak also surprised me. It is better than the current state of Android, though.

View on HN

Pasteboard counter exists to help apps to not ask again about the same item in the buffer.

And nothing stops from using reset it every day.

Would you elaborate on both points?

Any way to reset it as an end user? (Not enough awareness of the issue for search engines to find much.)

I think something like a per boot delta added to a (per app?) random base would preserve such functionality.

Just generate a new random value instead of incrementing

Even that is overkill if all you're interested in is if a change occured.

What’s an easier way? I’m assuming they want the app to be able to detect when “a”, was copied, then “b” and then “a” again, so just looking at the value probably isn’t enough.

I don’t think an app should have access to that (without some sort of very special permission).

Allowing an app to access the pasteboard without the user explicitly pasting into the app is weird to me. Maybe the thing I have in the pasteboard is not for this app but left over from use in another app. Since there's no easy way to clear the pasteboard, this will happen often. Maybe it's because I'm not an app dev that this doesn't make sense to me????

iOS will ask for pasteboard permission every time an app wants to read the actual contents.

& we can set ask each time, always allow, never allow per app.

Why do you need a count for that? Couldn’t they just generate a UUID every time the clipboard changes?

That’s even worse - now you have a tracking UUID that only changes when the user copies something.

Graphene is way ahead of this

Apps on grapheneos can see a list of other apps in the same profile.

Reply on news.ycombinator.com