You are probably well aware (probably more than me anyway) that many websites use scripts to fingerprint user's browser by gathering info like resolution and screen-size, OS details, browser version and build, installed add-ons, etc.
Is it possible, using javascript to spoof some/every property of your browser (Chomium/Cef or any other), so that it is impossible for later-loaded scripts to fingerprint your browser or detect the navigator object has been tempered with?
If it's not possible to accomplish using JS then how about extensions and addons?
This might be something obvious for the seasoned web developers of you, but I don't have extensive experience with web development, and can't find a definitive answer online either.
Related
I'm making a game with HTML/CSS/Javascript because it's the code I'm most comfortable with at the moment. I'm only really doing this as an exercise in game development and plan to learn C# later. But for now that's what I'm using, and I have a question about it.
Obviously when making a website, you want your website to be compatible with all web browsers equally. Right now, I'm using Chrome to test/debug my game, and I've decided to develop this game with Chrome in mind. But not everybody has Chrome, and not everyone would want to download it in order to play my game.
Is there a way to run an HTML/CSS/Javascript file in a Google Chrome "environment" without having the actual browser installed? Just it's code engine and none of the rest of the browser.
I've been reading about their V8 Javascript engine that they use in Chrome, and am wondering if that is part of the answer I'm looking for. What I'd like to do is include this "engine" in an installer with my game files and have it install like any other game.
Hopefully this makes sense. This may not be possible/exist, but if someone knows something I don't or an point me in the right direction, that'd be amazing. Thanks!
You could look into Node-webkit which essentially allows you to write desktop applications in html/css/js. When you distribute your game along with your node webkit executable, it is always run in the same environment. You can see some cool examples on their demos and examples page.
Usually a common path to convert web application to native desktop applications is to use a "thin" browser as app container and ship it.
A lot of current applications out there are using this trick (Spotify, Slack, etc...) and it works pretty well.
I've read of some people using the CocoonJS game engine framework and successfully ship it with this techniques.
To most famous wrappers, that I know are node-webkit or electron (AKA atom-shell).
Once you include your game in either one of those you can just "compile" it (it is not a real compile, but just to give you an idea) and ship it: with some tricks it is also possible to publish it in the Mac/Win app stores.
In case you want to focus on mobile instead, there are similar frameworks but I don't really know which are the most common.
Note: if you're using fancy WebGL or very advanced stuff these tools may have some issues sometimes.
So essentially you want to install the JS engine to use it with any browser? In this case, the answer is: nope. Browsers act different, they don't have a standard interface, nor have this "swapping" capability in mind.
In case you'd be asking for an embedded browser inside an app... well, isn't that worse than installing Chrome? You may embed webkit/V8, but it's a hard way and you'd know programming.
So simple answer is: you'd make it compatible for at least the evergreen browsers (Chrome / Firefox mainly). Or reduce your target to webkit based only browsers (or in your case V8, i.e. Chrome, Chromium and the forks).
If you want that your game is only for chrome, because you read V8 documentation, you can create it as an extension. There'sn't other way to install your JS, because browser interpret javascript, not compile it. And the docs you need is found at: https://developer.chrome.com/extensions/getstarted
Since I read Google's message that NPAPI will no longer be supported by the end of 2014, I've been looking for an alternative. The issue is that we currently use a custom made Kinect Browserplugin which we use to control the browser with JS and control Unity Web Player games with your body.
Without NPAPI support it simply won't work anymore and our work will be lost. Google gives NaCl as an alternative but this doesn't support interaction with hardware.
The main question I have is: How to use the Kinect in a webbased platform and crossbrowser?
Currently we have the "normal" Kinect and the Kinect One from the closed beta working in the browser and Unity Web Player.
Please share your thoughts on a solution.
I apologize in advance for just spewing out links without actually supplying much information, but as far as I know there are no known good alternatives.
If I was in your position, I would have a look at the chrome.usb API or possibly, depending on your use case, node-kinect.
Here's a good general resource/discussion of NPAPI alternatives: Browser Plugins in a post NPAPI world
Probably your best approach at this point is to continue using NPAPI except in Chrome, and in Chrome use native messaging. Of course, Chrome has made it as difficult as they can to install the host that you'll be connecting to, so it'll be a pain and you'll have to install the extension and the host seperately, but there you go.
So not sure if this would be the correct place to ask these but I know I could perhaps get some answers.
I am getting into Meteor and now would like to make some desktop apps. I was going to go the route of just making a native Mac app. But then I found the app wunderlist and its open source making use of the tidesdk.
Anyways I was hoping to get some feedback just in general about these frameworks (pros/cons etc). I don't really have a conceptual understanding of what they do. (or what the main difference between the two is).
I notice you can do routing in them. How is this working exactly? Because there is no URLs or client/server side.
Another thing I was wondering is if it would be possible to use MeteorJS on the desktop in a similar way?
Thanks.
Working with TideSDK is quite easy. We are working to make the experience great for developers. You are essentially just creating an HTML5 app in a special Resources folder. In most cases you can drop an HTML5 app directly into the Resources folder, point to the index.html using TideSDK's configuration and have it running in minutes. TideSDK can be used to run clients, servers, processes, and workers. I tend to work with frameworks such as backbone.js where routing is baked into a single page app.
At the core of TideSDK is WebKit, the core technology that powers the Safari and Chrome web browsers. We use three different ports of WebKit in TideSDK, one to reach each platform (Windows, Mac, Linux). On OSX, we can also use the native WebKit. The APIs of TideSDK provide native UI capabilities (that we are enhancing over time). These include native windows, system trays, menus, and dialogs. You can also interact with the clipboard. We have networking and database capabilities, system notifications, and more. We patch Webkit to allow the interpretation of python, php or ruby in the DOM in script tags and are able to bridge objects between languages. Our API's really allow your to reach the resources of your system including interacting with its filesystem.
It would be fun to run meteor in TideSDK. It is currently possible to run node.js within TideSDK using an appropriate startup process so I cannot see an issue running meteor so that it can run client and server within an app.
If you need your apps to reach Apple's AppStore, TideSDK is the only framework that I am aware of that has this potential. Competitive frameworks use ports of WebKit that are not native to the Mac such as the Chrome port (appjs) or the QT port (Sencha Ion). Apple's scan of an app based on these ports will reveal the use of "private APIs". Therefore, you would could not enter the AppStore marketplace with an app based on these. TideSDK is different and can use the native WebKit implementation on OSX. More about this capability will be revealed in the upcoming TideSDK-1.4.0 release. Our upgraded WebKit will also bring the HTML5 capabilities right up to date with the trunk of WebKit. Many of our users are waiting for this important update.
With WebKit eliminated as a barrier to the AppStore, the last issue facing a developer is Apple's sandboxing and entitlement to the resources of the system. We are looking at possible solutions to aid developers with sandboxing requirements. Some apps will be suitable for sandboxing and others will not. That said, if your goal is AppStore compliance, you will need to work with restrictions Apple has in place. I hope this helps.
I need some expert information about ActiveX and some valuable experience reports from those that already used it.
The situation is the following: ~90% of all of our applications are created as web apps with ASP.net WebForms. We're now in the process of switching to a more modern approach, creating rich client JavaScript apps. However, In one of the recent projects, a strong requirement from the customer is the ability to directly print to a (previously configured) printer attached to the user's workstation. Yes, no printer dialogs, print previews etc.. It has to be fast.
Obviously this is a scenario where you would rather use a desktop app than a web based one. Still, we would like to benefit from our existing web dev knowledge and are therefore considering to write that very specific, isolated printing functionality as an ActiveX control (IE dependency is not an issue).
Now, since the word "ActiveX" alone causes disgust for some people, I'd like to hear what might be the potential problems at using such a (old) technology or do u directly consider me to make it as a desktop app and completely forget about it?? Or are there alternatives??
The primary challenge you'll face is the learning curve; beyond that the biggest problems are the potential for you messing up and opening a security hole (for example, what happens if a malicious third party loads your activex control on their phishing site? can they use it to print things?), etc.
For the learning curve, I highly recommend looking at FireBreath, which can be used to create browser plugins that work on IE (as an ActiveX control) as well as Firefox, chrome, safari, etc (as a NPAPI plugin). Though ActiveX is an "old" technology, it's still used extensively in the modern day; for example, Flash, Silverlight, Quicktime, and other "plugins" like that are all activex controls in IE.
Firefox has a SpiderMonkey javascript engine. Chrome has V8 javascript engine.
Obviously those engines are a separate products and browsers utilize some kind of interface API to interact with them.
On the other hand programmers longed for a long time for their favorite language in browser. So much so, that we have products like GWT (for java), parenscript (for common lisp), HJScript (for haskell), and i'm sure many other libraries for many other languages that allow programmers stay with their favorite language and generate client side code as well.
The idea is so obvious that i am surprised that there's no implementation of it yet. Why not publish the interface API of browser to language engine and allow web sites to provide custom language engines as downloadable bundles. With current internet speeds 3-4 megabytes one time download is not a problem for majority of applications, even more so for intranet usage.
So where's our pluggable engines ?
You don't need pluggable engines really, just an agreed upon byte-code format. Google is going down that path now with NaCl and PNaCl which is based on LLVM. So any program that compiled down to a safe subset of LLVM byte-code could be run in the browser.
Browser vendors can't even agree on a common video format (see the html5 <video> debate) or on how the document DOM object should look like, and you want them to agree on a whole language interface?
Good luck.
I guess you forgot about applets and embed's. Both offer exactly what you want. And both suck for the very same reason.
We've been down this route in the past.
Older versions of IE supported VBScript as a scripting language in addition to JScript.
The result was a whole load of sites that only worked in IE.
This isn't what the web needs again. As a developer, I may desperately want to write code using my favourite language, but as a user I want to be able to browse all sites on the web without having to worry about which plug-ins I need for any given site, or whether my preferred browser can even use those plug-ins.
This is the problem that Microsoft's Silverlight has had. It might be a marvellous technology, but to the end user, why do I want another plug-in? Silverlight has managed to gain some market share thanks to the sheer power of Microsoft, but really not that much.
Now, if the code reaching the end user is consistent, regardless of the language it's written in, then the language doesn't matter. But this effectively means compiled code (or at least bytecode), which is a whole different kettle of fish to running a scripting language in the browser.