LGTM3

On Mon, Mar 7, 2022 at 7:45 AM Mike Taylor <[email protected]> wrote:

> 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
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/82e3afc3-05c0-087b-61a8-98161d1cc98c%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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_uEsG3V15FxGQ9ygwOTPviXbvJWs3_TKqui7EodEFwjA%40mail.gmail.com.

Reply via email to