Qualcomm XTRA GPS almanac network requests in Device Only Location Mode?

[securesearch]

Noticed that a recent release moved Qualcomm's XTRA (almanac download) network requests for location services to a secure transport which is great. However, it would be nice if there were a GPS mode that didn't include Qualcomm's XTRA services (izatcloud.net/gpsonextra.net) when the device is set in "Device only" location mode.

Would it be feasible to either remove any such background network requests when the device is set to "Device only" mode or include a new mode that relied entirely on GPS signal instead? A test with a fresh device in "Device only" mode with no network connection, never having connected to the XTRA servers got a location fix rapidly and functioned perfectly well, so it would seem that having access to the almanacs aren't really necessary for basic GPS functionality even though they can cut down location fix time.

I am aware that the metadata sent might be minimal, but reducing network requests if possible with a pure GPS mode would not seem out of place for a privacy/security-oriented OS. With no complete on-device firewall allowing for interactive interception of all network traffic, this is the only way to deal with this unless external network equipment is involved.

Thanks (and I understand if there is no time to deal with this, just thought I'd bring it up).

[thestinger]

This is used in the device only location mode. GPS lock takes significantly longer without it. It's not going to be disabled by default.

There's currently no difference between the device-only and full location mode for us since we don't offer supplementary location services. Crippling the GPS is going to make that problem much worse and isn't going to happen as a default.

I don't see a significant problem with fetching static assets over HTTPS.

If you want a toggle for this, you need to propose a realistic / acceptable way of doing it and you need to implement it.

[thestinger]

This is used in the device only location mode. GPS lock takes significantly longer without it. It's not going to be disabled by default.

There's currently no difference between the device-only and full location mode for us since we don't offer supplementary location services. Crippling the GPS is going to make that problem much worse and isn't going to happen as a default.

I don't see a significant problem with fetching static assets over HTTPS.

If you want a toggle for this, you need to propose a realistic / acceptable way of doing it and you need to implement it.

[thestinger]

With no complete on-device firewall allowing for interactive interception of all network traffic, this is the only way to deal with this unless external network equipment is involved.

There is a firewall. There isn't user control over it and it wouldn't work the way people think anyway. People probably think blocking an app / process from accessing the network via iptables prevents it from accessing the network and it really doesn't due to IPC.

I don't see how firewall configuration would allow blocking this anyway since I think it's done by system_server.

[thestinger]

With no complete on-device firewall allowing for interactive interception of all network traffic, this is the only way to deal with this unless external network equipment is involved.

There is a firewall. There isn't user control over it and it wouldn't work the way people think anyway. People probably think blocking an app / process from accessing the network via iptables prevents it from accessing the network and it really doesn't due to IPC.

I don't see how firewall configuration would allow blocking this anyway since I think it's done by system_server.

[securesearch]

I don't see a significant problem with fetching static assets over HTTPS.

This assumes that this is all that occurs, and that headers or separate requests including metadata are not sent.

Even if this is not the case, leaking that a given IP is requesting Qualcomm almanac data at a given time to the ISP, DNS servers, Qualcomm, Amazon (AWS), and the routers along the way (after all, DPI of certs is all that is needed) could be considered sensitive in many circumstances.

Perhaps informing users somewhere that this occurs would be an idea anyhow since "Device only" could be understood by the first time user as GPS signal only, especially if they aren't actively monitoring/intercepting their network traffic.

[securesearch]

I don't see a significant problem with fetching static assets over HTTPS.

This assumes that this is all that occurs, and that headers or separate requests including metadata are not sent.

Even if this is not the case, leaking that a given IP is requesting Qualcomm almanac data at a given time to the ISP, DNS servers, Qualcomm, Amazon (AWS), and the routers along the way (after all, DPI of certs is all that is needed) could be considered sensitive in many circumstances.

Perhaps informing users somewhere that this occurs would be an idea anyhow since "Device only" could be understood by the first time user as GPS signal only, especially if they aren't actively monitoring/intercepting their network traffic.

[thestinger]

It's not an assumption.

Perhaps informing users somewhere that this occurs would be an idea anyhow since "Device only" could be understood by the first time user as GPS signal only, especially if they aren't actively monitoring/intercepting their network traffic.

It is GPS signal only. Downloading that data isn't connected to that setting and provides data for the GPS location method not others.

[thestinger]

It's not an assumption.

Perhaps informing users somewhere that this occurs would be an idea anyhow since "Device only" could be understood by the first time user as GPS signal only, especially if they aren't actively monitoring/intercepting their network traffic.

It is GPS signal only. Downloading that data isn't connected to that setting and provides data for the GPS location method not others.

[securesearch]

People probably think blocking an app / process from accessing the network via iptables prevents it from accessing the network and it really doesn't due to IPC.

I wasn't really thinking of iptables per se, but considering more specialized solutions that are available on various desktop OSes. IPC of course is an issue.

There are options out there for desktop OSes that include complete per-process interception of DNS resolutions, any network request on any interface, IPC, and extend to interactive filesystem interception beyond static access controls. Of course these are paid solutions that require kernel modules which brings a whole host of other problems.

I am of course not suggesting that this be something for CopperheadOS, but just highlighting that solutions for user interactive full per-process network stack control do exist out there and that despite the issues implementations do bring, from a privacy and user control standpoint it can be exceedingly valuable.

[securesearch]

People probably think blocking an app / process from accessing the network via iptables prevents it from accessing the network and it really doesn't due to IPC.

I wasn't really thinking of iptables per se, but considering more specialized solutions that are available on various desktop OSes. IPC of course is an issue.

There are options out there for desktop OSes that include complete per-process interception of DNS resolutions, any network request on any interface, IPC, and extend to interactive filesystem interception beyond static access controls. Of course these are paid solutions that require kernel modules which brings a whole host of other problems.

I am of course not suggesting that this be something for CopperheadOS, but just highlighting that solutions for user interactive full per-process network stack control do exist out there and that despite the issues implementations do bring, from a privacy and user control standpoint it can be exceedingly valuable.

[securesearch]

It is GPS signal only. Downloading that data isn't connected to that setting and provides data for the GPS location method not others.

Well, of course the actual GPS fix is reliant mainly on GPS signal. However, the network requests are made only when location services are enabled, with no indication to users that this background network activity is occurring so quite clearly there is an opportunity for a user to think their device is acting passively when it really isn't.

A GPS client in its original implementation is passive and Rx-only, relying solely on RF. Connecting to remote servers to speed up the process was never part of it.

Using location services on COS at all times involves both GPS signal and network requests to speed up the process. TCP packets are sent and received when location services are enabled, and that is what isn't clear to the user.

As you said though, if I have spare time to actually implement a pure GPS mode I'll look into it.

I think I'll leave it at that since otherwise this conversation could go on forever, and get ugly. Thanks for your time anyhow.

[securesearch]

It is GPS signal only. Downloading that data isn't connected to that setting and provides data for the GPS location method not others.

Well, of course the actual GPS fix is reliant mainly on GPS signal. However, the network requests are made only when location services are enabled, with no indication to users that this background network activity is occurring so quite clearly there is an opportunity for a user to think their device is acting passively when it really isn't.

A GPS client in its original implementation is passive and Rx-only, relying solely on RF. Connecting to remote servers to speed up the process was never part of it.

Using location services on COS at all times involves both GPS signal and network requests to speed up the process. TCP packets are sent and received when location services are enabled, and that is what isn't clear to the user.

As you said though, if I have spare time to actually implement a pure GPS mode I'll look into it.

I think I'll leave it at that since otherwise this conversation could go on forever, and get ugly. Thanks for your time anyhow.