ysnp (u/ysnp) - Readit News

ysnp commented on Graphene OS: a security-enhanced Android build lwn.net/SubscriberLink/10... · Posted by u/madars

Eavolution · a month ago

About the OEM, are you working on having devices ship with GrapheneOS, or devices be GOS compatible (i.e. same as the Pixels)? If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing? That's the main reason I am running the android on my phone, as my banks don't work with Play Integrity failing and I have to use the app for 3DS. The ability to run GOS without this issue would be huge.

ysnp · a month ago

>About the OEM, are you working on having devices ship with GrapheneOS, or devices be GOS compatible (i.e. same as the Pixels)?

As far as I'm aware as an outsider, the aim is a device that is compatible with GrapheneOS like the Pixels, yes.

>If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing?

I think to pass this you need to be 'blessed by Google' which means being certified Android by their standards. GrapheneOS have mentioned that their CTS/CDD Android certification process holds back some of the privacy/security features (think things like new Sensors and Internet permissions etc.) implemented so they cannot can't target it.

ysnp commented on Graphene OS: a security-enhanced Android build lwn.net/SubscriberLink/10... · Posted by u/madars

ndriscoll · a month ago

Does Vanadium include the necessary APIs for uBlock Origin? Otherwise this seems like having a long explanation of how secure the windows are with titanium frames and bulletproof glass while the front door is wide open.

ysnp · a month ago

Vanadium implements per-site content filtering as a usability feature via Chromium's in-built filtering engine [0]. They currently use EasyList & EasyPrivacy filters which are quite popular and also a prominent default in uBlock Origin [1].

[0] https://grapheneos.org/features#vanadium

[1] https://github.com/gorhill/uBlock?tab=readme-ov-file#ublock-...

ysnp commented on Graphene OS: a security-enhanced Android build lwn.net/SubscriberLink/10... · Posted by u/madars

minimalist · a month ago

Last I heard, Google discontinued publishing device trees and driver binaries for Pixel devices with their recent changes to their stewardship of the AOSP [0]. Was it something definitive or are they merely delayed? If the practice is being discontinued, what would be the reason why? Doesn't publishing these artifacts create a business case for customer demand for the Pixel devices? Or is there some cost that outweighs the benefits? Is it maintainer overhead?

I didn't bring this up when it was a news story last month because there was a lot of cynicism in the thread, but I am genuinely curious. I am really grateful for both GrapheneOS and Google for creating a phone platform that Just Works for the essential stuff and that I can reasonably recommend to non-technical people!

[0]: https://news.ycombinator.com/item?id=44259921

ysnp · a month ago

It may be permanent and I think this was the official indirect response:

"AOSP needs a reference target that is flexible, configurable, and affordable — independent of any particular hardware, including those from Google." [0]

Emphasis on independent of any particular hardware.

Current speculation/inference suggests it is because of the antitrust case against them, preparing for the possibility that they may be divested of Android (or at least to decouple in meaningful ways [1]).

[0]: https://www.androidauthority.com/google-not-killing-aosp-356...

[1]: https://www.bloomberg.com/news/articles/2024-11-18/doj-will-...

ysnp commented on Running a Certificate Transparency log words.filippo.io/run-sunl... · Posted by u/Metalnem

FiloSottile · 2 months ago

My bad! This is what I get for doing a deploy to fix the layout while the post is on HN. Back up now.

ysnp · 2 months ago

https://words.filippo.io/passkey-encryption/ also seems to be gone?

ysnp commented on GrapheneOS needs OEM partner access xcancel.com/GrapheneOS/st... · Posted by u/udev4096

udev4096 · 3 months ago

Yeah, they haven't posted about shutting down on twitter. It was posted in the matrix room:

> We previously let the community know we need Android partner access in order to port to Android 16 early and for other reasons. We have not received Android partner access. Now that Android 16 has been released, it has become clear that we are going to need it more than before going forward. At the moment, it's clear that GrapheneOS development will be unable to continue in the way it was going before. This the last call for people to share partner access with us if you want to see GrapheneOS continue. Otherwise, be prepared for the final release of GrapheneOS to be today. It's up to the people who have this access to decide if they want the project to go on after today. In order to continue without this, we would need to do substantially more work that we have not had to do previously.

ysnp · 3 months ago

EDIT: More context from the GrapheneOS team on their public Twitter communications

