~sircmpwn/sr.ht-discuss

15 9

Opt out of FLoC

Details
Message ID
<9c33cafc99ca4f0aeab08c8b10dff88a@disroot.org>
DKIM signature
pass
Download raw message
Google has launched trials of FLoC and that raises some privacy concerns.
Fortunately, there is a way to [opt out][1] of this as someone who hosts websites: setting a HTTP Header

```
Permissions-Policy: interest-cohort=()
```

I hope sourcehut would advocate privacy by standing against this.

[1]: https://github.com/WICG/floc#opting-out-of-computation
Details
Message ID
<20210416062901.3ucq5epn23iyz7el@meneltarma.localdomain>
In-Reply-To
<9c33cafc99ca4f0aeab08c8b10dff88a@disroot.org> (view parent)
DKIM signature
missing
Download raw message
On 21/04/16 05:50, huyngo@disroot.org wrote:
> Google has launched trials of FLoC and that raises some privacy concerns.
> Fortunately, there is a way to [opt out][1] of this as someone who hosts websites: setting a HTTP Header
> 
> ```
> Permissions-Policy: interest-cohort=()
> ```
> 
> I hope sourcehut would advocate privacy by standing against this.

	This is similar to DNT[1] in expecting naive faith that it would be
actually used to not track users and not to additionally (along with tracking)
mark them as having something to hide, or at least openly mark them as opposing
tracking, which is just additional personal data.

[1]: https://en.wikipedia.org/wiki/Do_Not_Track
mx
Details
Message ID
<0687EBA2-E271-4E7E-8C7F-88E44AB09A15@mehdix.org>
In-Reply-To
<20210416062901.3ucq5epn23iyz7el@meneltarma.localdomain> (view parent)
DKIM signature
pass
Download raw message
> mark them as having something to hide, or at least openly mark them as opposing tracking, which is just additional personal data.

I can only second this. It'd be yet another piece of personal data to harvest.
tom
Details
Message ID
<b4d0ce5b6e0a3656cb35a05153da3b55@tomsdiner.org>
In-Reply-To
<0687EBA2-E271-4E7E-8C7F-88E44AB09A15@mehdix.org> (view parent)
DKIM signature
pass
Download raw message
On 2021-04-16 11:21, mx wrote:
>> mark them as having something to hide, or at least openly mark them as 
>> opposing tracking, which is just additional personal data.
> 
> I can only second this. It'd be yet another piece of personal data to 
> harvest.

I may be a bit dense, but how is a http-server-side setting additional 
personal data?
Details
Message ID
<bP9AV97LTq6ERSuT16lXSezTCvrCBzW9cZd56MW8vU80G3NhXmjUdh86eCut5J1oOOXvCFj8m072A0veiSLRM0UsTGJ9ErOPupewvQMngIM=@emersion.fr>
In-Reply-To
<9c33cafc99ca4f0aeab08c8b10dff88a@disroot.org> (view parent)
DKIM signature
pass
Download raw message
Should already be done.

    > curl -v -X HEAD https://meta.sr.ht
    […]
    < permissions-policy: interest-cohort=()
Details
Message ID
<baaa8343-46fd-a704-da42-8a9f2e86f239@mehdix.org>
In-Reply-To
<b4d0ce5b6e0a3656cb35a05153da3b55@tomsdiner.org> (view parent)
DKIM signature
pass
Download raw message
 > I may be a bit dense, but how is a http-server-side setting 
additional personal data?

My bad, you're perfectly right! It would only apply to DNT sent from 
http clients to http servers and not this.
Details
Message ID
<20210416121243.5nc5k7mhqphbjveo@meneltarma.localdomain>
In-Reply-To
<b4d0ce5b6e0a3656cb35a05153da3b55@tomsdiner.org> (view parent)
DKIM signature
missing
Download raw message
On 21/04/16 11:30, tom wrote:
> I may be a bit dense, but how is a http-server-side setting additional
> personal data?

	Not at a per-user level. It could mark the server as potentially more
interesting target for harvesting.
Details
Message ID
<149b26e8-e4aa-7358-9a3e-75550b16011a@orbital.rocks>
In-Reply-To
<20210416121243.5nc5k7mhqphbjveo@meneltarma.localdomain> (view parent)
DKIM signature
pass
Download raw message
On 4/16/2021 8:12 AM, Страхиња Радић wrote:
> 	Not at a per-user level. It could mark the server as potentially more
> interesting target for harvesting.
> 

How would that work?

If the server isn't even receiving any of this data, why would it be a 
target? DNT has obvious value tracking since so few people set it, but I 
really can't see how the **server** setting a header value is going to 
do anything other than preventing them from receiving data that they 
don't want.

