1329853 - Ability to configure alternative FxA and Sync services through WebExtensions

Status: RESOLVED WONTFIX

(Firefox :: Distributions, enhancement, P5)

Description

[Hector Zhao [:hectorz]]

As a result of unstable internet access to AWS and certain UI modifications according to local regulations, Beijing office operates https://accounts.firefox.com.cn and related services for China repack users.

We cannot simply change the default prefs since there're users who prefer the global services and already have their data there.

We added a link-like button in about:preferences#sync for users to switch services before logging into it.

We also defaults to a bookmark-only sync for new users, to reduce the load on our server.

Comment 1

[Shane Caraveo (:mixedpuppy)]

This is not something that should be a webextensions feature.  What we really need is a distributions component where we can put some items like this.

This feature should be created as a bootstrap addon and added to the distribution as a system addon.

Comment 2

[Hector Zhao [:hectorz]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #1)
> This is not something that should be a webextensions feature.  What we
> really need is a distributions component where we can put some items like
> this.
> 
> This feature should be created as a bootstrap addon and added to the
> distribution as a system addon.

Thanks for the quick response. I'll keep posting the bugs for tracking and triaging.

Also marking one related feature as blocking this.

Comment 3

[Mike Kaply [:mkaply]]

hector:

Can you please create a MozillaOnline desktop tracking bug and link all of these bugs together?

Thanks.

Comment 4

[Hector Zhao [:hectorz]]

(In reply to Mike Kaply [:mkaply] from comment #3)
> hector:
> 
> Can you please create a MozillaOnline desktop tracking bug and link all of
> these bugs together?
> 
> Thanks.

Bug 1311472 kinda serves this purpose.

For this specific bug, since a special case for https://accounts.firefox.com.cn/ was already included in Firefox for iOS (visible in zh-CN only, and defaults on there), I'd hope similar special cases can be introduced into vanilla Firefox for both desktop and Android, restricted to mozillaonline repacks if necessary.

Comment 6

[Mike Kaply [:mkaply]]

Hector, what do you think we should do with this bug?

Comment 7

[Hector Zhao [:hectorz]]

(In reply to Mike Kaply [:mkaply] from comment #6)

Hector, what do you think we should do with this bug?

Hi Mike, my current rough idea for this bug is maybe building something like those in bug 1342584.

Display something like a banner on about:preferences#sync if:

1. identity.fxaccounts.autoconfig.uri is set to non-empty value, notifying users they're about to use a 3rd-party FxA/Sync service; OR
2. FxA/Sync is already connected to such a 3rd party FxA/Sync service, making this fact more discoverable.

And maybe expose a new webextension API (restricted to priveledged if necessary) or manifest entry, so that an extension can be shown as controlling this in the above mentioned banner.

Of course this will need to somehow works for those using vanilla FxA + custom Sync, too.

I wanted to build a PoC before raising this idea, but never found time to do it. Now that I've written it down, maybe I should start needinfo-ing someone from both Sync & webextension API team to see how they like this idea?

Comment 8

[Mike Kaply [:mkaply]]

I wanted to build a PoC before raising this idea, but never found time to do it. Now that I've written it down, maybe I should start needinfo-ing someone from both Sync & webextension API team to see how they like this idea?

Yeah, if you think this is important, probably need to get it on someone's radar.

Comment 9

[Lina Butler (ex-Mozilla)]

Hi Hector! I think this makes sense to iterate on this as a WebExtension Experiment API to set the autoconfig.uri pref, as well as the UX changes you mentioned—maybe something like the policies warning, but shown in about:preferences#sync, and in the account submenu in the app menu.

We would definitely want to restrict this to privileged extensions, though. Even though Sync data is client-side encrypted, I'm super wary of non-Mozilla extensions being able to override it to point to random servers.

Comment 10

[Hector Zhao [:hectorz]]

(In reply to :Lina Cambridge from comment #9)

Hi Hector! I think this makes sense to iterate on this as a WebExtension Experiment API to set the autoconfig.uri pref, as well as the UX changes you mentioned—maybe something like the policies warning, but shown in about:preferences#sync, and in the account submenu in the app menu.

We would definitely want to restrict this to privileged extensions, though. Even though Sync data is client-side encrypted, I'm super wary of non-Mozilla extensions being able to override it to point to random servers.

Hi Lina, thanks for the suggestion! Hopefully I'll be able to starting working on this in some not too distant future.

Comment 11

[Ryan Kelly [:rfkelly]]

We would definitely want to restrict this to privileged extensions, though.

+1

Even though Sync data is client-side encrypted...

If this API lets you change the location of the FxA server, it can defeat that encryption by serving you bad web content that phishes your account password.

Comment 12

[Hector Zhao [:hectorz]]

Attachment: [WIP] Bug 1329853 - WebExt API to configure alternative FxA service. r?lina!,mixedpuppy!

Comment 13

[Hector Zhao [:hectorz]]

Hi, I've built an initial PoC mostly focusing on the FXA_PAGE_LOGGED_OUT page of the about:preferences#sync, and would like to get some early feedback on whether this looks like the right approach.

Known missing parts:

• FXA_PAGE_LOGGED_IN page not changed, maybe just a notice about an alternative service being used, w/o any ability to disable it;
• FxA panel in the app menu not changed, not sure what's the best message that fits in the limited width;
• Not restricted to priviledged extension, should it be some kind of permission or directly checking for context.extension.isPrivileged somewhere?
• Only works for FxA, not vanilla Fxa + alternative Sync;
• Only works if identity.fxaccounts.autoconfig.uri is set through the API, not if set manually in about:config.

Thanks!

Comment 14

[Mark Hammond [:markh] [:mhammond]]

I'd just like to step back a little to sanity check this really is the correct approach. Apologies if I've missed some context - I had a quick look above but it didn't answer my questions.

I believe privileged extensions are likely to be capable of setting this preference already - they can already set arbitrary prefs, right? So I guess I really don't see what value the complexity of webext mechanics serves. Indeed, it might be a footgun - "Only works if identity.fxaccounts.autoconfig.uri is set through the API, not if set manually in about:config." means it will not work for exactly 100% of current users of that preference, right?

It does add a fair degree of complexity too - we'd probably need a sample extension in the tree and tests for the about:preferences change - and even then, it doesn't tell the user what service is being used, just that some mysterious addon is setting it. But fixing that is going to add complexity around fluent and localization, even though we only ever expect it to be used in China.

It also seems highly unlikely that there are going to be any other use-cases from Mozilla. I could understand this approach a little more if there was talk of allowing users outside of mozilla (although I understand and agree with the fact we don't want to do that)

So stepping back, is there something we can do that's simpler and is limited to serving Mozilla China's use-case? Eg, off the top of my head, I see 2 possibilities:

• A privileged extensions that just adjusts the preference using the existing sandbox-blasting capabilities those extensions have, and some other UI that extensions can create. This would require zero changes to mozilla-central.

• Mozilla China's repack introducing a simple radio button asking the user which of the 2 candidate services they would prefer. This might or might not require a few changes we could make to make the lives easier for our colleagues.

Comment 15

[Shane Caraveo (:mixedpuppy)]

I haven't fully looked over the patch or history on the bug, but my initial reaction is essentially the same as before, this shouldn't be a webextension, but a distribution capability or something. Essentially I'm in line with Marks comments above.

Comment 16

[Hector Zhao [:hectorz]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #15)

I haven't fully looked over the patch or history on the bug, but my initial reaction is essentially the same as before, this shouldn't be a webextension, but a distribution capability or something. Essentially I'm in line with Marks comments above.

(In reply to Mark Hammond [:markh] [:mhammond] from comment #14)

I'd just like to step back a little to sanity check this really is the correct approach. Apologies if I've missed some context - I had a quick look above but it didn't answer my questions.

Hi Mark & Shane,

Thanks for the comments.

I believe privileged extensions are likely to be capable of setting this preference already - they can already set arbitrary prefs, right? So I guess I really don't see what value the complexity of webext mechanics serves.

Yes, this pref is currently set by one of our priviledged extension, together with some other FxA related tweaks (hiding Lockwise/Monitor/Pocket etc. which only works with global FxA, also calling FxAccounts.config.fetchConfigURLs to fix mismatches in FxA related prefs, like bug 1207440 and bug 1641188). The motive behind this is mostly to reduce our out-of-tree implementations which need to be compatible with multiple Fx versions and require compat fixes from time to time. AMO editors also would prefer us adopting WebExt APIs more, instead of keep touching Fx internals with the priviledged capability.

Indeed, it might be a footgun - "Only works if identity.fxaccounts.autoconfig.uri is set through the API, not if set manually in about:config." means it will not work for exactly 100% of current users of that preference, right?

That's more about the limitation of this early implementation, but yes, fixing it would introduce even more complexities.

It does add a fair degree of complexity too - we'd probably need a sample extension in the tree and tests for the about:preferences change - and even then, it doesn't tell the user what service is being used, just that some mysterious addon is setting it. But fixing that is going to add complexity around fluent and localization, even though we only ever expect it to be used in China.

It also seems highly unlikely that there are going to be any other use-cases from Mozilla. I could understand this approach a little more if there was talk of allowing users outside of mozilla (although I understand and agree with the fact we don't want to do that)

So stepping back, is there something we can do that's simpler and is limited to serving Mozilla China's use-case? Eg, off the top of my head, I see 2 possibilities:

• A privileged extensions that just adjusts the preference using the existing sandbox-blasting capabilities those extensions have, and some other UI that extensions can create. This would require zero changes to mozilla-central.

As I've mentioned above, this is basically the current status. Some of the issues might be isolated and fixed separately, but creating any UI tweaks in the extension would mean keeping its drawbacks.

• Mozilla China's repack introducing a simple radio button asking the user which of the 2 candidate services they would prefer. This might or might not require a few changes we could make to make the lives easier for our colleagues.

If not with an extension, then this sounds like some code hidden behind China repack's distribution id "MozillaOnline" (or another pref set in its distribution.ini, but I would prefer the distribution id).

This would still require some m-c changes. In an earlier China repack related installer patch, new strings were limited to en-US & zh-CN locales 1, not sure if that's possible for UI changes to about:preferences.

Comment 17

[Mark Hammond [:markh] [:mhammond]]

Hi Hector,

(In reply to Hector Zhao [:hectorz] from comment #16)

Yes, this pref is currently set by one of our priviledged extension, together with some other FxA related tweaks (hiding Lockwise/Monitor/Pocket etc. which only works with global FxA, also calling FxAccounts.config.fetchConfigURLs to fix mismatches in FxA related prefs, like bug 1207440 and bug 1641188). The motive behind this is mostly to reduce our out-of-tree implementations which need to be compatible with multiple Fx versions and require compat fixes from time to time. AMO editors also would prefer us adopting WebExt APIs more, instead of keep touching Fx internals with the priviledged capability.

I can understand that desire in the general case - eg, if you were hacking the implementation of FxAccounts it would be fragile and concerning - but in this scenario we are literally setting a single preference which is designed explicitly for this purpose. I imagine you also touch many other preferences too but don't want to create webextension APIs for each of them too?

• A privileged extensions that just adjusts the preference using the existing sandbox-blasting capabilities those extensions have, and some other UI that extensions can create. This would require zero changes to mozilla-central.

As I've mentioned above, this is basically the current status. Some of the issues might be isolated and fixed separately, but creating any UI tweaks in the extension would mean keeping its drawbacks.

Could you expand on these drawbacks?

• Mozilla China's repack introducing a simple radio button asking the user which of the 2 candidate services they would prefer. This might or might not require a few changes we could make to make the lives easier for our colleagues.

If not with an extension, then this sounds like some code hidden behind China repack's distribution id "MozillaOnline" (or another pref set in its distribution.ini, but I would prefer the distribution id).

This would still require some m-c changes. In an earlier China repack related installer patch, new strings were limited to en-US & zh-CN locales [1], not sure if that's possible for UI changes to about:preferences.

I don't know enough about "distributions" to comment there, and I'm not pushing back specifically on about:preferences changes, just that I'm looking for opportunities to keep unnecessary complexity down.

Comment 18

[Hector Zhao [:hectorz]]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #17)

Hi Hector,

(In reply to Hector Zhao [:hectorz] from comment #16)

Yes, this pref is currently set by one of our priviledged extension, together with some other FxA related tweaks (hiding Lockwise/Monitor/Pocket etc. which only works with global FxA, also calling FxAccounts.config.fetchConfigURLs to fix mismatches in FxA related prefs, like bug 1207440 and bug 1641188). The motive behind this is mostly to reduce our out-of-tree implementations which need to be compatible with multiple Fx versions and require compat fixes from time to time. AMO editors also would prefer us adopting WebExt APIs more, instead of keep touching Fx internals with the priviledged capability.

I can understand that desire in the general case - eg, if you were hacking the implementation of FxAccounts it would be fragile and concerning - but in this scenario we are literally setting a single preference which is designed explicitly for this purpose. I imagine you also touch many other preferences too but don't want to create webextension APIs for each of them too?

I agree setting the pref alone is never problematic. Part of the reason I'm re-using the extension controlled UI is to provide a replacement of our extra link to switch between China/Global FxA services. I started working on this first because FxA switch is one of our most important features, we're still auditing other parts of our extensions to figure out next steps to meet AMO editors' requests.

• A privileged extensions that just adjusts the preference using the existing sandbox-blasting capabilities those extensions have, and some other UI that extensions can create. This would require zero changes to mozilla-central.

As I've mentioned above, this is basically the current status. Some of the issues might be isolated and fixed separately, but creating any UI tweaks in the extension would mean keeping its drawbacks.

Could you expand on these drawbacks?

In FxA/Sync's case, mostly having to keep our UI tweaks up to date with the XUL dialog => in-content preference => de-XBL binding changes, it's definitely not the most fragile part of our extensions.

• Mozilla China's repack introducing a simple radio button asking the user which of the 2 candidate services they would prefer. This might or might not require a few changes we could make to make the lives easier for our colleagues.

If not with an extension, then this sounds like some code hidden behind China repack's distribution id "MozillaOnline" (or another pref set in its distribution.ini, but I would prefer the distribution id).

This would still require some m-c changes. In an earlier China repack related installer patch, new strings were limited to en-US & zh-CN locales [1], not sure if that's possible for UI changes to about:preferences.

I don't know enough about "distributions" to comment there, and I'm not pushing back specifically on about:preferences changes, just that I'm looking for opportunities to keep unnecessary complexity down.

Yes, I understand. To put it simply, distributions are basically customized prefs & extra bookmarks in distribution.ini and bundled extensions.

Comment 19

[Hector Zhao [:hectorz]]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #17)

• Mozilla China's repack introducing a simple radio button asking the user which of the 2 candidate services they would prefer. This might or might not require a few changes we could make to make the lives easier for our colleagues.

If not with an extension, then this sounds like some code hidden behind China repack's distribution id "MozillaOnline" (or another pref set in its distribution.ini, but I would prefer the distribution id).

This would still require some m-c changes. In an earlier China repack related installer patch, new strings were limited to en-US & zh-CN locales [1], not sure if that's possible for UI changes to about:preferences.

I don't know enough about "distributions" to comment there, and I'm not pushing back specifically on about:preferences changes, just that I'm looking for opportunities to keep unnecessary complexity down.

Also in case it's not clear, pref-controlled UI works for me, in fact I raised a similar idea in comment 4 above.

Comment 20

[Mike Kaply [:mkaply]]

We've had some enterprise related inquires around custom sync servers as well where folks want to setup their own servers. We currently don't make it easy, but that might be another use case for this.

Comment 21

[Hector Zhao [:hectorz]]

Attachment: WIP: [WIP] Bug 1329853 - UI to expose any custom FxA service in use. r?markh

Comment 22

[Hector Zhao [:hectorz]]

Attachment: WIP: [WIP] Bug 1329853 - special treatment for China FxA in Fx China repack. r?markh

Depends on D84634

Comment 23

[Hector Zhao [:hectorz]]

Hi Mark, Mike & Shane,

I've uploaded two new PoC patches, would you mind taking a quick look at them and let me know your thoughts?

The first one is exposing the hostname of the alternative FxA service in about:preferences#sync, no matter where it comes from. I think it should be useful for the usecase in comment 20 as well.

The second one is special treatment for China FxA stack, so that it's possible to switch between China/global stacks on either direction. This should be limited to zh-CN locale, but I enabled it for en-US as well for easier testing with a local build.

Thanks!

Comment 24

[Mark Hammond [:markh] [:mhammond]]

I don't have any problem with that patch conceptually. It needs more comments, some tests and I'm not sure about the hard-coded strings there (but do understand these aren't typical user-facing strings too, so would need to think more about that) but I'm assuming most of them come later. I also think that checkbox should be disabled when already signed in - it doesn't make sense to toggle it in that case and things would be certain to break - but it seems a pragmatic solution to a special one-off problem.

I think it's worth getting Gijs' feedback too though.

Comment 25

[Hector Zhao [:hectorz]]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #24)

Hi Mark,

Thank you!

I don't have any problem with that patch conceptually. It needs more comments, some tests and I'm not sure about the hard-coded strings there (but do understand these aren't typical user-facing strings too, so would need to think more about that) but I'm assuming most of them come later.

Yes, I will start adding those once everyone agrees this approach is a reasonable one.

I also think that checkbox should be disabled when already signed in - it doesn't make sense to toggle it in that case and things would be certain to break - but it seems a pragmatic solution to a special one-off problem.

UI changes in these patches are limited to the FXA_PAGE_LOGGED_OUT page of gSyncPane and won't be visible once an user signs in.

I agree similar change to the FXA_PAGE_LOGGED_IN page should be read only.

I think it's worth getting Gijs' feedback too though.

Comment 26

[:Gijs (he/him)]

Sorry this took me a while to get back to. I'm not a UI designer, but it seems like there are effectively 3 cases here:

1. the user is using the default sync service (no autoconfig URL) and is not in China. We shouldn't change the UI at all in this case, to avoid complexity that could confuse users.
2. the user is in China and gets an option for the China-specific accounts service. We should show UI for this.
3. the user is using (or at least, autoconfig URL is set to) some 3rd server. We should show UI for this.

Like in comment #24 I think conceptually the patch is fine though there are some technical issues and some design issues to sort out. For instance, I think if using a custom sync/fxa server this information should be available (but not immediately mutable) even when signed in, so that there is some trace of what's going on if there's a preference hijack of sorts.

I think radio buttons are probably the best choice for UI here, though we could also use a menulist, or a checkbox if the choice is just between Mozilla China's server and the global one.

I think the Mozilla China option should be restricted to the repack, and that we will therefore need to use some other check than just checking for the language (I believe mozilla.org distributes zh-CN builds that are not the Mozilla China repack?) to decide when to show it.

In terms of precedence, I think this is more or less similar to the DoH UI that lists specific providers as well as providing a "custom" option, and where we have now started work to offer e.g. people on the US Comcast ISP a Comcast-controlled DNS-over-HTTP option.

Finally, I'm a bit wary of what sign-off this kind of thing is going to need. I don't know the answer to that. Mark, can you take point on figuring out the answer to that?

Comment 27

[Shane Caraveo (:mixedpuppy)]

Thinking about the ux aspect of this, if it were completely generalized, I would think that we would do something similar to the Homepage preference.

Accounts Service Provider: [dropdown menu]

dropdown menu:

Firefox USA
Firefox China
Custom Service URL

When custom url is choosen, there is a text entry box.

If we only want it to appear in China, we might only provide the USA/China options. Though it may be nice to at least show the custom url if it is set via enterprise policy (or via pref modification).

I would suggest getting some UX feedback (ni?abenson) and perhaps someone to consider the correct content (ni?meridel). They can forward the ni to someone else if necessary.

Comment 28

[Hector Zhao [:hectorz]]

Hi Gijs,

Sorry I didn't respond earlier.

(In reply to :Gijs (back Aug 3rd; he/him) from comment #26)

......

...... For instance, I think if using a custom sync/fxa server this information should be available (but not immediately mutable) even when signed in, so that there is some trace of what's going on if there's a preference hijack of sorts.

I didn't include any changes to the FXA_PAGE_LOGGED_IN page in my PoC patch, because I feel it most likely will be a read only warning of sorts, and want to wait until a concensus is reached on the proposed approach regarding the primary interactions.

I think radio buttons are probably the best choice for UI here, though we could also use a menulist, or a checkbox if the choice is just between Mozilla China's server and the global one.

Checkbox is chosed in my PoC patch mostly because it only introduces one hardcoded zh-CN string.

I think the Mozilla China option should be restricted to the repack, and that we will therefore need to use some other check than just checking for the language (I believe mozilla.org distributes zh-CN builds that are not the Mozilla China repack?) to decide when to show it.

A check for distribution.id was already included in the patch, when I said "limited to zh-CN locale" in comment 23, it was meant to explain why the checkbox label is hardcoded.

Comment 29

[Hector Zhao [:hectorz]]

Hi Shane,

Thanks for the comment.

(In reply to Shane Caraveo (:mixedpuppy) from comment #27)

Thinking about the ux aspect of this, if it were completely generalized, I would think that we would do something similar to the Homepage preference.

......

If we only want it to appear in China, we might only provide the USA/China options. Though it may be nice to at least show the custom url if it is set via enterprise policy (or via pref modification).

My impression is most would agree the fact a custom FxA is in use should be more discoverable in about:preferences#sync, but I'm not sure it's desirable to surface the option more prominently to general audiences if they're happy with the official service.

For the cases mentioned by :Gijs in comment 26:

• Nothing changes for 1;
• UI is shown for 3, with an action to easily revert to the official service;
• For 2, the special case for China repack, both China & global FxA stacks should be considered official, it should be possible to switch between them at any time.

I would suggest getting some UX feedback (ni?abenson) and perhaps someone to consider the correct content (ni?meridel). They can forward the ni to someone else if necessary.

Hello Aaron & Meridel, please let me know if you need anything from me to evaluate this change, thanks!

Comment 30

[Meridel [:meridel]]

I think I need a short meeting to walk through this—trying to track context here but have some basic questions. Shane, would you be the person to meet with?

Comment 31

[Hector Zhao [:hectorz]]

Hi everyone,

I've created this GDoc with summarized backgrounds (from my point of view, obviously) and brief explanations/screenshots of my current PoC patch, hopefully it would be helpful.

Comment 32

[Shane Caraveo (:mixedpuppy)]

I'm not sure who should be driving this bug, but I don't have anything to add here so clearing my ni.

@Meridel, the doc Hector added in comment 31 might help.

Comment 62

[David Lawrence [:dkl]]

The content of attachment 9347811 [details] has been deleted for the following reason:

Spam

Comment 63

[David Lawrence [:dkl]]

The content of attachment 9347812 [details] has been deleted for the following reason:

Spam

Comment 64

[David Lawrence [:dkl]]

The content of attachment 9347815 [details] has been deleted for the following reason:

Spam

Comment 65

[David Lawrence [:dkl]]

The content of attachment 9347816 [details] has been deleted for the following reason:

Spam

Comment 66

[David Lawrence [:dkl]]

The content of attachment 9347817 [details] has been deleted for the following reason:

Spam

Comment 67

[David Lawrence [:dkl]]

The content of attachment 9347818 [details] has been deleted for the following reason:

Spam

Comment 68

[David Lawrence [:dkl]]

The content of attachment 9347819 [details] has been deleted for the following reason:

Spam

Comment 69

[David Lawrence [:dkl]]

The content of attachment 9347820 [details] has been deleted for the following reason:

Spam

Comment 70

[David Lawrence [:dkl]]

The content of attachment 9347821 [details] has been deleted for the following reason:

Spam

Comment 71

[David Lawrence [:dkl]]

The content of attachment 9347822 [details] has been deleted for the following reason:

Spam

Comment 72

[David Lawrence [:dkl]]

The content of attachment 9347823 [details] has been deleted for the following reason:

Spam

Comment 73

[David Lawrence [:dkl]]

The content of attachment 9347824 [details] has been deleted for the following reason:

Spam

Comment 74

[David Lawrence [:dkl]]

The content of attachment 9347825 [details] has been deleted for the following reason:

Spam

Comment 75

[David Lawrence [:dkl]]

The content of attachment 9347829 [details] has been deleted for the following reason:

Spam

Comment 76

[David Lawrence [:dkl]]

The content of attachment 9347830 [details] has been deleted for the following reason:

Spam

Comment 77

[David Lawrence [:dkl]]

The content of attachment 9347831 [details] has been deleted for the following reason:

Spam

Comment 78

[David Lawrence [:dkl]]

The content of attachment 9347832 [details] has been deleted for the following reason:

Spam

Comment 79

[David Lawrence [:dkl]]

The content of attachment 9347833 [details] has been deleted for the following reason:

Spam

Comment 80

[David Lawrence [:dkl]]

The content of attachment 9347834 [details] has been deleted for the following reason:

Spam

Comment 81

[David Lawrence [:dkl]]

The content of attachment 9347835 [details] has been deleted for the following reason:

Spam

Comment 82

[David Lawrence [:dkl]]

The content of attachment 9347836 [details] has been deleted for the following reason:

Spam

Comment 83

[David Lawrence [:dkl]]

The content of attachment 9347837 [details] has been deleted for the following reason:

Spam

Comment 84

[David Lawrence [:dkl]]

The content of attachment 9347838 [details] has been deleted for the following reason:

Spam

Comment 85

[David Lawrence [:dkl]]

The content of attachment 9347839 [details] has been deleted for the following reason:

Spam

Comment 86

[David Lawrence [:dkl]]

The content of attachment 9347840 [details] has been deleted for the following reason:

Spam

Comment 87

[Mark Hammond [:markh] [:mhammond]]

With the question of the china repack unclear and the lack of any other requests or justification for a new extension API for this, I suggest we just close this?