...@chromium.org ;
yoav...@chromium.org ; Bo Cupp ;
Scott Low ; gar...@chromium.org ;
dom...@chromium.org ; Anupam Snigdha
Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship:
Feature policy for Keyboard API
LGTM3, (but follow up with Dave about the implementation details, and make
iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3huSRtIRvPEdaKXk0FRkPNSHWNgxUEtAAqt%2BP3BgWpo%3D&reserved=0>,
>>
>> but will also create an issue to investigate Permissions API integration.
>> Thanks!
>>
>>
>>
>> *From:* Alex Russell
>> *Sent:* Th
>> *From:* Dave Tapuska
>> *Sent:* Wednesday, October 27, 2021 2:27 PM
>> *To:* Anupam Snigdha
>> *Cc:* slightly...@chromium.org; blink-dev@chromium.org;
>> yoavwe...@chromium.org; Bo Cupp ; Scott Low <
>> sc...@microsoft.com>; gary...@chromium.o
.com>; gary...@chromium.org; dome...@chromium.org
> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and
> Ship: Feature policy for Keyboard API
>
>
>
> I was looking at the implementation of this. Is it possible to move the
> check of the policy to be based in
rg
Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship:
Feature policy for Keyboard API
I was looking at the implementation of this. Is it possible to move the check
of the policy to be based in the browser when the map is fetched? As of right
now the policy enforcement
...@chromium.org ; Bo
> Cupp ; Scott Low ;
> gar...@chromium.org ; Domenic Denicola <
> dome...@chromium.org>
> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and
> Ship: Feature policy for Keyboard API
>
>
>
> Not consulting the TAG in this instanc
: Alex Russell
Sent: Thursday, October 21, 2021 12:21 PM
To: blink-dev
Cc: Yoav Weiss ; Anupam Snigdha ;
blin...@chromium.org ; Bo Cupp ;
Scott Low ; gar...@chromium.org ;
Domenic Denicola
Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship:
Feature policy for Keyboard API
Not consulting the TAG in this instance may have been an error. In general,
we should be putting things into consistent surfaces that they affect. In
this case, it seems like we're missing integrations w/ the Permissions API.
I'm LGTM2 on this intent contingent on a commitment to follow up w/ th
LGTM1
On Sat, Oct 16, 2021 at 12:35 AM Domenic Denicola
wrote:
> Just chiming in from the sidelines: in general I think this sort of
> exposure via permissions policies is a good thing, and should be encouraged.
>
> It shouldn't have any additional concerns for an API like this which is
> about
Just chiming in from the sidelines: in general I think this sort of
exposure via permissions policies is a good thing, and should be encouraged.
It shouldn't have any additional concerns for an API like this which is
about exposing information:
- Same-origin iframes can already call
top.nav
On Fri, Oct 15, 2021 at 5:45 AM Yoav Weiss wrote:
> Reading through https://wicg.github.io/keyboard-map/#privacy the only
> risk here is increased fingerprinting surface. Is that correct?
I don't believe this change (adding a permission policy) increases the
fingerprinting surface in a practica
getLayoutMap() can already be accessed by the top level browsing context and I
believe it does have fingerprinting concerns: a site can gain knowledge of the
keyboard layout of the user even before the user has typed anything. Try this
site switching between French and English keyboard layouts:
Reading through https://wicg.github.io/keyboard-map/#privacy the only risk
here is increased fingerprinting surface. Is that correct?
(aside - the privacy section states that the API is only available in
top-level contexts. You probably want to change that)
On Thursday, October 14, 2021 at 10:09
Can you clarify what the current situation is?
getLayoutMap() which is part of the Keyboard API can only be accessed in the
top browsing context which cuts off access from same and cross origin iframes.
With this permission policy based solution, the default value would be "Self"
that grants acce
14 matches
Mail list logo
