Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copy-edit the Collective Privacy section. #365

Merged
merged 5 commits into from
Nov 1, 2023

Conversation

jyasskin
Copy link
Collaborator

@jyasskin jyasskin commented Nov 1, 2023

I significantly simplified and shortened the wording, so please check that this still says what we want it to say.

This includes the change to the principle in #363, and updates to that PR might imply that we need some other changes to this one.

This should fix #308.


Preview | Diff

index.html Outdated
Comment on lines 1560 to 1566
Unfortunately, while this arrangement did improve performance,
it turned out not to help privacy.
What prevents a site from using [^a/ping^] for [=people=] who have it activated
and bounce tracking for others? What prevents a browser from opting everyone out because it wishes
to offer better protection by default? Given the contested nature of the [^a/ping^] attribute and
the absence of a forcing function to support collective enforcement, the scheme failed to deliver
improved privacy.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure exactly what we meant here by "a forcing function to support collective enforcement", so I haven't changed it to simpler wording. What should get enforced? That websites exclusively use ping instead of bounce tracking?

I'm also not sure that we're right that <a ping> didn't help privacy. My understanding is that there are tracking-blocking extensions that do block the network requests from the ping attribute, and that websites have some trouble falling back to bounce tracking in that case. Is there something we can cite that'll better demonstrate that there's a problem?

@jyasskin jyasskin added the agenda+ Add to the next call's agenda. label Nov 1, 2023
</ul>

Different forms of collective decision-making are legitimate depending on what data is being processed.
These forms might be governmental bodies at various administrative levels, standards
organisations, worker bargaining units, or civil society fora.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not vital, but wondering if we should reference: https://www.mnot.net/blog/2023/11/01/regulators

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a separate PR. :)

index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
@jyasskin jyasskin force-pushed the copy-edit-collective-privacy branch from 17efd13 to 004888e Compare November 1, 2023 17:46
Copy link
Member

@torgo torgo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm and reflects consensus of today's call

@jyasskin jyasskin merged commit 6874866 into w3ctag:main Nov 1, 2023
1 check passed
@jyasskin jyasskin deleted the copy-edit-collective-privacy branch November 1, 2023 17:53
github-actions bot added a commit that referenced this pull request Nov 1, 2023
SHA: 6874866
Reason: push, by jyasskin

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agenda+ Add to the next call's agenda.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Copy edit section 2.7, Collective Privacy
4 participants