• 111 Posts
  • 720 Comments
Joined 2 years ago
cake
Cake day: March 19th, 2024

help-circle




  • It does, I think I’m a bit confused here. I think the apks may be signed with the original key from the previous repo, but that key doesn’t necessarily have to line up with what’s in the GitHub repo since a lot of the repo tasks were removed or changed. I’ll edit my post, but this kind of highlights how messy this handover was, and how confusing it is to users (myself included).

    This isn’t something you’d really want to mess with, since typically it has full filesystem access.





  • The new repo has two releases in it now. These releases are not signed with the original key as far as I can tell. Further, GitHub is silently redirecting to the new repo, even in Obtainium, meaning it’s possible that if you had this previously installed via Obtainium and updated now, you may have unsigned apks installed that may or may not contain the changes in the repo.

    This is a mess. I deleted the repo from Obtainium (luckily I don’t auto install updates) and will wait to see what happens over the next few months. Might just save my notes in a network share instead of using syncthing from my phone. Idk, notes are all that I was using it for.








  • Well, yes, but that is not exclusive to Pixels, and in fact, most phones (other than the latest iPhones) are more vulnerable. Pixels, especially the latest devices, have the best hardware security features of any Android phone (unfortunately). You’re focused on Pixel, but that’s only because of the recent leaks which specifically focused on Pixel because of their breaching difficulty. Here’s the full matrix from last year (which hasn’t leaked as recently):

    https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation

    GrapheneOS, even now, is not vulnerable for several reasons, most of which tie into the hardware features of the Pixel. There’s a reason Graphene only works on Pixel.

    All I’m saying is that it’s entirely misleading to imply that only Pixels are vulnerable. This is not the case, even for iPhones.

    I’m also not sure why you seem to be trying to say I disagree on the fact that Google is happy to leave vulnerabilities wide open, when that is exactly what I said in my original comment. Their new release schedule allows them to leave these vulnerabilities open for an even longer time, making Cellebrite’s job easier.






  • I know what you meant. You’re missing my point. Servers at this scale heat up much more than your average satellite. There is no efficiency gain, only loss, it’s really not efficient compared to even closed loop cooling systems on the ground, and they don’t even want to use closed loop as it stands.

    What would the benefit of having swarms of these in space be? I don’t see the benefit in any sense. It’s more expensive, you cannot do maintenance, it costs much more money, and you cannot shoot entire datacenters into space with as much ease as just building them on the ground in the first place.

    It seems to me that they just want another way to generate attention and money. They’ll shoot one of these up there, and then continue to waste water on the ground anyway.


  • Radiators typically need to have something to vent the heat into. While there is still a slight atmosphere in LEO, I fail to see how it would be more efficient than doing it all on the ground. Servers are basically heaters that do fancy things in the middle, they’ll have much more heat than a standard LEO satellite. Plus, in LEO, you constantly have to correct your orbit (or burn up). Then, you have to also be able to cool down while in the sun, and likely heat up in the dark. On top of that, good luck if you have hardware fail. Then there’s latency on top of it all.

    My point is that how is all of that more efficient than doing it on the ground, where you don’t have to consider these things?