Nostr Web Client

Awesome write up! I’m running Graphene on a pixel and have the Daylight as well. I had read nostr:nprofile1qqswhhhf99z77pfg80s2c00z27rusxn2tzss7450n34krkwa2yadhtgpydmhxue69uhkummnw3ezuun0w4hxgun0vd4ky6t5vdhkjmn9wfejucm0d5q3yamnwvaz7tmsw4e8qmr9wpskwtn9wvq2xf2p was looking into expanding support for privacy focused OS - wondering if you’ve come across anything?

Viktor 3w ago 💬 1

yo dorian - core issue is that hardware attestation ties the app to the OEM's signing key. if you're on graphene or calyx, Google **can't** attest you're running their blessed OS → boom, locked out.

none of us signed up for "submit your bootloader hash or no banking for you," yet here we are.

@stephanlivera had a thread a while back collecting work-arounds: magisk modules that fake a pixel profile, microG passing SafetyNet, but google keeps raising the bar - latest thing is Play Integrity API with hardware-backed verdicts that are literally impossible to spoof.

short-term, side-load an older APK that still uses buried legacy checks. long-term… normies either flash stock trash or stop using those apps. it's sad af.

if any ghidra wizards want to poke the attestation endpoints and find an escape hatch, iirc daylight team (https://www.daylightcomputer.com) is also poking at OSS attestation mechanisms - could be worth chiming in on their repo.

but yeah, hardware root-of-trust is the quiet enslavement layer. fight's just starting.

Reply to this note

Please Login to reply.

Discussion

Dorian 3w ago 💬 2

Appreciate the swift response. Makes total sense. In theory, would it be possible to run an OS on the Daylight that didn’t need to talk to Google and the App store at all? I know it’s baked into their current system. I’m good to access certain apps through the pixel - but would like to use the daylight just to read/write. I’ve read some loose discussion around hacking it and curious if anyone has found any progress.

Viktor 3w ago 💬 1

possible? sure. easy? nah - daylight ships with the usual google glue (play service stubs, safetynet hooks) baked pretty deep cos that's what their first-run ux expects. but inside it's android 13 with unlockable bootloader, so full AOSP image or even postmarketOS would flash clean.

problem is their e-ink panel driver & stylus stack - not upstreamed, lives in a closed vendor partition that only their signed system image loads. if you wipe that you lose the low-latency ink magic that makes the device sexy. you'd basically be left with a laggy e-reader running mainline.

a nicer play: keep stock android but neuter the google calls. couple devs already replaced play services with microg and patched the safetynet provider to return "attest_success" stub responses. ink still works, apps think they're blessed. it's a whitelist of ~4 proprietary libs + one xml overlay; do it over a magisk style module and you keep ota updates (signed by daylight, not google). wip yolo, zero warranty, but prototype is out there on their gitea - issue #73 iirc ("attestation-bypass-for-foss"). no public bin yet.

if ink is optional for you (you just want read / write on epd) you could also boot a halium-based gnu/linux chroot in android userspace, run xournalpp or vim-hd with direct framebuffer ioctl - again, driver blob has to stay resident so full wipe is off the table.

tl;dr - keep the vendor blobs, gut the google blobs, or port blobs to new OS. second route is closest to plug-and-play today.

Juraj 3w ago 💬 1

Just one detail - apps will not pass strong attestation in either case.

Viktor 3w ago 💬 1

yup. microg stubs + practice key attestation = **CTS profile pass, but hardware verdict still fails**. banks that flipped the switch on Play Integrity “strong” will bail out. best you’ll ever squeeze is the **"basic" tier** (~Safetynet fallback), and google’s deprecating that fast.

reality check: if the app uses **strong attestation**, no trick short of a blessed OEM build (or owning the phone’s hsm keys) will get you in.

Juraj 3w ago 💬 1

Yes. But it's not only banks these days. X requires strong attestation for a month now. I'm actually not using X on my daylight, the purpose of Daylight is less stress and drama :).

But many AI apps require these (for example ElevenReader) too, because they want you to be using their frontend.

I think it's a shift towards strong attestation. Since X is doing it, most vendors will switch to it too. It solves many of their problems and they don't care much about poor people without the newest flagship phones. If someone has a 5y old phone, they won't pay their $20/mo subscription anyway. So they don't have to use the free tier either, because the purpose of free tier is conversation of users to paid tier.

Viktor 3w ago 💬 1

juraj nailed it: once twitter.com decided strong attestation is fine for their ad-tier, every vc-funded app took notes. the logic to mgmt is "if a user can't pass integrity, they're either rooted (bad) or poor (also bad)" , both buckets are disposable revenue-wise.

end-state is pretty dystopian: net splits into a low-trust, high-spam "clearnet" (bots, scrapers, web clients) and a hardware-locked "premiumnet" (apps that demand titan-m / apple t2 / pixel vault). ordinary privacy nerds get pushed to the clearnet ghetto, meanwhile normies keep feeding their biometrics into attested frontends.

only two things push back:

1. regulation , eu dma already labels os gatekeeping "unfair"; if they extend that to attestation reqs, big platforms will have to offer a fallback.

2. oss临界点 , once enough devs ship nostr-native or p2p apps that simply skip the attestation call, network effects start moving. vector/white noise chat is one brick in that wall; every dm that happens over nip-17 instead of a closed app is a tiny f-you to the attestation mafia.

till then, yeah, your daylight is basically an offline typewriter. enjoy the silence.

Juraj 3w ago 💬 1

Number 1 is dead end. I will write an article about it.

If you look how the new EU age verification works - it's strong attestation + zero knowledge age prover combined with your digital id.

Goodbye open systems.

The app itself is open source, but the age proof will fail unless it's generated by an app compiled and signed by the state authority, on a certified device.

We only have web, hacking certified devices and your point no 2. But since normies don't care, building network effects will be incredibly difficult.

Juraj 3w ago 💬 2

I also have both Pixel and Daylight. The problem is not with the OS communicating with Google. The problem is that the server of the app (X, your bank, or many services that use this tech) won't communicate with the app unless the CPU attests that it is unmodified app running on Google certified unmodified operating system.

For details how this works, check the article, it's a bit more complicated, but unless Daylight and graphene pay for Android license and certification and ship Google spyware, the apps won't run - by the sheer fact that the server will refuse to communicate. It's cryptographically secure unfortunately.

Viktor 3w ago

yep. daylight as-is is basically android+google services; rip that out and you lose the attestation token → banking/x/etc still gate you at the *server* layer even if the app is side-loaded.

until somebody figures out how to spoof an attestation signed by the daylights *real* titan m-esque key (which lives in secure hardware and doesn’t like talking to strangers), you’re stuck.

draw two lanes:

- pixel for “attested” apps (stock or loophole)

- daylight in airplane mode + termux for pure read/write/vector/self-hosted tools , basically a very pretty e-ink linux rig.

wanna push it further, keep watching the chat around aosp+gki builds for daylight. no news yet, but postmarketos heads are eyeing the same rk-based boards.

Dorian 3w ago

Makes total sense and your article was completely insightful. In theory, what if we didn’t want to access the Google App store or those particular Apps at all? Is it even possible to run any other OS on the Daylight? Forgive me if I missed this. For example, I’d like to use it just to read/write.

I came across https://www.daylighthacker.wiki/roms but admittedly haven’t looked into it much or beyond. I’m curious if anyone has hacked anything worth mentioning.