Unintentionally helping others steal your biometric data

The pieces of the puzzle

1. Let's start by stating the obvious: people do upload a lot of videos and images to social media showing their family vacations, new dance movies, and, yes, twerking. These files are publicly available and can be easily gathered. Do you remember the old warning about being very careful about what you share on the internet? The security and privacy concerns were about showing where you live, who are your family members, and when you will be out of your house. Thanks to advancements in AI we can add a new reason to slow down posting so much about ourselves.
2. Biometric-based authentication is the process of authenticating people based on something you are, i.e. an unique pyshical feature -- fingerprint, iris, or retina to name a few -- instead of something you know (password) or have (token). Some of the applications are multifactor authentication and face recognition, which are used to unlock smart phones and identify people in a crowd.
3. Deepfake is an evolution of the tradition of inserting (or removing) people in pictures and videos using cropping and blue screens. Benign results have been seen in movies like Zelig and Forrest Gump; George Orwell' 1984 talks about using that for malign purpose, namely rewrite history. The difference is that thanks to AI, deepfake is automated to the point it runs in real time. The classical example of the potential of this technology is a Tom Cruise deepfake video created by Belgian visual effects artist Chris Ume:

   It did not take long for malicious individuals to apply deepfake to create celebrity porn videos, fake news, hoaxes, and financial fraud. What about the average people? They are not famous politician, singer, or athlete; can they shrug it off saying "this does not affect me; I am too small of a target for them to have an interest on" like they have done many times before, or should they be worried? The reality is that

   • Attackers are always looking for opportunities, and will strike at the low hanging fruit.
   • The cost of the resources required to deepfake has dropped a lot in the last few years.

Let's have some fun

How can we combine that? In 2007 (yes, time flies), Microsoft identified the following as the most popular types of biometric authentication devices of the time:

• Fingerprint scanners
• Facial pattern recognition devices
• Hand geometry recognition devices
• Iris scan identification devices
• Retinal scan identification devices

Nowadays we can do all of that using just a camera. Let's consider a few applications that are possible today:

• Videos and pictures collected from your social media provide enough info about your face to unlock your phone.
• Inserting you in the CCTV records of a riot is just a matter of being able to access said records and change them. Only limiting factor here is bypassing tampering detection, which is not as common as you are led to believe. Yes, we are not at the Ghost In The Shell level, where video streams were being tampered in real time at the camera level, but there is enough knowledge to make some damage right now.
• Back to those high quality videos found in social media, they are (not may be) good enough to collect your fingeprints or ear shape. The later has been successfully used to identify people in riots while wearing masks.
• Saving the best for last, imagine someone using deepfake, after collecting your videos for images and voice samples, to have a webconference with your children's school or doctor. I will leave to your imagination to ponder on the consequences of that. Before you say anything, the Tom Cruise video I mentioned early is now old from Moore's Law's point of view.

We could go over an example of how to do that, but that is not the point of this article. If you thought your identity and, as a result, your privacy was at risk, I think we reached a whole new level.

What can be done to minimize exposing biometric data?

Think before posting! This rule has not changed. There are some who argue that millenials and Gen Z crowd are the biggest offenders, but this is just a matter of training. If you have to post, be mindful of what is being exposed. Or, cut down the quality of the pictures a bit so the bad guys do not have a nice clean image to start with. For the images and videos you already posted, once it is out in the internet, there is no coming back.

Make protecting your privacy a priority in your life. If people are going to steal your data, make them work for it.

Further reading

Trendmicro published a great paper on the risks of exposed biometric data.

Optus and how to DevOps badly in a few easy steps

Full disclosure: I put Optus on the title because those LinkedIn articles avocate the need for clickbait to attact viewers. Problem is I am actually going to talk about this company. But, this article is really about code development gone bad; Optus just happens to be the perfect example of, in the words of Jeremy Clarkson, what could possibly go wrong.

We are Agile!

