Hot answers tagged

53

In theory, if all servers and connections to them were perfectly secure (impossible) and trustworthy (not true), neither one would be more "secure" than the other - mainly because the developer(s) of the website are in full control of the content of the site. Since Flash and the JS is served to clients, the server would have to serve malicious content to the ...


30

In addition to WillS' excellent answer, a couple more differences that affect security: Flash is a product, while HTML5/Javascript is a specification. With a product (and especially a closed-source one), you always depend on the vendor to play a game of whack-a-mole (which Adobe is doing admirably, but long term it is a losing battle). A specification can ...


21

A popup was used to show the alert. Does this mean that the popup feature introduces vulnerabilities? Then by that line of reasoning JavaScript is the source of all problems. There are people who actually think that JS is an important vector for attacks and block it on untrusted websites with extensions like NoScript. Many features can be misused, and is ...


4

In this post in the chromium forum there are alternatives mentioned Within the browser space, alternatives exist such as: Use the device's native management capabilities if an enterprise use case. On Windows, this is Group Policy. On iOS/Android, this is the mobile device management suites. On OS X, this is Enterprise settings. On ChromeOS, ...


3

Honestly, the core question is whether vibration of the phone will give an application/website significantly more authority than without the vibration. Now, obviously I lack any research into this specific issue, but we can note that applications do not use vibrations as a way to convene authority. If anything it would feel wrong for an application to ...


2

Firefox The battery API is enabled by default. It can be easily disabled without using third-party addons. Go to about:config, accept the warning, look up the dom.battery.enabled boolean and set it to false. Changes take effect immediately on subsequent page loads. To deploy these settings in an enterprise environment you can use the user.js file which ...


1

Apparently the sessionStorage is not really cleared when closing the tab. It is easily revived by clicking on "Reopen closed tab" I've written more about it in here: http://blog.guya.net/2015/08/25/the-never-ending-browser-sessions/


1

I would like to start this post by mentioning that I expect a downvote from the OP, and possibly a flag, as this question is in fact part of an elaborate straw man which was originally an argument which resulted in my posting of this question. No need to get into that here. But I will certainly answer the question. I would also like to note that Steffen has ...


1

Your question is broad and I will try to answer part of it. In my opinion the move to the web, disabling of Flash and Java etc does not make the whole system safer. It just shifts the fragility and exploits to other kinds of attacks. While we currently have lots of attacks at the OS level and application level (buffer overflows etc) we will have more logic ...


1

In short; A browser restart. However, not every browser implements the specification defined by the W3C the same way. a) Does anyone have any knowledge on how the Tier 1 open source browsers (Firefox, Chromium) handle the sessionStorage and whether the contents could be written to disk, even temporarily in the case of a browser crash? It makes no ...


1

One iframe does a GET on the page with the password and sends this password via html5 windows.postMessage() to another iframe (sourcing the attacker's site) which takes this password and sends it off to the hacker's site via a query parameter in an http get to a hacker's web service. postMessage is done with Javascript. This means one can not force a ...



Only top voted, non community-wiki answers of a minimum length are eligible