If Lumicast / QUIP is included in the release, then access to this feature ought to be controlled by prior user authorization

[Rudd-O]

Qualcomm has come up with a very invasive technology that uses vision sensors (camera / light) on the phone to track EXACTLY where you are, say, on a mall / on a street / et cetera, it doesn't matter. It's called QUIP, the brochure is at https://www.qualcomm.com/media/documents/files/lumicast-whitepaper.pdf , and it says:

In this paper we introduce a new technology, called Lumicast, for mobile device positioning in indoor environments. The
technology uses LED light fixtures to broadcast positioning signals via amplitude modulation of light in a way that does not impact
the fixtures’ primary function of providing illumination. A mobile application that incorporates the Lumicast software framework
can decode these Visible Light Communication signals and use them to determine the position of the mobile device. Given its
compatibility with existing smartphone devices and LED lighting infrastructure, this technology is able to support a broad range of
indoor positioning applications in commercial, office and industrial settings, and has been adopted by leading players in the LED
lighting ecosystem such as Acuity Brands [1], [2] and GE Lighting [3].

This appears to be shipping, secretly, on stock Android, or at least on tons of vendor phones. It is unclear what permissions it has, but at the very least it appears to have permissions to read light from your surroundings at a high-enough frequency that it's viable. The transmitter / modulator side is very simple and probably quite cheap to manufacture, which is probably a good reason to believe that this is already widely deployed.

This is not something I'd like to have on my phone.

Can Copperhead make sure this sort of thing isn't in its OS?

Thanks in advance.

[thestinger]

You should be more worried about https://www.qualcomm.com/products/izat.

[thestinger]

You should be more worried about https://www.qualcomm.com/products/izat.

[thestinger]

This stuff is present in their blobs but there's nothing triggering it to run by default. It's simply platform functionality that's available. Google didn't develop SELinux policy to allow this stuff to work anyway.

[thestinger]

This stuff is present in their blobs but there's nothing triggering it to run by default. It's simply platform functionality that's available. Google didn't develop SELinux policy to allow this stuff to work anyway.

[Rudd-O]

Thanks for your response but I'm not sure I understand.

1. Is this stuff in Copperhead? How does one go about finding out?
2. What stops an app from calling into QUIP and therefore activating it?

[Rudd-O]

Thanks for your response but I'm not sure I understand.

1. Is this stuff in Copperhead? How does one go about finding out?
2. What stops an app from calling into QUIP and therefore activating it?

[Rudd-O]

Also note that iZat doesn't work indoors. It isn't clear to me when they talk about their SnapDragon processors having the technology in — do they mean it's running constantly, do they mean it casts that information somewhere?

This is spy movie stuff, honestly.

[Rudd-O]

Also note that iZat doesn't work indoors. It isn't clear to me when they talk about their SnapDragon processors having the technology in — do they mean it's running constantly, do they mean it casts that information somewhere?

This is spy movie stuff, honestly.

[thestinger]

An app can't do anything with these blobs that it can't already do itself. They're just there.

[thestinger]

An app can't do anything with these blobs that it can't already do itself. They're just there.

[thestinger]

All they mean by this technology being present on Qualcomm SoC devices is that vendors could teach the OS to leverage it if they wanted to. It doesn't mean that it does or that it's exposed to apps. Totally different from the functionality simply being available in unused proprietary code.

[thestinger]

All they mean by this technology being present on Qualcomm SoC devices is that vendors could teach the OS to leverage it if they wanted to. It doesn't mean that it does or that it's exposed to apps. Totally different from the functionality simply being available in unused proprietary code.

[Rudd-O]

Yes, I understand. Does this ship as an app with privileges? If another app were to use these blobs as itself, it'd be clear what the app is doing (mischievously) by requesting light sensor or camera permissions. But if there's an independent app installed in the system, then that app has its own permissions and can do what the system has granted, no?

[Rudd-O]

Yes, I understand. Does this ship as an app with privileges? If another app were to use these blobs as itself, it'd be clear what the app is doing (mischievously) by requesting light sensor or camera permissions. But if there's an independent app installed in the system, then that app has its own permissions and can do what the system has granted, no?

[Rudd-O]

