>And the parents that are worried about their children getting fucked up by hardcore porn and social media.
Rarely brought up during the OSA debate, but I think we all know every UK ISP has "Safety Shield" on to block access to adult entertainment - by default. When purchasing the service you're asked if you want it disabled.
If parents are disabling it, they can't be that worried.
I got it installed last weekend, really powerful mobile OS.
I did do about three weeks of research, as I worried that maybe a number of apps wouldn't run on it or needed some form of deep attestation. Didn't find much, OpsGenie and other work apps are happy with the GOS level of attestation provided.
Great to have Google kicked off the phone. So nice to shut off the network permission for any apps that only require an internet connection to serve ads.
One tip from me, if you came from stock Pixel: You can download the default Pixel sounds and set them up like it was. Have a look for "Your New Adventure" online, the message sound is "Eureka".
I've got a Pixel 9a expected to arrive today, specifically for it to run GrapheneOS. One of my old phones was a Nexus 6P running CopperheadOS (prior to the dispute that spawned GrapheneOS), and it was great back then. Looking forward to how things have progressed in the years since.
I wish GrapheneOS would support non-Pixel hardware, though, specifically my Fairphone 4. I get why that probably won't ever happen, but it feels like a massive regression in terms of repairable hardware to move away from that.
Yes, but there are various annoyances that I was tired of dealing with:
- RCS chats not sending/receiving, which has caused me to not be able to receive or send messages from/to multiple group chats with friends/family (probably going to be an issue with GrapheneOS, but at least plenty of people have reported that to be possible to work; currently doing the "disable RCS and wait 10 days" dance, so we'll see how that shakes out)
- Every other reboot the speakers would fail to initialize, meaning I couldn't hear anything except through Bluetooth (massive problem for getting up in the morning if I'm relying on my phone's alarms!).
- Microphone quality was inconsistent; sometimes I'd sound fine, and other times I'd sound muddy. Also not an issue through Bluetooth; it was just the phone's built-in microphone(s).
These were probably fixable issues, but I'm lazy and I wanted to give GrapheneOS a go, anyway (and so far I'm pretty happy with it, minus RCS still being a work-in-progress).
Except the default browser is Chromium with some changes
This reminds me of a recent HN comment I saw that suggested using Firefox was "kicking Google where it hurts" or something like that
Like Firefox, this project depends on Google. For the hardware, the web browser and who knows what else
It even offers a sandboxed Google Play Store
It tries to copy Google paternalism
It swaps a Google mothership for a Graphene mothership
What if the computer owner does not want a mothership
Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory
Even Netguard which works on any hardware and does not require root makes unnecessary connections to ipinfo.io servers effectively giving them a list of almost every domain the user's phone trying to access
If the concern is apps that only require internet connection for ads, Netguard solves that problem without root
Most apps but not all will try to connect to the internet at some point, even if you never use them
The user-hostile design of Android is that apps keep running in the background after they are "closed"
(There are crude apps one can use to automate manually killing each process with "Force stop" but no one uses them. This doesn't prevent apps from trying to access the internet on some preset schedule)
Netguard will show when apps try to connect and block the connections. It provides DNS logs and PCAPs.
One does not even need Netguard to see this subversive activity
Try this at home
Enable IP forwarding on a computer you can control, i.e., one that is running an OS you can compile yourself such as Linux or BSD
Put the phone on the same network as this computer
Set the phone's gateway address to the address of the computer
Run tcpdump on the computer and filter for the phone's IP address
I work for IPinfo. What is the context mentioning us here? I'm unsure if graphene uses our data. We process trillions of requests at the moment. I have no clue which services or software even use our data, let alone identifying individual IP addresses.
Is making a connection to our API a cause for concern? If that is the case, we welcome OSS projects to user our local IP databases, which includes our free IPinfo Lite database that we primarily designed for firewall and privacy applications.
But since privacy is a major concern for them, they should just use our IP-to-country database and host an API themselves on top of it: https://ipinfo.io/lite
We are happy to support and be part of any software that want to use our data.
I agree that it would be a more privacy-friendly solution for them to host their own API, but that got me thinking, wouldn't it be possible to just let users download the IPinfo data and use it locally? Does IPinfo offer database downloads? That's also how the Server-Status Firefox extension (https://github.com/tdulcet/Server-Status) works (but it doesn't use IPinfo). Also asking for potential personal use: How does the quality of IPinfo data compare to MaxMind, DB-IP, etc?
> Also asking for potential personal use: How does the quality of IPinfo data compare to MaxMind, DB-IP, etc?
We are miles ahead of everyone in terms of accuracy. Currently, we have 1,100+ PoPs across the world running active measurements. While traditional IP geolocation services are no much more than ASN/ISP reported data aggregation and parsing services. Our priority above all is accuracy and at this moment we are likely the industry leader for that.
If you have the time, go through some of our posts in our community and you will be surprised how good our data is right now. I will share my recent favorite one:
When viewing the "Show log" screen in Netguard, under the top right, three dot menu there are checkbox options for "Show names" and "Show organization". Netguard sends requests to ipinfo.io to get information about IP addresses. These requests to ipinfo.io do not show up in the Netguard log.
There is no cause for concern necessarily. These are design choices, nothing more.
Users have no idea what happens to the data that leaves their computers. To quote from another story currently on the HN front page: "It's incredibly easy to give information away. But once that data is out there, it's nearly impossible to take back." https://news.ycombinator.com/item?id=44689059
Promises made by developers are reassuring to some, but rarely if ever legally enforceable in the event something goes wrong, and the harm already caused may be beyond redress. As a proactive measure users can, among other things, seek to minimise the amount of data they send. For example, some users might want the _option_ to stop their phones from constantly trying to ping or connect to remote servers _without any explicit user intent to do so_. Maybe they do not want their phone to act like a beacon to someone else's remote server.
The point of the comment is that sometimes there are remote connections being made to servers chosen by developers that are assumed to be OK with all users, e.g., connections to Graphene servers, IPinfo servers, or myriad other examples. Meanwhile there is no option for the user to disable this behaviour. There may be some users who prefer _zero_ remote connections except the ones they themselves choose to initiate or enable. The possibility of such users often seems to be overlooked or deliberately ignored.
Like Firefox constantly sending HTTP requests to remote servers to check for "connectivity". Even when the user is not trying to connect to any server. The requests are sent in the clear. This is not optional behaviour.
Traditionally Windows allowed applications to be either minimized or closed. (AFAIK it still does.) These options might be displayed as buttons in the upper right corner of the window in which the application is running, for example, [-] and [x], respectively. When an application is minimized, it may continue to run in the background. When an application is closed, it does not run in the background.
An exception would be Windows applications that can be "run as a service". This is generally not default behaviour for user-installed Windows applications. It generally requires administrative privileges and manual configuration for each application
Unlike Windows, Android does not present an option to close an application while the application is in view. Android applications can be "swiped off" the screen, but they are not closed. By default, _all_ Android applications continue to run in the background. Closing an application in Android requires using a separate app. For example, opening the "Settings" app, then finding the app to be closed in a list of apps, then "stopping" the app by selecting "Force stop" as describeed in the articles above. If the Android user wants to close a number of applications running in the background simultaneously, she is out of luck. They can only be closed serially, one after the other. She must find each of them via the Settings app and Force stop each one, individually. This is extremely tedious and slow and, as one would expect, results in almost all Android users allowing applications to run in the background. The tedium mandated by this design could be purely coincidental.
There are only a few services GrapheneOS devices connect to:
- a time server (securely, over HTTPS, not insecure NTP)
- the OS update server (obvious; it's just plain HTTP requests, no user identifiers other than the IP address, which can easily be masked by using Tor or a VPN)
- the GrapheneOS App repository, which provides updates for preinstalled apps like Auditor, as well as the Vanadium browser and WebView (it's critical to get security patches for your browser in a timely manner)
- network connectivity checks (required to sign in to public wifis that use captive portals; can be entirely disabled in the settings)
- SUPL and PSDS through GrapheneOS proxies for A-GNSS because there is no network location service enabled by default
> Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory
You can block all the connections. You don't even need to, since they can all be disabled in the settings. If you disable the System Updater app, you're gonna have to adb sideload your system updates https://grapheneos.org/usage#updates-sideloading.
> If the concern is apps that only require internet connection for ads, Netguard solves that problem without root
You don't need Netguard, GrapheneOS has a built in network permission toggle, which offers even better protection than a firewall, since it completely blocks access to the underlying network socket (https://grapheneos.org/features#network-permission-toggle)
> The user-hostile design of Android is that apps keep running in the background after they are "closed"
You can deny apps running in the background, even on stock Android. This isn't unique to Android btw, I'm sure you've come across the system tray in Windows before. Those are all apps running in the background. Android basically has the same thing, it's in the notification center, and you can also stop background apps from there.
> So nice to shut off the network permission for any apps that only require an internet connection to serve ads.
For those of us who aren't ready to cut the umbilical cord to the mothership, you can also root/firewall on normal android to stop this. In fact I choose to not be able to use banking apps in order to cut out the crappy ads.
For those who don't want to root the phone, you can still avoid most of the ads by using a filtering DNS server with the Private DNS functionality on stock Android ROMs (or only at browser level if your favorite browser support DNS over HTTPS).
It comes with some minor usability issues with captive Wifi portals sometimes, but the trade-off of not having ads in app or while browsing is way worth it IMHO.
You can use RethinkDNS and avoid compatibility issues with captive portals. This is one of the options we recommend for GrapheneOS users. RethinkDNS is implemented as a VPN service but it has support for local filtering combined with optionally using a WireGuard VPN or multiple chained WireGuard VPNs. Android's captive portal handling works with a VPN and VPN leak blocking active since the connectivity checks are specially marked as not going through the VPN and so is the captive portal handling component opened by the captive portal notification. Private DNS is still missing support for this and also has the issue of causing DNS leaks for secondary profile VPNs.
I put a Private DNS ('controld' for that matter) and never looked back. No more private VPNs with Blokada, no more block list updates. You choose if you want ad, tracker or adult blocking, without hassle, for free.
> For those of us who aren't ready to cut the umbilical cord to the mothership
You can use Google apps and apps depending on them on GrapheneOS via sandboxed Google Play. The vast majority of Android apps can be used. You don't need to stop using Google apps/services or other mainstream apps to use GrapheneOS. It's likely nearly all the apps you use or even all of them work on GrapheneOS. There's a per-app exploit protection compatibility mode toggle (and finer-grained toggles) to work around buggy apps with memory corruption bugs. We avoid turning on features breaking non-buggy apps by default and hardware memory tagging is temporarily opt-in for user installed apps not marked as compatible due to how many memory corruption bugs it finds.
A small number of apps are unavailable due to checking for a Google certified device/OS via the Play Integrity API. These are mostly banking apps, but most banking apps do work on GrapheneOS. There are tap-to-pay implementations which can be used on GrapheneOS in the UK and European Economic Area. Several banking apps recently explicitly added support for GrapheneOS via hardware-based attestation as an alternative to the Play Integrity API. We're pushing for more apps to do this and for regulation disallowing Google from providing an API to app developers for enforcing devices licensing Google Mobile Services. Play Integrity API often portrayed as a security feature but Google chooses not to enforce a security patch level. They're permitting devices with years of missing important privacy and security patches but not a much more private and secure OS. Only their strong integrity level has a patch level check, but the check is only done for recent Android versions and only requires they aren't more than 12 months behind on patches which serves no real purpose.
> you can also root/firewall on normal android
This is different from our Network permission which not only blocks direct access but also indirect access via APIs requiring Android's low-level INTERNET permission. Our Network permission also pretends the network is down through many of the APIs. For example, scheduled jobs set to depend on internet access won't run.
Graphene has a really great sandboxed google servicen implementation, so barring a handful of banking apps not working, switching to graphene is a very gentle cutting of the mothership. For me it was very subtle, with better battery life!
The Netguard app worked well for me for that on vanilla burners and such. No root, "VPN" that I had block pretty much everything but the browser and Signal.
Even without root, a VPN-style firewall will work against all non-system apps. The downside of this approach is that you can't combine one with another VPN app.
RethinkDNS is implemented as a VPN service but it has support for local filtering combined with optionally using a WireGuard VPN or multiple chained WireGuard VPNs. You can have both via the VPN service API rather than choosing one or the other. No need for app accessible root access.
Yes. I used to run NetGuard, but Karma seems to work very similarly.
It looks like there's an app on F-Droid called "Rethink" that promises to do both firewalling, DNS blocking, and offers a WireGuard VPN. That seems promising, though I must add that I haven't tested it myself.
Rethink isn't quite ready yet. Depending on your use case you can go without getting thrown off by a bug for weeks, but when it fails it can be quite annoying. And don't use the GPlay version, but the FDroid or GitHub one.
On the other hand, the functionality is top notch. Easily the best integration of consumer level DNS + firewall blocking in any application on any platform. Just block everything of an application by default and then watch the connection logs for the app and start unblocking stuff via ips, domains or wildcards until the app starts working again.
RethinkDNS is implemented as a VPN service but it has support for local filtering combined with optionally using a WireGuard VPN or multiple chained WireGuard VPNs. You can have both via the VPN service API rather than choosing one or the other. No need for app accessible root access.
I use both adaway and AFWall+, as I don't like random apps making random connections, even if it's not for adverts. Once google play store ate my monthly data allowance, and it will never happen to me again.
Haha. I only avoided that reflexive action because my reflex when a large online service is down is to start typing 'news.ycom...' in my address bar and then scroll down to search :-)
Of course hilarity will ensue the day I experience a HN outage and wish to see if anyone has made a thread about it...
I didn't realise bang operators work even when DuckDuckGo itself is down.
That's pretty neat, I don't need to change the search in the address bar, just add '!g' to every search to seamlessly redirect to Google until DuckDuckGo is back.
I use fish with the sponge plugin that omits any command that doesn't return an error code 0.
Combined with ones like `z` to jump around directories, I reckon my history is pretty tidy.
Anything important and convoluted, I'll shove it in the fish config for quick access.
> I thought we were making progress in the anti-surveillance privacy na[rra]tive
What lead to to believe that? The Conservatives and Conservative-Continuity governments both agree that our data simply must be in the hands of the police, DEFRA, and your local council.
RIPA will never be repealed and only strengthened.
I don't disagree with your analysis but i wouldn't be so fatalistic. This stuff _isn't_ inevitable and i think it's possible to win people over to our side. Things can change for the better, but they won't unless people who care don't give up
Ahh, I used to have that opinion, but I've encountered too many "It's fine if they want it, I've got nothing to hide" people. (They never give you their Facebook password if you ask, though. Funny, that.)
Change what you can, I say, VPN on the network device.
> When Oliver shows Snowden evidence that all typical Americans care about is whether the government can see our "dick pics," he encourages Snowden to go through a list of every government surveillance program and explain its capabilities in terms of access to "dick pics."
Rarely brought up during the OSA debate, but I think we all know every UK ISP has "Safety Shield" on to block access to adult entertainment - by default. When purchasing the service you're asked if you want it disabled.
If parents are disabling it, they can't be that worried.