@hamaki If you can reach the Opera sites only via a VPN (but other websites work OK), then it implies that either the DNS lookup service you (or your ISP) is using has some kind of problem resolving Opera's URL to its correct IP number or your signal path to that IP is being blocked (either by your computer/software, by your ISP, by national censorship, or by Opera's servers). If your friends are using the same ISP but getting through directly to Opera without VPN, then the problem lies in your system... probably either in some kind of block inserted into your hosts file, because of an erroneous antimalware software program/setting on your system, or because of a problem with the DNS service accessed by your system.

Your ISP can "watch" the packets as they go past, since the first upbound 'external' portal (and the last downward-bound portal) they pass through is the ISP's server. However, if the packet contents are encrypted as they should be (https), all the ISP should be able to "read" from each packet is the IP address of Opera's VPN server as either destination or source, depending on direction of travel.

That said, if an ISP is playing man-in-the-middle games with certificates, etc., they can decrypt, see, and do whatever they want with the packets. That is not common, but it is feasible, particularly in repressive nations.

@yanta said in So it is impossible to natively block a malicious website in Opera, right?:

@blackbird71 said in So it is impossible to natively block a malicious website in Opera, right?:

A malicious extension can use the same hooking mechanisms to inject ad pages into the browser data stream, and there is little that can be done in the browser itself to over-ride the behavior other than disabling/removing the offending extension.

Maybe I misunderstand you, but wouldn't @antimech's suggestion to allow the user to block specific websites in Opera until a malicious situation has been analyzed and resolved not make sense precisely because of this circumstance?

The effectiveness of that would depend on the extension consistently injecting the same ad page URL and the user being able to identify that URL so as to block its appearance. Moreover, if an injected pop-up ad came directly from the rogue extension code itself, the user would only be able to block the ads' linked URL but not the extension's pop-up itself (unless they identified and blocked the extension).

@antimech said in So it is impossible to natively block a malicious website in Opera, right?:

It was an aggressive adware/malware of the sort "you are the lucky winner" that was called by some specific website or installed without my consent.
In both cases a browser should not allow full control without an escape method, by ... any addon when the code itself is not infected.
That is perfectly feasible. Period. ...

Given that in current chromium rendering engines, extensions potentially have the ability to hook a browser's 'internals' before the browser actually processes the site code, the browser may not be able to "escape" what an extension does. This is how Ublock Origin, Ghostery, and many other similar extensions are able to block sites (or portions thereof) effectively. A malicious extension can use the same hooking mechanisms to inject ad pages into the browser data stream, and there is little that can be done in the browser itself to over-ride the behavior other than disabling/removing the offending extension. There is currently much controversy over chromium developers' recent efforts to reduce the scope of some of the extension hooking since that would also make ad blockers less effective, though it would tend to reduce the attack surface used by rogue extensions.

According to Adgoal's website (https://www.adgoal.de/en/privacy-user.html), the smartredirect.de site is an ad server operated by Adgoal. In analyzing the URL with several different browsers here, a "Could not locate remote server" error message (or equivalent) appears on each. Either the URL is being blocked by anti-adware software on your system or along the signal path, the URL has no DNS entry, or the smartredirect server is down.

Unless you're getting the popup repeatedly on the same website(s), the implication is that specific websites are not the actual cause. In which case, it's something already onboard your computer or browser that's triggering the popups... either malware or adware. Check your Opera browser extensions for anything you don't recognize as something legitimate and clean it out; run a full-system scan for malware and adware using reputable 'anti' tools. Ublock won't trap or block adware/malware already installed into the browser; Kaspersky may or may not trap a particular form of adware, especially if it was installed 'piggy-backed' on some other legitimate software you may have downloaded and installed.

There are signficant differences in an eMail client from a web browser. Olde Opera used essentially separate code modules for each funtion, which shared some common user interface coding that made them appear as a unit. Any "internal" eMail client for a browser would have to be architected essentially that same way, since the eMail protocols and functionality are not normally part of a browser rendering engine, especially the chromium engine. Likewise, the detailed support for an eMail extension is typically not present in a browser engine.

Since there are a number of widely-used, standalone eMail clients 'out there' (Thunderbird, Outlook, etc), there is a limited 'market' demand for an internal eMail capability in a browser. Vivaldi is exploring this with their browser, but nothing has yet emerged for public distribution after several years of design effort. An eMail client (either internal or standalone) represents a very reliability-demanding design that must essentially end up glitch-free in all its modes, so there is a limited risk-reward payoff for its design.

@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.