In earlier, simpler times, the recommended software development lifecycle model (SDLC for you acronym addicts) was the Waterfall Model. There are many places which describe it better than I could ever do, so suffice to say that it is linear and starts with the idea, then goes to the design, and then a few steps including coding and testing until it is deployed and goes to the maintenance mode. In other words, you start with an idea and then ends up with a product.

Making the code secure, or implementing (Buzzword time!) privacy by design was fairly easy if the security and privacy team was involved fromt he get going, as that was just another well-defined step.

But, what if the product needs to be changed? As in not just a patch but feature request or something that requires a new library or user interface redesign. You need to go back to the start.

You can say it is a bit rigid, and many people agreed with you. Next step was modifying the model so you could hop back one step or two, and that started to get messy. The bottom line is it does not take changes well. In many fields that is completly fine. However, for code which is always changing and put into production as soon as changes are done, like in a website, it can slow down delivering a working product. In some industries, who puts it out first, even if it is not perfect, wins. So, we need something better.

We evolved into the Agile model, which. as a friend taught me, is also called the "Never Finished Model." What the joke implies is that this model is designed to handle changes quickly and deliver a working product even if it is not perfect. The reason is that you can improve on it later once you have some feedback from customers.

The following picture shows a typical Continuous Integration/Continuous Deployment (CI/CD) pipeline, which is a trademark of using the Agile model in code development. How do we account for security and privacy here? DevSecOps places security controls in the CI/CD process of DevOps. Note the two red boxes: they are the points where we add security testing to the cycle. one is for the Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). The red arrows indicate that funny business they find is then send to something which then logs and reports them by creating tickets or sending emails or something else. This is of course, ideally supposed to be done in conjunction with training developers in secure coding, (Buzzword Alert!) pivacy by design, and whatnot.

In reality, some companies/developers which should know better decide that slows them down and hampers their style. In other words, they nee to be putting new code out with new features, and privacy and security are not features but

Enter the Optus

Singtel Optus Pty Limited, a.k.a. Optus is the second largest wireless carrier in Australia. In the last week of September 2022, Optus reported that on 22 September 2022 it was victim of a very sophisticated cyberattack by members of a criminal or state-sponsored organization. This attack resulted in a major personal data breach, where the names, dates of birth, phone numbers, email addresses, street addresses, drivers licences, and passport numbers of both current and former customers was leaked. Optus chief executive Kelly Bayer Rosmarin said that they "are not aware of customers having suffered any harm."

Insert here the videos of a guy in a hoodie in a dark room and computer screens showing random Linux output.

What does this very sophisticated cyberattack have to do with coding?

Glad you asked.

You see, later on it was found Optus had an unauthenticated API, http://api.www.optus.com.au, that released all of the personal data it stored, not only of current but also previous customers (there is the case of someone who has not been an Opus customer for the last 14 years and not only received an email from them about the breach but also started to be flooded with spam). We are talking about data from 10 million people. Unencrypted.

Optus detected the event when the attacker started hitting the AIP hard.

So, the questions are

1. Why did it have an exposed API without some kind of authentication? Perhaps that was originally done to allow testing of the API more convenient by developers. I myself have seen that in the wild. When developers/DevOps from the environment in question were asked to at least limit access to a network only reacheable from behind their firewall, they shrugged it off saying the VPN (which is not a solution but sure is an improvement) was too cumbersome to use from their personal laptops.
2. Why was the connection to said exposed API unencrypted? Do you remember when we said that DevSecOps places security controls in the CI/CD process? That probably would have caught that: the SAST would have noticed the unencrypted connections in the code; the ones I have used before would bark at unencrypted traffic (and hardcoded passwords, which was not the case here since no passwords were used). In the real world that does not happen as much as people believe. In fact, it is too common to hear that devsecops slows down the of devops' work.
3. Why was the personal data stored unencrypted? Once again, convenience. Maybe when that was recommended, it was then turned down because developers argued it would slow the response time of the system. Once again, SAST would have caught that.

