Firefox Gets Fix For Evil Cursor Attack (zdnet.com) 29
Firefox has fixed a bug that was being exploited in the wild by tech support scammers to create artificial mouse cursors and prevent users from easily leaving malicious sites. From a report: The bug was discovered being abused online by UK cyber-security firm Sophos and reported to Mozilla earlier this year. A bugfix was provided and has been live in Firefox since version 79.0, released last week. he bug is a classic "evil cursor" attack and works because modern browsers allow site owners to modify how the mouse cursor looks while users are navigating their websites. This type of customization might look useless, but it's often used for browser-based games, browser augmented reality, or browser virtual reality experiences. However, custom cursors have been a major problem for the regular web. In evil cursor attacks, malicious websites tamper with cursor settings in order to modify where the actual cursor is visible on screen, and where the actual click area is.
Why are browser features opt-out, not opt-in? (Score:1)
I don't understand why almost every browser feature is automatically available to any website one browses to. Or that advertising and tracking javascript loads in the background.
The list of first-party websites that I'd want to have access to advanced features (and their increased attack surface) is limited to a few that I visit regularly, log into, or otherwise would be happy to whitelist.
Re: (Score:3)
I don't understand why almost every browser feature is automatically available to any website one browses to. Or that advertising and tracking javascript loads in the background.
The list of first-party websites that I'd want to have access to advanced features (and their increased attack surface) is limited to a few that I visit regularly, log into, or otherwise would be happy to whitelist.
You seem to be under the impression that the browser was written for you, the user, rather than the people that wish to exploit the users.
Re: Why are browser features opt-out, not opt-in? (Score:2)
Re: (Score:2)
You seem to be under the impression that the browser was written for you, the user, rather than the people that wish to exploit the users.
Seriously stop being a fuckwit.
You have absolutely zero evidence that Firefox is written for the people that wish to exploit the users. For any X the reason they do X is because without it they risk haemorrhaging even more users to the one backed and pushed by the world's largest advertiser.
Don't want javascript? then install noscript. It's not complicated.
Re: (Score:2)
Except for the well known modal alert() loop known well back in ~1995, the free reign Javascript got over some browser features (e.g.resizing windows), where an infinite loop in the code can lock a browser window (still). Or for a very long time, allowing plugins to auto-run whatever the browser thought was a good idea. With all the security flaws, it was designed like that by accident.
At most, there's ze
Re: (Score:2)
Re:Why are browser features opt-out, not opt-in? (Score:4, Insightful)
Oh, I just realized I never directly answered your question. Every browser feature is turned on because a lot of the things we think of as features are built on top of very basic functionality. Which, if turned off, will break A LOT of things. Like, in all actuality, (if you take things like CORS out of the equation, which is only good if it's implemented everywhere and currently isn't. Not really.) all you need to track a person on multiple sites is a javascript snippet on a page that says "Send the url of the page they're currently on to my tracking server". And if that snippet is everywhere, like say, an ad or something more invisible, and that ad or something is almost everywhere because they have a near monopoly *cough* *google* *cough*, then you have tracking to virtually the entire internet. But, at the same time, if you turn off the ability for javascript to call other pages or api's or servers for info or requests or to pull info or whatever, pretty much 70~90% of all reactive pages will break down. Things like async loading in a page won't work which means the entire page's content has to be generated from a single request. Which, supposedly, will slow down rendering time (despite the fact that people use to scream that users see parts of the page loading is bad and a bad user experience and the solution is faster internet. Now we have faster internet and people are like "async loading is the future, it makes page loading faster.").
So yeah, the way it's currently built, you can't just "turn off advertising and tracking javascript" because there's no single function called "tracking and advertising" that can be turned off. If you're thinking "Then why don't they give us the option to turn off things like AJAX? I don't mind those other stuff being broken." Honestly, I wonder that as well. For now, the best we have is turn off javascript entirely in the browser. If you ever make a petition for the mozilla foundation and/or chrome to give us the ability to turn off specific parts the the javascript web API, I'll be the first to sign it.
Re: Why are browser features opt-out, not opt-in? (Score:1)
Re: (Score:1)
Re: (Score:2)
>"If you ever make a petition for the mozilla foundation and/or chrome to give us the ability to turn off specific parts the the javascript web API, I'll be the first to sign it."
Me too, especially if it is anything that allows sites to animate. I have been saying for years we at least need control over timers that do things to animate, pop up crap, or monitor the user in tight loops. I am not sure how that would work, though.
Re: (Score:2)
I have been saying for years we at least need control over timers that do things to animate, pop up crap, or monitor the user in tight loops.
Agreed.
Let's assume for a moment that a browser institutes controls that manage to block all forms of animation seen in this test suite [pineight.com]. What would a site need to do to convince a reasonable user to choose "allow this site to animate"? Or is it reasonable to expect the user of, say, a chat site to have to click "check for new messages sent to the channel" every 10 seconds?
Re: (Score:2)
>"What would a site need to do to convince a reasonable user to choose "allow this site to animate"? Or is it reasonable to expect the user of, say, a chat site to have to click "check for new messages sent to the channel" every 10 seconds?"
That is a good question. I suppose it could be a permission of some sort that would have to be given by the user.
"This site requests auto-refresh/update every 10 seconds. Allow?"
And it could remember that site permission. Of course, a site developer could retaliate
Re: (Score:2)
I suppose it could be a permission of some sort that would have to be given by the user.
My question was about how to effectively communicate to both novice users and privacy-paranoid users that a particular application has a good faith need for a permission in order to be usable and won't abuse it.
Same thing with ad blockers, ad blocker detectors, ad blocker detector circumvention, etc.
This article [blockadblock.com] implies that the "etc." includes legal action. Its author claims that an ad blocker detector constitutes access control pursuant to national anti-circumvention statutes that implement the WIPO Copyright Treaty 1996, such as 17 USC 1201, and recommends suing the publishers of ad blocker
Re: (Score:1)
My question was about how to effectively communicate to both novice users and privacy-paranoid users that a particular application has a good faith need for a permission in order to be usable and won't abuse it.
Honestly, my approach is that you don't. That's a problem, imo, that's been plaguing anti-virus software writers and network admins for decades and I'm definitely not better than they are. The other part is that what's good faith for someone may not be beneficial for you. My personal approach is, rather than figure that out for the user, let the user decide what they want. Don't enforce anything on the user, give them the granularity control. Empower them and let them decide.
This article [blockadblock.com] implies that the "etc." includes legal action. Its author claims that an ad blocker detector constitutes access control pursuant to national anti-circumvention statutes that implement the WIPO Copyright Treaty 1996, such as 17 USC 1201, and recommends suing the publishers of ad blocker detector circumvention software for violating these laws.
Except there is no law and no en
Re: (Score:2)
>"My question was about how to effectively communicate to both novice users and privacy-paranoid users that a particular application has a good faith need for a permission in order to be usable and won't abuse it"
I am not sure how I can answer that. Trust is in the eye of the beholder. It is usually something that is earned, or something given based on past experience. About the only thing you could do is to provide full-disclosure information about what you want to do and why. Of course, that doesn'
Re: (Score:1)
Re: (Score:2)
Or you could use uMatrix [github.com]
Re: (Score:1)
Re: (Score:2)
I think NoScript does what you're talking about, but it does it at the site/domain level rather than the function level.
I think it's possible to do function blocking in NoScript, but my regex-fu isn't good enough to have ever made it work.
uBlock Origin also does element blocking using a more intuitive interface, but I'm not sure it does it to the extent or with the ease you're suggesting.
I'll be very interested to see what you come up with.
Re: (Score:1)
Re: Why are browser features opt-out, not opt-in? (Score:1)
Re: (Score:2)
The problem is that neither browsers nor web servers are RFC3514 compliant. It makes it difficult to prevent abuse of useful features.
The next attempt was to implement that feature into the HTTP protocol but it was too limited, only targeting trackers and not evilness in general. Also didn't work.
Re: (Score:2)
I don't understand why almost every browser feature is automatically available to any website one browses to.
Because some of us want to visit websites without the desire to micromanage our experience. There's nothing worse for a user than:
1. Visit website which requires functionality.
2. Are you sure you want website to be able to.... Yes.
3. Are you okay with storing cookies? Yes.
4. Do you agree to our privac... OMG FUCKING YES. JUST GET ON WITH IT.
5. Click button.
6. Click button in frustration.
7. FUCK disable no script white list the site.
8. Click reload.
9. Are you sure you want the website to be able to... You kn
JavaScript problem (Score:1)
This is not a browser problem. It is a JavaScript problem. The solution is simple -- disable JavaScript.
Re: JavaScript problem (Score:2)
Re: (Score:2)
Except recent Firefoxes have developed a very bad habit. If there's a firefox update, they will regularly disable NoScript until you apply the update.
Yes, if you use NoScript and Firefox needs updating, NoScript gets disabled silently. You can always go to Addons - Extensions and disable/re-enable NoScript to get it working again, but in a day, it will disable itself again. You don't get any warning, jus
Re: (Score:2)
>"Only to do it again the next day. This continues until you update Firefox. Then it stays enabled again."
Interesting.
Have you tried disabling updates to see if that helps? [Under Linux, at least] in the install directory, create a "distribution" directory with a file named policies.json and that will contain:
{
"policies": {
"DisableAppUpdate": true
}
}
Unfortunately, you will have to copy that directory over to any new install every time you manually update