Error with permissions policy header origin trial controlled feature not enabled interest cohort

Что такое когорты Google (FLoC), безопасна ли эта технология и чем отличается от Cookies

Когорты Google – это всего лишь группы, которые формируются по определенным предпочтениям. В отличии от ориентации под одного пользователя, подбирать контент под группу пользователей гораздо проще. Это может использоваться в рекламных целях, что и было сделано компанией Google – была представлена технология FLoC (Federated Learning of Cohorts).

Данная технология внедряется в современные версии браузеров от Google (Chrome), пока это носит характер тестирования. Как работает FLoC? Пользователь при посещении какой-либо страницы сайта оставляет в браузере историю, на основе которой браузер относит данного пользователя к какой-либо группе такой же тематики. Такие группы имеют свои идентификаторы (Groupe ID) – данные хранятся на стороне клиента, а также отсылаются на сервера обработки.

Однако у такой технологии есть свои недостатки в плане безопасности и приватности личных предпочтений. Как раз об этом заявили прочие разработчики браузеров, таких как Firefox, Opera и т.д. Ведь существует потенциальная возможность вычислить пользователя, узнать его предпочтения, к каким он группам принадлежит. Всё это делает его личные предпочтения мишенью для злоумышленников, так как можно вычислить интересы пользователя и уже исходя из них совершать атаки.

Отличия технологии FLoC от Cookie совершенно очевидны, Cookie хранятся лишь в браузере и при правильном использовании отвечают базовым нормам безопасности пользователя. В то время как зачисление пользователя в когорту (группу) и последующая отправка такой информации партнерам и различным компаниям очевидно не самый безопасный способ персонализации контента и функционала сайта.

Могут возникать ошибки при работе с FLoC, например, ошибка:

Error with Permissions-Policy header: Unrecognized feature: ‘interest-cohort’ (Ошибка с заголовком политики разрешений: неизвестный объект: когорта интересов).

Это значит, что необходимо пересмотреть настройки сайта, добавить правильные условия отправки заголовков и т.д. Также не стоит забывать о совместимости FLoC с разными браузерами, так как технология новая.

Источник

I am getting console log warnings after activating the plugin:

and then the following error which I believe is related:

Error with Permissions-Policy header: Parse of permissions policy failed because of errors reported by structured header parser.

WordPress Version 6.0
WPEngine hosting
Headers Security Advanced & HSTS WP Version 4.8.88
Present on both Firefox & Chrome/Webkit

Any insight is greatly appreciated! Thanks!

Hi @dankfresh, Thank you for installing Headers Security Advanced & HSTS WP.

I am Andrea and I will help you solve the issue you encountered as best as possible.

I will start internal audits and as soon as I finish I will contact you to update you with the solution.

Please help me with this
Every plugin is updated.
Checked with multiple theme same error displaying is Console.

