oAuth for ATT and oAth generally. What is the way forward?
unicorn.consulting at gmail.com
Sat Sep 28 01:03:07 UTC 2019
I am not suggesting we export the actual secret, more offer a drop down
where the user can insert say in their ATT mail that the oAuth provider
to use is Yahoo. (inclusion in the database would also be required for
the new account wizard to make the correct choice). This is perhaps not
technically correct usage, but it is how it is being implemented.
Between Google, Yahoo Microsoft the US market is basically being served
by those three providers. The large ISP email market is also included
with those three providing services for ATT, Verizon and AOL as well as
a multitude of domains they have taken over. Allowing the user to select
one of those three primary providers would basically make the US market
oAuth. Without needing t add 20 or 200 additional oAuth keys to
Thunderbird The UK market looks some what similar with BT, Sky at least
in the Yahoo camp. We are not going to see these ISP's having oAuth
tokens to use, which it why I am suggesting we make the provider user
In a similar issue Outlook has a TFA option that stops the login pending
the entry of the TFA code the user has received. This second thing is
not something I favour as such, but it does lead to the the inevitable
questions, where is our implementation. It is also a no brainer in a
world where actual knowledge about what one is doing is sadly lacking.
Most web mail users have been migrated to TFA. Just give them a box and
they go on their merry way without anyone having to try and explain app
passwords to them.
On 27-Sep-19 8:01 PM, Philipp Kewisch wrote:
> Hi Matt,
> for larger providers I think we should reach out, this is something
> the council can do. For smaller providers, I doubt the secret will be
> exposed to the customers. Therefore I'm not sure how useful it would
> be to expose this in the UI. Having something in about:config or even
> exposed through the MailExtensions API seems reasonable to me.
> Instead of having this in the source I'm wondering if we should
> instead deliver the secrets vis RemoteSettings. This way we can easily
> update keys as necessary without an extra release.
>> On 22. Sep 2019, at 6:25 AM, Matt Harris
>> <unicorn.consulting at gmail.com> wrote:
>> It is obvious from recent SUMO posts that ATT is pushing oAuth for
>> their customers. Probably at the behest of Yahoo. However ATT have
>> no oAuth secret. So I am posting to tb planning looking for feedback
>> on how we deal with the insidious oAuth contracts. It has been out
>> there for years that Frontier intend to withdraw other connection
>> methods <https://bugzilla.mozilla.org/show_bug.cgi?id=1293958#c25>.
>> It has also come to my notice recently that we simply do not support
>> oAuth for POP accounts at all.
>> So it is time for a coherent decision. Do we just leave these users
>> out in the cold, reach out to the parties concerned asking for their
>> non existent secrets, or do we modify the account manager to allow
>> the selection of a pre existing secret. Thunderbird offers a list of
>> providers whose keys Thunderbird has and let user input what ever
>> they like in the field. So BT, ATT, Verizon and Yahoo can set the
>> oAuth key to Yahoo.
>> I claim no knowledge of oAuth, but it is a reality and we need to
>> have some sort of policy on how this is to be done going forward.
>> The existing process of needing to create a separate arrangement for
>> BT, ATT, Verizon and Yahoo is going to become labour intensive and
>> always out of date.
>> Given dovecote is offering oAuth as an authentication method means
>> that oAuth will most likely become more common over time with small
>> providers. So what is it to be? how do we manage this?
>> “Against stupidity the gods themselves contend in vain.” /― Friedrich
>> von Schiller, Die Jungfrau von Orleans /
>> tb-planning mailing list
>> tb-planning at mozilla.org
“Against stupidity the gods themselves contend in vain.” /― Friedrich
von Schiller, Die Jungfrau von Orleans /
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning