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

Improve the privacy section. #132

Merged
merged 1 commit into from
Mar 14, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 50 additions & 32 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -96,7 +96,7 @@
}
</style>
</head>
<body data-cite="FEATURE-POLICY PERMISSIONS CSSOM-VIEW SCREEN-ORIENTATION">
<body data-cite="FEATURE-POLICY PERMISSIONS CSSOM-VIEW MEDIAQUERIES SCREEN-ORIENTATION">
Copy link
Member

Choose a reason for hiding this comment

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

Not related to this PR, but it's preferable to use xref instead of data-cite: https://respec.org/docs/#xref

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll make a follow up PR to fix this.

<section id='abstract'>
<p>
This document specifies an API that allows web applications to request
Expand Down Expand Up @@ -381,7 +381,10 @@ <h3>
instance, a device might not yield exactly 180° when laying flat, but
instead values ranging from 175° to 185°. Device makers SHOULD make
sure that the physical device postures map correctly to the postures
defined by this specification.
defined by this specification. Device makers are also allowed to determine
the posture using more sensors than just the hinge angle. For example,
they can also detect if keyboard is docked on the bottom half of the screen
or not. Another example is to detect whether the kickstand is deployed or not.
</p>
<p>
Some devices might also lack one or more of the postures due to
Expand Down Expand Up @@ -524,54 +527,69 @@ <h2>
</section>
<section>
<h2>
Security and Privacy considerations
Security Considerations
</h2>
<p>
The Device Posture API exposes a <a>posture</a> determined from the
hinge angle value and other sensors.
No new security considerations have been reported on this specification.
</p>
</section>
<section>
<h2>
Privacy considerations
</h2>
<p>
Typical sensor readings are sent at a constant frequency to whomever is
listening to its readings. However the fold angle only communicates its
value when the hinge is manipulated by the user. Variations in the
angle’s readings and posture calculation, as well as event dispatching
frequency offer a possibility of fingerprinting to identify users. User
agents may reduce this risk by limiting or coalescing events when
exposing this information to web developers. Users don’t constantly
adjust the angle, so the fold angle value is changing in bursts: the
events may be dispatched at a very low frequency most of the time and
fire at a high frequency when the device is being opened or closed. In
order for the events to be dispatched, the content must be on the
foreground and visible to the user. Because the API does not directly
expose the raw angle values, but a more abstract posture with fewer
possible states, fingerprinting possibilities are more limited.
The Device Posture API exposes a <a>posture</a> determined from the hinge
angle sensor, but additional data can be used to determine the posture
such as whether the keyboard is attached or not, whether the
kickstand is deployed or not, etc.
</p>
<p>
If the same code using the API can be used simultaneously in different
window contexts on the same device it may be possible for that code to
correlate the user across those two contexts, creating unanticipated
tracking mechanisms.
Device Posture exposes high level concept and not sensor values
making fingerprinting possibilities more limited. Changing
posture is a physical manipulation done by the user. The frequency of
the posture changes are low, users do not constantly adjust the angle,
and even if they do the <a>posture</a> will only be changed in certain
scenarios as described in [=posture values table=].
rakuco marked this conversation as resolved.
Show resolved Hide resolved
</p>
<section>
<h3>
Types of security and privacy threats
Types of privacy threats
</h3>
<p>
<i>This section is non-normative.</i>
</p>
<h4 id="identifying-users-across-contexts">
Identifying users across contexts
</h4>
<p>
If this API can be used simultaneously in different window contexts
on the same device it may be possible for that code to correlate
the user across those two contexts, creating unanticipated
tracking mechanisms. However, because the posture value is typically
stable for a long time it could only be used to verify that two users
are not the same, but it would not help to identify a given user given
the fact that there are multiple types and models of foldable devices.
</p>
<p>
This API's entropy is comparable to the
<a data-xref-type="css-descriptor" data-xref-for="@media">pointer</a>
API which tells whether the user's primary input is touch-based or not.
darktears marked this conversation as resolved.
Show resolved Hide resolved
However, the primary input can change on devices where
the keyboard can be removed/added or the tablet mode is activated/deactivated.
</p>

<h4>
iframes
</h4>
<p>
iframes have access to the posture through this API and therefore could use
this information to identify users as mentioned in [[[#identifying-users-across-contexts]]].
</p>
</section>
<section>
<h3>
Mitigation Strategies
</h3>
<p>
<i>This section is non-normative.</i>
</p>
<p>
This section gives a high-level presentation of some of the
mitigation strategies specified in the normative sections of this
specification.
</p>
<section>
<h4>
Secure Context
Expand Down
Loading