Open Bug 763489 Opened 10 years ago Updated 2 months ago

Filelink: Add account auto config

Categories

(Thunderbird :: FileLink, enhancement)

16 Branch
enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: jb, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file, 4 obsolete files)

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.
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.
Attached image Sign-up workflow from the Compose window (obsolete) —
Making each section clearer.
Attachment #632729 - Attachment is obsolete: true
Making the sections clearer.
Attachment #632730 - Attachment is obsolete: true
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.
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
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
(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.
[-sec-review-needed]
re-branded TB BigFiles which we have already seen
(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.
ah, ok, I will put everything back then
(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.
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
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.
(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.
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.
Attachment #632733 - Attachment is obsolete: true
Attachment #632734 - Attachment is obsolete: true
Attachment #635432 - Attachment is patch: false
Attachment #635432 - Flags: feedback?(tom)
Attachment #635432 - Flags: feedback?(mbaz)
Attachment #635432 - Flags: feedback?(james)
Component: General → FileLink
QA Contact: general → filelink
Attachment #635432 - Flags: feedback?(briks.si)
Maxim, Tom, James and Brian - any thoughts on this?
Attachment #635432 - Attachment mime type: text/plain → application/pdf
Whiteboard: [sec-assigned:curtisk]
Flags: sec-review?(curtisk)
Whiteboard: [sec-assigned:curtisk]
is this feature still alive or has it gone to the land of dust bunnies with the change over to community support?
Flags: needinfo?(nobody)
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.
Flags: needinfo?(nobody)
bug 764561 resolved-incomplete for now, please reopen the bug if this feature starts moving again
Attachment #635432 - Flags: feedback?(bking)
Flags: sec-review?(curtisk) → sec-review?
Severity: normal → enhancement

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?

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.

Blocks: 1532957
You need to log in before you can comment on or make changes to this bug.