Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.
posted by Fnord666 on Wednesday November 22 2017, @06:57AM   Printer-friendly
from the hands-in-the-cookie-jar dept.

Quartz has found that Android phones have been tracking user locations and sending them to Google throughout 2017:

Even if you take all of those precautions, phones running Android software gather data about your location and send it back to Google when they're connected to the internet, a Quartz investigation has revealed.

Since the beginning of 2017, Android phones have been collecting the addresses of nearby cellular towers—even when location services are disabled—and sending that data back to Google. The result is that Google, the unit of Alphabet behind Android, has access to data about individuals' locations and their movements that go far beyond a reasonable consumer expectation of privacy. Quartz observed the data collection occur and contacted Google, which confirmed the practice.

The cell tower addresses have been included in information sent to the system Google uses to manage push notifications and messages on Android phones for the past 11 months, according to a Google spokesperson. They were never used or stored, the spokesperson said, and the company is now taking steps to end the practice after being contacted by Quartz. By the end of November, the company said, Android phones will no longer send cell-tower location data to Google, at least as part of this particular service, which consumers cannot disable.

"In January of this year, we began looking into using Cell ID codes as an additional signal to further improve the speed and performance of message delivery," the Google spokesperson said in an email. "However, we never incorporated Cell ID into our network sync system, so that data was immediately discarded, and we updated it to no longer request Cell ID."

Also at TechCrunch and Engadget.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by edIII on Wednesday November 22 2017, @08:09AM (2 children)

    by edIII (791) on Wednesday November 22 2017, @08:09AM (#600101)

    Yeah, but most people also have DHCP turned on, and most DHCP servers set DNS, and that is mostly sourced from the DHCP lease from the ISP, and that means ISP resolvers. According to the threads the SystemD Google default is not used if DHCP sets DNS.

    It's really a non-issue beyond the policy itself as the fallback is highly unlikely.

    --
    Technically, lunchtime is at any moment. It's just a wave function.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Wednesday November 22 2017, @04:00PM (1 child)

    by Anonymous Coward on Wednesday November 22 2017, @04:00PM (#600215)

    guys android has always reported to 8.8.2.2 and 8.8.8.8 even when you set a different dns address- be it in the dhcp scope or statically.

    do a packet capture and you'll see a request to your configured dns server, and one (sometimes more than one) to google dns servers.

    the only way to stop it is to either not configure a gateway (not handy for applications requiring internet access), or to block it in the network somewhere, outside of the device.

    you otherwise would need a software firewall on the android to prevent it, which is administratively more complicated to do and more clumsy than a device at the network edge. i mean its not like you can update the host file to point to a different dns server that is always defined by ip address anyway... i have seen people suggest that and that's clearly not how it works..

    • (Score: 2) by RS3 on Thursday November 23 2017, @12:52AM

      by RS3 (6367) on Thursday November 23 2017, @12:52AM (#600445)

      How about

      iptables -A INPUT -s 8.8.8.8 -j DROP

      ?