It's that time again, when families and friends gather and implore the more technically inclined among them to troubleshoot problems they're having behind the device screens all around them. One of the most vexing and most common problems is logging into accounts in a way that's both secure and reliable.

Using the same password everywhere is easy, but in an age of mass data breaches and precision-orchestrated phishing attacks, it's also highly unadvisable. Then again, creating hundreds of unique passwords, storing them securely, and keeping them out of the hands of phishers and database hackers is hard enough for experts, let alone Uncle Charlie, who got his first smartphone only a few years ago. No wonder this problem never goes away.

Passkeys—the much-talked-about password alternative to passwords that have been widely available for almost two years—was supposed to fix all that. When I wrote about passkeys two years ago, I was a big believer. I remain convinced that passkeys mount the steepest hurdle yet for phishers, SIM swappers, database plunderers, and other adversaries trying to hijack accounts. How and why is that?

Elegant, yes, but usable?

The FIDO2 specification and the overlapping WebAuthn predecessor that underpin passkeys are nothing short of pure elegance. Unfortunately, as support has become ubiquitous in browsers, operating systems, password managers, and other third-party offerings, the ease and simplicity envisioned have been undone—so much so that they can't be considered usable security, a term I define as a security measure that's as easy, or only incrementally harder, to use as less-secure alternatives.

"There are barriers at each turn that guide you through a developer's idea of how you should use them," William Brown, a software engineer specializing in authentication, wrote in an online interview. "None of them are deal-breaking, but they add up."

Passkeys are now supported on hundreds of sites and roughly a dozen operating systems and browsers. The diverse ecosystem demonstrates the industry-wide support for passkeys, but it has also fostered a jumble of competing workflows, appearances, and capabilities that can vary greatly depending on the particular site, OS, and browser (or browser agents such as native iOS or Android apps). Rather than help users understand the dizzying number of options and choose the right one, each implementation strong-arms the user into choosing the vendor's preferred choice.

The experience of logging into PayPal with a passkey on Windows will be different from logging into the same site on iOS or even logging into it with Edge on Android. And forget about trying to use a passkey to log into PayPal on Firefox. The payment site doesn't support that browser on any OS.

Another example is when I create a passkey for my LinkedIn account on Firefox. Because I use a wide assortment of browsers on platforms, I have chosen to sync the passkey using my 1Password password manager. In theory, that choice allows me to automatically use this passkey anywhere I have access to my 1Password account, something that isn't possible otherwise. But it's not as simple as all that.

When I look at the passkey in LinkedIn settings, it shows as being created for Firefox on Mac OS X 10, even though it works on all the browsers and OSes I'm using.

Screenshot showing passkey is created for Firefox on Mac OS X 10.</p> <p>

Why is LinkedIn indicating otherwise? The answer is that there's no way for LinkedIn to interoperate flexibly with the browsers and OSes and vice versa. Per the FIDO2 and WebAuthn specs, LinkedIn knows only the browser and OS I used when creating the credential. 1Password, meanwhile, has no way to coordinate with LinkedIn to ensure I'm presented with consistent information that will help me keep track of this. Suddenly, using passkeys is more confusing than it needs to be for there to be utility to ordinary users.

Things get more complicated still when I want to log into LinkedIn on Firefox for Android, and am presented with the following dialog box.

Screenshot showing a dialog box with the text: "You're using on-device encryption. Unlock your passwords to sign in."

