Hi Daniel,
We don't have any further details to announce right now, but when we do
we can update this thread.
thanks,
Mike
On 3/8/24 7:28 PM, Daniel Santiago Rincón Silva wrote:
Hi Brianna and team.
I see that the readme has been updated to specify that the feature
will be initially launch
Hi Brianna and team.
I see that the readme has been updated to specify that the feature will be
initially launched as an "opt-in setting in specific regions". Is there a
tentative timeline for this roll-out as well as the candidate regions? Also
will this roll-out still be limited to Google ser
Putting all other concerns aside, wouldn't this "ip protection" proxy allow
the owner/controllers of the proxies to decide what websites and content
the end user will and won't be allowed to access? Why is this problem not
listed with other concerns in any of the proposal write ups I have read?
LGTM, no concerns from me with experimenting. It seems like user and
enterprise controls are in place, and since this is just about proxying 3P
resources that reduces the risk of it impacting either site functionality
or network filtering policy.
Note that Chrome already has another (fully shipped
Hi Daniel,
You can read more about the Blink process for shipping features here:
https://www.chromium.org/blink/launching-features/
And yes, we do have plans for phase 0 and phase 1 experiments (and
possibly others, depending on what we learn in the process).
best,
Mike
On 10/24/23 2:00 PM,
Can you describe in more detail what are the steps that this proposal would
go through in order to be approved? Is there voting from the community that
needs to happen or internal Google decisions? Are the 'experimentation
phases' mentioned by Mike above the phase 0 and 1 mentioned in the other
What's the advantages / disadvantages of the IP Protection (formerly known
as Gnatcatcher) compared to something like the Tor browser?
On Tuesday, 24 October 2023 at 00:28:24 UTC+1 Mike Taylor wrote:
> Hi Eric,
>
> Sure - we will have more details about which domains will be proxied as we
> get
Hi Eric,
Sure - we will have more details about which domains will be proxied as
we get past the experimentation phases and sent an Intent to Ship.
thanks,
Mike
On 10/23/23 5:21 PM, Eric Browning wrote:
Please publish the domains this feature will use so that school and
district admins may b
Hi Pete,
Yes, users will be able to turn the feature off. See:
https://github.com/GoogleChrome/ip-protection/issues/16
https://support.google.com/chrome/a/answer/7679408?sjid=15843372962730454051-NA#upChromeBrsrX118
thanks,
Mike
On 10/23/23 3:21 PM, Pete Stergion wrote:
Will we be able to turn
Please publish the domains this feature will use so that school and
district admins may block it because of required governmental child safety
filtering concerns.
On Thursday, October 19, 2023 at 2:52:53 PM UTC-6 Brianna Goldstein wrote:
> Contact emails
>
> Brianna Goldstein, James Bradley, Da
Will we be able to turn this feature off once it rolled out or will it be
REQUIRED? The issue for us here at the Cornell University Library IT
department is that we have resources that we access by whitelisting domain
ip address/vlans to our ERM (Electronic Resource Mangement.) We do not want
t
Sure, the plan is to file one before any future I2S. But this isn't a
blocking concern for this first experiment, imho.
On 10/20/23 2:22 AM, Yoav Weiss wrote:
I think it makes sense to file a TAG review as FYI in the future
(non-blocking for this experiment) just to let the TAG know that this
As Harald mentioned, this is based on ongoing IETF work, but I think that
Mike's assessment is the relevant one: this is a choice that Chrome can
make without necessarily getting approval from anyone. Apple's iCloud
Private Relay is a very similar system that is well-known and favourably
viewed.
I think it makes sense to file a TAG review as FYI in the future
(non-blocking for this experiment) just to let the TAG know that this is
happening, as it changes things significantly when it comes to
fingerprinting data (by making other avenues of fingerprinting data more
valuable than they curren
standard naming rant can we call this "IP Address Protection"?
My initial read of the title was "Intellectual Property Protection", and I
opened it with a sense of dread expecting to find DRM-related stuff and a
long argument.
There are IETF efforts related to automatic relays (MASQUE, OHAI),
This is going to change observable network behavior, right? The TAG liases
with IETF, and if there aren't already active conversations in IETF about
this change, I worry that it will be received poorly.
On Thu, Oct 19, 2023, 7:15 PM Mike Taylor wrote:
> I'm recused from voting on this feature so
I'm recused from voting on this feature so with my API OWNER hat off (or
maybe just back and to the side to make me look cool...), it's possible
that we submit an FYI review in the future ahead of an I2S.
That said, this is a feature that arguably does not materially alter web
platform APIs, b
Why has the TAG not been consulted?
On Thu, Oct 19, 2023, 3:09 PM 'Brianna Goldstein' via blink-dev <
blink-dev@chromium.org> wrote:
> *Correction*:
> The link to the entry on the Chrome Platform Status was incorrect. Below
> is the corrected link
>
> https://chromestatus.com/feature/511146023924
*Correction*:
The link to the entry on the Chrome Platform Status was incorrect. Below is
the corrected link
https://chromestatus.com/feature/5111460239245312
On Thu, Oct 19, 2023 at 4:52 PM Brianna Goldstein
wrote:
> Contact emails
>
> Brianna Goldstein , James Bradley
> , David Schinazi
>
>
19 matches
Mail list logo