>In the past, the main issue with AOSP was them forking AOSP apps into Google apps and then sometimes abandoning the AOSP apps. This increased over time, leaving behind a bunch of legacy apps we need to replace. There have been similar issues to this, but all things we can handle.

>They've added more and more functionality to Google Play which ends up being considered required, but they haven't ever gone out of the way to gut parts of AOSP. Android 16 has changed this. They ripped out all of the device repositories, despite promising to do the opposite.

More contextual information potentially coming from a community member (not GrapheneOS) on their forum:

>Google apparently hasn't released the kernel code and Pixel device specific code yet, and GrapheneOS team seem to be panicking over that latter part right now, as Google seemingly have removed that code from the AOSP tree entirely, possibly permanently. The next few days will be exciting.

ysnp commented on Security and Privacy Issues in WhatsApp's Handshake Mechanism arxiv.org/abs/2504.07323... · Posted by u/ysnp

ysnp · 5 months ago

Abstract: WhatsApp, the world’s largest messaging application, uses a version of the Signal protocol to provide end-to-end encryption (E2EE) with strong security guarantees, including Perfect Forward Secrecy (PFS). To ensure PFS right from the start of a new conversation –even when the recipient is offline– a stash of ephemeral (one-time) prekeys must be stored on a server. While the critical role of these one-time prekeys in achieving PFS has been outlined in the Signal specification, we are the first to demonstrate a targeted depletion attack against them on individual WhatsApp user devices. Our findings not only reveal an attack that can degrade PFS for certain messages, but also expose inherent privacy risks and serious availability implications arising from the refilling and distribution procedure essential for this security mechanism.

ysnp commented on Cwtch – Privacy Preserving Messaging docs.cwtch.im/... · Posted by u/dp-hackernews

sarahjamielewis · 5 months ago

Hi! Sarah from the Open Privacy Research Society / Cwtch team here - happy to answer questions.

ysnp · 5 months ago

TL;DR: Have you already written about OR off the top of your head what are some of the hard problems in usable decentralised metadata resistant communication that your project and others tackle and intend to tackle in future?

Hi Sarah. My layperson understanding is that Cwtch is where you research and implement metadata-resistant infrastructure for communication tools and by extension where you find the acceptable trade-offs for open questions in usable privacy-enhancements.

My memory might deceive me, but I feel like there used to be an "open questions" section in the documentation that I can no longer find? Anyway, sorry for the rambling but the question I wanted to ask is: have you already written about OR off the top of your head what are some of the hard problems in usable decentralised metadata resistant communication that your project and others tackle and intend to tackle in future? Is there anywhere we can read about these sort of things to keep up to date on developments? Nowadays it is very easy for projects to claim exceptional privacy or absolute privacy partly because accurate awareness of limits, trade-offs and state-of-the-art is not common knowledge in some communities.

-----

I saw a minor accident while skimming the documentation. Briar's summary in https://docs.cwtch.im/security/intro#a-brief-history-of-meta... says, "while providing resistant to metadata surveillance". Looks like resistance would fit better there.

ysnp commented on Unfashionably secure: why we use isolated VMs blog.thinkst.com/2024/07/... · Posted by u/mh_

compsciphd · a year ago

As the person who created docker (well, before docker - see https://www.usenix.org/legacy/events/atc10/tech/full_papers/... and compare to docker), I argued that it wasn't just good for containers, but could be used to improve VM management as well (i.e. a single VM per running image - seehttps://www.usenix.org/legacy/events/lisa11/tech/full_papers...)

I then went onto built a system with kubernetes that enabled one to run "kubernetes pods" in independent VMs - https://github.com/apporbit/infranetes (as well as create hybrid "legacy" VM / "modern" container deployments all managed via kubernetes.)

- as a total aside (while I toot my own hort on the topic of papers I wrote or contributed to), note the reviewer of this paper that originally used the term Pod for a running container - https://www.usenix.org/legacy/events/osdi02/tech/full_papers... - explains where Kubernetes got the term from.

I'd argue that FreeBSD Jails / Solaris Zones (Solaris Zone/ZFS inspired my original work) really aren't any more secure than containers on linux, as they all suffer from the same fundamental problem of the entire kernel being part of one's "tcb", so any security advantage they have is simply due lack of bugs, not simply a better design.

ysnp · a year ago

Would you say approaches like gvisor or nabla containers provide more/enough evolution on the security front? Or is there something new on the horizon that excites you more as a prospect?