In theory, you can examine it, sure. But I fear that in practice, it's so complicated and large, it's unlikely there are many humans who can really tell about themselves that they really know how the thing works. A certain part - sure, given enough time to read and learn. A whole thing - quite unlikely.
You don't have to understand it in this case, you just have to make sure that code path isn't invoked by anything other than clicking the button. This can be pretty easily verified.
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.
Stick a printf/file write/breakpoint at the root of the code path if you want continuous verification that the code path never executes except by clicking the button. This isn't hard.
