Secure paste has been merged into #GrapheneOS to provide a replacement for focused apps being able to read the clipboard: https://github.com/GrapheneOS/platform_frameworks_base/pull/435

Was somehow an existing feature in the AOSP messaging app already.

Not intentional. Sent the above to team to see if it can be recreated. Some VPN apps may not be playing well to the tighter leak protection. I assume User Profiles are fine?

Features like that are in the issue tracker to do, don't worry. Just like I mentioned it won't defeat the most invasive types of fingerprinting, if there's data that is randomised they will choose to track on what isn't instead.

(would be an edit of above but I know some clients don't behave well on certain nostr features so they make me use comments, sorry!) The privacy/resistance score used by CreepJS is a great example of measuring metrics against someone's attempts of trying to resist/circumvent being fingerprinted. A service could just close someone out of they think a user is 'suspicious' enough

^ You can use a browser *designed* for going against it like Brave, but you'll find one of these tests still continue to work against it. Even the Tor Browser on Mobile does and you have to wipe the browser data / state each time for all of the browsers or timing out a service until they forget about you

See what was talked about here: https://discuss.grapheneos.org/d/5775-device-fingerprinting-test-results-concerns-and-questions/20 https://discuss.grapheneos.org/d/19692-vanadium-fingerprinting/4 Disabling the JS wouldn't actually stop it in practice, because you'd stand out incredibly by the lack of data being provided in comparison to almost everyone else on the planet. The service just isn't adapted to that scenario and it would be trivially easy to set up a library to do it. You should use web services that respect your privacy and don't do such nefarious things as a first priority. No browser's fingerprinting protection works well at all and is highly dependent on having a crowd. On most implementations it's randomizing data points and hoping that the service admin isn't smart enough to correlate or to track the points that do not change. The more invasive a site is about fingerprinting then any resistance towards it is increasingly less possible, final boss being services requiring you to KYC to use it. This would apply even for browsers with strict settings that do not change. Take a look at your display size, locale, timezone, GPU, for example or even benchmarking the device performance. In reality the fingerprint suggests a GrapheneOS user of a certain device with a VPN and it tries to keep that as much as it can which goes under the radar for more naive services.

GrapheneOS is open source so we expect access to that code to be available to anyone including who we don't like. There have been malicious forks. Someone could easily mirror the code to GitHub had it not been there already. Someone can also automated mirror the repos from our GitHub and GitLab elsewhere if they don't like the platforms. For a lot of open source projects, finding the talent is harder than funding. GrapheneOS is getting kinda popular now so there's a fan base and funding behind it even if it comes at a consequence of getting mentioned on mainstream news for clicks and hype. The best developers are obviously living the dream with big tech salaries which no one can blame them for taking it. We have enough to hire multiple people, it's just they need to fit what developers want and have the GrapheneOS attitude and 'culture'.

When it comes to open source software, the corporates funded with state money who want to find vulnerabilities in your software for their advantage are often far more qualified, resourceful and committed to their objectives than the limited project developers are. You must be more cautious about having both a secure design and a secure implementation of the design of your software at the earliest possible stage of software development. This increases the time and effort to discover a vulnerability or can close out entire classes of vulnerabilities. We have seen how massive projects are weighted down from development standards of the late 90s and 00s that makes them have thousands of CVEs every release. https://www.phoronix.com/news/Linux-Kernel-CVEs-Nearly-2000 Check out some of the open-source AI tooling from Cellebrite to improve their workflows and automate in researching mobile device vulnerabilities. https://github.com/cellebrite-labs/ghidra-rpc https://github.com/cellebrite-labs/ida-bridge https://github.com/cellebrite-labs/ida-docs https://github.com/cellebrite-labs/ida-porter You can have opinions on the issues of LLMs (and I have several), but that comes with having to accept an adversary is accelerating how to harm you with that technology.

You can see the individual pull requests for how many people have worked on the app and that there's people discussing what to do. There's people involved in every step or the development testing for quality. Here's the largest: https://github.com/GrapheneOS/Messaging/pull/109 The leading apps dev has around a decade and a half of experience in developing on the Android platform alone. His contributions so far have been incredible. We have a broad access to many LLMs for security testing, including cyber-enabled models for dual-use. It's not actually writing the code of GrapheneOS much. It would be poor to willingly dumb ourselves down when companies such as Cellebrite are devoting teams to creating AI tooling to reverse engineer mobile devices to try and exploit them.

GrapheneOS App Store app. You may need to change the release channel to get it early (see the three dots at the top right).

The Secure in this instance means a place that is difficult to get out of or escape from, rather than the digital security itself. The purpose is to store sensitive data away from the OS so it is not compromised if the OS is. There are many secure elements that have poor security, like your standard dedicated desktop 'TPM'.

Would check out. Appears to be invite-only.

When the overhauled Clock app is worked on it should absolutely be, it's just the AOSP apps are that old from when standards of what Kyiv was a mess. There's also some time zones that are missing there.

Unaware of other open source projects using RCS. However RCS on Android is currently implemented with code across the OS, Google Messages and Google Play services. To start it would require sandboxed Google Play for RCS activation and so on. It would be less reliant, but not entirely separated. RCS isn't an open platform at all compared to SMS/MMS. It heavily depends on proprietary Google and carrier infrastructure. We can start by replicating Google's approach in the messaging app they have and then we can work on only using carrier services for carriers where it's actually supported to cut that out. RCS support is simply for added compatibility and feature pairity. People should use a secure messenger not relying on mobile carriers as a first choice, which our messaging app first run tells you about.

We haven't released these in other app stores yet but eventually this could be done when they're more of a standout app. For the messaging app where we plan to use RCS support this might only work as intended on GrapheneOS, so need to see how we approach it first.

Using this as a space to verify myself. (Please ignore). I own the seed for @final on Stasher News. This npub is associated to the same username on Stacker News.