Tampermonkey: origin of this script cannot be determined?

Created on 1 Mar 2019  路  24Comments  路  Source: Tampermonkey/tampermonkey

hello,
I'm syncing my browser backup at work and I received this message:
tampermonkey the origin of this script cannot be determined maybe because hardware has changed,
how could I avoid that?
is there any setting in tampermonkey I need to change to allow for different hardware configuration or
shouldn't I sync some files/folders?
thanks

tampermonkey latest version (unpacked) on cent brownser latest version

fixed at beta

Most helpful comment

Should be fixed now.

All 24 comments

ok I've found out that when I sync (=mirror copy) this folder:

\CentBrowserPortable\User Data*\Local Extension Settings\lkekbnepoojggkmajeekfjpmolgljpbl
\PortableApps\GoogleChromePortable\Data\profile*\Local Extension Settings\lkekbnepoojggkmajeekfjpmolgljpbl

(for cent browser and chrome respectively),

tampermonkey becomes a mess next time it opens,
why is that?
I guess these folders contain the extension's settings,
so, what if there are changes in its settings indeed?

why can't I sync them with browser copy?

there should be some way to disable that behavior, right?

even though I excluded the folders
\CentBrowserPortable\User Data*\Local Extension Settings\lkekbnepoojggkmajeekfjpmolgljpbl and
\PortableApps\GoogleChromePortable\Data\profile*\Local Extension Settings\lkekbnepoojggkmajeekfjpmolgljpbl
(tampermonkey folder)
from sync, I still had issues after today's sync,
my scripts had a strike-through font over them,
like they were deleted or something,

so I guess I have to restore from tampermonkey's backup each time?

maybe offer a solution please?

edit: oops, I've had a bug in the first one, it should be \Portableapps

\PortableApps\GoogleChromePortable\Data\profile*\Local Extension Settings\lkekbnepoojggkmajeekfjpmolgljpbl
(tampermonkey folder)

This is no official Tampermonkey extension ID, right?

isn't it?
I've got it unpacked, I extracted it with the way you told me on email (download the url),
is it wrong?

Yeah, this started happening ~ 3-4 months ago for me as well, and it's a real PITA. My install is the regular CWS TM Beta. I've been using a Chromium fork which is truly portable for years, and copying the whole folder to another computer has never been an issue, but recently TM started disabling all scripts with the "unknown origin" warnings.

If it's some sorta new security measure, that's all well and good, but it'd be nice if you gave us the option to disable it. It breaks portability, which is super annoying.

copying the whole folder to another computer has never been an issue

This is an experimental feature of TM BETA as a consequence of #635, which tries to prevent script modifications from outside. So from this point of view it's doing what it was designed for. 馃榿

You can re-enable all scripts by running this command at the extension background page:

scbr.getUidList().forEach(function(uid) {
    var s = scbr.getByUid(uid);
    s.script.evilness = 0;
    scma.doModify(uid, s.script, false);
});

but it'd be nice if you gave us the option to disable it.

The problem is that the whole storage can be modified from outside. If the user can turn it off, then any third-party can turn it off as well.

isn't it? I've got it unpacked, I extracted it with the way you told me on email (download the url),

No this is not the official ID. Unpacked extension get a new ID when they're loaded.
This protection is not (yet?) enabled at the stable version, but you have to drag and drop the crx to Chrome's extension page (chrome://extensions) to make sure the official extension ID is preserved.

so you're saying that it is doing this to me because the id is wrong?
my version of tampermonkey is 4.8,
can you give me a link of a version without this behavior (to run in my portable)?

I get it. Still hate it, but I get it. Wishful thinking would be that you'd be able to prevent the same vulnerability by tying legit installs to the browser they were installed in, and somehow leave the portability of that browser alone.

You can re-enable all scripts by running this command

I'm not psyched about any extra step. The computer I sync is an entertainment center with a remote control, so running code in the console is an even bigger PITA than exporting and re-importing. Bottom line is, I'm gonna forget about this every time I re-sync and then only remember when I'm browsing and nothing's working, which will suck every time.

also, if I load the extension with the way you say @derjanb, I'll get the official id, but it won't be unpacked, so I don't think there's a way to load an extension unpacked and still maintain its id and I prefer the unpacked behavior because there are this and a couple more extensions that I want to update whenever I want to

anyway, I've found 4.7.54 version, is this one without the "security feature" we're talking about?

This issue has nothing to do with the id. My install is from CWS, and I have the same problem.

I've just checked with 4.7.54, I've overwritten local settings folder from usb backup and it worked, @narcolepticinsomniac you can try too

I just tested on chrome portable too and it worked there too

Getting stuck on some random version of TM forever isn't a solution to me. I would if this were some kinda bug that'd get worked out eventually, but that isn't the case. He'll either fix portability, or he won't. If I get annoyed enough with it, I could always use some other extension, but I probably won't because I prefer TM.

What I don't really get is why TM is held responsible for malware on the OS level. Malware has been compromising browsers since browsers existed, and if you're dumb enough to infect your own computer, you get what you get. The fact that this all spawned from Opera's extension gallery, which is an absolute joke, is unfortunate.

I didn't say I'll get stuck on this version forever, but for the time being at least I'm fine with it,
or, if you prefer, I prefer portability over having the latest version anytime

The computer I sync is an entertainment center with a remote control,

How about syncing the scripts via TamperDAV a NodeJS based webDAV server? Would that be an option?

This issue has nothing to do with the id. My install is from CWS, and I have the same problem.

The stable version is excluded by extension ID. That's why an unpacked stable version has it enabled.

What I don't really get is why TM is held responsible for malware on the OS level. Malware has been compromising browsers since browsers existed, and if you're dumb enough to infect your own computer, you get what you get.

Yes, it's difficult. That's why it's an experimental feature, because I don't know whether I'll keep it. The problem is that it's too easy to run third-party code via Tampermonkey.

Maybe I'll limit it explicitely to the CWS extension IDs. Unpacked extensions are limited by Chrome anyway.

How about syncing the scripts via TamperDAV a NodeJS based webDAV server? Would that be an option?

Nah, I'm using the term "sync" for lack of a better one that comes to mind. Maybe once a month, or anytime I've made significant changes to a bunch of different things in the browser that'd be useful on the other computer, I delete the old copy and do a copy/paste transfer over the network.

Maybe I'll limit it explicitly to the CWS extension IDs

Seems like that'd be sufficient. I really hope you decide to go that route instead.

I'm syncing between two computers via freefilesync lately, total commander before

I really hope you decide to go that route instead.

Latest BETA (4.9.5921) should work as usual again.

Great news man, thanks!

Btw, I left an update in the layout repo a couple months ago. There's a bunch of bug fixes, improvements and some compatibility optimizations for older browsers. If you're ignoring it on purpose, go ahead and keep doing that. Might be worth mentioning in case you missed it though.

Just made my first transfer with 4.9.5921 installed, and I'm getting the same "origin cannot be determined" issue. Expected it to work, so that was kinda disappointing.

there was just an update:

4.8.41
2019-05-06

General:
Re-enable persistent storage in incognito mode
Fix GM_xhr onabort callback
Fix GM_xhr blob response type property
Fix an issue where uBlock Origin prevents script execution
Sandbox fixes
Rely on permissions.getAll instead of permissions.contains
Sync:
Fix cloud services authentication

is our issue fixed? do we update @narcolepticinsomniac?

no, it isn't fixed

Should be fixed now.

Was this page helpful?
0 / 5 - 0 ratings