Closed Bug 948320 Opened 6 years ago Closed 5 years ago

[User Story] Rocketbar: Search Suggestion Privacy Setting

Categories

(Firefox OS Graveyard :: Gaia::Search, defect, P1)

x86
macOS
defect

Tracking

(feature-b2g:2.0, tracking-b2g:backlog, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S4 (20june)
feature-b2g 2.0
tracking-b2g backlog
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: pdol, Assigned: daleharvey)

References

Details

(Whiteboard: [ucid:System153, 1.4:P2, ft:systems-fe][systemsfe])

User Story

Visual Specs:
https://mozilla.box.com/s/626r2x4kn3xzzecbney2

Interaction specs: 
https://mozilla.box.com/s/5dy7gllr9k3xaro44d07

Attachments

(1 file, 2 obsolete files)

User Story:
As a user, I want to be able to opt out of having my Rocketbar input string sent to a third party server while I type, so that I can control my privacy.

Acceptance Criteria:
1. If I choose to opt out of search suggestions from third party servers, when I type into Rocketbar my inputted string remains local on the device.

Note: Additional details will be provided after further discussion with Privacy team.
Assumptions:
1. UX spec to indicate where opt out will be accessible from.
Hi Peter -

What are the next steps here? Do we need to discuss with the privacy team? What's the timeline for doing so?

I'm wondering if we should unblock bug 946452 on this until we have something more actionable.
Flags: needinfo?(pdolanjski)
(In reply to Kevin Grandon :kgrandon from comment #1)
> Hi Peter -
> 
> What are the next steps here? Do we need to discuss with the privacy team?
> What's the timeline for doing so?
> 
> I'm wondering if we should unblock bug 946452 on this until we have
> something more actionable.

Hi Kevin,

I already kicked off discussions with them and our legal team.  We're looking at Fennec's solution and trying to determine what makes the most sense to move forward with.  I'm hoping to have something definitive in the next week.
Flags: needinfo?(pdolanjski)
I'm going to unblock the main meta bug until we have something more actionable here.
No longer blocks: rocketbar-search-mvp
Component: Gaia::System → Gaia::Search
Flags: in-moztrap?(jsmith)
No longer blocks: 1.4-systems-fe
Flags: in-moztrap?(jsmith)
Flags: needinfo?(fdjabri)
Attached file opt out_v2.pdf (obsolete) —
Initial proposal for review
Flags: needinfo?(fdjabri)
Whiteboard: [ucid:System153, 1.4:P2, ft:systems-fe] → [ucid:System153, 1.4:P2, ft:systems-fe][systemsfe]
User Story: (updated)
Francis / Peter - To confirm from our prior discussions, both Privacy and Legal are fine with Search Suggestions turned ON by default. 

Geoff and I reviewed and edited the copy for the contextual notices in Francis' proposal (attached in comment 4). We put the original and updated copy here:  https://docs.google.com/a/mozilla.com/document/d/1QpIfzklWhAAa3XpFQltQOCc_fKcEsetMN8sBz5FlI4Q/edit?usp=shaing

The copy on page 1 / screen 3 is fine as is - no changes. 

For the copy on page 2 / screens 3 and 4, we have a couple questions: 

1) Could the contextual notice text be implemented so that it changes depending on whether Search Suggestions is turned on or off? When the user goes to this setting, it will be default ON and the notice may read:

"Characters you type when entering a search are sent to our third party search partner and will be used to send you suggestions. Additional data charges may apply in certain areas for using this Search Suggestions feature." 

(We made a minor edits to the original text in Francis' proposal.) 
If the user turns the feature OFF, we suggest the copy may read something to the effect of: 

"The Search Suggestions feature will help you find things relevant to you if you turn it on."

(Copy to be wordsmithed. The idea is to describe the benefit of using the feature.) 

2) RE our suggested text above - "Additional data charges may apply in certain areas for using this Search Suggestions feature." - Does "in certain areas" make sense? Would it apply in all areas? Could you provide more information for how data charges would affect users? 

We can schedule a follow-up meeting to discuss if you would like.
Flags: needinfo?(fdjabri)
(In reply to Alina Hua from comment #5)
> 2) RE our suggested text above - "Additional data charges may apply in
> certain areas for using this Search Suggestions feature." - Does "in certain
> areas" make sense? Would it apply in all areas? Could you provide more
> information for how data charges would affect users? 

