Google Maps is killing Timeline for Web
androidauthority.com
androidauthority.com
> 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).
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.
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.
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).
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.
>After transitioning, users will be able to back up and restore their Timeline data to avoid losing it when switching devices.
To me, that means "Google doesn't want this data on their servers", which probably translates to "We can't keep this data from law enforcement, and that is not what users expect/want, and it is harming our users, so we won't store it at all".
We should be cheering this.
I really used it on the web. Was looking forward to the email they sent in the beginning of each month.
Bastards!
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.
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.
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!
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.
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.
It looks like a small thing, but what happens when you switch ecosystem on number of apps/services you're using, maybe you won't use Chrome on the iPhone, maybe you won't sync browser history anymore because of that, maybe you'll use Apple maps, you'll abandon Google photos, maybe you'll have less use for Google account when not all services are Google's? And in the end maybe you'll find that some other search engine is the same or better than Google and de-google completely? And that's where the Google's billions come from.
How could they risk this? It's a death by thousand (actually much less) cuts? If this is my company I would be very worried that one of these cuts will be too much, and once users start going away it would be very hard to win them back. I never thought I would say this, but at this point I'm sad that Microsoft didn't find a way to remain in the phone race.
I have used this obsessively for many years, and removing the web version (and requiring device->device transitions) makes my phone a spof for this data I truly like to keep.
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 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.
When I had to track miles for work, I’d just hop on at the end of the year and go day-by-day.
Zillions of things happened from that time that the law system cannot digest as "easy" as Internet Explorer as a monopolistic move.
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.
{
"endTime" : "2024-06-03T13:00:00.000Z",
"startTime" : "2024-06-03T11:00:00.000Z",
"timelinePath" : [
{
"point" : "geo:38.383631,27.147296",
"durationMinutesOffsetFromStartTime" : "46"
},
{
"point" : "geo:38.382012,27.146800",
"durationMinutesOffsetFromStartTime" : "47"
},
{
"point" : "geo:38.379945,27.148987",
"durationMinutesOffsetFromStartTime" : "49"
},
{
"point" : "geo:38.379359,27.150270",
"durationMinutesOffsetFromStartTime" : "51"
}
]
}Somehow this is the first product shutdown by Google I'm affected by. Good thing they're letting us export this data in an open format /s.
However, based on other commenters here, you need to export it before enabling the new location history feature.
Thanks Google, I guess it was over due.