Drop allowFileAccessFromFileURLs and allowUniversalAccessFromFileURLs in VectorWebViewActivity and WidgetWebView#9145
Open
jim-daf wants to merge 1 commit into
Conversation
… in the two simple WebViews
VectorWebViewActivity (the 'simple' WebView used to open identity
server terms pages, SSO fallback URLs and similar links) and
WidgetWebView (the WebView that hosts Matrix widget integrations)
both turn on:
allowFileAccessFromFileURLs = true // @Suppress(DEPRECATION)
allowUniversalAccessFromFileURLs = true // @Suppress(DEPRECATION)
Both flags only take effect when the main frame is itself a file://
URL. VectorWebViewActivity is invoked via getIntent(context, url, ...)
and every call site that builds that intent supplies an http or https
URL. WidgetWebView is pointed at the widget's https URL. No call site
loads a file:// document into either WebView, so neither flag is
load-bearing for any existing path.
allowUniversalAccessFromFileURLs in particular lets a file:// page
XHR any origin, the classic CWE-200 sandbox escape, and is the reason
the AOSP API was deprecated. The @Suppress comments suggest the
deprecation warning was acknowledged but the flags themselves were
not re-evaluated.
Drop both lines in both files. Behaviour for the existing https
widget and link flows is unchanged. On pre-API-30 devices (where the
WebView defaults to true for both flags) this is a tightening rather
than a no-op.
|
|
This was referenced May 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Type: Bug fix
Issue: #9144
Motivation
Two WebView setup paths still toggle the deprecated
allowFileAccessFromFileURLsandallowUniversalAccessFromFileURLsflags even though neither WebView ever loads afile://main frame.VectorWebViewActivity
Invoked through
VectorWebViewActivity.getIntent(context, url, ...). Every call site that builds that intent supplies an http or https URL (identity-server terms pages, SSO fallback, etc.). The two flags only take effect on afile://main frame, so they do nothing for the actual launch paths.WidgetWebView
Widgets are served from the integration server's https widget URL. Same reasoning applies.
Content
Drop the
setAllowFileAccessFromFileURLs = trueandsetAllowUniversalAccessFromFileURLs = truelines in both files. Replace them with a short inline comment recording why neither flag is needed.allowUniversalAccessFromFileURLs = trueis the universal-XSS flag from theWebSettingsjavadoc (lets afile://page XHR any origin, CWE-200). It is unsafe to leave on as a safety margin if a future code path ever loads afile://document into one of these WebViews. The@Suppress("DEPRECATION")annotations on the removed lines suggest the deprecation warning was acknowledged but the flags were never re-evaluated.On pre-API-30 devices both flags default to
true, so removing the explicit= truelines is a tightening on those devices rather than a no-op only on API 30+.Provenance
Originally filed against the SchildiChat fork (SchildiChat/SchildiChat-android#284, #285). The maintainer asked me to file it upstream, so this PR is the upstream version.
Test plan
The change is two lines removed in each file plus a short comment. No other WebView setting touched. Both call paths continue to load their http/https URLs unchanged.
Checklist
changelog.d/9144.bugfix)