Not really easily in general sense, given that it's JS and not, say, Haskell or BitC.
But true enough, you can spend some time and check that it's unlikely to be executed, unless there's some hidden malicious obfuscated code sneaked under the hood. And discovery of such code would be a giant scandal, so it's unlikely there'd be some - it just won't worth it. Anyway, such analysis would take some time and skill. It's not really possible to just open Firefox source code and immediately understand what's going on. And I was commenting on the general nature of Firefox, not this particular button.
To be precise, though, static analysis can only confirm that there are no obvious direct references to the specific code parts outside of certain areas. Given that in a language like JS such references are surely not the only way how execution can get there, the task is not really trivial.
> And I was commenting on the general nature of Firefox, not this particular button.
Then we have no argument there. I thought you were commenting on the general nature of the Pocket feature, which is also probably complicated given it's its own separate thing, and my reply was just echoing that you only need to understand and audit the layer that talks to the black box. In this case, a button response handler.
I found https://hg.mozilla.org/mozilla-central/file/tip/browser/comp... within 5 minutes of looking. It's very readable, I spent another 5-10 minutes reading it. This is the first time in memory I've looked at Firefox's code, so I didn't even know where to find it, though I'm sure I've browsed bits of the codebase before for some reason. I first browsed to their files, went to 'browser', and since we're talking about the button I thought 'components' was a good next choice, and hey, a pocket directory. Lucky? Maybe. Reading through the component tells me the initial claim of nothing important happening until you click the button seems accurate, except that functions are exposed publicly so other bits of Firefox could probably get at them without user interaction, and when you do click on it (L165) it'll prompt you to sign up at about:pocket-signup before doing anything. If I wanted to get rid of this, googling seems to say you can override default components with some extra effort. I build Firefox from source (Gentoo) so it would be simpler to just add a patch to the build process that removes the whole directory and deletes the dir line from moz.build.
This is just static human analysis, it didn't take much time or skill. But static analysis isn't the only thing you can do, as I initially said "verify". Active verification by monitoring and alerting works great, and if you can do rebuilds like you can with Firefox then you have even greater control. If I were particularly concerned about something happening without my knowledge (with or without the button) I'd use what I learned from reading the code to monitor my network for outreaches to pocket's website. Of course I can't be fully certain some other code doesn't send all my visited sites to some other IP (or maybe an IRC server) that is then harvested by pocket asynchronously... But as you say, it's very unlikely for such malicious and underhanded code to be there.
But true enough, you can spend some time and check that it's unlikely to be executed, unless there's some hidden malicious obfuscated code sneaked under the hood. And discovery of such code would be a giant scandal, so it's unlikely there'd be some - it just won't worth it. Anyway, such analysis would take some time and skill. It's not really possible to just open Firefox source code and immediately understand what's going on. And I was commenting on the general nature of Firefox, not this particular button.
To be precise, though, static analysis can only confirm that there are no obvious direct references to the specific code parts outside of certain areas. Given that in a language like JS such references are surely not the only way how execution can get there, the task is not really trivial.