petedoyle

Wow, I'd love to do this. Any tips on how to build this (or how to help an LLM build this), specifically for ./gradlew?

The U.S. Missile Defense Agency (MDA), in cooperation with U.S. Space Force and U.S. Northern Command, conducted a flight test on June 23, 2025, in which the Long Range Discrimination Radar (LRDR) at Clear Space Force Station, Alaska, successfully acquired, tracked and reported missile target data to the Command and Control Battle Management and Communications (C2BMC). This was the radar’s first flight test tracking a live Intercontinental Ballistic Missile (ICBM) representative target. More: https://www.mda.mil/news/25news0006.html

Apologies / small correction:

Apps first published to the Play store before August 2021 are not required to upload their keys [1]. This likely includes Signal.

[1] https://developer.android.com/guide/app-bundle

Maybe this? https://en.wikipedia.org/wiki/MUSCULAR

> The absolute nightmare is about giving Google the root signing key of your application

I wish more people talked about this. At Amazon, I helped with the early threat modeling around adoption of "App Signing by Google Play", which requires sending your app's root signing key to Google (and is now required, with no publicly-available opt-out for new apps.) It would have added some nice things for Android devs: app bundles, smaller downloads, instant apps, etc.

That said, we imagined the following scenario, and were unable to find a reasonable mitigation at the time:

It seems plausible the US government could send a NSL (or similar) to Google and force them to distribute modified APKs for apps like Signal (ex: to exfiltrate keys). This would be nearly impossible to detect, especially if the modified APK were distributed to only an individual user, or a small group. A few people raised concerns [1], but I don't recall Google ever giving a reasonable response.

[1] https://commonsware.com/blog/2020/09/23/uncomfortable-questi...

Edit: clarify no opt out applies to new apps

Somewhat off-topic: Does anyone know the underlying strength of the keys used as the "root of trust" behind passkey synchronization on Android/iOS? I can't find a lot of documentation on this.

It seems like they're synced between devices using client-side encryption, with keys derived from your phone's lock code (typically only 4-6 digits). Is it possible that the passkeys are fully random, but then encrypted with far less than 128/256 bits of actual entropy while being synchronized between devices?

Could it be possible to brute force the keys server-side (IIUC, derived from 4-6 digit pins) with non-excessive amounts of compute? What am I missing?

I didn't know him, but followed his work on bufferbloat closely. I've never seen anyone work so diligently, for so many years, to fix a problem most people will never know even existed. And yet, that work will be felt by almost everyone on the internet. I'm sad knowing he's passed, and thankful to have seen his work. Rest in peace.

Oh, looks like it. I disabled extensions one by one til I found it was reflect.app's extension. Edit: reported on their discord.

False alarm :) Amazing work!!

Small FYI that I couldn't see them in Chrome 133.0.6943.142 on MacOS. Firefox works.

If Apple were to add new APIs, it might be possible to use personal cloud storage (NAS, Decentralized Web Nodes, etc.) with the same UX as iCloud with E2EE.

Maybe they wanted some cached data to get invalidated if users change their passwords?

Would be fun if this turned into a huge recruiting event :)

> Sure, but if that key derivation function is protected by a "you get 10 attempts then we wipe the keys" safeguard, the effective entropy is much higher.

Thank you. 100% agree.

> Passkeys do not and are not designed to protect against nation-state level attackers

I've been mulling over some use-cases where this is important, hence the deep consideration over entropy. 100% not a huge deal for the passkeys case for many 9's of people.

Thank you! I'm trying to understand more deeply, so I appreciate it. :)

> This approach works because the secure enclave provides measures against bruteforcing and tampering.

That's interesting!

> because that implies off-device use of the PIN, so those measures are lost

This link from your previous thread is interesting: https://support.apple.com/en-sg/guide/security/sec3e341e75d/...

Uses SRP to let the device prove to iCloud HSMs that the user entered the correct pin, without ever sending it over the wire. The HSMs have similar protections for brute forcing, etc.

From the docs I have a fairly high confidence entropy is 256 bits for iCloud Keychain. I have much less confidence on Android, but I'm still researching... :)

This has been bothering me, a lot. Google talks [1] about how Passkey replication is e2e encrypted between devices, but AFAICT they're just using a pin + key derivation. A six digit pin is like 20 bits of entropy before a KDF. [2]

Has anyone seen any docs that might help characterize how much entropy the keys have for e2e encryption (Android/iOS)?

I must be missing something, because I can't see how Google would call something e2e encrypted if the keys only have like 30-35 bits of "effective" entropy after a KDF. But that seems like it's the case??

    [1] "From the user's point of view, this means that when using 
    a passkey for the first time on the new device, they will 
    be asked for an existing device's screen lock in order to 
    restore the end-to-end encryption keys"

[1] https://security.googleblog.com/2022/10/SecurityofPasskeysin...

[2] https://www.omnicalculator.com/other/password-entropy?c=SGD&...

I recently drove by both the GCP and AWS regions in Oregon. It was so interesting to see one giant facility for GCP, and like 40 separate datacenter buildings for AWS, typically separated by at least half a mile, sometimes tens of miles.

