Closed Bug 989756 Opened 10 years ago Closed 7 years ago

Custom server configuration UI for Sync and Firefox Accounts

Categories

(Firefox :: Sync, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: oliver, Unassigned)

References

Details

User Story

Firefox supports custom Sync (and FxA) servers. This bug is only for exposing that configuration in more polished UI.


Here's how to run your own Sync server:

https://docs.services.mozilla.com/howtos/run-sync-1.5.html


Here's how to run your own Firefox Accounts server (much harder):

https://docs.services.mozilla.com/howtos/run-fxa.html#howto-run-fxa


Both of those guides include documentation for how to configure desktop Firefox. If you're only self-hosting storage, you just need to set identity.sync.tokenserver.uri. If you're self-hosting FxA+token+Sync, you can use the autoconfig URL.

See those docs for more details.
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140319120302

Steps to reproduce:

I want to create a Firefox Account on a custom server. I have my own Firefox Accounts server using ownCloud in combination with the mozilla_sync app [1].

[1] https://github.com/owncloud/mozilla_sync


Actual results:

It is not possible to configure a custom Firefox Accounts server in Firefox 31.0a1.


Expected results:

It should be possible to use a custom Firefox Accounts server. This could be done via a checkbox ("Use custom server") and then specifying a custom server URL.

This worked for the previous Sync implementation.
+1 please give that option back

I don't wanna give you all my data...sry
The feature of adding your own sync server is a key feature. Since you will sync your password, saving them on your own server does make sense.

I am using this feature with owncloud's mozilla_sync for a long time, I am happy with it and I would like to use it also in the future.

Please keep this feature in Firefox also in future versions.

Thanks :-)
Self-hosted sync servers is^W was one of the great things of Mozilla, and in the spirit of "...making the web better and more open for all" as you yourself say.
Please don't take away that option.
Dear Mozilla/Firefox sync developers, please do not remove the feature to use custom servers. It's a highly anticipated feature used by many users that are concerned about privacy.
+1 for holding the custom sync server feature
Status: UNCONFIRMED → NEW
Ever confirmed: true
The issue is caused due to the switch to a new synchronization platform. Unfortunately that deprecates the current self-hosted servers. The solution, of course, is to liberate the new code and refactorize it to become usable in any given server.
@Carlos: The code is already open source at https://github.com/mozilla/fxa-content-server, https://github.com/mozilla/fxa-auth-server/

The real problem is as described: The Firefox Beta with the new system, as well as Firefox for Android, don’t provide a way for people to use their own content server. (In Firefox Beta it’s apparently possible to put in a custom URL using about:config, but that can’t be the real solution.)

There is an API defined: https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md and we plan to implement it in ownCloud with the mozilla_sync app. But for that to even make sense, Firefox needs to provide this way to use a custom server.
Please, bring back the possibility to use a custom sync server.
+1 :+1: (y) Please bring this possibility back to use a custom sync server easily.

Do not lock-in Mozilla Firefox into a closed mandatory eco-system. It would get over a very bad message from Mozilla to Firefox users and bring very bad publicity to Firefox unneededly. Chrome and Safari are just waiting for such bad news.

With revelations from NSA activities, unfortunately, nobody can trust any cloud, including Mozilla's own cloud, as secured as it certainly is. That is not Mozilla's fault, but just how bad things are today with NSA.

Open Source rocks, but Open Source with Closed data does not.

Thanks for listening and fixing this bug before releasing.
I was about to file a bug about mobile/tablet version of firefox for android (v28) making it very difficult to configure your own sync server, when I found this bug.  (Being difficult because you have to enter a recovery password and have to make it up, without having any hint of the format of the password or lenght or anything else. I ended copying a recovery password from a desktop installation, where you have a link to automatically generate one)
 
Having the option to use my own sync server is crucial for me. Disabling this option or hiding it away is (in my oppinion) as if you would force us to use a mozilla given accout for our mail in Thunderbird.

The main reason for me to use Firefox is Mozilla's privacy policies and I see this as a step in the wrong direction.

Thanks for hearing an otherwise very happy Firefox/Thunderbird user.
I want back my data on mon own server too.

You can see little how to here https://docs.services.mozilla.com/howtos/run-fxa.html

I want how to but easy how to, it's to hard today ;)
Thanks, everyone, for your comments. I appreciate your investment in this.

I'd like to take a moment to point out Bugzilla Etiquette:

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Please don't leave "+1" comments. It slows things down, rather than speeding them up.


Everyone involved with building out FxA and Sync is aware that there's currently no UI for configuring self-hosted servers, particularly on Android.

In the interest of clarity, there are some complications here that you might not have thought of. These make the "just throw in a checkbox" solution less attractive than it first appears.

* Does one host only a Sync server, or a whole private Accounts instance (auth, content, etc.)? If the former, how does a client know which Sync server to use (there's no server-side service discovery yet), and does it meet your security/privacy/isolation needs (because it would still depend on Mozilla's production FxA setup)? If the latter, how can you also use FxA-powered services like Marketplace, given that the client only supports one Firefox Account?

* What's the right UI to use here? Is this something we want to expose to mainstream end users at all, or is a 'side-config' the right way to go? We don't want to end up with confused users with their data split across two servers.

* Is it sufficient to say "here's the source", or do we need a better distribution mechanism?

* Is the security model for FxA suitable as-is for unaudited shared hosting?


It's important that we have a well-thought-out story here before moving forward -- it would be unfortunate if we shipped something that would leave you in a broken state in the future, and the short-term priority has been supporting the 99.9% of users that are happy to use free Mozilla-hosted encrypted storage, so we're not going to rush to get to a false ideal of parity.

In short: people are working on it, some kind of solution will arrive in a future release, and in the mean time you can hack something together using about:config on desktop. But no more +1 comments, please.

Thanks!
I have several thoughts on this subject which I was composing when Richard Newman's comment came in.  I'll post these after this comment:

"... how can you also use FxA-powered services like Marketplace, given that the client only supports one Firefox Account?"

Any "account" type system hosted under Windows or Linux has different permissions/security options applied depending on the account users situation.  I believe Firefox Account (Persona) needs to do the same or better if it is going to be applied to "Internet Access" to multiple server resources.

As for "how" this might be accomplished, look at how other internet services for information operate, take DNS as an example.  DNS looks at the local server for Domain/IP associations.  If they don't exist on the server, then the DNS request is passed up the chain.  Also, DNS caches recent lookup values to prevent upstream services from being hammered with every request.

This concept might be modified to lookup local login permissions, and submit a non-blocking query to an upstream server for any additional "non-local" permissions.  And as always, if this information is cached, there must also be a way to expire this information based on both expire time and forced manual request to do so.
I believe the issue of self hosted sync and accounts is one of having a choice of autonomy for both privacy and independent function from "none" to "complete".  Removing this autonomy and personal choice is a giant step backwards from all Mozilla's earlier efforts to make "Sync" safe and secure for -all- users.

