Hacker News: summm

New comment by summm in "How Bluesky draws its logo on screenshots"

summm — Tue, 18 Aug 2026 14:21:17 +0000

Correction: GrapheneOS is concerned with their so called "Android security model" more than anything else, and where that security model gives guarantees to app developers and service providers that harms the user's security, they merrily side with the developer's security against the user, at best give some more or less questionable reasons why that unfortunately currently cannot be changed, and at worst insult you for suggesting anything else.

New comment by summm in "Pixel 11 Pro Fold"

summm — Thu, 13 Aug 2026 19:56:21 +0000

Which was not the point. Each one of these changes made it harder, not yet impossible to make a custom Android or Linux variant. The harder it is the more likely people will continue. At some point it might be too hard. Or, one of these changes will finally make all of that impossible.

New comment by summm in "Pixel 11 Pro Fold"

summm — Thu, 13 Aug 2026 06:22:57 +0000

Here, the Pixel 10, especially in more niche variants like Pro and with larger flash has almost disappeared from the market, or is as expensive as the equivalent Pixel 11 offers.

New comment by summm in "Pixel 11 Pro Fold"

summm — Wed, 12 Aug 2026 19:30:18 +0000

With direction Google has chosen to go with the Pixel 10, it might as well be that GrapheneOS will never be available on the Pixel 11. They started by not publishing device trees anymore, squashing commits in AOSP, publishing open source drivers as a tar ball dump only after the requester has entered personal data in a web form, instead of having them public in an version control system. I wonder what dumb ideas they come up with next in order to make the GrapheneOS people suffer even more.

Walrus: An Efficient Decentralized Storage Network

summm — Tue, 11 Aug 2026 22:12:10 +0000

Article URL: https://arxiv.org/abs/2505.05370

Comments URL: https://news.ycombinator.com/item?id=49265190

Points: 11

# Comments: 0

GNUnet 0.28.0 Released

summm — Fri, 17 Jul 2026 19:35:36 +0000

Article URL: https://www.gnunet.org/en/news/2026-07-0.28.0.html

Comments URL: https://news.ycombinator.com/item?id=48951397

Points: 2

# Comments: 0

Curb impacts of AI on programming to maintain EU sovereignty

summm — Thu, 09 Jul 2026 18:14:48 +0000

Article URL: https://www.draketo.de/software/curb-ai-impact

Comments URL: https://news.ycombinator.com/item?id=48850205

Points: 1

# Comments: 0

New comment by summm in "The bottleneck might be the air in the room"

summm — Sat, 04 Jul 2026 10:08:18 +0000

Can you recommend some?

New comment by summm in "European digital ID wallets rely on safety services of Google and Apple"

summm — Thu, 02 Jul 2026 10:11:50 +0000

I think Meneth was basically correct but a bit imprecise: Boot integrity itself is only user respectful as long as the user can freely decide and change the integrity reference values, without consequences to the latter usefulness of their system. But attestation (based on boot integrity) as a principle directly contradicts "respect user ownership". This is not a question of technical feasibility, but of principle. Attestation is directed against users. The main purpose of attestation is to make sure that the local user can be forced to use a specific software (and not run other software at the same time that could influence this specific software) to access a certain remote service. Remote attestation means by definition "vendor lock", in that the vendor and their contractual partners lock and control the device's software. Therefore an attestation model that fully respects the user simply cannot exist.

New comment by summm in "European digital ID wallets rely on safety services of Google and Apple"

summm — Wed, 01 Jul 2026 18:18:24 +0000

So now you have the choice between two approved ROMs. Not a lot of improvement? And as soon as GrapheneOS implements something beneficial to the users that the government does not like, the approval will be taken back. That's also why GrapheneOS will probably not even think about doing that. So you want some OS functionality neither Google nor Graphene offer, you're, again, out of luck. CA is something completely different, and much more limited in what can be centrally controlled. Everybody can go to a CA, get a certificate for their domain, and use it with any server software, even with software they compiled themselves.

New comment by summm in "European digital ID wallets rely on safety services of Google and Apple"

summm — Tue, 30 Jun 2026 18:02:08 +0000

No, this would just require a publicly verifyable signature of the software, and the user would just choose to have their operating system verify it. No remote attestation or other hand-over-your-controls necessary.

New comment by summm in "European digital ID wallets rely on safety services of Google and Apple"

summm — Tue, 30 Jun 2026 17:51:41 +0000