At this point, I don't know if it's Google or Firefox that's presenting me with this non-intuitive response. I just want to open LinkedIn using the passkey that's being synced by 1Password to all my devices. Somehow, the mysterious entity responsible for this message (it's Google in this case) has hijacked the process in an attempt to convince me to use its platform.

Also, consider the experience on WebAuthn.io, a site that demonstrates how the standard works under different scenarios. When a user wants to enroll a physical security key to log in on macOS, they receive a dialog that steers them toward using a passkey instead and to sync it through iCloud.

Dialog box showing macOS passkeys message.

The user just wants to enroll a security key in the form of a USB dongle or smartphone and can be used when logging in on any device. But instead, macOS preempts this task with directions for creating a passkey that will be synced through iCloud. What's the user to do? Maybe click on the "other options" in small text at the very bottom? Let's try and see.

The dialog box that appears after clicking "other options."

Wait, why is it still offering the option for the passkey to be synced in iCloud, and how does that qualify as "other options"? And why is the most prominent suggestion that the user "continue with Touch ID"? It isn't until selectng "security key" that the user will see that option they wanted all along—to store the credential on a security key. Only after this step—now three clicks in—does the light on a USB security key begin blinking, and the key is finally ready to be enrolled.

Dialog box finally allows the creation of a passkey on a security key.

The dueling dialogs in this example are by no means unique to macOS.

Too many cooks in the kitchen

"Most try to funnel you into a vendor's sync passkey option, and don't make it clear how you can use other things," Brown noted. "Chrome, Apple, Windows, all try to force you to use their synced passkeys by default, and you have to click through prompts to use alternatives."

Bruce Davie, another software engineer with expertise in authentication, agreed, writing in an October post that the current implementation of passkeys "seems to have failed the 'make it easy for users' test, which in my view is the whole point of passkeys."

In April, Son Nguyen Kim, the product lead for the free Proton Pass password manager, penned a post titled Big Tech passkey implementations are a trap. In it, he complained that passkey implementations to date lock users into the platform they created the credential on.

“If you use Google Chrome as your browser on a Mac, it uses the Apple Keychain feature to store your passkeys,” he wrote. "This means you can’t sync your passkeys to your Chrome profile on other devices.” In an email last month, Kim said users can now override this option and choose to store their passkeys in Chrome. Even then, however, "passkeys created on Chrome on Mac don’t sync to Chrome in iPhone, so the user can’t use it seamlessly on Chrome on their iPhone."

Other posts reciting similar complaints are here and here.

In short, there are too many cooks in the kitchen, and each one thinks they know the proper way to make pie.

I have put these and other criticisms to the test over the past four months. I have used them on a true heterogeneous environment that includes a MacBook Air, a Lenovo X1 ThinkPad, an iPhone, and a Pixel running Firefox, Chrome, Edge, Safari, and on the phones, a large number of apps, including those for LinkedIn, PayPal, eBay, Kayak, Gmail, Amazon, and Uber. My objective has been to understand how well passkey-based authentication works over the long term, particularly for cross-platform users.

I fully agree that syncing across different platforms is much harder than it should be. So is the messaging provided during the passkey enrollment phase. The dialogs users see are dictated arbitrarily by whatever OS or browser has control at the moment. There's no way for previously made configuration choices to be communicated to tailor dialog boxes and workflow.

Another shortcoming: There's no programming interface for Apple, Google, and Microsoft platforms to directly pass credentials from one to the other. The FIDO2 standard has devised a clever method in an attempt to bridge this gap. It typically involves joining two devices over a secure BLE connection and using a QR code so the already-authenticated device can vouch for the trustworthiness of the other. This process is easy for some people in some cases, but it can quickly become quirky and prone to failure, particularly when fussy devices can't connect over BLE.

In many cases, however, critics overstate the severity of these sorts of problems. These are definitely things that unnecessarily confuse and complicate the use of passkeys. But often, they're one-time events that can be overcome by creating multiple passkeys and bootstrapping them for each device. From then on, these unphishable, unstealable credentials live on both devices, in much the way some users allow credentials for their Gmail or Apple ID to be stored in two or more browsers or password managers for convenience.

More helpful still is using a cross-platform password manager to store and sync passkeys. I have been using 1Password to do just that for a month with no problems to report. Most other name-brand password managers would likely perform as well. In keeping with the FIDO2 spec, these credentials are end-to-end encrypted.

Halfway house for password managers

With my 1Password account running on my devices, I had no trouble using a passkey to log into any enrolled site on a device running any browser. The flow was fast and intuitive. In most cases, both iOS and Android had no problem passing the key from 1Password to an app for Uber, Amazon, Gmail, or another site. Signing into phone apps is one of the bigger hassles for me. Passkeys made this process much easier, and it did so while also allowing me the added security of MFA.

This reliance on a password manager, however, largely undermines a key value proposition of passkeys, which has been to provide an entirely new paradigm for authenticating ourselves. Using 1Password to sync a password is almost identical to syncing a passkey, so why bother? Worse still, the majority of people still don't use password managers. I'm a big believer in password managers for the security they offer. Making them a condition for using a passkey would be a travesty.

I'm not the first person to voice this criticism. David Heinemeier Hansson said much the same thing in September.

"The problem with passkeys is that they're essentially a halfway house to a password manager, but tied to a specific platform in ways that aren't obvious to a user at all, and liable to easily leave them unable to access ... their accounts," wrote the Danish software engineer and programmer, who created Ruby on Rails and is the CTO of web-based software development firm 37signals. "Much the same way that two-factor authentication can do, but worse, since you're not even aware of it."

He continued:

Let's take a simple example. You have an iPhone and a Windows computer. Chrome on Windows stores your passkeys in Windows Hello, so if you sign up for a service on Windows, and you then want to access it on iPhone, you're going to be stuck (unless you're so forward thinking as to add a second passkey, somehow, from the iPhone will on the Windows computer!). The passkey lives on the wrong device, if you're away from the computer and want to login, and it's not at all obvious to most users how they might fix that.

Even in the best case scenario, where you're using an iPhone and a Mac that are synced with Keychain Access via iCloud, you're still going to be stuck, if you need to access a service on a friend's computer in a pinch. Or if you're not using Keychain Access at all. There are plenty of pitfalls all over the flow. And the solutions, like scanning a QR code with a separate device, are cumbersome and alien to most users.

If you're going to teach someone how to deal with all of this, and all the potential pitfalls that might lock them out of your service, you almost might as well teach them how to use a cross-platform password manager like 1Password.

Undermining security promises

The security benefits of passkeys at the moment are also undermined by an undeniable truth. Of the hundreds of sites supporting passkeys, there isn't one I know of that allows users to ditch their password completely. The password is still mandatory. And with the exception of Google's Advanced Protection Program, I know of no sites that won't allow logins to fall back on passwords, often without any additional factor. Even then, all but Google APP accounts can be accessed using a recovery code.

This fallback on phishable, stealable credentials undoes some of the key selling points of passkeys. As soon as passkey adoption poses a meaningful hurdle in account takeovers, threat actors will devise hacks and social engineering attacks that exploit this shortcoming. Then we're right back where we were before.

Christiaan Brandt, co-chair of the FIDO2 technical working group and an identity and security product manager at Google, said in an online interview that most users aren't ready for true passwordless authentication.

"We have to meet users where they are," he wrote. "When we tested messaging for passkeys, users balked at 'replace your password with passkeys,' but felt much more comfortable with more softened language like "you can now use a passkey to log in to your account too.' Over time, we most definitely plan to wean users off phishable authentication factors, but we anticipate this journey to take multiple years. We really can only do it once users are so comfortable with passkeys that the fallback to passwords is (almost) never needed."

A design choice further negating the security benefits of passkeys: Amazon, PayPal, Uber, and no small number of other sites supporting passkeys continue to rely on SMS texts for authentication even after passkeys are enrolled.

SMS-based MFA is among the weakest form of this protection. Not only can the texts be phished, but they're also notoriously vulnerable to SIM swaps, in which an adversary gains control of a target's phone number. As long as these less-secure fallbacks exist, passkeys aren't much more than security theater.

I still think passkeys make sense in many cases. I'll say more about that later. First, for a bit more context, readers should know:

Passkeys are defined in the WebAuthn spec as a "discoverable credential," historically known as a "resident key." The credential is in the form of a private-public key pair, which is created on the security key, which can be in the form of a FIDO-approved secure enclave embedded into a USB dongle, smartphone, or computer. The key pair is unique to each user account. The user creates the key pair after proving their identity to the website using an existing authentication method, typically a password. The private key never leaves the security key.

Going forward, when the user logs in, the site sends a security challenge to the user. The user then uses the locally stored private key to cryptographically sign the challenge and sends it to the website. The website then uses the public key it stores to verify the response is signed with the private key. With that, the user is logged in.

Under the FIDO2 spec, the passkey can never leave the security key, except as an encrypted blob of bits when the passkey is being synced from one device to another. The secret key can be unlocked only when the user authenticates to the physical key using a PIN, password, or most commonly a fingerprint or face scan. In the event the user authenticates with a biometric, it never leaves the security key, just as they never leave Android and iOS phones and computers running macOS or Windows.

Passkeys can be stored and synced using the same mechanisms millions of people already use for passwords—a password manager such as Bitwarden, Apple iCloud, Google Password Manager, or Microsoft's cloud. Just like passwords, passkeys available in these managers are end-to-end encrypted using tried and true cryptographic algorithms.

The advent of this new paradigm was supposed to solve multiple problems at once—make authenticating ourselves online easier, eliminate the hassle of remembering passwords, and all but eradicate the most common forms of account takeovers.

When not encumbered by the problems mentioned earlier, this design provides multifactor authentication in a single stroke. The user logs in using something they have—the physical key, which must be near the device logging in. They must also use something they know—the PIN or password—or something they are—their face or fingerprint—to complete the credential transfer. The cryptographic secret never leaves the enclave embedded into the physical key.

What to tell Uncle Charlie?

In enterprise environments, passkeys can be a no-brainer alternative to passwords and authenticators. And even for Uncle Charlie—who has a single iPhone and Mac, and logs into only a handful of sites—passkeys may provide a simpler, less phishable path forward. Using a password manager to log into Gmail with a passkey ensures he's protected by MFA. Using the password alone does not.

The takeaway from all of this—particularly for those recruited to provide technical support this week but also anyone trying to decide if it's time to up their own authentication game: If a password manager isn't already a part of the routine, see if it's viable to add one now. Password managers make it practical to use a virtually unlimited number of long, randomly generated passwords that are unique to each site.

For some, particularly people with diminished capacity or less comfort being online, this step alone will be enough. Everyone else should also, whenever possible, opt into MFA, ideally using security keys or, if that's not available, an authenticator app. I'm partial to 1Password as a password manager, Authy as an authenticator, and security keys from Yubico or Titan. There are plenty of other suitable alternatives.

I still think passkeys provide the greatest promise yet for filling the many security pitfalls of passwords and lowering the difficulty of remembering and storing them. For now, however, the hassles of using passkeys, coupled with their diminished security created by the presence of fallbacks, means no one should feel like a technophobe or laggard for sticking with their passwords. For now, passwords and key- or authenticator-based MFA remain essential.

With any luck, passkeys will someday be ready for the masses, but that day is not (yet) here.

Read full article

Comments

There are many museums, zoos, botanic gardens, and other institutions that are good at translating their educational and preservational assets to social media. And then there’s the Monterey Bay Aquarium and its oceanic lo-fi livestreams. 

Monterey Bay is an internationally respected aquarium that real nerdy-ass fuckin’ nerds will know as the shot-on-location stand-in for the Maritime Cetacean Institute as featured in Star Trek IV: The One With the Whales. But tucked away in California’s central coast, a drive of two hours or more from the closest big city, San Francisco, it’s on the museum’s staff to make their institution accessible to the wide world that might never visit. 

And Monterey Bay’s YouTube team? They’re doing impeccable work. Getting scientists to stream sea-themed video games that run the gamut from chill scuba diving sim Endless Ocean Luminous to the “crustacean-themed ‘Soulslike’” Another Crab’s Treasure. Chill model-painting streams of 3D-printed sea creature models. A livestreamed 24th birthday party for the world’s oldest known sea otter! 

But where Monterey Bay’s content team really excels is in its devotion to the vitally important category of “Second Monitor Videos.” Any aquarium can point a camera at a tank and livestream it. But the Monterey Bay Aquarium is adding curated track lists and — most importantly — punny titles and a tongue-in-cheek attitude. There’s “Krill Waves Radio” and “Littoral Relaxocean” and an April Fools’ stream of head-banging skeleton shrimp set to actually pretty listenable, productivity-motivating metal music. 

This is the Lofi Girl crossover we need. How can you resist the video title “2 Hours of Squid to Relax/Study/Work To”? You can’t. It’s scientifically impossible. Monterey Bay Aquarium biologists would agree. 

Google search hallucinates Encanto 2

Jason Schreier on Bluesky:

I was excited to tell my kids that there's a sequel to Encanto, only to scroll down and learn that Google's AI just completely made this up

I just replicated the same result by searching Google for encanto 2. Here's what the "AI overview" at the top of the page looked like:

Only when I clicked the "Show more" link did it become clear what had happened:

The link in that first snippet was to the Encanto 2: A New Generation page on Idea Wiki:

This is a fanon wiki, and just like fan-fiction wikis, this one has a variety of fan created ideas on here! These include potential sequels and new series that have yet to exist.

Other cited links included this article about Instagram fan art and Encanto's Sequel Chances Addressed by Disney Director, a very thin article built around a short quote from Encanto's director at D23 Brazil.

And that August 2024 release date (which the AI summary weirdly lists as "scheduled for release" despite that date being five months in the past)? It's from the Idea Wiki imaginary info box for the film.

This is a particularly clear example of how badly wrong AI summarization can go. LLMs are gullible: they believe what you tell them, and the web is full of misleading information - some of which is completely innocent.

Update: I've had some pushback over my use of the term "hallucination" here, on the basis that the LLM itself is doing what it's meant to: summarizing the RAG content that has been provided to it by the host system.

That's fair: this is not a classic LLM hallucination, where the LLM produces incorrect data purely from knowledge partially encoded in its weights.

I classify this as a bug in Google's larger LLM-powered AI overview system. That system should be able to take the existence of invalid data sources into account - given how common searches for non-existent movie sequels (or TV seasons) are, I would hope that AI overviews could classify such searches and take extra steps to avoid serving misleading answers.

So think this is a "hallucination" bug in the AI overview system itself: it's making statements about the world that are not true.

Tags: slop, generative-ai, google, ethics, search, ai, llms, rag

The Federal Trade Commission is investigating Microsoft in a wide-ranging probe that will examine whether the company’s business practices have run afoul of antitrust laws, according to people familiar with the matter. In recent weeks, FTC attorneys have been conducting interviews and setting up meetings with Microsoft competitors.

One key area of interest is how the world’s largest software provider packages popular Office products together with cybersecurity and cloud computing services, said one of the people, who asked not to be named discussing a confidential matter.

This so-called bundling was the subject of a recent ProPublica investigation, which detailed how, beginning in 2021, Microsoft used the practice to vastly expand its business with the US government while boxing competitors out of lucrative federal contracts.

At the time, many federal employees used a software license that included the Windows operating system and products like Word, Outlook and Excel. In the wake of several devastating cyberattacks, Microsoft offered to upgrade those license bundles for free for a limited time, giving the government access to its more advanced cybersecurity products. The company also provided consultants to install the upgrades.

Vast swaths of the federal bureaucracy accepted, including all of the military services in the Defense Department — and then began paying for those enhanced services when the free trial ended. Former sales leaders involved in the effort likened it to a drug dealer hooking a user with free samples, as they knew federal customers would be effectively locked into the upgrades once they were installed. Microsoft’s offer not only displaced some existing cybersecurity vendors but also took market share from cloud providers like Amazon Web Services, as the government began using products that ran on Azure, Microsoft’s own cloud platform.

Some experts told ProPublica that the company’s tactics might have violated laws regulating contracting and competition, and the news organization reported that even some of Microsoft’s own attorneys had antitrust worries about the deals.

Microsoft has said its offer was “structured to avoid antitrust concerns.” The company’s “sole goal during this period was to support an urgent request by the Administration to enhance the security posture of federal agencies who were continuously being targeted by sophisticated nation-state threat actors,” Steve Faehl, the security leader for Microsoft’s federal business, told ProPublica.

Some of those incursions were the result of Microsoft’s own security lapses. As ProPublica reported in June, Russian state-sponsored hackers in the so-called SolarWinds attack exploited a weakness in a Microsoft product to steal sensitive data from the National Nuclear Security Administration and the National Institutes of Health, among other victims. Years before the attack was discovered, a Microsoft engineer warned product leaders about the flaw, but they refused to address it for fear of alienating the federal government and losing ground to competitors, ProPublica reported.

While the engineer’s proposed fix would have kept customers safe, it also would have created a “speed bump” for users logging on to their devices. Adding such “friction” was unacceptable to the managers of the product group, which at the time was in a fierce rivalry with competitors in the market for so-called identity tools, the news organization reported. These tools, which ensure that users have permission to log on to cloud-based programs, are important to Microsoft’s business strategy because they often lead to demand for the company’s other cloud services.

According to a person familiar with the FTC’s probe, one such identity product, Entra ID, formerly known as Azure Active Directory, is another focus of the agency’s investigation.

Microsoft has defended its decision against addressing the SolarWinds-related flaw, telling ProPublica in June that the company’s assessment included “multiple reviews” at the time and that its response to security issues is based on “potential customer disruption, exploitability, and available mitigations.” It has pledged to put security “above all else.”

The FTC views the fact that Microsoft has won more federal business even as it left the government vulnerable to hacks as an example of the company’s problematic power over the market, a person familiar with the probe told the news organization.

The commission is not alone in that view. “These guys are sort of a version of ‘too big to fail,’” said Sen. Ron Wyden, an Oregon Democrat who chairs the Senate Finance Committee and a longtime critic of Microsoft. “I think it’s time to amp up the antitrust side of the house, dealing with antitrust abuses.”

The FTC’s investigation of Microsoft, which was first reported by the Financial Times and Bloomberg, is far from the company’s first brush with federal regulators over antitrust issues. More than two decades ago, the Department of Justice sued the company in a landmark antitrust case that nearly resulted in its breakup. Federal prosecutors alleged that Microsoft maintained an illegal monopoly in the operating system market through anticompetitive behaviors that prevented rivals from getting a foothold. Ultimately, the Justice Department settled with Microsoft, and a federal judge approved a consent decree that imposed restrictions on how the company could develop and license software.

John Lopatka, a former consultant to the FTC who now teaches antitrust law at Penn State, told ProPublica that the Microsoft actions detailed in the news organization’s recent reporting followed “a very familiar pattern” of behavior.

“It does echo the Microsoft case” from decades ago, said Lopatka, who co-authored a book on that case.

In the new investigation, the FTC has sent Microsoft a civil investigative demand, the agency’s version of a subpoena, compelling the company to turn over information, people familiar with the probe said. Microsoft confirmed that it received the document.

Company spokesperson David Cuddy did not comment on the specifics of the investigation but said the FTC’s demand is “broad, wide ranging, and requests things that are out of the realm of possibility to even be logical.” He declined to provide on-the-record examples. The FTC declined to comment.

The agency’s investigation follows a public comment period in 2023 during which it sought information on the business practices of cloud computing providers. When that concluded, the FTC said it had ongoing interest in whether “certain business practices are inhibiting competition.”

The recent demand to Microsoft represents one of FTC Commissioner Lina Khan’s final moves as chair, and the probe appears to be picking up steam as the Biden administration winds down. The commission’s new leadership, however, will decide the future of the investigation.

President-elect Donald Trump said this month that he will elevate Commissioner Andrew Ferguson, a Republican attorney, to lead the agency. Following the announcement, Ferguson said in a post on X, “At the FTC, we will end Big Tech’s vendetta against competition and free speech. We will make sure that America is the world’s technological leader and the best place for innovators to bring new ideas to life.”

Trump also said he would nominate Republican lawyer Mark Meador as a commissioner, describing him as an “antitrust enforcer” who previously worked at the FTC and the Justice Department. Meador is also a former aide to Sen. Mike Lee, a Utah Republican who introduced legislation to break up Google.

Doris Burke contributed research.

This story originally appeared on ProPublica.

Read full article

Comments

A process to split methane into its components, hydrogen and carbon, is advertised as a way to make hydrogen from fossil gas without emissions. Yet, claims that methane pyrolysis is free of CO₂ emissions or more efficient than water electrolysis are highly misleading.

Theatergoers will have to wait a bit longer for Robert Pattinson’s Batman to return to the big screen. Matt Reeves’ follow up to 2022’s The Batman has swooped back a year from its Oct. 2, 2026 release date to Oct. 1, 2027.

Warner Bros. greenlit the unnamed sequel in 2022, Reeves will direct and co-write the script with uncredited The Batman screenwriter Mattson Tomlin, with filming expected to begin in mid-2025. Most of the main cast, including Pattinson, Geoffrey Wright, Andy Serkis, and Colin Farrell, is already confirmed to return.

Reeves and Tomlin are naturally keeping the sequel’s script under wraps, but the director did offer some hints when speaking to Digital Spy this week. Though Paul Dano’s Riddler is locked away in Arkham now, Gotham is facing a slow recovery from the catastrophic flood he caused by destroying the city’s seawall. And according to Reeves, that’s made things pretty complicated for Batman.

“In the first movie, Batman views things very simplistically, he sees things in black and white. What he can represent and how he can affect that,” Reeves told Digital Spy. “As we enter into the next movie, there’s a lot more grey. There’s a lot more people at odds. There’s a lot more division in the city. It’s a lot more like our world is now, there’s a lot of turmoil because people are in their camps and they’re not communicating.”

Reeves added, “And when things are in grey, it makes it very hard to be Batman, so this is part of the challenge as we enter it.”