Meta’s €805M Italy Fine: Why Android Permissions Aren’t Consent

A single app-wide Android “Allow” button cannot serve as consent for a specific feature that reads your photo gallery.

On 14 November 2026 the Garante per la protezione dei dati personali, Italy’s data protection authority, announced an €805 million fine against Meta Platforms Ireland Limited. That is roughly $887 million at the exchange rate Reuters used, and the largest penalty the Italian regulator has ever imposed. It works out to about 0.47 percent of Meta’s global annual turnover, and the authority put the affected population at around 20 million Android users in Italy.

The trigger was a feature available since 2023 that surfaces photos and videos from a user’s own gallery as post suggestions while they scroll through Facebook, together with the way the app asked permission to read that gallery. No breach, leak, or AI scandal was involved.

Meta said it would appeal. A spokesperson told Reuters the company “strongly” disagreed with the authority’s assessment and called the fine “disproportionate,” adding: “This is a simple feature that helps people share photos and videos on Facebook. Users must grant permission on their device before the feature can operate, and they can change that permission at any time in their settings.”

Meta’s defense rests on the operating system having asked and the user having tapped “Allow.” The Garante’s position is that the operating system asked about device access, and that agreeing to that prompt is a different act from agreeing to a specific feature that reads your photo archive. The €805 million sits in the gap between those two readings, and every mobile engineering team building for European users should understand it.

What the Garante found about Facebook’s gallery suggestions

The investigation began in July 2025 after a complaint from the Centro Tutela Consumatori Utenti, the consumer protection centre in Bolzano. It rested on a technical analysis the authority ran itself rather than on Meta’s descriptions of the feature.

The feature is the one the Garante calls “Ottieni suggerimenti dalla galleria quando navighi su Facebook,” rendered in English reporting as “Get suggestions from gallery when browsing Facebook.” Meta’s help centre documents it as “camera roll suggestions when browsing Facebook.” The help page is candid about what it does: it “uses basic metadata from your device camera roll, such as when a photo was taken or if it was favorited, to suggest content for you to share while browsing,” and it says you “must first grant the Facebook app permission to access your photos in your device settings.” The toggle sits in the app’s account settings under Preferences, and you can also reach it while creating a post or story.

The regulator’s findings were specific:

1. Gallery access was requested through a single authorisation valid for the entire app and for several functions serving different purposes.
2. That authorisation was preceded by a generic notice about “enabling other features,” which did not tell the user that gallery suggestions were being switched on in the same grant.
3. The feature was enabled by default.

In the Garante’s words, once fully granted, “such authorisation allows the app to read the entire photo archive on the device, on an ongoing basis, without the user or the Authority being able to verify what information is actually being used.”

That last clause carries as much weight as the consent defect. The authority was describing an access surface that neither the person holding the phone nor the regulator could audit afterward, which goes beyond a dark pattern.

The Bolzano centre had raised the problem publicly before the investigation opened. In advice published on 11 July 2025 it quoted the in-app settings text, a cluster labelled “Suggerimenti da condividere provenienti dalla galleria.” The cluster bundles personalised, pre-edited creations with transitions, music and effects, plus the browsing-time prompts that are the subject of the fine. The centre told users to switch these options off and to check what permissions the Facebook app holds on their phone. Its director, Gunde Bauhofer, pointed to photos people never intend to share, “for various reasons, just think of photos of children,” and called it “simply appalling” that a company would “silently take the liberty of processing and editing these photos.” That settings cluster is the product-level version of what the Garante later found at the permission level: several functions with different purposes riding on one authorisation.

How Android’s media permissions made this possible

To see why a technically valid Android permission can still be legally inadequate as consent, it helps to follow how Android’s media access has evolved.