Clearly there were poor security practices at play here. Perhaps DevOps security and privacy training never happened, or SAST/DAST was never implemented in the SDLC chain. Usually that happens because they are considered cost centers in business that, as mentioned earlier, slow down progress. Remember we mentioned that automated security testing will create tickets developers will have to deal with in addition to the other tickets they already have on their plates.

Post Morten

Don't be that guy!

• Privacy by design would not have allowed this kind of code to even make into the repo.
• Encrypt the traffic to the API, period. Ideally that should be done at the API level. I know some people will put a Nginx proxy in front of the unencrypted API (using kubernetes or docker), and I cringe about that: it is an improvement from the Optus setup but not by much.
• Encrypt your data at rest. Yes, that is specially important for personal data, but it is a good habit regardless.
• All connections to an API should be authenticated by default. If you have a query, say list status, you want to make available unauthorized to users, spend some serious time thinking on the consequences.
• Ensure your CI/CD process has proper security controls. If DevOps is being swamped with the tickets generated by these controls, this may either mean they need more security and private training, or the controls need better tuning, or the external code/libraries you rely on are not as well written as they should. That is how BadUSB and many of the IoT issues came into being.

Phishing Is Too Easy - 3

Last week I received another traditional phishing email; apologies for the lack of images because my email account is setup not to load externally attached pictures. Here it is, with my address removed:

Yes, this is pretty much a variation of the last one I commented on months ago, namely:

• It is an invoice for some product, in this case it implies to be some kind of Norton product.
• It creates a veil of credibility by alluding itself (blue box) in a rather half-ass way to be related a real company. Note it claims to be "Norton Support LLC," which I have no idea who it may be. Since the average person probably heard of Norton, who sells an antivirus and other security products, it is easy for said person to associate both.
• Still on the credibility standpoint, the sender address is supposedly from quickbooks (I did not bother to check the header). Yes, a large company right Norton would not be using quickbooks to send its bills. However, if you have to deal with purchasing you probably have seen invoices from smaller business which use the online quickbooks site; when they send their invoices, their invoices will have "<quickbooks@notification.intuit.com>" as the email. But, we hope they will look more like "Something Of Doom LLC <quickbooks@notification.intuit.com>" instead of "Intuit E-Commerce Service <quickbooks@notification.intuit.com>"; I think the later is not the default value, but it sounds credible enough.
• To create the urgency, the invoice is for $800. That will make someone's heart beat a bit faster and immediately want to open the attached PDF file (red box) to find what this invoice is all about. This is a bit lazier than the last phishing email we posted about as some mail services will disable attachments with macros in hope to block malicious payloads. However, most of the mail services do not do that; mine could not be bothered and told me if I want to see it, and be properly infected, I need to have Adobe Acrobat Reader (green box). Since my mail service does not automagically open anything, I have some extra time to read the email and decide what I want to do next.
• It provides a number which may be tied to the phisher (VoIP?) so if the frantic recipient of the email calls, the phisher (we called him Peggy in the last phishing post) can then social engineer his way into the victim's computer.
• The return address is a typical quasi-randomly created Gmail one; they could not be bothered with making it sound like it came from a billing department as it claims to be.

How effective it is? I think it depends on where people will focus on. The phishers hope their marks will see the value of the invoice -- $800 -- and immediately open the pdf to find out what is going on. The best thing to do here is stop -- but not stop/drop/roll as you are not on fire -- whenever you see something suspicious, specially when it claims to be urgent. Then ask yourself if you expected an invoice from Norton. Then look at the email addresses and see if they are not overly suspicious.

Remember: phishers are lazy, and they hope you are equally lazy!

There and back again: DEFCON 30

No, I did not postpone posting about my trip to DEFCON30 until now because I did not have anything to post this month. The truth is I was slacking. There, I said it.

This will be a bit of a post morten of our workshop. Will this post have any useful info? Don't hold your breath; what I can promise is there will be many opportunities to laugh at our expense.

The Plan

For those who read the announcement for our workshop at the Crypto and Privacy Village, you know that there are two authors -- Matt and yours truly -- who put together the mess without killing each other; the fact we had half a continent between us probably helped.