-gildarts
Details
Message ID
<20210416150718.b5slxnq425ea4h4d@meneltarma.localdomain>
In-Reply-To
<149b26e8-e4aa-7358-9a3e-75550b16011a@orbital.rocks> (view parent)
DKIM signature
missing
Download raw message
On 21/04/16 09:45, gildarts wrote:
> How would that work?

	This is all hypothetical, but still there is a potential. A big tech
spying corporation could use any means it already uses to gather data about a
user.  When a user accesses a server that is known to set the header telling
"not to gather information" (IDK, maybe information obtained by something as
simple as a crawler?), the user gets that habit associated with his/her "social
profile" or however else one would call it. The corporation could then, for
example, dedicate more resources/attention towards tracking the user, or use the
information in whetever other way it sees fit. It is a bit of data about a user
accessing such servers. The corporation could then - again: for example - track
frequency of visits, referrers, or use that information in ad targeting, etc
etc.
Details
Message ID
<PhF8IY1eoK41oTDW6acHt3t5XsrMHyhuklaWKISp3c@cp3-web-020.plabs.ch>
In-Reply-To
<20210416150718.b5slxnq425ea4h4d@meneltarma.localdomain> (view parent)
DKIM signature
pass
Download raw message
> This is all hypothetical, but still there is a potential. A big tech spying corporation could use any means it already uses to gather data about a user.  When a user accesses a server that is known to set the header telling "not to gather information" (IDK, maybe information obtained by something as simple as a crawler?), the user gets that habit associated with his/her "social profile" or however else one would call it. The corporation could then, for example, dedicate more resources/attention towards tracking the user, or use the information in whetever other way it sees fit. It is a bit of data about a user accessing such servers. The corporation could then - again: for example - track frequency of visits, referrers, or use that information in ad targeting, etc etc.

But wouldn't that be against the legal value of the opt-out and 
therefore usable against said company (making it useful)?

 From my point of view it:
a) sends a message
b) may potentially work at least for a while
c) can be used as leverage in case of later abuse

Whereas not doing it has no positive outcome that I can see.
Details
Message ID
<20210416154357.5xqquhazrdb5a45t@meneltarma.localdomain>
In-Reply-To
<PhF8IY1eoK41oTDW6acHt3t5XsrMHyhuklaWKISp3c@cp3-web-020.plabs.ch> (view parent)
DKIM signature
missing
Download raw message
On 21/04/16 03:14, Tanguy Fardet wrote:
> But wouldn't that be against the legal value of the opt-out and 
> therefore usable against said company (making it useful)?

	There's a difference between easily machine-identifiable "value" and
actual human-readable "legal value" (in the form of terms of use or such).

>  From my point of view it:
> a) sends a message
> b) may potentially work at least for a while
> c) can be used as leverage in case of later abuse
> 
> Whereas not doing it has no positive outcome that I can see.

	Whatever Google and other big tech companies push can't be trusted.
> 
Details
Message ID
<1b539f65-7cd8-eaef-0676-f9f2853574a2@orbital.rocks>
In-Reply-To
<20210416150718.b5slxnq425ea4h4d@meneltarma.localdomain> (view parent)
DKIM signature
pass
Download raw message
On 4/16/2021 11:07 AM, Страхиња Радић wrote:
> On 21/04/16 09:45, gildarts wrote:
>> How would that work?
> 
> 	This is all hypothetical, but still there is a potential. A big tech
> spying corporation could use any means it already uses to gather data about a
> user.  When a user accesses a server that is known to set the header telling
> "not to gather information" (IDK, maybe information obtained by something as
> simple as a crawler?), the user gets that habit associated with his/her 
"social
> profile" or however else one would call it. The corporation could then, 
for
> example, dedicate more resources/attention towards tracking the user, or use the
> information in whetever other way it sees fit. It is a bit of data about a user
> accessing such servers. The corporation could then - again: for example 
- track
> frequency of visits, referrers, or use that information in ad targeting, etc
> etc.
> 

That just sounds like a whole bunch of FUD. Unless you can explain how 
the **server** setting this header can give information to third parties 
that don't have anything embedded on the website, I think it is all BS.

If you are using Chrome and/or have nefarious extensions installed, you 
are already screwed from a data collection standpoint and the server 
setting this header will do absolutely nothing to help you other than 
not sending data back to that server. Chrome or other tracking tools can 
already see **every** single site you visit so it doesn't matter what 
the server is going.

There are enough real privacy and security threats out there without 
people peddling pure FUD.