For years, an app that wanted the user’s photos declared READ_EXTERNAL_STORAGE, and one runtime grant gave read access across the shared storage volume. In practice that meant the whole camera roll, screenshots and downloads included. Android 13 (API level 33) replaced it, for apps targeting 33 or higher, with three media-type permissions: READ_MEDIA_IMAGES, READ_MEDIA_VIDEO and READ_MEDIA_AUDIO. READ_EXTERNAL_STORAGE ceased to have effect for those apps.

This was a real privacy gain, since an audio player no longer needed to ask for your photos. But the granularity stops at the media type. A grant of READ_MEDIA_IMAGES still authorises the app to read every image on the device, and the operating system has no concept of “only the images relevant to this one feature.”

At the implementation level, the gatekeeper is the MediaProvider module. It indexes shared storage into the MediaStore database and checks the calling app’s identity and permissions when it queries or opens a file. Once com.facebook.katana holds the relevant media permission, a ContentResolver query against MediaStore.Images returns the full set of images, and the app can open file descriptors for them. Enforcement happens at the level of the app and the media type, never the product feature that happens to be running.

The system cannot tell a user attaching one holiday photo to a message from a background routine enumerating the whole library to generate feed prompts, because both look identical to the permission check. That is the structural gap the Garante identified. It is a gap in the model, and no single app’s bug explains it.

Two details in Google’s documentation make the gap worse in practice.

• Combined dialogs. If an app requests READ_MEDIA_IMAGES and READ_MEDIA_VIDEO together, Android shows a single system dialog for both, so even the media-type granularity collapses into one tap at the moment of consent.
• Carry-forward grants. An app that previously held READ_EXTERNAL_STORAGE is automatically granted the corresponding READ_MEDIA_* permissions when the device or the app’s target SDK moves up. The Android 14 documentation spells out that a user who granted the old storage permission on Android 12 keeps full photo and video access after upgrading. A consent that was never specific to begin with therefore propagates across OS versions without anyone being asked again.

This is why the Garante treated the infringement as ongoing for users who had already granted the system authorisation, and why its remedial order reaches those existing grantees and not only new installs.

Does the gallery permission expose GPS location?

The metadata question is commonly overstated, so precision helps. The Garante found access to photos, videos and “related metadata,” and Meta’s help page confirms the feature uses basic metadata such as capture time and whether an item was favorited. Timestamps, file names, dimensions and camera model are readable through MediaStore and EXIF once a media permission is held.

Geolocation works differently. Since Android 10, scoped storage redacts location from media by default. An app that wants unredacted EXIF GPS coordinates must declare and be granted a separate ACCESS_MEDIA_LOCATION permission and call setRequireOriginal() on the URI. A gallery permission therefore does not freely hand over GPS coordinates. It exposes the entire visual archive and its non-location metadata, with location behind an additional, explicit grant. The legal problem does not depend on the GPS point, because under the rule the Garante applied, reading the archive at all is the trigger.

The current Facebook app is also no legacy artifact outside the modern regime. APKMirror’s metadata for a recent build lists the package as com.facebook.katana, with a minimum of Android 11 (API 30) and a target of Android 15 (API 35). Targeting 35 puts it inside the Android 14 partial-access behavior and Google Play’s photo and video permissions policy, so the more granular tools described below were available to it.

The Garante’s press release does not name the specific permission Facebook declared, and it does not need to. Its finding concerns the shape of the authorisation: one grant, whole app, many purposes, default on. The storage and media permission family produces exactly that shape.

Android Photo Picker and selected photos access: the tools Meta could have used

Android has spent several years building mechanisms that break up the all-or-nothing grant, which is why the design choice in this case looks consequential instead of inevitable.

The system Photo Picker shows the user’s library in an isolated system interface. The user taps the specific items they want to share, and the app receives temporary, read-only content:// URIs for just those items, with no storage or media runtime permission at all. Through the Jetpack PickVisualMedia and PickMultipleVisualMedia contracts in androidx.activity 1.7.0 and later, the picker works on Android 11 and above through Google’s modular system updates. A backported module is installable through Google Play services on Android 4.4 through 10 and on Android Go devices running 11 or 12. Where the picker is absent, the library falls back to the ACTION_OPEN_DOCUMENT intent.