All areas is closer to the truth - data usage will cost our users money in almost every conceivable scenario (even wi-fi costs money in some parts of some of our markets).

The text should be explicit that the feature uses the data connection *when it is used* if search suggestions are on, and does *not* use the data connection when suggestions are off.

The user can then make an educated decision about whether to spend their money on that particular part of the Rocketbar feature.

It's a delicate thing - we don't want users to avoid the Rocketbar because they associate it with data charges :)
Hi, 

I'm not keen on changing the text depending on the user selection. It feels somehow as if we're hiding information - I'd prefer that we're open and upfront about all the information the user needs in order to make a decision. In any case, the first sentence of the current text seems to describe the benefit to users: "Characters you type when entering a search are sent to our third party search partner and will be used to send you suggestions".

I've updated the second sentence to emphasize that data charges are only applied if the feature is switched on. The complete text is now:

"Characters you type when entering a search are sent to our third party search partner and will be used to send you suggestions. Additional data charges may apply when using this feature". Let me know if you have any other suggestions. Thanks!
Flags: needinfo?(fdjabri)
Attached file Updated wireframe (obsolete) —
Attachment #8392413 - Attachment is obsolete: true
Catching up from above, the revised language is fine and works
Hmm, seems like this UX doesn't work with the new visuals in bug 1009401 (there's no E.me suggestion icon).

Also - what happens if you toggle the suggestions off? Would we just show an empty row with only an icon?
feature-b2g: --- → 2.0
Priority: -- → P1
Updated wires for the search suggestion settings and display prompt.
Attachment #8410580 - Attachment is obsolete: true
Assignee: nobody → bfrancis
Target Milestone: --- → 2.0 S3 (6june)
1. the spec https://bug948320.bugzilla.mozilla.org/attachment.cgi?id=8428023 shows a modal popup when you first start typing, with https://bugzilla.mozilla.org/show_bug.cgi?id=961675 landing we will also get a geolocation popup on the first launch of e.me. having 2 dialogs get in the way when you start trying to do something seems problematic.

2. Being able to use search provider suggestions is at risk, however even if that was implemented we would still be showing e.me results unconditionally in the app grid (lets call those recommendations) the e.me recommendations are useful and I think distinct from search suggestions, even when we implement provider search suggestions we wont be able to have search provider recommendations

