joseki

joined 1 week ago
[–] joseki@lemmy.zip 1 points 2 days ago

From the data I pulled from ADB though it's not clear that the hash is actually gone that's what I'm trying to figure out

[–] joseki@lemmy.zip 1 points 2 days ago (2 children)

There's no encrypted copy, just a manifest showing the encrypted copy is on Google's servers, but the device that has the hash to decrypt it was flashed...I'm tantalizingly close

[–] joseki@lemmy.zip 13 points 2 days ago (2 children)

He literally said in an interview that he felt the progressivism flowing out of his body when it happened

[–] joseki@lemmy.zip 10 points 2 days ago (1 children)

Blue team just needs to keep him in the party until the next election. Until then, he votes with the blue team on judge appointments over 95% of the time. If that's the only worthwhile thing he's gonna do I'll take it until he gets the boot. Red team isn't going to take him either. Sad how a brain injury can derail your life.

[–] joseki@lemmy.zip 4 points 2 days ago

Right and the predecessor to ChatGPT was trained on links from reddit posts pretty wild. I remember having fun making it come up with nonsense prose on my GPU

[–] joseki@lemmy.zip 2 points 2 days ago (4 children)

Unfortunately I only get the encrypted txt manifest not the data itself from takeout - the phone was flashed trying to fix a problem with the file picker and that's what started this problem, I can't export the data using takeout and the phone image doesn't match the cryptographic hash - I just need to log into maps using a phone that is recognized as the originator of the data at the time the new encryption method rolled out. I have the phone but it was flashed so it's not recognized as the device that has permission to decrypt my location history. Very frustrating.

[–] joseki@lemmy.zip 1 points 3 days ago

Right my comment was intended to hilight how outside the norm this is

 

I’m trying to recover many years of Google Maps Timeline history and have gotten far enough into the problem that I’m hoping someone familiar with Android Keystore, Google Play Services/Folsom security domains, or Maps Timeline’s encrypted-backup implementation might recognize what is happening.

The short version is:

Google confirms that encrypted Timeline backups for my account still exist on its servers, but every device I try says “Your encrypted data isn’t unlocked yet.” On the S23 that was probably involved in the Timeline migration, an Android bugreport shows Google Play Services actually attempting key recovery and failing with:

LocationHistory: [BackupRunner] Failed to get encryption key for backup

LocationHistory: bmas: 38502: Domain is not retrievable

The recovery flow also invokes:

com.google.android.gms.auth.folsom.StartKeyRetrieval

and references:

on_device_location_history

How I think I got here

I have used Google Maps Timeline/Location History for many years.

For most of that time my primary Google account on Android devices was one account, while the account I actually used inside Google Maps for Timeline was a different secondary Google account. That worked normally for years.

My main phone during the transition from Google's old server-based Timeline system to the newer device-local/encrypted-backup system was a Samsung Galaxy S23 Ultra, SM-S918U1.

At some point I had to repair/reflash the S23 firmware. I believe I used firmware that was compatible with the hardware but may not initially have been the exact correct region/CSC variant. The phone continued working afterward.

I cannot prove that this caused the Timeline problem. It is simply the most suspicious event in the history because Android Keystore/device trust material may have changed during that process.

Later I noticed that older Timeline history was gone from the normal Maps UI.

What Google Takeout shows

I requested a Google Takeout specifically for Timeline.

The plaintext Timeline export only contains relatively recent device-local history.

However, Takeout also produced an Encrypted Backups file that explicitly states that I have encrypted Timeline backups stored on Google servers.

So as far as I can determine:

Old Timeline data

encrypted backup still exists at Google

decryption/recovery state is unavailable

Maps cannot restore it

Importantly, the Takeout file is not the encrypted backup itself. It just confirms that encrypted backups exist.

What Maps does

On the S23, my new Galaxy Fold, and several old Android devices, Maps shows:

Your encrypted data isn’t unlocked yet

If I tap the Timeline cloud/backup icon:

A spinner appears.

It waits for a while.

The spinner disappears.

No backup list appears.

I never receive a PIN/password/key-recovery prompt.

I never get a usable “Fix now” flow.

I have tested:

Galaxy S23 Ultra

Galaxy Z Fold8 Ultra

Galaxy Note8

Galaxy Tab A

The older devices were preserved and had not necessarily been wiped, but signing the Timeline Google account into them does not change the behavior.

This suggests that simply having an old device is not enough. The specific device-side recovery/security-domain state apparently matters.

What I found on the S23

I kept the S23 intact after moving to the Fold and captured an Android bugreport while reproducing the Timeline failure.

The critical log entries are:

LocationHistory: [BackupRunner] Failed to get encryption key for backup

