[iOS] Skip favicon fetch in Incognito to prevent Privacy Report leak [chromium/src : main]
Daiming Pan (Gerrit)
Message from Daiming Pan![]( "Open in Gerrit")
This CL fixes a privacy leak on iOS where Incognito browsing activity is visible in the iOS App Privacy Report (Settings > Privacy & Security > App Privacy Report).
Related details
- Sylvain Defresne
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Sylvain Defresne (Gerrit)
Sylvain Defresne added 2 comments![]( "Open in Gerrit")
I can accept this patch iff there is a plan to restore fetching the favicon for incognito mode, either by fixing `SharedURLLoaderFactory` for not recording the URL for incognito mode, or by not using `SharedURLLoaderFactory`.
But without plan, I don't think we should land the change as it breaks the application.
// See https://crbug.com/481074876.This breaks the favicon for incognito tabs.
I think instead `SharedURLLoaderFactory` should not log the request if the url is requested for incognito mode.
Related details
- Daiming Pan
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Daiming Pan (Gerrit)
Daiming Pan added 1 comment![]( "Open in Gerrit")
This breaks the favicon for incognito tabs.
I think instead `SharedURLLoaderFactory` should not log the request if the url is requested for incognito mode.
This breaks the favicon for incognito tabs.
I think instead `SharedURLLoaderFactory` should not log the request if the url is requested for incognito mode.
The issue is not that `SharedURLLoaderFactory` logs the request — it's that iOS App Privacy Report records all DNS requests made from the app process, regardless of the networking API used. There's no API to exclude specific requests from this logging. The only way to avoid it is to not make the request at all.
Re: "breaks favicon for incognito tabs" — Chromium already treats incognito favicons as non-persistent (won't save to DB, won't update mappings). The only thing we lose by not fetching is the in-session favicon display. I think this is an acceptable trade-off for a privacy leak that exposes visited domains in a user-facing system report.
However, I agree a follow-up to restore in-session favicons would be ideal. A possible approach: use WKWebView to fetch the favicon through the `nonPersistentDataStore` (which iOS doesn't log in Privacy Report), then pass the image data back to `WebFaviconDriver`. This would restore UX without the privacy leak. I'll file a follow-up bug for this.
Related details
- Sylvain Defresne
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Daiming Pan (Gerrit)
Daiming Pan added 1 comment![]( "Open in Gerrit")
Daiming PanThis breaks the favicon for incognito tabs.
I think instead `SharedURLLoaderFactory` should not log the request if the url is requested for incognito mode.
This breaks the favicon for incognito tabs.
I think instead `SharedURLLoaderFactory` should not log the request if the url is requested for incognito mode.
The issue is not that `SharedURLLoaderFactory` logs the request — it's that iOS App Privacy Report records all DNS requests made from the app process, regardless of the networking API used. There's no API to exclude specific requests from this logging. The only way to avoid it is to not make the request at all.
Re: "breaks favicon for incognito tabs" — Chromium already treats incognito favicons as non-persistent (won't save to DB, won't update mappings). The only thing we lose by not fetching is the in-session favicon display. I think this is an acceptable trade-off for a privacy leak that exposes visited domains in a user-facing system report.
However, I agree a follow-up to restore in-session favicons would be ideal. A possible approach: use WKWebView to fetch the favicon through the `nonPersistentDataStore` (which iOS doesn't log in Privacy Report), then pass the image data back to `WebFaviconDriver`. This would restore UX without the privacy leak. I'll file a follow-up bug for this.
Thanks for the feedback. I agree that completely disabling favicon fetch in incognito is not ideal.
To clarify the root cause: this isn't something SharedURLLoaderFactory can control — iOS App Privacy Report logs all DNS requests from the app process regardless of the networking API. There's no opt-out mechanism on the iOS side.
One possible workaround I'm considering: instead of fetching favicons from the app process, we could potentially fetch them through the WKWebView JS context (e.g. injecting a fetch() call and passing the image data back via message handler). Since WebKit process requests go through nonPersistentDataStore in incognito, iOS wouldn't log them in the Privacy Report. This way we could preserve favicon display without the privacy leak.
I haven't fully prototyped this yet, so I'd appreciate your thoughts on whether this direction makes sense before I invest more time. Would you be open to landing the current simple fix first and following up with the WKWebView-based approach?