Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Popular iPhone and iPad Apps Snooping on the Pasteboard

mysk.blog

Post reply on HN
Print view View original

101–107 of 107 posts

Re: Popular iPhone and iPad Apps Snooping on the Pasteboard

#101

Post by woobar »

Marsymars wrote: post #55
woobar wrote: post #31

Accuweather — com.yourcompany.TestWithCustomTabs Off topic. I can't imagine how did they shipped this app with this BundleId.

Presumably it got developed as such, and it never got prioritized before release. "Okay we've finished all the must-haves just in time for our release deadline but the name for our app in our code isn't really configured correctly." "How long will it take to fix?" "Maybe a week to update our CI environments and be confident that there aren't any regressions related to dependencies on the thing that we're changing, bu…

I get this for a scrappy startup trying to move fast. But this app (pretty decent, btw) is 10+ years old.

Re: Popular iPhone and iPad Apps Snooping on the Pasteboard

#102

Post by wool_gather »

stefan_ wrote: post #24
wool_gather wrote: post #17

I wouldn't be surprised if the apps themselves were not directly responsible here -- that is, the code that's written directly by the app developers. Instead, it may very well be be some analytics/marketing SDK that has been included in the app because of a business request. These have no privilege separation: they run their code in the same context as the code that the app developers wrote. (Consider the example of…

"We shipped a trojan and code-signed it, but it's okay, it is some blob from a vendor that we included just because. We should talk to Bob from marketing to make sure it's not doing bad things." No.

I think you got my point backwards. I wasn't justifying including bad code.

> ...we included just because...

Bob from marketing is the one who asked for the integration.

> We should talk to Bob from marketing to make sure...

Bob has no clue about this stuff.

We're not asking Bob what the SDK is doing, we're telling him. And any other decision makers in the vicinity.

Then we see whether the decision about the SDK changes. If not, we have to make our own personal ethical decision about what to work on.

Re: Popular iPhone and iPad Apps Snooping on the Pasteboard

#103

Post by wool_gather »

woobar wrote: post #101
Marsymars wrote: post #55

Earlier quoted context omitted.

Presumably it got developed as such, and it never got prioritized before release. "Okay we've finished all the must-haves just in time for our release deadline but the name for our app in our code isn't really configured correctly." "How long will it take to fix?" "Maybe a week to update our CI environments and be confident that there aren't any regressions related to dependencies on the thing that we're changing, bu…

I get this for a scrappy startup trying to move fast. But this app (pretty decent, btw) is 10+ years old.

It's effectively impossible to fix this once it's been shipped, though. The bundle ID is the fundamental identifier of the app to the whole system. If they were to change it, they would end up with a completely separate app in the app store. They would have no way (at least no way that's not nasty and convoluted) to move user data from the old one to the new one.

Re: Popular iPhone and iPad Apps Snooping on the Pasteboard

#105

Post by cortesoft »

saagarjha wrote: post #79
cortesoft wrote: post #51

Earlier quoted context omitted.

Would that mess up things users actually copied?

You can read the pasteboard without messing it up, and then replace the contents back to what they used to be.

But don't you have to update the paste contents, and then wait for the other process to read them and update the paste contents to tell the original process that the message was received?

Re: Popular iPhone and iPad Apps Snooping on the Pasteboard

#106

Post by kennywinker »

saagarjha wrote: post #72
kennywinker wrote: post #28

The pasteboard API is essentially the same in iOS as it is in macOS. Which means it's an api that was likely designed more than 20 years ago. Because of that, it was not designed for the user-hostile app world we live in, where developers will harness any api that can leak data about the user. A solution to this is to re-design this api so that it allows developers to query for specific matches, but requires user-act…

> A solution to this is to re-design this api so that it allows developers to query for specific matches, but requires user-action to unlock them I.e. I can passively ask "does the clipboard contain a photo?" or "does the clipboard contain a url in the *.facebook.com domain?" but in order to get the contents I have to prompt the user to manually paste. I fully expect apps to try to leak information bit-by-bit to the…

Addressed by the next bit in my post: force developers to list their queries in the info plist. Only allow those queries. Validate that the query list is not malicious during app review.

Re: Popular iPhone and iPad Apps Snooping on the Pasteboard

#107

Post by walterbell »

saagarjha wrote: post #73
walterbell wrote: post #23

Earlier quoted context omitted.

The permissions can be unidrectional, e.g. password manager grants permission to a specific app for the next N seconds. Similar to "add photo" permission.

How would the password manager know which app you’re going to paste the password into?

The OS could provide a whitelisting API and an "app picker" to the user. The password manager app itself need not know the destination app, the OS could manage the binding. The password manager could invoke an OS API to create each association, with user-OS input for app selection. This whitelist approach would be similar to SE Linux or other mandatory access control systems.

This kind of inter-app policy could also be useful for opening URLs, e.g. open all URLs from untrusted app A in Brave browser where Javascript can be easily whitelisted on a per-site basis.

Post reply on HN