This core will hold what somebody watches, when they watched it, how far they
got, and the credentials that reach their server. In most of the jurisdictions
this software will run in, all of that is personal data, and some of it is close
to the sensitive kind, because a viewing history says a great deal about a
person.
The position this repository takes has to be written down before code depends on
it, because a position adopted afterwards is a position that has to be proven
against code that was not built for it.
The position. Personal data stays on the operator's own host and the devices
they use. Nothing leaves for anywhere else unless the operator has deliberately
set up federation to a second server they chose. There is no exception for
diagnostics, for statistics, for improving anything, or for a default that can be
turned off.
What the record must answer
What counts as personal data here, listed concretely rather than by reference to
a statute, so a contributor can tell whether a new field is in the set.
The rule above, stated as something a check can be written against: an outbound
connection to a host the operator did not configure is a defect.
What deliberate federation means as an act, which is #72, and why an opt-out
default would not satisfy this.
The retention question. What the core keeps on the device, for how long, and what
removes it, including what signing out removes and what uninstalling leaves
behind.
What this position gives up. It rules out crash reporting that would find bugs
faster, and usage measurement that would answer real questions about what to
build. Both are worth naming as costs rather than pretending the choice is free.
Done when
The record exists in docs/decisions/, states the position and its costs, and
names the checks in #70 and #73 as the mechanisms that hold it. Blocked on #2.
This core will hold what somebody watches, when they watched it, how far they
got, and the credentials that reach their server. In most of the jurisdictions
this software will run in, all of that is personal data, and some of it is close
to the sensitive kind, because a viewing history says a great deal about a
person.
The position this repository takes has to be written down before code depends on
it, because a position adopted afterwards is a position that has to be proven
against code that was not built for it.
The position. Personal data stays on the operator's own host and the devices
they use. Nothing leaves for anywhere else unless the operator has deliberately
set up federation to a second server they chose. There is no exception for
diagnostics, for statistics, for improving anything, or for a default that can be
turned off.
What the record must answer
What counts as personal data here, listed concretely rather than by reference to
a statute, so a contributor can tell whether a new field is in the set.
The rule above, stated as something a check can be written against: an outbound
connection to a host the operator did not configure is a defect.
What deliberate federation means as an act, which is #72, and why an opt-out
default would not satisfy this.
The retention question. What the core keeps on the device, for how long, and what
removes it, including what signing out removes and what uninstalling leaves
behind.
What this position gives up. It rules out crash reporting that would find bugs
faster, and usage measurement that would answer real questions about what to
build. Both are worth naming as costs rather than pretending the choice is free.
Done when
The record exists in
docs/decisions/, states the position and its costs, andnames the checks in #70 and #73 as the mechanisms that hold it. Blocked on #2.