Originally, the plan was to start with an explanation of why this phone privacy thing was so important and then get show how to do it. Ideally people would have read the announcement, followed our instructions, and show up with a phone ready to be configured. While one of us would be on the podium, the other would then be helping the audience.

After we had the entire workshop done and did a few dry runs, we started thinking: how many people will bring a phone that meets the requirements? Probably not many -- not many people have spare phones that can take CalyxOS or LineageOS in their kitchen drawer -- and we will not be able to bring enough loaners as all the resources in the workshop are coming out of our own pockets. We could just shrug it off and tell people "Hey you did not bring a phone, so we will bore you with screenshots."

Thing is, we had taken a lot of screenshots of everything we would be showing in the phone, in case we would not be able to share the phone screen or point a camera at it. So, this was an option but we felt that would detract from the workshop; instead of being something interactive it would be no better than watching a video.

We needed a plan B.

What if we provided an emulator? It will not do everything a real phone can but it will allow the audience to follow along on their laptops. Since we were going to focus on CalyxOS (we had only an hour to run the entire workshop; compromises had to be made), we then decided to create that image, make it available somewhere, and then update the wiki with instructions on how to use it. We also asked the Crypto and Privacy Village (CPV) people to add a single line in the workshop announcement, indicated with a green line in the picture below, to tell people they should install Android Studio in their laptop.

The plan was to have everything finished two weeks before the event and then take the last week to practice, and ensure we had a reliable way to hand out the emulator images.

Things did not happen according to the plan.

Matt was able to go to DEFCON from the beginning of the event; I do not know if he also was able to stop by BSidesLV. I, on the other hand, was a bit more time constrained: I flew the first flight on Friday and was going to return on Saturday after the workshop. In any case, we were going to try to attend as many events and talks as possible, and meet up with people we have not seen in ages. I also planned on volunteer to the CPV.

What really happened?

1. Building the CalyxOS phone image was not as smooth as we hope for. In plain English, I could not make it work. I had no issues building LineageOS ones in my docker build environment -- if someone reminds me I can post instructions on how to do that later -- but CalyxOS was fighting me all the way. Fortunately we were working in parallel and Matt was able to make it work.

   I will let Matt post how to create the CalyxOS image with all the apps already installed in his blog, as he is the one that made it work. In fact, it worked so well, he used that instead of a real phone during the hands-on part of the workshop.

2. We spent too much time trying to come up with a clever way to deploy the phone image. After days of frustration we came up with a simpler way to do that, wrote the docs that worked whether you had a Linux, Mac, or Windows laptop, and put it with the image.
3. The emulator stopped working. I do not know why but it went on strike. More frustration ensued. Was it the emulator itself or the image? Once again Matt rose to the occasion and made it work.
4. We also found out it would take too long to download the image we built using the DEFCON public network. Fortunately we had a bunch of USB drives and decided to put in each, formatted in some Windows file system so all 3 OS could mount them, the image and instructions.

There are probably more things that went wrong, but I cannot think of them right now. Bottom line is we spent most of the time that week working on these bugs. And, we made it work.

Showtime

The CPV people did a great job. Everything was working smoothly on their side. I did most of the overview and then Matt took over for the technical part:

You will note on the above picture the audience (picture was taken from the back out of respect) has set some chairs apart for social distancing's sake. I then came back from the podium sporting one of my favourite shirts (bonus points if you recognize it) with the final comments and we then took questions. After it ended, Matt was surrounded on the podium with members of the audience for a long while until the Defcon Goons kicked us out.

Thank you for all the fish

• Avi Zajac and the rest of the Crypto and Privacy Village crew for not only having us there but making the event possible. And the badge. And the shirt (I am afraid of wearing it out because it is nice). And keeping the Goons at bay. And the sticker!
• The NCC Group for mentioning us in its August announcement.
• DEFCON for, well, being defcon. I do with I had more time to see it all this year instead of being in a hotel room trying to get all working. But, it was all worth in the end.
• CalyxOS for trying to make a more secure and private Android distro easier to install. There is more around this line item, but I am getting ahead of myself.

