Miscellaneous Security Concerns

BillHurdle

First of all, I really appreciate whoever it was that seems to have acted upon some of my previous security suggestions by improving the code. Maybe it's just coincidence but GrapheneOS is better as a result.

I've been stacking up a new list of various security concerns for a while. I can't afford to report them as I notice them because I just don't have the time. This list is more for the sake of raising awareness so that the devs can at least make a decision of whether and how they want to address them in future updates. Maybe the answers are in the docs somewhere so apologies if that's the case but I'd rather just make sure it's all out there. In no particular order:

I've always wondered about the signin app the comes up when you try to connect to a public wifi. I don't even know what the app is, let alone what it might remember about past sessions. I was really stunned once, on a stock Android phone, to find that it remembered me from months ago, even though I had MAC randomization enabled! "Hi Bill! Welcome back to the hotel!" Because I don't know what the app is, I can't even go and clear its storage. I'm just left to hope that it forgets everything when I disconnect from wifi. Maybe it's all fine but it would be nice if that were made obvious somehow.
Several weeks ago, a change went through that made the Internet button go dark when you lose wifi, even if the wifi hardware is still on. It would only be too easy to go walking down the street, spraying your hidden SSID everywhere, because you think it's off. I think the button should be illuminated if the hardware is on, regardless of the connection status (which is already easy to inspect by virtue of that "!" that goes over the signal strength icon if there's no actual network connection).
Last year, Apple made a change to their wifi UI that was actually helpful. They alphabetized all the SSIDs so you don't get races between finger tapping and SSID reordering, or at least not nearly as often. I think they concluded that sorting alphnumerically was more conducive to list stability than signal strength; what it lacks in predictive quality it more than makes up for in UX. In any event, it's not good to have a jumpy list because there are some rare but nasty potential mishaps that invites. For similar reasons, I would recommend putting all the fixed menu items above the SSID list so they can be accessed in a stable manner (for example "Saved networks").
I was shocked to discover that Telegram can hijack the storage clearing UI. That means you can't actually clear its storage at all (which is why it will at least remember the phone number you previously used with the app). It just comes up with lots of rainbow colors and a big checkmark in order to reassure you that everything has been erased. Not! Yes, we could just keep doing full (un)install cycles but that seems heavy handed. No app should be able to intercept its own storage clearing.
Do predictive text and/or spell checking hit the internet? Encrypted or in the clear? To what server? Owned by who? Are they used to train a local model? What access controls are on the training data or the resulting neural net? Am I overthinking this? Probably so.
I have an app in the Owner profile. Like most sneaky apps, it wants network permission, but I refused to grant it and it works fine. Eventually I decided to copy it into another profile using the "Install available apps" menu. Very handy! The only problem is that when the app lands in the other profile, it's automatically granted network permission! No popup, no warning, nothing.
If someone hotspots through your phone, it's not obvious that their traffic doesn't hit your network stack, so you could be forgiven for thinking that you're helping them by covering them with your VPN. Ideally there would be an option to pull them through your VPN (but defaulting to current behavior). Absent that, some sort of notification about this would be useful when hotspot is enabled.
I learned the hard way that you can't prevent the Owner profile from working in the background (while you're in another profile). Well duh! Now consider what this means: If your Owner profile isn't using the same degree of VPN hardness (or onion routing) as your other profile, then when you switch to your other profile, then your overall security level is the lesser of the two. So for instance maybe Owner isn't using any VPN at all because you only use it at the office, which already has a VPN at the router. Then you switch into your Home profile before you leave, which has a VPN app. But now you might not be aware that your Owner profile is still talking to the internet without a VPN, from your home! I don't know how to handle this. Obviously Owner needs to stay active no matter what because it has to deal with stuff like alarm clocks that need to ring even when you're in another profile. Maybe put a toggle somewhere that says "Disable Owner network access when in another profile". And "Don't enable Owner network access automatically upon return". Something like that.

That's all I got for now. Peace!

fid02

BillHurdle