By default the grant lasts only until the device restarts or the app stops, and an app that needs longer access must explicitly call takePersistableUriPermission(). Access is per selection, time-bounded, and visible to the user every time it happens, which is the opposite of a standing whole-library grant.

Selected Photos Access arrived in Android 14 for apps targeting API 34 or higher, backed by the READ_MEDIA_VISUAL_USER_SELECTED permission. It adds a “Select photos and videos” option beside “Allow all” and “Don’t allow.” When the user picks it, MediaStore queries return only the selected subset. Apps that maintain their own gallery are expected to adopt the new permission and handle re-selection. Apps that do not run in a compatibility mode where the partial grant behaves like a one-time permission, revoked when the app moves to the background or is killed. Either way the user decides the scope, and the scope can be a handful of images instead of twenty thousand.

Google Play policy now enforces this. The Photo and Video Permissions policy, introduced in October 2023, says apps targeting Android 13 or later may request READ_MEDIA_IMAGES and READ_MEDIA_VIDEO only if system pickers are not sufficient for the app’s core functionality. Full compliance became mandatory on 28 May 2025, and non-compliant apps can be removed from Google Play. Developers must submit a Play Console declaration justifying broad access, a custom in-app picker does not automatically qualify, and apps without a legitimate core use case must drop the permissions entirely. The policy’s own rationale is that broad access to shared media “is a vector for abuse.”

Apple got to a similar place earlier. iOS 14, in 2020, introduced a limited-photos mode and PHPickerViewController, which lets an app receive user-chosen items without any photo-library permission. Selection-based, purpose-scoped access has been the recommended pattern on both platforms for years.

The Garante does not cite any of this as its legal test, since the test is consent and API choice does not enter into it. It does show that a default-on feature riding on a whole-library grant was a design decision and no technical necessity.

Article 122 of the Italian Privacy Code: consent for device access

The fine rests on Article 122 of the Italian Privacy Code (Legislative Decree 196/2003), which transposes Article 5(3) of the EU ePrivacy Directive, 2002/58/EC as amended, and the GDPR’s general processing rules play a secondary role. The provision follows the device, and the data is secondary. Storing information on a user’s terminal equipment, or gaining access to information already stored there, is permitted only if the person has consented after being informed in simplified form. There are two exceptions:

• technical storage or access solely to carry out the transmission of a communication over an electronic communications network;
• access strictly necessary for a provider to deliver an information society service the user explicitly requested.

A 2021 addition, comma 2-bis, frames the same rule as a general prohibition on using an electronic communications network to access stored information, store information, or monitor the user’s operations, except as the consent clause allows. In this reading the smartphone belongs to the person’s private sphere, and the act of reading what it holds is the regulated event.

That explains the Garante’s insistence that the violation stands “regardless of whether the data is transmitted or any harm occurs.” The trigger is access to the terminal equipment, so it makes no difference whether the gallery content was processed entirely on the device, whether anything reached Meta’s servers, or whether any user suffered a demonstrable loss. It also makes no difference whether the information is personal data at all.

The Court of Justice of the European Union settled that point in Planet49 (C-673/17, 1 October 2019). It held that Article 5(3) refers to “the storing of information” and “the gaining of access to information already stored” without requiring that the information be personal data, and that the provision protects the user’s private sphere regardless. The same judgment held that consent must be an active, specific indication. A pre-ticked box is not consent, and clicking a button to enter a lottery is not consent to an unrelated tracking operation. The GDPR’s definition of consent, with its clear affirmative act, governs the ePrivacy standard.

Unsolicited gallery prompts shown while a user browses a feed are neither necessary to transmit network traffic nor a service the user explicitly requested at the moment of access. Neither exemption fits, which leaves consent that is freely given, specific, informed and unambiguous.

