-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
brave-core
Core engine for the Brave browser for mobile and desktop. For issues https://github.com/brave/brave-browser/issues
-
From the README.md at https://github.com/WICG/floc:
"This API democratizes access to some information about an individual's general browsing history (and thus, general interests) to any site that opts into it. This is in contrast to today's world, in which cookies or other tracking techniques may be used to collate someone's browsing activity across many sites."
Can the user detemrine whether a site has opted in without sending an HTTP request the site (and thereby recording the access in her browsing history).
"Sites that know a person's PII (e.g., when people sign in using their email address) could record and reveal their cohort. This means that information about an individual's interests may eventually become public.
"As such, there will be people for whom providing this information in exchange for funding the web ecosystem is an unacceptable trade-off. Whether the browser sends a real FLoC or a random one is user controllable."
Can advertisers determine whether a FLoC sent is real or random.
I can imagine some FLoCs if sent would trigger ads that were undesirable, perhaps damaging to the user's reputation, embarassing, etc.
As described, this system compels users to accept targeted advertising (what Google and Facebook want every user to do). There is no opt-out. There is no such thing as non-targeted (general) ads. Users can either send real FLoC or random FLoC, but they cannot send no FLoC. If they choose randomised FLoC, they might receive ads targeted to cohorts with which they do not want to be identified. As the next paragraph states, the FLoC when compbinaed with other data can indeed be used as an user identifier. Choosing "randomised FLoC" might mean being publicly identified with undesirable cohorts. For example, IP address might become associated with an undesirable cohort.
"A cohort could be used as a user identifier. It may not have enough bits of information to individually identify someone, but in combination with other information (such as an IP address), it might."
"The expectation is that the user's FLoC will be updated over time, so that it continues to have advertising utility. The privacy impacts of this need to be taken into consideration. For instance, multiple FLoC samples means that more information about a user's browsing history is revealed over time."
"Second, if cohorts can be used for tracking, then having more interest cohort samples for a user will make it easier to reidentify them on other sites that have observed the same sequence of cohorts for a user."
"A cohort might reveal sensitive information."
"Some people are sensitive to categories that others are not, and there is no globally accepted notion of sensitive categories."
"It should be clear that FLoC will never be able to prevent all misuse. There will be categories that are sensitive in contexts that weren't predicted."
"A site should be able to declare that it does not want to be included in the user's list of sites for cohort calculation. This can be accomplished via a new interest-cohort permissions policy. This policy will be default allow."
Default is no privacy. Nice.
"... a site can opt out of all FLoC cohort calculation by sending the HTTP response header:
Permissions-Policy: interest-cohort=()"
Proxy config:
http-request del-header Permissions-Policy
http-response add-header Permissions-Policy "interest-cohort()"
"We will analyze the resulting cohorts for correlations between cohort and sensitive categories, including the prohibited categories defined here. This analysis is designed to protect user privacy by evaluating only whether a cohort may be sensitive, in the abstract, without learning why it is sensitive, i.e., without computing or otherwise inferring specific sensitive categories that may be associated with that cohort. Cohorts that reveal sensitive categories will be blocked or the clustering algorithm will be reconfigured to reduce the correlation."
Well, this appears to negate the claim that no browsing history is sent to the browser vendor. To conduct experiments and develop this system, Google needs to collect and process user browsing histories.
Taking things out or disabling them at chokepoints is easier than doing an entire engine on your own.
https://github.com/brave/brave-browser/wiki/Deviations-from-...