Good Cookies, Bad Cookies, and Privacy

Cookies "banners" are a particular pet peeve of me. As in don't get me started or I will be on it for hours if not days on end. So, I will struggle a bit to get this short enough so not to kill any reader of boredom. I am not claiming I will accomplish this goal, so you have been warned.

I should also warn this article has been in the making for months; I collected a lot of real samples I need to cover the names of the companies to protect the guilty. If you recognize the site by looking at the cookie policy form, smirk and keep it to yourself.

So, are cookies bad?

That is an oversimplified question. Cookies are used to track what users are doing in a website, and that may mean storing some personal data no t only of site users but also visitors. Some of which have very valid and important applications, like ensuring users can authenticate and are the right people to access a given resource, like their bank accounts, or repository of cat videos. Then we have the ones companies are interested on, such as:

• Which pages users go to in a given website, links they have clicked, and how long they spent on a given page. That may help them figure out which content -- primarily cat videos -- their audience seek and which ones they are avoiding. Or find out whether a given page is too convoluted, causing visitors to spend too much time and frustration in them. I can see why anyone wants to provide a website that does not suck.
• How often they visit a website whose cookie is in their computers.
• Which products or keywords they search for. This may tell the product lines the websites need to be providing and which ones may be taken down.
• Geolocation and IP address. A business case is to know where its customers are coming from so they can identify markets they are not covering, and then find out why.
• Username/password, and even address. Do not ask me why someone thought it was a clever idea to have them in cookies so forms would be conveniently filled, but they are there in the wild.

None of these are really needed to provide a service to users, so GDPR would say you must ask the visitors if they give you consent (Articles 6, 7, and Recital 32) to collect said data, and provide a way for them to remove their consent. CCPA and CPRA are less restrictive, having a set of thresholds (selling personal information of more than 50,000 Californian households, or making more than half of its annual revenue selling that data) before they are applicable and providing a the get-out-of-jail-free card (Art.9(2),e).

Some of these cookies are collected by the company running the website (first-party cookies) and others by whatever add-on they have deplopyed (third-party cookies). Google Analytics is an example of an app that creates the later; we have talked about how nicely it plays with GDPR before. However, that does not necessarily make first-party cookies better for security; but that is the topic of another article.

From a security standpoint, criminals will try to steal -- phishing emails are a popular way to deploy malware to achieve the goal -- cookies to impersonate users. So, a sensible business minimizes how much data it stores in its cookies.

The Good

• Let's start with a nice bright example of someone who respects the privacy of its website visitors.
  
  It is written in plain language, gives a quick blurb on what it is being used for, and allows the user the choice to accept all the cookies, deny all of them, or do something in between (which leads to a more itemized list you can enable item by item).
• The next one, from one of the European Union's official websites, is not as nice but at least they are trying.
  
  Why am I not impressed with their banner? Because it is an all-or-nothing, without a proper explanation, and mentions these "essential cookies" (is this like "essential oils?") without explaining them. Yes, if you click the link explaining how they use the cookies you realize they are not out to suck you dry of your private info, which is why it is listed here. But, I think they could do a better job given the resources they have.

The Bad

This list is but a tiny sample of my fun collection. Still, get the popcorn.

• First we will start with one that is on the slippery slope as far as GDPR is concerned. It mentions collected data with "trusted third parties." Who are they? Google Analytics? We have talked before that you can no longer use it on a site that is accessed by European residents.
  
• We really should just get serious and look at an example of conning the user. For convenience, I highlighted the relevant wording in their privacy note.
  
  First we have "This information might be about you" (red), which uses the "might" word to imply that it is ok because maybe the information is really not about you. Well, knowing your IP (considered by GDPR personal data), OS, browser, and other facts that we will not go over here (username?) suffice to uniquely identify you. If you use the same computer without bothering to run VPN later, they will know you are back... specially if from home as your external/public IP rarely changes if at all. But then they smother your worries claiming that "the information does not usually directly identify you" (blue). It is personal data already, sunshine.