First of all, I think all of your questions are easily answerable, although I will refrain from answering them all because I don't think I can phrase my answers to them in a clear enough way. And frankly, I'm not sure I am comprehending points 2-4.

You are writing that you do not have time to report or read documentation. Therefore, my first normative statement is this: you should find time to read the official documentation on https://grapheneos.org and, if you do not find answers, please search this forum. Then, if you are still struggling with your questions, you are of course more than welcome to make a thread.

I am having a bit of a hard time understanding why you do not have time to read official documentation, and at the same time writing a lengthy post which surely demands lengthy replies from community members, if they are to be of quality. If you do not have time to first read official documentation, and search this forum, I must nearly assume that you do not have time to read this very reply. It is not my intention to be cross, and I hope this doesn't come across as rude.

It's my decision to spend time writing this, but after having done so, I do partly regret doing that. Still, since it's already written, here it is. In the future, I will avoid replying to such threads, other than pointing towards official sources.

1.
"I was really stunned once, on a stock Android phone, to find that it remembered me from months ago, even though I had MAC randomization enabled!"

You are thinking about captive portals, which show up mostly on public Wi-Fi networks where the network wants you to provide some form of registration, accepts its terms of use, etc.

"I was really stunned once, on a stock Android phone, to find that it remembered me from months ago, even though I had MAC randomization enabled!"

Your stock Android phone does not implement per-connection randomized MAC, as GrapheneOS does by default. In practice, that means that the network is unable to identify you based on the MAC address the next time you connect to that network.

If you would like to avoid receiving the captive portal on each time you connect to a specific network, you can go to the network settings of that network and change it to either "Use per-network randomized MAC" or "Use device MAC". I recommend the former, unless you have a clear reason to reveal your real MAC address to the network.

There's nothing to worry about by sticking to the default settings. The defaults are sane and provides Wi-Fi privacy beyond what the stock PixelOS provides. You can adjust them as desired.

Wi-Fi privacy on GrapheneOS goes far beyond just randomizing MAC addresses per-connection. More info here: https://grapheneos.org/usage#wifi-privacy

There might be some benefit to showing the user a brief descriptive text within the OS about randomized MAC and the causes of captive portals reappearing on each connection. But I'm not a UI designer, merely a QA tester, and I don't know how many users would find this helpful in practice.

5.
"Do predictive text and/or spell checking hit the internet?"

The GrapheneOS keyboard app – which is the default – does not make network connections. It does not send your typing data to a server. You have nothing to worry about here.

6.
"The only problem is that when the app lands in the other profile, it's automatically granted network permission!"

This is expected. And in my opinion, desirable. The secondary user could be another person, who could desire that the app connects to a network by default. If it didn't, they might be confused as to why it doesn't work. The user of the Owner profile might have entirely different needs and preferences.

7.
"If someone hotspots through your phone, it's not obvious that their traffic doesn't hit your network stack, so you could be forgiven for thinking that you're helping them by covering them with your VPN."

You could be forgiven, if you didn't know that the hotspot feature follows the same logic as Android's per-profile approach to VPN connections. It avoids giving a secondary device and secondary user the same exit IP.

If the VPN from your Owner/secondary profile was routed through the hotspot, that device and the services it uses would know the exit IP of your Owner/secondary profile. I can see that sharing the VPN cross-devices might be of some convenience for a certain group of users, but it is an approach that is detrimental to privacy, and there is a reason Android doesn't do this. Note that this is the approach taken in upstream AOSP, and not something GrapheneOS has changed.

"Absent that, some sort of notification about this would be useful when hotspot is enabled."

Perhaps useful to some users. Other users might become confused as to why the OS is suddenly showing them a notification about VPNs, when they might not be using one or might not even know about VPNs. They might misinterpret the notification text. I guess there could be some brief text in the Hotspot interface. Perhaps you could make a feature request on Github?

8.
You can solve this by running an always-on VPN with "Block connections without VPN" enabled for the VPN in the Owner profile. If you are using secondary profiles for all your apps, and have no third-party apps installed in the Owner profile, the connections that are made are documented here: https://grapheneos.org/faq#default-connections

