Closed Bug 1015891 Opened 5 years ago Closed 5 years ago

Desktop client needs to let a non signed-in user accept the ToS and privacy notice

Categories

(Hello (Loop) :: Client, defect, P1)

defect

Tracking

(firefox33 verified)

VERIFIED FIXED
mozilla33
Tracking Status
firefox33 --- verified

People

(Reporter: RT, Assigned: andreio)

References

Details

(Whiteboard: p=1)

User Story

As a non signed-in user, I want to accept the ToS and privacy notice so that I am aware of it and can start using Loop.

Attachments

(5 files, 3 obsolete files)

A non signed-in user is required to accept the ToS and privacy notice prior to be able to share a URL.
Once accepted, the user won't have to accept it again to share other URLs unless the ToS and privacy notice changes.
User Story: (updated)
I'm concerned that having something this prominent is likely to hurt our customer acquisition funnel a bunch, and create an unpleasant feel for the user, since the biggest, most central piece of UI in front of them sounds like it's a lawyer talking.  I completely understand that there are meaningful ToS/privacy concerns that we need to deal with, but I'm wondering if it would make sense to do this in a gentler way.
Attached image Hangouts are go!
I would agree with Dan that there should be a way to onboard the Desktop Loop user without introducing a lot of legalese and friction while being Mozilla and protecting their privacy and sovereignty. See attachment for comparison.
Hey, I'm all for making this as pleasant as possible for the user as well. Perhaps we should develop some alternate proposals that we can discuss with legal?
Attached image non-blocking-tos-pn.png
Do we need to block on the TOS/PN? We don't do this on Firefox Accounts, so I doubt we'd need to here. It feels like we're adding a lot of unnecessary overhead for users by doing so.

Attached a proposal for an alternative.
FYI more details from Geoff on the legal side received by e-mail:
Text to be used: "By using this [Mozilla Web RTC product], you agree to the Mozilla Terms of Use and Privacy Notice."
Placement can be unobtrusively below the initiate call buttons in the window.

Geoff can you confirm that this can be FTU only?
Flags: needinfo?(gpiper)
Isn't the need to have a possibly combined ToS mean that we should not call out the specific WebRTC product down below?  I think we are still working out how to present ToS that includes Loop. So I think a more general statement should do for now.
The copy is somewhat dependent on naming of this product which at this moment I don't believe that has been settled yet. The exact word choice would probably be up to that input. 

It seems we need to sync again on the types of users and the ways we will treat the terms of use and privacy notices. I spoke with Bill yesterday and I also had a good meeting with Darrin, Ryan, John and Chris on this topic too but seems we should reconvene to be clear. Romain, would you lead a meeting to sync on this?

Chris and I also have a meeting with Jess Davis to discuss email notification practices/choices for Firefox account holders (whether existing and new) relating to modifications to the terms. 

I believe the copy below, slightly revised again to handle this period where we are unsure of the product name, can be used for Nightly for the non-account user calls (initiator and receiver) and I believe Darrin has created mock ups of where it will be placed:

"By using this product, you agree to these Terms of Use and Privacy Notice" 

[Terms of Use and Privacy Notice are hyperlinks to webpages displaying the applicable content]

As before, placement can be unobtrusive. This applies to both initiator and receiver.

I have thought a lot about the displaying this for the first time user only (and not subsequent uses), and I believe there are situations (like PCs at public libraries for example) where technically the IP address may not be the same user in each call. So, I would like to hear more about why we should not use the copy in all cases for the non-account holders scenarios.
Flags: needinfo?(gpiper)
Meeting arranged for tomorrow to discuss.
Duplicate of this bug: 1019567
As per discussions, Geoff will confirm with Denelle if we're OK with the approach proposed by Darrin on [1] for account-less mode (considered low user risk / high UX value).

[1] https://people.mozilla.org/~dhenein/labs/loop-mvp-spec/
Flags: needinfo?(gpiper)
1) For Nightly, for our Non-FxA holders, for both initiator and receive, we should present the following copy to each first time user:
"By using this product, you agree to these Terms of Use and Privacy Notice" 

[Terms of Use and Privacy Notice are hyperlinks to webpages displaying the applicable content]

2) For general release, for our non-FxA holders, for both initiator and receive, we should present the same copy and add the OK or click action like a check box to get their actual consent.