• Here is one from a bank that prides itself to have branches in many countries across the world.
  
  At first I thought the following cookie banner was just for the American market, but when connecting from Japan and Europe I still was "welcomed" by the very same banner; I do not need to say what that means. I have a ton of other examples following the same pattern, but I think we only need one to get the idea.
• This one is a variation of the bank banner we saw earlier seen in the website of a professional society. I would not have posted it if it did not have one single word: consent.
  

  I must assume the reason this specific term was used is because of the language in GDPR, specifically article 7 states that if you do not have a legal reason to collect personal data, you must obtain consent from the user, who must freely give it. They seem to beleive that by having the word "consent" in the banner, they satisfied this GDPR article. However, if the only option is to surrender your private data, this consent is not freely given. Or can be easily revoked.

  "But," one can argue, "you did not consider they are probably an American-based society which does not cross the CCPA requirements by keeping the number of Californian households under the limit." How would that work? Geolocating may be hard: one of the VPN services I use has servers in California; there might be other services with servers somewhere else in the US being used by Californian citizens. Given the banner you are seeing, how would you distiguish the two cases? And besides, if this is an international (they hope they are, as one of the letters in their name stands for that) professional society, GDPR, LGDP, and APPI just to name a few are bound to be triggered. I did my Westen Europe test, and it did not switch to a GDPR-compliant cookie banner.

The Sleazy

Now we get to the really special ones, the ones that decided laughing at the privacy rights of individuals was not enough; they had to make a point.

• First jewel is what I call a BannerWall: you cannot use the website until you click on the only option ("Accept"), so site owners can then say "here! User consented to use collecting all personal info. We have the log showing the Accept button was clicked!" Hopefully you do not need to use this site, so you can just close your browser and find some other place with similar information but more privacy conscious.
  
  Looking at the screen capture, do you know if "Privacy Policy" and "Terms of Service" are links? No? You are not alone. Can you say hiding in plain sight?
• But, what if you have to use the website? For instance, what if you need to log into the site to pay your utilities or rent, and they do not offer another way (mail or in person) to make said payment? Can you say coercion?
  

Don't Be That Guy

• Instead of having you site collect personal data based on the location of the site visitor, assume they are all coming from the EU and build it for that, as it is one of the more restrictive ones. Make your life easier, be your website a commercial or educational/research one; we covered that a while ago.
• What is wrong with asking users if it is ok to collect their data and tell them how you are going to use it without vague words? And by that, ask properly, not like the no-real-option seen in some of the examples above.
• Document everything, logs included, because the world is changing and you may be audited or even fined for non-compliance. Remember, you do not need to have suffered a personal data breach before a GDPR Data Protection Authority takes legal action against you. Don't believe me? We commented on some cases earlier this year. All is needed to get that avalance running is for someone to file a complaint.

Measuring company reputation

One of the bullet buttons in the (ISC)2 Security Domain 1 (security and risk management) is risk analysis (yes, you with the beard on the back row, that would be under NIST 800-53r5 Security Domain 14). There are many ways to define it but I will be lazy and steal the defition of it from NIST 800-160 because it is short and to the point:

Risk Analysis is the process to comprehend the nature of risk and to determine the level of risk.

We can subdivide this analysis into two groups based on the criteria we use in the decision process: quantitative and qualitative analysis. Without going over the details, the bottom line is a lot of people ignore qualitative analysis because it does not directly tie into money: how can you ask for fundings to executives if you cannot provide a proper cost-benefit analysis? For instance, if you are asked to measure and tie to the yearly budget, say, your company reputation (a topic picked out of blue which has absolutely nothing to do with the title of this article), what would you do? After all, this is the typical topic qualitative risk analysis is built for.

The answer is we can quatify it if we look at it in a non-direct way. If you think about it, company reputation can be "itemized" by the things that affect it:

