763489 - Filelink: Add account auto config

Status: NEW

(Thunderbird :: FileLink, enhancement)

Description

[Jb Piacentino]

Filelink account creation should implement auto-config, in the same way Acccount Provisioner works, i.e return the credentials to configure the account, once the creation is complete. 

Since there is not standard to describe Filelink accounts, each providers' code should be responsible for interpreting the returned data and configure TB accordingly (maybe there is a need for an extra Filelink account creation TB API here).

Account auto-config is optional, although strongly encouraged to improve user experience and conversion.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

So there are two ways of getting to the "Set up Filelink" dialog.

1)  From the compose window. The compose window is non-modal, and does not block the 3pane. A sign-up content tab could easily be opened and focused in the 3pane. Once sign up is completed, we return to the compose window (which is still blocked by the "Set up Filelink" dialog), to either:

a)  Tell the user that something went wrong during the sign up.
b)  Automatically log in for the user.

2)  From the preferences dialog. On some platforms (Windows at least), the preferences dialog blocks the opener (which, I believe to be the 3pane in almost all cases).

What we could do here is, when the user has indicated that they'd like to sign-up for an account, we close the "Set up Filelink" and preferences dialogs, and open the sign-up content tab in the most recent 3pane, and then focus it. When the sign-up procedure finishes, we respawn the preferences dialog and "Set up Filelink" dialog to, again:

a)  Tell the user that something went wrong during the sign up.
b)  Automatically log in for the user.

Those are my current thoughts, anyhow.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Attachment: Sign-up workflow from the Compose window

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Attachment: Sign-up workflow from the Preferences dialog

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Attachment: Sign-up workflow from the Compose window

Making each section clearer.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Attachment: Sign-up workflow from the Preferences dialog

Making the sections clearer.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

As this involves (possibly) sending user information to third-parties, as well as evaluating the response from those third-parties at the chrome-level, I think this feature request warrants both privacy and security review.

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Just working out the details of the communications protocol between Thunderbird and the storage services. Currently in flux - viewable here: https://etherpad.mozilla.org/FilelinkAutoconfig

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Looping in security and privacy folks, since I have a few questions, and I'd rather get their input sooner rather than later.

Privacy:

One thing we'd like to do is auto-complete as many fields as possible for the user when the order form is loaded. This would likely be fields for an email address and a name.

Instead of passing those values to the service for *them* to pre-populate the form with, would it be preferable for us to attempt to pre-populate the fields on the client-side?

Or can we assume that if the user has decided to sign up for the service, that they're OK sending that information?

Security:

With the current proposal, we'd be receiving and interpreting a JSON string from our third-party partners, and using it to tweak prefs at the chrome-level.  Does that sound kosher?

-Mike

Comment 9

[Sid Stamm [:geekboy or :sstamm]]

