Apple’s new operating system is here, and along with it comes a new version of Siri, dubbed with two very familiar letters: AI. As the name suggests, this Siri power-up resembles an AI chatbot more than the often derided voice assistant you might be used to. It has even evolved from a blob you invoke with a verbal command or a button press to a whole app. This update comes with a slew of privacy complications, but you can take some control over what this new Siri can access and use. 

There’s no denying that the new version of Siri is far more powerful than it used to be, and arguably more useful at surfacing details on your phone. But that comes at the cost of deeper access. Once enabled, Siri and Spotlight are combined, unifying the interface. Where you may have once just pulled down on the screen to search for an app or contact, you’re now also invoking Siri. 

Spotlight and Siri are now visually one and the same.

By default, ask Siri a question and it’ll search through your Apple apps, like Notes, Messages, emails, and more. As time goes on, if the developer chooses to let it, Siri will gain access to more and more third-party apps. If an app developer doesn’t add that support, then Siri AI won’t be able to access the contents of that app (unless it’s shared screenshot-style via a new feature called “on-screen awareness,” which we’ll talk about more in a moment). 

For example, if Signal doesn’t choose to implement Siri AI support and you only talk to Bill on Signal, you won’t get an answer when you ask Siri AI, “What was the last photo Bill sent me?” But if you talk to Bill on Apple Messages and ask that same question, Siri AI will summarize what it thinks the photo is.

Sometimes Siri processes this data on your device. Sometimes it uses Apple’s Private Cloud Compute (PCC), which means the data is sent off your device to a cloud server. While you can try digging through the Apple Intelligence Report to figure out what’s sent to PCC, there’s no immediate visual indication from the user’s point of view when data leaves the device or when AI can handle it on the phone, iPad, or Mac itself. In practice, ask Siri AI a question and you’ll never really know if it’s being computed on device or off.

Apple claims what’s sent to PCC is not stored by the company after it is processed, but there are certain types of data or certain apps you might have on your phone that are not worth the risk. That’s especially true if you’re using a feature like Advanced Data Protection, which turns on end-to-end encryption for much of what’s stored in iCloud. Sending data that’s stored with end-to-end encryption off your device and into the cloud—no matter the privacy promises—is a fundamental change to the risk assessment you should make. “Private” means the system is engineered so that Apple shouldn’t be able to see or store the data, but it doesn’t mean it’s encrypted or doesn’t leave the device.

This leaves the privacy of certain apps up to a strange combination of an app developer’s choices and your own. You can, of course, disable Siri entirely (Settings > Siri > "Turn Off Siri"), or choose not to invoke Siri to ask questions, but perhaps you don’t want to fully disable or disengage with the system. Thankfully, you can put some guardrails on Siri AI’s access. Once you’ve updated to iOS 27, here are the steps to take. 

Note: only iPhone 15 Pro/Pro Max, as well as all models of the iPhone 16 and newer support Apple’s AI features. Siri AI is currently only available in English, and not available worldwide.

How to Restrict Siri’s Access to the Content Inside Apps

By default, how (and if) Siri AI can access data inside apps is up to the app developer. If an app developer chooses to index the contents of their app, then it may appear in search, and thus be made available to Siri AI. This means the content may pop up during general or direct searches, like “What are my plans for November" might cull information from your calendar, Messages, Notes, and, as they update, third-party apps.

If you do not want Siri to look through certain apps to consider the contents in results, you can tell it not to:

• Open Settings > Apps > [the app you don’t want Siri to look through] > Search
• Disable the option to “Show Content in Search.” 

With this setting disabled, when you ask Siri general questions, it will not surface details from the app you selected. For example, if you disable “Show Content in Search” for Messages, it will not be able to read your Messages conversations. 

Left: Asking Siri to summarize a message thread with Show Content in Search enabled. Right: With the setting disabled.

There is also an “App Access” setting where you can configure some of the ways Siri interacts with apps. You’d think this is where we’d have gone to revoke access to the content of an app, but alas, this settings page is more about some basic functionality with device personalization, not Siri’s access to the contents of the app.

• Open Settings > Siri > App Access
• Tap an app where you’d like to change Siri’s settings.

On this screen, you’ll find a variety of options, depending on what an app supports. “Learn from this App” sounds nefarious, but is mostly about tracking usage, like how often you open an app, and if a developer supports it, what you interact with.

The rest of the options are mostly about the personalization tweaks that Siri makes, where it suggests apps it thinks you want at the moment in various places, like when searching or sharing. “Show on Home Screen,” “Suggest App,” and “Suggest Notifications” are just about whether you see apps in those places. 

For example, if you have a widget of Siri-suggested apps on the home screen, that’s the “Show on Home Screen” toggle. If you see an app recommended in another app, like adding a date to your calendar from an email, that’s “Suggest App.” Apple claims these features all use on-device processing and the data is not stored on servers.

For anything not covered here, refer to this documentation for steps to disable certain features.

The On-Screen Awareness Capability May Be Concerning for Some People

There is one Siri AI feature you (and app developers) can’t do as much about: on-screen awareness, a feature you can invoke at any point to prompt Siri and ask it to explain what you’re looking at and perform certain actions. For example, you can ask it to summarize a web page, cut a recipe you’re reading in half, add an event to your calendar, or try to figure out where a photo was taken. All potentially useful features.

But you can also ask it to summarize or explain a Signal group chat that you're looking at, or a meme in a WhatsApp chat, and the data from that on-screen interaction may be sent to PCC. There is currently no way for you or app developers to block this feature, so it’s up to you, and those you chat with, to simply not use it if you’re concerned about the content of conversations potentially leaving your device. It would be a large improvement to privacy, especially secure chat apps, if Apple provided developers a means to block access to Siri AI’s on-screen awareness tool. Even better if they gave you a single control to block all Siri AI features from an app entirely.

Revoke Access to Training Data

