It wasn’t me, but I’m glad to hear it! I should also say that your previous attempts to contact AMO reached the right folks. I think it’s mostly coincidence that action was taken shortly after I commented here.
@stig Unsure if this will keep being a problem for you, but if it does then you could consider rigging your original code to either not function correctly and/or show a warning popup whenever the extension id does not match yours, and remember to obfuscate it so it isn’t easy for them to track it in code. This way, whenever someone installs a blind copy of your original code from AMO the user will be either informed of the situation, or the extension will not work correctly, or both.
3 Likes
@Particle, very interesting idea.
First of all, I wish you gave me that tip half a year ago 
But it got me thinking…
I’m not sure it would be a good idea to obfuscate any code, that would also mean trouble for me when submitting new versions to AMO.
The questions is, should I try to make it difficult for the spammer, or should I make it easy for users to discover they have an unofficial version?
Even though the spammer hasn’t changed anything in copies I have checked, the spammer knows Git good enough to import my repository and zip content of a folder (it’s a snapshot of code in-between two official releases). So I will assume spammer has some coding experience too. Will the spammer just jump to another extension if I put a simple “integrity check” on extension’s onboarding page? There’s a good chance I guess, but if not I will always be one step behind if he starts modifying my code.
If I focus on users only, I’m thinking about not making the “integrity check” immediately. Maybe wait until a day or two after install, and hope that spammer never discovers the check, and thus never look for a way to remove it?
But of course, nothing here helps fighting the current spammer, unless he gets the idea of taking a newer snapshot, instead of just continuing using the same as he does currently 
…
Yes, I’m just thinking out loud here. Comments and ideas are welcome (and I hope spammer doesn’t follow this thread )
1 Like
You could also check details.temporary in the runtime.onInstalled listener.
Spammers probably won’t install their clone extensions from AMO to see if they really work.
Or combine this with your method.
edit:
LoL, I’ve just gone on a reporting spree.
But AMO doesn’t let me report any more clone SEO spam add-ons:
“This request was throttled. Expected available in 84015 seconds.”
= 1400.25 minutes = 23 hours and 20.25 minutes
Mozilla, please don’t be mad at me 
2 Likes
Does anybody know if there is a way for an extension to make a link to the AMO-page it was installed from?
I tried using the extension-id as search-input on AMO, but that didn’t work…
If the extension ID is: “{914110ae-a286-4f40-abe3-fb421f459994}”
then the AMO page is: https://addons.mozilla.org/addon/{914110ae-a286-4f40-abe3-fb421f459994}
(using a recent clone extension as an example)
2 Likes
Ah, so simple I should have guessed - Thanks.
The AMO-name of the extension is not known by the extension itself, nor seems to be shown by the browser anywhere. So it can be difficult for an ordinary user to find out where it was installed from (the only way I have found in browser, is to follow link to reviews from extension manage details page - not very intuitive or easy to find). But now I can point directly to the install-page 
Sorry, I am afraid I can’t provide you with a definite answer. Obfuscation does not necessarily mean the text has to be garbled, the code itself can be dynamic, not fit a specific pattern (function offuscate(), function ObfUsct(), const ofsct = function(), etc), move the code up and down in the source code and fragment it, and so on. It was simply a suggestion in case you might face the same situation again, which I hope it does not happen.
Another idea would be to make bait releases in your repo only and you don’t release them on AMO, so essentially the copycats would blindly grab that version and uploaded it to the store and any users would get a warning or something informing them that they are using a fake version and to make sure that any installs are made from - and you provide the only official link to your extension.
But if you also do releases to the public in your repo (users actually install directly from your repo releases) you’d have to make sure they wouldn’t be served with that version either, otherwise that idea wouldn’t be a viable strategy.
Just a note, I think it’s possible to find out the current extension GUID by running the following command:
browser.runtime.getURL("")
Should return the following string
"moz-extension://914110ae-a286-4f40-abe3-fb421f459994/"
And you can just remove the surrounding moz-extension://.../ to get the extension GUID.
But you could just as well fetch your manifest id since it should be unique for every addon that wants to be listed on AMO
browser.runtime.id
or
browser.runtime.getManifest().applications.gecko.id
If you don’t have that ID already set on your manifest, you can always download your AMO listing and check that manifest file. As far as I can see, this is the one AMO assigned to your extension:
An important reminder; the ids returned by getURL and *.id are not guaranteed to be the same if you have an id manually entered in your manifest, but the one returned by getURL should always be the same that is used by the AMO store listing.
Hi @Particle
Thanks for tips, but they are confusing me a bit…
My impression from reading elsewhere is that…
… is an “installation specific id”, and not my “general” extension-id. If I look at the URLs of my extensions own “internal pages” (up/on-boarding, options and exif-popup) they use such an URL, but the id is not the same as the one AMO have inserted in my manifest file.
I think this is the one which will give me my general “extension id” that AMO has inserted into my manifest file, and browser.runtime.id would also be the id I can use for AMO install-page links?
But I cannot really test it without uploading to AMO 
…
Is this valid? I have no “applications” property in my manifest file!? I’m thinking it should be getManifest().browser_specific_settings.gecko.id, but it is probably easier to just use browser.runtime.id instead.
( Slightly off-topic note: I only just recently really started noticing and caring about these ids when investigating these clone extensions. But also stumbled upon a remark (here on discourse.mozilla.org I think) telling it is mandatory to specify “your” id in manifest v3 before upload to AMO. Maybe I haven’t studied MV3 guidelines good enough, but I haven’t seen any mentions on how to get your current id, because I assume it is a good idea to insert the same id in manifest v3 as was used for MV2? But that was an off-topic comment about MV3 guidelines and documentation. And maybe I just overlooked it and it is not an issue at all… )
… is an “installation specific id”, and not my “general” extension-id.
Good call, I honestly am not sure either.
But I cannot really test it without uploading to AMO
I see, it’s the chicken and egg situation. My suggestion if you plan on making use of that information is to add some sort of line or debug method (it would do nothing at all) just to check if that id is correct in a future version update you upload and go from there. After you confirm that you will know if you can use that id for anything after that.
Is this valid? I have no “applications” property in my manifest file!? I’m thinking it should be getManifest().browser_specific_settings.gecko.id , but it is probably easier to just use browser.runtime.id instead.
Sorry, seems like in MV3 “browser_specific_settings” replaced by “applications”.
telling it is mandatory to specify “your” id in manifest v3 before upload to AMO.
If you add your own id it would make things easier for sure, and that id would be returned by browser.runtime.id as is too.
it is a good idea to insert the same id in manifest v3 as was used for MV2
Very good question, I honestly do not know how it works in your case since you never had your own id before, but AMO was adding one in place. I’m afraid I won’t be able to help you with that one thought.
I know this, in my extension additional details (where you can add featured screenshots and change the listing details) this information is shown:
I wonder what shows in yours, and if you can set yours. I cannot change mine because I always had it, but I wonder if someone who didn’t have before can add it there.
Ahh yes, there it is. Same value as inserted by AMO in my manifest. And no, I cannot edit it either.
When dynamically linking to AMO, I’d recommend using this pattern.
url = `https://addons.mozilla.org/addon/${browser.runtime.id}`
This will work in all Firefox extensions, even if the manifest does not explicitly include a browser_specific_settings key or the legacy applications key in the manifest. Also, note that the URL doesn’t include a locale ID or either “/firefox/” or “/android/”. By excluding these signals, we’re asking AMO to automatically figure out which local and type of device the user is on.
I’d strongly encourage you not to obfuscate your code. Here’s the relevant section of AMO’s policies (emphasis mine):
Add-ons are not allowed to contain obfuscated code, nor code that hides the purpose of the functionality involved. If external resources are used in combination with add-on code, the functionality of the code must not be obscured. Minification of code with the intent to reduce file size is permitted.
Even if you are able to submit a new add-on that contains obfuscated code, this practice is officially against policy and will likely get your add-on taken down in subsequent reviews.
You are correct. The ID used in an extension’s URL is actually generated at browser start time. As a result you should really only use this to link to assets inside your extension’s package, such as when you embed an iframe in a website via a content script. (See also web_accessible_resources.)
Yes and no. No in that Firefox Add-ons used to use the "applications" manifest key and it’s use in a manifest.json file is not recommended. Yes in that when Firefox load an extension, it will parse the value of "browser_specifid_settings" and use that to populate an internal applications property for the manifest. This is an implementation detail due to Firefox’s legacy behavior and is not guaranteed to be available in the future. As such, direct interaction with this property is not advised.
You can declare your own ID on AMO during the creation flow for a new add-on.
1 Like
I should have made it clear from the beginning since that word is very tied to garbling code form. Obfuscation can also be achieved in simpler ways, where the specific function, body, or logic changes with each iteration - not necessarily encoding it. You can change the function name to different variations of the same name, you can split the function into two or more code blocks instead of having it all in one, changing the position in the code, etc. It’s a lighter obfuscation than what the word is usually used for, and it wouldn’t go against AMO’s rules, and would make it harder for blind copy-cats to patch it every single time.
I see, so it’s the opposite of what I interpreted, applications is legacy, not V3. Thanks for making that clear.
Hi @dotproto or other Mozilla/AMO people
Frustrations are building up again
Any updates on eventual plans from Mozilla to stop the spam-extensions being posted on AMO? I hope not I’m going to need to continue reporting new extensions myself forever…
How are reports on add-ons handled by Mozilla? Are they processed chronologically?
I have reported 10 new clones this year and two of them has been removed. At least one of them very fast after the reporting. However it seems random which ones was removed, and the oldest (first reported) extension is still to be found on AMO.
Does that mean that (some of) the other reports have also been processed by admins, but conclusion was against removing the add-ons?
I make all the reports authenticated as myself (same account as used to update my own xIFr extension). So it seems relevant to give me some response if a report is rejected. But I have never received any response on the reports.
Would it be a good idea to report the older clone extensions on more time on AMO? Or should I try sending an email to AMO-admins again (I stopped that practice when it became possible to report authenticated on AMO)?
Whenever I report an extension on AMO, I mention all the other clone extensions too that haven’t been removed yet. But I don’t know if AMO-admins only will react on the exact extension report was posted on?
The following is how my reports look. I usually just copy this text and add the latest clone-extension to the list:
This, and other currently available extensions:
ImageMetaViewer - https://addons.mozilla.org/firefox/addon/xxxx/ (Feb 17)
PhotoInspector - https://addons.mozilla.org/firefox/addon/xxxx/ (Feb 12)
MetaView New - https://addons.mozilla.org/firefox/addon/xxxx/ (Feb 8)
ImageMeta Analyzer Pro - https://addons.mozilla.org/firefox/xxxx/ (Feb 4)
MetaInsight Viewer - https://addons.mozilla.org/firefox/addon/xxxx/ (Jan 30)
MetaTag Inspector - https://addons.mozilla.org/firefox/addon/xxxx/ (Jan 22)
MetaVision Explorer - https://addons.mozilla.org/firefox/addon/xxxx/ (Jan 11)
MetaMap Viewer Pro - https://addons.mozilla.org/firefox/addon/xxxx/ (Dec 30)are all clones of my “xIFr” extension posted here on AMO. They follow in the footsteps of 27 other “clone extensions” you have deleted (thanks!) since middle of November…
MetaExplore Pro, PicData Viewer Pro, PicData Analyzer, ImageMeta Master, ImageData Explorer, PicInspector Plus, MetaView Pro, Image Metadata Master Pro, MetaLens Master, DataLens Pro Max, EXIF Inspector Pro, MetaLens Pro, Photo Metadata Viewer, EXIF Master Pro, EXIF Explorer Pro, Image Data Master, Photo Data Viewer Pro, Image Insight Pro Max, MetaView Max Pro, Imago Meta Detect, Meta Visio+, Imago Meta View, MetaXplorer, Pic Meta Detect, xMetaViewer, Image Insights+ and MetaViewr
I believe these extensions are all in violation of Mozilla Add-on policies, especially:
- if the add-on is a fork of another add-on, the name must clearly distinguish it from the original and provide a significant difference in functionality and/or code.
- Add-ons with the sole purpose of promoting, installing, loading or launching another website, application or add-on are not permitted.
The extensions all seems to be copied directly from my “xIFr” repository. To be exact, based on a snapshot shortly after I tagged version 2.12.0.
Someone published copies of my add-on on AMO
The following is a direct link to the snapshot in my repository. The “spam-extensions” is simply content of the WebExtension folder in this snapshot:
https://github.com/StigNygaard/xIFr/tree/c652833a7324391d9937771084d94f05ae5c9337
“SEO-link spamming” from the uploader-accounts, so far looks like being the primary purpose of these “clone extensions”. Usually you will find SEO spam-links on the uploader-accounts’ homepage-links, though I have noticed the link is sometimes not present immediately after upload of the extensions, but added a little later.
To my great discomfort, the extensions being direct copies of xIFr also means the manifest.json file plus the up/on-board pages and options-page of the extensions includes all the original references to me (as the author), my homepage (including my contact-info at https://www.rockland.dk/xIFr/ and the intro-page at https://www.rockland.dk/xIFr/start/) and my github repository (https://github.com/StigNygaard/xIFr). Also the extensions identify themselves as “xIFr version 2.12.0” both when and after installing. NOT by the name they have on AMO:
Someone published copies of my add-on on AMO
PS. I know xIFr is far from the only extension being copied and abused for spam like this right now. I know manpower for manual checks of all new extensions is not easy for Mozilla to get or prioritize. But maybe put a fee on every new extension being published? It can be a small symbolic fee, the important thing is there is some needed payment-step. I think that would stop the current systematized spamming?
I report as authenticated and check “It violates Add-on Policies” and “Both locations”.
Can I do any better?
And the latest of the listed (ImageMetaViewer, uploaded Feb 17) was also removed very quickly after I reported it. But the others are still here - and a new MetaLens (uploaded Feb 20) too.
I guess, I try reporting the others one more time, and asks if I can get some kind of response on why, if AMO-admins doesn’t think they should be removed…
I hope my reports aren’t somehow blocking your reports in the moderation queue:
- MetaMap Viewer Pro
- MetaVision Explorer
- MetaTag Inspector
- MetaInsight Viewer
- ImageMeta Analyzer Pro
(I reported the users, not the extensions)
And I don’t know how many people Mozilla can spare for anti-spam measures, after the recent round of layoffs.
@hans_squared I can only be grateful for you also reporting.
And yes, I am partly frustrated by the time it can take for extensions to be removed. But I’m mostly frustrated when it doesn’t happen chronologically, because I don’t know if that maybe means the older - still present extensions - also was reviewed but found to be ok by the reviewer!?
Most of the latest mentioned extensions have now been removed from AMO. If it was because I wrote here again, or if it was because I have resubmitted reports on listed extensions, I don’t know?..
Strangely though, MetaVision Explorer from Jan 11 is still available on AMO. And a new Image Info Explorer was also posted yesterday. But definitely a step forward…
But really wish there was some more transparency on whats going on. Why are some extensions almost immediately deleted when reported, and others need a second (or more?) reporting or writing here? Do Mozilla forget to look at some of the reports, or are someone deciding it is not always relevant to delete the extensions I am reporting?