Please excuse any grammatical errors. I used a tool to generate the transcript and haven’t had a chance to read through it yet. ✔️
The other day, someone sent me this video from The Wall Street Journal. It was a good video, so if you have some time, you might enjoy watching it. The video covered a situation that’s occurring where someone will be at a bar. An individual or a group of individuals will either observe or befriend a Target to determine what their pin code is as they enter it into their device. As it’s normal for someone to enter their pin code multiple times while they are out for the evening, they have various chances to figure out what it is.
Once they figure out what the PIN code is, they either swipe the iPhone when the suspect is distracted or they forcefully take it. Now, what happens after that is quick and calculated. The thieves using the PIN code are able to change the victim’s password associated with their Apple ID, thus locking them out of their account and rendering finding my iPhone unusable. Once that step is completed, the thieves start draining any Financial accounts on the user’s device that uses the PIN code to authenticate. In addition, if the victim uses the iCloud keychain chain, the PIN code can also be used to gain access to that which would then allow them access to any accounts stored in there.
The video goes over in more detail, and if anyone you care about uses an iPhone, consider sending them the video to make them aware of the situation so they can be more cautious. I will also link a post below that has some advice for iPhone owners on steps they can take to protect themselves.
In today’s video, I wanted to cover some settings and suggestions you can implement on graphene OS to help with these kinds of attacks. While it’s not the exact same scenario, I do think these are useful options. So, the example scenario is that you have a Google pixel running graphene OS, and either you or you and your friends decided to go out and grab a bite to eat or some drinks at a local bar.
The first suggestion I want to make for this type of scenario is to use biometric authentication, which is a fancy way of saying to use your fingerprint. To access that setting, you can go into Settings > Security > Fingerprint unlock. Enter your passcode and you can then set up a new fingerprint to authenticate with. I know some people don’t like the idea of using biometric authentication, but the main advantage that using your fingerprint has for authentication is that you can’t shoulder surf a fingerprint. Someone can’t observe you and gain access to your fingerprint. So in a social setting where others might see you enter a PIN code on your device, using your fingerprint can avoid this altogether.
Graphene OS also has a quick option to disable the fingerprint reader. So let’s say you’re going through TSA at the airport or a police officer pulls you over, you can press and hold down the power button and then select “Lockdown.” At this point, biometric authentication is disabled and you need to enter your PIN code to access your device. If you aren’t comfortable using biometric authentication, another useful feature is pin scrambling. To access that, go into Settings > Security > Pin scrambling. Go ahead and enable that. What that does is, on your lock screen, the PIN code will be scrambled every time you go to enter it. This means that someone observing you can’t determine your PIN code based on the physical location of your finger on the screen when entering your PIN code. And while it’s not guaranteed that they can’t determine what your PIN code is, it will make it much more difficult and hopefully deter them enough that they pick an easier target.
And while we are on the topic of PIN codes, the longer the PIN code, the better. It’s going to be much more difficult to determine a 10-digit PIN code compared to a four-digit PIN code. My next suggestion is to use a separate user profile with a different PIN code from your main owner profile, specifically for situations where you’re in a public setting with a large amount of individuals around who could watch you enter your PIN code into your device.
To do that, we’re going to go into Settings > System > Multiple users > Enable “Allow multiple users” > Add user > Set a name for your new user profile. For this example, on this restricted user profile, I’m going to leave phone calls and SMS disabled, but as far as apps go, I do think it would be helpful to have NewPipe installed in case I need to look up a video to show someone. Other than that, I won’t install any other apps. The “Install available apps” feature is a convenient feature to install apps on separate user profiles so that you don’t need to install a separate App Store on the other user profile.
Separate user profiles are a great way to keep your sensitive apps like banking apps separate from a profile you’ll be using in a public setting. So now that we have our new user profile created, you can switch to that by either tapping “Switch to” and your profile name or you can swipe down, pull down again, tap the user icon in the bottom right, and then select your new user profile.
So you won’t be able to see it in the screen recording because it stopped recording when I switched, but all I did was go through the initial profile setup and set a different pin code for my main owner profile. So now here we are in the new user profile. If we swipe up, we can see NewPipe was installed, but Signal was not installed. So now at this point, we have a separate user profile created with a different pin code from our main owner profile that we can use in public settings so that in a worst-case scenario, if someone does get our pin code, they won’t have access to our main owner profile with our sensitive data.
I also want to note that every user profile has separate settings, so you will need to enable pin scrambling on this new user profile we just created. The last setting I want to talk about is auto reboot, and this setting is only accessible from the main owner profile. So make sure you switch back to that user profile. To access that, go into Settings > Security > Auto reboot. I like the 12 hours option. What this setting does is it will reboot the phone if there hasn’t been any successful unlock within the timeframe selected. This puts the device fully at rest in a pre-first unlock state, which is the most secure state for your data.
The reason this is useful for us is if we’re logged into that separate user profile, worst-case scenario someone finds out our pin code, they swipe our device, they now have access to that restricted user profile. Once there is no successful authentication within 12 hours, the device will reboot itself. And now at that point, they need to enter the main owner pin code, which is required to unlock any separate user profiles. The entire device is now inaccessible to them since they don’t know the main owner PIN code, and therefore they cannot access that separate user profile we created. For all intents and purposes, your device is a brick to them.
Probably the best protection, at least in the United States, is the fact that you are using an Android device. Most thieves target Apple devices because they have a great resale value and just how connected they are to everything else on the device. So an Android device being less premium is a solid defense.
Those are the ideas that I came up with. If you have any other suggestions, feel free to leave those down below in the comments. And if you enjoyed this video, I think you’ll like the top one shown here, and the bottom one has been selected for you based on your viewing habits.
]]>Please excuse any grammatical errors. I used a tool to generate the transcript and haven’t had a chance to read through it yet. ✔️
FUD stands for “fear, uncertainty, and doubt.” It’s a popular term used a lot in the privacy community, and leads me to a topic I’ve been wanting to talk about: best practices when researching and analyzing information on the internet. I will be referencing an article written by a security researcher about Apple. I am not making this video to defend or shill Apple, but because I believe that real conversations about privacy and security should be based on facts, not lazily written articles attempting to lead readers down a path the author wants.
The article was published on January 15th, 2023 and has a very intriguing title. However, my skepticism kicked in and I looked into it some more. A lot of information is out there and, sadly, catchy headlines are the ones that get shared first without much validation.
So, let me take you through my process when evaluating an article, especially one that I am considering sharing with an audience. When I first get to the page, I see the title. In the sidebar, I quickly read about the author, who is a hacker and security researcher living in Berlin. After reading that, I think that the information should be technical with a lot of detail. However, the title, “Apple has begun scanning your local image files without consent,” is a very strong claim to make, and I would expect something equally strong in the writing to back that up.
The author starts off with a preface, explaining that they don’t use iCloud, Apple ID, Mac App Store, or store photos in the Mac OS Photos application. They use Mac OS software on Apple hardware.
The author then describes using a program called Little Snitch, which alerts them to network traffic attempted by the programs they use, and that they have all network access denied for many Apple OS level apps. They then start browsing some HEIC files in a subfolder of their documents and Little Snitch tells them that Mac OS is now connecting to Apple APIs via a program named “media analysis daemon,” a background process for analyzing media files.
Instead of reading more detailed technical analysis and information, the author just starts to talk about Apple’s client-side scanning for CSAM in 2021, and how they retracted it because of a public backlash. The author talks about the need to read Apple’s statements carefully and how they are very good at writing technically truthful things that say one thing, but cause reporters to report a different thing.
The article concludes by reminding readers that if they have nothing to hide, they’ve done nothing wrong, and it’s most important to limit information in those times.
So, to put this in perspective, the first few paragraphs gave the preface and some background on what the author found. Everything else talked about Apple’s CSAM scanning, how they’re bad, and the government. When I read an article and someone gives me one or two paragraphs with technical detail and then the following 10 paragraphs are about an event they want me to remember, that’s a little suspicious and I feel like I’m being led down a path to correlate events without the author actually saying that.
So, after reading that, I had some hesitation about actually trusting what I read in this article or about what the author found. So, the next thing I like to do in that case is to actually search for the title of the article and see what else shows up. See if anyone on the Internet is talking about it. Typically, if it’s a newly published article, I’ll search for it on Google because they usually index first before other search engines. So, in this case, we’ll search for the title, and we can see here I actually clicked it in the past. But one of the first results is for Hacker News.
This is a forum where information can be posted and shared, and people can comment on it. And we can see here, the article is posted 25 days ago. This is the site we were on reading it. Sneaked up Berlin. You might notice it was published by sneak, and if we go to this website, we can see most of the handles the author has are sneak. We don’t see the Hacker News one listed here, but if we go to the home page of the website, they list that their Hacker News handle is at sneak. So, we can confirm that the author is the one that posted this on Hacker News. We can also see the article was flagged, and if you start reading through the comments, we can start to see pretty quickly that other people had similar doubts. It talks about the domain that showed up in the author’s image smoot.apple.com is used for spotlight. This article is rightly flagged as BS. This guy found something a little snitch and suddenly exposing some dark company secret in the story.
I understand these are just some strangers on the Internet, but they’re already confirming some of these suspicions I had about this article, and we know that sneak is the username for the author. So, if we search for sneak on the page, we can start to see some comments from the author. “If I made any false claims in the article, please let me know ASAP so I can correct them. I was very careful to report facts only and let the readers draw their own conclusions about what is happening here.” You didn’t report any false claims, you reported a bunch of unrelated claims without any technical research, and then pointed your readers to a conclusion that lacked any technical or journalistic merit.
It’s shallow alarmism, and I want to be clear that I understand people might publish information that’s inaccurate. But if someone goes back then and edits their information or adds something at the bottom saying “you know, after further research this was determined,” but what you find from reading this is that the author chose to die in this hill. I didn’t make that claim because I have not reverse engineered media analysis D to know precisely what it’s doing. And this, I think, sums it up right here. We have a lazily written article where the author found something that they knew would get clicks.
So, nothing that we found is concrete proof of what’s going on, but my trust with him is lacking because instead of adding corrections or addendums to his article, he chose to publicly defend it and continually say that he did not make those claims, even though he employed the same practice that he bashed Apple for, which is Apple is very good at writing technically truthful things that say one thing, that caused reporters to report a different thing.
Now, to contrast the article that was posted by Jeffrey, a miss-put thread on Twitter countered what was actually claimed in that article: no, Mac OS doesn’t send info about your local photos to Apple. We analyzed media analysis D after an extraordinary claim by Jeffrey Paul that it scans local photos and secretly sends the results to an Apple server. They did a thorough analysis of what was claimed by the author to analyze the process, the network traffic. They did all the work that Jeffrey did not do or chose not to do. The unfortunate part is that it’s likely these tweets with actual technical data to back them up did not get the same attention the original article did. They posted an update that this was indeed a bug and was fixed in Mac OS 13.2. This process no longer makes calls to Apple servers.
So, that’s what I do when I find an article that I think is too good to be true, especially if I’m considering making a video on the topic. I do want to touch on one last point on why I think publishing this type of information and letting readers draw their own conclusion is irresponsible. This article had a clear conclusion they wanted the readers to come to, and that’s exactly what happened. Two other popular YouTubers, with audiences much larger than myself, Mental Outlaw and Louis Rossman, both published videos on the topic. In defense of Lewis, he did publish an updated video correcting what he said in this one. If you produce content for a large audience, at least spend a few minutes fact-checking the articles you’re talking about. At the end of the day, people are out there trying to make the best educated and informed decisions that they can. Content and blog posts like this are not helpful and they do more harm than good.
I absolutely agree these companies are doing things that are not good for user privacy, but if we’re going to have discussions like this, they should be based on accurate technical details, not conspiratorial narratives based on fear, uncertainty, and doubt that get clicks and shares. So, if you liked this video and made it this far listening to me talk, I think you’ll like this top video, and the algorithm thinks you’ll like the bottom one.
]]>