"There's no guarantee that the Internet will remain open or enjoyable or safe." From Mozilla.org/about/history  Your internet connection could be disrupted for any number of reasons;  Sun spots, Terrorism, Control (business agenda's; like Mozilla's decision to remove self hosted sync to promote and force use of Persona), Political (like China's tightly controlled internet, and current US proposals to close internet boarders {similar to China}).  For all these reasons and more, I need Sync, Persona, and any other Mozilla features to still work with my own in-house services/servers across multiple domains even if/when my Internet connection is unplugged/non-functional.  Don't let Mozilla's marketing zeal cripple Firefox/Thunderbird ability to operate under any of these conditions which might require complete autonomy. I currently don't trust even Mozilla to host sensitive information like Identification of all my accounts and associated Passwords for banking, healthcare, retirement planning, etc.  Telling me how well encrypted this information is, won't cut it.  Encrypted or not, this information is still on someone else's servers.

I also think it is deplorable that Mozilla will use a successful privacy feature such as self-hosted Sync as leverage in a marketing ploy to "sell" Mozilla's new Persona login authentication scheme https://wiki.mozilla.org/User_Services/Sync/v1#Strategy. Taking control away from users is something Mozilla should be ashamed for even considering or attempting.  The word "encourage" is a thinly veiled euphemism for strong arm tactics to control, and force adoption of Mozilla's "Firefox Account" aka Persona.  With use of this tactic, Persona is already giving it's image a "black eye".

Don't let Mozilla's "Most Trusted Internet Company in Privacy" standing be a one year flash in the pan to be destroyed by Mozilla Marketing "acceptance" agendas. https://blog.mozilla.org/theden/2013/02/06/mozilla-is-most-trusted-internet-company-in-privacy/

Restore "Freedom" and choice to Mozilla users.  Allow the use of self-hosted servers for all these new Sync, Account Login, and future functions.  Without this freedom of choice, Mozilla's standing will suffer a great blow and become just another entity attempting to force agendas. Instead I believe Mozilla should be known for offering high quality tools which help maintain privacy and freedom of choice.

I suggest Mozilla offer its own servers as easy entry and setup for these new beneficial features for all to use.  Maintain the options for self hosting of these features for more sophisticated application and user needs.
Hi Richard,

Thanks for your reply. As I saw, the UI for specifying an alternate server is disapearing and that's what can be called a regression bug or a removed fundamental feature. This makes pairing with e.g. an OwnCloud server impossible or very difficult.

From what I see in this tracker and elsewhere, OwnCloud is an important player, and it would be great that Mozilla and OwnCloud teams discuss the issue and find a solution *before* removing that setting from Firefox released, as it is in the interest of both and of the whole community to have alternatives.

I don't see why Marketplace would be an issue for most people using OwnCloud to sync Firefox. Showing that there is a choice for clouds syncing is an important message to users too.

Missusing the Sync account information to automatically connect to Marketplace could also be considered a privacy issue. That should sure be different accounts or settings.

This is not a +1 (i did include one into my comment above, sorry about that), but a few thoughts of the consequences of the removal of that setting and seeing your reply.

Best Regards
The ability to host your own *is not going away*. The API and interface are changing, but Mozilla is committed to preserving self-hosting and the ability to be completely independent *from* Mozilla.

Here are a few options you have right now:

1) Temporarily switch to Firefox ESR, which will retain the current Sync system and its APIs until the release of Firefox 31 ESR next year. This will let you keep going with the status quo while the new self-hosting experience gets polished. https://mozilla.org/firefox/organizations/

2) Set up your own new TokenServer and SyncStorage instances for use with the new Sync system, storing your own data, but delegating authentication and key escrow to Mozilla's Firefox Accounts system. https://docs.services.mozilla.com/howtos/run-sync-1.5.html

3) Do #2 *and* set up your own Firefox Accounts server, which completely removes Mozilla from the trust or authentication path. https://docs.services.mozilla.com/howtos/run-fxa.html

Making this work -- and making it work well -- is something I'm focused on this year, as a paid contributor. If you'd like to help, you can find me in #sync on irc.mozilla.org, or start digging in at https://docs.services.mozilla.com/
(Also, #4: I believe that the existing sync code will continue to exist and work in Firefox, even though the UI is changing, so you should be able to keep syncing as per normal for quite some time.)
ESR is not even an option on android. Also on android, only recent versions support FIPS compliant servers (no RC4).
While configuring in about:config could be a workable option, I would think that a UI switch to select old sync style would be better.
At this point, if we want to use old sync style, we don't need anything else than the code still being in mozilla releases. So exposing old sync in an advanced setting or something like that would be sufficient. Given that most users using their own servers don't need any of the new sync features, old sync code could stay, it just needs to be usable from the UI in an advanced mode.
Quick update: As per the docs on SUMO [0],

- The old sync code will stay in Firefox and Firefox for Android (Fennec) "a limited time" (I don't know what that specifically means yet, but I imagine it's at least a year given Firefox ESR), so your devices will continue to sync with your self-hosted syncservers, as per normal, for now.

- The pairing UI has been removed from Firefox and Fennec, which means you won't be able to set up new devices with legacy Sync servers using Fx29 and newer.

I believe you could download Fx28 on desktop and Android [1, 2], set up sync and pairing, then upgrade to a modern Firefox while still using your own sync server.

However, that *doesn't* solve things for people that want to self-host Sync 1.5 on Fennec. This whole situation is a bit messy, but we'll find a way to get it working!

[0]: https://support.mozilla.org/en-US/kb/how-to-update-to-the-new-firefox-sync#w_what-if-i-dont-want-to-update-to-the-new-sync

[1]: http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/28.0/

[2]: http://ftp.mozilla.org/pub/mobile/releases/28.0.1/
Oh hey! Great news! You can still set up Sync 1.1 with private servers in Firefox for Android. You'll be able to do that via:

1. Go to Android Settings
2. Tap on "Add account"
3. Choose "Firefox Sync (deprecated)"

Closing this bug as resolved, since Sync 1.1 with private servers is going to keep working, and we have docs for self-hosting Sync 1.5 + FxA online at https://docs.services.mozilla.com/

(The docs and interface could be better, but it's totally possible, right now, to self-host.)

If this doesn't work for anyone, please re-open and let me know what's up.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to Dan Callahan [:callahad] from comment #20)
> Oh hey! Great news! You can still set up Sync 1.1 with private servers in
> Firefox for Android. You'll be able to do that via:

That's actually an un-fixed bug (Bug 965924) -- it allows you to end up with two Sync accounts (one old, one new), which is very much an unsupported scenario.


> Closing this bug as resolved, since Sync 1.1 with private servers is going
> to keep working

I expect Sync 1.1 support to be removed from the client at some point in the 31-32 timeframe, and Mozilla's own hosted servers to enter deprecation mode then, too. As far as I know, supporting the legacy Sync service for the duration of ESR 31 is an explicit non-goal.

There might be a release or two on Android in which it's not possible to use a custom server, because Sync 1.1 will go away but we won't have done the work for 1.5. Neither the UX nor engineering work has been specced out yet.


> If this doesn't work for anyone, please re-open and let me know what's up.

If the goal is to have a self-hosted FxA Sync setup on Android, this is still a valid bug. If you want to limit this bug to desktop, then you can close it.

To quote Comment 0:

  "It is not possible to configure a custom Firefox Accounts server in Firefox 31.0a1."
> If the goal is to have a self-hosted FxA Sync setup on Android, this is still a valid bug. If you want to limit this bug to desktop, then you can close it.

I'm new to Bugzilla (coming from a team that used GitHub almost exclusively), so my bug triaging instincts might be a little off. Re-opening this.

For the two scenarios:

1. Self-hosting Sync 1.1

Per :rnewman (thanks!), things are unchanged from the status quo for at least the next several months (Fx31/32 timeframe). If you're self-hosting, it will keep working.

2. Self-hosting Sync 1.5

Completely possible, but not yet user friendly on Desktop. Unsure if this is currently possible on Fennec.

I'll focus on making sure that #2 is solved, and solved in a user-friendly way, before #1 becomes difficult. :)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
FYI, I seem to be able to do syncing the old way (being able to enter a custom sync URL) by simply setting the following in about:config:

services.sync.fxaccounts.enabled = false
I should amend my previous comment #23 by saying that I did this in Firefox 29 beta 4.
As noted in Comment 12, adding +1s is not helpful here. We understand and agree with the sentiments being expressed and fully plan to continue support for self-hosted servers.

As with many major transitions, there may be a little bumpiness. Right now it's not too bad in desktop, but if you do upgrade to the new system, attaching an android device is a challenge. That's not due to a change in direction, simply a question of what has to be prioritized. We have people working on self-hosting, and if you want to get involved with the efforts, please let me know.

If everything is already set up on the old sync server, that's not going to stop functioning for a while yet, which should give us the time to get all the polish in place for self-hosted new sync servers. In the meantime, bear with us.
Hello,

I'm not here to +1 but to suggest to drop the current Sync feature as it is today.

Firefox users are expecting from Mozilla to offer an OPEN (not only open-source, but open on the ethical and practical levels) sync solution.

Congratulation, Firefox now have the same feature that its most prominent competitor - Chrome - had years ago. 

I thought it was about "openness, innovation & opportunity", I see here no openness (sending my personal data to Mozilla servers??) and no innovation (this is a clone of Chrome's innovation), and lastly let me elaborate on the "opportunity" aspect:

Mozilla actually do have the OPPORTUNITY to INNOVATE by extending its OPENNESS, here's how:

1) Create a "Custom Sync Server" that can be installed by ANYONE. This can be done by providing a single PHP script that can be run on most shared hosting.

2) In the Firefox UI, make it super-easy to use a Custom Sync Server. Provide a direct link to download the Sync Server PHP Script, optimally offer a wizard that will guide the user from uploading the PHP script to its hosting, to providing the URL of their custom server to Firefox. The whole process of installing and configuring a custom Sync server should not be longer than 5 minutes, including the time to connect via FTP to upload the PHP script.

3) When clicking the main "Sync" button in Firefox, the option 1 should be to Sync with a custom server, and the option 2 should be to use Mozilla servers but must display links to Mozilla terms and privacy policy. Option 1 should display the mention "Recommended".