(In reply to Mike Conley (:mconley) from comment #8)
> Instead of passing those values to the service for *them* to pre-populate
> the form with, would it be preferable for us to attempt to pre-populate the
> fields on the client-side?

Yes.  We should let the user see and correct the data before submitting them to the server.

> Or can we assume that if the user has decided to sign up for the service,
> that they're OK sending that information?

I don't think we should make assumptions, especially about peoples' willingness to share their email, name, etc.  While the users may have consciously decided to sign up, they may not have thought through what information is required to register.

Comment 10

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

[-sec-review-needed]
re-branded TB BigFiles which we have already seen

Comment 11

[Blake Winton (:bwinton) (:☕️)]

(In reply to Curtis Koenig [:curtisk] from comment #10)
> [-sec-review-needed]
> re-branded TB BigFiles which we have already seen

Just a note: We're adding some new behaviour here, which is why we requested another sec-review.  Specifically we'll be adding the ability to sign up for, and auto-configure, a file sharing account from within Thunderbird.  I hope there aren't any security bugs in this new communication we're proposing, but since it's a whole new set of data coming from third parties that we would be using to configure Thunderbird, we figured it might be worth someone from the security team taking a quick look…

Thanks,
Blake.

Comment 12

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

ah, ok, I will put everything back then

Comment 13

[Mike Conley (:mconley) (:⚙️)]

(In reply to Sid Stamm [:geekboy] from comment #9)
> (In reply to Mike Conley (:mconley) from comment #8)
> > Instead of passing those values to the service for *them* to pre-populate
> > the form with, would it be preferable for us to attempt to pre-populate the
> > fields on the client-side?
> 
> Yes.  We should let the user see and correct the data before submitting them
> to the server.
> 
> > Or can we assume that if the user has decided to sign up for the service,
> > that they're OK sending that information?
> 
> I don't think we should make assumptions, especially about peoples'
> willingness to share their email, name, etc.  While the users may have
> consciously decided to sign up, they may not have thought through what
> information is required to register.

Excellent, OK, good to know.

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Cc'ing representatives from YouSendIt, UbuntuOne and SpiderOak for feedback.

James, Tom, Maxim:

When you have a second, take a look at the Etherpad I've been working on (https://etherpad.mozilla.org/FilelinkAutoconfig) - it's a rough spec, but it gives you an idea of where I'm going with this.

I'd love to hear your feedback,

-Mike

Comment 15

[James Henstridge]

At the moment, our account signup procedure requires an email address verification step.  For sign up via the web, this involves following a link in an email message.  For our desktop client sign up, it involves pasting a code from an email message into the client.  I'm not sure how either of those methods would easily fit into this work flow.

I know there have been discussions about relaxing this requirement since not all users of our SSO require this level of checking, but I don't believe it is being worked on right now.

Comment 16

[Mike Conley (:mconley) (:⚙️)]

(In reply to James Henstridge from comment #15)
> At the moment, our account signup procedure requires an email address
> verification step.  For sign up via the web, this involves following a link
> in an email message.  For our desktop client sign up, it involves pasting a
> code from an email message into the client.  I'm not sure how either of
> those methods would easily fit into this work flow.
> 
> I know there have been discussions about relaxing this requirement since not
> all users of our SSO require this level of checking, but I don't believe it
> is being worked on right now.

Hm, that's good to know - I hadn't considered that possibility. Now that I think about it, I think the other two services do the same kind of verification.

Ok, back to the drawing board. Back soon with some options.

Comment 17

[Mike Conley (:mconley) (:⚙️)]

Attachment: Sign-up workflow from Compose window - interactive wireframe

Alright, I've come up with a possible solution for the email verification problem.

Without going into too many details just yet, Thunderbird will wait for an email to arrive with a special set of headers. The headers will contain a key that Thunderbird will insert into URL template (hard-coded into the nsIMsgCloudFileProvider implementation). Thunderbird will then automatically follow that link, verifying the account for the user.  At that point, the providers will return the JSON blob necessary to set up the account.

The dialog that takes care of auto-verification / configuration is an in-content dialog that Thunderbird will take care of; providers will not need to implement this.

That's the general workflow, anyhow. The interactive wireframe will (hopefully) make the experience a bit clearer.

Instructions to use the wireframe:

1) Open in a PDF viewer in full screen on the first page
2) The sections highlighted in pink are clickable, and will take you from page to page
3) The links that appear *below* the "Setting up your new Service X account" dialog are to trigger behaviour, and are not actually part of the UI.

All feedback welcome.

Comment 18

[Mike Conley (:mconley) (:⚙️)]

Maxim, Tom, James and Brian - any thoughts on this?

Comment 19

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

is this feature still alive or has it gone to the land of dust bunnies with the change over to community support?

Comment 20

[Blake Winton (:bwinton) (:☕️)]

I'm not entirely sure what would happen to it in the land of dust bunnies, or how it's any less alive than any other feature the community might work on…

Having said that, I don't know of anyone pushing it forward currently, so feel free to remove the sec-review? flag for now, and when someone picks it up, we can re-request.

Comment 21

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

bug 764561 resolved-incomplete for now, please reopen the bug if this feature starts moving again

Comment 22

[John Bieling]

A lot has changed in the last 8 years. I do not see an option to add cloudFile accouts from the compose window anymore, only from the preference page. Also, the setup process of cloudFile accounts is delegated to the individual cloudFile add-on.

Is this bug still valid?

Comment 23

[Magnus Melin [:mkmelin]]

Kind of, after bug 1532957 we could autodetect using DNS SRV records. For other types, I would think we don't want to do anything.