41–50 of 93 posts
This is why apps that shouldn't need the mic or speaker but still require it should not be installed. Permissions on an app should be checked carefully by a user, and users should be educated in this!
cough youtube cough
False, on Android
Earlier quoted context omitted.
That model is backwards. If there is one thing iOS got right, it's the permission prompt. Nobody reads those lists and it's hard to know what the intent is without context in the app. Having the app ask on first use makes much more sense. It's much less likely to get away with this. Even better, you can still use the app if you say no. It will just get dummy values back.
On the flip side, this means you have already installed and committed to having this app on your phone. Lots of people might just press "accept" at that point out of being lazy, instead of uninstalling it and going back to the app store to look for an alternative. If you ask me, both should be in place. When I install an app a list of permissions (and a short text next to each from the developer explaining why they n…
Earlier quoted context omitted.
That model is backwards. If there is one thing iOS got right, it's the permission prompt. Nobody reads those lists and it's hard to know what the intent is without context in the app. Having the app ask on first use makes much more sense. It's much less likely to get away with this. Even better, you can still use the app if you say no. It will just get dummy values back.
This works the same since Android 6 (2015)
Earlier quoted context omitted.
18-19 kHz is usually high enough; smartphone speakers can play that fine from my experience. Yes, battery drain is an issue. Most apps use a background service that wakes up at a fixed interval. The longer the interval, the longer the broadcast has to be though, so it's basically a trial and error kind of thing.
Clock sync? Protocol usually is to check NTP and broadcast at prechosen times if you wanna keep the battery drain down.
NTP sounds like it would work. As you kindly noted, just make sure the beacons broadcast at a agreed upon time and in fixed increments.
My first instinct is that the signal probably doesn't need to be ultrasound. In the same way that my phone will sometimes hear my car radio and falsely hear, "hello Google", I bet the beacon can just be planted on top of the signal and match filtered to a decent SNR. Similar to image steganography, it doesn't need to be perceptible to the listener. Compression issues would exist, but at least they wouldn't be fightin…
Earlier quoted context omitted.
This works the same since Android 6 (2015)
Only on apps that target Android 6 however. They couldn't retroactively apply it. Just build your app targeting Lollipop and you get all the permissions you want. Plus their app store isn't as strongly vetted, so apps can refuse to work if you don't grant a bullshit tracking permission.
Earlier quoted context omitted.
That model is backwards. If there is one thing iOS got right, it's the permission prompt. Nobody reads those lists and it's hard to know what the intent is without context in the app. Having the app ask on first use makes much more sense. It's much less likely to get away with this. Even better, you can still use the app if you say no. It will just get dummy values back.
This works the same since Android 6 (2015)
First, there is no sane way to grant permissions "just for a few minutes" rather than forever (unless revoked). E.g. a banking app that has a screen with nearest ATM locations doesn't need GPS access granted all the time - only when I ask for the directions.
Then, there are apps that ask for just about everything (a long sequence of "grant AppName access to something") at startup. It's a subjective opinion but I believe this sort of "fix" to deal with the new permission model on SDK update was quite popular, as I saw it relatively a lot.
And it's good if denying access is an option and you just aren't asked the same thing again until you either give up or kill the app. It's probably not an issue if that's some flashlight app you can uninstall without even thinking about it, but isn't so much when it's an app from your mobile network, allowing you to manage your plan, or something unique enough to be considered valuable.
I see only two options how to fix this for real. First is more and more regulations. Second is improved app isolation and permission spoofing (silent mic input, empty contact list and filesystem, no persistent identifiers across reinstalls, etc), and activity indicators "app is trying to access the camera right now", "app had accessed your contact list recently" that would both raise alarm or allow to grant access, depending on the end-user decision.
> The only good news found in this research was that after searching TV streams from seven different countries, researchers failed to discover any ultrasonic beacons Would that even work? I'm pretty sure modern digital TV audio compression totally removes sound that is vaguely close to 'ultrasound'. I guess maybe smart TV apps could add the signal though, but why would they when they already know what you are watchin…
They'd do it to connect profiles between the TV (which knows what you're watching) and any mobile devices within ultrasound reach (i.e. line of sight) of the TV. Do this a few times and it quickly becomes clear which phone is usually within range of the TV, and with that the profiles can be merged, giving a broader view of the user behind these devices. The solution is simple: don't get a 'smart' television. Better s…
Will that prevent ultrasonic beacons? I assumed the speakers were the same on smart and 'dumb' TVs.