I believe we still have meetings slated to iron out the treatments for FxA holders. Those meetings are pending next week I believe.
Flags: needinfo?(gpiper)
Attachment #8428614 - Attachment is obsolete: true
Attached image FTU ToS
For FTU display legal text
Attached image non FTU ToS
When the user has already share a URL in the past, no need to display the legal text anymore.
Whiteboard: p=? → p=1
Assignee: nobody → andrei.br92
Geoff/Romain, I'm assuming the Terms of Use and Privacy Notice links will be to web pages that live on the mozilla.org site itself.  Is that correct?  If so, when/how do we figure out what the exact links for those pages should point to?
Flags: needinfo?(rtestard)
Flags: needinfo?(gpiper)
I'm emailing Mark Mayo asking where we host internally and how to get the links and copied Dan and Andrei.
Flags: needinfo?(rtestard)
Flags: needinfo?(gpiper)
(In reply to sescalante from comment #16)
> I'm emailing Mark Mayo asking where we host internally and how to get the
> links and copied Dan and Andrei.

Shell, unfortunately internal links aren't going to work, since this will be landed in Nightly.  That said, if the links just 404 until some future date when the docs are finished and they're pushed live, that doesn't seem terrible to me.
Target Milestone: mozilla33 → 33 Sprint 1- 6/23
Comment on attachment 8442495 [details] [diff] [review]
implements ToS view

Review of attachment 8442495 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.  Please update the patch addressing the comments here as discussed, and then you'll have r=dmose.  Once the dependent bug (setLoopCharPref) gets fixed, then the next step will be to make sure it actually works as expected, upload a screenshot, and request ui-review on that screenshot from :darrin.

::: browser/components/loop/content/shared/css/panel.css
@@ +83,5 @@
> +.tos {
> +  font-size: .6rem;
> +  color: #a8a8a8;
> +  text-align: center;
> +  padding: 1em;

Please make this rems also to match the font-size.

::: browser/components/loop/loop.iml
@@ +5,5 @@
> +    <content url="file://$MODULE_DIR$" />
> +    <orderEntry type="inheritedJdk" />
> +    <orderEntry type="sourceFolder" forTests="false" />
> +  </component>
> +</module>

Please remove this file from the patch and just put it in your .gitignore, since it's an IntelliJ artifact.

::: browser/components/loop/standalone/content/config.js
@@ +1,2 @@
> +var loop = loop || {};
> +loop.config = {serverUrl: 'http://localhost:5000'};

Please add this to the browser/components/loop/.gitignore and remove it from the patch.

::: browser/components/loop/test/desktop-local/panel_test.js
@@ +4,5 @@
>  
>  /*global loop, sinon */
>  
>  var expect = chai.expect;
> +var fakeSeenToSPref = 0; // simulate a seenToS pref

Please move this down into the appropriate describe block.

@@ +46,5 @@
>        },
>        get locale() {
>          return "en-US";
> +      },
> +      setLoopCharPref: sinon.stub(),

sandbox.{stub,spy} etc is a good habit to get into because these are automagically cleaned up by the sandbox.restore().

@@ +55,5 @@
> +        if (fakeSeenToSPref == 0) {
> +            return null;
> +        }
> +        return 'seen';
> +    })

Avoid the overhead of a stub by just putting the body of this function in the original functional declaration.

@@ +390,5 @@
> +        expect(navigator.mozLoop.setLoopCharPref.callCount).to.equal(0);
> +
> +      });
> +
> +    });

Please clean up the whitespace and notCalled bits as we've discussed.

::: browser/locales/en-US/chrome/browser/loop/loop-l10n.iml
@@ +1,1 @@
> +<?xml version="1.0" encoding="UTF-8"?>

Please remove from the patch.
Attachment #8442495 - Flags: review?(dmose) → review+
Comment on attachment 8442582 [details] [diff] [review]
implements ToS view

Review of attachment 8442582 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/locales/en-US/chrome/browser/loop/loop.properties
@@ +13,5 @@
>  do_not_disturb=Do not disturb
>  incoming_call=Incoming call
>  accept_button=Accept
>  decline_button=Decline
> +legal_text_and_links.innerHTML=By using this product you agree to the <a \

This should get a localization note explaining about maintaining the URL and that the bits between {{...}} get replaced.

If you search for LOCALIZATION NOTE you'll see plenty of examples in the code.
For the Privacy link use: www.mozilla.org/privacy/
Attachment #8448899 - Attachment description: implements ToS view → implements ToS view. r=dmose
Oh, ftr, I used a slightly more descriptive checkin message so that folks knew what the ToS was for etc:

"Implement ToS and privacy notice links for Loop"
https://hg.mozilla.org/mozilla-central/rev/1e82422c6d81
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: 33 Sprint 1- 6/23 → mozilla33
Depends on: 1034841
Depends on: 1035846
This seems to be fixed in FF 33, but I don't see the ToS and privacy notice in Aurora 33.0a2 (2014-07-29). Why?
Flags: needinfo?(andrei.br92)
(In reply to Paul Silaghi, QA [:pauly] from comment #29)
> This seems to be fixed in FF 33, but I don't see the ToS and privacy notice
> in Aurora 33.0a2 (2014-07-29). Why?

You'll only see it on first display, as per comment 12. If you want to see it again, you need to reset your "loop.seenToS" pref.
Flags: needinfo?(andrei.br92)
Thanks for the info.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.