We definitely will have to keep up with the changes. We already do in order to provide support for using RCS via Google Messages on GrapheneOS. Recently, they made a change which broke it on GrapheneOS and we had to quickly fix that in under a day.
We passed it along to our developer working on solving VPN leaks. We didn't feel it was necessary to reply to a post linking to a public article. The article was shared with us by our users before we checked out emails.
We have a bunch of internally discovered VPN leaks which are already being worked on and this was added to that workload. We've already shipped a bunch of fixes and will ship more soon. We plan to eventually overhaul the whole system to prevent leaks in a much more systemic way.
Google considers VPN leaks to be valid bugs but unfortunately doesn't consider them security bugs. Internal issues are created for any issue report considered valid. The external one is only used to communicate with people. If it was filed as a security bug, they'll close it if it isn't considered within the scope of the bounty program.
I am not sure why all your comments are flagged, but here is my response to your other comment:
> We plan to heavily overhaul the VPN implementation to make most forms of leaks nearly impossible rather than continuing to use the current system prone to it.
Thanks, great to hear. Given the slew of bugs you uncovered it seems the Android implementation has some rough edges. Would `pasta` be helpful to you? It allows you to unshare netns and then pass a user-space network adapter inside. https://passt.top/passt/about/ Podman leverages this one as well in more recent versions.
The past couple weeks of our replies were maliciously flagged. We've made a post about it on social media as we've had to do before when this happens. This happens very regularly to posts by GrapheneOS or posts which simply support GrapheneOS. There are a bunch of malicious accounts which show up to each thread about GrapheneOS to make personal attacks towards our team, baselessly claim it's a honey pot, promote non-hardened products reducing privacy/security compared to AOSP and to make a bunch of disingenuous attacks towards it. The attacks towards our team often involve fabricated stories about us and harassment content. There's an account active in many of these recent threads making disingenuous replies and spreading Kiwi Farms harassment content in their profile:
This comment specifically was also auto-collapsed for me, without being marked as flagged or dead.
It might help to ask moderation about this. Could be an artefact of brigarding or something similar.
I also wouldn't worry about individual accounts so much. Asking for others to be banned, linking mirrored profiles, etc. That is just not the stuff many users like to read on HN. I think your technical content is truly amazing on its own already.
The past several weeks of our replies were wrongly flagged. None of our posts were in any way inappropriate and it's entirely appropriate to ask for help getting it undone. On the other hand, you're repeatedly making personal attacks on our team, engaging in doxxing and spreading harassment content. You're directly pointing people to Kiwi Farms harassment content with blatant libel and doxxing. There have been years of this harassment on Hacker News without it being addressed by the moderators. We're not going to be tolerating it anymore. Hacker News actively engages in moderation and therefore has no excuse to be permitting this harassment and leaving up years of it across many threads.
We've previously emailed them with no result. This time around we got a reply about this specific account targeting us but it isn't resolved. We don't have much optimism about getting the many past threads with personal attacks based around fabricated stories and harassment content addressed without doing more than asking via email.
Google considers VPN leaks to be valid bugs but unfortunately doesn't consider them security bugs. Internal issues are created for any issue report considered valid. The external one is only used to communicate with people. If it was filed as a security bug, they'll close it if it isn't considered within the scope of the bounty program.
Security issues considered outside the scope of what they consider a security vulnerability are closed regardless of what they plan to do about the issue. Google primarily uses internal issues to track issues with Android. Public issues and security issues filed by external parties are only used to communicate externally and an internal issue is created for their actual issue tracking.
A security issue being closed means you aren't getting a bounty and it won't be fixed for existing Android releases. It doesn't mean it won't be fixed in a future Android release. They do track VPN leaks as issues internally and regularly ship fixes in new major releases. They unfortunately don't consider those security issues so they don't get prioritized. If they were considered security issues, then they'd likely consider them Low or Moderate severity which means those wouldn't be backported.
Only a large subset of patches for High and Critical severity issues are backported to older releases of Android. Low and Moderate severity issues stopped having patches backported years ago due to volume. High and Critical severity patch backporting is now being scaled down too due to AI accelerated vulnerability discovery. You need the latest yearly or QPR2 release to get full updates.
GrapheneOS has had to fix a bunch of VPN leak issues and we're in the process of fixing more of the issues. We plan to heavily overhaul the VPN implementation to make most forms of leaks nearly impossible rather than continuing to use the current system prone to it.
There's nearly no information available on the working conditions, pay or environmental impact of Fairphones. T2Mobile is the company designing and making Fairphones since the Fairphone 4 and little information is available on them. Fairphone provides a long list of companies involved in the supply chain without more details than their location and website.
Pixels have long term availability of official parts for repairs and also official repairs.
Unlike Fairphones, Pixels have very good updates over the long term. Fairphones do not provide anything close to decent updates and it greatly degrades over the lifetime of the device. Fairphone 5 and earlier have an end-of-life kernel without security support. The devices start out lagging months behind on partial security backports and a year or more behind on full security updates which gets worse over time.
RCS already works on GrapheneOS via Google Messages using sandboxed Google Play. We have an ICC authentication toggle for granting the required access to Google Play services. We want to provide our own implementation within our Messaging app to replace Google Messages and then we want to provide an alternate backend not depending on sandboxed Google Play, at least for carriers with their own implementation.
It may take a long time to make a fully standalone implementation and that may not be compatible with most carriers. However, we plan to provide it in the short term through support for using the Google RCS infrastructure. We can have it start out supporting using sandboxed Google Play for RCS activation in the same way Google Messages uses it to replace Google Messages.
GrapheneOS already supports using Google Messages with RCS. Google Messages is essentially the only RCS app for Android and it's the only one supporting end-to-end encryption. There were other apps such as a Samsung one but they died out and are nearly entirely only still around on outdated devices as a legacy app. We don't want people to need to use Google Messages for RCS and plan to add it to our Messaging app.
reply