@mac29 There are a lot of browsers, extensions, and accessories (VPNs, proxies, etc) that may claim to increase browsing anonymity, with actual results that may or may not really improve one's situation to some degree, depending on what a site is doing with its code technology and from whom one is seeking to protect their anonymity. However, in most cases, there is no perfect answer (even with Tor) that assures 100% anonymity against all types of betrayal of privacy or user tracking.

I've observed that, in trying to 'hide' from a visited website, the most effective techniques also tend to break the websites. One of the strategies used by some sites seeking to ID visitors is simply to deny access if they aren't able to derive legitimate-appearing data from the visitor, and there are various methods for them to test such data-legitimacy. I wish you the best results in your quest, but I have little optimism that any major success you may obtain will last, since websites (and their market affiliates) are constantly seeking new and 'improved' ways to enforce their paywalls and/or their user tracking.

@mac29 A VPN will only block the user's IP from being routed to the destination. Depending on the sophistication of a website's code, there are other elements that can be used by the site to attempt to uniquely identify a visiting browser. As you note, cookes and supercookies can betray a unique browser. However, there are other elements that can be exploited: WebRTC leakage, enabled system/software geolocation, browser service workers, enabled website notifications, user-agent fingerprinting, and a variety of system and browser fingerprinting via website Javascript code. The effectiveness and accuracy of these elements can and do vary, but all have been known to be employed by various sites at times.

My own experience is that the IP, cookies/supercookies, WebRTC leakage, and service workers are the most common trackers used by many sites to limit the number of viewed articles, so they are the best areas to attempt to suppress in the browser. However, there is a constant effort on the part of subscriber-based sites to find creative new ways to limit free visits, particularly using Javascript to play with and exploit browser API's and in seeking ways to plant various kinds of site-related "seed" data bits into browser storage areas.

Usually I've found that if one kills cookies/supercookies, WebRTC, and exterminates service workers before revisiting a site, the site is likely to allow viewing for a brief time until their limit is again exceeded. If those techniques don't work, there's typically not a lot one can do (in practicality) since killing other tracking mechanisms usually involves blocking the site's Javascript - which usually causes the sites to not work at all.

At this point in time, it's way too early to know how this will unfold for various browsers, Opera included. At least in part, that's because the final version of the new chromium API and any 'permanent' changes/deprecation of the old API have not been decided upon. Only then, and based upon that impact to browser coding, will it be possible to determine how the various browsers will be impacted. Those impacts will determine the economics or possibility of various browsers preserving existing ad-blocking capabilities or extension compatibility. Right now, it appears that everyone's at the mercy of how the chromium changes are actually implemented, and that's where the battle is being fought between app and chromium developers.

A fair number of sites already block ad-blocking browsers/extensions. Whether an ad-favoring site sniffs a user agent string for browser type or uses site code to sniff for ad blocking, the result turns out to be essentially the same: up pops a usage-blocking message if ads can be user-blocked. The struggle is really over how websites can recoup their costs of providing their online services/media, and until that is finally settled somehow, this stands as only one more round of tactics.

What is often overlooked by users in seeking a VPN (or similar) for "privacy" are their own personal answers to questions of: what exactly is the user trying to keep private and from whom? Asked another way, what are the real-world consequences of the information-flow "privacy" being betrayed? The answers can range anywhere from a user trying to protect against a spouse somehow knowing what sites and traffic one is viewing all the way to attempting to hide from national censors/snoopers while seeking "prohibited" information (or even covertly communicating with an enemy faction). Hence the consequences of "losing privacy" may range from 'embarrassment' up to a prison term (or even execution).

Given that the use of a VPN (even including Opera's 'VPN' proxy) always necessarily reveals the IP of the initial-contact VPN server, since that must be openly affixed to the packet headers to route the traffic up to the server, a foundational privacy limitation of all VPNs is that the communication leg from the user's system through the ISP server on to the VPN server will always betray to a snooper that a VPN is being contacted by the user, regardless of the depth or success of any other traffic analysis of the packet contents. A competent traffic analyst will have access to a fairly up-to-date index list of virtually all the commercial VPN server IPs in use. In some scenarios and locales, merely using a VPN is sufficient for sanctions upon the user, or at least placing them on a "watch" list for more intensive scrutiny.

My counsel to anyone considering a VPN is to first answer the critical question of whether it seriously/legally matters to their local authorities whether or not they are even using a VPN, since such usage will easily be apparent to any snooping that exists there. This is usually a national/politically-driven issue, so the answer depends on the locale's "rules" and sanctions and the related risks a user is willing to run for whatever purposes. Beyond that, the Golem.de information is spot on regarding real-world VPN limitations to security/privacy.

The changes to the current webRequest API involve replacing/restricting that API with a declarativeNetRequest API which prevents extensions (adblockers, user-agent switchers, anti-phishers, etc) from taking action before page loading occurs. Moreover, it imposes heavy table-size limits on site white/black listings within the extension, forcing more remote look-up actions in screening URLs or content in a loaded page.

Ostensibly this is being done to prevent abuse by rogue extensions and to "improve performance" during page loads, but the claimed performance effect are arguably minimal. Given that Google earns considerable portions of their revenue from ads/marketing, there is a high likelihood that Chrome/chromium developers are being pressured by such interests to reduce the effectiveness of ad blocking in their browser family.

For the technically-interested, part of the discussion/debate between extension developers and Chrome/chromium developers can be observed at https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/veJy9uAwS00 and in its fore-runner thread (now restricted): https://bugs.chromium.org/p/chromium/issues/detail?id=896897.

@wolnumber1 Can you provide some example websites where the problem ads consistently appear? Also, approximately how often or how many websites are you encountering this on? Have you scanned your system for adware/malware?

@rif When I last checked (a few days ago), not a lot has changed in terms of the impact to ad-blocking users from the ManifestV3 API design focus. While some movement/negotiation has occurred based on app developer feedback, it appears in many respects that the Chrome/chromium and app developers are talking past each other. Given that a large part of Google's revenue comes from the ad/marketing industry, I believe this represents a significant factor in the Chrome/chromium development reluctance to change its course regarding the V3 update, which will render a variety of currently-effective ad-blocking tools unusable.

@mrb96 If this is indeed censorship blocking, you might read the first several sections of the year-old article at https://www.addictivetips.com/vpn/iran-vpn/ to get a better idea of what you're facing. However, given the dynamic nature of how censors operate, there's no guarantee the VPN recommendations listed in that article are still effective. The unfortunate reality is that all VPN connections from a user must first contact the IP of the VPN, which leaves a clear blocking target (either directly at IP level or indirectly by DNS-blocking) for the determined censor. A censorship agency can easily figure out all the user-connection IP addresses used by a VPN operator, if only by installing the VPN products and patiently sniffing the resulting packet traffic. In a truly free world, things might be different, but sadly that's not the way it currently is.

@crisalide said in Has Opera Turbo been killed?:

... Opera Turbo, especially for those who have a consumer connection, was an essential function, one of those that should never be touched, so I don't understand the logic behind this decision.

I'm not an Opera employee, but my best guess is it was a business cost decision, perhaps accelerated by the recent Opera ownership change. Turbo was not a strictly browser-code feature as much as it was a proxy-like filter residing on servers operated by Opera (which compressed the data coming back from a visited website - especially images - thereby reducing the data package size going to the user). So two cost-reduction possibilities present themselves: either it was becoming too expensive to maintain the Turbo browser code in light of the continual chromium engine updates or/and it was becoming too expensive (or bandwidth-competitive) to maintain the proxy-like server network. My personal guess is the latter to be more likely contributor.