[PINNED] Firefox version is out of date (pre-URL change), and we know

[cooljeanius]

I keep forgetting which discussions to refer people to when closing duplicate issues about the Firefox version being broken due to the change in URLs from Twitter to X, so I'm pinning this issue as a reminder: see discussion in #294, #321 and #327.

---

There is not a whole lot that we can do to get the Firefox version updated from our end, we have tried to implement all of their requested changes and are currently still waiting to hear back from them. If you want to talk to people who actually have power over this, use Mozilla's forum. ~@rougetimelord

[cooljeanius]

Any future dups will be closed as dups against this one instead.

[willthamic]

For anyone looking for a workaround, if are logged in and go to twitter.com/?mx=1, it'll let you browse for a while under the twitter.com domain instead of x.com, which keeps the extension working.

[rougetimelord]

Thank you omg, maybe people won't make 20 dupes of the same issue

[dotproto]

Hi folks. I'm Simeon from the Mozilla Add-ons team. I'm visiting by way of this thread.

There is not a whole lot that we can do to get the Firefox version updated from our end, we have tried to implement all of their requested changes and are currently still waiting to hear back from them.

If you've been waiting a long time (multiple weeks), something unusual is likely happening. Maybe there was a miscommunication, maybe someone missed an update. Regardless, I think your best course of action is to reply to the relevant rejection email thread to bring it back to the reviewers' attention.

[cooljeanius]

If you've been waiting a long time (multiple weeks), something unusual is likely happening. Maybe there was a miscommunication, maybe someone missed an update. Regardless, I think your best course of action is to reply to the relevant rejection email thread to bring it back to the reviewers' attention.

Hm, that would probably be up to @kheina, although that may be changing depending on how discussion in #327 goes...

[gbootsma]

Does the "wontfix" label mean that there won't be an updated version to firefox at all? or does it mean we're just waiting for firefox to approve the next version?

[cooljeanius]

Does the "wontfix" label mean that there won't be an updated version to firefox at all? or does it mean we're just waiting for firefox to approve the next version?

I think @rougetimelord meant the latter, but let's wait for confirmation...

[worsedoughnut]

Asking as an idiot, is there a technical limitation stopping the developers of Blue-Blocker from adding an XPI binary to the github releases for users to install into Firefox manually?

I only ask because there are other similarly "blacklisted" addons (most notably bypass-paywalls-clean) that use this method to get around being unable to use the mozilla addon store anymore.

[rougetimelord]

Does the "wontfix" label mean that there won't be an updated version to firefox at all? or does it mean we're just waiting for firefox to approve the next version?

I think @rougetimelord meant the latter, but let's wait for confirmation...

Waiting for Mozilla AMO to do something, and also kind of at the end of my (personal) will to make changes at their whims...

[rougetimelord]

Asking as an idiot, is there a technical limitation stopping the developers of Blue-Blocker from adding an XPI binary to the github releases for users to install into Firefox manually?

