Closed Bug 1442035 Opened 5 years ago Closed 5 years ago

Remove InstallTrigger

Categories

(Toolkit :: Add-ons Manager, enhancement)

Product:
Toolkit
Component:
Add-ons Manager
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mkaply, Unassigned)

References

Details

We should remove InstallTrigger.

It's not useful in WebExtensions with the new install flow (because you can't use a custom URL or name). And it has a problems:

https://bugzilla.mozilla.org/show_bug.cgi?id=1084646
InstallTrigger always sends third party cookies regardless of cookie settings

https://bugzilla.mozilla.org/show_bug.cgi?id=841352
Using InstallTrigger bypasses nsIContentPolicy

There are also quite a few other bugs in bugzilla we could probably get rid of.

Do we know of any major sites still using it?
(In reply to Mike Kaply [:mkaply] from comment #0)
> Do we know of any major sites still using it?

I'm pretty sure a site called addons.mozilla.org still uses it.
> I'm pretty sure a site called addons.mozilla.org still uses it.

Really? I thought they used direct XPI links now...
Nope:

https://github.com/mozilla/addons-frontend/blob/master/src/core/components/InstallButton/index.js#L147

Maybe someday we'll remove.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Interesting info from AMO on why they installtrigger if anyone ever finds this bug

•kumar> we were using mozAddonManager but then we had to remove it. We plan to add it back. Long story.
4:00 PM InstallTrigger has its own special way of handling certs. It's fun.
4:02 PM 
<mkaply> Mike Kaply kumar: What's the downside of just linking to the XPI directly?
4:03 PM 
<•kumar> hmm, I'm not sure why we use InstallTrigger
4:04 PM there is some reason
4:05 PM 
<•kumar> mkaply: oh, yeah, it's because it handles custom certs differently https://github.com/mozilla/addons-frontend/issues/3867
4:06 PM mkaply: when we link directly to the xpi, the browser does not allow built-in root certs
4:06 PM 
<mkaply> Mike Kaply interesting
4:06 PM 
<•kumar> but with InstallTrigger it does (since the file hash is used for integrity)
4:06 PM and anti-virus software replaces your root cert so it can snoop on all traffic
4:07 PM and a lot of our users have anti-virus software
Resolution: WONTFIX → FIXED
And for anybody still following along: bug 1403075 is about removing the special built-in cert handling for installs.

Seems that since this issue was closed addons.mozilla.org moved to newer mozAddonManager API - I don't see any use of InstallTrigger when looking at installation flow and a search for InstallTrigger across the project yielded no results, which means that unless I can't search properly it's not used anywhere.

Seems like with addons not using it anymore it's not really useful anymore outside of fingerprinting.

Funnily enough, it is actually used on the https://addons.mozilla.org webiste, but not for the intended purpose - it's used by web-vitals to detect the browser as Firefox. Again, going back to its only use being fingerprinting.

So, since the only downside of removal now seems to be breaking some fingerprinting I think it might be a good idea to revisit this and perhaps remove the API.

It would not only actually resolve this issue (the resolution should've stayed as WONTFIX, no idea why it's set as FIXED, as the API was not removed), but would also allow to close bug 1632146, bug 841352 and possibly bug 1692267 and bug 1404356. Additionally, it would simplify bug 1451045 (why migrate if you can delete it :)

(In reply to opliko.reg from comment #6)

Seems that since this issue was closed addons.mozilla.org moved to newer mozAddonManager API - I don't see any use of InstallTrigger when looking at installation flow and a search for InstallTrigger across the project yielded no results, which means that unless I can't search properly it's not used anywhere.

That's good to know! Hopefully this remains true.

it's used by web-vitals to detect the browser as Firefox. Again, going back to its only use being fingerprinting.

Looks like this was reported and fixed:

https://github.com/GoogleChrome/web-vitals/issues/124

So, since the only downside of removal now seems to be breaking some fingerprinting I think it might be a good idea to revisit this and perhaps remove the API.

Yup. To be clear, "fingerprinting" here includes UA detection, which might be painful to break. (as opposed to panopticlick-style "supercookie" fingerprinting, which we would be happy about breaking)

One example of a site that uses this for UA-detection is https://mozilla.crowdicity.com which is currently broken if I load it in Firefox with a Chrome UA string. (They do two-part UA detection -- first they check for InstallTrigger, then they check your UA string to find the Firefox version number. If they see that you're Firefox but you have a Chrome UA string, their version-number-parsing code is broken and the site doesn't finish loading.) The script in question is here - search that script for InstallTrigger for the first part of UA-sniffing and rv: for the second part.

Fortunately, the site seems to load fine if I load it in Firefox with the default UA string and with InstallTrigger hidden (technically I just set their JS local-variable to false after they tested for it; I didn't fully hide it).

There might be other sites that depend on this API for UA-detection in a way that would break the site if we remove it; fortunately crowdcity depends on it in a way that seems to fail gracefully if we remove the API.

Sadly big sites still use this like https://www.grammarly.com/.

It looks like we're probably never going to be able to remove it because it's a historical way to detect firefox

https://stackoverflow.com/questions/9847580/how-to-detect-safari-chrome-ie-firefox-and-opera-browser

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

It looks like we're probably never going to be able to remove it because it's a historical way to detect firefox

https://stackoverflow.com/questions/9847580/how-to-detect-safari-chrome-ie-firefox-and-opera-browser

We could make it a stub, and/or we could still "just" choose to stop providing this. There were lots of ways to detect Firefox in the past (e.g. Components object exposed on the global scope) that we've removed before now, I don't see why this should stop us here?

Based on the data, a lot of sites still use it for its original purpose.

Resolution: FIXED → WONTFIX

Mike confirmed changing it to FIXED was accidental (it didn't make sense: nothing was changed)

You need to log in before you can comment on or make changes to this bug.