Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

greasemonkey 4.1 #329

Closed
ghost opened this issue Jan 5, 2018 · 12 comments
Closed

greasemonkey 4.1 #329

ghost opened this issue Jan 5, 2018 · 12 comments

Comments

@ghost
Copy link

ghost commented Jan 5, 2018

I noticed that the wiki says the new greasemonkey is not ready yet, but I installed it just fine and seems to be working well now

@Thorin-Oakenpants
Copy link
Contributor

Thorin-Oakenpants commented Jan 5, 2018

I've kind of kept an eye on it, but I am super happy with ViolentMonkey myself - so no incentive for me to follow up on GM (but I have). Last version was 25 or so days ago, last commit in github was over a month ago (besides a version bump to 4.1). Reviews on AMO aren't all that great since then (a lot of lost scripts, no saving of edits, broken scripts etc - but on that side it could be IDB issues or lack of user knowledge). Issues still open include no ability to SAVE in editor.

Granted, I am not using it. I'm also not fully knowledgeable about the change that breaks a lot of scripts. I'd need to re-find that "change" and see if it applies to VM (I think it does) but it does not seem to apply to TamperMonkey IIRC (but I do not want to recommend TM).

I'm also kinda loath to recommend two items that do the same thing and AFAIC VM is superior. Leaving open so I can chase down this deprecated GM setting thingie

@ghost
Copy link
Author

ghost commented Jan 5, 2018

Thank'you for the thorough answer! I wasn't familiar with either and chosed GM due to the amount of stars on github, so it's really appreciated, I'll use violentmonkey too.

@Thorin-Oakenpants
Copy link
Contributor

no worries. I think I'll close this. Maybe someone can revisit GM in a few months, but if you look at the issues on github, it has a lot to work yet to be done - VM in my opinion is polished

@Thorin-Oakenpants
Copy link
Contributor

aaaaand .. 21 commits just done - https://github.com/greasemonkey/greasemonkey/commits/master including added the save button :)

@ghost
Copy link

ghost commented Feb 7, 2019

@Thorin-Oakenpants

The main reason I was looking Greasemonkey was because of the discussion here about the usage policy of VM.

What are your thoughts on that? Discussion that initiated that is https://github.com/privacytoolsIO/privacytools.io/issues/121#issuecomment-458088832

@KOLANICH
Copy link

KOLANICH commented Feb 7, 2019

The real problem with VM is that ... it doesn't work (at least on devedition).

@Thorin-Oakenpants
Copy link
Contributor

@tya99 from your first link and some subsequent posts (I think you linked to the wrong comment and you meant the one two posts further down)

FYI to back up your argument with SCIENCE!!: When multiple extensions (e.g. uBO, uMatrix, NoScript) use CSP header injection/modification, only one wins. Predicting the winner is like rolling a dice - read this comment

I do think that page [ghacks extensions wiki] might be outdated

Err WOT? Nope, I have kept it pretty much spot on since day one. What is "outdated" on it?

It would appear currently I wasn't protecting against cache

FYI: the lucible test is slightly dodgy (it uses your IP as well), as long as the page never says more than 2 visits, then the etag blocking is working, just keep refreshing and adding data and refreshing. Although it can easily be seen that it's working in the network inspector.

It appears for many of those APIs they do exist now

Read what I said: I'll bold some bits for you: "APIs do not exist to allow clearing IndexedDB, Service Workers cache, appCache, or cache by host" which is correct.

I'll talk about VM in the next post

@Thorin-Oakenpants
Copy link
Contributor

I do not see any issue with the privacy policy in VM: https://violentmonkey.github.io/privacy/

Have you ever given them any PII? No, because they have never asked for it. So there's nothing to share.

That said, you do have a UUID but that is not used AFAIK - e.g sending it when you import something from greasyfork or whatever - the code is all open source and if it was doing this there would be a shitstorm

I fail to see what the problem is. Also, just quietly, I only use VM for two scripts, which we wrote/collected - so I never have any end point to connect to to update them - but not everyone is like that.

Also, GM just gave me the shits - so slow to move to web extension, so many issues, and it doesn't even work with document at run start, STILL .. and I honestly can't be bothered with them anymore.

Feel free to open a new issue on the merits of GM vs VM, rather than use this old one

@ghost
Copy link

ghost commented Feb 7, 2019

@tya99 from your first link and some subsequent posts (I think you linked to the wrong comment and you meant the one two posts further down)

Ah yeah, you're right, I meant to link https://github.com/privacytoolsIO/privacytools.io/issues/121#issuecomment-461203115 derp.