I don't see the logic behind this concern, and it does not lessen the security of your device. But you may have the threat model of needing to hide the default GrapheneOS connections from your ISP or the network. You can use a VPN.

Please also see this: https://grapheneos.org/faq#encryption

Sensitive data is stored in user profiles. User profiles each have their own unique, randomly generated disk encryption key and their own unique key encryption key is used to encrypt it. The owner profile is special and is used to store sensitive system-wide operating system data. This is why the owner profile needs to be logged in after a reboot before other user profiles can be used. The owner profile does not have access to the data in other profiles. Filesystem-based encryption is designed so that files can be deleted without having the keys for their data and file names, which enables the owner profile to delete other profiles without them being active.

other8026

BillHurdle hidden SSID

please take a look at https://grapheneos.org/usage#wifi-privacy-scanning

BillHurdle They alphabetized all the SSIDs

This would be something I'd expect AOSP can do. GrapheneOS developers are busy improving the OS to maximize our security and privacy. They don't tend to make UI tweaks like this.

BillHurdle No app should be able to intercept its own storage clearing.

I don't know how this works, really, but again this would be something upstream AOSP would change. GrapheneOS cannot change certain things because it might affect app compatibility. I'm guessing this may be one of those cases.

BillHurdle Do predictive text and/or spell checking hit the internet?

All of this depends on the app.

BillHurdle it's automatically granted network permission! No popup, no warning, nothing.

https://github.com/GrapheneOS/os-issue-tracker/issues/2226

BillHurdle

@fid02 Since you asked... I get your point about "please read the docs first" and I'm not offended by it because I don't want to waste everyone's time, either. But my choice was between either spending hours that I don't have searching for the answers (without necessarily knowing what terminology to key on) and then investigating all the arguments and counterarguments, or just dumping it here for those who are willing to risk a bit of their time in exchange for maybe learning about a way to improve the product. Writing the long post was easy because it was actually done over several weeks, one discovery at a time. People who only want to hear about confirmed vulnerabilities would have stopped reading after my second paragraph, and that's fine.

I've always read all my replies on this forum, including yours, which I think are of benefit to anyone reading the thread, notwithstanding some disagreements on my part.

@fid02 Yes "captive portals". (I was unaware of the term.) I knew about the 3 MAC randomization policies but I still posed the question because I was thinking of other fingerprinting issues such as cookies that might survive in the "browser". I didn't know because there's nothing in the UI that indicates one way or the other. ("This is your first time connecting to a captive portal. We'd like to inform you that once you close the app (and turn off wifi?) it will forget everything.") Nevertheless I think your explanation of my stock Android experience is likely correct.
@other8026 Well that was informative. "SSIDs are not broadcast for standard non-hidden APs". Years ago I was told that there were (are?) Android phones that would constantly walk through their entire SSID history, shouting each one out until one of them replied (or wifi was disabled). I guess they did so because it minimized reconnection latency and the privacy ramifications were an afterthought. So in the case that one doesn't use hidden SSIDs, it doesn't matter if the wifi button is dark even though the radio is still on. But if one does use them (say because they're controlled by other people) this is still an issue.
@other8026 Yeah, it's not at the same priority level as security enhancements. Although it's annoying and does have some security ramifications. (I've actually connected to the wrong wifi because of the constant position juggling in the SSID list.)
@other8026 You are probably correct that changing this might break some (very few) apps. I recommend breaking them because no app should have the power to protect its local datastore against deletion, or worse (as in this case) lie about it having been cleared. Not the biggest security vulnerability by any stretch, but a problem nonetheless.
@fid02 Thanks for the explanation. Sounds fine so long as there's no way some other app can obtain the predicted (but not yet typed) text (and then send it via its own network access). (This is because the prediction itself can imply data that has previously been entered into yet another app.) My understanding is that's not an issue because, short of taking a screenshot of itself and doing OCR, no app can get any textual information until the user actually enters it (via typing or tapping on a prediction). (I don't think apps can take selfies but I actually don't know, and that would be a larger issue than just text prediction.)
@other8026 Good find! And that banana guy is way ahead of the curve.
@fid02 You're right that they'd be able to learn your exit node. But they're probably people you trust (because they have your hotspot password) and if they don't go through your VPN, then they could compromise you in other ways (say because they're livestreaming right next to you and have no VPN). It goes both ways and neither side of the VPN is ideal, so an option or at minimum an explanatory text would be valuable. Yes, Github would be the obvious place to post such a request. Unfortunately I'm unable to get a Github account, hence my post here (deep technical rabbit hole but that's the bottom line after mailing support).
@fid02 You're right, so I should probably provide more context: Yes, I could just as well put a VPN on the Owner profile as well. Then it wouldn't matter if Owner and Other were using the same (or different) VPN at the same time. But I don't do this because then it tells the VPN provider that Owner and Other are really the same person (because they're sharing an IP sometimes). I could use different VPNs, but that only indirects the problem one step further (and creates new problems around having to find another competent one, paying for an account, etc.). Having a way to shut down Owner network traffic while Owner is inactive would definitively solve the problem. If that's not gonna happen, then I would advocate for a succinct warning text somewhere in the profile selection menu (but... Github).

fid02

BillHurdle But I don't do this because then it tells the VPN provider that Owner and Other are really the same person (because they're sharing an IP sometimes).

The VPN provider can just as easily simply log your entry IP and tie it to any of the other activities you perform using that VPN service. The VPN provider can log which sites you visit, tie it to your entry IP and the account information you have willingly provided, and do anything it wants with that. Surely you are aware of this? Your description of your concern implies that you do not trust the VPN provider with your data. Then why use it at all? Users of VPN providers are inherently placing trust in the providers' privacy and security practices. If users believe that the providers are collecting up their data, it does not make sense in the slightest to be using their services.

You haven't stated what you are trying to protect against by shutting down network access in the owner profile. I'm struggling to see a reason beyond avoiding revealing your IP to GrapheneOS servers, or preventing the ISP from seeing your connections to GrapheneOS servers. I'd be happy to be provided with further reasons for this, most preferably reasons that make sense within particular, real threat models. I'm happy to be given a chance to reflect upon threat models that do not personally affect me.

BillHurdle

fid02 Likewise I appreciate it when someone kicks the tires on my threat model. Inevitably we're worrying too much about threats with lesser statistically expected lifetime damage and visaversa, so recalibration with other paranoids is generally a good idea.

I think you already know all this but just to be clear...

The threat that VPNs pose isn't generally about malicious operators. It's more about everyone with access to their leakage. (And there are more mundane issues like race conditions around traffic interception when the VPN connection is being established. I've seen it on a variety of operating systems with a variety of providers.) They also serve to identify you: Don't be the only person who connects to country X using VPN service Y, and then walks all over town like that everyday.

Nobody should be using a VPN for any purpose other than (1) hiding their identity from websites (which is potentially arduous because it may require extensive behavioral alteration that goes way beyond browser randomization, e.g. x.com's deanonymization AI) or (2) getting around geoblocks for Netflix and the like. Tor is vastly better (and slower) but it still requires you to think very hard about leakage.

Why do I want to shut down Owner network access when another partition is active (or at least have an option for that)? Well in my case, the problem is like this (or was, until I figured out what was going on and made some adjustments):

When I'm in the office, I have no VPN because the office router has one for me (and I don't need my VPN provider ~~knowing~~ leaking where I work).
When leave the office, I disable all radios and switch to my Home profile, then enable wifi at home. The Home profile has a proper VPN (no router required).
Oops! At home, my Owner (office) partition is still doing network transactions, but with no VPN.

I'm sure I'm not the only one to have totally unappreciated this fact until I stumbled over it. I'm just lucky that it hasn't done me any damage, knock on wood.

But maybe my logic chain is broken somewhere. I appreciate your feedback!

mmmm

BillHurdle Nobody should be using a VPN for any purpose other than

3, and my main reason, not letting my ISP see my browsing habits.