Closed Bug 788878 Opened 9 years ago Closed 9 years ago

Privacy Review for Android product announcements


(Privacy Graveyard :: Product Review, task, P1)



(Not tracked)



(Reporter: smott, Assigned: me)



(Whiteboard: [snippets])

This is a bug to track the privacy review for the Firefox for Android feature Cloud To Device Messaging (specifically, the opt-out component of the feature).  

Background: The purpose of Cloud to Device Messaging is to provide a communication method that allows marketing to send a message to GA users that have Firefox for Android installed, and allows a message to be sent regardless of whether or not the application is currently open.  

Full Feature Page:

We are exploring the range of service options that we have to send messages to user's devices. Privacy concerns could include: 
--opt-out capability
--storage of device tokens (to facilitate messaging)

This bug will be updated when design work begins.
Summary: Implement Cloud-to-Device Messaging → Privacy Review for Cloud-to-Device Messaging
Closing as a duplicate of 749806
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 749806
Not a duplicate of the Services notifications product.
Resolution: DUPLICATE → ---
Blocks: 774497
No longer depends on: 774497
Feature page:

Meta bug: Bug 774497.
Summary: Privacy Review for Cloud-to-Device Messaging → Privacy Review for Android Snippets
Whiteboard: [snippets]
Could whoever is driving this schedule a 1h meeting with me next week (or later, if you're not yet ready)? Feel free to ping me on IRC in the mean time.
Assignee: nobody → tom
Thanks for the review today, Tom.

Summary of findings that I remember:

* If the set of collected data expands, new incremental review.
* Record server-side data with low-granularity timestamps: 15 minutes or an hour.
* Client preference string will be meaningless to most users. Explore alternatives.

What did I forget?
Summary: Privacy Review for Android Snippets → Privacy Review for Android product announcements
One question arose after the meeting. Do we have to pay attention to the DNT flag?

The system does not track individual users, nor is any personally identifying information stored. We are, however, acting on elements of the user's agent and one behavior (browser idle time), however this information is combined with others and presented as a collected report.
Additional note from metrics follow-up:

The current metrics system collects information the same way as our current logging does. (e.g. a timestamp is applied to records as they are recorded, and is per-second resolution.) This would be equivalent to a access log entry. 

There is some natural "fuzz" in that the client user agent collects a set of notifications, chooses one, and then presents it to the user who may or may not take action on it. In that case, we'll know that a user with a particular configuration requested some notices and that users have requested actions. It will not be easily correlatable to determine if those users are the same individuals.

The metrics folks are considering adding "delayed fuzz" to the timestamp, where after a period, the timestamp is decayed. This is not currently available.
Is there any reason that this bug needs to remain secret? Please object with 48h, so that I can make this public promptly if possible.
No objection from me.
I see no reason for this bug to remain secret.  The design docs and bugs are all public, and this is all in-house.
Group: privacy
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.