Now this is how you INNOVATE and bring OPENNESS to Firefox, here is your OPPORTUNITY to make a difference! We don't need another Google.

Sincerely,
Jeremy Shepard
Flags: needinfo?(dan.callahan)
Flags: needinfo?(callahad)
(Clearing needinfo because there's no question here to be answered)

> Congratulation, Firefox now have the same feature that its most
> prominent competitor - Chrome - had years ago.

Which is one good reason (among many) why we're not waiting another six months to polish the self-hosting story before shipping this thing.

I broadly agree with (1) and (2) as high-level goals and I think many others here do too.  We'd love to build this.  It's a matter of prioritization.

Number (3) would not only ensure an even worse rate of adoption than the old pairing-based sync, but would be laughably disrespectful to all those have no interesting in doing this, no time to spend doing this, and none of the skills necessary to do it in a secure manner.  It would be great to have a world where (3) could be the default, but we don't have such a world, and trying to force it on people wouldn't help to build such a world.

> here is your OPPORTUNITY to make a difference!

The problem is not in finding those opportunities - we have plenty of them, big and small.  The problem is picking which ones we can get done, and which ones will have the most impact, while still shipping an awesome product.

We actively want to make this situation better.  I doubt that paid MoCo contributors alone can get things anywhere close to the place described in (1) and (2) above, as wonderful as that place might be, simply because of prioritization.  I'm also hopeful that there's enough community members interested in this that we can really make something good. 

But +1's are not the way to get this done (yes, despite protesting otherwise, the previous comment is basically an elaborate +1).

For anyone reading this bug and caring about this issue: we welcome concrete contributions.  Find :rfkelly or :callahad in the locations documented here, and let us know you want to help (or even just let us know that you care):

    https://docs.services.mozilla.com/howtos/run-sync-1.5.html#asking-for-help
Flags: needinfo?(dan.callahan)
Flags: needinfo?(callahad)
As one of the passengers on this bus who's trying hard to be quiet on the sidelines, I do -very- much appreciate the effort of Mozilla and OwnCloud Developers to keep self hosting available and alive for users.  I am also aware of others quietly chomping at the bit on the sidelines with their pitchforks waiting for a "Custom Sync Server v1.5".  I made a big stink earlier because I'd tried for 2 weeks to get attention to the "Custom Sync Server" issue, and felt the issue was being ignored and was in danger of being dropped for good in favor of Mozilla servers.  I now believe because of this "REOPENED" thread this isn't true, and this issue is being addressed by Mozilla developers.  YEAH! 8-)  [ok, I'm not being so quiet now, but guys we're still out here watching]

#1 Above "PHP Custom Sync Server" already has a non-Mozilla solution called http://owncloud.org/ which offers a "brainless" way to install the "Mozilla-Sync" Add-on for the 1.1 version of Sync.  I'm one of the people running 1.1, and it does work... very well in fact and I only had to press one "Mozilla Sync Add-on Enable button" for it to install itself and run in OwnCloud 6.0.3.  Mozilla-Sync 1.1 has to be initially setup with FFv28 or earlier, but once setup it continues to work with FFv29 and OwnCloud v6.0.3.  It looks like FFv29 still allows "pairing" (very good, yes I'm watching this too).  One of the two OwnCloud developers working on OwnCloud Sync 1.5 started this bug-thread, and I'm sure he doesn't want to hear from any of us unless it involves coding help and/or free pizza and beer, money, or other forms of adulation.  So in case it wasn't obvious, it's being worked on. https://github.com/owncloud/mozilla_sync/issues/33

As I keep telling people in other threads, you don't need to spam this thread with "+1's", use the hard to find "Voting Button" to be counted.  The hard to find voting button is URL https://bugzilla.mozilla.org/page.cgi?id=voting/user.html&bug_id=989756#vote_989756 .  Use this to be counted!  I see 41 pitchforks (er votes) so far.  This issue got started late, and I'm sure there will be a few more bumps on this bus ride to 1.5, then 2.0.  Sitting back down in my bus seat (hmm, no seatbelts) for now.
> FYI, I seem to be able to do syncing the old way (being able to enter a
> custom sync URL) by simply setting the following in about:config:
> 
> services.sync.fxaccounts.enabled = false

This fix no longer seems to work in Firefox 30, FYI.
(In reply to Jay from comment #33)
> > FYI, I seem to be able to do syncing the old way (being able to enter a
> > custom sync URL) by simply setting the following in about:config:
> > 
> > services.sync.fxaccounts.enabled = false
> 
> This fix no longer seems to work in Firefox 30, FYI.

However, having set up custom syncing prior to this, syncing to my own server is still humming along fine.
please re-enable the GUI back to support existing FF Sync 1.1 installations (pairing devices) as long as FF Sync 1.1 is supported anyway.

Why? - It is expected to take some more time to have the external sync servers upgraded to support FF Sync 1.5 architecture.

!!! PLEASE !!!

BTW - I pretty much agree with the outlined opportunities mentioned in comment #30 above.

P.S. my workaround currently is to have supported users stepped back to ESR 24.5.0 releases until (hopefully) feasible solutions are avail. again. In my case I need a simple e.g. PHP based solution (eg owncloud) due to ftp limited web space.
I already have my own sync server, I use OwnCloud Sync. I can no longer add new devices as the GUI to enter my own URL is no longer available.

:(

Please consider simply re-enabling the GUI, even if it requires an about:config setting to make available. Or maybe even instructions to add required about:config entries to support my existing sync.

Otherwise, doing a great job with FF. Kudos to all involved.
Like Lyall Pearce, I use OwnCloud Sync to sync my bookmark with Firefox. Can you modify the GUI to enter an own URL server ?

Thanks in advance.
It was shocking for me, because I wanted to install my ownCloud firefox sync in days :-O
Restricting this bug to people with edit bugs as the last several comments were +1s.
Restrict Comments: true
(I don't think a rash of +1s on its own is grounds for restricting comments. Bugzilla isn't meant as a place to advocate, certainly, but this bug is already long enough to be a useful place to track work, so that will likely happen in other bugs anyhow. This might as well serve as a place to centralize discussion/advocacy.)
Restrict Comments: false
Option "services.sync.fxaccounts.enabled = false" mentioned here doesn't work for me on newly installed 29.0.1 on Windows. Since Android build doesn't allow modifying server url, I used this workaround to setup new stations with old sync: https://gist.github.com/mariussturm/061b9f4861ef1292aa60
Old setup UI is back when filling in services.sync.username with my hashed username.
i have my owncloud server sync, ad now i can 't sync on my server.
can u please add this option

pleeeease
I also user owncloud to sync and if firefox will no longer support this, i will no longer support firefox...
Creating my own sync server was killer feature against Chrome - now it doesn't matter if you give your data to Google or Mozilla :( Please bring this back !
(In reply to Jozef Peterka from comment #45)
> Creating my own sync server was killer feature against Chrome - now it
> doesn't matter if you give your data to Google or Mozilla

Not really correct. Mozilla doesn't -- and can't -- read or monetize your browsing data, because your data is encrypted before it reaches the server.
Mozilla DOES monetize your browsing data: http://liliputing.com/2014/02/mozilla-to-sell-ad-space-in-firefox-new-tab-page.html

Mozilla CAN read your browsing data - encrypted or not - the decryption key is stored by Mozilla too.
> Mozilla CAN read your browsing data - encrypted or not - the decryption key is stored by Mozilla too.

Completely untrue, Mozilla servers never see the crypto keys in their raw form.  See this post for more information:  https://blog.mozilla.org/services/2014/04/30/firefox-syncs-new-security-model/
(In reply to x.redir from comment #47)
> Mozilla DOES monetize your browsing data:
> http://liliputing.com/2014/02/mozilla-to-sell-ad-space-in-firefox-new-tab-
> page.html
> 

I've read this link you point to. It doesn't say anything about monetizing your browsing data. It says that it uses your (client-side) browsing history to populate directory tiles, and if it's a new install (so there's no history), it may use some sponsored content.

Regardless, we have zero interest in the contents of your history/bookmarks/etc, and would prefer not to be able to read it. The sync architecture is set up so that we can't.
interesting to see that people believe being able to finally conclude on other peoples perception how to value security or poitential business aspects. I do not think that such discussion could successfully be closed give one single direction.

My recommendation is to take comments like #30 serious and diffenrentiate Firefox features through openess and ease of use rather than trying to force users in a certain direction they feel uncomfortabel with. This is especially true when technical aspects "should" be safe like outlined above; cf. latest issues in vunerability such as heartbleed. Transposed to the new FF Sync concept - imagine if such possibility / attack would be successful on a central database ...
> I thought it was about "openness, innovation & opportunity", I see here no
> openness (sending my personal data to Mozilla servers??) 
When you used the sync feature in firefox without your own server you were already uploading you personal information.
On the first setup they asked you to give a mail and password. On https://account.services.mozilla.com/ you can login and see your bookmarks on THEIR server with the OLD sync feature. You never confirmed your account, but you sure created one.
If you still want to use the old sync go to about:config add services.sync.username string and type something. TADA it works
Hi,

how is it possible to use your own Fx Accounts server when setting up Sync 1.5? There are some config keys in about:config but none of them seems to affect the call to POST /v1/account/create [1].

The workflow when creating a new account in Firefox seems to be like this:
1) Load URL specified in identity.fxaccounts.remote.signup.uri
2) Users enters email and password
3) Data gets sent to identity.mozilla.com (this URL is hard coded into the JS included by the URL loaded in step (1))

There seems to be no way to change the URL where Firefox creates a new Fx Account. Or am I missing something?

Working support for a self-hosted Firefox Accounts server is a prerequisite for getting the complete Sync 1.5 process to run on your own server.

Can the Mozilla guys :rnewman :callahad :rfkelly comment on this?

Thanks

[1] https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#post-v1accountcreate
Flags: needinfo?(rnewman)
Flags: needinfo?(rfkelly)
Flags: needinfo?(dan.callahan)
> There are some config keys in about:config but none of them seems to affect the call to
> POST /v1/account/create

Did you change all the keys document in http://docs.services.mozilla.com/howtos/run-fxa.html ?

> 1) Load URL specified in identity.fxaccounts.remote.signup.uri