LocationHistory: bmas: 38502: Domain is not retrievable

The bugreport also shows the Google Play Services key-recovery path actually launching:

com.google.android.gms.auth.folsom.StartKeyRetrieval

The recovery request is associated with the correct Google account and:

on_device_location_history

There are also Google Play Services/Keystore references such as:

com.google.android.gms.auth.folsom

com.google.android.gms.backup/folsom

security_domain_member_key

security_domain_member_key_encrypted_locally

and activity involving operations with names along the lines of:

ListSecurityDomainMembersOperation

GetKeyMaterialOperation

MarkLocalKeysAsStaleOperation

INVALIDATE_LOCAL_KEYS

I am not interpreting those names as proof that Google deleted the keys. They are simply what appears in the recovery sequence.

Current S23 state

The phone currently reports:

Model: SM-S918U1

Android: 16

Bootloader: locked

Verified Boot: green

Warranty bit: 0

Security patch: 2026-08-05

Sales code: XAA

So there is no obvious current unlocked-bootloader/failed-Verified-Boot situation.

The Keystore is also clearly functioning in general. Google Play Services can create/use hardware-backed operations. The unresolved question is whether the specific historical Timeline/security-domain key material is gone, stale, inaccessible, or simply failing to be retrieved from Google's recovery infrastructure.

Things I have deliberately NOT done

I have not:

deleted the encrypted Timeline backups

selected Google's “delete encrypted data and start over” option

factory-reset the S23 during this investigation

cleared Google Play Services storage

cleared Maps storage

unlocked the bootloader

removed the affected Google account

reflashed the phone again

I want to preserve every remaining recovery possibility.

Things I've already tried

Tested the original/current S23

Tested a new Fold

Tested old Note8 and Tab A devices

Verified the correct Google account is being used

Verified normal Google authentication works

Confirmed the encrypted backups exist via Takeout

Captured ADB/logcat/Android bugreport during failure

Submitted the exact error through Google Maps feedback

Posted to the official Google Maps support community

The normal Google support documentation basically says to recover encrypted Timeline data using the original device, or delete the encrypted backup and start over if recovery is impossible.

The problem is that I still have the likely original device, and its recovery process is actively running but failing internally.

What I'm trying to figure out

Does anyone recognize:

38502: Domain is not retrievable

from Google Play Services, Folsom, security-domain recovery, Android backup encryption, or Maps Timeline?

In particular, I’m trying to determine whether this means:

The historical device-bound encryption key was permanently lost during the earlier firmware event.

The local Google security-domain membership/key wrapping state is damaged but potentially repairable.

Google still has enough recovery metadata server-side, but the security domain is in a broken/stale state.

This is a Google Play Services/Maps bug rather than true key loss.

There is some supported or unsupported way to re-enroll the device into the existing security domain without deleting the encrypted backups.

I am comfortable with ADB, Android debugging, Linux, Docker, firmware tooling, and doing forensic-style diagnostics on the S23 now that it is no longer my daily phone.

I am not looking to bypass someone else's encryption or account security. These are my own Google account, phone, and Timeline backups. I’m mainly trying to avoid destroying the one server-side copy that apparently still exists.

If anyone has dealt with Google Play Services auth.folsom, Android security domains, or Timeline's newer end-to-end encrypted backup implementation, I would especially appreciate pointers about what 38502 / Domain is not retrievable actually signifies and what additional state I should preserve before experimenting further.

[–] joseki@lemmy.zip 17 points 3 days ago (3 children)

K2 wasn't the first.

China had CPM-1 in 2020 that was a 2.6B model.

GPT-Neo (Mar 2021) EleutherAI replicates early GPT

PanGu-α (Apr 2021) Huawei's 200B model

WuDao 2.0 (May 2021) BAAI's massive 1.75T sparse MoE model

GPT-J (Jun 2021) EleutherAI release 6B

Meta released OPT in 2022, BLOOM was in 2022, GLM 130B by Tsinghua/Zhipu was in 2022 etc

K2 horizon is very recent, nowhere near the first. Different labs have different computational innovations worth studying. DeepSeek is crazy efficient and doing very novel things. Mistral in France is making very compact local friendly models that are fun and easy to fine tune and merge on consumer hardware.

[–] joseki@lemmy.zip 8 points 3 days ago (2 children)

Pretty much any job anywhere will fire you on the spot for sleeping with a subordinate because it's obvious that it's a coercive power dynamic and bad for business and legal risk.

[–] joseki@lemmy.zip 1 points 3 days ago

Sounds like you didn't make it past the intro

[–] joseki@lemmy.zip 1 points 1 week ago

LibreChat already exists and it's much better

view more: next ›