There isn't, we just haven't done that in the past. I can add uploading the zips to the release workflow pretty easily (edit: see #370)

[Baramanga]

Asking as an idiot, is there a technical limitation stopping the developers of Blue-Blocker from adding an XPI binary to the github releases for users to install into Firefox manually?

There isn't, we just haven't done that in the past. I can add uploading the zips to the release workflow pretty easily (edit: see #370)

Is there any available versions we can load manually after 4.2? It's still working but I'm just curious.

[gbootsma]

Does the "wontfix" label mean that there won't be an updated version to firefox at all? or does it mean we're just waiting for firefox to approve the next version?

I think @rougetimelord meant the latter, but let's wait for confirmation...

Waiting for Mozilla AMO to do something, and also kind of at the end of my (personal) will to make changes at their whims...

Thank you! I hope they approve the newest version soon, you have made more than enough changes because they asked for them

[rougetimelord]

Asking as an idiot, is there a technical limitation stopping the developers of Blue-Blocker from adding an XPI binary to the github releases for users to install into Firefox manually?

There isn't, we just haven't done that in the past. I can add uploading the zips to the release workflow pretty easily (edit: see #370)

Is there any available versions we can load manually after 4.2? It's still working but I'm just curious.

Following up, the v0.4.12 release has built zips attached to it. All future releases should also have built zips.

[dotproto]

Popping back in 'cause users have posted about this on our Discourse server (this is just the most recent).

@kheina, I didn't go into detail about the policy issues last time I commented for privacy reasons, but I can answer questions or provide guidance if you tag me in a question here. Alternatively, if you send an email to my first initial + last name @mozilla.com from the email address used to publish the extension on AMO, I'll take that as permission to share the reviewer's comments here.

Waiting for Mozilla AMO to do something, and also kind of at the end of my (personal) will to make changes at their whims...

Sorry, @rougetimelord. I know it's hard to get clarification form reviewers, and even if you can they're not really in a position to provide guidance on how fix policy issues. That's where I come in. Let me know if you have any questions :)

[rougetimelord]

Popping back in 'cause users have posted about this on our Discourse server (this is just the most recent).

@kheina, I didn't go into detail about the policy issues last time I commented for privacy reasons, but I can answer questions or provide guidance if you tag me in a question here

Just a heads up that Dani has been MIA for a few months, I'm currently trying to get in touch with her so I can get added on as an author on AMO but for right now, none of the active maintainers have access to the AMO listing.

Sorry, @rougetimelord. I know it's hard to get clarification form reviewers, and even if you can they're not really in a position to provide guidance on how fix policy issues. That's where I come in. Let me know if you have any questions :)

I'm confused here, the last review notes I saw was a failure to build from the source code because the host used to test that didn't have jq installed. We have since documented that jq must be installed to build the extension in the instructions, which was listed as a possible resolution, and we have taken steps to guarantee that jq is installed.
Are there other policy violations? Or is it the same one?

[kheina]

@rougetimelord you've already been added~

[rougetimelord]

@rougetimelord you've already been added~

Oop, it's not showing up on my end :(
Edit: oops got it, i'm just silly, ty <3

[kheina]

Popping back in 'cause users have posted about this on our Discourse server (this is just the most recent).

@kheina, I didn't go into detail about the policy issues last time I commented for privacy reasons, but I can answer questions or provide guidance if you tag me in a question here. Alternatively, if you send an email to my first initial + last name @mozilla.com from the email address used to publish the extension on AMO, I'll take that as permission to share the reviewer's comments here.

Waiting for Mozilla AMO to do something, and also kind of at the end of my (personal) will to make changes at their whims...

Sorry, @rougetimelord. I know it's hard to get clarification form reviewers, and even if you can they're not really in a position to provide guidance on how fix policy issues. That's where I come in. Let me know if you have any questions :)

email sent.

[kheina]

I'm currently in the hospital (and previously was preparing for being in the hospital) so apologies for being MIA. I've done my best to allow everyone here to keep things updated and running without me

[rougetimelord]

I'm currently in the hospital (and previously was preparing for being in the hospital) so apologies for being MIA. I've done my best to allow everyone here to keep things updated and running without me

Thank you so much! Hope you're doing well/heal well 💖

[dotproto]

@kheina we've only just met, but I hope you have a swift recovery!

The most recent review action I see was on Nov. 1, 2024, 11:54 AM (UTC I think?) on version 0.4.11.

Consent, specifically Nonexistent: For add-ons that collect or transmit user data, the user must be informed and provided with a clear and easy way to control this data collection. The control mechanism must be shown at first-run of the add-on. The control should contain a choice accompanied by the data collection summary. Depending on the type of data being collected, the choice to send cannot be enabled by default. If data collection starts or changes in an add-on update, or the consent and control is introduced in an update, it must be shown to all new and upgrading users. For the exact requirements, refer to https://extensionworkshop.com/documentation/publish/add-on-policies/#data-disclosure-collection-and-management . For an example of how to provide a consent and control dialog, see https://extensionworkshop.com/documentation/develop/best-practices-for-collecting-user-data-consents/ .
Also, if your add-on is listed on addons.mozilla.org, the listing needs to include a privacy policy, and a summary of the data collection should be mentioned in the add-on description.
Tab URL:
-> src/content/index.ts line 130
-> src/injected/inject.ts line 36

There are two issues identified here:

1. Externalizing the page URL
2. Privacy policy

The first one comes from the "User Consent and Control" section of the Add-ons Policies. The concern here is that sensitive user data being transmitted without the user's express consent puts them at risk of data collection, fingerprinting, de-anonymization, etc.

It looks like the reviewer was concerned with the CustomEvent('blue-blocker-event', {...}) calls in src/content/index.ts and src/injected/inject.ts
as these events externalize the user's current URL. Generally speaking browsing activity data such as the current URL of a page is considered highly sensitive, thus the concern.

My first question here would be "is it strictly necessary to pass the URL to OldTwitter?" If so, then I'm afraid the Add-ons Policies require that you disclose the fact that you "collect" this data in a data collection consent screen right after installation. The privacy policy should also disclose who the data is shared with.

[kheina]

I personally hate when extensions create new tabs on install (especially when we clearly explain how we collect data on the store page). but, regarding old Twitter, is it possible to send the data via the addon api somehow (send message or storage listeners) to avoid it being "public" and accessible to other add-ons?

[rougetimelord]

It looks like the reviewer was concerned with the CustomEvent('blue-blocker-event', {...}) calls in src/content/index.ts and src/injected/inject.ts
as these events externalize the user's current URL.

Just checking whether this is the reviewers notes or your own? It would be really nice to have more specific notes from the reviewers directly in the future, would be great if you passed that along to folks at AMO.

My first question here would be "is it strictly necessary to pass the URL to OldTwitter?"

I'm really confused with this one, the code location mentioned:

Blue-Blocker/src/content/index.ts

Lines 128 to 149 in 0e604e5

	window.addEventListener('message', function (ev) {
	if (ev.data.type !== 'OLDTWITTER_REQUEST_LOAD') return;
	if (!ev.data.url || !ev.data.body || !ev.data.headers)
	return console.error(logstr, 'OldTwitter sent an invalid payload.', ev.data);
	const body_str = JSON.stringify(ev.data.body);
	document.dispatchEvent(
	new CustomEvent('blue-blocker-event', {
	detail: {
	parsedUrl: /(.+)/.exec(ev.data.url)!, // Have to turn the endpoint string into a regex result...
	url: ev.data.url,
	body: body_str as XMLHttpRequest['response'],
	request: {
	headers: ev.data.headers,
	},
	// OldTwitter only emits messages on success.
	status: 200,
	},
	}),
	);
	});

Is an event listener that picks up on events emitted by OldTwitter and translates them into our extensions events... OldTwitter is passing the URL to Blue Blocker.

Is the problem in inject.ts that document.dispatchEvent is being used to pass information between a script that lives in the DOM and our content script? Are there suggested alternatives to do that communication?

Additionally our privacy policy explicitly lays out that the extension will share data with extensions that the user opts into integrating Blue Blocker with. So I'm also lost on what exactly y'all want changed here. See:

Blue-Blocker/privacy.md

Lines 46 to 50 in 0e604e5

	## What User Data is Shared With Third Parties
	The public user data sent by the Twitter API are parsed by the Extension, and/or extensions/addons you have opted to integrate with, and determines what user IDs are transmitted back to the Twitter API in order to block the user.
	You can optionally configure the Extension to send the Twitter data it collects to other extensions/addons ("integrations"). Data is never shared without your explicit consent, and you may revoke consent at any time. We advise you to refer to the Privacy Policies of the extensions/addons that you enable data sharing with to understand how those extensions collect, store, and use the data you provide to them.

[rougetimelord]

Is the problem in inject.ts that document.dispatchEvent is being used to pass information between a script that lives in the DOM and our content script? Are there suggested alternatives to do that communication?

I see that there's exportFunction to do this, but as a cross platform extension it feels really bad to have to rely on non-standard APIs for Firefox specifically...

[cooljeanius]

#375 should be good to merge now.

[rougetimelord]

@dotproto #375 adds a data disclosure and required consent on install/update, would that resolve the reviewer's concern or is there a problem with our privacy policy as well?

[dotproto]

Checking back in over here. Whew, buys couple of days. Sorry for the delay.

I personally hate when extensions create new tabs on install (especially when we clearly explain how we collect data on the store page). but, regarding old Twitter, is it possible to send the data via the addon api somehow (send message or storage listeners) to avoid it being "public" and accessible to other add-ons?

Fair feedback on new tabs being annoying. For the moment we don't have a better way to get this kind of explicit consent from the user, but hopefully we can improve things at the platform level in the future.

Unfortunately I don't think 1:1 communication with Old Twitter would address the concern. The core issue is the extension is externalizing data that it accesses. The specific method of externalization isn't as concerning.

Just checking whether this is the reviewers notes or your own? It would be really nice to have more specific notes from the reviewers directly in the future, would be great if you passed that along to folks at AMO.

Sorry for the ambiguity. The quote I included at the top of my reply was the the message from the reviewer. They identified two files and lines of concern: src/content/index.ts line 130 and src/injected/inject.ts line 36. I tried to map their comments to the concerning blocks of code directly in this repo. I appreciate the feedback on initial comms not being helpful enough.

Is an event listener that picks up on events emitted by OldTwitter and translates them into our extensions events... OldTwitter is passing the URL to Blue Blocker.

If I'm reading the source correctly (and I may not be), the block I highlighted in src/content/index.ts receives an event from Old Twitter and Blue Blocker replies with another event. Both the event received and the sent event contain the page's URL. I think it's just the data sent in the event that the reviewer is concerned with.

Is the problem in inject.ts that document.dispatchEvent is being used to pass information between a script that lives in the DOM and our content script? Are there suggested alternatives to do that communication?

Yep, I think that's definitely an issue. It looks like src/injected/inject.ts is shimming the page's global XHR object to broadcast the URL, response body, and headers of every XHR request via a CustomEvent. In my book that's exposing sensitive data more broadly than would happen without the extension installed.

While Firefox's Xray Vision may provide you with another way of communicating between a script injected into a page context and a content script, I'm not sure doing so will address the concerns identified by the reviewer. The simple problem is that even if the content script exported a function that the page script use to pass data back to the extension, an adversarial page may shim that function to access sensitive data.

And, as @rougetimelord mentioned, this isn't available across browsers. In the WECG we're currently discussing some new APIs that would enable secure communication between extension scripts that span words (#678, #679), but no browsers implement them yet.

I'll try to get some clarification here.

Additionally our privacy policy explicitly lays out that the extension will share data with extensions that the user opts into integrating Blue Blocker with. So I'm also lost on what exactly y'all want changed here. See:

Blue-Blocker/privacy.md

Lines 46 to 50 in 0e604e5

	## What User Data is Shared With Third Parties
	The public user data sent by the Twitter API are parsed by the Extension, and/or extensions/addons you have opted to integrate with, and determines what user IDs are transmitted back to the Twitter API in order to block the user.
	You can optionally configure the Extension to send the Twitter data it collects to other extensions/addons ("integrations"). Data is never shared without your explicit consent, and you may revoke consent at any time. We advise you to refer to the Privacy Policies of the extensions/addons that you enable data sharing with to understand how those extensions collect, store, and use the data you provide to them.

Hm. The most common issue I see with privacy policies is that the extension author hosts the policy on their own website rather than on AMO, but I can see that the policy is on AMO: https://addons.mozilla.org/en-US/firefox/addon/blue-blocker/privacy/.

I think the mention of the mention of the privacy policy in the reviewer's message is just part of the message template rather than a specific comment about your current privacy policy.

@dotproto #375 adds a data disclosure and required consent on install/update, would that resolve the reviewer's concern or is there a problem with our privacy policy as well?

I'll take a look and share feedback in another comment.

[rougetimelord]

Yep, I think that's definitely an issue. It looks like src/injected/inject.ts is shimming the page's global XHR object to broadcast the URL, response body, and headers of every XHR request via a CustomEvent. In my book that's exposing sensitive data more broadly than would happen without the extension installed.

While Firefox's Xray Vision may provide you with another way of communicating between a script injected into a page context and a content script, I'm not sure doing so will address the concerns identified by the reviewer. The simple problem is that even if the content script exported a function that the page script use to pass data back to the extension, an adversarial page may shim that function to access sensitive data.

I believe that if reviewers agree with you on this, we can no longer support Firefox. Could you ask around on your end and see if that's the case?

I think the mention of the mention of the privacy policy in the reviewer's message is just part of the message template rather than a specific comment about your current privacy policy.

I know you're not the AMO support helpline, but as an extension author the way that every reply is a template that does not give clear feedback is super frustrating and unhelpful. I don't like having policies re-explained to me, but I would like to know how I need to fix the extension. If we're going to get manual reviews I would prefer if it felt like a human read my code.

[Pxtl]

I have the sneaking suspicion that Firefox will resolve their complaints about this extension just in time for every person who wants to run BlueBlocker on Firefox to have moved onto Bluesky et al.