By default, Siri AI won’t collect and use data from your interactions with it for training AI features. But during the setup process, Apple provides a way to opt in, which you might have tapped without thinking about it. If you’d rather your data not get used for training, you can opt out:

• Open Settings > Privacy & Security > Analytics & Improvements
• Disable the option for “Improve Siri & Dictation.” 

According to Apple’s privacy documentation, disabling this option should revoke training access to the audio and text from the Siri app.

Go Back to the Old Version of Siri (and Disable Other AI Features)

Want nothing to do with any of this but still find Siri useful enough to keep around (or you just have to keep it turned on in order to use CarPlay)? For the time being, you can get the old Siri back, though the process is a bit odd.

• Open up Settings > Screen Time > Content & Privacy Restrictions
• If you have never done so, enable the toggle for “Content & Privacy Restrictions.”
• Tap the Siri option, then “Allowed Siri Version.” 
• Select “Siri Classic.”

You can no longer easily disable Apple Intelligence entirely with one tap in the Settings, but on this screen you can also configure other AI features, like disabling the writing and math assistance prompts, turning off image creation, and disallowing the use of extensions. Follow this guide on Apple's site for everything else.

For the most part, Apple’s handling of AI features is far less in-your-face than others, and because of that the privacy implications are easier to untangle. But even still, it’s difficult to know what’s processed on device and what’s sent off, and so the privacy trade-offs are never spelled out as clearly as they should be. 