Did firefox correctly retrieve the self-hosted version of this URL, rather than hitting the default servers?

> 3) Data gets sent to identity.mozilla.com

No data gets send to "identity.mozilla.com" and there's nothing there that might receive such data - that site is just the identity team blog.  The protocol uses the string "identity.mozilla.com" as a namespace when deriving some keys, but that won't affect your ability to self-host.

By default data is sent to api.accounts.firefox.com.

> (this URL is hard coded into the JS included by the URL loaded in step (1))

The site identified in the "identity.fxaccounts.remote.signup.uri" setting should be sending your custom URL in the returned javascript.  It's possible that this is not working correctly or that some mis-configuration means that the expected URL is not being sent.

Can you please summarize the config changes you made in fxa-customs-server to get it up and running?  In particular please check the value of "fxaccount_url" which should point to your self-hosted fxa-auth-server instance.
Flags: needinfo?(rnewman)
Flags: needinfo?(rfkelly)
Flags: needinfo?(dan.callahan)
> Did you change all the keys document in http://docs.services.mozilla.com/howtos/run-fxa.html ?

Yes, for testing purposes I set all keys to http://localhost and listend on the loopback interface. When I open the account creation page [1], just a blank page is shown and no data is sent to http://localhost.

> The site identified in the "identity.fxaccounts.remote.signup.uri" setting should be sending your
> custom URL in the returned javascript.

So if I am running my own Fx Accounts content server I would need to redo the work that went into creating the 8000 lines of code in Mozilla javascript file "/scripts/e95d6b21.main.js"? Why doesn't Firefox use the host specified in identity.fxaccounts.auth.uri also for account creation?

> In particular please check the value of "fxaccount_url" which should point to your self-hosted
> fxa-auth-server instance.

I am trying to set up my own Fx Accounts content server, not using the Node JS implementation.

[1] about:accounts?action=signup
> I am trying to set up my own Fx Accounts content server, not using the Node JS implementation.

Ah, I see, I misunderstood.

> So if I am running my own Fx Accounts content server I would need to redo the work that went
> into creating the 8000 lines of code in Mozilla javascript file "/scripts/e95d6b21.main.js"?