#1 is a UI issue that can be figured out, but as I understand it #2 is a plain blocker
Flags: needinfo?(rmacdonald)
(In reply to Dale Harvey (:daleharvey) from comment #12)

Thanks Dale. I'll need to verify these issues with Francis. Also adding Jacqueline as an FYI.
Flags: needinfo?(jsavory)
Flags: needinfo?(fdjabri)
(In reply to Dale Harvey (:daleharvey) from comment #12)
> 1. the spec https://bug948320.bugzilla.mozilla.org/attachment.cgi?id=8428023
> shows a modal popup when you first start typing, with
> https://bugzilla.mozilla.org/show_bug.cgi?id=961675 landing we will also get
> a geolocation popup on the first launch of e.me. having 2 dialogs get in the
> way when you start trying to do something seems problematic.
> 

I think we can suppress the Geolocation popup as I think it's covered fully enough in the FTE Geolocation notice. Peter and I discussed this with Alina and she seemed satisfied with doing this. Peter, could you confirm? 

> 2. Being able to use search provider suggestions is at risk, however even if
> that was implemented we would still be showing e.me results unconditionally
> in the app grid (lets call those recommendations) the e.me recommendations
> are useful and I think distinct from search suggestions, even when we
> implement provider search suggestions we wont be able to have search
> provider recommendations
> 
> #1 is a UI issue that can be figured out, but as I understand it #2 is a
> plain blocker

I'm not sure I completely follow your point here - are you saying that if the user disables the search suggestions, then they will also disable the e.me recommendations? I'm not sure that there's a way around this from a privacy perspective. If the user doesn't want their keypresses being sent, then we can't provide either search suggestions or search recommendations.
Flags: needinfo?(fdjabri)
Does not block bug 1019906 as this is new functionality.
No longer blocks: 1019906
I would also argue that this is not really needed in 2.0, and possibly detrimental to the experience as we do not show history results. If they opt into this in 2.0 the only thing that would be searched is apps, which is a much worse experience than the E.me search bar in the current homescreen.
I agree that with it disabled we dont have a great user experience, but its a user choice which I agree is important, we cant really force users to send their data all over the place to use the device.

Just talked with Francis, from what I understand is the way forward 

If we disable search suggestions, both the suggestions and recommendations will be disabled (users will only search local apps)

The wording for 'search suggestions' enabled will be worded in a way that it isnt specific to the single search provider, since with it enabled we will be sending data to both the search provider and e.me

We should force the geolocation prompt to open as soon as the search app is opened as having it appear on user input is fustrating

The dialog informing users of how to configure search providers will be non modal and not interupt users

Francis is working on new specs and can correct if I made any mistakes
(In reply to Dale Harvey (:daleharvey) from comment #17)
> I agree that with it disabled we dont have a great user experience, but its
> a user choice which I agree is important, we cant really force users to send
> their data all over the place to use the device.

I agree with this, and I think that it also fixes the privacy issue that we have up to now that we send searches to e.me without any way to turn that off. :)
(In reply to Dale Harvey (:daleharvey) from comment #17)
> We should force the geolocation prompt to open as soon as the search app is
> opened as having it appear on user input is fustrating

But do we still need this prompt based on Francis's reply in comment #14? 
> I think we can suppress the Geolocation popup as I think it's covered fully
> enough in the FTE Geolocation notice. Peter and I discussed this with Alina
> and she seemed satisfied with doing this. Peter, could you confirm? 

The goal was to drop it as it caused confusion amongst users. Flagging Peter to confirm.
Flags: needinfo?(pdolanjski)
Flags: needinfo?(dale)
I am dont think it is possible to disable the location permissions prompt, its a fairly core part of our security architecture.
Flags: needinfo?(dale)
Actually it might be possible now that bug 1014410 has landed?
Here’s an updated spec based on the discussion I had with Dale: https://mozilla.box.com/s/5dy7gllr9k3xaro44d07.

Key points are:

- the search suggestions pop-up is non-modal and shown after 3 keystrokes. This will make it conflict less with the geolocation prompt.
- only one search suggestion setting is shown in settings that controls both search suggestions and e.me recommendations. The wording has been updated to state that key presses are sent to multiple search providers. 

Regarding the geolocation prompt - as Dale mentions,  the Geolocation prompt should be shown when the search app is first activated, rather than on first key press, to make it less annoying. The Geolocation prompt should also refer to “Search” rather than “Homescreen”.
User Story: (updated)
Flags: needinfo?(rmacdonald)
Flags: needinfo?(jsavory)
I've updated the visuals specs on box here:

https://mozilla.box.com/s/0i2j11d3odruziews0r7

Just a few changes:
- Positioning
- Updated to 2px rounded corners
- Corner of pop up updated to #2d2d2d @ 94% opacity

Let me know if you have any questions, thanks!
User Story: (updated)
(In reply to Eric Pang [:epang] from comment #23)
> I've updated the visuals specs on box here:
> 
> https://mozilla.box.com/s/0i2j11d3odruziews0r7
> 
> Just a few changes:
> - Positioning
> - Updated to 2px rounded corners
> - Corner of pop up updated to #2d2d2d @ 94% opacity
> 
> Let me know if you have any questions, thanks!

forgot to add that I removed the dark overylay
feature-b2g: 2.0 → ---
feature-b2g: --- → 2.1
Assignee: bfrancis → dale
Candice, am I missing something? I thought this feature was still targeted for 2.0?
Flags: needinfo?(cserran)
feature-b2g: 2.1 → 2.0
Flags: needinfo?(cserran)
(In reply to Ben Francis [:benfrancis] from comment #25)
> Candice, am I missing something? I thought this feature was still targeted
> for 2.0?

Yikes! I marked the wrong bug.  Meant to change flag for 3rd party suggestions but! apologies
No worries, I don't think we ever had a bug for that because it was never explicitly called out as a requirement. I've filed bug 1021779
Just an update for candice so you dont need to worry about this for the weekend, I split this into 2 seperate bugs as it was mostly different work, they both have patches up and I dont expect major problems with either in review

However both patches depend on https://bugzilla.mozilla.org/show_bug.cgi?id=1009358 landing (and possibly some follow up work on that), Its already r+'d so should hopefully be landing soon, and I have requested early review on my patches so will hopefully be able to land them shortly after
Also one of the patches will need some visuals, not sure if francis is around or not, he is needinfo'd but if hes gonna be unavailable then might need someone else on it: https://bugzilla.mozilla.org/show_bug.cgi?id=1022053
QA Whiteboard: [2.0-rocketbar-FL-blocking+]
As we discussed earlier today, I’ve now updated the spec to reflect that search suggestions will only be provided by e.me. 

I’ve uploaded this to Box at: https://mozilla.box.com/s/qbbhcsoaqwqwl9dce4mc

@Eric, please could you update the visuals and let me know if you have any questions.

@Peter, as all the search suggestions and recommendations are now both coming from e.me, I’ve updated the notice in the settings text to say: 

“The characters you type when entering a search are sent to the search provider - everything.me - and will be used to send you search suggestions. Additional data charges may apply when using this feature."

I’ve called out everything.me in the name of transparency, but please let me know if there’s any issue with this.
Flags: needinfo?(epang)
(In reply to Rob MacDonald [:robmac] from comment #19)
> (In reply to Dale Harvey (:daleharvey) from comment #17)
> > I think we can suppress the Geolocation popup as I think it's covered fully
> > enough in the FTE Geolocation notice. Peter and I discussed this with Alina
> > and she seemed satisfied with doing this. Peter, could you confirm? 
> 
> The goal was to drop it as it caused confusion amongst users. Flagging Peter
> to confirm.

We had an email thread on this.  The synopsis is that we can't use the geolocation screen as part of the FTE since that screen is really for opting into geolocation use, in general.  Instead we should be able to use the geolocation prompt with (hopefully) better results since it's now split into two apps (Search and Smart Collections).  This should be more clear to users.
Flags: needinfo?(pdolanjski)
(In reply to Francis Djabri [:djabber] from comment #30)
> As we discussed earlier today, I’ve now updated the spec to reflect that
> search suggestions will only be provided by e.me. 
> 
> I’ve uploaded this to Box at: https://mozilla.box.com/s/qbbhcsoaqwqwl9dce4mc
> 
> @Eric, please could you update the visuals and let me know if you have any
> questions.
> 
> @Peter, as all the search suggestions and recommendations are now both
> coming from e.me, I’ve updated the notice in the settings text to say: 
> 
> “The characters you type when entering a search are sent to the search
> provider - everything.me - and will be used to send you search suggestions.
> Additional data charges may apply when using this feature."
> 
> I’ve called out everything.me in the name of transparency, but please let me
> know if there’s any issue with this.

Updated Visual specs
https://mozilla.box.com/s/0i2j11d3odruziews0r7

removed the e.me icon and updated text.
Flags: needinfo?(epang)
Target Milestone: 2.0 S3 (6june) → 2.0 S4 (20june)
does this bug still involve landing of strings for 2.0?
(In reply to Eric Pang [:epang] from comment #32)
> (In reply to Francis Djabri [:djabber] from comment #30)
> > As we discussed earlier today, I’ve now updated the spec to reflect that
> > search suggestions will only be provided by e.me. 
> > 
> > I’ve uploaded this to Box at: https://mozilla.box.com/s/qbbhcsoaqwqwl9dce4mc
> > 
> > @Eric, please could you update the visuals and let me know if you have any
> > questions.
> > 
> > @Peter, as all the search suggestions and recommendations are now both
> > coming from e.me, I’ve updated the notice in the settings text to say: 
> > 
> > “The characters you type when entering a search are sent to the search
> > provider - everything.me - and will be used to send you search suggestions.
> > Additional data charges may apply when using this feature."
> > 
> > I’ve called out everything.me in the name of transparency, but please let me
> > know if there’s any issue with this.
> 
> Updated Visual specs
> https://mozilla.box.com/s/0i2j11d3odruziews0r7
> 
> removed the e.me icon and updated text.

I've updated the spec to include an expanded pop up.

https://mozilla.box.com/s/0i2j11d3odruziews0r7

This will allow for an extra line of text, if there is still not enough space the upper portion of the pop up becomes scrollable.

Please let me know if you have any questions. Thanks!
QA Whiteboard: [2.0-rocketbar-FL-blocking+] → [VH-FL-blocking+]
QA Whiteboard: [VH-FL-blocking+] → [VH-FL-blocking+][VH-FC-blocking+]
This was was split into its dependents which have both landed
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
User Story: (updated)
Depends on: 1026007
blocking-b2g: --- → backlog
Gaia      8df02268fcd7e80c5fab8c1ec099772e37f8659d
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/731a5e8831e6
BuildID   20140627000201
Version   32.0a2
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
B1TC00011220
Flame
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.