When diagnosing bugzilla.redhat.com/show_bug.cgi?id=2457523 <https://bugzilla.redhat.com/show_bug.cgi?id=2457523#c0>, my prototyping was seriously slowed, because falkon-25.12.3-1.fc43’s omnibox doesn’t support data URIs, thereby requiring me to modify a shell command every time I wanted to access one.
On Tuesday, 5 June 2018 at 09:35:55 UTC+1 Philip Jägenstedt wrote: > Hi Jens, > > We understand that a change like this has the potential to cause pain for > users and web developers, and try to be thoughtful about it, in line with > our Blink principles of web compatibility > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?usp=sharing>, > > and balancing those risks against the upside, which was mainly security in > this case. > > Do you maintain a web site which was affected by this? Were you able to > find a workaround? > > On Tue, Jun 5, 2018 at 2:01 AM <[email protected]> wrote: > >> Why don't you just ask the user for permission like for geolocation and >> so on? Chrome team always decides what's best by blocking data-url, >> blocking audio, video autoplay etc. It's a big problem for many users and >> developers. >> >> On Thursday, 2 February 2017 03:47:55 UTC+2, Mustafa Emre Acer wrote: >>> >>> Primary eng (and PM) emails >>> >>> Eng: [email protected] >>> >>> PM: [email protected] >>> >>> Summary >>> >>> We intend to block web pages from loading data: URLs in the top frame >>> using <A> tags, window.open, window.location and similar mechanisms. >>> >>> Motivation >>> >>> data: URLs are generally a source of confusion for users. Because of >>> their unfamiliarity and ability to encode arbitrary untrusted content in a >>> URL, they are widely being used in spoofing and phishing attacks. Another >>> problem is that they can be passed along without a backing page that runs >>> JavaScript (e.g. a data URL can be sent via email). For that reason, we >>> intend to block top-frame navigations to data URLs. >>> >>> We are considering two alternative implementations: >>> >>> Alternative 1: >>> >>> Block only content initiated top-frame navigations to data URLs, while >>> still allowing direct navigations to them. Similar measures are already in >>> place for other schemes such as “chrome:”, “chrome-devtools:” and more >>> recently, “view-source: >>> <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/lyuWXZ_1kXo> >>> ”. >>> In practice, these will be blocked: >>> >>> - >>> >>> Navigations when the user clicks on links in the form of <A >>> HREF=”data:…”> >>> - >>> >>> window.open(“data:…”) >>> - >>> >>> window.location = “data:…” >>> - >>> >>> Meta redirects >>> >>> >>> The following will still be allowed: >>> >>> - >>> >>> User navigating to the URL by typing or pasting it in the omnibox >>> - >>> >>> Downloads from these protocols: >>> >>> >>> - >>> >>> Via non-browser-handled MIME types >>> - >>> >>> Via <A download> >>> - >>> >>> Via “Save link as” >>> >>> >>> Alternative 2: >>> >>> Block all top-frame navigations to data URLs. This only differs from (1) >>> in that it will additionally block direct navigations (“User navigating to >>> the URL by typing or pasting it in the omnibox”). >>> >>> In both cases, subresources with data URLs (e.g. <img src=”data:...”>, >>> <iframe src=”data:...”>) will be allowed. >>> >>> Pros of Approach 1: >>> >>> - >>> >>> Lower risk of breakage >>> >>> Cons of Approach 2: >>> >>> - >>> >>> Might be confusing to some users ("why does it work when I type the >>> address but not when I click the link?") >>> - >>> >>> We might end up playing whack-a-mole with edge cases where we don't >>> properly block the URLs >>> >>> >>> Pros of Approach 2: >>> >>> - >>> >>> Straightforward approach, consistent with IE/Edge behavior. >>> - >>> >>> Might be simpler to implement. >>> >>> Cons of Approach 2: >>> >>> - >>> >>> Higher risk of breakage >>> >>> >>> Compatibility Risk >>> >>> IE and Edge already block all top-frame navigations to data URLs. >>> Firefox and Safari allow them. >>> >>> If we implement (2), Chrome’s behavior will align with IE/Edge after >>> this change. >>> >>> The blocking will be similar to how chrome:// URLs are handled: >>> >>> - >>> >>> For same page navigations, clicking the link won’t do anything, and >>> a message will be displayed in the console. >>> - >>> >>> For navigations in other tabs or popups, the page will navigate to >>> about:blank instead. >>> - >>> >>> No event handlers will be triggered. >>> >>> >>> Alternative implementation suggestion for web developers >>> >>> The main use case for navigating to data URLs in the top frame is >>> generating files (HTML, PDF, images etc.) on the fly and displaying them to >>> the user. >>> >>> For that use case, these alternatives exist: >>> >>> - Generate the file on the backend and send it to the user over >>> http/https. >>> >>> - Initiate a download instead of displaying the URL. >>> >>> - If the contents of the URL is trusted, iframe the URL so that the >>> omnibox displays the site's URL. >>> >>> Usage information >>> >>> According to latest Stable Channel metrics over the last 28 days in >>> January 2017, data URLs are 0.05% of all top-frame navigations among all >>> platforms, and 0.01% of all navigations on Android. >>> >>> OWP launch tracking bug >>> >>> OWP tracking bug: https://crbug.com/684011 >>> >>> Discussion: https://crbug.com/594215 >>> >>> Entry on the feature dashboard <https://www.chromestatus.com/> >>> >>> https://www.chromestatus.com/feature/5669602927312896 >>> >>> Requesting approval to remove too? >>> >>> Yes, requesting approval to block top-frame navigations to data URLs. >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> > To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/163ed0ef-665d-41d4-92fd-20e1287c7b0a%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/163ed0ef-665d-41d4-92fd-20e1287c7b0a%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d1bd53d1-4ed3-4c6a-9544-16ac8bb67a9cn%40chromium.org.