Measured against that standard, the three findings map onto three failures:

• A single authorisation covering several functions with different purposes is not specific.
• A generic “enable other features” notice does not inform the user that gallery suggestions are being activated.
• A feature that switches on by default once a broader permission is granted is not an unambiguous affirmative act directed at that feature.

A revocation toggle in settings does not cure the defect, because the law asks whether valid consent existed before the access, and the user’s ability to escape it later is a separate matter.

The sanction comes from Article 166 of the Privacy Code. Paragraph 2 subjects violations of Article 122 to the administrative fine in Article 83(5) of the GDPR, the tier that tops out at €20 million or 4 percent of total worldwide annual turnover, whichever is higher. Paragraph 3 confirms the Garante’s competence to impose that fine and the corrective measures in Article 58(2). At about 0.47 percent of turnover, the €805 million figure sits well below the 4 percent ceiling, which makes Meta’s “disproportionate” argument an uphill one.

In setting the amount, the authority weighed several factors:

• the scale of the affected population;
• the duration of the infringement, which it described as still ongoing for users who had not updated the app and for those who had already granted the system authorisation;
• a previous 2019 decision against the company;
• limited cooperation during the investigation.

It credited the changes Meta made after the complaint as a mitigating factor but discounted them as late and limited to users who update the app.

The 2019 precedent was a €1 million fine over the Cambridge Analytica matter, announced on 28 June 2019 under the pre-GDPR Privacy Code. The Garante found that 57 Italians had installed the Thisisyourdigitallife app and that the data of a further 214,077 Italian users had been acquired without their knowledge or consent, though it was not passed on to Cambridge Analytica itself. An €805 million penalty now follows a €1 million one, on a device-access theory instead of a data-misuse theory, which shows how far the enforcement posture has moved.

Why Ireland’s DPC can’t take over: ePrivacy has no one-stop-shop

Meta tried to move the case. It argued that Ireland’s Data Protection Commission, the lead supervisory authority for Meta Platforms Ireland under the GDPR’s one-stop-shop mechanism, should have handled the investigation, since Article 56 centralises cross-border enforcement in the member state of the controller’s main establishment.

The Garante rejected the objection on structural grounds: the ePrivacy rules provide no one-stop-shop, so each national authority enforces its own transposition. The position is well established. The European Data Protection Board’s Opinion 5/2019, adopted on 12 March 2019, treats the ePrivacy Directive as lex specialis to the GDPR and says the cooperation and consistency mechanisms in Chapter VII of the GDPR cover the monitoring and application of the GDPR and do not apply to enforcement of national ePrivacy rules. The same opinion notes that a supervisory authority enforcing ePrivacy does so through the tasks and powers national law gives it for that purpose, and cannot simply borrow its GDPR powers.

For multinational platforms the result is an uneven enforcement map. Backend processing of personal data may be coordinated through one lead regulator in Dublin or Luxembourg. Client-side behavior that touches the device remains directly exposed to any of the 27 national authorities acting under their own ePrivacy transpositions, with no consistency mechanism to harmonise the outcome. That covers gallery reads, local storage, SDK telemetry and tracking pixels.

The Garante has been building this doctrine steadily. In April 2026 it adopted guidelines applying the same Article 122 to tracking pixels in email, treating the silent loading of a pixel as access to the terminal equipment and giving operators until late October 2026 to comply. The Meta fine is the largest expression of that line. For compliance teams, centralising GDPR governance does not centralise device-access risk, and the consent design of a mobile feature is a per-market legal question even when the code ships worldwide from one repository.

What Meta must change: the Garante’s orders as an engineering spec

The remedial orders are unusually concrete and read like a specification for a consent architecture. Within 60 days Meta must:

• request consent through a separate, specific request for the gallery suggestions feature, explaining what the feature is for, that it involves access to the gallery, and how to disable it;
• keep the feature off by default, including for users who already granted the broader permission.