(Note that QUIP is a software technology, which surely leverages Qualcomm hardware, but it surely isn't necessary to run Android proper.)

[Rudd-O]

(Note that QUIP is a software technology, which surely leverages Qualcomm hardware, but it surely isn't necessary to run Android proper.)

[thestinger]

I don't think a permission is required to access any of the sensors anyway. It's already exposed to every app whether or not Qualcomm has unused libraries / services for leveraging the sensor data.

[thestinger]

I don't think a permission is required to access any of the sensors anyway. It's already exposed to every app whether or not Qualcomm has unused libraries / services for leveraging the sensor data.

[thestinger]

It's already known that location can be tracked via the compass combined with the accelerometer, and no permissions are required. I'm not going to allocate time to looking for theoretical Qualcomm functionality that in all likelihood does not exist in a form that can actually do anything on Nexus devices.

[thestinger]

It's already known that location can be tracked via the compass combined with the accelerometer, and no permissions are required. I'm not going to allocate time to looking for theoretical Qualcomm functionality that in all likelihood does not exist in a form that can actually do anything on Nexus devices.

[thestinger]

See #377.

[thestinger]

See #377.

[Rudd-O]

Android requires permission for the cameras.

There's a android.hardware.sensor.light too.

I am unsure whether defeating these permissions would kill apps that include the QUIP library (which, for some reason, appears to ship on CyanogenMod as well as >3 billion other devices according to what the Web says). They do not make it clear exactly how their technology works — I suspect that's deliberate — but it doesn't seem like it goes through location services. There seems to be no way to disable it via permissions.

I understand you don't want to spend time doing this sort of work. I felt this would be important to you because this is a proprietary app that doesn't have any useful (for the user) or required functionality. But I do have to say this isn't a theoretical thing.

Sorry to hear you're closing the issue.

[Rudd-O]

Android requires permission for the cameras.

There's a android.hardware.sensor.light too.

I am unsure whether defeating these permissions would kill apps that include the QUIP library (which, for some reason, appears to ship on CyanogenMod as well as >3 billion other devices according to what the Web says). They do not make it clear exactly how their technology works — I suspect that's deliberate — but it doesn't seem like it goes through location services. There seems to be no way to disable it via permissions.

I understand you don't want to spend time doing this sort of work. I felt this would be important to you because this is a proprietary app that doesn't have any useful (for the user) or required functionality. But I do have to say this isn't a theoretical thing.

Sorry to hear you're closing the issue.

[thestinger]

It is a theoretical thing. There's no app on the system doing this, and no service in any of the init scripts.

[thestinger]

It is a theoretical thing. There's no app on the system doing this, and no service in any of the init scripts.

[thestinger]

If it's a baseband feature, then there's nothing that we could do about it anyway and that also means it's present on iPhones too, other than the very new Intel baseband variants.

[thestinger]

If it's a baseband feature, then there's nothing that we could do about it anyway and that also means it's present on iPhones too, other than the very new Intel baseband variants.

[thestinger]

Qualcomm releasing information showing the capabilities of their hardware makes sense and shouldn't be scary. The fact that their hardware can be used to do these things via their SDK doesn't mean that it is sitting there doing this without your knowledge.

[thestinger]

Qualcomm releasing information showing the capabilities of their hardware makes sense and shouldn't be scary. The fact that their hardware can be used to do these things via their SDK doesn't mean that it is sitting there doing this without your knowledge.

[Rudd-O]

I understand no app in the system uses this thing. It would be a good thing to deny use of this thing to newly-installed apps, unless they have been duly authorized by the user of the device. The question is whether this thing is accessible to apps by (a) talking to a kernel device that can be denied via permissions (b) using CPU instructions that cannot be denied via permission. If it's the first, then the device can be made to go away by removing the QUIP malware. If it's the second, then we're all screwed anyway. The docs for this antifeature do not make it clear what is the case.

[Rudd-O]

I understand no app in the system uses this thing. It would be a good thing to deny use of this thing to newly-installed apps, unless they have been duly authorized by the user of the device. The question is whether this thing is accessible to apps by (a) talking to a kernel device that can be denied via permissions (b) using CPU instructions that cannot be denied via permission. If it's the first, then the device can be made to go away by removing the QUIP malware. If it's the second, then we're all screwed anyway. The docs for this antifeature do not make it clear what is the case.

[thestinger]

It's not clear that the feature actually exists beyond the sensors and associated libraries existing, which makes it theoretically possible to implement location enhancements for indoor positioning but it doesn't mean that anyone does and it's not really any creepier than GPS access being available.

[thestinger]

It's not clear that the feature actually exists beyond the sensors and associated libraries existing, which makes it theoretically possible to implement location enhancements for indoor positioning but it doesn't mean that anyone does and it's not really any creepier than GPS access being available.

[thestinger]

android.hardware.sensor.light is a feature, not a permission. As in https://developer.android.com/guide/topics/manifest/uses-feature-element.html.

Even if it was a permission, it wouldn't be a dangerous permission, so Android wouldn't prompt the user to request it. Non-dangerous permissions are essentially hidden. You can only see them in advanced menus and they aren't really meant to make any sense to users.

[thestinger]

android.hardware.sensor.light is a feature, not a permission. As in https://developer.android.com/guide/topics/manifest/uses-feature-element.html.

Even if it was a permission, it wouldn't be a dangerous permission, so Android wouldn't prompt the user to request it. Non-dangerous permissions are essentially hidden. You can only see them in advanced menus and they aren't really meant to make any sense to users.

[Rudd-O]

GPS access is subject to a toggle. Based on what we've discussed here, indoor positioning technologies are not (a dream for whomever wants to spy on you and your whereabouts).

Sorry man, GPS access is substantially less creepy than QUIP and related tech (like the compass plus accelerometer creepometer).

[Rudd-O]

GPS access is subject to a toggle. Based on what we've discussed here, indoor positioning technologies are not (a dream for whomever wants to spy on you and your whereabouts).

Sorry man, GPS access is substantially less creepy than QUIP and related tech (like the compass plus accelerometer creepometer).

[thestinger]

Yet in all likelihood, no one is going to submit a patch implementing that sensor access toggle feature.

[thestinger]

Yet in all likelihood, no one is going to submit a patch implementing that sensor access toggle feature.

[Rudd-O]

Oh, yeah, on that part, we agree. Still, let's not distort our reality just because we can't find someone who can contribute to change it in a positive way.

[Rudd-O]

Oh, yeah, on that part, we agree. Still, let's not distort our reality just because we can't find someone who can contribute to change it in a positive way.

[thestinger]

Well, agree that this is a problem just not convinced that it's a separate problem from sensor access, unless someone can demonstrate otherwise.

[thestinger]

Well, agree that this is a problem just not convinced that it's a separate problem from sensor access, unless someone can demonstrate otherwise.

[Rudd-O]

It depends. Do developers need to merely get sensor access in order to get access to this antifeature? I donno. Maybe, maybe not.

You may want to document in the other bug this particular antifeature as something that is related to it, but we do not yet know if defeating sensors for apps will defeat this antifeature. What if the antifeature is accessible via a few CPU instructions in some proprietary blob? No permissions or feature flags will mediate access to it.

Come to think of it, that does make for a nice argument to remove that blob from the OS that Copperhead ships. If no app is gonna use that, then why does Copperhead need to carry it? That is MEANT to be their software-side implementation of their antifeature. Which was the point of this bug to begin with — to kill that.

[Rudd-O]

It depends. Do developers need to merely get sensor access in order to get access to this antifeature? I donno. Maybe, maybe not.

You may want to document in the other bug this particular antifeature as something that is related to it, but we do not yet know if defeating sensors for apps will defeat this antifeature. What if the antifeature is accessible via a few CPU instructions in some proprietary blob? No permissions or feature flags will mediate access to it.

Come to think of it, that does make for a nice argument to remove that blob from the OS that Copperhead ships. If no app is gonna use that, then why does Copperhead need to carry it? That is MEANT to be their software-side implementation of their antifeature. Which was the point of this bug to begin with — to kill that.

[thestinger]

How do you know there's actually a blob implementing this feature, rather than them simply considering sensor access to provide this? You're not asking me to do something specific. Remove which blob? I highly doubt there is anything like this exposed via 'CPU instructions'. It's not how this stuff is implemented.

[thestinger]

How do you know there's actually a blob implementing this feature, rather than them simply considering sensor access to provide this? You're not asking me to do something specific. Remove which blob? I highly doubt there is anything like this exposed via 'CPU instructions'. It's not how this stuff is implemented.

[Rudd-O]

I do not know whether CopperheadOS ships that blob, but I know the blob exists. I know that the Fairphone carries that blob, and that blog comes from "upstream", according to the bug report where this was discussed.

I did ask you to do something quite specific, in the original title of the bug report. Make sure that QUIP is not available as a blob because it does not provide any useful service to CopperheadOS.

Here is the relevant information:

nvllsvm/freecyngn#18 (comment)

Always happy to discuss this.

[Rudd-O]

I do not know whether CopperheadOS ships that blob, but I know the blob exists. I know that the Fairphone carries that blob, and that blog comes from "upstream", according to the bug report where this was discussed.

I did ask you to do something quite specific, in the original title of the bug report. Make sure that QUIP is not available as a blob because it does not provide any useful service to CopperheadOS.

Here is the relevant information:

nvllsvm/freecyngn#18 (comment)

Always happy to discuss this.

[thestinger]

You aren't telling me what you want me to remove, and you don't actually know that there's anything present or what it is. Figure out what you want me to do, and then make the request.

[thestinger]

You aren't telling me what you want me to remove, and you don't actually know that there's anything present or what it is. Figure out what you want me to do, and then make the request.

[thestinger]

I'm not going to do research on theoretical problems.

[thestinger]

I'm not going to do research on theoretical problems.