On 3/7/22 10:37 AM, Arthur Sonzogni wrote:
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.
OK, thanks for confirming (not trying to blow up your scope in this
intent, I promise).
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
Thanks, LGTM2.
--
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/82e3afc3-05c0-087b-61a8-98161d1cc98c%40chromium.org.