If the deadline passes without compliance, the feature cannot be activated for anyone who has not given valid consent. Meta must also report to the authority within 30 days on the initiatives it has undertaken and within 90 days on the measures it has adopted.

The theory behind the orders is ex ante and purpose-specific. The user must be asked about this feature as its own operation, the default state must be non-participation, and a previously granted device permission does not substitute.

In engineering terms, the orders force a separation the permission model does not provide on its own. The state gating the feature can no longer be “does the app hold a media permission,” because that state is shared across purposes, survives upgrades through the automatic grant behavior described earlier, and can be flipped in system settings without the user ever confronting the feature. It has to be a distinct, server-side consent record tied to the specific feature, defaulted to off, set only by an affirmative in-app choice after a clear explanation, and honored independently of the OS permission state.

Reaching existing grantees means a migration that resets the feature for everyone who previously allowed gallery access, in addition to a new onboarding flow for new users. Because the breach persists for users on old app versions, a client-only fix is insufficient. A server-side flag that disables the feature for non-consenting users on any build is the only way to satisfy the order across a fragmented install base. The 30- and 90-day reporting deadlines make the whole exercise an auditable programme where a quiet config change would otherwise suffice.

AI training and cloud processing: the question the Garante left open

One boundary in the decision is easily blurred in coverage. The Garante stated that the proceeding did not concern the possible use of gallery content to train AI models, a practice Meta denies. It also reserved the right to assess separately a newer feature, launched in 2026, that lets gallery content be processed in the cloud.

The split follows from the device-centric logic of Article 122 and from the EDPB’s two-step analysis. The ePrivacy rule governs access to the terminal equipment, and any processing of the personal data obtained that way needs its own basis under the GDPR. Unauthorised local access is enough to ground a very large fine by itself. Cloud ingestion and model training sit on a different regulatory track that the authority has explicitly kept open.

That track is not hypothetical for Meta. In June 2024 the company paused plans to train its models on public content from EU and EEA users after a wave of complaints coordinated by noyb and intensive engagement with the Irish Data Protection Commission, and the DPC later confirmed the pause in a public statement. The gallery case is separate from that controversy, and the Garante said so. Still, the reserved cloud-processing question signals that the authority intends to examine the newer feature on its own terms.

What happens next, and what developers should take away

Meta’s appeal will turn on legal characterisation more than on disputed facts. The company treats the device-level permission as the relevant act of authorisation and assumes that a grant through Android’s runtime model, revocable at any time in settings, satisfies the consent requirement whether or not the specific feature was presented separately. The Garante rejects that equivalence: a permission that bundles multiple purposes behind a generic notice and switches a feature on by default is not the specific, informed, unambiguous consent Article 122 demands for each purpose.

The appeal will also revisit the jurisdictional objection and the proportionality of the amount. The one-stop-shop argument runs against the settled EDPB position, and the fine sits far below the statutory ceiling. Whatever the Italian administrative courts decide, the corrective orders stay binding unless a court suspends them, so the 60-, 30- and 90-day clocks are already running.

The lesson reaches beyond Meta. Android’s permission model has moved from broad storage access to media-type permissions to per-selection and partial-access mechanisms, and each step has narrowed what an app can touch. The operating system still cannot tell whether a feature’s use of media falls within what the user understood themselves to be authorising. That understanding comes from the app’s prompts, their sequencing, their default states and their explanations, and the kernel plays no part in creating it.

A permission is a technical control. Consent is a legal act with a purpose attached, and one cannot stand in for the other. The Garante found a consent design that failed to connect a device-level grant to a specific gallery-reading feature in a way a user could understand and agree to. Its orders sketch the design that would pass: a separate and specific request, a clear explanation of purpose and gallery access, a default-off state, and an easy way to withdraw. Any team shipping a feature that reads the camera roll, contacts, or local storage on a European user’s phone should treat “the OS asked permission” as a much weaker defense than it once seemed.