Closed Bug 983799 Opened 10 years ago Closed 10 years ago

Technical Privacy Review: The feature detection API

Categories

(mozilla.org :: Security Assurance: Review Request, task)

Product:
mozilla.org
Component:
Security Assurance: Review Request
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: cgalimidi, Assigned: curtisk)

References

Details

(Keywords: privacy-review-needed) 

Initial Questions:

Project/Feature Name: The feature detection API
Tracking  ID:983502
Description:
Description:
We're designing an API to address the use case of feature detecting scenarios where the interesting information is either not available to the application because it doesn't have enough permissions, or that it doesn't have direct access to the information it needs to query.

Most of this information can be indirectly inferred from the information exposed in the UA string.  An example of this is APIs designed to tell you whether the platform supports a given API if the app has the required privileges, with the goal of enabling Market Place to avoid offering apps which will not work on the device.

But there are two specific cases where we might end up exposing additional fingerprinting bits which is what I would like to feedback on from the Privacy team.

1. Exposing the amount of available memory on the device.  This is a requirement for the Tarako device.  The issue here is that the Tarako device ships with 128MiB of memory which makes it unable to run some of the apps that are in the Market Place because the app process would OOM if the app was loaded on the device.  In order for the Market Place app to be able to avoid offering those types of apps to our users, it needs to know the amount of memory available on the device.

Right now my proposal does the simple thing of returning the amount of available memory as the number of mebibytes, like this:

navigator.getFeature("hardware.memory").then(function(mem) {
  if (mem == 128) {
    // We're running on a 128MiB device
  }
});

This information will probably be directly correlated with other information which is currently exposed, such as the device's screen size, so I'm not sure if this is an actual one unique bit of new information.  Our current use case includes detecting extremely low memory environments, so we might get away with exposing coarser grained information such as "lowmem" and "highmem", but there are some games right now which will not start up on a 256MiB device, and I can only imagine that this problem will keep recurring with higher amounts of device memory in the future so it would be nice if we keep that use case in mind while we think about this.

2. Exposing whether the platform supports APIs which rely on hardware capabilities.
For things such as the Bluetooth API, we need to know whether or not the underlying hardware capability to support the API exists, in addition to whether or not the API to expose that functionality exists.  While the existence of the API can be derived from the UA string, the existence of the hardware is not directly exposed today.  So for example, a web page can run code like:

navigator.getFeature("api.navigator.mozBluetooth").then(function(available) {
  if (available) {
    // This device has bluetooth hardware inside it
  } else {
    // This device either doesn't have bluetooth hardware, or the API for that doesn't exist
  }
});

