RESTful online applications may use of many of the request methods which World Wide Web and HTTP are based on, while web browsers classically use at most GET., POST requests methods. In GET request, query string is sent as part of the URL. GET requests can be cached, bookmarked and remain in the browser history. The use of GET request is not an option when dealing with sensitive data. It is only used to request data, not modified it.

POST request sends data to a server in order to update/create a resource. POST request has similarities with GET request, except it contains a body. That data sent to the server is stored in the request body of the HTTP request. POST requests are not cached and cannot be bookmarked. They do not remain in the browser history.

POST is somehow safer than GET because the parameters are not stored in browser history or in web server logs and because data sent is not part of the URL.

Those for which true confidentiality comes with no compromise, search engines providing a cloud storage service regarding browser's settings is definitively not an option. The dully auto-stated, world's most private search engine has by default the right settings to deserve that appellation. Then POST method is coherently as default. Since any government surveillance programs that were begun with good intentions unaccountably have become tools for abuse, it even provides the ability to opt for the use of EU-servers, instead of US' ones, in order for EU users to avoid the mass Internet surveillance program "PRISM".
Despite the cookie StartPage sets to save settings is non-identifiable and therefore safe to accept, cookies in general may pose a threat to user's privacy.

For those users like me that do not accept cookies, an option is provided to generate an URL in an obfuscated form, (model: 'https://www.startpage.com/do/mypage.pl?prf=5ca7c2adc2e8c17819jk4eed4cf197ae'. Despite that generated URL can be set as homepage or used as bookmark, it cannot be yet as search engine in any web browsers, which counts Opera.

Though an URL in GET form, such as 'https://www.startpage.com/do/search?query=%s' , would be a valid one to be used for the addition of a search engine, but it still would use the GET method. In that context, would it be fair to request from Opera the implementation of a new design scheme that would allow a search engine involving such an URL relying on POST method to be set as the default one?

@jbrandon. An option titled 'Enable dark theme' has been made available –path: opera://settings/ , under category Basic, subcategory Appearance–. Yet targets to which that function applies are without doubt on purpose made restrictive as that observation cannot possibly be an issue. Those built-in pages Bookmarks, Personal News, History, Extensions, have been left in the UI team process out of consideration, and their readability illustrate still what an unfriendly eye-destructive over-lighted theme can be. Title 'Enable dark theme', comes along with no particular mention; therefore its application is meant to be global, while it currently applies only to the built-in page Settings.

Bright backgrounds are obviously well known to fill doctors' list of customers constantly full, as such backgrounds are indeed so eyes consuming which is no trivial case. Expectedly current request concerns the need for a solid dark color as an alternative option so that current reading won't be aggressive any more. That is only one of the so many ways to deserve a qualification closest to 'modern' regarding the very web browser Opera.

Hi. Only when the browser is opened in Private mode and regarding the LastPass extension in Extensions interface the option Allow in private mode is selected, a systematic crash occurs when clicking the LastPass’ icon in the login field. The browser is unable to recover from such a consecutive crash.

The Private Window mode keeps tracks of history regarding the managed extensions while it is expected not to do so. While checking for testing purpose the Clear browsing data… section, History appears to be empty as it should when dealing with web pages but not regarding the managed extensions. Wouldn't it be preferable to make the Private Window mode working globally by covering extensions as well?

Even in Private Window mode, after having logged out from an account and then having refreshed the web page (Issue currently occurred with the Google GMAIL service), had no effect on the login display as the page kept displaying the previous login name. Issue could only be avoided by shutting down the current tab and reopening a new one with the same login page.

Official on-line available information lacks of transparency regarding the free, unlimited, and with no subscription built-in VPN service related possible internal vulnerabilities. Would Opera be kind enough to inform transparently and in a clearly form its on-line documentation regarding the present topic?

As mentioned on Opera's web site, this service in Opera browser is provided by SurfEasy Inc., an Opera company based in Canada. By offering such a legitimate service aimed to enhance privacy and even for free of charge, it rises concerns regarding the essentially privacy, about leakages which indeed do occur behind VPN services (paid or not).

Currently a growing range of techniques like fingerprinting detection attempts through Canvas elements, like Canvas font access, audio (via the AudioContext API), via the WebGL API), via the Battery API), device enumeration (via the WebRTC API), gamepad enumeration (via the Gamepad API), WebVR enumeration (via the WebVR API), or through calculating Client’s element rectangles. decrease instantaneously the very effectiveness of VPN services.

