I was wondering if there is any way to get the HTML5 Geolocation system without GUI on a Debian based system?
My plan is to geolocate via HTML5 a computer without any GPS system, so I thought I would send a request with an headless browser to my web server, get the headless browser position (by accepting the prompt somehow) and return it to my server, am I wrong?
I saw phantomjs but apparently it's not working for geolocation.
(Yes, I already saw this Headless browser that support Geolocation but I think the answer is outdated and my question is more precise)
Thanks
Related
sending linux terminal traffic to chromium browser
As you know there is chromium extension called veepn. it's a tunneling service
this question may be strange, but i hardly looking a way to send linux terminal traffic (for example wget) to chromium browser.
I don't want to use vpn connection on my linux network.
anyway to do that ? thank you guys.
I heard the TPM can be used for DRM purposes. But currently is there a way to access this module through the browser? or is it simply for native applications.
The only thing I came across searching was tpm-js, but this tutorial seems to be for js running outside the browser.
Has there been demonstration of TPM access to identify users through the browser?
I want to create a webpage that will access the USB port of the client. Intent is to configure the hardware connected the USB port. I can do a desktop application because the configuration option is different for different hardware. connected and I need to pull this code dynamically from the server. I am not a web programmer. It will great to find the best way to do this.
It ends up that I am attempting to write an app that performs something similar. What I am doing, instead is writing both the web server and the web page. Use something simple, like DLib for the web server, to serve the data to the end user.
This is how it works:
The web server handles the USB connection. If written in C++ or some other native language, you will have much more control over the device. The web page is then loaded from the web server that you have written. In the web page, you can have some sort of javascript worker, etc. to constantly pull new data from the server and push data from the web interface to the USB device. This also adds a layer of protection because you can ensure that the user has not made any modifications to the web page.
The main drawback to this possibility is that you will be required to install the server on the client's machine. However, this can be circumvented by writing this as a applet that can be embedded within the page!
It is possible to write a browser plugin that communicates with USB devices. An example of an app that does that is MyTrezor.com, but unfortunately I don't think you can see the source of their plugin.
Another option might be to use the chrome.usb or chrome.serial Javascript API, but this means your app would only work in Google Chrome, and it would have to be installed as a Chrome packaged app, a special thing that looks more like a native app than a web page.
I've been playing with HTML5 geolocation and noticed that I get consistently better results on my Windows system than on my Linux system.
I dual boot, so hardware is identical. Wifi is on in both scenarios, and there's no GPS adapter built in.
By more accurate I mean that on Windows the location shown is usually within 50-100m of my actual location, while on Linux the location is off by ~6km (and it never varies, it always shows the exact same location, basically the city center).
Tested on Chrome and Firefox on Windows, and Chrome, Chromium and Firefox on Linux.
Update: Just tested on Safari/Mac OSX. Same precision as in Windows. So Linux is the only system with bad results :(
Can anybody reproduce this? Do Firefox and Chrome on Linux not make use of the WiFi as an additional source of location information? What else am I missing here?
Thanks for your valuable input!
Acording to this article: HTML5 geolocation accuracy
Not all Geolocation services are the same, and they certainly don’t all use the same algorithms and exact same databases. Because of this the results typically vary across browsers that use different Geolocation services.
It also explains that Firefox on Windows uses Google Location Services. Firefox on Linux uses GPSD, GPS daemon is a service for geolocation on Linux.
That may be the reason for the difference in accuracy.
I would like to use the chrome browser as a software technical platform for
digital signage purposes. To force the chrome browser to receive and execute any
self-defined custom commands (e.g. create a new tab and inquire the content of a
certain web-page/url) I need to run the chrome browser as a server
listening to a certain network port.
What is the best way/technology to use websockets, server.io, etc?
NPAPI is the only way to do what you want, short of drastically modifying and compiling Chromium from source. If the client that controls Chrome is in a browser, then packaging a WebSocket library as an NPAPI plugin is probably your best bet. If your client is a desktop application, packaging a plain TCP library should be sufficient.
However, NPAPI has quite a steep learning curve, so I don't recommend using it if you can help it. If possible, just have Chrome establish a constant connection to a central server (using, e.g., Socket.io). Your client can also connect to that server and use it to forward commands to the Chrome instance that you want to remotely control.
So, instead of:
[controlling client] ---> [Chrome]
You could use:
[Chrome] ---> [myserver.example.net] <--- [controlling client]
If your system requirements mandate independence from the Internet (i.e. Chrome won't always have access to a specific external server like myserver.example.net, but must still accept clients on the local network), then you could run the intermediate server on the same machine as the Chrome browser that you're controlling.
Maybe you can implement for example Node.js via NPAPI and get it work... or something else.
It would be better if you use something else because google controls all NPAPI extensions manually.