Apple could improve on this by offering an on-device only option for Siri AI and providing a clear, single setting toggle to prevent all AI features in a specific app (it looks like Apple is planning a single privacy toggle in a future update. We'll update if and when it does). In general, Siri’s power-up has also made it blurry and difficult to really figure out what sorts of privacy options exist. “Siri” means many things, both on device and off, ranging from “searching the entire internet for an answer” to “setting a timer,” and users have no straightforward ways to wrangle that data to suit their needs. As it stands, it’s a confusing collection of different toggles that never feel exactly right and which many users might struggle to grasp.

Secure messaging platforms, like Signal, WhatsApp, and recently, encrypted RCS, operate on a straightforward assumption: the content at each end of a conversation is private to the participants in the conversation. End-to-end encryption helps provide the mathematical guarantees that the companies who operate these messaging platforms cannot access the contents of messages. But there’s no way to guarantee what happens once the message arrives on a phone. As more devices and services introduce more artificial intelligence (AI) features into messaging apps, that line begins to blur. 

When AI features are computed entirely on device, it’s less concerning. Yet sometimes the computing requirements are heavy enough that the computation has to be done on a company server. Tech companies tell us they have a solution for this: trusted execution environments (TEEs). But do server-side TEEs really solve the problem?

TEEs exist to serve many different functions, ranging from digital rights management (DRM) content protections to securely storing information in your phone's mobile wallet, but for our purposes, we’ll be focusing on how tech companies use them for their AI tools. 

The basic idea is straightforward: most consumer devices aren’t powerful enough to handle the sorts of AI features companies want to offer, so sometimes they send data off your device to more powerful cloud servers to do the computing, then display the results on your device. Since your data is leaving your device, there’s a privacy compromise. For example, if you ask for a messaging app to summarize a conversation, it may offload that computing power to a cloud server, sending the entire contents of your messages to the cloud, then back to your phone.

TEEs supposedly offer a way to keep those requests private. There are several implementations out there, like Apple’s Private Cloud Compute, Google’s Private AI Compute, and WhatsApp’s Private Processing. It’s not just the big tech players, we’ve seen chatbots built with TEEs as well.

TEEs can provide more security and privacy than simply running in the clear, but they are fundamentally different from actual encryption or running locally. Despite the promises of some tech companies, they will never be able to match that level of security and privacy. Because of that, a user’s device should never automatically send data to a TEE. Let’s dig through the reasons why.

What Exactly Is a TEE, Anyway?

A TEE is a hardened section of the computer that runs software in a way that’s supposed to be secret even from other processes running on the machine. TEEs also let users check that the code being run is the code that they think is running, and not backdoored code instead, using a process called “attestation.” You may have also heard this referred to as a “secure enclave,” or heard the brand names SGX or TrustZone.

The intention of a cloud-based TEE is simple: a company can run a server in their data center, but still process data that you provide on your behalf without being able to see that information themselves.

Is a TEE Secure?

In practice, we've seen multiple cracks and hacks every year that show that it is possible to get at that data. That’s because while encryption relies on math, TEEs rely on engineering to provide their security. Standard encryption algorithms are created by years-long processes collaboratively produced by mathematicians around the world and are based on problems that have been studied for decades. The math is reliable, and there is no shortcut to breaking it that would not also upend fundamental understandings of mathematics as a field. 

The collective understanding of every mathematician in the world is that standard encryption algorithms are not breakable to the best of the world’s collective knowledge. No responsible engineer builds a system based on a new encryption method until after it’s been offered up for prodding.

Engineering, on the other hand, doesn’t work like that. Every individual system is the product of a group of engineers who put it out into the world, and each product will have its own quirks and bugs that have to be individually discovered and patched. These bugs are found after the system is built, not before. No one has yet built a system that is unbreakable. On the contrary, there is new research all the time that finds new ways to break into TEE systems. They’re patched as they come up, but they’re unlikely to ever become perfect, and certainly not any time soon. 

TEEs in particular are a hard engineering problem because the encryption key is physically right there on the device. Building a TEE means keeping a key fully separate and inaccessible while it’s on the same physical device as parts of the system that shouldn’t have access to the key.

Many attacks on TEEs involve “side channels.” In a side channel attack, the attacker measures the electrical impulses or other effects to figure out the timing of operations inside the TEE, then uses that to figure out the key being used. Once they have the key, they can read all the data. Compare that to end-to-end encryption, where the key is never on that machine in the first place, so an attacker would have to also run a similar attack on the user’s device.

Companies who turn to TEEs to protect data want to both have the key on the server and have it protected while still performing complex operations like running an LLM, which makes it much more difficult to protect those keys.

That being said, a TEE versus plaintext on a server is the difference between being able to easily read the data and having to do a bunch of specialized work to get at the data. That work often involves accessing the physical machine. This is most relevant for protecting against mass surveillance, and for many people, that might just be enough security.

But that's the core of the problem. “Secure enough for most cases” and “encrypted as in math” are not the same thing, and it’s important not to conflate the two. And services that currently offer “encryption as in math” have a real downgrade in security when they switch to security based on TEEs. 

If you want to dive into the myriad security issues and limitations of TEEs we’ve seen so far, they’re well documented here, here, here, and here.

What Does This Have To Do With LLMs and AI?

Sometimes organizations want to offer an LLM that can respond to queries in a private manner. On-device LLMs exist, but they’re limited in size. So, when organizations want to offer the ability to answer queries without being able to see the conversation, they turn to TEEs. That’s a useful way to run a chatbot that’s reasonably private. This is what Apple, Google, WhatsApp, and others are doing.

Why not turn to encryption? After all, LLM inference is just a bunch of math like any other things a computer does. It takes input to a (really big) function and gives an output. We have the math to do that computation in a way that hides the inputs and outputs from the one running the computation, it's just super expensive. It’s called homomorphic encryption, and no one’s figured out how to do it fast enough that it makes sense for this sort of computation.

Instead, the allure of a TEE is that it will run that computation for you inside of a special opaque section of a server. TEE manufacturers try to make it as hard as possible for the person running the TEE to peek inside. But you still have to trust the operator to not put a stethoscope to the box to try to figure out what's happening inside. 

In this case, it’s reasonable to consider these systems “privacy-preserving,” but not “encrypted.” That distinction is important, especially when we talk about how the TEEs interact with secure messaging. When someone using an end-to-end encrypted chat app asks an LLM to summarize, review, or store those messages, the content of those messages is leaving the device and going to an unencrypted third-party server somewhere. That’s a major threat to the privacy of secure chat apps, and one that’s increasingly hard for users to take control of.

How Does This Translate to Practical Advice?

The answer to this is going to vary based on an individual’s threat model, but a good rule of thumb is that a user’s device should never automatically send data to a TEE. When the person holding a phone can choose what information is sent, even if it’s a chunk of data like “unread messages,” they have the opportunity to pause and consider if that data might be too sensitive to risk sending.

In contrast, when data is sent automatically, the automatic sending becomes a feature of the system as a whole. If the system was previously end-to-end encrypted, adding automatic exfiltration makes the whole system no longer end-to-end encrypted.

Developers: don’t build systems that automatically send data off a device to a TEE, especially when it’s coming from an app that is otherwise end-to-end encrypted.

Users: if developers ignore us and build that system, turn off any automatic data sending features. Take a second to think about how much you’re willing to risk sending data when you choose to send it off the device.

So, What Should I Be Concerned About?

TEEs are useful for security in a number of circumstances. Your phone likely has a TEE where it keeps the key that encrypts your biometric unlock data and the base of the keychain where passwords are stored. It also enables certain backup systems, like how you can restore a phone with your passcode or restore WhatsApp or Signal backups.

But when we’re talking about cloud processing, it’s important to be clear this isn’t the same as end-to-end encryption and doesn’t offer the same level of privacy. 

Most of our private lives are on our phones and in our messages. We’ve worked for years to secure those messages, with major wins like encrypted RCS, and the continued user experience improvements of Signal and WhatsApp. We’ve even seen real improvements to backup security with features like Advanced Data Protection that bring end-to-end encryption for a variety of data outside of messaging, like notes and photos. 

But as companies roll out AI features that interact with these encrypted services, pulling data off devices and into a cloud-based TEE, they’re eroding the privacy protections of end-to-end encryption and risk causing serious confusion around what data is protected and what isn’t.

The term “digital sovereignty” has become ubiquitous. European officials invoke it in debates about cloud infrastructure, AI, semiconductors, and platform regulation. Governments throughout the global majority use it to argue for greater control over data and communications infrastructure and boost their economies. Companies market “sovereign cloud” products designed to reassure their customers that their information stays under local jurisdiction. But digital sovereignty could be something more: an opportunity for users around the world to build more resilient, open  systems and the skills and infrastructure to maintain them.

There is no singular definition of digital sovereignty, nor is there a single coherent position in the digital rights space. Despite its growing popularity, the term remains frustratingly vague. Policymakers, regulators, civil society groups, and others can mean very different things when they use the term. But to start simply with a broad definition, we can say that it means having the capacity to control one’s digital destiny—though the implications of that will obviously differ considerably whether you’re talking about an individual or a country.

We can start by developing  a shared understanding of what digital sovereignty actually means. We’ve also included a glossary of terms at the bottom of this post. 

In Europe and other places where digital sovereignty has become a topic of policy, discussions focus on reducing dependency: on foreign (and particularly American) cloud infrastructure, chips, platforms, and at times, foreign political priorities. The concern is both economic and geopolitical. If essential infrastructure is controlled by companies elsewhere—and thus subject to the laws of another jurisdiction—then what control does a country actually have over its own digital future?

In global majority countries in particular, wars, sanctions, and the growing fragmentation of the internet have demonstrated for many that the physical infrastructure that underlies digital life is neither neutral nor invulnerable. 

Amidst this increasing geopolitical instability governments and civil society should consider whether digital sovereignty can help shore up that infrastructure. 

What are we talking about when we talk about digital sovereignty? 

A recent Franco-German joint paper on digital sovereignty defines it as the “capability and capacity to develop, provide, use, adapt and control digital technologies including hardware in an independent, self-determined and secure manner” and puts forward a framework to operationalize Europe’s capacity to act in the digital domain. 

Some governments, such as Germany’s, have started to put funding behind sovereignty efforts through initiatives like the Sovereign Tech Agency, which “invest[s] globally in the open software components that underpin Germany's and Europe's competitiveness and ability to innovate.” 

Positions on digital sovereignty among EFF’s allies across Europe vary. Open Rights Group have defined digital sovereignty as “the ability of a country to have control over its digital infrastructure, data, and technology” and states it to be “critical for the UK’s economic and national security.” 

Similarly, the European Partnership for Democracy has expressed concern that “a few Big Tech corporations decide our collective destiny,” and argue that the EU should explore “alternative ownership models for tech companies and clearly [define] their purpose and mission.” And our friends at EDRi (of which EFF is a member) have stated clearly that “Europe’s digital sovereignty starts with open source.” Some initiatives, such as DI.DAY, consider digital sovereignty an opportunity to free users from Big Tech dependencies.

Elsewhere in the world, conversations about digital sovereignty often take a different shape. Indigenous discussions of the topic have been ongoing for more than a decade and focus on the inherent right of Native nations to govern their own digital ecosystems. In Southeast Asia, the desire for digital sovereignty has created growth in the sovereign cloud industry, but the conversation isn’t purely economic: Concerns about jurisdiction for where data is held are driving much of the conversation. 

In Latin America, digital public infrastructure is often a key aspect of debates. Across Africa, leaders speak of a desire to shift the continent from being consumers of technology to becoming architects of their own digital infrastructure and data ecosystems. And in the Middle East and North Africa, concerns about reliance on U.S. technology companies—which have engaged in conflict and disproportionate censorship (particularly of Palestinian voices) in the region—are often paramount.

Reem Almasri, a senior researcher based in Jordan, recently spoke to EFF about digital sovereignty, which she sees as “the ability of people and communities to choose, control, and use technology that serves their needs and values,” particularly in light of the role that U.S. companies have played in regional conflicts.

In a January article, Almasri pointed to growing concerns about granting greater sovereignty and influence to governments over citizens’ data, communications, and websites, writing: “This is particularly worrisome in countries that impose high levels of internet and media censorship and run unaccountable surveillance programs on their citizens’ data.”

Indeed, while pushing for greater sovereignty from Big Tech has benefits, there is an inherent risk that some states will pursue digital sovereignty as a means of cutting off or splintering access—as we’ve already seen in Iran, Russia, and elsewhere.

For that reason, it’s no surprise that some, such as Iranian professor Azadeh Akbari, believe that “the current wave pushing digital sovereignty as the key to ending dependency on American and Chinese technology is negligent of its Eurocentric bias.” 

What does EFF believe?

In a world where people have digital sovereignty, civil society should be able to communicate freely, privately, and anonymously if they wish. People should be able to easily understand where their data lives and who has access to it. That data should be easily portable between platforms and services.

At EFF, we view digital sovereignty not as a walled garden, but as an opportunity for resilience and development of industries and skills. We believe that governments can and should take a role in crafting digital sovereignty that centers the autonomy of users rather than just re-creating a state of digital dependency with a new set of companies. Governments should support and use free and open source tools and projects built using principles of interoperability and data portability. This support should include employing full-time developers, UX designers, and community managers. Government policy and legislation should grant users control of their own data and a clear understanding of who can lawfully access it. Digital sovereignty should foster users’ ability to choose how they use digital products and services, free from unfair lock-ins, coercive terms and manipulative defaults. It should also foster the broader public interest internet, the part of the web that provides public goods and useful services without requiring the scale or the business practices of the tech giants.

Encryption backdoors are fundamentally incompatible with a vision of data sovereignty that centers user control. Governments should support the development and normalization of reputable end-to-end encrypted communications as well as strong encryption for data at rest. This support should include employing cryptographers and contributing to strong, peer-reviewed encryption standards strengthened by data minimization as a fundamental design principle, as well as refraining from legislating mandates for “lawful access” or any other reason.  

As technologists, we don’t have to wait for governments to act in order to create the digital sovereignty we want. We get the internet that we build. We can contribute to open source, decentralized, and end-to-end encrypted projects. We can build standards that make interoperability and data portability a feature from the very beginning. We can resist the call of proprietary solutions, user lock-in, and encryption backdoors.

And finally, while digital sovereignty is often framed as a response to the dominance of Big Tech, that does not mean that there is no role for private companies to play. There is no point in replacing the influence of a few mostly US-based tech companies with a handful of giants based elsewhere. Companies can and should build platforms and services on top of open source, decentralized protocols and contribute to the ecosystem. Companies should also minimize processing a person’s data except as strictly necessary to provide them what they asked for, and only with opt-in consent that makes it clear to users what data they are gathering, where it is stored, and who has access to it. And companies should build their tools and platforms in a way that allows interoperability and that makes it easy for users to leave with their data. Some of these practices are already required by law in some jurisdictions, but companies don’t have to merely do the bare minimum the law demands: they should respect their users and support data sovereignty right now.

A glossary of terms

The following terms are useful for understanding this blog post as well as the broader conversation about Digital Sovereignty:

Intermediary liability: the legal responsibility of online service providers (ISPs, websites, social media platforms) for unlawful activities by their users, such as defamation, copyright infringement, or illegal hate speech.

The stack: a secure, open-source technology framework, often focusing on European alternatives, designed to break dependencies on (mostly) US-based technology providers. It comprises interoperable, vendor-neutral, and transparent digital infrastructures designed to regain control over data, infrastructure, and technology.

Digital sovereignty: the ability of people, as nations, organizations, and individuals, to control their own digital destiny by retaining authority over their own data, technology, and infrastructure.

Data sovereignty: the principle that digital information is subject to the laws and governance frameworks of the country or region where it is physically collected, stored, or processed. It dictates that data remains bound by the specific privacy protections and regulations of its originating jurisdiction, regardless of where the collecting organization is located.

Digital commons: a shared, online resource, such as knowledge, software, and data, that is collectively produced, governed, and maintained by a community, intended for public access. Examples include Wikipedia, open source operating systems such as Linux, and Creative Commons licensed content.

Data portability/interoperability: the ability to easily transfer personal data from one service provider to another, or to a personal system, in a structured, machine-readable format. It empowers users to move away from "walled gardens," reducing vendor lock-in and enhancing user autonomy.

Digital dependency: the opposite of digital sovereignty. The inability of people as nations, organizations, and individuals to control their own digital destiny through control over their own data, technology, and infrastructure. 

Decentralization: a shift away from relying on centralized, often US-based, corporate platforms toward a distributed, user-centric internet where individuals, communities, and nations maintain control over their data, digital identity, and infrastructure.

End-to-end encryption (e2ee): a secure communication process where only the sender and intended recipient can access, read, or decrypt messages or data.

Fairness (à la the Digital Fairness Act): the absence of deceptive, manipulative, or addictive design practices that distort consumer choice and exploit vulnerabilities. 

User sovereignty: the concept that individuals possess absolute control over their personal data, digital identity, and online privacy, rejecting the centralization of power by large technology platforms. It emphasizes user consent, decentralization, and the ability to manage personal data using secure and independent tools.

With no serious debate, including on proposed amendments, Canada is blazing full speed ahead with Bill C-22, which would threaten encryption and increase surveillance. Also known as the Lawful Access Bill, Bill C-22 is currently moving forward quickly to a vote despite the many, many criticisms civil liberty groups and the tech industry have hurled at it.

As we’ve discussed before, Bill C-22 is dangerous on multiple levels. It pushes for requirements for metadata retention, expands information sharing with foreign governments, and establishes a mechanism that allows Canada’s Ministry of Public Safety to demand that companies create backdoors, effectively breaking encryption. That mechanism was a key facet of Part 2 in Bill C-22, and the government prevented it from being independently debated.

In a deep analysis of the bill, Citizen Lab and the Canadian Civil Liberties Association detail every one of flaws of this proposal, concluding that most elements are unsalvageable. 

A wide range of tech companies agree. Signal, Apple, Google, and several VPN providers oppose the bill, and some have said they’d likely be forced to either cut Canadians off from certain features or shut down services in Canada altogether.

The Canadian government wants this dangerous, complicated, overreaching bill passed before June 19. Bill C-22 is riddled with privacy problems that affect millions of people. It should be debated and studied fully, not jammed through on an arbitrary deadline. 

OpenMedia is offering a tool for Canadians to contact their elected representatives about the bill. Actions taken on OpenMedia's website are governed by OpenMedia's privacy policy, not EFF's.

Last week, Instagram ended its opt-in, and therefore rarely used, end-to-end encryption feature. Years after publicly promising to provide the privacy protections of end-to-end encryption across its platforms by default, it instead gave up on that technical challenge. Now, we've all lost an option for safer conversations on one of the biggest social media platforms in the world.

In an announcement in 2023, Meta bragged about how it had successfully encrypted Messenger, and teased that Instagram was in progress. Even before then, they’d talked about how important encryption was in Messenger and Instagram in a white paper published in 2022, stating: 

We want people to have a trusted private space that’s safe and secure, which is why we’re taking our time to thoughtfully build and implement e2ee by default across Messenger and Instagram DMs.

So where did the reversal come from? In a statement, Meta claimed that, “Very few people were opting in to end-to-end encrypted messaging in DMs.” This isn’t all that surprising, as turning it on was an optional four-step process that few people knew about. Defaults matter, and Meta’s choice to blame people for failing to opt into this feature is proof of how much. In that same statement, the company pointed people to WhatsApp for access to encrypted messaging. Yet if Meta truly wanted people to have a trusted private space to communicate, it would meet them everywhere they are: on WhatsApp, on Messenger, and on Instagram.

But at least Meta was straightforward about the fact that it will not continue to support or work on this feature. That's rare. Most tech company promises aren’t broken explicitly, they just remain undelivered long enough to be forgotten. 

This is particularly disappointing as other companies take even bigger swings, like Google and Apple working together to implement end-to-end encryption over Rich Communication Services (RCS), and Signal’s continued work to make its app simpler and easier to use for everyone.

Meta abandoning this principle is disheartening, especially as we are still waiting for other promised features from the company, like end-to-end encryption in Facebook Messenger group messages. Instead of blaming users for not using these sorts of features and then abandoning the promise of delivery, Meta—and other tech companies—should start by enabling strong privacy protective features by default.

This week, Apple released iOS 26.5, an update that supports end-to-end encryption for Rich Communication Services (RCS), meaning conversations between Android and iPhone will soon be encrypted in the default chat apps. This has been a long time coming, and is a welcome delivery on a promise both Google and Apple made.

With this update, conversations that take place between Apple’s Messages app and Google Messages on Android will be end-to-end encrypted by default, as long as the carrier supports both RCS and encrypted messages (you can find a list of carriers here). RCS messages are a replacement for SMS, and in 2024 Apple started supporting it, making for a marked improvement in the quality of images and other media shared between Android and iPhones. 

Now, those conversations can also benefit from the increased privacy and security that end-to-end encryption offers, making it so neither Google, Apple, nor the cellular carriers have access to the contents of messages. This feature comes courtesy of both Apple and Google supporting the GSMA RCS Universal Profile 3.0, which implements the Messaging Layer Security protocol for encryption. Metadata will likely still be collected and stored for these conversations, making alternatives like Signal still a better option for many conversations. Likewise, if you back up those conversations to the cloud, they may be stored unencrypted unless you enable Advanced Data Protection on iOS (Google Messages end-to-end encrypts the text of messages in backups, but not the media, so we’d like to see a similar offering as ADP on Android). Still, this is a significant step forward for the privacy of millions of conversations worldwide.

End-to-end encrypted RCS messaging is still marked as beta on Apple devices, likely because the rollout is dependent on carriers as well as the Android phone running the most recent version of Google Messages. 

It might take some time before you get this feature in your chats and until you do, remember that the conversations are not protected with end-to-end encryption. But once everyone in the conversation is on the right software version and the carrier support is implemented, you will see a lock icon and the text, “Encrypted” at the top of the conversation for any chats you have over RCS, as seen here:

We applaud Apple and Google for getting this across the finish line and Encrypting It Already! More companies should take these sorts of difficult but necessary steps to protect the privacy of our conversations and our data.

Last year, the Canadian government pushed Bill C-2, which would erode Canadian digital rights in the name of “border security.” The bill was so bad it didn’t even make it to committee because of the backlash from the privacy community. Now, the spring’s worst sequel, Bill C-22, aka The Lawful Access Act, is trying it again.

As with most sequels, Bill C-22 makes some tweaks to problematic elements, but largely retains the same problems. The bill forces digital services, which could include telecoms, messaging apps, and more, to record and retain metadata for a full year, and expands information sharing with foreign governments, including the United States. Metadata can reveal a lot about who you communicate with, where you go, and when you do so. Expanding the collection of metadata would require companies to store even more information about their users than they already do, providing an incentive for bad actors to access that information. 

Worst of all, Bill C-22 erodes the privacy of millions by providing a mechanism for the Minister of Public Safety to demand companies create a backdoor to their services to provide law enforcement access to data, as long as these mandates don’t introduce a “systemic vulnerability.” These widespread surveillance backdoors would likely facilitate even more data breaches than we see already. The bill also bans companies from even revealing the existence of these orders publicly.

The definitions of both “systemic vulnerabilities” and “encryption” are not clear enough in C-22, leaving wiggle room for the government to demand that companies circumvent encryption. And the overbroad definitions in the bill can include apps as well as operating systems. Canadian officials have made it clear they believe it’s possible to add surveillance without introducing systemic vulnerabilities, which is just not true. Surveillance of encrypted communications is fundamentally a systemic vulnerability.

This resembles what happened in the UK last year, when the government demanded that Apple implement this type of backdoor into its optional Advanced Data Protection feature, which then forced Apple to revoke the feature for its UK users instead of complying with the request. To this day, UK users still do not have access to this powerful, privacy-protective feature that provides stronger protections for data stored in iCloud. Both Meta and Apple are concerned that C-22 would give the Canadian governments similar powers, and both companies have come out against the bill. The U.S. House Judiciary and Foreign Affairs committees also sent a joint letter to Canada’s Minister of Public Safety highlighting the concern around backdoors into encrypted systems.

The dangers of these sorts of backdoors are not theoretical. In 2024, the Salt Typhoon hack took advantage of a system built by Internet Service Providers to give law enforcement access to user data. When you build these systems, hackers will come.

Canadians deserve strong privacy protections, transparency into how companies handle user data, and clear safeguards around encrypted data. Bill C-22 provides none of that, instead reaching further into the digital pockets of tech companies to build broad lawful access mechanisms.

Further reading

• Full text of C-22
• Canadian Civil Liberties Association statement and letter
• Open Media blog on C-22
• EFF’s blog on bill C-2

EFF friend Guy Kawasaki* has written a book: Everybody Has Something to Hide: Why and How to Use Signal to Preserve Your Privacy, Security, and Well-Being. This guide is now available in Spanish and English as an ebook in the EPUB format that you can download here. Take a look and consider sharing it with anyone who you know who uses (or should use) Signal. 

And don't forget: EFF has two short guides on using Signal on our Surveillance Self-Defense site. An intro How to Use Signal guide, and a guide on Managing Signal Groups. 

Everybody Has Something to Hide: Why and How to Use Signal to Preserve Your Privacy, Security, and Well-Being courtesy of Guy Kawasaki. 

*Guy Kawasaki is an EFF donor.

A phone’s push notifications can contain a significant amount of information about you, your communications, and what you do throughout the day. They’re important enough to government investigations that Apple and Google now both require a judge’s order to hand details about push notifications over to law enforcement, and even with that requirement Apple shares data on hundreds of users. More recently, we also learned from a 404 Media report that law enforcement forensic extraction tools can unearth the text from deleted notifications, including those from secure messaging tools, like Signal. The good news is that you can mitigate some of this risk. 

There are two points where notifications may betray your privacy: when they’re transmitted over cloud servers and once they land on the device. Let’s start with the cloud. It might seem like push notifications come directly from an app, but they are typically routed through either Apple or Google’s servers first (depending on if you use iOS or Android). According to a letter sent to the Department of Justice by Senator Wyden, the content of those notifications may be visible to Apple and Google, and at the very least the companies collect some metadata about what apps send a notification and when. App providers have to make the decision to hide the content from Apple and Google and implement that functionality; Signal is one app that does this. 

Then, once the notifications land on your phone, depending on your settings, the notification content may be visible on your lock screen without needing to unlock the device. This can be dangerous if you lose your device, someone steals it, or it’s confiscated by law enforcement. 

You may clear notifications after looking at them. But it turns out the content notifications get recorded in your device’s internal storage, which then makes them susceptible to recovery with certain types of forensic tools. Notification content may even persist after the app is deleted, if the OS doesn’t fully purge the app’s notification data. 

We still have a lot of unanswered questions about how the notification databases work on devices. We do not know how long notifications are stored, or whether they’re backed up to the cloud, in which case the cloud provider could get backdoor access to the content of messages if the backups are enabled and not end-to-end encrypted. This may also make backups vulnerable to law enforcement demands for data. 

Which is all to say that there are myriad ways that law enforcement can access the content or metadata of push notifications. Let’s fix that.

Consider the Strongest Notification Protections for Your Secure Messaging Apps

Secure chat tools are designed to keep the content of the messages safe inside the app. So, for secure chat apps like WhatsApp and Signal, that means the company that makes those apps cannot see the content of your messages, and they’re only accessible on your and your recipients’ devices. Once messages land on a device, it’s still important to consider some privacy precautions, particularly with notifications. 

Signal
Signal offers three levels of information to include in notifications, all which are pretty self explanatory:

• Name, Content, and Actions (Name and message on Android) shows the entirety of a message as well as who sent it (on iPhone you can also slide to reply, mark as read, or call back). 
• Name only only shows the name of the sender. 
• No Name or Content (No name or message on Android) will only show that you have a message from Signal, not who sent it or what it’s about. 

To change your settings:

• On iPhone: Tap your profile picture, then Settings > Notifications > Show.
• On Android: Tap your profile picture, then Notifications > Show. 

WhatsApp
WhatsApp only has one option for this, and it’s currently limited to iPhone, but you can at least tell the app not to include the content of a message in the notification:

• Open WhatsApp for iPhone, tap the “You” bar, then Notifications, and disable the Show preview option.

Check your other apps to see if they offer similar settings.

Limit Your Notifications Device-Wide

Since Apple and Google manage push notifications for their respective devices, they also have some visibility into certain data. Push notification data can include certain types of metadata, like which app sent a notification and when, as well as the account ID associated with the phone. In some cases, Apple and Google may have access to unencrypted content, including the content of the text in a notification or other information from the app itself. 

For most app notifications, there’s no simple way to easily figure out what metadata might be gleaned from a notification, or if the notification is unencrypted or not. But some app developers have described details along these lines. For example, Signal president Meredith Whittaker explained on social media how the Signal app handles notifications entirely on-device. Searching online for an app name along with “notification privacy,” “notification encryption” or “notification metadata” may help answer your questions, or you may need to dig around in support forums for the app.

It’s also good to reconsider whether any app should be sending you notifications to begin with. Aside from a potential decrease in the number of distractions you endure throughout the day, or the level of chaos on display on your lockscreen, limiting the apps that can send notifications and what content is visible in them can improve your privacy with respect to the sorts of metadata that may be gathered by the companies, as well as any content that may be viewable if someone has physically accessed your device.

To check and change your settings on iPhone

• Open Settings > Notifications.
• On the Show Previews option, you can choose whether to show the content of notifications on the lock screen, “Always,” which doesn’t require unlocking the device, “When Unlocked,” which does, and “Never,” which means notifications won’t have any details, just that you have a notification in an app. 
• Alternatively, you can scroll down and change these settings per app. Just tap the app name, then the Show Previews menu, and choose how you’d like them to appear. Or, if you’ve decided you don’t want notifications from that app at all, uncheck the Allow Notifications option.

To check and change your settings on Android
The core version of Android relies on app developers to develop specific settings more than controlling them on a platform-wide level.

• Open Settings > Notifications > App notifications to disable notifications from any app completely. Some apps may also offer internal notification options for specific types of notices, like new messages, that you can control in the app itself. Tap an app name, then tap the Addition settings in the app option to potentially customize it more.
• You can also experiment with the sensitive content setting. This is up to the developer to set properly, but when done so, most notifications will require at least unlocking the device to see them. Open Settings > Notifications > Notifications on lock screen and disable “Show sensitive content.”

Control What Notifications AI Tools Can Access

In an attempt to make notifications easier to skim, both Android and iOS offer optional ways to get notification summaries using their AI tools that summarize the content of notifications. On an individual app level, WhatsApp offers this as well. Some of these summarization tools, like Apple’s, run on the device, while others, like WhatsApp’s, do not. This can all be a lot to keep track of, and sending data off device may create some level of risk for some messages.

Since this is a bit more complicated, we have another blog post that walks through the steps to take to protect messaging from accidentally ending up in AI tools built into Apple and Google's devices. For WhatsApp specifically, we have a blog detailing when you might want to turn on the app’s “Advanced Chat Privacy” feature, which can disable summaries for both yourself and others in the chat.

Balancing security, privacy, and usability with something like push notifications is a complicated task. At the very least, Apple and Google should better ensure that the content of these notifications isn’t transmitted over their servers in plain text. The companies need to also make sure that device operating systems don’t back up the notification database to the cloud, and when an app is deleted, that all notification data is purged.

We appreciate that apps like Signal allow you to control what’s visible with notifications on a per-app basis, and we’d like to see this level of granularity of choices in other secure messaging tools, like WhatsApp. Likewise, more apps should handle push notifications similarly to the way Signal does, where a ping is sent to wake up the app to check for messages, and the content of that message is never sent across servers.

Google moved up its estimated deadline for quantum preparedness in cryptography to 2029—only 33 months from now. That’s earlier than previous deadlines, and they proposed the new post-quantum migration deadline because of two new papers that comprise a big jump in the state of the technology. It’s ahead of schedule, but not altogether unexpected. Cryptographers and engineers have been working on this for years, and as the deadline gets closer, it’s not surprising to see more precise timeline estimates come up.

The preparation for the Y2K bug is not a perfect analogy. Like Y2K, if systems are not updated in time, anyone with a powerful enough quantum computer will be able to more easily insert malware into the core systems of a computer and fake authentication to allow impersonation merely by observing network traffic. These are the threats whose mitigation timelines have been moved up.

But unlike Y2K, there’s a second sort of attack that we already need to be prepared for: quantum computers will be able to decrypt years of captured messages sent over encrypted messaging platforms shared any time before those platforms updated to quantum-proof encryption. That type of attack has been the main focus of engineering efforts so far and mitigation is well on its way, since anything before the upgrade might eventually be compromised.

Fortunately, not all cryptography is broken by quantum computers. Notably, symmetric encryption is quantum resistant. That means that if you have disk encryption turned on, you shouldn’t have to worry about quantum computers breaking into your phone, as long as your system’s keys are long enough. The problem is how you get the keys to do that encryption, and how you authenticate software on your device and in the cloud.

Engineers: Time to Lock In

For those whose work touches on any sort of cryptographic deployment, you’re hopefully already working on the post-quantum transition. If not, you really should be; there are quite a few relevant posts and updates with more information about what this news means for you. Your key agreement systems should be upgraded soon if they’re not already because of store-now-decrypt-later attacks. Now it’s time to prepare for authentication attacks on forged signatures as well.

In some cases, you may need to wait on others to finish their work first. If you’re using NGINX to host websites on Ubuntu, for example, the security settings you need to upgrade key agreement were just released in version 26.04. Updates are rolling out, so keep checking in and upgrade your systems as soon as you’re able to.

Users: Stay Updated, Check on Your Chats

But if you’re not in any position to be updating software or hardware, there may be some additional steps you can take to make sure you're as protected as possible. You’ll want to get the latest post-quantum protections as soon as they're available, so if you don't already have a habit of applying software updates in a timely manner, now’s a good time to start.

If you want to know if the website you’re using or the encrypted messaging app you’re chatting over will leak its data in a few years to anyone storing traffic now, you can search for its name with the word "quantum." The engineers are usually pretty proud of their work and have announced their post-quantum support (like what we’ve seen from Signal and iMessage). If you can’t find that information, you may want to have extra consideration for what you say over the internet, or switch the tools you're using. Those are the big areas to worry about now, before quantum computers are actually here, because they could result in the mass leakage of old messages.

The new deadline means that some technologies are simply not going to make it in time and will have to be left by the wayside, like trusted execution environments (TEEs), due to the slower speed of hardware deployments. TEEs are how companies do private processing on user data in the cloud, and they’re particularly relevant to AI offerings. 

Even now, though they offer more protection than processing data in the clear, TEEs are not as secure as homomorphic encryption or doing the processing on device. Post-quantum, the security level gets much closer to computation on cleartext, and even with strong user controls, that makes it way too easy to accidentally backdoor your own encrypted chats. If you’re worried about the contents of messages in an encrypted chat being exposed, you’ll probably want to completely avoid using AI features that might leak that content, such as summarization of recent chat history and notifications, and reply composition assistance. 

How’s the Transition Going So Far?

The work to update the world to post-quantum is well on its way. NIST finalized the standards for post-quantum cryptographic algorithms back in 2024. The larger platforms, websites, and hosting providers have already updated their algorithms, so even now, you’re probably already using post-quantum algorithms to access some of the internet. Measurements vary pretty widely, but up to about 4 in 10 websites currently support a post-quantum key exchange.

There’s still some work to be done in figuring out how to make the needed changes—for example, the way you find out a website’s private key to make HTTPS possible is being reworked to make room for larger signatures. Some technologies are just coming to market, like the post-quantum root of trust available now in some Chromebooks. In practice, this means that as you think about replacing your current devices in the next few years, you may want to check if you’re picking up hardware that has post-quantum support, if those specific protections are required for your threat model.

For the areas that still need updating, how much can we expect to actually get ready by the new deadline? It’s likely that not every cryptographically-capable device and deployment will be ready in time, and hardware with hard-coded certificates will probably be the last to update. We saw that happen when SHA-1 was deprecated; Point of Sale systems in particular were late adopters. While governments and large companies with quantum computers may not be interested in stealing money from cash registers, they will be interested in accessing secrets about people’s private lives. That’s why it’s so important that everyone does their part to upgrade, to protect the details of private communications and browsing. 

And there’s a good chance that older devices that won’t receive quantum-resistant updates were probably vulnerable to some other attack already. Quantum computation is just one type of attack on cryptography that’s notable for the scale of migration required, and how every public-key cryptosystem and authentication scheme has to do the work to prepare. That’s not a difference in kind, it’s a difference in scale, and some systems will inevitably be left behind.

Quantum preparedness hits different industries and services in different ways, but services that handle communications and financial information are particularly susceptible to risk, and need to act quickly to protect the privacy and security of billions of people.

The EU’s so-called Chat Control plan, which would mandate mass scanning and other encryption breaking measures, has had some good news lately. The most controversial idea, the forced requirement to scan encrypted messages, was given up by EU member states. And now, another win for privacy: the EU Parliament has dealt a real blow to voluntary mass-scanning of chats by voting to not prolong an interim derogation from e-Privacy rules in the EU. These rules allowed service providers, temporarily, to scan private communication.  

But no one should celebrate just yet. We said there is more to it, and voluntary scanning is a key part. Unlike in the U.S., where there is no comprehensive federal privacy law, the general and indiscriminate scanning of people’s messages is not legal in the EU without a specific legal basis. The e-Privacy derogation law, which gave (limited) cover for such activities, has now expired. Does that mean mass scanning will stop overnight?  

Not really. 

Companies have continued similar scanning practices during past gaps. Google, Meta, Microsoft, and Snap have already signaled in a joint statement to “continue to take voluntary action on our relevant Interpersonal Communication Services.” Whether this indicates continued scanning of our private communication is not entirely clear, but what is clear is that such activity would now risk breaching EU law. Then again, lack of compliance with EU data protection and privacy rules is nothing new for big tech in Europe. 

Most importantly, the “Chat Control” proposal for mandatory detection of child abuse material (CSAM) is still alive and being negotiated. It has shifted the focus toward so-called risk mitigation measures, such as problematic age verification and voluntary activities. If platforms are expected to adopt these as part of their compliance, they risk no longer being truly voluntary. While mass scanning may be gone on paper, some broader concerns remain.  

So, where does this leave us? The immediate priority is to make sure the expired exception for mass scanning is not revived. At the same time, lawmakers need to pull the teeth from the currently negotiated Chat Control proposal by narrowing risk mitigation measures. This means ensuring that age verification does not become a default requirement and “voluntary activities” are not turned into an expectation to scan our communications.   

As we said before, this is a zombie proposal. It keeps coming back and must not be allowed to return through the back door.