Error with Feature-Policy header: Unrecognized feature: ‘geolocation=(self’.
Error with Feature-Policy header: Unrecognized feature: ‘microphone=()’.
Error with Feature-Policy header: Unrecognized feature: ‘accelerometer=()’.
Error with Feature-Policy header: Unrecognized feature: ‘gyroscope=()’.
Error with Feature-Policy header: Unrecognized origin: ‘(self’.
Error with Feature-Policy header: Unrecognized feature: ‘push=()’.
Error with Feature-Policy header: Unrecognized feature: ‘vibrate=()’.
Error with Feature-Policy header: Unrecognized feature: ‘magnetometer=()’.
Error with Feature-Policy header: Unrecognized feature: ‘interest-cohort=()’.

Error with Permissions-Policy header: Origin trial controlled feature not enabled: ‘interest-cohort’.

• This reply was modified 7 months, 3 weeks ago by prash009 .

Hi @prash009 and @dankfresh, Thank you for installing the Headers Security advanced & HSTS WP plugin.

After your report I did some verification and testing, we have just released a new plugin update (version 4.8.89) this will fix the issue found in the console log.

Also if you need further assistance I will be at your disposal as soon as possible.

That update did the trick! With how often policies and security header compliance changes, I imagine it is difficult keeping up. I appreciate the effort in developing this plugin and the quick turnaround. Thanks!

Hi @dankfresh, thank you for the feedback 🙂 thanks for using Headers Security Advanced & HSTS WP.

We are trying to offer the best assistance in a short time and I hope you enjoyed it, but most importantly it was helpful.

We always try to optimize the plugin and release patches with new headers or improvement for the plugin in short time.

Thank you for your feedback and should you need support be here.

You can leave us a review to rate the support and the plugin.

Источник

Joomla! Issue Tracker — CMS

[#33212] — [3.9][Privacy] Block usage of FLoC by default

Pending

User tests: Successful: Unsuccessful:

Issue

As a replacement for third party cookies, Google has introduced the Federated Learning of Cohorts into the Chrome browser lately. This feature is supposed to allow better tracking of users while also keeping data privacy. Details can be read here. The Joomla! project disagrees that this feature is in the interests of the owners of Joomla!-powered websites as well as their visitors. We share the assessment of the EFF as well as many other organisations (Mozilla, Microsoft, Opera, WordPress).

We consider this a security issue and thus will roll out countermeasures with the next bugfix release of the Joomla 3.9 series.

Summary of Changes

This PR introduces a header to disable Federated Learning of Cohorts, which is sent with every request that is handled by the Joomla framework. The header specifically looks like this:
Permissions-Policy: interest-cohort=()
and is the equivalent of opting out of this feature. Please be aware that this only adds this header to requests which go through the Joomla! application. Assets like CSS files, images or javascript are handled by your webserver directly and we would advise to modify the webserver to add this header to every request directly.

If you really want to disable the blocking of this feature, we added a switch in the global configuration to remove this header.

A postinstall message has been added to the database to inform administrators of this decision.

Testing Instructions

Apply this patch and load a random page of your testing site. The answer to your request should contain the above noted header.

Documentation Changes Required

Handling of this in the future

This PR fixes this issue for the 3.9 and 3.10 releases. We will decide on how to implement this countermeasure in 4.0 in the time before the final release.

We will decide on how to implement this countermeasure in 4.0 in the time before the final release.

Assets like CSS files, images or javascript are handled by your webserver directly and we would advise to modify the webserver to add this header to every request directly.

Should we also be putting this in htaccess.txt like the other headers like no-sniff? This would then apply the header globally and not only on PHP requests through the app.

«Google is introducing a replacement. «

Should the language be written time independently, so that in a decade it is still true? Maybe something like «In 2021, Google introduced. «

We will decide on how to implement this countermeasure in 4.0 in the time before the final release.

Agreed, we are just still discussing about that. We definitely don’t want the above special case to live on in J4.

Assets like CSS files, images or javascript are handled by your webserver directly and we would advise to modify the webserver to add this header to every request directly.

Should we also be putting this in htaccess.txt like the other headers like no-sniff? This would then apply the header globally and not only on PHP requests through the app.

Maybe, however since most people don’t update their htaccess on a Joomla update, we can’t rely on this alone. Be my guest to add this header to the htaccess.

«Google is introducing a replacement. «

Should the language be written time independently, so that in a decade it is still true? Maybe something like «In 2021, Google introduced. «

I’m happy to accept a changed text PR to this branch.

Agreed, but the htaccess is still the right place for this also to be, over and above this PR. Just thought you might like to add it here for completeness.

I’m happy to accept a changed text PR to this branch.

haha that’s @brianteeman domain 🙂 I only speak crap.

Maybe, however since most people don’t update their htaccess on a Joomla update, we can’t rely on this alone. Be my guest to add this header to the htaccess.

Also need to check if .htaccess has this header, and Joomla outputs this header, do they resolve to a single header, or to two separate duplicated headers in the response — need to test that first.

Such a shame that the project doesn’t take the use of cookies as seriously

Maybe, however since most people don’t update their htaccess on a Joomla update, we can’t rely on this alone. Be my guest to add this header to the htaccess.

Also need to check if .htaccess has this header, and Joomla outputs this header, do they resolve to a single header, or to two separate duplicated headers in the response — need to test that first.

Header has been set in htaccess.txt as well. Testing on my system only showed one header to be sent.

Update SQL scripts for PostgreSQL and for MS SQL Server/SQL Azure are missing.

Have been added. Sorry, it was late yesterday.

Such a shame that the project doesn’t take the use of cookies as seriously

Since J4 has already the system_httpheader and @zero-24 already did the backport for J3 https://github.com/zero-24/plg_system_httpheader why don’t you merge that to J3 (assuming that @zero-24 has no objections)?

Was consideration given to implement this as a standalone Plugin instead of «yet another» configuration option?

Was consideration given to the Post Installation message, to have «condition» for showing only if not enabled in global config and «a one click action» to implement the change like the 2FA and the Load Balancer change recently?

Since J4 has already the system_httpheader and @zero-24 already did the backport for J3 zero-24/plg_system_httpheader why don’t you merge that to J3 (assuming that @zero-24 has no objections)?

Was consideration given to implement this as a standalone Plugin instead of «yet another» configuration option?

It was decided to keep the implementation minimal and to not use a separate plugin.

Was consideration given to the Post Installation message, to have «condition» for showing only if not enabled in global config and «a one click action» to implement the change like the 2FA and the Load Balancer change recently?

This feature is enabled by default, so people would need to disable it actively. In that case they can also click away the post install message.

We consider this a security issue and thus will roll out countermeasures

This has nothing to do with security, add it in J4 (default off), but don’t force this in J3 in the name of security. At best this is a privacy concern (in the browser).

I see that Joomla is trying to not fall behind WP but please note that WP is NOT including this feature in its code, despite what the tech press misguidedly reported.

Moreover, this is not a definite security or privacy issue. Please do read https://twitter.com/Log3overLog2/status/1384337637763387394 for the whole story. In short, FLoC is only a concern if you include JavaScript which explicitly requests the FLoC cohort. Moreover, FLoC is currently an experiment, not a final implementation. In the few Chrome browsers this experiment is enabled — notably none in the EU, where the author of this PR lives — this is currently an opt-out feature just because it’s the only way to run an experiment of a technology nobody has heard about before. Google seems to indicate that the final implementation is very likely to be opt-in, not opt-out, or at the very least provide a user warning the same way that asking for location data does. It is, in fact, extremely likely to be so because of GDRP and that’s probably why the opt-out format experiment does not run in browsers of EU residents.

Further to that, this has NOTHING AT ALL to do with security. Your site can’t be hacked with FLoC. Maybe — MAYBE — it will have to do with privacy IF AND ONLY IF the final implementation of FLoC is opt-out instead of opt-in. Marking it as a security concern dilutes the importance of fixing real security issues and projects the wrong message to users. If we label speculative, non-security issues as «SECURITY» the users are trained to ignore any security fix as superficial and unimportant, undermining their safety in the long term.

On top of that, sending a Permissions-Policy to disable FLoC doesn’t mean that the user will magically no longer be tracked. In fact, it’s possible that instead of being assigned into a cohort of at least 1000 users he will be otherwise tracked and placed in a finer grained cohort using a different set of tracking technologies including but not limited to ISP detection, IP geolocation, per-user subdomain pinging and so on. FLoC was actually designed to strengthen the privacy by making cohorts large enough so as not to allow individual tracking and deanonymisation. Whether we trust Google to do that is a largely philosophical question, not a technical one. From a technical perspective using the Permissions-Policy might actually prove counter-productive to the stated goal of protecting the user’s privacy.

It is also worth noting that FLoC is only ever enabled if you include JavaScript in your page which uses FLoC (either directly on the page or via an IFRAME). This means that unless you are using analytics, ads or similar technology which uses FLoC-enabled JavaScript there is no placement in a cohort. Pretending that merely using Chrome on any site is magically destroying your privacy is misguided at best.

Based on this, there is no real benefit in including this in Joomla, let alone as a feature enabled by default. We are not protecting anyone from anything, especially the site owner i.e. it’s not a «security» feature. What this feature does is probably disable FLoC if you are using third party ads, analytics etc on your site. Whether it will succeed depends entirely on the implementation. If a third party ad is included in your site via an IFRAME it’s easy for it to add the allow=»interest-cohort» in the attribute, nullifying this «protection». It would only work if the FLoC-enabled third-party JS only ever runs in the main page context on your site. Even then, whether it would be something that actually protects your users instead of enabling more tracking for them is something to be determined. Not to mention that we still do not know if Chrome will make it opt-in or display a warning before interest cohorts are used, especially in jurisdictions with strict personally identifiable information legislation.

In short, this PR jumps the shark by a freaking mile.

Finally, the implementation as it stands right now is completely wrong and breaks sites. It replaces the Permissions-Policy header instead of amending it. People who use plugins to set the Permissions-Policy for legal compliance, privacy or security reasons will be very surprised to see that their Permissions-Policy is overwritten and replaced with a BS non-fix of a speculative issue. So, while nothing (or at the very least nothing of importance) is fixed something of actual importance is broken for them! A better way to do it is more like along these lines (from a PR in Admin Tools Professional I have not merged yet for the reasons stated above):

While this won’t overwrite a permissions policy set by a plugin — including Joomla 4’s core feature — it’s still mostly window dressing because it can and will be overwritten by .htaccess or equivalent server-level code if it sets the Permissions-Policy header and can and will be overwritten by IFRAME attributes. As we say in Greece, this is very much like drilling holes in the water.

It’s important to get all the facts straight before jumping the gun and implementing something under a false security banner, even more so when the implementation is plain bad code that breaks another core feature.

Источник

Joomla! Issue Tracker — CMS

[#33212] — [3.9][Privacy] Block usage of FLoC by default

Pending

User tests: Successful: Unsuccessful:

Issue

As a replacement for third party cookies, Google has introduced the Federated Learning of Cohorts into the Chrome browser lately. This feature is supposed to allow better tracking of users while also keeping data privacy. Details can be read here. The Joomla! project disagrees that this feature is in the interests of the owners of Joomla!-powered websites as well as their visitors. We share the assessment of the EFF as well as many other organisations (Mozilla, Microsoft, Opera, WordPress).

We consider this a security issue and thus will roll out countermeasures with the next bugfix release of the Joomla 3.9 series.

Summary of Changes

This PR introduces a header to disable Federated Learning of Cohorts, which is sent with every request that is handled by the Joomla framework. The header specifically looks like this:
Permissions-Policy: interest-cohort=()
and is the equivalent of opting out of this feature. Please be aware that this only adds this header to requests which go through the Joomla! application. Assets like CSS files, images or javascript are handled by your webserver directly and we would advise to modify the webserver to add this header to every request directly.

If you really want to disable the blocking of this feature, we added a switch in the global configuration to remove this header.

A postinstall message has been added to the database to inform administrators of this decision.

Testing Instructions

Apply this patch and load a random page of your testing site. The answer to your request should contain the above noted header.

Documentation Changes Required

Handling of this in the future

This PR fixes this issue for the 3.9 and 3.10 releases. We will decide on how to implement this countermeasure in 4.0 in the time before the final release.

We will decide on how to implement this countermeasure in 4.0 in the time before the final release.

Assets like CSS files, images or javascript are handled by your webserver directly and we would advise to modify the webserver to add this header to every request directly.

Should we also be putting this in htaccess.txt like the other headers like no-sniff? This would then apply the header globally and not only on PHP requests through the app.

«Google is introducing a replacement. «

Should the language be written time independently, so that in a decade it is still true? Maybe something like «In 2021, Google introduced. «

We will decide on how to implement this countermeasure in 4.0 in the time before the final release.

Agreed, we are just still discussing about that. We definitely don’t want the above special case to live on in J4.

Assets like CSS files, images or javascript are handled by your webserver directly and we would advise to modify the webserver to add this header to every request directly.

Should we also be putting this in htaccess.txt like the other headers like no-sniff? This would then apply the header globally and not only on PHP requests through the app.

Maybe, however since most people don’t update their htaccess on a Joomla update, we can’t rely on this alone. Be my guest to add this header to the htaccess.

«Google is introducing a replacement. «

Should the language be written time independently, so that in a decade it is still true? Maybe something like «In 2021, Google introduced. «

I’m happy to accept a changed text PR to this branch.

Agreed, but the htaccess is still the right place for this also to be, over and above this PR. Just thought you might like to add it here for completeness.

I’m happy to accept a changed text PR to this branch.

haha that’s @brianteeman domain 🙂 I only speak crap.

Maybe, however since most people don’t update their htaccess on a Joomla update, we can’t rely on this alone. Be my guest to add this header to the htaccess.

Also need to check if .htaccess has this header, and Joomla outputs this header, do they resolve to a single header, or to two separate duplicated headers in the response — need to test that first.

Such a shame that the project doesn’t take the use of cookies as seriously

Maybe, however since most people don’t update their htaccess on a Joomla update, we can’t rely on this alone. Be my guest to add this header to the htaccess.

Also need to check if .htaccess has this header, and Joomla outputs this header, do they resolve to a single header, or to two separate duplicated headers in the response — need to test that first.

Header has been set in htaccess.txt as well. Testing on my system only showed one header to be sent.

Update SQL scripts for PostgreSQL and for MS SQL Server/SQL Azure are missing.

Have been added. Sorry, it was late yesterday.

Such a shame that the project doesn’t take the use of cookies as seriously

Since J4 has already the system_httpheader and @zero-24 already did the backport for J3 https://github.com/zero-24/plg_system_httpheader why don’t you merge that to J3 (assuming that @zero-24 has no objections)?

Was consideration given to implement this as a standalone Plugin instead of «yet another» configuration option?

Was consideration given to the Post Installation message, to have «condition» for showing only if not enabled in global config and «a one click action» to implement the change like the 2FA and the Load Balancer change recently?

Since J4 has already the system_httpheader and @zero-24 already did the backport for J3 zero-24/plg_system_httpheader why don’t you merge that to J3 (assuming that @zero-24 has no objections)?

Was consideration given to implement this as a standalone Plugin instead of «yet another» configuration option?

It was decided to keep the implementation minimal and to not use a separate plugin.

Was consideration given to the Post Installation message, to have «condition» for showing only if not enabled in global config and «a one click action» to implement the change like the 2FA and the Load Balancer change recently?

This feature is enabled by default, so people would need to disable it actively. In that case they can also click away the post install message.

We consider this a security issue and thus will roll out countermeasures

This has nothing to do with security, add it in J4 (default off), but don’t force this in J3 in the name of security. At best this is a privacy concern (in the browser).

I see that Joomla is trying to not fall behind WP but please note that WP is NOT including this feature in its code, despite what the tech press misguidedly reported.

Moreover, this is not a definite security or privacy issue. Please do read https://twitter.com/Log3overLog2/status/1384337637763387394 for the whole story. In short, FLoC is only a concern if you include JavaScript which explicitly requests the FLoC cohort. Moreover, FLoC is currently an experiment, not a final implementation. In the few Chrome browsers this experiment is enabled — notably none in the EU, where the author of this PR lives — this is currently an opt-out feature just because it’s the only way to run an experiment of a technology nobody has heard about before. Google seems to indicate that the final implementation is very likely to be opt-in, not opt-out, or at the very least provide a user warning the same way that asking for location data does. It is, in fact, extremely likely to be so because of GDRP and that’s probably why the opt-out format experiment does not run in browsers of EU residents.

Further to that, this has NOTHING AT ALL to do with security. Your site can’t be hacked with FLoC. Maybe — MAYBE — it will have to do with privacy IF AND ONLY IF the final implementation of FLoC is opt-out instead of opt-in. Marking it as a security concern dilutes the importance of fixing real security issues and projects the wrong message to users. If we label speculative, non-security issues as «SECURITY» the users are trained to ignore any security fix as superficial and unimportant, undermining their safety in the long term.

On top of that, sending a Permissions-Policy to disable FLoC doesn’t mean that the user will magically no longer be tracked. In fact, it’s possible that instead of being assigned into a cohort of at least 1000 users he will be otherwise tracked and placed in a finer grained cohort using a different set of tracking technologies including but not limited to ISP detection, IP geolocation, per-user subdomain pinging and so on. FLoC was actually designed to strengthen the privacy by making cohorts large enough so as not to allow individual tracking and deanonymisation. Whether we trust Google to do that is a largely philosophical question, not a technical one. From a technical perspective using the Permissions-Policy might actually prove counter-productive to the stated goal of protecting the user’s privacy.

It is also worth noting that FLoC is only ever enabled if you include JavaScript in your page which uses FLoC (either directly on the page or via an IFRAME). This means that unless you are using analytics, ads or similar technology which uses FLoC-enabled JavaScript there is no placement in a cohort. Pretending that merely using Chrome on any site is magically destroying your privacy is misguided at best.

Based on this, there is no real benefit in including this in Joomla, let alone as a feature enabled by default. We are not protecting anyone from anything, especially the site owner i.e. it’s not a «security» feature. What this feature does is probably disable FLoC if you are using third party ads, analytics etc on your site. Whether it will succeed depends entirely on the implementation. If a third party ad is included in your site via an IFRAME it’s easy for it to add the allow=»interest-cohort» in the attribute, nullifying this «protection». It would only work if the FLoC-enabled third-party JS only ever runs in the main page context on your site. Even then, whether it would be something that actually protects your users instead of enabling more tracking for them is something to be determined. Not to mention that we still do not know if Chrome will make it opt-in or display a warning before interest cohorts are used, especially in jurisdictions with strict personally identifiable information legislation.

In short, this PR jumps the shark by a freaking mile.

Finally, the implementation as it stands right now is completely wrong and breaks sites. It replaces the Permissions-Policy header instead of amending it. People who use plugins to set the Permissions-Policy for legal compliance, privacy or security reasons will be very surprised to see that their Permissions-Policy is overwritten and replaced with a BS non-fix of a speculative issue. So, while nothing (or at the very least nothing of importance) is fixed something of actual importance is broken for them! A better way to do it is more like along these lines (from a PR in Admin Tools Professional I have not merged yet for the reasons stated above):

While this won’t overwrite a permissions policy set by a plugin — including Joomla 4’s core feature — it’s still mostly window dressing because it can and will be overwritten by .htaccess or equivalent server-level code if it sets the Permissions-Policy header and can and will be overwritten by IFRAME attributes. As we say in Greece, this is very much like drilling holes in the water.

It’s important to get all the facts straight before jumping the gun and implementing something under a false security banner, even more so when the implementation is plain bad code that breaks another core feature.

Источник

Что такое когорты Google (FLoC), безопасна ли эта технология и чем отличается от Cookies

Когорты Google – это всего лишь группы, которые формируются по определенным предпочтениям. В отличии от ориентации под одного пользователя, подбирать контент под группу пользователей гораздо проще. Это может использоваться в рекламных целях, что и было сделано компанией Google – была представлена технология FLoC (Federated Learning of Cohorts).

Данная технология внедряется в современные версии браузеров от Google (Chrome), пока это носит характер тестирования. Как работает FLoC? Пользователь при посещении какой-либо страницы сайта оставляет в браузере историю, на основе которой браузер относит данного пользователя к какой-либо группе такой же тематики. Такие группы имеют свои идентификаторы (Groupe ID) – данные хранятся на стороне клиента, а также отсылаются на сервера обработки.

Однако у такой технологии есть свои недостатки в плане безопасности и приватности личных предпочтений. Как раз об этом заявили прочие разработчики браузеров, таких как Firefox, Opera и т.д. Ведь существует потенциальная возможность вычислить пользователя, узнать его предпочтения, к каким он группам принадлежит. Всё это делает его личные предпочтения мишенью для злоумышленников, так как можно вычислить интересы пользователя и уже исходя из них совершать атаки.

Отличия технологии FLoC от Cookie совершенно очевидны, Cookie хранятся лишь в браузере и при правильном использовании отвечают базовым нормам безопасности пользователя. В то время как зачисление пользователя в когорту (группу) и последующая отправка такой информации партнерам и различным компаниям очевидно не самый безопасный способ персонализации контента и функционала сайта.

Могут возникать ошибки при работе с FLoC, например, ошибка:

Error with Permissions-Policy header: Unrecognized feature: ‘interest-cohort’ (Ошибка с заголовком политики разрешений: неизвестный объект: когорта интересов).

Это значит, что необходимо пересмотреть настройки сайта, добавить правильные условия отправки заголовков и т.д. Также не стоит забывать о совместимости FLoC с разными браузерами, так как технология новая.

Источник

Когорты Google – это всего лишь группы, которые формируются по определенным предпочтениям. В отличии от ориентации под одного пользователя, подбирать контент под группу пользователей гораздо проще. Это может использоваться в рекламных целях, что и было сделано компанией Google – была представлена технология FLoC (Federated Learning of Cohorts).

Данная технология внедряется в современные версии браузеров от Google (Chrome), пока это носит характер тестирования. Как работает FLoC? Пользователь при посещении какой-либо страницы сайта оставляет в браузере историю, на основе которой браузер относит данного пользователя к какой-либо группе такой же тематики. Такие группы имеют свои идентификаторы (Groupe ID) – данные хранятся на стороне клиента, а также отсылаются на сервера обработки.

Однако у такой технологии есть свои недостатки в плане безопасности и приватности личных предпочтений. Как раз об этом заявили прочие разработчики браузеров, таких как Firefox, Opera и т.д. Ведь существует потенциальная возможность вычислить пользователя, узнать его предпочтения, к каким он группам принадлежит. Всё это делает его личные предпочтения мишенью для злоумышленников, так как можно вычислить интересы пользователя и уже исходя из них совершать атаки.

Отличия технологии FLoC от Cookie совершенно очевидны, Cookie хранятся лишь в браузере и при правильном использовании отвечают базовым нормам безопасности пользователя. В то время как зачисление пользователя в когорту (группу) и последующая отправка такой информации партнерам и различным компаниям очевидно не самый безопасный способ персонализации контента и функционала сайта.

Могут возникать ошибки при работе с FLoC, например, ошибка:

Error with Permissions-Policy header: Unrecognized feature: ‘interest-cohort’ (Ошибка с заголовком политики разрешений: неизвестный объект: когорта интересов).

Это значит, что необходимо пересмотреть настройки сайта, добавить правильные условия отправки заголовков и т.д. Также не стоит забывать о совместимости FLoC с разными браузерами, так как технология новая.

Время прочтения
4 мин

Просмотры 12K

Google недавно объявил о развертывании технологии Federated Learning of Cohorts (FLoC) в рамках инициативы Privacy Sandbox, направленной на замену сторонних файлов cookie новым методом профилирования пользователей, который собирает данные, генерируемые непосредственно браузером.

Организация Electronic Frontier Foundation (EFF) выпустила обзор FLoC и связанных с ним угроз, а также разработала полезный инструмент для проверки, используется ли браузер пользователя для сбора данных и снятия цифрового отпечатка устройства. 

Примечания: EFF отмечают, что вместо устранение проблемы, Google создает новые. Если любой сайт сможет получить данные о когортах, возникнут условия для предварительной жесткой фильтрации целых групп пользователей, исходя из обобщенных предпочтений. Среди новых рисков также выделяют появление фактора для более интенсивного использования методов косвенной идентификации пользователя(browser fingerprinting), использующих специфичные настройки и особенности оборудования.

Plausible Analytics также присоединился к статье, в которой объясняется, какое отношение FLoC имеет к пользователям и разработчикам.  — что послужило источником вдохновения для этого краткого руководства.

Заголовок FLoC

Основной способ, с помощью которого конечный пользователь может избежать FLoC, — это просто не использовать Chrome, а вместо этого выбрать браузер, уважающий конфиденциальность, например Mozilla Firefox. 

Но владельцы веб-сайтов также могут гарантировать, что их веб-серверы не участвуют в этой огромной сети, отказавшись от FLoC.

Для этого необходимо добавить следующий кастомный заголовок HTTP-ответа:

Permissions-Policy: interest-cohort=()

В этом руководстве вы найдете инструкции о том, как добавить кастомные заголовки HTTP-ответов в конфигурации веб-серверов и прокси-серверов.

NGINX

Добавьте в файл конфигурации NGINX следующее:

# /etc/nginx/sites-available/default.conf

server {
    location / {
add_header Permissions-Policy interest-cohort=();
...

Перезапустите NGINX с помощью команды service nginx restart

Apache

Добавьте следующую директиву в свой файл конфигурации Apache:

# /www/htdocs/example.com/.htaccess 

<IfModule mod_headers.c>
  Header always set Permissions-Policy: interest-cohort=()
</IfModule>

Перезапустите Apache с помощью команды service apache2 restart

Caddy

Добавьте следующее в свой Caddyfile:

# Caddyfile

example.com {
header Permissions-Policy "interest-cohort=()"
...

Перезапустите Caddy с помощью команды caddy reload

Lighttpd

Добавьте в файл конфигурации Lighttpd следующее:

# /etc/lighttpd/lighttpd.conf

server.modules += ( "mod_setenv" )

setenv.add-response-header = ( "Permissions-Policy" => "interest-cohort=()" )

Перезапустите Lighttpd с помощью команды service lighttpd restart

Netlify

Добавьте в файл конфигурации Netlify следующее:

# netlify.toml

[[headers]]
  for = "/*"
  [headers.values]
    Permissions-Policy = "interest-cohort=()"

Если вы предпочитаете использовать _headers файл вместо файла конфигурации TOML, добавьте в этот файл вместо указанных выше строчек следующее:

# _headers

/*
  Permissions-Policy: interest-cohort=()

При следующей сборке или развертывании Netlify добавит и обслужит заголовки.

GitHub Pages

В настоящее время не существует возможности добавлять кастомные заголовки HTTP при использовании GitHub Pages. Однако есть обходной путь — добавление метатегов на сами страницы.

Добавьте в раздел <head> HTML-кода следующее:

<meta http-equiv="Permissions-Policy" content="interest-cohort=()"/>

GitLab Pages

Как и в случае с GitHub, при использовании GitLab Pages нет возможности добавлять кастомные заголовки HTTP. Таким образом, придется воспользоваться тем же методом, что и выше, и устанавливать директивы в самом HTML.

Однако, если вы пользуетесь GitLab Community Edition, можно установить заголовки, добавив в свой gitlab.rb файл следующее:

# gitlab.rb

gitlab_pages['headers'] = [ "Permissions-Policy: interest-cohort=()" ]

Вы также можете указать заголовки при запуске GitLab Pages binary:

./gitlab-pages -header "Permissions-Policy: interest-cohort=()"

CloudflareWorkers

Вы можете создать следующий Worker Script, чтобы установить заголовки ответа:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  let response = await fetch(request)
  let newHeaders = new Headers(response.headers)
  newHeaders.set("Permissions-Policy", "interest-cohort=()")

  return new Response(response.body, {
    status: response.status,
    statusText: response.statusText,
    headers: newHeaders
  })
}

Добавьте этот Worker Script в домен, установив этот домен в качестве Worker Route.

WordPress

WordPress позволяет устанавливать заголовки из своей кодовой базы с помощью хуков. Добавьте следующий код в конец functions.php файла активной темы:

function disable_floc($headers) {
    $headers['Permissions-Policy'] = 'interest-cohort=()';
    return $headers;
  }

add_filter('wp_headers', 'disable_floc');

Сохраните файл в админ-панели WordPress. Все новые запросы будут содержать необходимый заголовок.

Если вы используете какие-либо механизмы кэширования и плагины (например, FastCGI Cache от NGINX, W3 Total Cache и т. Д.), необходимо очистить кэш, чтобы он был повторно заполнен с указанными выше дополнениями.

Дата-центр ITSOFT — размещение и аренда серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.