Closed Martii closed 5 years ago
Apologies for not getting here sooner
Not at all .. thank you for taking the time to look into it
To start with, Firefox has postponed the official release of the new API to 68 (from 65) therefore as mentioned on the description, the API in FF65-67 requires:
Note: The Official release of the API has been postponed to FF67. The API can be manually enabled for Firefox 65 & 66 users via about:config?filter=extensions.webextensions.userScripts.enabled The API is enabled by default on Nightly.
FireFox API does not support RegEx matches and FireMonkey is adhering to Firefox API standard. You should have seen a red cross next to the script name to show it and there is a notification when clicking to show the script in the editor.
// @include /^https?://openuserjs\\.org(?::\\d{1,5})?/scripts//
// @include /^http://localhost(?::\\d{1,5})?/scripts//
AFA button icon, they are ALL Unicode text and not icons per se. Their quality is not as great as proper icon but then the are scalable and added for extra context only.
I have also explained all the buttons in the Help section.
Please let me know if above was helpful.
about:config?filter=extensions.webextensions.userScripts.enabled
plus a restart of the browser.
A typical way of end users disabling metadata block keys of:
// @include /^https?://openuserjs\\.org(?::\\d{1,5})?/scripts//
// @include /^http://localhost(?::\\d{1,5})?/scripts//
... is to do this:
//@include /^https?://openuserjs\\.org(?::\\d{1,5})?/scripts//
//@include /^http://localhost(?::\\d{1,5})?/scripts//
... which isn't working... Fx via your extension is still parsing it... which is incorrect spec for all .user.js engines including GM, GM Port, and TM. As I mentioned before your extension should probably parse the UserScript metadata block first then send it off to the Fx API. You'll encounter a lot of resistance from the diverse community on this one with people saying they won't do one engine or the other. Once I completely removed the lines then it injected.
NOTE Second retest... continues to FAIL
ALL Unicode text and not icons per se. Their quality is not as great as proper icon but then the are scalable
Nice tip... Ctrl + + here I come! :smile_cat:
You should have seen a red cross next to the script name to show
The X yes... I consider a cross to be ✝ but I'll add a mental note that you mean 🞮
... and there is a notification when clicking to show the script in the editor.
Seem to be missing this part.
Related to the editor at one point during the removal of the space between // @include
and //@include
lost the line numbers too... rendering issue... Leaving focus of Fx reshows the numbers and re-increments them. Very unusual bug. Even went past the left margin (several characters before it).
Firefox has postponed the official release of the new API to 68
Surprise, surprise :smile_cat:
and added for extra context only
Syncing up with my terminology... list filters ... would never have guessed that even with reading the Help. :smile_cat: With all of the reports rolling in of one .user.js engine deleting scripts on import/export (and a very casual look without testing to confirm) I'm a bit leery to just go poking around these days in a "dirty" profile that I should back up more often.
Script injection test nth test:
// ==UserScript==
// @name oujs - Meta View
// @namespace https://openuserjs.org/users/Marti
// @description Adds a script navigation link next to `Source Code` titled `Meta` and opens a phantom url to show the detected metadata
// @copyright 2014+, Marti Martz (https://openuserjs.org/users/Marti)
// @license CC-BY-NC-SA-4.0; https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode
// @license GPL-3.0-or-later; http://www.gnu.org/licenses/gpl-3.0.txt
// @version 4.4.5
// @icon https://www.gravatar.com/avatar/7ff58eb098c23feafa72e0b4cd13f396?r=G&s=48&default=identicon
// @homepageURL https://github.com/Martii/UserScripts/tree/master/src/oujs/Meta%20View
// @homepageURL https://openuserjs.org/scripts/marti/oujs_-_Meta_View
// @supportURL https://openuserjs.org/scripts/marti/oujs_-_Meta_View/issues
// @updateURL https://openuserjs.org/meta/Marti/oujs_-_Meta_View.meta.js
// @downloadURL https://openuserjs.org/install/Marti/oujs_-_Meta_View.min.user.js
// @include https://openuserjs.org/scripts/*/*
// @include http://localhost:8080/scripts/*/*
var x = 10; // *** This breaks script injection and should not ***
// @grant none
// ==/UserScript==
... result FAIL
NOTE Retested... 2nd time... PASS ... bleh... inconsistent results... probably why it's deferred to a later Fx release.
Btw Install button on OUJS still no workie.
New Script "button" with one script already in there copies the source of oujs - Meta View? A little unusual.
space between // @include and //@include It doesn't matter to FireMoneky as it doesn't even look for
// .....
it looks for@.....
Please note that Regular Expression includes are not supported by the API eg: /^https?://openuserjs\\.org(?::\\d{1,5})?/scripts//
On the option page, when clicking on the script with X after it, it display the script and then.. it has a notification popup with the error plus the the edit area changes colour to show error
After removing the RegEx include and enabling the script, the script runs but I dont know what it is supposed to do.
On https://openuserjs.org/scripts/Marti/oujs_-_Meta_View
it runs the else
on line 556
Never get that. Do get the pink background though.
It doesn't matter to FireMonkey as it doesn't even look for
// .....
it looks for@.....
That can be a security risk for starters not to mention a parsing nightmare.... the official spec for metadata blocks are at GM and the original spec of GM Port. Using a proprietary .user.js metadata block is not recommended since it makes it not a .user.js engine. The metadata is critical for parsing and busting that doesn't seem like a wise choice. I would suggest that changes in FireMonkey as it won't be endorsed as a .user.js engine until it does and won't be widely accepted in the community.
Ex.
// ==UserScript==
...
// Let's bury this in a really obnoxious comment and see what can be done.
// So now is the time for all coders to come to the aid of their rights.
// @icon https://www.gravatar.com/avatar/7ff58eb098c23feafa72e0b4cd13f396?r=G&s=48&default=identicon
// This is a regular comment and may show you how you can @require http://example.com/somebadscript.js and your extension will require it based off of the descriptive text explanation.
// Blah, blah, blah, blah... etc.
// Let's mess with the @icon http://example.com/scaryicon.jpg . Example.com's are ficticious but lets role play. Also what happens with @..... if it's not recognized...haven't tested that part yet but will after the security issue of
// another............................................................................................................................................................................................................................................................................................ @require http://example.com/anotherbadscript.js
// is addressed.
// @require http://example.com/goodscript.js
...
// ==/UserScript==
(Note: The ellipsis means there is more. This is just a snippet example)
Anyhow... don't want to seem like I'm tilting towards the negative spectrum. The extension has good promise but need a few standardizations on the basics. :smile:
but I dont know what it is supposed to do.
Parses the metadata blocks that we collect (specifically how GM, GM Port, TM, VM, etc. do it)... click on "Meta" on the nav bar.
Ref:
// @match
es now even though it's not Goo standard... this was a major breaking change too from the official spec.Never get that.
You should get it every time you click on the script with X on the left-side menu to display that script.
That can be a security risk for starters not to mention a parsing nightmare....
I beg to differ. The processing is quite different and are there safeguards. AFA this instance is concerned, it suffices to say that the space after //
has no bearing.
Even the naming of .user.js
is irrelevant to FireMoneky (at the moment) as it does NOT import scripts the same way as GM (by opening via internet or drag/drop). The import is manual and by user consent.
If a programmer chooses to insert comment that mimics meta-block inside the meta-block, that displays the poor choice of the script writer. Similarly, bad code writing displays the poor choice of the script writer. There is no way for the non-programmer-users to check the code for poor implementation. IMHO, Such scripts should be avoided.
The meta-block is not the place to have comments. That is simply poor and improper practice.
The extension has good promise but need a few standardizations on the basics.
While GM, TM & VM are similar, there are implementation differences that causes some scripts to behave differently (some of these are mentioned in the Help). While adhering to good standards is an improvement, adhering to no-so-good standards are not. Some standards are created by the length of time they have been in use and not by their own merit. ;)
Initially, I created FireMoneky for my own use as I wanted an alternative to the available user JS & CSS managers. I have released it for public use in the hope that some users might find it useful as an alternative, and not in competition with the established extensions.
It goes without saying that upon feedback from the users, FireMonkey will be further improved in future. :)
OpenUserJS/OpenUserJS.org#1330 How GM4 skips over bad/unsupported // @matches now even though it's not Goo standard... this was a major breaking change too from the official spec.
FireMonkey converts some common incompatible patterns automatically. It is not possible to check or convert all such instances. In case of bad-matches, the script does not run and is automatically disabled and a warning is added to the script (as mentioned above). Such scripts are still imparted but do not run until the issue is fixed and then the script is then enabled.
If a programmer chooses to insert comment that mimics meta-block inside the meta-block, that displays the poor choice of the script writer. ... The meta-block is not the place to have comments.
Actually it's excellent, and educated, coding to comment what things are when the url may be abstracted by a QSP/hash/etc. just as line breaks are. Again your opinion however not the communities.
Some standards are created by the length of time
I think that is where this extension fails because you haven't taken the time to consider the security ramifications of poor implementation of the UserScript metadata block. Perhaps you should reevaluate the lack of integrity of this decision?
Even the naming of .user.js is irrelevant to FireMoneky
Much like early Opera used to do... so not a new concept.
it does NOT import scripts the same way as GM (by opening via internet or drag/drop). The import is manual and by user consent.
Again much like early Opera. And you finally answered the lingering observation, implied, question of why it doesn't work with OUJS Install button. Thank you.
It goes without saying that upon feedback from the users, FireMonkey will be further improved in future.
Some people like the chaos theory better. As an individual who has been a systems administrator, engineer, and analyst most of my life I beg to contradict that persona. Clearly you want to open a security hole for the bad actors out there with your non-standardized implementation of the metadata block? Seems like a poor choice if so. Apologies but this is how it looks.
The processing is quite different and are there safeguards.
Saying this and proving it are different animals. I'll reinspect the code for these "safeguards" however if we, as OUJS A.M. and CoOwner, see anything remotely resembling a script that contains your security breach we'll probably have to ban it and quite possibly the Author. I'll have to notify AMO to reinspect your addon as well for this as it's quite easy to obfuscate (and is obfuscation in itself) what is happening buried in a comment after further investigation. I wish you would change your mind and work as a team player on this instead of just what you think is "right your way". The community has a lot of experience should you decide to learn from it. GM was taken off AMO in the early days if you recall (or maybe not... depends on your tenure) for security hacks such as these. Don't let this be a similar repeat... most recently Stylus.
I created FireMoneky for my own use as I wanted an alternative to the available user JS & CSS managers.
Alternatives can be good as long as they are safe. Not following the standards is unsafe and you'll jeopardize the community security.
Initially, I created FireMoneky for my own use as I wanted an alternative to the available user JS & CSS managers.
Perhaps. I've followed you for quite some time even before the visit on my fork so I perceive a little different motivation but I'm also not you... so there is the benefit of the doubt clause. :smile_cat:
and not in competition with the established extensions.
No one, including myself, has stated this. However maturity should come in taking constructive feedback especially when a CERT can be issued against bad extensions. This is part of the reason why Mozilla is changing a lot of the innards to prevent bad acting. Please don't contribute to the destruction of your extension as I said it has promise. Make the wiser choice. Since I'm the primary author/maintainer of GM Port I have no concern about competition or not. In fact I encouraged OUJS to not compete with any other .user.js site and the same goes with GM Port. I gracefully filled a browser deficit with SM so did sizzle from USO. It's not a race to have one sect win. That is immature assumptions and behavior which I do not practice. However improvement is always a goal one step at a time.
FireMonkey converts some common incompatible patterns automatically.
Interesting. Won't go into that one as you are correct there are a lot of variations and also legal implications.
Anyhow... I'll go ahead and close this as you've answered most of the basic questions and improved my understanding of your implementation.
Thanks for the clarifications and understanding.
// ==UserScript==
...
// Let's bury this in a really obnoxious comment and see what can be done.
// So now is the time for all coders to come to the aid of their rights.
// @icon https://www.gravatar.com/avatar/7ff58eb098c23feafa72e0b4cd13f396?r=G&s=48&default=identicon
// This is a regular comment and may show you how you can @require http://example.com/somebadscript.js and your extension will require it based off of the descriptive text explanation.
// Blah, blah, blah, blah... etc.
// Let's mess with the @icon http://example.com/scaryicon.jpg . Example.com's are ficticious but lets role play. Also what happens with @..... if it's not recognized...haven't tested that part yet but will after the security issue of
// another............................................................................................................................................................................................................................................................................................ @require http://example.com/anotherbadscript.js
// is addressed.
// @require http://example.com/goodscript.js
...
// ==/UserScript==
Just a note ....
Besides that fact that @require
& @icon
are not implemented in FireMonkey, the result is for example a match is made in FireMoneky but not in GM
Example:
// ==UserScript==
...
// Let's bury this in a really obnoxious comment and see what can be done.
// Blah, blah, blah @match http://example2.com/*
// ................
// is addressed.
// @match http://example.com/*
...
GM treat this as 1 match and FireMonkey as 2 matches (and they are clearly displayed in the script Info for the user) which is the same as:
// ==UserScript==
...
// Let's bury this in a really obnoxious comment and see what can be done.
// Blah, blah, blah
// ................
// is addressed.
// @match http://example.com/*
// @match http://example2.com/*
...
Again that is up to users to chose a script and script writer that doesn't attempt to deceive.
Furthermore, in this case, scripts may run on unexpected sites (but there is Info) but so does the result of the wildcard implementation in GM etc i.e. @match *://*.example.*/*
which runs on all sorts of unexpected and uninformed sites.
HOWEVER, I will think about ways to prevent the above situation.
Also, FireMonkey supports block metablock which others dont e.g.:
/*
....
@match http://example.com/*
....
*/
AFA standards, the standard has never been to include comments in meta-block.
Finally, as per addon's description:
Firemonkey is a totally new extension that can handle both user Scripts and user CSS. While it has similar functions to user script extensions like GreaseMonkey/Tampermonkey/Violentmonkey, and user CSS extensions like Stylish/Stylus, there are differences.
In other words, FireMonkey is not GM or VM or TM and does not aim to be a clone of them either. Therefore, comparison and/or full 100% compatibility is not the criteria.
The included Help explains how FireMonkey works.
Besides that fact that
@require
&@icon
are not implemented in FireMonkey
Those were chosen at random. Pick @name
if you wish, or any other key you support, and apply it.
and they are clearly displayed in the script Info for the user
After the fact... not before. Not everyone knows (or sometimes cares) what kind of security issues are present. The responsible thing to do is to educate and put in some basic safeguards. Some put in more than is needed imho (think the other .user.js site) but that is his prerogative within his means.
Again that is up to users to chose a script and script writer that doesn't attempt to deceive.
Might just be a casual comment too describing something which is why the fully documented standard exists and your extension will pick it up incorrectly. You can even have code in between // @key
s for example in the UserScript metadata block. Yes I see your consideration edit too.
but so does the result of the wildcard implementation in GM
Well aware of this one. I've banned several UserScripts for being too vague on injection. Some are useful on all sites too. TM/GM Port also has this feature. Been a while since I've tested VM but I think it does too.
AFA standards, the standard has never been to include comments in meta-block.
That's never been the case. Comments and other code have always been accepted on different lines in the UserScript metadata block. E4X is another example that proves it and so are function expressions and the like for restructuring. This goes back to the origin with Aaron which I'm a later addition to that origin. One can even encompass the entire script in the UserScript metadata block if bored. Granted it looks ick but that's one of the reason why oujs - Meta View was created... in case it's so terribly (imho) abstracted/obfuscated for even newer technologies and methodologies. I ran into one that mirrors node syntax in UserScripts... that threw me for a loop until I asked the Author what was going on... he helped me understand and I helped that Author out too with the build routine to not violate Copyright.
Also, FireMonkey supports block metablock which others dont
Interesting... that is another parsing nightmare (not yours necessarily... but everyone else who may consider implementing and hosting your new type).
Therefore, comparison and/or full 100% compatibility is not the criteria.
You actively sought out for my feedback... there it is. Even if I had no knowledge of UserScripts I'd still come to these same security concerns of accidental or intentional script injection or alteration.
If you want to try to make a spin-off like JetPack used to be you are always welcome to. :) Perhaps it will catch on... perhaps not. You know my 2 cents on this particular security issue. I do like less extensions but at the same time not at the expense of my default understanding of security and privacy.
Thank you for the feedback which will be taken into consideration.
Just to let you know, I have updated the code to prevent the unwanted processing of
// Blah, blah, blah @match http://example2.com/*
It will be in v1.6
Apologies for not getting here sooner... haven't had much free time to twiddle. Also had to wait until the Fx version was beyond your
em:version
(don't do beta and earliers now).Some data for you:
As the A.M. of OUJS we don't have any such policy yet that I know of... assume CORS and/or the like? or something internal to the extension?
OUJS test script (ref'd below) ... Install button did nothing for interception by FireMonkey... so manually created a new script... pasted in content... This console error may be relevant:
Export of preferences:
Went to see if the editor had any settings I missed first quick glance... check box for "Enabled" said it was unticked. Ticked it... reloaded web page... new tab load... both not injecting.
Do see your JSON
error
on the regular expression includes... should skip over those if your extension doesn't support them... perhaps the main issue.Bottom line... doesn't seem to inject .user.js yet I think in this use case.
Have not tested UserCSS yet. Scripts are more important to me. :)
Interface is snappy (very nice)... perhaps needs more tooltips eventually under "Script & CSS" panel/sidebar so I know what they do without blindly clicking and seeing what explodes/works. ;) Those icons could use a little larger for high DPI screens... mines not and I have to look pretty close to my monitor just to see what they are. Duplicate, I think of scripts and css with respective checkbox for example is something I can't immediately figure out with more in-depth testing.
Anyhow... looking forward to updates to test and any feedback you want me to try. I don't have a whole lot of time to examine in-depth WebExtensions since the site keeps me very busy... but I'll try to try. :smile_cat:
System:
Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
... profile "dirty" e.g. well used\/laundry list (hope you don't mind this for a start)