3 ms·
I write native apps. They can "fingerprint" devices more easily. They have access to all kinds of subsystems, like Bluetooth, NFC, gestures (at low level), etc
by ChrisMarshallNY 11mo ago
I write native apps.
They can "fingerprint" devices more easily. They have access to all kinds of subsystems, like Bluetooth, NFC, gestures (at low level), etc. Many require the user to give permission, but the first thing the app does, is ask for permission. As long as the statement in the request passes Apple muster, the app won't fail review, I seriously doubt that Apple will test after the app has shipped, to make sure that they stick to their word.
Some of this can be caught by the App Review process, if they do things like access private APIs, but we keep reading about clever app developers (and there are a lot of really smart crooks out there) that can fool the App Review testers. I read about a dodgy app that detected when it was in review, and modified its behavior (ala Volkswagen).
Really, I am not sure if there's a way to ensure the app works the same after review, than during. I would probably put a 4-day timer on it, starting the day of submission. After the timer expires, the app starts accessing private APIs via a hand-coded assembly interface. I would hope that Apple has already thought about this (It wouldn't be too difficult to test -just run it on a device with an advanced clock).
- raw_anon_1111 11mo ago> They can "fingerprint" devices more easily. They have access to all kinds of subsystems, like Bluetooth, NFC, gestures (at low level), etc. Many require the user to give permission, but the first thing the app does, is ask for permission Bluetooth https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo... Accelerometer https://developer.mozilla.org/en-US/docs/Web/API/Accelerometer https://developer.mozilla.org/en-US/docs/Web/API/Acceleromet... So it’s a great conspiracy that apps have permission to do things after you explicitly give it permission? No one is claiming that the app review process helps protect your privacy. The challenge is find something a native app can do surreptitiously to track you more than a website without you giving it permission bypassing OS safeguards. And on iOS an app can’t access your NFC chip without you giving it permission.
- deleted 11mo ago[deleted]
- ChrisMarshallNY 11mo agoNot just the NFC chip. Almost every I/O system requires explicit permission. That’s where a “social engineering” approach can be helpful. The permission request can be quite bland, to a non-technical person. And yes, a native app with the program counter can definitely do stuff a Web site can’t. Run machine code, for instance. We would hope the app sandbox is good enough to catch it.
- raw_anon_1111 11mo agoWhich permission is bland on iOS? “Running machine code” is not a security vulnerability. If your browser isn’t secure all sorts of exploits can happen from a web browser. That’s how a lot of the early iOS jailbreaks worked.
- ChrisMarshallNY 11mo agoI think we’re probably not getting anywhere here. No problem, but we can each do our own thing. If you are in the US, have a great Thanksgiving holiday. I sincerely hope it’s a warm, loving event.
- raw_anon_1111 11mo agoIt was a very simple request - show an example? Everyone commenting here is being hand wavy
- ChrisMarshallNY 11mo agoI stated an example. It was not enough. I used to write machine code, but I don’t, anymore. I am quite aware of how powerful it is, so I have to assume that the very smart people at Apple -who deal with current-day machine code- have a handle on dealing with it. I guarantee that hackers do.
- raw_anon_1111 11mo agoYou didn’t state one example where it bypassed the sandbox. All apps on iOS are compiled to assembly. If writing in assembly magically bypasses a well designed OS’s security model, we are in trouble