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.
Related
I want to identify a user by unique machine id across all browsers. So came up with an idea of launching a app which determines the machine-id (like electron using nodejs) and passes back the info to the browser that launched it and use for identifying the user.
I have seen something like this been done on canyourunit
Can anyone point me right direction where can i find some info about this kind of approach.
As you would be asking a user to download and execute native code, electron or whatever else, there are several complicated issues to consider.
The obvious first one is that you must consider the user platform (OSX, Windows, Linux...) then, communicating back with the browser directly (which one?) is probably not practical.
Your native application could however send the machine id/fingerprint to your backend so you could identify what web client is what.
This is quite involved, fragile, and even if you only support Windows, will fail in many scenarios (system policies, firewalls, antivirus, proxies, strange network setups...)
All in all, it would seem that you should consider more standard Device fingerprinting techniques if you only need an ID.
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/
I would like to develop desktop application with adobe air. but I am worried about html/javascript source code security.
Application has paid media content and I would not like to expose urls.
How can I secure source code?
I don't feel like anyone will be able to answer your question, because what you are asking for is not good practice. What you are trying to do is basically security through obscurity. You are hoping you will be more clever than any malicious users who download your app, and none of them will be able to figure out where you hide the stuff that is executing on their computers.
The United States National Institute of Standards and Technology
(NIST) specifically recommends against security through obscurity in
more than one document. Quoting from one, "System security should not
depend on the secrecy of the implementation or its components." -source
No matter what measures you take to obscure a URL, if the site is going to be visited on a computer where the user has physical access, it will be vulnerable.
Depending on what language your server software is written in, you can implement something like user accounts/roles. If you have a question about how to do that, you should give it a fair shot, and post another question if you come up with one.
I am completely new to javascript programming and I have a question that I didn't manage to find an answer for anywhere.
I have recently put together a simple slideshow to view the photos remotely that I host on my home computer. This by itself works fine. The problem I run into is that when I'm viewing photos I don't interact with the hardware, which after some time causes the monitor to switch off. This is particularly annoying when watching photos on my mobile phone.
My question is: is there a way to prevent this from happening? I am thinking in the direction of faking a mouse or other event every time I refresh the photo, but I have no clue how to do that and if it is possible.
Any help is greatly appreciated!
No. JavaScript on the browser cannot interact with the underlying system. Simulating keystrokes in the browser will not stop the screen saver from turning on. This is for security reasons, so that malicious code can't harm the system when you visit a web page.
Link on JavaScript Security
The modern JavaScript security model
is based upon Java. In theory,
downloaded scripts are run by default
in a restricted “sandbox” environment
that isolates them from the rest of
the operating system. Scripts are
permitted access only to data in the
current document or closely related
documents (generally those from the
same site as the current document). No
access is granted to the local file
system, the memory space of other
running programs, or the operating
system’s networking layer. Containment
of this kind is designed to prevent
malfunctioning or malicious scripts
from wreaking havoc in the user’s
environment. The reality of the
situation, however, is that often
scripts are not contained as neatly as
one would hope. There are numerous
ways that a script can exercise power
beyond what you might expect, both by
design and by accident.
Over the decade since this questions question was originally asked JavaScript has grown to provide much of the OS functionality (usually in a secure manner). The "wake lock" functionality is slowly being implemented. Currently there is a draft for the navigator.getWakeLock interface: https://www.w3.org/TR/wake-lock/#conformance
Chrome (https://developers.google.com/web/updates/2018/12/wakelock) and Mozilla (https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API) are considering it in various manners.
No, JavaScript cannot affect hardware or operating system. Just turn off monitor power saving settings until you're done with the slideshow.
Yes, It's possible now :)
Just use NoSleep.js library: https://github.com/richtr/NoSleep.js
It's working form me with Reveal.js slides on my Android Tablet
You could do it with a console application written in c# that interacted with the os
since js is a client side browser language it can only interact with the browser/bowser
I've never actually used greasemonkey, but I was considering using it.
Considering that GreaseMonkey allows you to let random people on the Internet change the behavior of your favorite websites, how safe can it be?
Can they steal my passwords? Look at my private data? Do things I didn't want to do?
How safe is Greasemonkey?
Thanks
Considering that GreaseMonkey allows you to let random people on the Internet change the behavior of your favorite websites, how safe can it be?
It's as safe as you allow it to be - but you aren't very clear, so let's look at it from a few perspectives:
Web Developer
Greasemonkey can't do anything to your website that a person with telnet can't already do to your website. It automates things a bit, but other than that if greasemonkey is a security hole, then your website design is flawed - not greasemonkey.
Internet user with Greasemonkey loaded
Like anything else you load on your system, greasemonkey can be used against you. Don't load scripts onto your system unless you trust the source (in both meanings of the term 'source'). It's fairly limited and sandboxed, but that doesn't mean it's safe, merely that it's harder for someone to do something nefarious.
Internet user without Greasemonkey
If you do not load greasemonkey or any of its scripts, it cannot affect you in any way. Greasemonkey does not alter the websites you visit unless you've loaded it on your system.
Greasemonkey developer
There's not much you can do beyond what can already be done with XUL and javascript, but it is possible to trash your mozilla and/or firefox profile, and possibly other parts of your system. Unlikely, difficult to do on purpose or maliciously, but it's not a bulletproof utility. Develop responsibly.
-Adam
Considering that GreaseMonkey allows you to let random people on the Internet change the behavior of your favorite websites
Random people whose UserScript you have installed. No one can force you to install a UserScript.
Can they steal my passwords?
Yes, a UserScript could modify a login page so it sent your password to an attacker.
No, it cannot look at your current passwords, or for websites the UserScript isn't enabled for
Look at my private data?
Yes, if your private data is viewable on a website that you've given a UserScript access too
Do things I didn't want to do?
Yes, a UserScript could do things to a webpage (you've given it access to) that are unwanted
How safe is GreaseMonkey?
As safe as the individual UserScripts you have installed
When used with discretion, Greasemonkey should be perfectly safe to install and use. While it is definitely possible to do all manners of mischief with carte-blanche Javascript access to pages, Greasemonkey scripts are restricted to specific URLs, and will not run on sites that are not specified by the URL patterns in their headers.
That being said, a basic rule of thumb is to consider most information on pages with Greasemonkey scripts active to be accessible to those scripts. It is technically feasible to play games like replacing input boxes (in which you might enter passwords or personal info), read any data on the pages, and send data collected to a third party. Greasemonkey scripts do run in an effective sandbox within the browser, and shouldn't be able to affect your computer outside of Firefox.
That being said, in some respects, the risk is comparable to or less than that of installing any other small pieces of open source software. Since Greasemonkey scripts are simple open source Javascript files, it's relatively easy for a programmer to take a look inside and make sure it does what it says it does. As always, run strangers' code (of any form) with care, and take the time to skim the source code if the software is important to you.
In general though, Greasemonkey scripts should be pretty safe. Try to use scripts with a large number of reviews and users, since these are likely to be more thoroughly vetted and analyzed by the community.
Happy userscripting!
Yes, userscripts can steal your passwords. That's the bottom line. Don't use firefox addons or userscripts on work or government computers without referring to your bosses.
Unlike firefox addons userscripts are not formally vetted. (Firefox 'experimental' addons are also not vetted). You can register and add a malicious script to userscripts.org in a moment.
Userscripts are very unsafe. The cross-site scripting ability means that it's no difficulty at all to send off your details/passwords to an evil server quite invisibly. And the script can do it for any site. Ignore the other answers that attempt to dismiss/minimise this issue. There are two issues: evil script writers putting their evil wares on to userscripts.org and scripts that break greasemonkeys' sandbox and so are vulnerable to being used by malicious code on a hacked site that would otherwise be restricted to same-domain.
In the case of evil script authors you can examine the scripts for code that sends your details; not much fun. At the very least you could restrict the script to particular sites by editing the 'include/exclude' clause. That doesn't solve the problem but at least it won't be sending off your banking credentials (unless you've used the same login details). It's a pity there isn't an 'includexss' clause to restrict xss requests, which would effectively solve the problem since, crucially, it would be easy to check even for non-developers. (the Firefox addon "RequestPolicy" doesn't block userscripts.)
Unsafe scripts: look for any use of 'unsafewindow'. There are other risky calls. Greasemonkey doesn't warn you of their use when the script is installed. Use of these calls doesn't mean the script is unsafe, just that the script writer had better be good at secure programming; it's difficult and most aren't. I avoid writing scripts that would need these calls. There are popular, high-download scripts that use these calls.
Firefox plugins/addons at Mozilla.org have similar problems to userscripts but at least they are formally vetted. The vetting/review includes the all-important code-review. Nevertheless there are clever techniques for avoiding the detection of evil code without the need of obfuscation. Also the addon may be hosted on an (unknown to anyone) hacked site. Unfortunately mozilla also lists 'experimental' addons which are not vetted and have had malicious code. You get a warning but how many know the real significance. I didn't until I picked up security knowledge. I never install such addons.
Userscripts are not formally vetted. Unless a script has a lot of installs I examine the code. Even so a high-install script could still have had the script-writer's account hijacked and script modified. Even if I examine a script the use of anti-detection programming means I may not see the evil. Perhaps the best bet is to examine outgoing requests with "Tamper Data" firefox addon, but a clever script will delay or infrequently send data. It's a tactical war, unfortunately. Ironically only microsoft's certificate based activeX objects really approach a real solution in developer traceability (but didn't go far enough).
It's true that a firefox addon gives an evil-doer greater exposure to potential victims, since firefox addons are generally more popular and so seem more likely to be targeted, but the firefox vetting process makes userscripts more attractive to the evil-doer since they are not vetted. Arguably a low-download userscript can still get a criminal plenty of valuable logins until it is spotted, while also giving the benefit of the relative obscurity and low community churn of userscripts, as well as a low chance of anyone code-reviewing it. You can't depend on firefox addons' popularity to protect you from evil userscripts.
As a non-developer you are dependent on other users spotting evil scripts/addons. How likely is that? Who knows. The truth is it's a crap security model.
Ultimately I use firefox for general browsing and Google Chrome (without greasemonkey/plugins) for admin purposes. Chrome also has a usable 'profiles' feature (totally separate browsing spaces) which is effectively like using different browsers. I've set up three chrome profiles to make myself even more safe: email/general-admin, banking, ebay/paypal. Firefox has unusable profiles (in my experience) but I prefer firefox as a browser which is why I still use it for uncritical browsing. Profiles also protect against old fashioned browser security holes and hacked sites, at least limiting their scope. But make sure you use different passwords. Another approach is a clean bootable ubuntu install on a USB stick for critical admin (see here http://www.geekconnection.org/remastersys/).
Jetpacks' special trust model, rather like the PGP trust network, which underlines the seriousness of this issue, should hopefully mitigate it. Jetpack is firefox's new kid on the block: a kind of super greasemonkey.