• Your cyber insurance, which is affected by how the insurers think you are about protecting your assets. So you can say "since we have not been breached in X years and we have great security policy which is enforced and audited, our insurance is lower than from our competitors." Can you see how close this narrative now is to that associated with the Annualized Loss Expectancy (ALE)? You may be able to ask the insurers to explain how a recent loss of personal data will affect the premium. There is no guarantees they will talk, but there is a compelling argument to work together to decrease their risk.
• Customer confidence, which is affected by how many data breaches you had, how you handled them, and how you deal with the customer's data. This can be estimated by investigating the decrease of sales of other companies due to loss of personal data including credit card info. People vote with their wallets, and their letters to elected officials.
• Your suppliers confidence on you, which leads to whether they will provide you with discounts, less interest, and longer times to pay your orders. If they do not trust you, they may say any bill is due on receipt. That affects cashflow in a very definite way.

Each of these in the end of the day affects the bottom line ($), which is what matters to upper management.

Phone Privacy at DEFCON 30!

So our workshop on smart (I will keep a straight face here, just saying) phone privacy was accepted by the Crypto and Privacy village at DEFCON 30. If you are there, we will be presenting it on Saturday Aug 13th. As it will be only one hour, we strongly recommend to first to folow the instructions in the co-author's github-based wiki; this link is also in the official DEFCON accouncement, but it is so important we would rather mention it a few times.

So, what is it all about?

Short version: how to make your smart phone more private and why you should care. I could elaborate on that, but this post is not about the contents of the workshop: go watch it and find out!

Anything useful you want to tell us?

People have told me I have some kind of fixation with bullet points; let's not disappoint them, shall we?

• No pictures will be taken with my phone; I will be bringing a camera -- ancient but trusty Canon ELF -- to take some pictures of the event. Yes, compared to modern smart phones its resolution is pathetic. But, it has a real zoom, using real lenses, has no understanding of wireless file transfer (great during DEFCON), and does not keep you up at night when vendor stopped creating patches for it. As this will be a real camera, not smart phone, they will not be posted in real time.
• I was comparing our abstract with the other presenters' and realized ours is gigantic by comparison! This is not a size competition, and I realized it may e nd up being a bit of a turnoff. But, there is some logic behind the madness: we really wanted to make sure people knew what to expect and that they need to prep are for the workshop. Which leads to...
• The "talk" part of this workshop will be rather short because the main dish is the hands-on part.
• If you to get your hands dirty, bring an Android phone. It's two main requirements are
  • A phone you are fine if it is bricked. That can happen. And, you can find out if it does brick before attending the event because we put the setup instructions in the wiki.
  • Ideally, you want to have a phone such as Google Pixel (3 and above), OnePlus, or Fairphone. Main reason is because a lot of Android phones have a closed source "blob" of code that is only updated for a brief period of time (a year? A week?), until not longer after replacement hit the shelves. However, we are not saying "for best experience you should have bought the latest $1000 phone" (bonus point if you know where I took that from). We do think everyone should be able to strive for a private focused phone (sounds like a tag line for a product, eh?). In fact, we will have a Pixel 4 to show things, but a Pixel 3 will work just fine and can be found for around $50 if you look hard enough. When I checked this morning, an used Pixel 4 was hoving around $100.
  • FYI, I have issues with the Google Pixel phones, primarily how hard it is to repair it.
• I would love if we could make the phone fully private from a GDPR (we tend to mention it a lot in this blog?) standpoint, but that won't happen. Compounding that, some countries do not take your efforts to protect your privacy in your phone very kindly.
• I really would like to thank the Crypto and Privacy village for having us. This may sound the typical fake message you associate with Facebook and LinkedIn, but for a change it is real. One of the hints is that I am not starting this thread with "I am excited that;" the truth is that we have been working hard and long hours on this and the CPV crowd have put up with all of our stupid questions and rewrites and whatnots. And have not tried to strangle us!

Dude, I have an iPhone! What should I do?

Dude, I have no clue; I do not have an iPhone to research on!