Several years ago I had a similar situation: Company was discontinuing a product that sold poorly except with enthusiasts. Some of us wanted to open source it.
I don’t know how or why, but after pushing on legal for months the only solution they came up with was for us to post the code on an unattributed GitHub account. If asked about it we were supposed to shrug and imply that it was a leak without saying anything.
I do now know why legal came to that conclusion because nobody wanted to ask for details before they changed their mind. This legal department was very conservative on most matters so the decision surprised us.
Plausible deniability probably. There is a chance that they would not be allowed to make parts of that code public if it relies on third party dependencies that may have stricter licensing. Even if the unknowns do not prove substantial, legal would likely tread carefully.
That seems like a likely scenario, some engineer started an email thread that ended up in their director's inbox who said "sure why not".
In a big company getting PR/Marketing to write an announcement can be a tall order, especially for a discontinued product that did not do very well and is mostly unknown.
This looks more like bare minimum legal compliance. The 4 posted repositories are all for (L)GPL licensed projects, so they're required to make it available.
This is super cool! Now if only my ISP would give me a static IP address so I could expose port 51820 on one of these things and life would be perfect.
Oh wow, that's interesting, thanks for sharing. I was experimenting with the Pixel Recorder app, which calls into the AICore system service, which calls into the Protected Download API to download its models. Based on the URLs ("pixelai-models" vs "aicore-models") it looks like Pixel Screenshots is doing its own thing and not using AICore.
It does the same thing re: hooking, but downloads most (if not all?) of the models, only at the end does it fail with "precondition check failed" from the server which aicore just repeats.
I haven't gotten further in it to figure out what it's bailing out on, aside from the request going to google using the trusted dl service and failing. It could be the same model call and they are being oddly protective over gemini nano.
I took a brief look into it, and they use the Google Private Compute Services Protected Download API to download the Gemini Nano model, which uses remote attestation to cryptographically ensure that your device is running the stock ROM: https://github.com/google/private-compute-services/tree/mast...
I'm not sure why they do that, tbh, since Gemini Nano is now part of Chrome, and you can download it without remote attestation. If you were dedicated enough, you could probably force the AICore system app on a rooted device into using the Gemini Nano model you downloaded from Chrome. I briefly attempted this but it proved too annoying so I gave up.
Edit: It appears Pixel Screenshots works differently than Pixel Recorder, which is what I was looking into.
To anyone in the US who said they make their own apps for their own iPhone: do you really pay Apple $99/year for that "privilege", or do you reinstall the app every 7 days (or use workarounds like AltStore non-PAL or jailbreaking) to get around this?
I pay $99/year. With the amount of money I make, it’s a really trivial sum for the convenience. Plus I could use it to add Apple OAuth to my web apps if I wanted to.
The hacking community has already taken DIY Wii U repair to a level beyond even what Nintendo was likely providing.
For example, someone wrote a recovery menu that leverages an exploit in the USB stack and executes before the OS loads [1]. Many Wii Us also have SK Hynix NAND chips with high failure rates, which under normal circumstances would eventually result in a bricked console, but hackers found out how to replace it with an SD card and rebuild the internal storage from scratch onto it [2].
Hackers also revived the console's online service [3]. This was up and running even before the official service shut down.
All very impressive achievements from the hacking community around a somewhat niche and commercially failed console.
yea, it's a bit tricky. this came in from google team today:
> To get back on track, make sure you're using Chrome version 128.0.6545.0 or later. If you want the most up-to-date version, try using Chrome Canary or Chrome dev channel.
The issue you linked is more or less resolved at this point. If you find Termux processes being killed, just run this command over adb shell and you're good:
settings put global settings_enable_monitor_phantom_procs false
Google added this setting in response to a bug report submitted by a Termux maintainer. It's also persistent, so you only have to run the command once.
Interesting. Why not make some tiny announcement about it somewhere?