Develop Reference

Is there a way to know anything about hardware resources of 'platform' accessing webpage?

I'd like to be able to find out about a browser's hardware resources from a web page, or at least a rough estimation.
Even when you detect the presence of modern technology (such as csstransforms3d, csstransitions, requestAnimationFrame) in a browser via a tool like Modernizr, you cannot be sure whether to activate some performance-consuming option (such as fancy 3D animation) or to avoid it.
I'm asking because I have (a lot of) experience with situations where the browser is modern (latest Chrome or Firefox supporting all cool technologies) but OS's CPU, GPU, and available memory are just catastrophic (32bit Windows XP with integrated GPU) and thus a decision based purely on detected browser caps is no good.

While Nickolay gave a very good and extensive explanation, I'd like to suggest one very simple, but possibly effective solution - you could try measuring how long it took for the page to load and decide whether to go with the resource-hungry features or not (Gmail does something similar - if the loading goes on for too long, a suggestion to switch to the "basic HTML" version will show up).
The idea is that, for slow computers, loading any page, regardless of content, should be, on average, much slower than on modern computers. Getting the amount of time it took to load your page should be simple, but there are a couple of things to note:
You need to experiment a bit to determine where to put the "too slow" threshold.
You need to keep in mind that slow connections can cause the page to load slower, but this will probably make a difference in a very small number of cases (using DOM ready instead of the load event can also help here).
In addition, the first time a user loads your site will probably be much slower, due to caching. One simple solution for this is to keep your result in a cookie or local storage and only take loading time into account when the user visits for the first time.
Don't forget to always, no matter what detection mechanism you used and how accurate it is, allow the user to choose between the regular, resource-hungry and the faster, "uglier" version - some people prefer better looking effects even if it means the website will be slower, while other value speed and snappiness more.

In general, the available (to web pages) information about the user's system is very limited.
I remember a discussion of adding one such API to the web platform (navigator.hardwareConcurrency - the number of available cores), where the opponents of the feature explained the reasons against it, in particular:
The number of cores available to your app depends on other workload, not just on the available hardware. It's not constant, and the user might not be willing to let your app use all (or whatever fixed portion you choose) of the available hardware resources;
Helps "fingerprinting" the client.
Too oriented on the specifics of today. The web is designed to work on many devices, some of which do not even exist today.
These arguments work as well for other APIs for querying the specific hardware resources. What specifically would you like to check to see if the user's system can afford running a "fancy 3D animation"?
As a user I'd rather you didn't use additional resources (such as fancy 3D animation) if it's not necessary for the core function of your site/app. It's sad really that I have to buy a new laptop every few years just to be able to continue with my current workflow without running very slowly due to lack of HW resources.
That said, here's what you can do:
Provide a fallback link for the users who are having trouble with the "full" version of the site.
If this is important enough to you, you could first run short benchmarks to check the performance and fall back to the less resource-hungry version of the site if you suspect that a system is short on resources.
You could target the specific high-end platforms by checking the OS, screen size, etc.
This article mentions this method on mobile: http://blog.scottlogic.com/2014/12/12/html5-android-optimisation.html
WebGL provides some information about the renderer via webgl.getParameter(). See this page for example: http://analyticalgraphicsinc.github.io/webglreport/

How to monitor and/or throttle rate limit cpu/bandwidth by client-side web pages?

Nowadays it appears that many webpages want to use my cpu/harddrive/bandwidth in order to show me their ads/pages/information in beautiful but expensive ways.
Often I like these new pages, but sometimes I'm a curmudgeon and am just annoyed that my fan starts spinning and the EMF loads rise when I open the pages.
Is there a browser/plugin that I can use to throttle, best case, and/or monitor, worst case? I am not very knowledgeable of the Reactive JS, etc techniques, so I am hoping there is an easy solution?
thank you!
Anne
ps Normally I use Firefox but of course I have Chrome on my machines (win8, win7, mac 10.8) as well.

You need a client side javascript manipulator.. they are known as User Scripts... For firefox, you want something like grease monkey.... its worth a google... This is not the simplest method, but most effective.
Otherwise you will just want a ad-remover addon for firefox.
Example For Chrome: https://chrome.google.com/webstore/detail/adblock/gighmmpiobklfepjocnamgkkbiglidom?hl=en
They simply search for common code that are used to display adverts (like adsense) and will remove the code from the webpage anytime you view/load a page.
The GreaseMonkey/UserScripts path would be more if you want to customize how your browser interacts with web sites.. For example, you could say for every image on a webpage to be hidden/removed and so on..
As for monitoring, throttling.. Well, you can monitor.. but to throttle.. well that would require a application/proxy that goes between your browser and net connection.
There was one i used years ago that would allow me to simulate a 56k modem speed while developing web pages.
Monitors: https://addons.mozilla.org/en-us/firefox/collections/smayer97/for-managing-bandwidth-usage/
Throttle/Limiter: http://www.netlimiter.com/