The existence of these kinds of hardware are also directly correlated with other bits that are already exposed such as the screen size.  For example, one could look at the screen size, and if it's small, determine that you're running a phone, which probably has bluetooth hardware on it.  The other case to consider is the else branch above, which tells you that navigator.mozBluetooth will not be available either because the API is not supported (for example if you're running on Firefox desktop) or that the hardware is not available.

Additional Information:

Note that the "hardware.memory" feature name is satisfying a Tarako use case, so we have a short amount of time before we can implement this API (about two weeks from now.)  In the interest of not rushing things through, we have decided to expose this API hidden behind a permission that only the MarketPlace app will have, so at least in the initial implementation, there is no additional figerprinting surface exposed to Web content.
Additional Information:
https://wiki.mozilla.org/WebAPI/Navigator.hasFeature
Key Initiative: Firefox OS
Release Date: 2014-03-28
Project Status: development
Mozilla Data: No
Mozilla Related: Firefox OS, Marketplace
Separate Party: No
Please contact Ehsan (cc'd) with all questions
Flags: needinfo?(curtisk)
Also please see the brief discussion in bug 983505, there was a bit of miscommunication about what we are asking for here.  :-)
Blocks: 983502
I'm pretty engaged at CanSecWest / Pwn2Own but I will be back to normal next week (all be it for 3 days) when I can really look at this.
Assignee: nobody → curtisk
Component: Project Review → Security Assurance: Review Request
Flags: needinfo?(curtisk)
Keywords: privacy-review-needed
Summary: The feature detection API → Technical Privacy Review: The feature detection API
(In reply to Mika from bug 983505 comment #9)
> > We already have access to all of this data, the proposed API here will allow
> > web pages (in the beginning, only the MarketPlace app) see this data as well.
> 
> In the beginning, only the Marketplace sees the data. What other web pages
> would see it later?

The current plan is to implement the API as a privileged API. That means that any packaged app that is submitted to the marketplace *and* which explicitly in the manifest asks for access to the feature-detecting API, and is then signed by the marketplace can use the API.

That means that the marketplace team and do whatever reviews or code inspection they want before making the app available.

This is something we already do for a number of other APIs (such as tcp-socket and contacts). Feel free to talk with the marketplace team about how these reviews work in practice.

It also means that we can refuse to sign any app that asks for this permission, effectively making the API only available to the apps that we pre-install on the device. Though that seems unnecessarily harsh.
It sounds like this is being bumped from 1.3T+ which means we have a few more weeks to discuss the proposal.  If that is happening I'd like us to consider it *not* being a privileged API which would let us use it for desktop and android as well as FxOS.
(In reply to Wil Clouser [:clouserw] from comment #6)
> It sounds like this is being bumped from 1.3T+ which means we have a few
> more weeks to discuss the proposal.  If that is happening I'd like us to
> consider it *not* being a privileged API which would let us use it for
> desktop and android as well as FxOS.

See bug 983502 comment 19.
Blocks: tarako-marketplace
No longer blocks: tarako-marketplace
Any updates here?  Anything I can do on my side to help expedite things?
Blocks: 988130
No longer blocks: 988130
Flags: needinfo?(curtisk)
From reading though this I don't see any direct user information being collected. Yes the API could be used with enough information to identify a particular class or type of hard ware (ie. a particular handset). The fact that this is available to privileged apps and not just the marketplace widens the threat circle a bit, but since we are backstopping this with explicit code review is an acceptable counter. The key part here is that all privileged apps that attempt to use this API should be tightly scrutinized.
Flags: needinfo?(curtisk)
Right now we're planning to *only* grant that permission to the market place app.

However, in the long run, we'd like the market place app itself to be a non-privileged app, which means that we'd like to look into exposing this API to the Web.  Sorry if comment 0 was not clear enough about that.
Flags: needinfo?(curtisk)
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #10)
> Right now we're planning to *only* grant that permission to the market place
> app.
> 
> However, in the long run, we'd like the market place app itself to be a
> non-privileged app, which means that we'd like to look into exposing this
> API to the Web.  Sorry if comment 0 was not clear enough about that.

I think this is far more concerning when allowing content access to specific information if that is more than what can be gleaned from current methods. If I can combine this with other data this could be a strong way to individually identify a user and thus foster tracking that would otherwise not be possible.
Flags: needinfo?(curtisk)
(In reply to comment #11)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #10)
> > Right now we're planning to *only* grant that permission to the market place
> > app.
> > 
> > However, in the long run, we'd like the market place app itself to be a
> > non-privileged app, which means that we'd like to look into exposing this
> > API to the Web.  Sorry if comment 0 was not clear enough about that.
> 
> I think this is far more concerning when allowing content access to specific
> information if that is more than what can be gleaned from current methods. If I
> can combine this with other data this could be a strong way to individually
> identify a user and thus foster tracking that would otherwise not be possible.

Do you mean specifically the device's physical memory or other things exposed through hasFeature()?
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #12)
> Do you mean specifically the device's physical memory or other things
> exposed through hasFeature()?

That is actually probably more to the point, the amount of memory and screen size might not be so bad, but are we planning on exposing other things? It would probably be helpful to have a complete list of data exposed by this API.
(In reply to Curtis Koenig [:curtisk] from comment #13)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #12)
> > Do you mean specifically the device's physical memory or other things
> > exposed through hasFeature()?
> 
> That is actually probably more to the point, the amount of memory and screen
> size might not be so bad, but are we planning on exposing other things? It
> would probably be helpful to have a complete list of data exposed by this
> API.

I have already provided that list. :-) https://wiki.mozilla.org/WebAPI/Navigator.hasFeature

Comment 0 is full of interesting details about the background of what we're trying to do here.  Please review it again, and let me know if you have any questions/concerns.  Thanks!
The first patch of the feature detection API is ready. (bug 983502)

"hardware.memory" is the first feature-name API support.
Only certified apps and privileged apps have the permission to get this value.
We don't expose the exactly value of physical memory.
The value is just a reference level. (rounding the value up to the next power of two)

Now we are waiting for the result of privacy review.
Hi Curtis,
is there any concern to land the feature detection with hardware.memory support?
From comment 13, the amount of memory should not be a problem.
For other feature-name, we can still wait for the result of privacy review.
Flags: needinfo?(curtisk)
(In reply to Alphan Chen[:Alphan] from comment #16)
> Hi Curtis,
> is there any concern to land the feature detection with hardware.memory
> support?
> From comment 13, the amount of memory should not be a problem.
> For other feature-name, we can still wait for the result of privacy review.

I personally don't see a concern, but I could be missing something. To that end I think we are going to have to follow the more formal process. To that end I've started https://wiki.mozilla.org/Privacy/Reviews/Feature_Detection_API and I've filled out as much of that as I can. If you all can help flesh out components section I will get this out to dev-planning today for review and comment.
Flags: needinfo?(curtisk) → needinfo?(alchen)
Curtis, I filled out some information on that page, please take a look and let me know if it looks good.  I'm not sure how to fill out this section: <https://wiki.mozilla.org/Privacy/Reviews/Feature_Detection_API#Alignment_with_Privacy_Operating_Principles> as it seems only relevant to the case where we're collecting users' data which we are not in this case.
Flags: needinfo?(alchen) → needinfo?(curtisk)
Thanks Ehsan, that section and all the ones that follow it are stuff I have to fill out as the privacy person assigned to this. Just because we're not collecting data this is directly part of the users data does not mean we don't have a privacy issue. If we're collecting any data that can be used to identify a single user (the ability to select them from a group) then that is a privacy issue. It does not have to be things like name, address, phone number. If I can use the data returned by this API to fingerprint a users hardware that is still a privacy issue especially if that information or this api is available to content. I could then store that information and watch for that user every time they return to my site and couple that with other data to learn things about them they might not want me to know.
Flags: needinfo?(curtisk)
OK, understood.  Yes, those concerns are the reason why I filed this bug.  :-)  I was just not familiar with our process here.
Hi Curtis, is there any update on the privacy review? We kindly need your help to expedite this, thank you.
Flags: needinfo?(curtisk)
I'll get the wiki done today and the comment thread started as well as filling any bugs from my part that I think need to be considered as part of the public discussion. Sorry for the delay, I've been out on PTO and then sidetracked with other stuff that was in the queue first.
Flags: needinfo?(curtisk)
How secure is the proposed design in terms of blocking a third-party (non-Mozilla) server from also accessing the data?  

I ask this not only in terms of malware but also relative to proposals such as described in the Slashdot article at <http://news.slashdot.org/story/14/04/30/1646228/dreamworks-animation-ceo-movie-downloads-will-move-to-pay-by-screen-size>.  Screen size might not be the only feature of interest to third parties, especially to spammers.  And, YES, malware that targets selected features would also be a concern.
(In reply to comment #23)
> How secure is the proposed design in terms of blocking a third-party
> (non-Mozilla) server from also accessing the data?  

This is about implementing a DOM API to give you access to some information.  We are not sending any data to any servers in Gecko.

> I ask this not only in terms of malware but also relative to proposals such as
> described in the Slashdot article at
> <http://news.slashdot.org/story/14/04/30/1646228/dreamworks-animation-ceo-movie-downloads-will-move-to-pay-by-screen-size>.
>  Screen size might not be the only feature of interest to third parties,
> especially to spammers.  And, YES, malware that targets selected features would
> also be a concern.

Please read the wiki page, David.  We're not talking about screen size.  FYI, the screen size *is* already exposed to the Web.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
So what is the final result of the privacy review?  Thanks!
Flags: needinfo?(curtisk)
There is no "result" per-se in these things. To a large degree it's about documenting the thinking and ensuring we're staying true to our privacy promises. If further work was needed then more bugs would have been filled. At this point since we documented the thinking in the 3 bugs and there were no follow up bugs you all are fine from a privacy perspective to continue with the feature as planned in its current iteration. I think we've been pretty clear about the use cases and the choices for those use cases. Exposing this to the Marketplace and privileged apps in the ways outlined in these bugs is acceptable from a technical perspective. So if legal has signed off and the non-technical privacy bugs are resolved then we're done with this question for now.
Flags: needinfo?(curtisk)
Thanks so much Curtis, sounds good!
You need to log in before you can comment on or make changes to this bug.