Hacker News Reader

Comment by gruez | Hacker News Reader

>I'm not saying this author is acting maliciously but a very common attack is to say something is open source, point to the repo but in reality the code running in the extension is unrelated to that repo.

The extension is small enough that you can inspect it yourself. Also, AMO addons are code-inspected by reviewers, unlike the chrome store.

>Now, when it comes to Chrome extensions I do believe there's ways to check out the source code of any extension you use, so you could double check it there but then you have to worry about the extension getting updated too.

That's why I disable addon updates for "uncommon" addons.

View on HN

> Also, AMO addons are code-inspected by reviewers, unlike the chrome store.

Are they still? Last I remember they started auto-accepting addons which passed the automatic tests and just maybe review them at a later point. Which could happen anytime between tommorow and next year. In the meanwhile the unsecure addon is floating around, endangering users.

There now is also this message: "This is not a Recommended Extension. Make sure you trust it before installing."

This kinda indicates the user is on it's own with such extensions, and there is no review at all?

> The extension is small enough that you can inspect it yourself. Also, AMO addons are code-inspected by reviewers, unlike the chrome store.

I've never been involved with performing code reviews for Chrome or FF extensions but I'm not sure this type of attack would be detected by a reviewer.

Because if all they do is take the HTML response and send it over to some web back-end with an ajax request, that looks innocent enough to any reviewer. For example, under what grounds would a reviewer flag that ajax request as malicious and prevent the extension from being published? It's not possible for them to know what purpose that data has for the extension unless they are really doing a deep dive on each review and take the extension's purpose into account based on their opinion of what it "should" do based on its description.

I'd love to hear back from anyone who happens to review extensions for either browser.

> if all they do is take the HTML response and send it over to some web back-end with an ajax request

This extension does not do that. Most extensions with the "Access your data for all websites" permission also do not do that. The permission is required to scan data (in this case, links) in the websites visited by the browser, and does not mean that the data in the website would necessarily be sent to a server. Neat URL processes the links locally.

You can inspect the source code of any WebExtension you have installed by downloading the package, renaming it to the .zip extension, and unzipping it (as .xpi files are equivalent to .zip files). For Firefox add-ons, right-click the "Add to Firefox" button on the extension listing, and click "Save Link As...". The code is not minified or obfuscated.

https://addons.mozilla.org/en-US/firefox/addon/neat-url/

Small correction: you don't need to install the WebExtension to inspect it. You can just download and unzip it.

>Because if all they do is take the HTML response and send it over to some web back-end with an ajax request, that looks innocent enough to any reviewer. For example, under what grounds would a reviewer flag that ajax request as malicious and prevent the extension from being published? It's not possible for them to know what purpose that data has for the extension unless they are really doing a deep dive on each review and take the extension's purpose into account based on their opinion of what it "should" do based on its description.

I think you're giving the reviewers too little credit. There's no plausible reason why you'd need to send urls to a server to perform such a trivial transformation. Also, a search of BMO[1] shows that addons are regularly being found to breach these policies and blacklisted.

[1] https://bugzilla.mozilla.org/buglist.cgi?product=Toolkit&com... control-f for "Add-ons collecting ancillary data".

> Because if all they do is take the HTML response and send it over to some web back-end with an ajax request, that looks innocent enough to any reviewer.

That's extremely not innocent for ANY browser extension.

Yeah, that alone should be a huge red flag unless it's something the add-on explicitly advertises, like it's doing translation or something.

That was just a broad example.

What if it got a list of every link on a page and sent that and then claimed it did that to better improve the extension by figuring out which query params aren't necessary and claimed that these links help train their app / extension.

That seems reasonable on paper, but it's a wildly over the top violation of your privacy and is only slightly less invasive than an entire page response.

I don't think the above example would get denied by a reviewer and it still uses the same "can read and modify" permissions as the current extension in its current form.

Then it'd probably need a privacy policy and/or disclaimer in the addon description, which in turn would cause people to find out and downrate it to obscurity.

Are you saying it wouldn't get accepted during the review unless it had that in the description?

That seems like a dangerous rule to live by if an extension is allowed to collect all of that information and it's auto-opt-in based on it existing somewhere buried in a privacy policy or long description.

We really only ever notice the permission setting because the browser puts that in front of us before agreeing to install it and it's usually a 1 liner like "hey, this extension can access everything about your browsing history".

Reply on news.ycombinator.com