Opera VPN vs Surfshark

X02 is the load-bearing finding, and both documents behind it are Opera's own. The 2024 announcement quotes Deloitte's opinion as "the configuration of IT systems and management of the supporting IT operations was suitably designed and implemented, in all material respects, based on the criteria described in Opera's Management Assertion, as of 10th August 2024", and separately attributes the sentence "There is no data logging functionality built into the VPN service, and no data whatsoever is collected" to Opera's own Management Assertion.

The 2026 post re-tells the same engagement as Deloitte having done the finding: "we gave Deloitte's team complete access to our VPN and server infrastructure, and they were able to verify our claim ... In fact, a data logging function is not even built into the VPN in the first place." The same post upgrades a window the 2024 post dates as 18 June to 10 August 2024 into "complete access".

Opera is describing its own assertion as its auditor's conclusion. That is why the VERIFY block splits the way it does. V01 is yes_verified on the strength of a report actually opened - Cure53's own published management summary of its March 2022 assessment - not on the strength of the Deloitte announcement.

The Deloitte report itself is not published anywhere, so V02 is press_only, and every field that is a finding of that report rather than a fact about the engagement stays unknown: fleet coverage (V04), assurance standard (V07), what the report states is retained (V11) and the strength of the opinion (V15).

Engagement facts - the firm, its category, the date, what was listed as tested - are taken from the announcement. A vendor that has demonstrably re-characterised this audit once is not a source for what the audit concluded. C01 is none_linkable because that is the declaration in the privacy statement; V11 is the finding, and there is no finding to read.

Cure53's report is real and is the reason V14 is yes_verified: seven testers, twenty-four person-days, white-box across four work packages covering the VPN clients, the server configuration and infrastructure, and the Opera Mini protocol used to deliver VPN config. Fourteen security-relevant issues, eight of them actual vulnerabilities, five rated high severity and none critical.

As of March 2022 nine were fixed with the fixes verified, one partly fixed, three risk accepted, one a false alert and one still in progress. Opera's blog says the seven items relating directly to the browser VPN were "all subsequently resolved", and the table bears that out - the residue sits in the Opera Mini work package, not in the VPN itself.

Ownership is fully disclosed and ends in a mandate country, which is why X03 and C11 point in opposite directions without contradicting each other.

The data controller named in Opera's own privacy statement is Opera Norway AS, a Norwegian company, and the transparency report is filed in that name.

The holding company is Opera Limited, an exempted company incorporated in the Cayman Islands in March 2018 with no substantive operations of its own. The Form 20-F for 2025 names Hong Kong Kunlun Tech Holding Limited as principal shareholder at 68.0%, a subsidiary of Kunlun Tech Co., Ltd. incorporated in the PRC, and states that Kunlun "is the ultimate parent of Opera and is controlled by Opera's executive chairman".

So M06 is NO and C10 is no, while M11 is CN and C11 is yes.

C12 is the sharpest gap between the VPN's declaration and the application it lives inside. The VPN section of the privacy statement declares no logging; a different section of the same document says that when an Opera application is installed "a random installation ID is generated. We collect this identifier, as well as Machine ID, hardware specifications (model, release date, etc.), operating system, environment configuration, and feature usage data", retained for up to three years.

A Machine ID is hardware-derived, so the identifier the provider holds is persistent_hardware_id and not an app-scoped random one, whatever the tunnel does or does not log.

X12 compares two documents Opera filed itself. The Play data-safety form for com.opera.browser declares Installed apps collected for Analytics, and the privacy statement never mentions collecting the applications installed on the device at all. Installed apps is behaviour, not an identifier, hence undisclosed_behaviour.

The same form declares Device or other IDs shared with other companies for advertising, which is what puts C07a at ads. C07b rests on something narrower and is marked B for it: the only third-party host in the markup served for the product page is Google Tag Manager, and what that container loads at run time was not enumerated.

U02 is unknown by design of the product, not by failure of the search: the free VPN offers three regions - Opera names them America, Asia and Europe - and never a country. C09 and C09b follow from that and cannot be settled while it holds.

