1106854 - Firefox Hello: Can't import contacts from Google on Linux using distro versions of Firefox

Status: RESOLVED WONTFIX

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

Description

[rosendeh]

Attachment: Screenshot - 021214 - 17:42:41.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141127111021

Steps to reproduce:

I enabled firefox hello in linux mint 17 - Qiana and tried to import contacts from Google


Actual results:

A new window opens indicating an error

401. That’s an error.
Error: invalid_client
The OAuth client was not found.
Request Details
    scope=https://www.google.com/m8/feeds
    response_type=code
    redirect_uri=urn:ietf:wg:oauth:2.0:oob:auto
    client_id=no-google-oauth-api-clientid
That’s all we know.


Expected results:

Contacts should be imported from Google.

Comment 1

[jorgeml]

Same thing for me (Firefox 34.0 with Fedora 21).

Comment 2

[Iakovos Gurulian]

Same for me on Ubuntu 14.10 / Firefox 34.

Comment 3

[Adam Roach [:abr]]

This looks like an issue with the downstream OAuth setup. The basic steps are here: https://wiki.mozilla.org/Loop/OAuth_Setup

Lawrence: do you know who our contacts are at our downstream projects? We need to reach out to them and let them know about this new requirement on their builds...

Comment 4

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Adam Roach [:abr] from comment #3)
> Lawrence: do you know who our contacts are at our downstream projects? We
> need to reach out to them and let them know about this new requirement on
> their builds...

Lukas - Do you have a list of downstream projects and contacts?
Sylvestre - You're plugged in to some of the Linux distros. Can you help here?

Comment 5

[Lawrence Mandel [:lmandel] (use needinfo)]

catlee - Does releng maintain a list of downstream projects and do you have contacts?

Comment 6

[Eugene Crosser]

I've opened this ticket in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1401402

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Usually, the way to do that is to update the configure to add a check on this. It will notify packagers about that.
n-i Mike for Debian (and our build system) in case he can help.

Comment 8

[Mike Hommey [:glandium]]

Sigh... one more API ID that distros can't use and that breaks features... We should probably make all the associated flags (not only this particular one, but all of them) fail to build when building with --enable-release (which distros should be using)... because failing for local developers build is not going to pan-out. Then the choice whether to add an api key or not is in the maintainer's hands, so even if they decide not use the API key, at least they are aware of it. Although I could see this as annoying... I don't know.

With my Debian hat on, iirc, most if not all of those API IDs can't be used in distros because they have to be "hidden". (that's why they're not in mozilla-central to begin with)

Now, for this specific case, I'd advise removing the import feature instead of having weird errors when Firefox doesn't have the corresponding key.

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

Afaik there is not a list of downstream projects - would be great to have one though.

Comment 10

[Wolfgang Rosenauer [:wolfiR]]

oauth keys are a pain indeed for Linux distributions and in case of openSUSE cannot added at all since it's not possible to keep the keys secret as the whole build process and sources are completely open. I agree with Mike that the feature should be hidden/disabled if no oauth api keys are configured/built in.

Comment 11

[Adam Roach [:abr]]

(In reply to Mike Hommey [:glandium] from comment #8)
> Now, for this specific case, I'd advise removing the import feature instead
> of having weird errors when Firefox doesn't have the corresponding key.

I agree that the current behavior isn't okay. I've opened a bug to do something better, with room to discuss what "better" looks like (Bug 1110508)

Comment 12

[Adam Roach [:abr]]

(In reply to Sylvestre Ledru [:sylvestre] from comment #7)
> Usually, the way to do that is to update the configure to add a check on
> this. It will notify packagers about that.

As we were adding this new OAuth key to the build system, we did a lot of digging around for "what had been done before," including talking to releng pretty extensively and close examination of similar code landings (e.g., build system support for our geoloc API key). This didn't come up.

I know we're not trying to encourage a proliferation of secret material here, but for those cases in which we don't have a choice (like this one), it would probably be a Good Thing if we had a wiki page that captured all the collected lore on Best Current Practices.

Sylvestre: You seem to have some knowledge here. Do you have enough of an understanding of what Mozilla-specific steps need to take place in these kinds of cases to take a first stab at such a page? Or were you speaking about project behavior in general rather than from a Moz perspective?

Comment 13

[Sylvestre Ledru [:Sylvestre]]

I am sorry but I was talking in a more general perspective. However, Mike, in comment #8, explained that issue.

Comment 14

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Lukas Blakk [:lsblakk] use ?needinfo from comment #9)
> Afaik there is not a list of downstream projects - would be great to have
> one though.

To follow up on this, I've given myself a Q1 goal to create this list. If you're redistributing Firefox, please ping me as I'll be collecting distros and trying to find at least one contact for each.

Comment 15

[:shell escalante]

requires outreach and private key for contact imports.  will require working with folks who are just going to be hard to get through holidays.

will loop back with catlee based on comment

Comment 17

[Chris Coulson]

The next Firefox update on Ubuntu will have this fixed

Comment 18

[Rémy Hubscher (:natim)]

Thanks Chris.

Comment 19

[Mike Hommey [:glandium]]

(In reply to Chris Coulson from comment #17)
> The next Firefox update on Ubuntu will have this fixed

How are you fixing this?

Comment 20

[Chris Coulson]

We have our own OAuth ID + key (and Google API key for geolocation / safe-browsing) used for both Firefox and Chromium. They're not hidden, and it doesn't look like we're the only distribution doing that (I found public keys in Gentoo as well)

Comment 21

[Mike Hommey [:glandium]]

If every distro uses a different key, then Google can distinguish which distro users are using. Wouldn't that qualify as a privacy breach? IIRC, we explicitely don't send the google cookie for safebrowsing. If we don't do that for geoloc, that would seem like a bug. OTOH, they can probably correlate with the google cookie the user is already using in the same browser... So while using a different key means more information available to google, is it actually making things worse than they already are?

That being said, doesn't shipping those keys in the source packages in distros breach their TOS?

Comment 22

[Felipe Lerena]

Same here on the ppa ubuntu build
36.0a2 (2014-12-15)

Comment 23

[[e-mail]]

Same for me, 
Ubuntu 14.10, (2015-feb-25)

Comment 24

[Sylvestre Ledru [:Sylvestre]]

Tracking as it is a user facing error for our GNU/Linux users (but this can indeed wait for 38).

Comment 25

[Sylvestre Ledru [:Sylvestre]]

Shell, do we have plans for this bug? Thanks

Comment 26

[Sylvestre Ledru [:Sylvestre]]

Unfortunately, it is too late for 38... and it does not affect our binaries. So, untracking + wontfix for 38.

Comment 27

[Mark Banner (:standard8)]

We are currently reworking the Loop "user journey" (bug 1209713) and as part of this direct calls and contacts are being removed. Therefore closing contact related bugs as wontfix.

Tracking id: contactuserjourneyclosing