And another one! I actually used this regularly on my PC to remember places I'd gone to on trips, or back in time.
> The company is switching to an on-device approach that is more private and works on each phone independently.
They're literally harvesting all of your location history, transaction histories, etc. What exactly is more private about doing it on your phone? It's not like your entire maps history will be stored on the device exclusively.
They mean “more private” as in your data are less useful for things like exporting into tools or third parties.
I wish google would just focus on apis and tools for me to work with my data as interoperable as possible. But there’s no money in this, so I guess it’s not a priority.
I'd argue that anything entered into a computer is not completely private, and since location can be inferred from environmental signals (e.g. cell towers, other devices, webcams, etc) location is one of the least private types of data.
> And another one! I actually used this regularly on my PC to remember places I'd gone to on trips, or back in time.
Me too. High-noon to engage Google Takeout [1] – so that I at least have a copy of all that data.
Off-topic: TIL, that Google Takeout can do regular backups automatically for up to one year when you link it to some cloud storage account (GDrive, Dropbox, One Drive, Box).
> EU will smack them with fines for it. And probably California, too.
Kind and respectful reminder that HN does not permit the users to delete their data or download it. It is against the law in EU (and probably California), but it hasn't been legally tested yet.
Hn is an interesting one because there's not even an email associated. Though I imagine they have logs of IPs and such. Still, an equivalent feels like ad networks that are everywhere though don't seem to have a way to delete data.
Yes, I know, Europeans think their laws automatically apply globally, but laws are meaningless without enforcement. Hence why 99% of US companies can safely ignore GDPR unless they're operating in the EU (which HN is not).
What the hell?? Seriously? There's no way to get my historical location data anymore? I always assumed I could rely on my google location history as a way to look back at where I've been throughout my life..
They didn't give me gpx files a few years ago either. I seem to remember it being a json or a csv, I can't remember which right now. Was easy to parse it to get the information I was after.
> It's not like your entire maps history will be stored on the device exclusively.
Isn’t that what “more private and works on each device independently” implies?
Obviously we need more detail on the implementation here but AFAIK Timeline is the only time I’ve seen a full accounting of my location in the cloud. There will, I’m sure, be a lot of ways it can still be inferred: purchases, which IP address I’m on etc etc but if Google is stepping away from constantly streaming your phone GPS location to the cloud that’s surely a good thing.
That feels like a kind of useless conversation though, there are no facts involved.
Once Google had implemented the change they’ve outlined here someone can plug their phone into Wireshark and see what, if anything, has changed. Then there’s a conversation to be had.
>> It's not like your entire maps history will be stored on the device exclusively.
>Isn’t that what “more private and works on each device independently” implies?
Probably, but I don't think it should be taken to mean that location data stays on the device. Surely, Google will continue to use location data for ad targeting. Location is also used in countless other places such as Photos.
The Google Maps timeline is a specific database and this particular database will be stored on-device. I don't think it changes anything for how Google uses location data more generally.
Spousal abuse works well through this feature. Not sure if this is it or privacy theatre, but it will force potential domestic stalkers to become more visible and/or to put more effort.
Am I the only one who feels that "domestic abuse" is becoming the new "think of the children" in computing? The problem is serious, but if we follow the logic of removing any and all features that could aid the abuser in tracking their victim or preventing them from getting help, then we'd have to remove a lot of functionality considered basic. This includes e.g. security warnings that you've logged in from a new location/machine, or an dashboard showing active sessions. Hell, this probably includes location tags and dates on photos in your own phone gallery. Abusers, especially spouses, have a lot of options on their disposal (including that the assumption that phone is a personal device no longer holds). I'm not sure how is removing web access to Timeline really helping here.
It is very likely that you are indeed the only one. "Think of the children" is aimed at eroding privacy while this feature is aimed at increasing it and the goals are diametrically opposite.
I used the spousal example because it was the shortest path between web access and demonstrating potential harm. However, bad browser extensions and stallen credentials can lead to the same result if the attacker is interested in using your history against you.
What's "more private" is that Google won't need to respond to apporax. a million daily requests for information from law enforcement(?) anymore.
Cf. whatsapp - they've been encrypting messages for years, but only recently started encrypting (if you enable it) the cloud backups at google. Encrypting the data that went to their own servers was a higher priority. And they could just send law enforcement to the cloud storage provider. Are those two things related? Curious minds wonder.
It would be cool if someone made a similar minimal open source desktop UI that could run on the data export from Google Takeout [or whatever the future export mechanism turns out to be].
I didn't see anything in the article that said they are (for sure) not retaining this data.
"Google could purge some or all of your location history when it sunsets Timeline’s web access" -- or they might not. It just won't be available to the user.
One can only assume that GOOG is still collecting/inferring device location whenever possible, and putting the pieces together on the back end to paint a broader picture of the user.
Removing the user-facing feature that shows all this collected data is akin to the classic tech company manoeuvre of adding an "isDeleted" attribute to data, hiding it, and keeping it in the 'base when a client requests to delete something. Out of sight, out of mind!
Yes, certainly, but Google only needs to appear that they are complying with GDPR. Their incentive is still to collect as much information as possible for their advertising partners.
There are many loopholes for a company to use and sell location data while claiming it stays on users' devices, or remains encrypted while kept on company servers.
Timeline has been so useful. I have used it as a way to recall where we stopped in holidays, check where I was when I made a purchase, and to help diarise work related car trips for tax purposes. Having a small computer a with you with lots of sensors on it that is able to record images, sounds, and log location is infinitely more useful when it is searchable in an archive. I don't want to have to do that searching on a small screen.
I started using Foursquare’s Swarm app for recording locations on holiday etc. it works well enough even if it has a load of social nonsense I don’t need or use.
I was a longtime user of 4sq/swarm in its heyday, but eventually gave up on it mainly because they never could figure out how to automatically check me in — like Google Timeline does. The whole product has the stench of death about it these days, though. It seems like it’s a hair’s breadth from being discontinued, and its lack of any changes in the past 7 years or so makes me suspect that they have about half a FTE working on it at most.
I built a web app last year for planning travel but it's also great for tracking your travels and story telling. We use it for both (plan and log). Check out https://turas.app.
I've had that in the back of my mind since 2008 and even started building it once but couldn't find a revenue model that made sense - I like that you just decided not to bother with the revenue model!
Indeed, impossible to find a revenue model that makes sense so I gave up and just let folks use it for free since it costs virtually nothing to run (Firebase backend and Google Maps all still within free tier usage). I have all of my own trips on there so I pretty much build it for my wife and I and then there are a few dozen active MAU planning trips as well.
Works out for me and maybe one day I'll open source it when I can't operate it for free any more.
OwnTracks (https://owntracks.org/) seems quite well maintained, is FOSS, has iOS and Android clients and the server can be installed in one click if you're running Yunohost.
That looks like it'll either be much lower resolution than Google's timeline (manual or 15 minute checks) or will consume a lot more battery life than I'd be happy with (due to relying on GPS, turning it on for a location fix every minute).
Given wireless is turned on 24/7 for most people, it seems to me that a better method would be to cache APs that the user sees, so that if the same set of APs (or a significant subset there-of) are visible there is no need to ask for the GPS parts to be turned on. Obviously that is more work and there are some complexities to account for¹²³ but this is how Google's timeline uses little power. They have an centralised international database of AP locations (slurped while collecting images for Maps/Streetview and no doubt other sources) but that isn't really needed – you can just keep a list of APs seen recently and where on each users own device⁴.
It isn't something I'd have time or desire to develop. You'd have the faf of getting it approved in an appstore, dealing with supporting users that just don't understand, fun with some phones⁵ overly aggressively killing apps not matter what the user selects in order to make grandiose battery life claims (and users blaming that on your app), etc., but if someone else wants to (especially if it is an open source and/or stalking free app) feel free to take the idea, and I'll consider using your implementation!
---
[1] APs move or get renamed
[2] Assuming APs are identified by SSID there will be some names that are the same in multiple locations
[3] Some APs constantly move by design, i.e. those on public transport.
[4] Not having a central DB just means each device doesn't immediately benefit from the location cache avoiding GPS use when visiting a new area, but each device will quickly build a view of local APs for any area it enters.
I actually set up my phone to turn GPS tracking on whenever not on Wi-Fi (using Tasker + GPSLogger [1]), specifically to get better precision in Location History, and it uses surprisingly little battery if you're sampling at moderate frequencies like once per 15 seconds. The screen is the big battery hog, and also the cell radio if you have bad reception.
I use this too as I was trying to de-google myself. However, I hadn't stopped logging my location to Google since for the presentation of data I hadn't found an easy solution for. Do you view the GPS data from GPSLogger?
No, never. I only use GPSLogger to generate more frequent GPS points than Google Location Service would do by itself - it opportunistically uses all GPS requests made by apps on the system. You can also see this effect when using GPS navigation (in Google Maps, but also in other GPS apps): because they enable continuous (1Hz) GPS, the detail in tracks in Location History during your navigation app usage will be much better.
I have been thinking about how to replace Timeline for a while; the problem with most solutions is they don't do the snapping to semantic locations that Timeline does for you. And even if they did, an open source solution would probably have to snap to OSM POIs, which tend to be lower quality.
>That looks like it'll either be much lower resolution than Google's timeline (manual or 15 minute checks) or will consume a lot more battery life than I'd be happy with (due to relying on GPS, turning it on for a location fix every minute).
How does Google timeline achieve higher resolution with lower power consumption? Does it rely on special APIs or databases that other apps don't have access to?
As described in my last: they get a pretty good estimate from what APs you are close enough to see (the vast majority of users have wireless turned on 24/7, so this is not using power by needing extra hardware to be working). If your settings are such that it is able, it will occasionally get a more accurate fix using GPS.
> Does it rely on special APIs
No APIs that I know of. Just having the relevant permissions out-of-the-box, and perhaps (caveat: guessing here) having an exclusion from being blocked by aggressive power management tools (Xiaomi devices are notorious for breaking background apps in the name of battery conservation, and it works well enough on mine despite it occasionally killing the podcast app I'm actively listening to, despite all the relevant “don't kill this” options/permissions being set).
> or databases that other apps don't have access to?
Thinking about it, if the standard location APIs give access to this information with the same granularity, then a tracking app wouldn't need to be especially bright itself.
And if you don’t like the server software, there’s plenty that can also work with records from the OwnTracks client. E.g. I log my locations into Traccar (after a few years of using php-owntracks-recorder).
Yes, absolutely, especially now that any travel is at least five years prior I no longer necessarily remember exactly my favorite restaurants in Florence and Lyon :/
> To keep users’ sensitive location data more private and secure, Google Maps will sunset web access for its Timeline feature in the coming months.
Google is the last company I will ever trust with my data on earth. They keep literally everything about their users, what makes e.g. email less sensitive than location data?
What I smell here is there is probably something else Google is trying to rephrase in more "acceptable" way.
Anyone here work for Google in a capacity that can explain why they remove features that are oft used and that people love?
Things like Reader, location-based reminders ("remind me when I get home to..."), controlling my oven via the Assistant, Fitbit with Google workspace accounts, and now Maps timeline.
Like... I will just find replacements for all those and further myself even more from the Google ecosystem. What benefits does Google get out of killing these popular features?
It comes down to “the project doesn’t have enough staffing to keep operating” in the end, and those decisions get made way higher up. Any engineer at Google has no visibility into that.
Engineers at Google only understand how understaffed projects get shut down—it’s because there isn’t enough staff on the project to keep updating to work with Google’s changing infrastructure. This isn’t the root cause, though, it’s just a contributing factor. Maybe if Google infrastructure changed less, some of these projects would stick around longer with reduced staff.
I think the issue is that the underlying dependencies are changing, so even if the feature set never changes it still requires some amount of engineering work to keep it up and running.
Depends on the tech stack. If it's JS/TS then it's a nightmare to maintain, with all the Critical and High security issues. Packages that are not updated anymore you need to replace with something else.
You can't just leave it alone, it's easier to shut it down and save yourself another accident and subsequent postmortem.
The service has access to years and years of very fine-grained location data for millions of people. There's no way they could just let it drift. It would be a liability nightmare.
To be more concrete... It isn't acceptable for a service to be running from a years-old build, since it wouldn't pick up any security fixes.
Googles infrastructure evolves reasonably quickly - so most reasonably large services will need quite a few code changes every year just to keep up with the fact that internal database type X is going away and everyone needs to migrate to database Y which might have subtly different semantics requiring bits of your service be rewritten.
There is also a gradual flow of legal/privacy mandates (eg. as of Y date, IP addresses must not flow through technology Z because we now have to consider them personal information)
At some point, one of these migrations requires a lot of work, and there aren't enough humans really keen on doing the work, so it gets shut down.
Management could assign workers to do the work, but generally maintaining stuff isn't good for the career path, so few volunteer for big but non-impactful projects like this. As soon as the 'founders' of a project have moved on, it is vulnerable to this kind of shutdown.
We can assume that with minimal staff, the project is still building and deploying new versions with new dependencies. If it weren’t getting new builds and security fixes, it would raise internal alarms designed to catch unpatched software.
It’s the “database X is going away” that really, really kills an understaffed project.
> Googles infrastructure evolves reasonably quickly - so most reasonably large services will need quite a few code changes every year just to keep up with the fact that internal database type X is going away and everyone needs to migrate to database Y which might have subtly different semantics requiring bits of your service be rewritten.
I find this an unsatisfying explanation (to be clear, I'm not criticising you but the effect you're describing), if we develop to interfaces as a principle, then underlying implementations shouldn't matter.
Google is where Titus Winters and Hyrum Wright coined "Hyrum's Law". Loosely paraphrased: given enough users, people start depending on the "implicit interface" rather than the defined one.
People are responding talking about interfaces changing… I’m going to say that interfaces changing is the whole point.
You see weird stuff when you scale to Google scale. I know it’s cliché to talk about “Google scale” but bear with me for a moment. If you are just running some little service, maybe you have a local filesystem and a SQLite database and that’s enough. If you grow, maybe you have a few machines, network storage, and a PostgreSQL server with a hot replica. If you grow, maybe you have distributed storage and you shard your database across multiple servers. If you keep growing, maybe you end up with Google’s situation, where you have filesystems like Colossus and databases like Spanner.
These systems didn’t appear overnight. Someone at Google made a distributed database, and after iterations and evolution, we got Spanner, which is now a Google cloud product you can use yourself.
There was a lot of interface breakage on the road to getting something like Spanner. Now that Spanner is a Google cloud offering, you can bet your ass that the interface is stable. It just takes a long time to get there, and the internal customers (Google teams building products) don’t want to wait for the stable, final iteration of some infrastructure to arrive. Nobody knows like that looks like until you suffer through the growing pains of building it.
Thanks for the information... That sounds kind of dysfunctional, organizationally. It means well-established services are vulnerable to shutdown because they aren't new and exciting. As a customer, that would make me even less inclined to use Google.
I figured engineers wouldn't know. But someone at the company makes these decisions. Do they ever poll random users to get feedback in how much a feature is loved? I'm curious what data and processes are used to determine if a project should be staffed more vs just killed. From the outside it doesn't make sense.
It’s not a staffing thing. They’re fundamentally getting away from storing your location data to avoid having to deal with law enforcement requests and other problematic things.
I don't think that's it, since this project has been in the works for years and has burnt way more resources than just keeping on-server location history in maintenance mode ever would have.
It seems to be motivated by actual privacy concerns with Google keeping an exhaustive history of users' precise and semantic locations on Google servers, in particular the increasing use of geofence warrants (https://www.forbes.com/sites/cyrusfarivar/2023/12/14/google-...).
While often true, in this case it seems like supporting the web view as it would break the new security model. I'm sure they could develop something similar to how you can use WhatsApp from the web, but that's also probably a lot of work for a feature that's probably not heavily used.
They are trying to get out of having to fulfill law enforcement requests because they have this data. If it’s only on-device (i.e. no web-based view) then Google can’t give law enforcement data they don’t have.
Eehhhhh. Encryption at rest is technically possible here, no? Though I guess they could still be gagged and coerced by law enforcement to MITM the front end (browser/client). But they could also be coerced to do that in the mobile app too, so nothing seems to have really changed.
> The company plans to sunset web access and switch to a more private, on-device approach. This would make Google Maps’ Timeline data unique to each connected phone — as the migration would deactivate the universal sync mechanism.
So even though they're killing the feature as it exists today, they're replacing it with something more secure. What's wrong here exactly?
I do, too. Stuff like "what was that restaurant we went to in <random city> in <random year>". I really liked this feature and consciously left it enabled, knowing the privacy tradeoffs.
It seems hard to believe that offering the service via a desktop web app is any less secure - If it was, surely the same security concerns would apply to gmail, google docs, etc?
When I saw this reasoning my immediate assumption was that they made the decision first, then came up with this excuse in order to keep up appearances and conceal the _real_ reason, (which I would guess is something like "they're undertaking a project which involves making large changes to google maps in order to increase revenue, and the work needed to make desktop maps timeline compatible with these changes isn't deemed worthwhile since it doesn't have many users and doesn't directly create revenue").
Likely cost cutting is a factor. They’ve been getting rid of lots of freebies (e.g. no more free Photos storage), enforcing previously unenforced limits (e.g. Google Drive storage for business accounts), aggressively ramping up ad density (e.g. YouTube), and hiking rates across the board like crazy in recent years. I was shocked to find out my Workspace Enterprise bill has shot up 40% early this year, which is after another price hike from a year or two earlier.
Not a Googler, but gpt4o has been a declaration of war by OpenAI and Google is shutting down things no longer considered to have long-term strategic value.
My guess would be, that feature is "done" and there's not much else interesting to work on, so people have moved on and now it's not maintained. More likely than not this is a result of engineers only ever wanting to work on new projects.
I tried to export my Timeline history but I cannot get the full version. My Pixel 8 has the full version but no way to export. My iPhone does have a way to export but does not have the full version.
Layoffs and attrition has gutted some teams and puts pressure on what and cannot be maintained. This is compounded when teams are offshored to India or Poland and none of the original engineers are around to help.
We also have to contend with go/degrowth and shrink our service footprints, so you’ll see more G services go on device.
I know of several TLs planning on leaving in the next couple of months, so the Google brain drain is well underway.
Ugh. Same as with Google Photos where you can only see a worldwide heatmap of where you've been from your phone and not on the web.
I hate that I cannot use these features on a much larger screen where I can be more comfortable using them.
Normally when Timeline is talked about the comments are all extremely negative, making it sound like no-one wants this feature due to privacy concerns.
People love to bitch about privacy even if it doesn't affect them and usually when they don't even use the product in question. I like timeline - the privacy thing is a calculated trade off.
I have an actual question about the implementation of this. It currently seems like there is no way to maintain your location history if you switch device platforms. Your on device history seems to be synced to iCloud, but if you switch from iOS -> Android, it seems like your SOL?
So, the real and useful bit of information in TFA is that Big G is transitioning the Location History / Timeline service to be on-device only, thus removing the web version of it (since it will be tied to the device generating the coordinates material).
And the comments are all dunking on "yet another Google dead project" "someone who was already promoted doesn't care" etc etc etc. You can dunk on Google here asking, for example, if "is there any possible secret agenda behind this?" "What's the catch?" "No way they are giving up on that data!", at least it would be in topic with the article.
Yeah I came here ready to be mad another useful feature was being sunsetted and as much as I'd rather not have to view it all from my phone, if they're telling the truth that this data will stay on-device now, this is actually pretty cool!
How fragile is the local data? Will it be preserved if I switch phones? What about past events that aren't on the current phone? What if I use two phones?
This takes a unified view and fragments it for spurious user privacy benefits (when we know Google is still collecting and holding all the information needed anyways).
148 comments
[ 2.8 ms ] story [ 201 ms ] thread> The company is switching to an on-device approach that is more private and works on each phone independently.
They're literally harvesting all of your location history, transaction histories, etc. What exactly is more private about doing it on your phone? It's not like your entire maps history will be stored on the device exclusively.
I wish google would just focus on apis and tools for me to work with my data as interoperable as possible. But there’s no money in this, so I guess it’s not a priority.
I'd argue that anything entered into a computer is not completely private, and since location can be inferred from environmental signals (e.g. cell towers, other devices, webcams, etc) location is one of the least private types of data.
Me too. High-noon to engage Google Takeout [1] – so that I at least have a copy of all that data.
Off-topic: TIL, that Google Takeout can do regular backups automatically for up to one year when you link it to some cloud storage account (GDrive, Dropbox, One Drive, Box).
[1] https://takeout.google.com
Kind and respectful reminder that HN does not permit the users to delete their data or download it. It is against the law in EU (and probably California), but it hasn't been legally tested yet.
Yes, I know, Europeans think their laws automatically apply globally, but laws are meaningless without enforcement. Hence why 99% of US companies can safely ignore GDPR unless they're operating in the EU (which HN is not).
i.e. no GPX files
Isn’t that what “more private and works on each device independently” implies?
Obviously we need more detail on the implementation here but AFAIK Timeline is the only time I’ve seen a full accounting of my location in the cloud. There will, I’m sure, be a lot of ways it can still be inferred: purchases, which IP address I’m on etc etc but if Google is stepping away from constantly streaming your phone GPS location to the cloud that’s surely a good thing.
Yes, that _you've_ seen. I think the person you're replying to is referring to use cases of your location data that you don't see.
Once Google had implemented the change they’ve outlined here someone can plug their phone into Wireshark and see what, if anything, has changed. Then there’s a conversation to be had.
>Isn’t that what “more private and works on each device independently” implies?
Probably, but I don't think it should be taken to mean that location data stays on the device. Surely, Google will continue to use location data for ad targeting. Location is also used in countless other places such as Photos.
The Google Maps timeline is a specific database and this particular database will be stored on-device. I don't think it changes anything for how Google uses location data more generally.
I used the spousal example because it was the shortest path between web access and demonstrating potential harm. However, bad browser extensions and stallen credentials can lead to the same result if the attacker is interested in using your history against you.
Cf. whatsapp - they've been encrypting messages for years, but only recently started encrypting (if you enable it) the cloud backups at google. Encrypting the data that went to their own servers was a higher priority. And they could just send law enforcement to the cloud storage provider. Are those two things related? Curious minds wonder.
And some PM decided they could get a promo by 'unifying interfaces to simplify and enhance the user experience'
"Google could purge some or all of your location history when it sunsets Timeline’s web access" -- or they might not. It just won't be available to the user.
Removing the user-facing feature that shows all this collected data is akin to the classic tech company manoeuvre of adding an "isDeleted" attribute to data, hiding it, and keeping it in the 'base when a client requests to delete something. Out of sight, out of mind!
There are many loopholes for a company to use and sell location data while claiming it stays on users' devices, or remains encrypted while kept on company servers.
Our trip: https://turas.app/s/taiwan/0vylwa7K
Works out for me and maybe one day I'll open source it when I can't operate it for free any more.
I really used it on the web. Was looking forward to the email they sent in the beginning of each month.
Bastards!
Thanks Google, I guess it was over due.
I wouldn't be surprised if the APIs used to get a rough estimate of the position in the background without invoking battery draining GPS are private.
Given wireless is turned on 24/7 for most people, it seems to me that a better method would be to cache APs that the user sees, so that if the same set of APs (or a significant subset there-of) are visible there is no need to ask for the GPS parts to be turned on. Obviously that is more work and there are some complexities to account for¹²³ but this is how Google's timeline uses little power. They have an centralised international database of AP locations (slurped while collecting images for Maps/Streetview and no doubt other sources) but that isn't really needed – you can just keep a list of APs seen recently and where on each users own device⁴.
It isn't something I'd have time or desire to develop. You'd have the faf of getting it approved in an appstore, dealing with supporting users that just don't understand, fun with some phones⁵ overly aggressively killing apps not matter what the user selects in order to make grandiose battery life claims (and users blaming that on your app), etc., but if someone else wants to (especially if it is an open source and/or stalking free app) feel free to take the idea, and I'll consider using your implementation!
---
[1] APs move or get renamed
[2] Assuming APs are identified by SSID there will be some names that are the same in multiple locations
[3] Some APs constantly move by design, i.e. those on public transport.
[4] Not having a central DB just means each device doesn't immediately benefit from the location cache avoiding GPS use when visiting a new area, but each device will quickly build a view of local APs for any area it enters.
[5] I'm looking at you, Xiaomi!
[1] https://f-droid.org/en/packages/com.mendhak.gpslogger/
I have been thinking about how to replace Timeline for a while; the problem with most solutions is they don't do the snapping to semantic locations that Timeline does for you. And even if they did, an open source solution would probably have to snap to OSM POIs, which tend to be lower quality.
How does Google timeline achieve higher resolution with lower power consumption? Does it rely on special APIs or databases that other apps don't have access to?
> Does it rely on special APIs
No APIs that I know of. Just having the relevant permissions out-of-the-box, and perhaps (caveat: guessing here) having an exclusion from being blocked by aggressive power management tools (Xiaomi devices are notorious for breaking background apps in the name of battery conservation, and it works well enough on mine despite it occasionally killing the podcast app I'm actively listening to, despite all the relevant “don't kill this” options/permissions being set).
> or databases that other apps don't have access to?
They have a database of AP locations which their own services use: https://support.google.com/maps/answer/1725632?hl=en-GB
Thinking about it, if the standard location APIs give access to this information with the same granularity, then a tracking app wouldn't need to be especially bright itself.
Google is the last company I will ever trust with my data on earth. They keep literally everything about their users, what makes e.g. email less sensitive than location data?
What I smell here is there is probably something else Google is trying to rephrase in more "acceptable" way.
Things like Reader, location-based reminders ("remind me when I get home to..."), controlling my oven via the Assistant, Fitbit with Google workspace accounts, and now Maps timeline.
Like... I will just find replacements for all those and further myself even more from the Google ecosystem. What benefits does Google get out of killing these popular features?
Engineers at Google only understand how understaffed projects get shut down—it’s because there isn’t enough staff on the project to keep updating to work with Google’s changing infrastructure. This isn’t the root cause, though, it’s just a contributing factor. Maybe if Google infrastructure changed less, some of these projects would stick around longer with reduced staff.
You can't just leave it alone, it's easier to shut it down and save yourself another accident and subsequent postmortem.
Googles infrastructure evolves reasonably quickly - so most reasonably large services will need quite a few code changes every year just to keep up with the fact that internal database type X is going away and everyone needs to migrate to database Y which might have subtly different semantics requiring bits of your service be rewritten.
There is also a gradual flow of legal/privacy mandates (eg. as of Y date, IP addresses must not flow through technology Z because we now have to consider them personal information)
At some point, one of these migrations requires a lot of work, and there aren't enough humans really keen on doing the work, so it gets shut down.
Management could assign workers to do the work, but generally maintaining stuff isn't good for the career path, so few volunteer for big but non-impactful projects like this. As soon as the 'founders' of a project have moved on, it is vulnerable to this kind of shutdown.
It’s the “database X is going away” that really, really kills an understaffed project.
I find this an unsatisfying explanation (to be clear, I'm not criticising you but the effect you're describing), if we develop to interfaces as a principle, then underlying implementations shouldn't matter.
https://www.hyrumslaw.com/
You see weird stuff when you scale to Google scale. I know it’s cliché to talk about “Google scale” but bear with me for a moment. If you are just running some little service, maybe you have a local filesystem and a SQLite database and that’s enough. If you grow, maybe you have a few machines, network storage, and a PostgreSQL server with a hot replica. If you grow, maybe you have distributed storage and you shard your database across multiple servers. If you keep growing, maybe you end up with Google’s situation, where you have filesystems like Colossus and databases like Spanner.
These systems didn’t appear overnight. Someone at Google made a distributed database, and after iterations and evolution, we got Spanner, which is now a Google cloud product you can use yourself.
There was a lot of interface breakage on the road to getting something like Spanner. Now that Spanner is a Google cloud offering, you can bet your ass that the interface is stable. It just takes a long time to get there, and the internal customers (Google teams building products) don’t want to wait for the stable, final iteration of some infrastructure to arrive. Nobody knows like that looks like until you suffer through the growing pains of building it.
Which is interesting considering how bloated Google seems to be.
It seems to be motivated by actual privacy concerns with Google keeping an exhaustive history of users' precise and semantic locations on Google servers, in particular the increasing use of geofence warrants (https://www.forbes.com/sites/cyrusfarivar/2023/12/14/google-...).
One could argue that loss leaders help keep people using Google, but I suspect that’s at odds with how things work at Google.
> The company plans to sunset web access and switch to a more private, on-device approach. This would make Google Maps’ Timeline data unique to each connected phone — as the migration would deactivate the universal sync mechanism.
So even though they're killing the feature as it exists today, they're replacing it with something more secure. What's wrong here exactly?
When I saw this reasoning my immediate assumption was that they made the decision first, then came up with this excuse in order to keep up appearances and conceal the _real_ reason, (which I would guess is something like "they're undertaking a project which involves making large changes to google maps in order to increase revenue, and the work needed to make desktop maps timeline compatible with these changes isn't deemed worthwhile since it doesn't have many users and doesn't directly create revenue").
Google is tired of giving the cops your location. For once they are doing a good thing.
Zillions of things happened from that time that the law system cannot digest as "easy" as Internet Explorer as a monopolistic move.
[1] https://en.wikipedia.org/wiki/Don't_be_evil
Layoffs and attrition has gutted some teams and puts pressure on what and cannot be maintained. This is compounded when teams are offshored to India or Poland and none of the original engineers are around to help.
We also have to contend with go/degrowth and shrink our service footprints, so you’ll see more G services go on device.
I know of several TLs planning on leaving in the next couple of months, so the Google brain drain is well underway.
And the comments are all dunking on "yet another Google dead project" "someone who was already promoted doesn't care" etc etc etc. You can dunk on Google here asking, for example, if "is there any possible secret agenda behind this?" "What's the catch?" "No way they are giving up on that data!", at least it would be in topic with the article.
This takes a unified view and fragments it for spurious user privacy benefits (when we know Google is still collecting and holding all the information needed anyways).