However, protection against those attempts requires unfortunately for now a third-party add-on, that may not be trust-worth. The fact that only one add-on of that nature is currently present for download in the add-on collection available in Opera, may not be a surprise for the few who were aware of the challenging situation in protecting even with VPN.

Does Opera use for tunneling and data encapsulation the PPTP protocol, which is fundamentally insecure due to using short length encryption keys and password hashes that can be cracked by a skilled individual or the L2TP/IPSec protocol, which has already been tampered successfully by the NSA. In case Opera uses a more secure protocol, may the traffic remain vulnerable because of the use of insecure ciphers?

Does the VPN service require use of Perfect Forward Secrecy ciphers, so VPN network traffic can not be saved, and subsequently decrypted later if the encryption keys or algorithms have been compromised?

At last, while VPN services usually do protect web traffic, many do not or loosely, protect DNS lookups, meaning that user’s browsing history can still be reconstructed from DNS lookups. How does Opera protect DNS lookups from DNS leakage if it even does?

Currently, a reader-view mode, a welcome feature, because so useful regarding the damaging nature of so many web pages for eyes, is not present. Such a feature, realized in a user-friendly way, would be so that activating a such mode would come with a vertical bar on one side of the screen. Regarding the bar, the feature would provide the options either to hide it permanently or automatically, on demand (showing a discrete arrow when hided). The bar would automatically adjusts its color to the selected available background color so that it would avoid annoying eye-consuming contrast. The reader-view mode icon itself would sit into the URL field (right or left) with a specific color regarding to its state (activated or inactivated).

The current way the Full Screen mode is realized is a restrictive one, as it conducts invariably to the situation in which the users have indeed to quit the Full Screen mode, –in which they may want to stay permanently– in order to complete whatever the available tasks (as examples, selecting in Menu’s bar one of the two states for a page (Back, Forward), completing a search in the URL field, opening a new tab or something else).

In fact, the current Full Screen mode does force the users to interact manually with the Full Screen mode function that way:

• By selecting ”Exit full screen (F11)” by mouse or pressing key F11. Doing so, users are no longer in the Full Screen mode which is not the goal when aiming at be used permanently.
• User completes his task (whatever the task, in which Menu’s bar has to be momentarily visible)
• Then by reactivating the Full Screen mode, which user was forcing to leave in order to complete the previous step, and that should not have to be deactivated if Full Screen mode had been conceptualized in a user-friendly way.

The solution to that case does exit indeed:
While in Full Screen mode, by moving the cursor on to the top of the screen, the Menu’s bar would be made momentarily visible, so the user may completes his task (whatever the task), without leaving at anytime the current Full Screen mode. Once the task would be completed, by moving the cursor out from the Menu’s bar, the Full Screen state would reappears instantly.

The above depicted solution has been implemented in other browsers just the right way (you may know the ones). It just needs to be realized the right way once for all in Opera.

Regularly dealing with the creations of HTTPS-web servers, comes along with the testing phases of the HTTPS-sessions’ pages and their components’ related security information and features (Protocol version, cipher suite, HTTPS Strict Transport security, certificate an so on).

Such a web tool for testing and troubleshooting purposes has been available for a while in Mozilla Firefox and browsers based on it, which is no surprise, and Firefox remained the only one to make it available. So that is the one that could be used, until now too.

After a long break of using Opera for the reason (at least part of it) some of the Developer tools were not as accurate as expected, I just came back to it because of pertinent improvements and surprisingly found that the tool is still missing from the Opera’s Developer tools (Ctrl+Shift+I). It seemed logical to assume that the tool would be naturally implemented in time into Opera because of the obvious need for it; without it indeed the work cannot be done.

For the moment under Network in menu, only the following tools are indeed present: Headers, Preview, Response, and Timing. If it takes many efforts from your current team’s developers to achieve this tool, at least it is worth to be done.