Nope. It is still not possible to give someone else (the government, or the bank) control over your phone while at the same time run software that you alone control with higher privileges. Please don't mix that up with "is practically hard to implement because of sloppy code. Also your attacker model is still "occasional evil government agency or evil private corporation wants to crack and read your messages", while what is discussed here is more fundamental "evil government or abusive corporation controls your phone in the first place, and can just remote control it you can't use really secure apps"

New comment by summm in "Volkswagen started blocking GrapheneOS users"

summm — Wed, 17 Jun 2026 22:40:43 +0000

My opinion: Any kind of attestation that is delivered to a non-user-controlled server about the state of a user's end device that the user (possibly using means outside of the end device) cannot change will be abused, e.g for anti-competitve purposes. I am hearing lots of arguments that grapheneOS is more secure (it is) and should therefore be included in remote attestation.

The pinning you are proposing, does it imply that there is again some certification of the "official" GrapheneOS, versus e.g. the user's own fork of GrapheneOS?

How would any of the existing proponents of remote attestation agree to anything like this, given what we consider abuse is exactly their reason of implementing it in the first place? Here, VW wants to stop use of the API by anything else than their App, in order to stop hobbyists and sell API access to commercial middle men. If the user could pin their own software's attestation or even register an arbitrary public key to cover updates, then the user would as well be able to code his own API client that just emulates the attestation. Is there any write up or discussion of the pinning you propose?

I am really not yet convinced how you want to counter the inevitable abuse that app developers and service providers will subject the user to if the OS security model gives them that kind of power over the user's end device.

New comment by summm in "Volkswagen started blocking GrapheneOS users"

summm — Wed, 17 Jun 2026 21:10:20 +0000

The GrapheneOS supporters are not on our sides, apparently. The seem to actually like remote attestation. They just don't like that they are not in on Play Integrity. But what is won if attestation includes official GrapheneOS releases but would still otherwise be exactly the same evil stuff that takes control of the user's device?

I still am hoping that at one point they understand the full consequences of remote attestation. There are some signs they start to notice, but it's slow...

Mozilla Added Google Play Integrity to Firefox for Android

summm — Tue, 16 Jun 2026 22:19:57 +0000

Article URL: https://bugzilla.mozilla.org/show_bug.cgi?id=2046154

Comments URL: https://news.ycombinator.com/item?id=48563000

Points: 18

# Comments: 3

New comment by summm in "Volkswagen blocks Home Assistant by requiring client assertion"

summm — Sat, 30 May 2026 09:20:27 +0000

Depends. In some sense EU companies are quite afraid of the GDPR. Privacy is used in a twisted way in that argument: if any privacy relevant data is exposed to another party, and there is any incident down the line, they fear they could be made responsible. So they to block you as a user to access your own data.

Of course, if that privacy risk came from them storing and selling your data, they happily accept that, you are right in that regard.

New comment by summm in "Volkswagen blocks Home Assistant by requiring client assertion"

summm — Fri, 29 May 2026 08:53:15 +0000

They already add cryptographic authentication to some CAN messages, so you can't change them. It is only a matter of time until they add encryption.

This is mostly a corporate problem of risk aversion in my opinion. Some department writes down a risk assessment with a list of miniscule risks, for example of some 3rd party app backend being hacked. Or just a headline "Tinkerer hacked his car to use with his home assistant" in the local press. This list circulates, and since nobody in the middle management wants to be responsible for anything, and there is no officially approved positive use case, draconian countermeasures are drafted and constructed one by one.

New comment by summm in "Brussels launched an age checking app. Hackers took 2 minutes to break it"

summm — Tue, 28 Apr 2026 14:27:21 +0000

Only "open" in a twisted sense, and definitely not user-controlled: Remote attestation per definition means to accept only pre-approved operating systems. If anybody builds an implementation, regardless whether it is aosp-compliant or not, this will be excluded, until the App developer or someone in the chain explicitly approves that implementation. That is the whole purpose of that technology. Including GrapheneOS in that pre-approved list just shifts power from Google and the App Developer to GrapheneOS Developers and the App Developer. Nice for GraphenOS, still bad for users and devs of any other OS variant or platform.

New comment by summm in "Brussels launched an age checking app. Hackers took 2 minutes to break it"

summm — Tue, 21 Apr 2026 16:00:56 +0000

Their security model requires remote attestation. So, open, user-controlled platforms cannot be used. Of course some other future locked-down linux-based OS might be usable.

New comment by summm in "The Downfall and Enshittification of Microsoft in 2026"

summm — Tue, 07 Apr 2026 13:08:20 +0000

Another "blog" that doesn't even offer an RSS or Atom feed...