joseki

joined 3 weeks ago
[–] joseki@lemmy.zip 4 points 1 day ago* (last edited 1 day ago)

Government administered healthcare has better outcomes and less administrative overhead than privately administered healthcare. Look at privatized firefighters for another example. Government is always on the forefront of messy expensive and complex systems and yes it could be improved but if half of it wasn't trying to deregulate the other half out of existence we could probably bring some more resources to bear on the problem more efficiently.

The problem is that profit seeking enterprise explicitly doesn't serve human values and that's by design.

Also psychiatric commitment isn't necessarily forever and has a restorative focus.

[–] joseki@lemmy.zip 22 points 1 day ago (3 children)

Just levying fines and imposing jail sentences doesn't go far enough, it's a 19th century solution to a 21st century problem.

Corporate personhood and limited liability need to be abolished and private enterprise needs to be re considered from first principles for the modern era.

It corporations are people, there needs to be a death sentence and involuntary psychiatric commitment .

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

Some features of the app claim to require shizuku, maybe the app itself is lying to me?

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

I need it to run keymapper which is very cool and lets me map Bluetooth keyboard combinations to map them to app UI elements. Also shizuku-mcp let's my OpenClaw stack remotely operate my mobile device which is also lots of fun

[–] joseki@lemmy.zip 1 points 1 week 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 1 week 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 4 points 2 weeks 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 weeks 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.

 

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 2 weeks 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 1 points 2 weeks ago

Sounds like you didn't make it past the intro

[–] joseki@lemmy.zip 1 points 2 weeks ago

LibreChat already exists and it's much better

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

Well sure human nature exists but there's also professionalism - unfortunately in many parts of the country these people take an intelligence test to screen out the high scorers.

view more: next ›