Hacker News Reader

Hacker News

Comment by flixic | Hacker News Reader

Parent Full thread

flixic

Remarkably short blog post. I would have appreciated a "why", to help build the voice of opposition.

Also, what about github.com itself?

View on HN

> Also, what about github.com itself?

Don't ask, try it. curl says: permissions-policy: interest-cohort=()

    $ curl -o /dev/null -v https://github.com/ 2>&1 | grep permissions-policy
    < permissions-policy: interest-cohort=()

Btw you can do this much shorter with the curl -I parameter which lists the return headers.

That also causes curl to change the underlying request to a HEAD request. Though according to the spec they should return the same headers, it’s not uncommon for sites to fail to do so (some web frameworks leave this responsibility to the user) or to cache these responses differently.

Personally I reflexively use the verbose version they used for these kind of investigations of server behavior after being bit a few times.

Same here, I thought it caused cURL to do a GET request and throw away the body, but it doesn't, and I've gotten different results more than once.

Also consider changing the user-agent from the default. I set mine to a typical browser string in ~/.curlrc, but you can also use -A/--user-agent on the command line.

curl -i (lowercase) prints the headers as well as the response body without the verbosity of -v

I believe you can also control what exactly is emitted with -w, which is nicer than trying to parse it later.

I use -i instead of -v -o /dev/null; is there any reason to prefer the latter? Is Curl smart enough to skip fetching the response body with the latter?

Shows how often I use curl.

does -I not work? ;)

It's not really a blog post, even though it's pushed out over their "blog" endpoint. This post is part of https://github.blog/changelog/ which tends to lean closer to the "git commit message" length than blog post length. Just a statement of changes they've made users may notice or be affected by.

FWIW the duckduckgo extension already shows the github.com website as tracker free, so they take a pretty strong stance on privacy. I think the why (ie. why does github take this stance on user pages) is pretty self explanatory in this situation.

> Also, what about github.com itself?

Shouldn't matter. FLoC isn't enabled if they don't use the `document.interestCohort()` API and if Chromium doesn't detect ads; at least for now. https://seirdy.one/2021/04/16/permissions-policy-floc-misinf...

This is a bit confusing. That post seems to suggest that (1) adding the header is not necessary to prevent one's site from "leveraging" floc, ie, identifying users, unless one already runs ads, and hence (2) that the header isn't necessary in most cases.

But it also says:

What adding this header does is exclude your website from being used when calcualting a user’s cohort. A cohort is an identifier shared with a few thousand other users, calculated locally from browsing history; sites that send this header will be excluded from this calculation. The EFF estimates that a cohort ID can add up to 8 bits of of entropy to a user’s fingerprint.

Being excluded from cohort calculation has a chance to place a user in a different cohort, altering a user’s fingerprint. This new fingerprint may or may not have more entropy than the one derived without being excluded.

But is individual fingerprinting really the concern? What if I don't want google clustering people who visit my page with people who visit similar pages? In they case, the header still helps protect their privacy, right? By making Google's website visit interest based clustering less substantively accurate? Or am I misunderstanding how floc works?

(Am author) Google's FLoC cohorts are determiend by browsing history. If your page is excluded thereby giving other pages a higher weight, it doesn't necessarily reduce the bits of entropy in a user's fingerprint. Cohorts will still have roughly the same number of people and thus make it about as easy to identify users.

If you add the header to your site, do it for the right reason. It could mess with unsophisticated ad targeting, but it won't necessarily make a difference wrt. privacy. Energy is better spent getting users off of any browser that supports FLoC (Chrome, probably Chromium too).

I guess the question here is what you mean by "privacy." It seems to me that privacy goes beyond merely avoiding the risk of fingerprinting, or individualized identification. Collective identification is also a privacy problem: if I get advertisements targeted at people with similar political beliefs to mine because I've labelled as a member of a cohort that has visited a cluster of X-leaning news sites, that seems objectionable independent of whether the owner of some website can also distinguish me as an individual from every other member of the cohort.

I'm also interested in understanding this.

My company is a non-profit and doesn't serve ads on our website. Should we ensure this header exists for our site?

yes

Yeh, but what happens when Google Analytics adds `document.interestCohort` and ~90% of the web get opted in?

If you are already embedding Google Analytics on your page, then surely all bets are off for your users' privacy?

Yes, but aren't they different?

If we have GA, we're getting some information and Google is getting some information, but are they sharing this information about users directly with advertisers?

The premise of FLoC is that they are explicitly tagging you in a group specifically for advertisers.

It's not just GA though it's any analytics or other 3rd-party that decides it wants to collect the cohort data

It would be if an (advertisement) iframe did, no?

Reply on news.ycombinator.com