OP, in Firefox 68+ (and probably earlier as long as it's Quantum) you can open Tools, Web Developer, Network, or CTRL-SH-E and see how long each element on a page takes to load. It actually has a lot of info. From there you can tell which ad servers are overloaded and take a while to load. Ad servers often slow down a page load because they are busy, but so do larger animated images shown as ads, or ad videos.
I know this isn't exactly a throttle, but it will help you find out more details of what is going on in a specific web page. FWIW, I simply block all ads on most pages and that helps increase load time and reduce bandwidth usage from Firefox.

Protect against browser extension injected Javascript code

Browsers allow extensions to inject code, manipulate the DOM, etc.
Over the years, I have noticed lots and various uncaught errors (using window.onerror) on a website (app) I am watching, generated by unknown browser extensions on Firefox, Chrome and Internet Explorer (all versions).
These errors didn't seem to be interrupting anything. Now I want to increase the security of this website, because it will start processing credit cards. I have seen with my own eyes malware/spyware infecting browsers with modified browser extensions (innocent browser extension, modified to report to attackers/script kiddies) working as keyloggers (using trivial onkey* event handlers, or just input.value checks).
Is there a way (meta tag, etc.) to inform a browser to disallow code injection or reading the DOM, standard or non-standard? The webpage is already SSL, yet this doesn't seem to matter (as in give a hint to the browser to activate stricter security for extensions).
.
Possible workarounds (kind of a stretch vs. a simple meta tag) suggested by others or off the top of my head:
Virtual keyboard for entering numbers + non textual inputs (aka img for digits)
remote desktop using Flash (someone suggested HTML5, yet that doesn't solve the browser extension listening on keyboard events; only Flash, Java, etc. can).
Very complex Javascript based protection (removes non white listed event listeners, in-memory input values along with inputs protected with actual asterix characters, etc.) (not feasible, unless it already exists)
Browser extension with the role of an antivirus or which could somehow protect a specific webpage (this is not feasible, maybe not even possible without creating a huge array of problems)
Edit: Google Chrome disables extensions in Incognito Mode, however, there is no standard way to detect or automatically enable Incognito Mode and so a permanent warning must be displayed.

Being able to disable someone's browser extension usually implies taking over the browser. I don't think it's possible. It would be a huge security risk. Your purpose maybe legit, but consider the scenario of webmasters programatically disabling addblockers for users in order to get them to view the advertisments.
In the end it's the user's responsability to make sure they have a clean OS when making online banking transactions. It's not the website's fault that the user is compromised
UPDATE
We should wrap things up.
Something like:
<meta name="disable-extension-feature" content="read-dom" />
or
<script type="text/javascript">
Browser.MakeExtension.MallwareLogger.to.not.read.that.user.types(true);
</script>
doesn't exist and i'm sure there won't be implemented in the near future.
Use any means necessary to best use the current up to date existing technologies and design your app as best as you can security wise. Don't waste your energy trying to cover for users who souldn't be making payments over the internet in the first place

UPDATE (2019-10-16): This isn't a "real" solution - meaning you should not rely on this as a security policy. Truth is, there is no "real" solution because malicious addons can hijack/spoof JavaScript in a way which in not detectable. The technique below was more of an exercise for me to figure out how to prevent simple key logging. You could expand on this technique to make it more difficult for hackers... but Vlad Balmos said it best in his answer below - Don't waste your energy trying to cover for users who souldn't be making payments over the internet in the first place.
You can get around the key logging by using a javascript prompt. I wrote a little test case (which ended up getting a little out of hand). This test case does the following:
Uses a prompt() to ask for the credit card number on focus.
Provides a failsafe when users check "prevent additional dialogs" or if the user is somehow able to type in the CC field
Periodically checks to make sure event handlers haven't been removed or spoofed and rebinds/ warns the user when necessary.
http://jsfiddle.net/ryanwheale/wQTtf/
prompt('Please enter your credit card number');
Tested in IE7+, Chrome, FF 3.6+, Android 2.3.5, iPad 2 (iOS 6.0)

Your question is interesting, and thoughtful (+1'd), however unfortunately the proposed security does not provide real security, thus no browser will ever implement it.
One of the core principle on browser/web/network security is to resist from the desire of implementing a bogus security feature. Web will be less secure with the feature than without!
Hear me out:
Everything execute on the client-side can be manipulated. Browsers are just another HTTP clients that talks to server; server should never ever trust the computation result, or checks done in front-end Javascript. If someone can simply bypass your "security" check code executed in a browser with a extension, they can surely fire the HTTP request directly to your server with curl to do that. At least, in a browser, skilled users can turn to Firebug or Web Inspector and bypass your script, just like what you do when you debug your website.
The <meta> tag stopping extensions from injection does make the website more robust, but not more secure. There are a thousand ways to write robust JavaScript than praying for not having an evil extension. Hide your global functions/objects being one of them, and perform environment sanity check being another. GMail checks for Firebug, for example. Many websites detects Ad block.
The <meta> tag does make sense in terms of privacy (again, not security). There should be a way to tell the browser that the information currently present in the DOM is sensitive (e.g. my bank balance) and should not be exposed to third parties. Yet, if an user uses OS from vender A, browser from vender B, extension from vender C without reading through it's source code to know exactly what they do, the user have already stated his trust to these venders. Your website will not be at fault here. Users who really cares about privacy will turn to their trusted OS and browser, and use another profile or private mode of the browser to check their sensitive information.
Conclusion: If you do all the input checks on sever-side (again), your website is secure enough that no <meta> tag can make it more secure. Well done!

I saw something similar being done many times, although the protection was directed in the other way: quite a few sites, when they offer sensitive information in a form of text would use a Flash widget to display the text (for example, e-mail addresses, which would be otherwise found by bots and spammed).
Flash applet may be configured to reject any code that comes from the HTML page, actually, unless you specifically expect this to be possible, it will not work out of the box. Flash also doesn't re-dispatch events to the browser, so if the keylogger works on the browser level, it won't be able to log the keys pressed. Certainly, Flash has its own disadvantages, but given all other options this seems the most feasible one. So, you don't need remote desktop via Flash, simple embedded applet will be just as good. Also, Flash alone can't be used to make a fully-functional remote desktop client, you'd be looking into NaCl or JavaFX, which would make this only usable by corporate users and only eventually by private users.
Other things to consider: write your own extension. Making Firefox extension is really easy + you could reuse a lot of your JavaScript code since it can also use JavaScript. I never wrote a Google Chrome or MSIE extension, but I would imagine it's not much more difficult. But you don't need to turn it into an antivirus extension. With the tools available, you could make it so no other extension can eavesdrop on what's going on inside your own extension. I'm not sure how friendly your audience will greet that, but if you are targeting corporate sector, then that audience is, in a way, a very good one, as they don't get to choose their tools... so you can just obligate them to use the extension.
Any more ideas? - well, this one is very straight-forward and efficient: have users open a pop-up window / separate tab and disable JavaScript in it :) I mean, you could decline to accept a credit card info if the JavaScript is enabled in the browser - obviously, it is very easy to check. This would require some mental effort from the users to find the setting, where they can disable it + they will be raging over a pop-up window... but almost certainly this will disable all code injection :)

This wont work, but i'll try something around document.createElement = function(){};
That should affect client side scripts (greasemonkey)
You can also try to submit the current DOM using an hidden input
myform.onsubmit=function(){myform.hiddeninput.value=document.body.innerHTML;} and check server side for unwanted DOM elements. I guess using a server side generated id/token on every element can help here (as injected DOM node will surely miss it)
=> page should look like
<html uniqueid="121234"> <body uniqueid="121234"><form uniqueid="121234"> ...
So finding un-tracked elements in the POST action should be easy (using xpath for example)
<?php
simplexml_load_string($_POST['currentdom'])->xpath("*:not(#uniqueid)") //style
Something around that for the DOM injection issue.
As for the keylogging part, i don't think you can do anything to prevent keylogger from a client side perspective (except using virtual keyboard & so), as there is no way to discern them from the browser internals. If you are paranoid, you should try a 100% canvas generated design (mimicking HTML element & interaction) as this might protect you (no DOM element to be bound to), but that would mean creating a browser in a browser.

And just that we all know we cannot explicitly block the extensions from our code,
one another way can be to find the list of event listeners attached to key fields like password, ssn and also events on body like keypress, keyup, keydown and verify whether the listener belongs to your code, if not just throw a flash message to disable addons.
And you can attach mutation events to your page and see if there are some new nodes being created / generated by a third party apart from your code.
ok its obvious that you will get into performance issues, but thats a trade off for your security.
any takers ?

How much access should an OS give to web-based scripting?

I've been thinking about the access web-based applications have to an OS.
I'm curious:
What is the best way of determining
this as it currently stands?
Is the trend leaning toward more, or
less access?
What functionalities should be
open/closed?
A simple example would be.. say your g-mail alerted you in the task-bar when an incoming e-mail is received.

In the past, browsers have shown a strong tendency to prevent all manner of access to the operating system (and also the browser chrome). The fundamental risk is about trust and deception; if all you have done is visited a website, do you want it popping up dialog boxes or reading files on your hard drive? Even worse, you might not have visited the website on purpose; you might have been subject to a phishing attack where a spammy email linked you to a URL that looks like a popular site, but has a "1" instead of an "I".
It's nuanced to say which way the trend is going. In one sense, you can now do more than before, because you have the browsers enabling GPU support and, as part of HTML5, offline storage. All of this is being done with careful consideration of the security issues though, ensuring sandboxing takes place. On the other hand, you have browsers locking down on things like cookies on the file:// URI.
Many apps are increasingly web apps, but it's not as simple as just pointing to the web app in your browser. It might be an app you installed as a mobile web widget, or purchased in an app store like the Palm Pre's, where most apps are basically just web apps. The point is, the trust scenario is different in each case; I'd feel more confident giving certain OS access to an app from a reputable app store, where the code has been inspected, the producer has signed it, and the app's actions and privileges can be tracked ... than a random website I happened upon.

Any access that is given is going to be abused by malware. Guaranteed.
I think the trend is toward less access; consider Google's Chrome OS, in which you do all of your work within web applications, which have no native access to your system at all.

In what case does IE8 block Javascript and how to avoid it?

I got a web site using jQuery, jQuery Tools and some handcrafted JS running performing graphical enhancements. While it's running smooth on FF, Safari and Chrome, IE blocks the script execution :
There is nothing particularly more dangerous on this code than, let's say, on Netvibes.
Why is even talking about activeX ? I'm using JS.
And how can I prevent that ? I don't want my user to click on "I allow this website" to work. It would be like putting a big red absolute DIV reading "Live quick and never come back".

js can't access the filesystem, so what's so point ?
Actually JS can traditionally do some bad stuff running from the My Computer Zone, like install ActiveX objects. A lot of past IE exploits used this to leverage filesystem access into arbitrary-code access.
So faced with this problem Microsoft decided to solve the problem, not by simply removing the My Computer zone — oh no, that would be far too easy — but by adding an extra layer of complexity. So Internet Explorer gained an option, on by default, to lock down content from the filesystem, whilst allowing other applications that used embedded WebBrowser controls to continue as before, on the grounds that maybe some applications were relying on the loose settings in their internal HTML interfaces.
(They weren't, really, in the consumer space, but then we never know what shades of foulness may exist in the bespoke Enterprise app world.)
After the embarrassment of IE getting hacked all the time, MS overcompensated by making the lockdown settings for filesystem pages considerably more restrictive than even normal web pages from the Intenet. So you can't run JavaScript from files off the filesystem, for no particularly good reason.
At this point web authors whinged, so MS responded not by removing the excessive lockdown — oh no, that would be far too easy — but by adding an extra layer of complexity. So now you can get out of the My Computer Zone simply by placing at the top of your file:
<!-- saved from url=(0014)about:internet -->
This cryptic incantation is known as the Mark of the Web. The newline at the end of it has to be a Windows CRLF, which nicely shafts you if you're using plain LF line-endings. Including this string puts you in the normal Internet Zone where JScript works but you get no other special privileges.
The amusing thing is that since then, the normal security settings in the My Computer Zone have been tightened up so that it's pretty much the same as the default Internet Zone. So the net result is the same as if they'd just got rid of the bloody My Computer Zone in the first place, only with lots of extra complication for the user and annoyance to the web author.
Thank you so very much Microsoft.

As Ken Browning said in a comment to your question, this alert happens with javascript when on a High Security Zone, where local pages are.
If someone has the Internet as a High Security Zone, then the warning will pop up.
You can add localhost to the Trusted Sites Zone.