X05 is ads_supported on Opera's own explainer, which lists advertising first among three revenue lines and describes Opera Ads collecting a randomly-generated user ID, city or country and broad categories of sites browsed, retained for up to a year; together with U05 = unlimited_free this is exactly the case R15 exists to flag.

X06 is the 2026 post's claim that AES-256 "would take a hacker with even the fastest computer more than a billion years to break". X09 is self_disclosed_prompt on two 2026 posts in which Opera published vulnerabilities that outside researchers had reported to it, along with the analysis and the fixed version - these are browser vulnerabilities rather than VPN incidents, and no VPN incident is known.

C05 is not_sold. The free VPN has no payment step at all - no subscription, no account - so there is nothing to pay anonymously or otherwise.

This record was first written as none, which reads as "only identified payment methods are offered" and is false here, because the vocabulary had no token for a service that takes no money; unknown would have claimed the search failed, which was also false, and between two wrong readings the one that errs against the provider was recorded. The token exists now and prices at nothing, which is the honest answer: where there is no payment there is no payment identity to leak.

This record was previously read twice — connection_timestamps in V11 from the audit wording, source_ip in C01 from the policy wording — and graded at the worse of the two, which made the fifteen-minute buffer cost more than saying nothing at all: a blank on C01 is the market prior 0.550 and source_ip is 0.750.

R29 now draws the line: state deleted within a declared window tied to the end of the session is the connection, not a record of it, so both fields read connection_timestamps on the same sentence. What is still charged is what outlives the session — the last login date in policy section 2.3.1 and the connection timestamps the auditor names.

Surfshark and NordVPN share a parent (Nord Security, since 2022) but Surfshark's own about-us page states the brands merged 'while operating independently' with separate infrastructure — M18 is set to separate on that basis, mirroring the nordvpn.com record.

U12a is partial rather than yes on the server table's own P2P column: 88 of the 100 listed countries carry it and twelve do not (AU, CL, CO, HR, GR, IE, JP, MX, NZ, TW, TR, AE). The column is drawn client-side, so it was read off the rendered table rather than the static HTML, where every row carries every label.

The transparency report at /transparency-report — which is where /warrant-canary now redirects — carries the April-June 2026 quarter as a table: 374,719 DMCA notices, 33 inquiries from government institutions, 1 warrant, 0 national security letters and 0 gag orders. P08 counts the 34 legal requests and leaves the DMCA notices out: those are copyright complaints about traffic, not requests for a user's data.

The same page states Surfshark is retiring its warrant canary in favour of quarterly reporting, which is why P07 is removed rather than none — the canary existed and was withdrawn deliberately.

U07_protocols carries proprietary for Dausos on Surfshark's own word — its protocol page calls Dausos "Surfshark's proprietary protocol" and publishes no source for it — and that single value is what sets C13_weakest_protocol and the hygiene charge that follows. IKEv2 is kept because Surfshark still documents it, though its own blog records the removal from the Windows app; Shadowsocks is gone from the support index and is not listed.

The report that would move four fields. The Deloitte report is the other document that would move several fields at once: V04, V07, V11 and V15 are all unknown only because it is not published, and V11 in particular is the field the whole no-log claim rests on.

What has no document. U07 has no document and neither does C13 behind it: Opera names AES-256 and a "secure tunnel" and never a protocol, so the weakest transport on offer is unestablished. U08, U09 and U12b are unfilled for the same reason - the feature comparison table on the product page marks rows with ticks that the fetched markup does not carry, and reading ticks off a rendered image is not a source.

Servers described, not evidenced. C02, C06 and C08 have nothing behind them: Opera says the servers are physical and its own, which settles neither disk nor DNS nor who owns the hardware. C09b cannot be answered while U02 is unknown.

One store, not two. Only the Google Play data-safety form was read; the App Store privacy labels for the iOS browser were not, so X12 rests on one store rather than the worse of two.

Two readings rather than statements. Linux in U01 is inferred from the desktop help manual, which documents the VPN and covers Windows, macOS and Linux together without splitting by platform; Android and iOS are named explicitly in the audit announcement. U10 is unlimited because there is no account and no device cap to enforce one, which is a reading of the product rather than a stated figure.