This
document
defines
a
signal,
transmitted
over
HTTP
and
through
the
DOM,
that
conveys
a
person's
request
to
websites
and
services
to
not
sell
or
share
their
personal
information
with
third
parties.
This
standard
is
intended
to
work
with
existing
and
upcoming
legal
frameworks
that
render
such
requests
enforceable.
Status
of
This
Document
This
is
a
preview
Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://w3c.github.io/gpc/
for
the
Editor's
draft.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
standards
and
drafts
index
at
https://www.w3.org/TR/.
Publication
as
an
Editor's
Draft
does
not
imply
endorsement
by
W3C
and
its
Members.
This
is
a
draft
document
and
may
be
updated,
replaced
replaced,
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
Building
websites
today
often
involves
relying
on
services
provided
by
businesses
other
than
the
one
with
which
a
person
choses
to
interact.
This
result
is
a
natural
consequence
of
the
increasing
complexity
of
Web
technology
and
of
the
division
of
labor
between
different
services.
While
this
architecture
can
be
used
in
the
service
of
better
Web
experiences,
it
can
also
be
abused
to
violate
privacy
([
privacy-principles
]).
While
data
can
be
shared
with
service
providers
for
limited
operational
purposes,
it
can
also
be
shared
with
third
parties
or
used
for
behavioral
targeting
in
ways
that
many
users
find
objectionable.
Several
different
legal
frameworks
have
been
proposed
or
enacted
by
jurisdictions
around
the
world
to
address
this
concern.
Some
models
rely
upon
user
consent
for
tracking.
Other
models
based
on
the
principle
of
data
minimization
simply
prohibit
certain
data
sharing
or
data
processing
entirely.
Some
laws
and
proposals
grant
users
the
right
to
request
that
their
privacy
be
protected,
including
"opt
out"
requests
that
their
data
not
be
sold
or
shared
beyond
the
business
with
which
they
intend
to
interact.
Requiring
that
people
manually
express
their
rights
for
each
and
every
site
they
visit
is,
however,
impractical.
Given
the
ease
and
frequency
by
which
personal
information
is
collected
and
sold
when
a
consumer
visits
a
website,
consumers
should
have
a
similarly
easy
ability
to
request
to
opt-out
globally.
This
regulation
offers
consumers
a
global
choice
to
opt-out
of
the
sale
of
personal
information,
as
opposed
to
going
website
by
website
to
make
individual
requests
with
each
business
each
time
they
use
a
new
browser
or
a
new
device.
[
CCPA-AG-FINAL-STATEMENT
]
This
specification
is
designed
for
this
last
category
of
laws
and
addresses
the
problem
of
the
difficulty
of
scaling
user
choices
by
providing
a
way
to
universally
signal
to
all
website
publishers,
through
an
HTTP
header
or
the
DOM,
a
person's
assertion
of
their
applicable
rights
to
prevent
the
sale
of
their
data,
data
and
the
sharing
of
their
data
with
third
parties,
and
the
use
of
their
data
for
cross-site
targeted
advertising.
parties.
This
signal
allows
users
to
take
advantage
of
specific
provisions
in
some
of
these
opt-out
based
laws,
such
as,
for
example,
the
provisions
relating
to
"opt
out
preferences
signals"
in
the
California
Consumer
Privacy
Act.
[
CCPA-REGULATIONS
].
The
specification
should
not
be
interpreted
as
an
endorsement
of
the
opt-out
model
of
regulation
—
or
cross-site
tracking
more
broadly
—
or
a
rejecion
of
other
models
based
on
consent
or
data
minimization.
It
is
instead
designed
to
make
it
possible
to
exercise
the
affirmative
rights
granted
to
users
in
certain
jurisdictions.
2.
Definitions
A
do-not-sell-or-share
interaction
is
an
interaction
with
a
website
in
which
the
person
is
requesting
that
their
data
not
be
sold
to
or
shared
with
any
party
other
than
the
one
the
person
intends
to
interact
with,
or
to
have
their
data
used
for
cross-site
ad
targeting,
except
as
permitted
by
law.
A
do-not-sell-or-share
preference
is
when
a
person
requests
that
their
data
"not
be
sold
or
shared"
for
instance
by
activating
a
Global
Privacy
Control
setting
with
their
user
agent
or
by
using
tools
that
default
to
such
a
setting
(possibly
because
this
setting
matches
the
most
common
expectations
of
that
tool's
users).
When
set,
this
preference
indicates
that
the
person
expects
to
browse
the
Web
with
do-not-sell-or-share
interactions
.
3.
Expressing
a
Do
Not
Sell
Or
Share
Preference
3.1
Expression
Format
A
Global
Privacy
Control
preference
should
be
conveyed
for
all
HTTP
requests
(in
the
form
of
the
HTTP
header)
and
all
websites
(in
the
form
of
the
Web
API
property).
If
set,
this
preference
is
expressed
as
a
single
value
of
1
or
equivalently
true
according
to
context.
In
the
absence
of
regulatory,
legal,
or
other
requirements,
websites
MAY
interpret
an
expressed
Global
Privacy
Control
preference
as
they
find
most
appropriate
for
the
given
person,
particularly
as
considered
in
light
of
the
person's
privacy
expectations,
context,
and
cultural
circumstances.
Likewise,
websites
might
make
use
of
other
preference
information
outside
the
scope
of
this
protocol,
such
as
site-specific
person
preferences
or
third-party
registration
services,
to
inform
or
adjust
their
behavior
when
no
explicit
preference
is
expressed
via
this
protocol.
User
agents
are
expected
to
convey
person
preferences
as
accurately
as
they
can.
User
agents
SHOULD
strive
to
represent
what
the
user
agent
best
believes
to
be
the
person's
preference
for
the
Global
Privacy
Control
value.
3.2
Preference
Caching
The
preference
MUST
be
cached
on
each
top-level
navigation
to
ensure
consistency
in
communication
of
the
person's
request
that
their
data
"not
be
sold
or
shared."
This
means
that
if
the
preference
changes
during
or
after
a
top-level
navigation,
it
will
not
be
reflected
until
the
next
navigation.
If
preference
is
changed
to
be
inconsistent
with
some
gpcAtNavigation
cached
in
a
top-level
browsing
context
,
the
user
agent
SHOULD
inform
the
user
of
any
inconsistent
tabs
and
provide
the
option
to
reload
them,
refreshing
the
cached
gpcAtNavigation
to
reflect
the
current
preference
.
A
user
agent
MUST
generate
a
Sec-GPC
header
field
with
a
field-value
that
is
exactly
the
numeric
character
"1"
if
top-level
browsing
context
's
gpcAtNavigation
is
true
.
A
user
agent
MUST
NOT
generate
more
than
one
Sec-GPC
in
a
given
HTTP
request
and
MUST
NOT
use
a
Sec-GPC
field
in
an
HTTP
trailer.
A
server
processing
an
HTTP
request
that
contains
a
Sec-GPC
header
MUST
ignore
it
and
process
the
request
as
if
that
header
had
not
been
specified
unless
the
field
value
is
exactly
the
character
"1".
If
there
are
multiple
Sec-GPC
headers
and
at
least
one
has
a
field
value
of
exactly
"1"
then
the
server
MUST
treat
the
request
as
if
there
were
only
one
Sec-GPC
header
with
a
field
value
of
"1";
and
as
if
there
were
none
otherwise.
HTTP
intermediaries
MUST
NOT
remove
a
Sec-GPC
header
set
to
"1",
but
they
MAY
remove
Sec-GPC
headers
that
contain
other
values.
Additionally,
an
HTTP
intermediary
that
has
reasons
to
believe
the
the
person
originating
a
given
HTTP
request
has
a
do-not-sell-or-share
preference
,
MAY
insert
a
Sec-GPC
header
set
to
"1".
3.3.1
Extensibility
of
the
Sec-GPC
Field
Value
The
Sec-GPC
is
deliberately
defined
without
an
extension
mechanism.
Experience
with
previous
similar
headers
shows
that
people
tend
to
rely
on
string
equality
instead
of
parsing
the
value
when
testing
for
their
presence,
especially
when
extensions
do
not
yet
exist.
Such
checks
would
of
course
fail
in
the
presence
of
extension
content,
which
would
in
turn
render
the
mechanism
moot.
Should
extensions
prove
necessary
to
this
standard,
they
will
need
to
be
implemented
through
other
headers,
which
may
in
time
supersede
this
one.
The
globalPrivacyControl
property
is
available
on
the
navigator
object
in
both
regular
and
worker
contexts,
and
so
can
be
checked
reading
from
navigator.globalPrivacyControl
.
4.
GPC
Support
Resource
A
site
MAY
produce
a
resource
at
a
.well-known
URL
in
order
for
a
site
to
represent
the
fact
that
it
abides
by
GPC
requests,
at
least
where
required
to
do
so.
The
purpose
of
a
GPC
support
resource
is
for
a
site
to
convey
its
awareness
of
and
support
for
the
Global
Privacy
Control.
The
support
resource
is
not
intended
to
convey
whether
the
site
abides
by
GPC
requests
from
the
user
agent
accessing
the
resource.
By
default,
an
origin's
support
is
unknown
.
A
GPC
support
resource
has
the
well-known
identifier
/.well-known/gpc.json
relative
to
the
origin
server's
URL
[
RFC8615
].
An
origin
server
that
receives
a
valid
GET
request
targeting
its
GPC
support
resource
responds
either
with
a
successful
response
containing
a
machine-readable
representation
of
the
site-wide
tracking
status,
as
defined
below,
or
a
sequence
of
redirects
that
leads
to
such
a
representation
(which
MAY
be
provided
by
a
server
at
another
origin).
4.1
GPC
Support
Representation
The
origin
server
MUST
return
the
GPC
support
resource
as
a
valid
representation
using
the
application/json
media
type
[
RFC8259
],
otherwise
the
origin's
support
is
unknown.
The
GPC
support
representation
MUST
be
an
JSON
object
,
otherwise
the
origin's
support
is
unknown.
Members
of
this
JSON
object
not
in
the
list
below
have
no
meaning
in
this
specification
and
MUST
be
ignored.
Members
include:
A
gpc
member.
The
value
of
the
gpc
member
MUST
be
either
true
,
to
indicate
that
the
server
intends
to
abide
by
GPC
requests
at
least
to
the
extent
it
is
legally
obligated
to
do
so,
or
false
,
to
indicate
that
it
does
not.
For
any
other
value
the
origin's
support
is
unknown.
A
lastUpdate
member.
The
value
of
the
lastUpdate
member
MUST
be
an
RFC3339
full-date
(YYYY-MM-DD)
or
date-time
(YYYY-MM-DDTHH:mm:ss.sssZ)
[
RFC3339
].
This
indicates
the
time
at
which
the
statement
of
support
was
made,
such
that
later
changes
to
the
meaning
of
the
GPC
standard
should
not
affect
the
interpretation
of
the
resource
for
legal
purposes.
If
the
member
is
not
in
a
valid
RFC3339
format,
the
last
update
date
and
time
is
unknown.
5.
Legal
Effects
This
section
is
non-normative.
The
GPC
signal
was
designed
to
allow
users
to
take
advantage
of
legal
rights
to
stop
certain
sharing
sale
or
processing
sharing
of
their
data.
Some
jurisdictions
phrase
this
as
opting
out
of
targeting
advertisements
using
data
that
was
shared
between
non-affiliated
companies,
and
that
still
falls
into
the
opt
out
of
sharing
in
general.
As
such,
the
sending
and
receipt
of
a
GPC
signal
may
have
a
variety
of
legal
effects,
depending
on
factors
such
as
the
location
of
the
individual
sending
the
signal,
the
scope
of
the
applicable
law,
as
well
as
any
separate
agreement
between
the
recipient
of
the
signal
and
the
individual.
For
additional
details
on
legal
effects,
consult
the
Legal
and
Implementation
Considerations
Guide
.
For
example,
the
use
of
the
GPC
signal
by
an
individual
will
be
intended
to
communicate
the
individual's
intention
to
invoke
the
following
rights,
as
applicable:
5.1
United
States
Privacy
Law
GPC
was
originally
created
to
take
advantage
of
new
opt-out
privacy
laws
in
the
United
State.
Starting
with
the
enactment
of
the
California
Consumer
Privacy
Act
in
2018,
several
U.S.
states
have
passed
privacy
laws
that
give
consumers
the
legal
right
to
opt
out
of
the
sale
or
share
of
their
data,
or
the
use
of
their
data
for
cross-context
targeted
advertising.
data.
Many
of
those
state
laws
make
explicit
provision
for
the
exercise
of
those
rights
through
universal
opt-out
mechanisms
such
as
the
GPC.
At
least
four
states
have
specifically
identified
GPC
as
a
valid
means
to
exercise
legal
opt-out
rights.
A
minority
of
states
provide
for
rulemaking
procedures
to
allow
regulators
to
expand
on
the
specifics
of
how
universal
opt-out
requests
should
be
honored;
other
states
may
rely
upon
informal
guidance
or
enforcement
actions
to
provide
clarity
on
the
scope
of
legal
obligations
around
GPC
signals.
5.2
Other
Jurisdictions
and
Privacy
Rights
GPC
could
potentially
be
used
to
indicate
rights
in
other
jurisdictions
as
well.
For
example,
the
GDPR
potentially
affords
data
subjects
the
right
to
limit
the
sharing
of
personal
information
under
Articles
7
and
21.
Many
other
countries
around
the
world
have
adopted
affirmative
privacy
legislation
—
often
modeled
on
the
GDPR;
a
regulator
in
one
of
those
countries
could
determine
that
GPC
invokes
a
legal
right
that
requires
some
response
from
a
recipient.
Other
US
state
privacy
laws,
such
as
those
in
Virginia
and
Utah,
give
consumers
new
opt-out
rights
around
data
sales
and
targeted
advertising
sharing
but
are
silent
on
the
legal
effect
of
global
opt-out
signals.
Regulators
enforcing
those
statutes
may
determine
that
a
user
activating
a
signal
such
as
GPC
may
be
sufficient
to
legally
exercise
opt-out
rights
in
those
jurisdictions.
However,
GPC
is
not
necessarily
intended
to
invoke
every
new
privacy
right
in
every
jurisdiction.
For
example,
GPC
is
not
intended
to
globally
invoke
data
deletion
rights
on
every
website
visited
by
the
user.
GPC
is
also
not
intended
to
limit
a
first
party’s
use
of
personal
information
within
the
first-party
context
(such
as
a
publisher
targeting
ads
to
a
user
on
its
website
based
on
that
user’s
previous
activity
on
that
same
site).
Given
the
complexities
of
existing
consent
frameworks,
publishers
who
accept
the
GPC
signal
should
disclose
how
they
treat
the
GPC
signal
in
that
jurisdiction
and
how
they
deal
with
conflicts
between
the
signal
and
other
specific
privacy
choices
that
the
person
has
already
made
directly
with
the
publisher,
including
instances
where
third
party
sharing
may
be
permitted
such
as
sharing
to
service
providers/processors,
sharing
at
law
or
at
the
direction
of
the
individual.
5.3
User
Interface
Language
User
agents
SHOULD
strive
to
represent
what
the
user
agent
best
believes
to
be
the
person's
preference
for
the
Global
Privacy
Control
value.
While
studies
have
shown
that
people
do
not
want
their
data
sold
or
shared,
some
jurisdictions
have
enacted
"opt-out"
legal
frameworks
where
consumers
have
to
take
an
affirmative
action
to
express
a
preference
to
limit
data
sharing
of
the
use
of
their
data
for
targeted
advertising.
sharing.
Different
jurisdictions
have
different
prerequisites
before
a
platform
can
enable
a
universal
opt-out.
Many
US
states
say
that
a
user
agent
may
not
send
a
universal
opt-out
signal
by
"default,"
though
at
least
one
state
has
said
that
selecting
a
privacy
focused
user
agent
is
a
sufficient
indicator
of
user
intent.
Different
jurisdictions
may
also
have
different
rules
for
when
companies
can
override
or
disregard
a
universally
applicable
opt-out
signal,
for
example
because
they
have
consent
from
the
user
to
do
so.
The
legal
landscape
around
global
opt-outs
is
also
changing.
Several
states
have
now
passed
laws
that
include
requirements
to
honor
global
opt-outs,
though
some
of
those
states’
provisions
differ
considerably.
Additionally
states
may
revise
their
legal
requirements
as
California
has
already
amended
the
original
CCPA
that
was
passed
in
2018.
In
addition
to
the
United
States,
other
jurisdictions
may
recognize
universal
privacy
signals
and
may
impose
their
own
requirements
before
such
signals
are
deemed
legally
bindinging.
For
more
information
on
the
latest
legal
requirements,
please
review
the
Legal
and
Implementation
Considerations
Guide
which
will
provide
more
up-to-date
information
about
the
latest
legal
guidance
around
global
opt-outs.
User
agents
are
expected,
where
required,
to
present
all
the
appropriate
notices
to
people
to
ensure
that
the
rights
they
wish
to
avail
themselves
of
are
effectively
binding.
6.
Privacy
Considerations
Exposing
a
user's
preference
(in
the
HTTP
header
field
or
navigator
object)
potentially
divides
users
into
two
groups
in
a
way
that
might
increase
the
information
available
for
browser
or
device
fingerprinting.
This
additional
information
is
available
unless
the
signal
perfectly
correlates
with
other
signals
or
is
turned
on
in
a
non-configurable
setting.
Thus,
depending
on
the
implementation,
the
GPC
signal
may
impose
a
privacy
cost,
though,
one
intended
to
be
justified
by
the
privacy
benefit
of
sending
the
signal.
7.
Security
Considerations
There
are
no
known
security
impacts
of
the
features
in
this
specification.
8.
Conformance
As
well
as
sections
marked
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
and
notes
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The
key
words
MAY
,
MUST
,
MUST
NOT
,
and
SHOULD
in
this
document
are
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
A.
Implementation
Considerations
It
is
worth
considering
that
a
GPC
signal
will
be
attached
to
every
HTTP
request
made
to
a
given
site.
Rendering
a
page
on
the
Web
often
requires
making
dozens
such
requests.
As
such
it
can
prove
impractical
for
GPC
signals
to
trigger
full-blown
opt-out
procedures
with
costly
audit
trails
for
every
single
GPC
interaction
as
that
will
cause
a
large
amount
of
processing,
including
for
resources
served
from
a
content
delivery
network
(CDN)
that
must
be
executed
as
efficiently
as
possible.
Regulations
that
intend
to
support
GPC
are
encouraged
to
consider
such
implementation
difficulties.
One
way
of
addressing
them
is
to
differentiate
between
user
interface
affordances
given
to
people
for
the
purpose
of
requesting
a
do-not-sell-or-share
interaction
preference
to
persist
on
the
site,
and
the
provision
of
a
do-not-sell-or-share
interaction
signal
the
state
of
which
is
maintained
with
the
user
agent.
In
the
latter
case,
the
interaction
can
be
processed
as
if
the
person
had
previously
requested
such
a
do-not-sell-or-share
interaction
preference
and
were
interacting
with
that
preference
already
active.