Damus

Recent Notes

Final profile picture
What you search on YouTube is known to YouTube because you are doing it on YouTube. The platform wouldn't make a difference. Their ability to infer an identity to the searches is dependent on other information you give it, like your account, IP address etc.

There could be mining apps, but I don't think they'd be a good platform to do it on. Get a cheap mining hardware.
Final profile picture
You're asking a member of GrapheneOS to summarise their experiences so obviously you'll get a pretty positive answer.

It works very well and there's the ability to have Google Play in a sandbox should you need apps that require and depend on it or if you are going to use it more like the average person. If you used Android you'll feel close to home. Unfortunately some apps block running on any OS that isn't a Google certified one but this isn't something we can control. I'd recommend checking if your apps work on there first and if it not working is a non-negotiable.
Final profile picture
It gives them all the files of an unlocked profile, calls and SMS history and light application data but this is depending on the techniques, OS and app support. Certain logical extraction techniques use standard ADB functionality, Android backup features, or more invasive methods like downgrading a system app to a vulnerable version (GrapheneOS closes this security hole).

If they wanted data on certain apps like messengers then manually browsing the apps and reading the messages with a camera mounted to the screen may be needed instead.

Full filesystem would give access to privileged OS data and the /data of all applications in at profiles not at rest. If there's a hot wallet app only protected by a simple PIN they could just clone that app data elsewhere and get control of the keys by brute forcing the PIN. Not usually possible on logical extractions.
Final profile picture
We won't be changing the UI at the moment given it is changing rapidly upstream and would be bad timing. Keep in mind a minor change like this would be low on priorities as well...
Final profile picture
Sometime ago unlocked extractions stopped providing access to the full filesystem. We didn't do anything in particular to cause that. If that's not available they'll do 'logical extraction' instead where they acquire the data through traditional logical operating system features like ADB.

The big capabilities to look out for are AFU (extraction AFU without password) and Brute Force capabilities, neither of which are present.
Final profile picture
#GrapheneOS is very distinct from other Android distributions and OEM configurations. There is a litany of Linux kernel and Android Runtime hardening changes and features powering GrapheneOS. This is very significant but often overlooked because most changes aren't visible to the end user.

The leading example of this is hardened_malloc, the hardened memory allocator used in GrapheneOS to protect against memory corruption vulnerabilities. You can find a technical article about it by Synacktiv, a French cyber security company:

https://www.synacktiv.com/en/publications/exploring-grapheneos-secure-allocator-hardened-malloc

Hardening in GrapheneOS are built on closing out commonly exploited attack surfaces, substituting them with more secure replacements, or giving them stronger security defaults.

If you are a blue teamer you'll already be familiar with the Pyramid of Pain:



For newcomers, this model is a layered pyramid that ranks indicators of compromise by a linear level of difficulty and cost for the threat actor to evade security measures to perform an attack; The bottom of the pyramid being very easy and trivial for the threat actor to change and the top being tough.

This model opens newcomers on how good security strategy is built: Techniques and capabilities over individual actors. Closing out tactics, techniques and procedures are far more important than blocking an IP address or a file hash. You want to protect against a type of attack, not against a particular actor who performs them.

The point of having extensive hardening features is that we need to ensure vulnerabilities that would affect Android are benign, harder to exploit or patched in GrapheneOS before they can be exploited. Android distributions carry the weight of vulnerabilities from upstream. To reduce that weight, we need to make sure a highly sophisticated exploit developer would have to uniquely design their exploit to target GrapheneOS, should they be able to at all.

Without that, GrapheneOS wouldn't be special. It would not be sensible to claim it is more security and privacy focused than Android if it was able to be exploited through the exact same mechanisms with little or no effort needed to port. An Android distribution that is just Android without Google services is mostly as exploitable as Android. Something that is "DeGoogled" (I don't use the term, it's Reddit tier buzzword nonsense) may not necessarily be safer to use either.

To earn the title of being hardened it needs more, but this isn't ever implemented well enough. Projects that have done so to the best of their ability also have died (DivestOS).

Our hardening features are available outside of GrapheneOS. Leading example of this is secureblue, a security hardened Linux distribution (https://secureblue.dev/) which is using hardened_malloc and Vanadium inspired chromium browser. A business also sells hardened Rocky Linux supporting hardened_malloc. If you are a maintainer of a leading project then implementing our hardening features and supporting is strongly encouraged.

Final profile picture
Around Android 17 is likely when the desktop mode could finalize and not become a developer option upstream. You can test the developer option today. It's unlikely we'll be doing a lot of work on this when we know it's being changed a lot.

We have a lot of ideas for the Linux Terminal app but not being approached yet for the same reasons. Ideally we'd not want to be using Debian but a hardened distribution of some kind. The process of having GUI apps could be a little more seamless than running terminal, installing GNOME, doing sudo passwd to let yourself log in, praying it doesn't break and moving to GUI. Should just be like opening an app and selecting a VM.
Final profile picture
We've received a 2nd IPv4 /24 subnet from ARIN for our 2nd anycast DNS network. Both our /24 subnets were obtained quickly under the NRPM 4.10 policy for IPv6 deployment for our dual stack DNS use case. 2nd was obtained without waiting 6 months due to being a discrete network.

We host our own authoritative DNS servers to provide DNS resolution for our services. Authoritative DNS are the servers queried by DNS resolvers run by your ISP, VPN or an explicitly user chosen one such as Cloudflare or Quad9 DNS. We now have our own AS and IP space for this.

Our ns1 has 11 locations on Vultr: New York City, Miami, Los Angeles, Seattle, London, Frankfurt, Singapore, Mumbai, Tokyo, Sao Paulo and Sydney.

Our ns2 has 4 locations on BuyVM: New York City, Miami, Las Vegas and Bern. We'll be adding a 2nd server provider for more locations.

DNS resolvers quickly fall back to the other network if traffic is dropped. Having two discrete networks with separate hosting companies and transit providers provides very high reliability. Individual servers which go down also stop having traffic routed to them due to BGP.

We have tiny #GrapheneOS website/network servers and also powerful update mirrors around the world. Our DNS servers use a combination of a GeoIP database and their own location to route users to the closest server that's up. Frequent health checks and low expiry time handle server downtime.