I'm open to the possibility I'm wrong on this, but I'm going to need you 
to describe a real mechanism for this to happen and matter for me to 
change my mind.

-gildarts
Details
Message ID
<20210416181020.45fs6kp4el73ynbx@meneltarma.localdomain>
In-Reply-To
<1b539f65-7cd8-eaef-0676-f9f2853574a2@orbital.rocks> (view parent)
DKIM signature
missing
Download raw message
On 21/04/16 01:19, gildarts wrote:
> I'm open to the possibility I'm wrong on this, but I'm going to need you to
> describe a real mechanism for this to happen and matter for me to change my
> mind.

	If you ask about the possible scenario (which you already kind of
acknowledged by "may potentially work at least for a while") how this can be
detrimental, opting out of collecting "interest cohorts" would definitely prompt
Google that the server is openly opposing their "feature". How Google would
react would then entirely depend on them. If they wanted to retaliate, they
could for example lower the server's ranking in Google search to oblivion, or
they could make it so the server is treated as "malicious". I'm not them, so
IDK.

	Again, the point is that "permissions-policy", like DNT, is additional
*data* (concerning server's attitude towards Google) made public.

	I see this discussion is getting rather pointless, so I'm out.
Details
Message ID
<fa129988-a187-a525-1b19-db30950f5f17@archlinux.org>
In-Reply-To
<20210416181020.45fs6kp4el73ynbx@meneltarma.localdomain> (view parent)
DKIM signature
pass
Download raw message
On 4/16/21 2:10 PM, Страхиња Радић wrote:
> On 21/04/16 01:19, gildarts wrote:
>> I'm open to the possibility I'm wrong on this, but I'm going to need you to
>> describe a real mechanism for this to happen and matter for me to change my
>> mind.
> 
> 	If you ask about the possible scenario (which you already kind of
> acknowledged by "may potentially work at least for a while") how this can be
> detrimental, opting out of collecting "interest cohorts" would definitely prompt
> Google that the server is openly opposing their "feature". How Google would
> react would then entirely depend on them. If they wanted to retaliate, they
> could for example lower the server's ranking in Google search to oblivion, or
> they could make it so the server is treated as "malicious". I'm not them, so
> IDK.
> 
> 	Again, the point is that "permissions-policy", like DNT, is additional
> *data* (concerning server's attitude towards Google) made public.
> 
> 	I see this discussion is getting rather pointless, so I'm out.

But this is just changing the goalposts.

First you proposed that using this header constitutes additional
personal data attached to the user's FLoC profile.

Now you propose that the problem is Google will retaliate against the
server owner by harming their google search ranking and making them less
discoverable.

How does this latter concern constitute a user privacy issue?

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
Details
Message ID
<58643319-7c2d-c256-556e-63a7fc07d0c0@tomlebreux.com>
In-Reply-To
<bP9AV97LTq6ERSuT16lXSezTCvrCBzW9cZd56MW8vU80G3NhXmjUdh86eCut5J1oOOXvCFj8m072A0veiSLRM0UsTGJ9ErOPupewvQMngIM=@emersion.fr> (view parent)
DKIM signature
pass
Download raw message
On 2021-04-16 5:38 a.m., Simon Ser wrote:
> Should already be done.
> 
>      > curl -v -X HEAD https://meta.sr.ht
>      […]
>      < permissions-policy: interest-cohort=()
> 

Would it make sense to add the header to pages hosted on page.sr.ht?

Currently:


	> curl -v -X HEAD https://pages.sr.ht
	[...]
	< permissions-policy: interest-cohort=()

but

	> curl -v -X HEAD https://blog.tomlebreux.com
	// Not here
Details
Message ID
<gkNLo0ARoNsrEKJRwCq8PdGplxhZyJH2iXB7hxk7q5w@cp4-web-028.plabs.ch>
In-Reply-To
<58643319-7c2d-c256-556e-63a7fc07d0c0@tomlebreux.com> (view parent)
DKIM signature
pass
Download raw message
On 18/04/2021 06:05, Tom Lebreux wrote:
> Would it make sense to add the header to pages hosted on page.sr.ht?

I already asked Drew about this and it comes from the fact that personal 
pages are using Caddy and that it's seems to be a bit of a capricious 
tool, so header there may come later.

Also, for people who are interested, I found this interesting piece of 
information on FLoC: 
https://seirdy.one/2021/04/16/permissions-policy-floc-misinfo.html

I still think the header is worth it as a message and future (potential) 
leverage against Google, but I think it's important to make sure that 
people know the full story (I certainly did not know).
Reply to thread Export thread (mbox)