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

Status: VERIFIED FIXED

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

Description

[Romain Testard [:RT]]

Attachment: ToS and privacy notice acceptance mock-up

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.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 2

[Bill Maggs (bmaggs)]

Attachment: Hangouts are go!

Comment 3

[Bill Maggs (bmaggs)]

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.

Comment 4

[Darrin Henein [:darrin]]

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?

Comment 5

[John Gruen [:jgruen]]

Attachment: 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.

Comment 6

[Romain Testard [:RT]]

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?

Comment 7

[Bill Maggs (bmaggs)]

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.

Comment 8

[Geoff Piper]

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.

Comment 9

[Romain Testard [:RT]]

Meeting arranged for tomorrow to discuss.

Comment 11

[Romain Testard [:RT]]

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/

Comment 12

[Geoff Piper]

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.

Comment 13

[Romain Testard [:RT]]

Attachment: FTU ToS

For FTU display legal text

Comment 14

[Romain Testard [:RT]]

Attachment: non FTU ToS

When the user has already share a URL in the past, no need to display the legal text anymore.

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

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?

Comment 16

[:shell escalante]

I'm emailing Mark Mayo asking where we host internally and how to get the links and copied Dan and Andrei.

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

(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.

Comment 18

[Andrei Oprea [mention me on [e-mail]]]

Attachment: implements ToS view

Comment 19

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 20

[Andrei Oprea [mention me on [e-mail]]]

Attachment: implements ToS view

Comment 21

[Mark Banner (:standard8)]

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.

Comment 22

[:shell escalante]

For the Privacy link use: www.mozilla.org/privacy/

Comment 23

[Andrei Oprea [mention me on [e-mail]]]

Attachment: implements ToS view. r=dmose

Comment 24

[Dan Mosedale (:dmosedale, :dmose)]

https://tbpl.mozilla.org/?tree=Try&rev=e037e4e6e64c

Comment 25

[Dan Mosedale (:dmosedale, :dmose)]

The correct one: https://tbpl.mozilla.org/?tree=Try&rev=a8ac877f9d46

Comment 26

[Mark Banner (:standard8)]

https://hg.mozilla.org/integration/fx-team/rev/1e82422c6d81

Comment 27

[Mark Banner (:standard8)]

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"

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1e82422c6d81

Comment 29

[Paul Silaghi, QA [:pauly]]

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?

Comment 30

[Mark Banner (:standard8)]

(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.

Comment 31

[Paul Silaghi, QA [:pauly]]

Thanks for the info.