@GrapheneOS Is there any way now or in the future to get graphene os on a pocket sized device (not the pixel tablet) without cellular? Any ways to securely remove those capabilities from a pixel?
[#]grapheneos
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@GrapheneOS It really seems like where ever people bring up the question of cellular surveillance and protection against it or just hint in the direction of hardware measurements to have a fail-safe many people defend the official graphene position like in this thread without taking into account that it is an actual thread for folks all over the globe with different use cases for grapheneos to protect against cellular attacks and surveillance with a bit more than software toggle that can currently be worked around without unlocking.
I really love the GrapheneOS project and appreciate all your work guys, but this I just don't understand.
(I also don't want to start any beef around this if you decide that this is not part of the thread model grapheneos can help to protect against then that's unfortunate but fine)
@matchboxbananasynergy @shady_
[#]grapheneos #opsec #surveillance #zeroday #cellularattack
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi Cellular is integrated in a similar way as Wi-Fi and Bluetooth via an IOMMU isolated radio which can be reliably turned off. Samsung makes both the main SoC and the cellular radio. Not clear what you're trying to avoid. If you don't want to use cellular, use airplane mode.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@GrapheneOS And what if the risk of airplane mode for example in pocket or by thread actor gets disabled? This is a fundamental thread for some use cases.
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi @GrapheneOS You can't enable/disable airplane mode while the device is locked on GrapheneOS. Give it a shot. You'll see it asks for authentication.
=> More informations about this toot | More toots from matchboxbananasynergy@infosec.exchange
@matchboxbananasynergy @GrapheneOS I understand that but first of all graphene os can only be installed after you boot and enable dev settings for bootloader unlock, the device connects to cellular, after the installation it is still a big risk if you have to keep the device unlocked and hand it over to other people.
I'm honestly critical of the official graphene position that software toggles are enough for all use cases. For some people this can even be a life or dead question and to just recommend air-plain mode seems a bit inconsiderate.
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi @GrapheneOS In order to complete GrapheneOS' installation, you lock the bootloader, in case that wasn't clear.
=> More informations about this toot | More toots from matchboxbananasynergy@infosec.exchange
@matchboxbananasynergy @GrapheneOS yeah that's clear
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi @matchboxbananasynergy You can buy a device with GrapheneOS installed if you don't want to install it yourself. Not clear what you think the risk is with having support for cellular. It's not substantially different from Wi-Fi and Bluetooth. They're each implemented in a way that's isolated and unprivileged. Cellular does not have control over the device as you seem to believe.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@matchboxbananasynergy @GrapheneOS That is not true, you can disable it from the lockscreen when attempting an emergency call, @GrapheneOS THIS IS EXTREMELY DANGEROUS.
Same behaviour with disabling the microphone.
Again for a life dead situation some thread scenarios need fallback options especially because issues like that.
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi @GrapheneOS That requires an explicit action on part of the user. What makes a hardware switch different, which could be switched by someone with physical access to the device?
=> More informations about this toot | More toots from matchboxbananasynergy@infosec.exchange
@matchboxbananasynergy @GrapheneOS Never talked about hardware switches here but also there is an actual difference, this can literally happen in your pocket by accident and even if fixed, the potential alone can be dangerous. I'm talking about a device that has not cellular to make completely sure stuff like this can't happen.
Also in case GrapheneOS has a zero day that allows root privileges (I know this is not that likely and a highly targeted attack) and the device itself does not store any dangerous information but becomes an issue if located you have a big problem. So the argument often used that you are fucked anyway is also not really a holistic one.
And yes i know location tracking is also possible in many other ways but this is the main thread for many people for example struggling under repressive regimes.
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi @matchboxbananasynergy That's not true. You can remove airplane mode from quick settings after disabling it to avoid toggling it on by accident. The emergency button does not disable airplane mode. Only explicitly calling an emergency number like 911 after pressing it disables airplane mode. This requires physical access to the device and the explicit intent to call an emergency number.
The threat model you're describing about an attacker already having root access is nonsensical.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@fredy_pferdi @matchboxbananasynergy An attacker with root access can use GNSS or Wi-Fi to detect location. GNSS exists for that purpose and Wi-Fi is heavily used for that by Apple and Google via their network location services. You're talking about an attacker who has ALREADY compromised the OS and gained kernel/root level access. You're trying to come up with contrived reasons for the existing functionality not being enough but none of what you're claiming checks out.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@GrapheneOS @matchboxbananasynergy yes that you right I'm wrong with that point.
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi @matchboxbananasynergy There's nothing "extremely dangerous" about being able to very explicitly make emergency calls with physical access to the device. We have a planned feature to provide a toggle for whether emergency calls can be made while locked but it's not a high priority and certainly not something extremely dangerous. The toggle will not be very useful to most people yet without another feature like a toggle for automatic airplane mode at reboot.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@GrapheneOS @matchboxbananasynergy But that here is still a valid issue. As long as this is not reliably solved using a graphene os is not usable for guaranteed radio silence.
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi @matchboxbananasynergy Cellular is one of 5 radios: Cellular, Wi-Fi, Bluetooth, GNSS and NFC. GNSS is receive-only and NFC is extremely low range, but Bluetooth has decent range and Wi-Fi has very long range especially in the longer range modes. Wi-Fi, Bluetooth and cellular are used for network-based location, which is mainly based on Wi-Fi in cities. It sounds like you don't want to have any radios at all. What is special about having a cellular radio with it disabled?
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@fredy_pferdi @matchboxbananasynergy Accidentally disabling airplane mode is not a real world issue if you remove the quick tile. Providing a toggle to prevent disabling airplane mode via an emergency call is already planned as a minor feature to improve protection against forensic data extraction similarly to how automatically disabling USB-C at a hardware level while locked is implemented by GrapheneOS and enabled by default. It's far lower value since it can't be default and is conditional.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@fredy_pferdi @matchboxbananasynergy Disabling USB-C while locked is the default. Enabling airplane mode while locked cannot be the default, but could be supported as an option, although it would hurt usability quite a lot especially since it can take a long time to reconnect. Enabling airplane mode after reboot is another option which would be a lot more usable.
Toggling off ability to do emergency calls while locked with airplane mode enabled cannot be the default because it's a safety issue.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@GrapheneOS @matchboxbananasynergy There is no other device that has such hardware protection features, what other alternative is there? So a no radio Pixel is something that has a use case, only working with Ethernet is an option when radio silence has to be uphold with certainty.
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi @matchboxbananasynergy You can remove the radios from a Pixel if you want. It will still boot and work fine, although there will be errors and it might drain some battery life while awake trying to connect to those components without the OS explicitly supporting them being missing.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@GrapheneOS @matchboxbananasynergy That sounds very interesting, I always was thinking the main components are part of the processor nowadays.
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi @matchboxbananasynergy Snapdragon includes an isolated baseband as part of the SoC with separate isolated processes running on it for cellular, GNSS, Bluetooth and Wi-Fi. We no longer have any officially supported Snapdragon-based devices now that the Pixel 5a is end-of-life and in extended support. All of the devices we officially support are Tensor SoC Pixels which have a Samsung radio chip, Samsung or Broadcom GNSS chip and Broadcom or Qualcomm dual Wi-Fi/Bluetooth chip.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@fredy_pferdi @matchboxbananasynergy Therefore, for all the officially supported devices, it's possible to remove the radio chips if you really want to outright remove the functionality. The device will boot without one or more of the radios present, but it will likely repeatedly try to connect to it which could drain a bit of power while the device is awake. It's definitely able to handle the radios not being present but it's not something that's heavily tested or optimized.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@fredy_pferdi @matchboxbananasynergy It might not drain a significant amount of power in practice, we don't know. We're just warning that it could theoretically drain significant power trying to reconnect, although it's probably fairly throttled and won't really make a significant impact.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@GrapheneOS @matchboxbananasynergy This is amazing, thanks a lot for your in depth response :) I'm sorry if I any how sounded antagonistic or was a bit stupid.
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi You can remove the airplane mode quick tile if you don't want it to be possible to accidentally toggle it through the quick settings tray. If someone remotely exploits your device to get the level of control needed to disable it, they already have access to your device anyway. Wi-Fi can be used too.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@GrapheneOS @fredy_pferdi does airplane mode disable all cellular function including timezone and time setting?
Also, why do mobile OS's use cellular to set time instead of NTP or internet time like all other internet devices?
=> More informations about this toot | More toots from shady_@mastodon.social
@shady_ @fredy_pferdi
does airplane mode disable all cellular function including timezone and time setting?
It disables the cellular radio, so no functionality using it is available.
Also, why do mobile OS's use cellular to set time instead of NTP or internet time like all other internet devices?
That's not accurate. Android supports obtaining time via cellular, NTP or GNSS. The default is using cellular as the highest priority and NTP as a fallback. Cellular is more reliable.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@GrapheneOS @fredy_pferdi thanks!
=> More informations about this toot | More toots from shady_@mastodon.social
@GrapheneOS @fredy_pferdi slightly related, enabling airplane mode currently also disables UWB - is there a way to separate the functionality of these two? I always have airplane mode on to not use cellular but like Bluetooth, I'd still like to be able to use UWB features most of the time.
=> More informations about this toot | More toots from nickc@mastodon.online
@nickc @fredy_pferdi Enabling airplane mode disables all the radios but it only force disables cellular. You can re-enable the non-cellular radios in airplane mode.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@GrapheneOS @fredy_pferdi not UWB on my device at least
=> More informations about this toot | More toots from nickc@mastodon.online
@nickc @fredy_pferdi Might be a regulatory issue. We could provide another toggle for cellular but that would be complex and hard to do correctly. It would be easier to provide a way to use UWB with airplane mode on but we'd need to look into why it's disabled.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@fredy_pferdi @matchboxbananasynergy @shady_ Your claims about this are highly inaccurate and not based on any real world threat model. You want to have something for unclear reasons and are trying to come up with contrived reasons you need it. You're working backwards from wanting something to coming up with reasons you should want it instead of having reasons to want it and then requesting it. Cellular is implemented via an isolated radio and other than SIM support is similar to Wi-Fi radios.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@GrapheneOS @matchboxbananasynergy @shady_ Yeah for that thread level using Ethernet only is the way to go think.
=> More informations about this toot | More toots from fredy_pferdi@social.linux.pizza
@fredy_pferdi @matchboxbananasynergy @shady_ The receive-only GNSS radio exists for location detection and is the main way to do it either outdoors or in wood frame buildings not blocking it.
Network-based location is normally done based on Wi-Fi, cellular and Bluetooth beacons. At least in cities, Wi-Fi is the most important part of it and provides the most.
Cellular is not needed for location detection. Pixel Tablet lacks both GNSS and cellular but can still detect location via Wi-Fi.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social
@fredy_pferdi @matchboxbananasynergy @shady_ The stock Pixel OS uses Google's network location service by default and on the Pixel Tablet can still do quite decent location detection. It's not as precise or reliable as it would be with GNSS but it works fine in cities. It won't usually work well in a rural area since there won't always be Wi-Fi around and it won't be as regularly mapped by people using Android devices with location active and submitting data to Google for their database.
=> More informations about this toot | More toots from GrapheneOS@grapheneos.social This content has been proxied by September (ba2dc).Proxy Information
text/gemini