I fear you will have to reproduce at least some of it, yes. :-(.  Hopefully not all of it though!

There is a javascript API for talking to the auth server available here, which is at least part of the 8000 lines in that file:

  https://github.com/mozilla/fxa-js-client

> Why doesn't Firefox use the host specified in identity.fxaccounts.auth.uri also for account creation?

For a variety of reasons that all boil down to "doing it this way meant we could ship it faster".

The signin process is a kind of hybrid implementation between the browser itself and the web content hosted on http://accounts.firefox.com.  Essentially the browser just loads up the web page and lets you create the account from there, with some hooks to tell the browser when it's done.

I don't know the details of how state is managed between the two, or where to find such details, so I'm cc'ing some folks onto this bug who may be able to advise you.  Shane or Zach: can you please comment on the feasibility of replacing fxa-content-server with a custom server implementation, and where one might look for details on the protocol it speaks with browser chrome?
+1 for implement the option that you can use your own sync server again.
(In reply to Ryan Kelly [:rfkelly] from comment #55)
> 
> The signin process is a kind of hybrid implementation between the browser
> itself and the web content hosted on http://accounts.firefox.com. 
> Essentially the browser just loads up the web page and lets you create the
> account from there, with some hooks to tell the browser when it's done.
> 
> I don't know the details of how state is managed between the two, or where
> to find such details, so I'm cc'ing some folks onto this bug who may be able
> to advise you.  Shane or Zach: can you please comment on the feasibility of
> replacing fxa-content-server with a custom server implementation, and where
> one might look for details on the protocol it speaks with browser chrome?


The (undocumented) protocol is basically a few events that the hosted page sends to the browser. The login event is the major one, which sends the user's credentials to the browser and kicks off Sync.

If you can reuse our front-end AMD scripts that would be best. You can find the pre-built scripts in the fxa-content-server repo; you'll want this script in particular: https://github.com/mozilla/fxa-content-server/blob/master/app/scripts/lib/fxa-client.js. That's a wrapper around the fxa-js-client that rfkelly already linked to.

The code that constructs events for the browser is here: https://github.com/mozilla/fxa-content-server/blob/master/app/scripts/lib/channels/fx-desktop.js

And, for reference, the browser code that listens for them is here: https://github.com/mozilla/gecko-dev/blob/master/browser/base/content/aboutaccounts/aboutaccounts.js#L222-L234

Here's a peak at the credentials the hosted code sends with a login event: https://github.com/mozilla/fxa-content-server/blob/master/app/scripts/lib/fxa-client.js#L120-L128

Besides the login event, the session_status event is also useful. It lets the hosted code retrieve the account data of the user currently logged in to Sync in the browser: https://github.com/mozilla/fxa-content-server/blob/master/app/scripts/lib/channels/fx-desktop.js#L67-L86

There's more where that came from, so feel free to hop into #fxa if you need help setting things up.
Merci de conserver cette fonctionnalité (avec owncloud)... 

C'est pour moi,  la meilleure raison pour laquelle je reste sur Firefox ! 

Je refuse de utiliser les  serveurs sync de Moselle !  Je veux conserver la main sur ses données. 

Merci
Cette fonctionnalié est un des avantages importants de Firefox, merci de la garder !
I too am using Owncloud and while Mozilla sync on my Desktop still works, I can't pair my new laptop.

Let me find some clear words here:
As an IT security expert and 18+ years Linux user, I would go so far and say that this step of trying to bind people to Mozilla's cloud for me has jeopardized any and all credibility of the Mozilla Foundation as an advocate of free software and Freedom in general. Trying to force people into using their own cloud services is a typical behavior of "evil" internet megacorps like Google or Microsoft. One might speculate about the background of this move, considering that Google is one of (if not *the*) major sources of income for the Foundation.

In any case, this move is totally unacceptable from a privacy standpoint as even *if* we were to believe that the Foundation itself won't touch te users' data and couldn't even if they wanted to, the Foundation is based in the US - a country with almost no effective privacy protection legislation and additionally pretty much limitless access rights to everything for federal authorities.

The *only* right thing to do here is to stop explaining, stop making statements about how secure the Mozilla cloudservice is and immediately reinstating the possibility of entering custom server information via an immediate service release of Firefox.

Otherwise, as was written before by others, users can as well use Chrome or any other arbitrary proprietary browser and Firefox would have to be classified as potential privacy risk.
(In reply to Stefan Gofferje from comment #60)
> I too am using Owncloud and while Mozilla sync on my Desktop still works, I
> can't pair my new laptop.
@Stefan: I am not a Mozilla employee. Just a normal (but experienced) user. Sorry to say that, but your mail is simply impolite and not well informed. As far as I read, there is little or rather none intention to push users of alternative solutions to use mozilla cloud services. Mozilla just improved the existing sync solution, to compete with Google, because the existing solution was (for non IT-experts) to complicated to use. In that process old alternative implementations where broken and need to be updated. As far as I understand Mozilla is working on this and supports others which work on solutions. So what is your problem? You claim to be an IT-expert. As such you should be perfectly capable of even making your old sync-solution work on your new laptop. Use the search engine of your choice and you will find solutions. I am a non IT-expert and I managed it. May be as an IT-expert, you are even able to support Mozilla in that effort. Unfortunately I do not have the skills, otherwise I would be happy to do so.
@Mark:
(In reply to Mark from comment #61)
> As far as I read, there is little or rather none intention to push users of
> alternative solutions to use mozilla cloud services.

You surely also believe that Google doesn't want to be evil or that Apple never cooperated with the NSA...
A few facts:
- The sync setup does not offer any possibility to enter a custom server
- It is rather complicated to get "old style" sync to work at the moment (in FF29)
- Old style sync will be removed in a coming version
- Allegedly (!) it will be possible to host a sync server for the new system privately
- Even you host a private sync server in the new system, a Mozilla authentication server will be necessary in future
- Allegedly (!) it will be possible to also host an authentication server privately

> Mozilla just improved
> the existing sync solution, to compete with Google,
> because the existing
> solution was (for non IT-experts) to complicated to use. In that process old
> alternative implementations where broken and need to be updated. As far as I
> understand Mozilla is working on this and supports others which work on
> solutions. So what is your problem?

Where was the "old style" solution too complicated to use for end users? It was like now "sign up" - simple process. But the future solution will be much more complicated for self-hosting because of the need for separate sync and auth instances, *and* let me point out that the availability of self-hosting as of now are just promises and they just came after this major backlash from the community.

That's a very simple calculation for me: Removing self-hosting compatibility and/or making it extremely complicated to set it up = trying to push users to their own cloud service. End of story.
As has been pointed out countless times before, the comments in this bug report are *NOT* the place for this discussion.

* Clamoring for ownCloud support here will not make it happen any faster.
* No argument you could give will be new to the Mozilla team. They get it.
* Any useful information posted here (workarounds, patches, etc.) will be obscured by the noise.

If you *really* want to help, stop commenting and be patient, or if you feel you can't keep quiet, write a blog post or send Mozilla an email. Or write a Tweet encourage others to VOTE on this bug, using the clearly labeled "VOTE" link in the bug details.
@Jay:
ACK, SRY and done.
(In reply to Stefan Gofferje from comment #62)

I'd like to give a quick update on where we are, and run through Stefan's comment.

> - The sync setup does not offer any possibility to enter a custom server

For the time being, this is correct: custom server support is not currently exposed in the UI, and instead requires editing values in about:config.

> - It is rather complicated to get "old style" sync to work at the moment (in
> FF29)

This is an unfortunate side-effect of deprecating Sync 1.1, but "complicated" does not mean "impossible."

For most users, everything will Just Work: previously configured Sync 1.1 settings are maintained when upgrading to Firefox 29. For others, it's still possible to set up Sync 1.1 using workarounds listed in this bug or by temporarily downgrading to Fx28. In Android, it's possible by adding a "Sync (Deprecated)" account to the system.

> - Old style sync will be removed in a coming version

This is correct, and is the expected result of deprecating Sync 1.1 in favor of Sync 1.5.

We acknowledge that there are currently regressions with the move to Sync 1.5, particularly around the ease of self-hosting.

> - Allegedly (!) it will be possible to host a sync server for the new system
> privately

The fear-mongering here is unwarranted and unbecoming; running your own Sync 1.5 server is absolutely possible right now.

Instructions live at https://docs.services.mozilla.com/howtos/run-sync-1.5.html

> - Even you host a private sync server in the new system, a Mozilla
> authentication server will be necessary in future
> - Allegedly (!) it will be possible to also host an authentication server
> privately

No FUD necessary; this is possible right now.

Instructions live at https://docs.services.mozilla.com/howtos/run-fxa.html

> self-hosting as of now are just promises and they just came after this major
> backlash from the community.

They're not "just promises;" you can run your own stack (FxA + Sync) right now.

Heck, if you want to fully replicate the FxA development / testing environment in AWS, you can use our own provisioning scripts from https://github.com/dannycoates/fxa-dev

The challenge is that Sync 1.5 is designed to scale to hundreds of millions of users, which imposes certain architectural constraints. Once you hit that point, it becomes difficult to package that same system in a way that makes sense for smaller deployments.

Later today / tomorrow I'll be posting a Vagrant + Ansible solution to standing up your own, local instance of the FxA + Sync servers in a single Ubuntu VM. My hope is that it will provide a good, testable template for folks that want to self-host using our own code. However, after grappling with this for the past few months, I don't think running Mozilla's server-side code is ultimately the right path for self-hosting. We're simply not focused on writing services for small-to-medium scale environments.

With that realization, I've shifted toward trying to figure out how we can "enable the enablers," rather than directly delivering a self-hosting package to end-users. For instance, I'd love to see OwnCloud become a drop-in replacement for Mozilla's hosted Sync backend in much the same way that Open Whisper Systems was able to build a drop-in, self-hostable contact and calendar sync solution for Android (https://whispersystems.org/blog/flock/). 

So for now, my highest priority is to ensure that it's *possible* to self-host. Not easy. Not polished. Possible.

From there, we can start chipping away at the barriers that keep third party solutions out of the ecosystem. We need to lock down and define protocols, we need to figure out what "services" mean on Desktop Firefox, etc. And we'll get there, but it'll be a long and bumpy journey.

Your help and support are appreciated.
@Dan:
Thx for the clearing up!
Sorry for the delay; running into some issues getting things fully working end-to-end.

Current work-in-progress can be found at https://github.com/callahad/selfhosted-sync

The README needs updates, but almost everything works, provided you configure your Firefox according to the docs linked above.

Current limitations:

- Only listens to connections from the local machine; not useful for real-world syncing.
- Stores data in memory, not MySQL; good for debugging, bad for real use.
- FxA components run in development mode; good for debugging, bad for real use.
- Local Sync refuses to accept certificates signed by the local FxA auth server, since it's still delegating to Mozilla's hosted verifier, and that verifier can't reach something that's only listening to local connections.

So what I still need to do is:

- Update README
- Add MySQL
- Add browserid-verifier
- Switch to "production" mode for the Node apps
- Document making the stuff available to outside connections.
- Document how to use a real (not self-signed) SSL certificate.

Once this is up and working for desktop Firefox, I'll start looking at what needs to happen to get Fennec into a good place for self-hosting.
So what's the current way of setting up the client side?

There seem to be lots of docs about setting up the sync server, but there's no working guide on how to set it up in FF 31's about:config.

What I tried:
1. Disconnect from Sync
2. set services.sync.tokenServerURI to my server's URL ( https://this.is-secret.eu/remote.php/mozilla_sync/ )
3. Options->Sync->Login

However, standard Sync login screen from mozilla.org was presented to me. 

So what are the about:config settings I need to change (if I want to use Mozilla's FxA and own data hosting)?

Thank you for answering.
Martin - try Steps 1. and 2. then restart Firefox.
Then try Step 3. The menu should reflect the change.
(In reply to Martin Pecka from comment #68)
> So what's the current way of setting up the client side?
> 
> There seem to be lots of docs about setting up the sync server, but there's
> no working guide on how to set it up in FF 31's about:config.
> 
> What I tried:
> 1. Disconnect from Sync
> 2. set services.sync.tokenServerURI to my server's URL (
> https://this.is-secret.eu/remote.php/mozilla_sync/ )
> 3. Options->Sync->Login
> 
> However, standard Sync login screen from mozilla.org was presented to me. 
> 
> So what are the about:config settings I need to change (if I want to use
> Mozilla's FxA and own data hosting)?
> 
> Thank you for answering.

If you're trying to use Sync 1.1 (with, for example, ownCloud), the following works for me (FF 32b9):

Create a new about:config string with the key services.sync.username and set it to anything (as long as it doesn't have an @ in it). Then click Tools > Set Up Sync.
Won't this feature beeing disabled within one of the next versions of Firefox?
[:jbonacci] I've tried restarting (twice) and it still doesn't work. I've verified after the 2nd restart that the tokenURI was still that URI I set instead of the default one.

Jay: I use Sync 1.5 (and I probably want to use it :) ).
Same here, I tried steps 1 + 2, restarted FF and step 3 did NOT reflect the change. Setting a custom services.sync.tokenServerURI seems to have no effect at all. Can anyone explain?
What worked for me:

1. Set <services.sync.tokenServerURI> to <$urserver>
2. Create <services.sync.username> and set it to "sometext" (to create, edit user.js or just rightclick in about:config)
3. restart Firefox
4. Create new sync-Account

I have recognized, that if you restart firefox twice, the ui to enable sync is the usual again (so you won't be able to set your own server).

HTH
That doesn't work for me. However, it might also be by an error in my sync server config, which I don't know how to check.

Anyway, pmu's tutorial seems to try to setup Sync 1.1.

After I do the 4 steps, I click Options->Sync->Set up Sync->I have account->I don't have the device with me.
Then I am presented with the UI where I can finally set up my own sync server's URI together with my email, password and recovery string. So I fill in everything, some random data as the recovery string, and click Next. Nothing happens. No error message. Wireshark shows only some 4 or 5 packets go to my own server and no more communication.

Clicking on Reset password brings up an empty page from my own server. But that I think is correct, because I run Sync 1.5 client on the server, whereas this seems to be 1.1 feature (due to the word "weave" in the loaded URL).
Thanks pmu, your steps help but I am experiencing similar issues like Martin Pecka. I managed to sync with my custom own cloud server but I do not see the new bookmarks. Looks like nothing happened.

Is there a debug console under Firefox where I can see all the sync activities?
Michael: Do you run 1.1 or 1.5 server?
How can I find this out? All I can say is that I am running owncloud v7.0.1 with the Mozilla Sync v1.4 App
Hmm, seems I got confused during installation of the owncloud app (the same as yours). It apparently supports only sync 1.1. Thus it seems it has to be some misconfiguration on my side. Maybe it's just not the right time to convert from FxA sync to owncloud. I can just wait a few weeks until all the issues get resolved.

So a question to all - is it true that it is currently not possible to setup sync 1.5 in any way?
The mozilla_sync ownCloud app (v1.4) only supports the Sync 1.1 protocol. Within ownCloud it is currently not possible to setup Sync 1.5. This is being worked on, but there is no ETA on it yet.
Exactly Oliver. I'll wait then.
@ Michael: I don't know what your problem is. I've onwcloud 7.01 + syncapp 1.4 tested with firefox 31.0 / waterfox 31.0 and palemoon 24.7.1 successful. Firefox and Waterfox need the about:config mod to work. Palemoon support the old sync 1.1 native. Palemoon is based on firefox 24 ESR with all security patches. btw my firefox installation was a new fresh setup with a new profile. For Firefox I've created 2 new profiles. They synchronize now their bookmarks and addons perfectly. I've tested everything.
was using firefox  just for the openness it provides .. we want'it back please .. sync is important for us. to be  able to choose an custom server even more. Thanks for the good work. I'll just downgrade >
Hi guys,

I have two questions concerning self hosting implementation.

As :callahad explained, there are two ways of self-hosting Mozilla Sync:
a) Synergy with FxA of Mozilla and own content server
b) Full, self-hosted server stack

1. Is it TECHNICALLY guaranteed that Mozilla Corp. (or other parties after compromising their servers) will never be able to read sync data of users that implemented option a)? Any reviews, blogs, comments?

2. And in case everything is securely encrypted, will there be a possibility to access sync data in a webinterface like lastPass provides it (extremly practical, because it is not required that you connected sync on the device your using -> computers in internet cafes, public environments etc.)?

Thank you very much in advance!
(In reply to Future from comment #85)
> Hi guys,
> 
> I have two questions concerning self hosting implementation.
> 
> As :callahad explained, there are two ways of self-hosting Mozilla Sync:
> a) Synergy with FxA of Mozilla and own content server
> b) Full, self-hosted server stack
> 
> 1. Is it TECHNICALLY guaranteed that Mozilla Corp. (or other parties after
> compromising their servers) will never be able to read sync data of users
> that implemented option a)? Any reviews, blogs, comments?

The best high-level blog post about the system security is probably https://blog.mozilla.org/services/2014/02/07/a-better-firefox-sync/.  The best low-level blog post is probably https://blog.mozilla.org/warner/2014/05/23/the-new-sync-protocol/.

Let me answer briefly here: no.  There is never any guarantee that any cryptographic system will remain secure in the face of attacks.  In the FxA system, Mozilla has a privileged attack only available to others that compromise the FxA servers.  The privileged attack is a faster password attack than others can do.  In other words, we can try to crack your password and we have a yes/no check that's quick (technically, this is called an offline attack).  Unprivileged people trying to do the same have a yes/no check that's not quick and requires the FxA system to respond to their question (technically, this is called an online attack).  If you choose a sufficiently strong password, we believe your data is safe from everybody, including Mozilla.

> 2. And in case everything is securely encrypted, will there be a possibility
> to access sync data in a webinterface like lastPass provides it (extremly
> practical, because it is not required that you connected sync on the device
> your using -> computers in internet cafes, public environments etc.)?

There is a possibility, but it is tricky and almost certainly not something Mozilla will build in the foreseeable future.

The reason it's hard is that the cryptography that secures your data is subtle and expensive to perform in the web browser.  (It's expensive by design: that's part of what keeps your data secure; see above!)  For most of the things you'd want -- say, searching for a bookmark or a site you visited a week ago -- you'd have to download and decrypt almost all the data.  That's extremely expensive, both in terms of bandwidth and in terms of CPU to decrypt.  Sync avoids that by doing everything incrementally, a little bit at a time.  That's the trade off, though: secure data; hard to search online :(
I would appreciate the posssibility to sync my data on my on server (owncloud with mozilla sync).
So please don´t reconsider integrating the option to use your own server as sync option.
(In reply to pupil2@web.de from comment #87)
> I would appreciate the posssibility to sync my data on my on server
> (owncloud with mozilla sync).
> So please don´t reconsider integrating the option to use your own server as
> sync option.

The functionality to configure Firefox (Desktop, and Android) to use such a custom server is in place.  
You can already run your own Accounts and Sync server.  Your request is blocked on the OwnCloud folks writing a Firefox Accounts server, and a Sync 1.5 server.
I would love the ability to sync my data on my on server again using owncloud with mozilla sync. I appreciate it. Keep up the good work
I would love the ability too.
Is there any date to be released?
Thank you for your effort.
(In reply to Jay from comment #70)
> (In reply to Martin Pecka from comment #68)
> > So what's the current way of setting up the client side?
> > 
> > There seem to be lots of docs about setting up the sync server, but there's
> > no working guide on how to set it up in FF 31's about:config.
> > 
> > What I tried:
> > 1. Disconnect from Sync
> > 2. set services.sync.tokenServerURI to my server's URL (
> > https://this.is-secret.eu/remote.php/mozilla_sync/ )
> > 3. Options->Sync->Login
> > 
> > However, standard Sync login screen from mozilla.org was presented to me. 
> > 
> > So what are the about:config settings I need to change (if I want to use
> > Mozilla's FxA and own data hosting)?
> > 
> > Thank you for answering.
> 
> If you're trying to use Sync 1.1 (with, for example, ownCloud), the
> following works for me (FF 32b9):
> 
> Create a new about:config string with the key services.sync.username and set
> it to anything (as long as it doesn't have an @ in it). Then click Tools >
> Set Up Sync.

This works (FF32.03 + ownCloud) - thank you!
(In reply to daveparker01 from comment #91)
> This works (FF32.03 + ownCloud) - thank you!

Wait, wasn't Sync 1.1 supposed to be dropped in FF32? At least that was the reason why I dumped Aurora 32, and migrated all the way backwards until FF31ESR.

Can someone shed some light on which versions (release/beta/aurora, desktop/mobile) actually still support Sync 1.1, and what the currently planned versions are that will drop Sync 1.1 support?
Fennec fully supports signing in to a 1.1 account via Android Settings. It never supported creation of old Sync accounts. 

Desktop continues to support syncing to existing 1.1 accounts. It doesn't offer any UI for creating accounts, or for logging in. If you're familiar with Firefox internals you can probably enter old 1.1 credentials and get it to work. 

This is true up to 35 (current Nightly).

But this is very tangential to this bug, so please take your questions to IRC (#sync) or support.mozilla.org.
@daveparker01@gmail.com nope, this still does not work for me. A custom services.sync.tokenServerURI pointing to my owncloud server and setting services.sync.username to my owncloud username does not make any difference (anything is still synced via mozilla's servers)
(In reply to michael.heuberger from comment #94)
> ... A custom
> services.sync.tokenServerURI pointing to my owncloud server...

tokenServerURI applies to Sync 1.5. If you're trying to use Sync 1.1 with Owncloud, that's the wrong way to go about it.
Ah, I missed that Richard. Thanks. How can I switch to Sync 1.5 in Firefox and Owncloud?
(In reply to michael.heuberger from comment #96)
> Ah, I missed that Richard. Thanks. How can I switch to Sync 1.5 in Firefox
> and Owncloud?

https://github.com/owncloud/mozilla_sync/issues/33
Yeah, I've seen it too that Sync 1.5 is still under development. But some folks in this thread are saying it is working. Confusing. People, if you say it works, please mention the which version you are referring to. Otherwise this thread becomes too chaotic!

Probably this thread should be muted until https://github.com/owncloud/mozilla_sync/issues/33 is resolved.
Since months I am wathich this issue and decided to use FF ESR 24.x (latest) on all machines as a workaround to overcome the current sync situation, hoping that in mean time there will be a solutuion for an owncloud based sysnc server. But since Firefox is now forcing upgrade to ESR 31 (with unclear functionality what sync 1.1 is concerned) I switched to Palemoon 25.0.1, which still supports sync 1.1 as FF did before. So far no issues encountered...
In my applications the full functionality to connect to the sync server is needed esp. being able to add new sync accounts to the sync server, which seems missing in the mentioned workarounds(?) above (... it is working ...). 
Hope that soon there will be future proof solution, either the owncloud Mozilla_sync app might be upgraded to support the new sync 1.5 protocols or Mozilla will continue to support sync 1.1. at least for the "own sync server" community. BTW - Palemoon on ANdroid also supports stronger cipher and sync is working fine with the owncloud mozilla sync 1.4 app.
I hope this doesn't equate to a "+1", apologies if anyone considers it so.

As far as I can tell, time is nearly up for self-hosters. I've been unable to keep sync-1.1 functional in some Desktop clients once I upgraded them past FF32, and from what I read on the sync-dev lists, clients are now being force-migrated to sync-1.5 (in a process which they haven't mentioned the upshot of for sync-1.1 users).  I cannot find info anywhere to confirm or deny, but it sounds like I should move all my clients back to FF31 ESR before sync-1.1 breaks down altogether.  Is this correct, and is it even possible to downgrade an active profile from (currently) 36 to 31?

I still haven't heard of anyone who has managed to recreate the vanilla sync-1.5 + FxA stack from the sources available. If anyone has, I would badly like to hear about it!

Can't anybody rustle up a functional VM image or Docker container at least? I'm not taking aim at MoFo here, but I'm genuinely surprised that between them and the community, something like that hasn't happened yet in all this time.
(In reply to Robin Bankhead from comment #100)
> I hope this doesn't equate to a "+1", apologies if anyone considers it so.

This isn't really the place to discuss this: let's move the conversation to https://mail.mozilla.org/pipermail/services-dev/.
 
> As far as I can tell, time is nearly up for self-hosters. I've been unable
> to keep sync-1.1 functional in some Desktop clients once I upgraded them
> past FF32, and from what I read on the sync-dev lists, clients are now being
> force-migrated to sync-1.5 (in a process which they haven't mentioned the
> upshot of for sync-1.1 users).  I cannot find info anywhere to confirm or
> deny, but it sounds like I should move all my clients back to FF31 ESR
> before sync-1.1 breaks down altogether.  Is this correct, and is it even
> possible to downgrade an active profile from (currently) 36 to 31?

My expectation is that downgrading an active profile is not supported, and almost certainly never will be.  (It's an enormous (!) amount of engineering effort.)

Have you seen https://blog.mozilla.org/services/2015/02/03/legacy-sync-migration/?  It answers some of your questions, I think.  The upshot is that Firefox engineering will not support Sync 1.1 clients past about Firefox 39; and that Firefox Cloud Services will not be running Sync 1.1 infrastructure past about August.

> I still haven't heard of anyone who has managed to recreate the vanilla
> sync-1.5 + FxA stack from the sources available. If anyone has, I would
> badly like to hear about it!

Vanilla doesn't mean anything specific here -- Mozilla's installation has very different requirements than do self hosted installations -- but some (many ?) people are self-hosting.

> Can't anybody rustle up a functional VM image or Docker container at least?
> I'm not taking aim at MoFo here, but I'm genuinely surprised that between
> them and the community, something like that hasn't happened yet in all this
> time.

I think this reflects the level of community support for this outcome.  The number of self-hosters is low; the variety of environments high; in the middle lies the pain of maintaining images or containers over time.
Hello Mozilla,

please give us a chance to backup and sync our settings to our own servers or storages. I've been using Andy Halfords SyncPlaces for a long time. It provided comfortable encrypted syncing to a local server and even backup to an USB-Stick. Syncplaces is no longer maintained and it isn't compatible to recent versions of Firefox. 
I'm not thinking of giving my passwords to any cloud service, even it's said to be safe today. It won't be tomorrow, so I want to keep control of all copies of these delicate personal data.
 
Currently I've got no chance to backup or sync bookmarks and passwords easily between my various installations, making Firefox less usable.
So please fix this bug and give users a chance to regain control over their private data when using sync.
Here's how to run your own Sync server:

https://docs.services.mozilla.com/howtos/run-sync-1.5.html


Here's how to run your own Firefox Accounts server (much harder):

https://docs.services.mozilla.com/howtos/run-fxa.html#howto-run-fxa


Both of those guides include documentation for how to configure desktop Firefox. If you're only self-hosting storage, you just need to set identity.sync.tokenserver.uri. If you're self-hosting FxA+token+Sync, you can use the autoconfig URL; see the doc.


This bug is *only* for offering UI rather than pushing you into about:config. As such, it's relatively low priority.
User Story: (updated)
Summary: Custom server support in Firefox Accounts → Custom server configuration UI for Sync and Firefox Accounts
As a happy user of ff and its ff sync 1.1, I doubt that the "rationalization" of proper custom server support is due to ressources, but politics.

Fact one: there was a custom sync configuration UI in former ff versions (times of sync 1.1).

Fact two: there was support for custom server in ff for Android till V33, but then removed from V44 and up?? (https://docs.services.mozilla.com/howtos/run-fxa.html#howto-run-fxa -> "Since Firefox 33, Firefox for Android has supported custom Firefox Account (and sync) servers. For Firefox 44 and later, enter “about:config” in the URL bar, search for items containing “fxaccounts”, and edit them to use your self-hosted URLs")

Fact three: Lack of documentation quite a time after release annoucement, e.g. Owncloud did not get insight early enough, as their app dropped support nowadays.

I really cannot understand why mozilla removes features that are streamlined with the organisations slogans/strategy ("protect me & keep my data private"), and in the end they change their mind arguing that the populace is not hit.

Is mozilla changing their attitude? Please add this very little piece of configuration UI and the small group of self hosting nerds (like myself!) will be happy...closely, server side is still...you know... :)
We're committed to supporting self-hosting via preferences (eg, bug 1249520 made this much simpler), but we aren't going to add UI for this. We need to do a better job at documentation, but comment 103 is a great start.
Status: REOPENED → RESOLVED
Closed: 10 years ago7 years ago
Resolution: --- → WONTFIX
(In reply to Future from comment #104)
> As a happy user of ff and its ff sync 1.1, I doubt that the
> "rationalization" of proper custom server support is due to ressources, but
> politics.

Glad you are (or were) happy!
 
> Fact one: there was a custom sync configuration UI in former ff versions
> (times of sync 1.1).
> 
> Fact two: there was support for custom server in ff for Android till V33,
> but then removed from V44 and up??
> (https://docs.services.mozilla.com/howtos/run-fxa.html#howto-run-fxa ->
> "Since Firefox 33, Firefox for Android has supported custom Firefox Account
> (and sync) servers. For Firefox 44 and later, enter “about:config” in the
> URL bar, search for items containing “fxaccounts”, and edit them to use your
> self-hosted URLs")

This isn't correct.  We didn't support custom FxA or Sync 1.5 endpoints between Fennec 29 (the first version with FxA at all) and Fennec 33.  This was simply due to the effort required to handle everything else.  Between Fennec 33 and Fennec 44 the process was different between Desktop (about:config) and Fennec (custom UI).  From Fennec 44, the process has been the same on Desktop and Fennec: about:config.  This is _better_, I think, because it's what people configuring Firefox (and Fennec!) expect.

> Fact three: Lack of documentation quite a time after release annoucement,
> e.g. Owncloud did not get insight early enough, as their app dropped support
> nowadays.

Perhaps.  I am in a privileged position (I built this stuff for Fennec, and was payed to work on it fulltime) but the documentation has definitely been available for a long time.  The hard truth is:
- this is very complicated
- Mozilla's FxA installation needs to support millions of users, at scale, at a low cost
- implementing things in Owncloud is not fun (I know, 'cuz I was interested in trying!)

> I really cannot understand why mozilla removes features that are streamlined
> with the organisations slogans/strategy ("protect me & keep my data
> private"), and in the end they change their mind arguing that the populace
> is not hit.
> 
> Is mozilla changing their attitude? Please add this very little piece of
> configuration UI and the small group of self hosting nerds (like myself!)
> will be happy...closely, server side is still...you know... :)

As I said above, you don't need any UI on Fennec -- just a few about:config prefs and a little patience.  The best place to ask for help is https://mail.mozilla.org/listinfo/sync-dev.  Good luck!
Component: Firefox Sync: UI → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.