Right, one might equate the criteria for *deciding to persist deviceId*
with that of *deciding to unfilter label* (i.e. active gUM-use "in the
current browsing context" or persistent permission).
But the difference is that the former decision isn't undone at the end
of gUM use (because that wouldn't be persistent at all), whereas the
latter decision is made every time enumerateDevices is called.
What remains to decide is what happens when persistent permissions are
revoked. I suggest:
Q: I clear my cookies but never revoke persistent permissions to site X.
A: When I revisit site X, it gets new (different) deviceIds, which get
persisted right away.
Q: I change site X's persistent permission from "Always Allow" back to
the default ("Always ask").
A: deviceId persists.
Q: I change site X's persistent permission from "Always Allow" to
"Always Deny".
A: Should we clear deviceId in this case, or is it unrelated at this point?
.: Jan-Ivar :.
On 7/6/15 2:17 PM, Martin Thomson wrote:
> On 6 July 2015 at 11:12, Joe Berkovitz <joe@noteflight.com> wrote:
>> Would this be identical to the filtered-vs-unfiltered-results criterion used
>> by enumerateDevices() to determine the inclusion of labels, etc.? It seems
>> logical to me that it would be exactly the same, since the aim in both
>> places is to defeat fingerprinting.
> No, the unfiltered information is only available when the site is able
> to use the source, either because they have a persistent permission or
> because the stream is active.
>
> This only changes the persistence story. When gUM consent is granted,
> the current random seed is persisted to disk. The current spec
> requires that the value be persisted when enumerateDevices is called.
Received on Monday, 6 July 2015 19:26:09 UTC