On Monday, March 7, 2022 at 3:47:11 PM UTC+1 Mike Taylor wrote:
> On 3/7/22 8:45 AM, Yoav Weiss wrote: > > On Mon, Mar 7, 2022 at 2:35 PM Arthur Sonzogni < > [email protected]> wrote: > >> >> >> We contacted several websites. Some confirmed they will be positively >>>> impacted. >>>> >>> Microsoft Teams, the #1 requested adding >>>> "allow-top-navigation-to-custom-scheme" to opt-out from this feature >>>> individually. >>>> >>> >>> It's reassuring to hear they'd be willing to use an opt-out. >>> Have you reached out to others on that list? It seems like tackling the >>> top ~3 would significantly reduce the risk. >>> >> >> I confirm I sent an email for every website we see: the top 8 on Windows >> and a few others on Android. I asked them to confirm reception. >> > Thanks - looking at the list, some of them seem to have obvious "open a > native app" use-cases, like Microsoft Teams. Others... not so obvious. > > If the primary motivation is to break malicious ads, would it make sense > to further require a secure context for the sandboxed iframe? (Maybe this > question is nonsense, I'm not a security expert). Do we know what the > breakdown is between http/non-secure and https/secure for iframes causing > these kinds of external app navigations? > Yes, this is probably worth doing. However, this would be a different topic, spec & impacted users. I think this would be more of an additional project, and ideally we would do both if possible. There are no metrics about security/non-secure context that I am aware of. > Please make sure you use CountDeprecation >>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/instrumentation/use_counter.h;l=45?q=Deprecation%20UseCounter&ss=chromium>, >>> >>> to get deprecation reports sent automatically. (unless there are particular >>> technical reasons that make this more complex than it should be. If that's >>> the case, let's discuss more) >>> >> >> This can't only be used in blink unfortunately. This is about navigation, >> and happens when we are out of handlers, before calling external >> applications. I can't make use of CountDeprecation here. It is not >> impossible to create new IPCs and get it plumbed to the renderer process, >> but that's probably more complex than what it deserves. >> > > That's probably true when considering only this particular intent, but > might be worthwhile to create the infra to enable this as this seems to be > a recurrent pattern. > > Agree it sounds like a useful tool to have down the road. I can't speak > for Yoav, but can we at least get a bug on file with enough context for > someone else to pick up? > That's the reasonable thing to do. Here is the bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1303603 -- 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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fcf7bcdf-aef4-4dcb-a21b-6b5c1c5727fan%40chromium.org.