Oh, that's great to know. Thank you both, I'll definitely try this!! :)

I've spent ~150 nights in hotels in the past year, and it's super rare that booking directly is cheaper. I almost always save like 30% on Hotels.com/HotelTonight/etc.

I recently wanted to extend a stay and the front desk quoted me $120/nt while Hotels.com was $107 (plus 10% back as a reward, so ~$96).

I wish that weren't the case because this is 100% true:

> never know what's going on and when anything goes wrong they just tell you they can't help you. Then the place tells you that they can't help you because you didn't book through them and they just point fingers at each other.

I've come to rely greatly on in-app ratings/reviews before booking.

They might be using App Bundles dynamic delivery [1] on Android, in which case this isn't really an issue. Helps keep the initial download size small, while allowing larger features to be delivered on-demand.

https://developer.android.com/guide/app-bundle/dynamic-deliv...

> "We believe that communicating dates produces the wrong incentives. What really matters on a long timescale is 1) priorities and 2) velocity." [1]

I saw this written during the 2017 cryptocurrency craze. Has stuck with me as one of the most insightful things I've ever read. Also a fan of 37 Signals' budgets. [2]

[1] https://medium.com/graphprotocol/introducing-the-graph-4a281...

[2] https://signalvnoise.com/posts/3746-drive-development-with-b...

Thinking this might be different. I've been curious what the BLE packet structure might look like. Looks like there's 16 bytes of unique id needed for the "Rolling Proximity Identifier" in the spec. Typically iBeacon would have 16 bytes of unchanging UUID, and 4 bytes that can change: https://support.kontakt.io/hc/en-gb/articles/201492492-iBeac....

Could probably flip it to be a 4 byte prefix (to identify this packet for contact tracing), followed by 16 bytes of the Rolling Proximity Identifier, but not sure if the underlying hardware (the BLE chips) can do low-power matching on a pattern like that. Something only Apple and Google could make work, so this is exciting.

(Or, it could be iBeacon to wake, then making a connection to fetch the Rolling Proximity Identifier. Though, in my experience, not requiring a connection will be more reliable in practice, especially for Android.)

Also excited because they can likely push both advertisement and scanning into the BLE chips themselves, letting the rest of the system (CPU, etc) sleep. Big win for battery life.

This is huge. A limiting factor has been iOS not being able to (on purpose, for privacy, and battery life) do BLE scanning (edit: or advertising, thanks Slartie) in the background. I imagine this will enable that for specific apps, and I have high confidence privacy will be well-implemented by Apple's involvement (edit: see tastroder's comment for technical docs). Having a single, well-designed spec for Bluetooth advertisement will prevent a world where there are different contact tracing apps, none of which can see each other. Doing this at the platform level will enable enough density of installs to make this effective at scale.

Just curious- is it built on Tekton? :) Have been tempted to play around with it.

I believe the recently announced Afterburner card for the upcoming Mac Pro is an FPGA. [1] Maybe they're trying to make a reconfigurable accelerator? Would be amazing to be able to decode REDCODE RAW, ProRes RAW, etc, then turn around and reprogram the FPGA to accelerate encoding of H.264/H.265/AV-1/etc faster than a CPU could.

Further, I think RED has a pretty close relationship with Nvidia [2]. For RED customers, it'd stink to buy a beefy Mac Pro and not be able to edit 8K REDCODE RAW as well as they could on other OSes that have better Nvidia support.

Especially when you consider when the Mac Pro finally ships, it will probably be up against Zen 2 Threadripper (at least 32 cores, likely more), Nvidia GPUs, and PCIe 4.0 SSDs at a significantly lower price point. To not have solid REDCODE RAW support would be a huge miss for Apple.

[1] https://www.redsharknews.com/technology/item/6408-apple-s-ma...

[2] https://www.youtube.com/watch?v=bi79vUO0GMk

The 3000 series that shipped yesterday is Zen 2

Given Apple's strong stance on privacy and not making backdoors for encryption, etc-- could they possibly be trying to prevent supply chain interdictions from the likes of the NSA? [1]

Or be trying to detect things like we saw this week? [2]

[1] https://techcrunch.com/2014/05/18/the-nsa-cisco-and-the-issu...

[2] https://www.bloomberg.com/news/features/2018-10-04/the-big-h...

I was in Rome a while back and wanted to go see Michelangelo's David. Searched for "David of Michelangelo" in Google Maps for Android. Clicked details. The main detail photo's aspect ratio is very tall and--because the photo is center-cropped--results in a zoomed in look right below his waist. :) Gave me a laugh. It's still live...

Anyone have any thoughts on whether this could be implemented on the GPU? (e.g. CUDA) Especially encoding.

Yes, absolutely. ZFS snapshots are immutable, such that once a snapshot is created nothing can change it (until to destroy the snapshot). Not designed to help with ransomware, but is a perfect use case they'd protect against. (You also want backups, of course).

Edit: I guess I'm assuming the ransomware doesn't have access to the raw disks, which would be true if you were using a NAS (e.g. FreeNAS) and connecting to it via NFS, CIFS, etc.