FYI to back up your argument with SCIENCE!!: When multiple extensions (e.g. uBO, uMatrix, NoScript) use CSP header injection/modification, only one wins. Predicting the winner is like rolling a dice - read this comment

In regard to that I have only been using privacy.resistFingerprinting = true which sets the uniqueness to "uniqueness is "× False (Tor Browser signature)". I don't have any need to use Canvas, hence I haven't yet installed CanvasBlocker. I see CanvasBlocker mentioned regularly and was still wondering if that was "best practice" or something like that.

I do not have NoScript installed, and I have not got "Block CSP reports" in uBlock checked. In uMatrix disableCSPReportInjection is false. I shouldn't have to worry about the rolling the dice thing? As far as I know none of my other addons touch that stuff.

I do think that page [ghacks extensions wiki] might be outdated

Err WOT? Nope, I have kept it pretty much spot on since day one. What is "outdated" on it?

Not I said might (I was looking for clarification as I wasn't sure). I would have thought you wouldn't have wanted to recommend Violent Monkey if any of the stuff in this discussion thread was true.

FYI: the lucible test is slightly dodgy (it uses your IP as well), as long as the page never says more than 2 visits, then the etag blocking is working, just keep refreshing and adding data and refreshing. Although it can easily be seen that it's working in the network inspector.

I did wonder about that. Because I swear I got the same result even with a different container. The only way that could be the same is if it matched via IP. Have you got a better test you prefer for that?

Read what I said: I'll bold some bits for you: "APIs do not exist to allow clearing IndexedDB, Service Workers cache, appCache, or cache by host" which is correct.

Right. I decided to go down the road of using Temporary Containers a pity that does not work on Android. For that matter CookieAutodelete looks like it is missing certain APIs there too. Ie:

Also, thanks for the terrific work on ghacks-user.js. I like to avoid installing addons if I can help it, as that is more people I have to trust. If you did spot any in my comments I would be curious to know:

I do not see any issue with the privacy policy in VM: https://violentmonkey.github.io/privacy/

Well it says it right there:

We may employ third party companies and individuals to facilitate our Service, to provide the Service on our behalf, to perform Service-related services or to assist us in analyzing how our Service is used.

These third parties have access to your Personal Information only to perform these tasks on our behalf and are obligated not to disclose or use it for any other purpose.

It seems a bit strange. They also say:

Currently we do not collect any of your personal data.

Why would they want to warn me they might collect it, but then don't currently? Is it so they can in the future and then just say "oh we told you so years ago..." just seems a bit odd.

If you look at this reply there's another issue:

Unfortunately, that's pretty difficult, since they have obfuscated the code of the addon uploaded to AMO.

It is very difficult to audit. It certainly seems they have obfuscated the code in release (I checked). This makes it difficult for me to check that the copy on AMO is actually the same as the source on github.

All new line characters have been removed out of release and all variables are single characters. I can't say I'm happy about this and would make me feel uneasy to use it to say the least. There's a good reason why I don't use or recommend Tamper Monkey. Only the old ancient version is open source.

On the other hand Greasemonkey doesn't do anything like this.

@Thorin-Oakenpants
Copy link
Contributor

In regard to that (rolling the dice)

That was just FYI to back up what you said about using NS and uBO/uMatrix or whatever. It's not just about CanvasBlocker (which also has one setting that uses CSP injection), it's about ALL extensions that use it in various things they do. For example, uBO uses it in rules to block fonts (I am not usre about filters), and that can affect uMatrix doing the same to block workers.

I have only been using privacy.resistFingerprinting = true which sets the uniqueness to "uniqueness is "× False (Tor Browser signature)"

As long as return a 10x10 white canvas (by using RFP, which is what we use instead of typing privacy.resistFingerprinting all the time), then you are fine. This is the same as Tor Browser, since that uses the same code from Firefox. IF you need to let a site use canvas for some reason, then CB (CanvasBlocker) can use a fake value - see #350 first post.

Personally, I am not using CanvasBlocker - but do note that it has some new protections: namely Audio and DomRect - however, I have audio API disabled, so that's covered. And I'm waiting for RFP to handle DomRect

Have you got a better test you prefer for that (etags)

You can see it in the network inspector. see this #179 (comment) .. what anyone solving this should do is remove the response etag because that prevents the browser from storing the etag, which in turn prevents it from sending the if-none-match header in the future

VM privacy policy

They do not collect any PII. I've never given them my name or email or anything. So how can any 3rd parties access my PII?

It seems a bit strange. They also say ... just seems a bit odd.

Not at all. It's standard boilerplate. The point is they do not collect anything.

It is very difficult to audit. It certainly seems they have obfuscated the code in release

Source code is not obfuscated because they are hiding anything - there are other reasons for doing so. Lots of extensions do this. The code actually has to be submitted to AMO un-obfuscated for machine and human review, but may be squeezed up / condensed after that.

The source code is not obfuscated on github - assuming that the submitted code to AMO wasn't changed. So hard to compare - I understand that.

Here's the point. It's used by LOTS of people. People do check to see what is happened e.g wireshark. The dev has never done anything shady. The dev has stated nothing is collected. The dev is unlikely to do anything shady given possible backlash (although some do, e.g Stylish on Chrome was a shit show - and easily found out by end users).

The other thing is, his privacy policy could be "We do not collect anything" and that's it, in it's entirety - that's doesn't actually MAKE IT TRUE. Lots of companies lie in their Privacy Policies.

But lets assume the dev is super honest. As soon as he makes a change to collect some PII, then he would edit his privacy policy.

So what exactly is the difference between all this - NONE. Either you trust the dev and the extension or go find something else. I for one trust the VM team

@ghost
Copy link

ghost commented Feb 7, 2019

In regard to that (rolling the dice)

That was just FYI to back up what you said about using NS and uBO/uMatrix or whatever. It's not just about CanvasBlocker (which also has one setting that uses CSP injection), it's about ALL extensions that use it in various things they do. For example, uBO uses it in rules to block fonts (I am not usre about filters), and that can affect uMatrix doing the same to block workers.

I have only been using privacy.resistFingerprinting = true which sets the uniqueness to "uniqueness is "× False (Tor Browser signature)"

As long as return a 10x10 white canvas (by using RFP, which is what we use instead of typing privacy.resistFingerprinting all the time), then you are fine. This is the same as Tor Browser, since that uses the same code from Firefox. IF you need to let a site use canvas for some reason, then CB (CanvasBlocker) can use a fake value - see #350 first post.

Personally, I am not using CanvasBlocker - but do note that it has some new protections: namely Audio and DomRect - however, I have audio API disabled, so that's covered. And I'm waiting for RFP to handle DomRect

Yeah this seems to be the case. I noticed with privacy.resistFingerprinting it's a 166 byte file with 1 color. It seems to be CanvasBlocker randomizes it. I have never actually used a site that has used the canvas for legitiate functionality.

I guess it wouldn't hurt for me to switch dom.webaudio.enabled off. I don't think I ever have used that either.

If there's no RFP to handle DOMRect and you don't use CanvasBlocker how do you disable it?

Have you got a better test you prefer for that (etags)

You can see it in the network inspector. see this #179 (comment) .. what anyone solving this should do is remove the response etag because that prevents the browser from storing the etag, which in turn prevents it from sending the if-none-match header in the future

I played around with that. Maybe we should add ETag Stoppa to privacytools.io. I've never actually needed ETags for some legitimate purpose either.

It is very difficult to audit. It certainly seems they have obfuscated the code in release

Source code is not obfuscated because they are hiding anything - there are other reasons for doing so. Lots of extensions do this. The code actually has to be submitted to AMO un-obfuscated for machine and human review, but may be squeezed up / condensed after that.

I guess it could be for some sort of performance reasons. I wouldn't have thought it would have made that much difference

The source code is not obfuscated on github - assuming that the submitted code to AMO wasn't changed. So hard to compare - I understand that.

Here's the point. It's used by LOTS of people. People do check to see what is happened e.g wireshark. The dev has never done anything shady. The dev has stated nothing is collected. The dev is unlikely to do anything shady given possible backlash (although some do, e.g Stylish on Chrome was a shit show - and easily found out by end users).

I guess that's true. I haven't really had a reason to switch from Greasemonkey.

The other thing is, his privacy policy could be "We do not collect anything" and that's it, in it's entirety - that's doesn't actually MAKE IT TRUE. Lots of companies lie in their Privacy Policies.

Some track you more when you ask not to be: like this example.

@Thorin-Oakenpants
Copy link
Contributor

If there's no RFP to handle DOMRect and you don't use CanvasBlocker how do you disable it?

Like almost every other FP'ing .. I control what JS runs and who I connect to. Anyway, I doubt DomRect FP'ing is used in the wild, there is so much more lower hanging fruit

@ghost ghost mentioned this issue Feb 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants