1004123 - Feature Detection API Transparency

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

What is our expectation for storing or using this data for the marketplace? Do we intend to store this in some way for some period of time or will this be a time of use then done kind of thing?

Comment 1

[(no longer active)]

This information would be cached inside Gecko, but I assume that doesn't count as "storing", because Gecko can just use the underlying platform APIs to recompute the information.

Needinfo'ing Wil to see if MarketPlace plans to store the data returned through the getFeature() API.

Comment 2

[David E. Ross]

Any storage of these data by Mozilla should involve strong encryption, strong enough to defeat any attempt by hackers to access Mozilla's database.  

Furthermore, users should have the options to disable the detection of features individually.

Comment 3

[Wil Clouser [:clouserw]]

It's unclear on whether we'd need to store it or not.  I'd want the option to remain available.

To expand on that, it currently takes around 4s for us to run all our detection tests in lieu of this API (because we are actually creating DOM elements and testing if they exist, etc.).  If that time remained constant, I would build a caching system based on user agent so we only had to run those tests on devices we hadn't seen before.  If that time it takes to test those goes down drastically (which I'm assuming it will) we may not need to build that caching system.

Another expected use of the data is in aggregate.  Something like a notice to developers saying "If your game didn't *require* the vibration API you'd be installable on 30% more of the devices viewing your app's detail page."  or similar.

So, yes, I'd expect some storage, but don't know how specific that would be.

Comment 4

[(no longer active)]

(In reply to Wil Clouser [:clouserw] from comment #3)
> To expand on that, it currently takes around 4s for us to run all our
> detection tests in lieu of this API (because we are actually creating DOM
> elements and testing if they exist, etc.).  If that time remained constant,
> I would build a caching system based on user agent so we only had to run
> those tests on devices we hadn't seen before.  If that time it takes to test
> those goes down drastically (which I'm assuming it will) we may not need to
> build that caching system.

Oh, 4s is absolutely unacceptable.  If you hit that with navigator.getFeature(), please file a bug and we'll investigate and fix the performance issue.

Comment 5

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

as long as the storage of the data could not be reversed to identify a single individual then it's fine. The concern becomes if I store this data along with some other data at the same time can the aggregate information be used to identify an individual or individual device?

Comment 6

[Wil Clouser [:clouserw]]

I don't know of or have any plans to do that.

Comment 7

[David Bialer [:dbialer]]

To be a bit more specific on use cases:
a) Matching apps to a device.  Marketplace uses feature detection to ensure that users are only presented with apps that can work on the device.  For instance, if an app requires MMS and the device doesn't support SMS, then the app would not be presented to the user for installation since it would fail.  
b) matching app updates to devices - if an update of an app adds a feature that is needed, and the user's device doesn't support that new capability, the app would not be updated until such a time, the app can run on the device.
c) used in aggregate - to advise developers on their addressable market.

I think that most feature patterns would be fairly broad and have large bases of users.  I do not believe that a set of features would define a unique device or user - or small set of users.

Comment 8

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

As long as this is limited to Marketplace & privileged apps this seems reasonable.