I'm building a web app, which involves detection of shaking event for a mobile device:
if (this.hasDeviceMotion) { window.addEventListener('devicemotion', this, false); }
I'm using shake.js plugin by Alex Gibson.
When testing my app in Chrome desktop browser I'm getting this warning:
The devicemotion event is deprecated on insecure origins, and support will be removed in the future. You should consider switching your application to a secure origin, such as HTTPS. See https://goo.gl/rStTGz for more details.
In this link there's this text:
We want to start applying the concepts in https://w3c.github.io/webappsec/specs/powerfulfeatures/ to features that have already shipped and which do not meet the (new, not present at the time) requirements. We want to start by requiring secure origins for these existing features:
Device motion / orientation
EME
Fullscreen
Geolocation
getUserMedia()...
Even though it currently deprecated on desktop Chrome, knowing the guys in Mountain View I'm sure it will shortly be deprecated on mobile Chrome and Android Webview too.
My app is hosted on a server without secure connection, just HTTP. Is there a way to bypass this warning and have a shake detection in my app with HTTP connection?
The best way to bypass the deprecation is to move your application to HTTPS.
Many browsers are going to deprecate plain HTTP in order to make the web more secure. You should follow this trend and make your application support HTTPS. It's not hard though, there are free SSL certificates coming ( Let's Encrypt ).
There is no way to bypass this warning on unsecured origins and you are correct it will be deprecated on all platforms that we are able to auto-update. Right now it is a deprecation warning only and has not been pushed to be a full removal yet. We don't have a timescale as to when exactly it will be removed.
Related
In the Substratum Initial Coin Offering (ICO), the White Paper talks about solving problems of the current Internet, by allowing hosts to become web hosts.
Based on reading of the White Paper, the team looks like they're intending to write Javascript that runs on any modern browser (IE, Safari, Chrome, Firefox) on any platform (Windows, Linux, etc) to turn it into a web server.
As the White Paper is very general, I'm not sure if the team's Javascript is also having some form of access to uPnP technology that tells the nearest router to forward port 80 into the (supposed) web browser that's running on the web server.
Does anyone familiar with current web browsers know if browsers are capable of:
Providing access to uPnP that can tell routers to do port forwarding?
Running a web server using Javascript?
Thank you. (I'm familiar with general programming, just not capabilities of current web browsers. Please limit responses to capabilities of web browsers)
There are some JavaScript libraries such as nohost that use Service Workers to mimic a file server on the client-side. This is apparently possible because service workers are able to send custom responses to HTTP requests.
It might also be possible to run a server in a browser in an x86 emulator in JavaScript, though I don't know if this has been done yet.
Can anyone explain me the possibilities of creating a web chat (i.e similar to whatsappweb) which works without internet connections the only possible way that these device communicate is either by WiFi or Bluetooth (i.e Peer to peer). If it is not possible on earth could then explain why?
I've come across some javascript files like peer.js. But it uses internet i think. I want it to work without internet connectivity.
Thanks in advance.
With WebRTC it is possible to establish peer-to-peer communication between web-browsers in the same local network: https://developer.mozilla.org/en-US/docs/Web/Guide/API/WebRTC/Peer-to-peer_communications_with_WebRTC
A server is only needed for communication outside of a local network: http://blog.vline.com/post/63765098884/webrtc-if-its-p2p-why-do-i-need-a-server
There is another demonstration in this page: https://hacks.mozilla.org/2013/05/embedding-webrtc-video-chat-right-into-your-website/
However WebRTC is a relatively new system that is not widely supported - so consider it experimental at this stage - but it has the backing of Mozilla, so it might end-up somewhere.
However you are limited to the capabilities that WebRTC provides - and as your code is still JavaScript that runs in the browser you will not have access to any kind of actual networking API (such as Berkeley Sockets) or lower-level control of hardware, such as the ability to create Ad-hoc Wi-Fi networks, new Bluetooth Personal Area Networks, or LE Bluetooth connections... at present.
Google is working on making a Bluetooth API available that runs in the browser. Presently it is only available to Chrome Extensions, but it may soon be available in web-pages in general: https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web
Ofcourse there is a way to make this happen. You would have to set up a webserver on the device with this webapp. You could then connect with localhost or 127.0.0.1 . Other people would have to join your hotspot and connect to your ip address.
If you want to connect automaticly you would have to write a real app.
Browsers run in a "contained" mode. No hardware access is possible from any script ran inside the browser, thus there's no way to initialize and setup the device to start direct communication.
I've got this JS application. All client side JS communicating with a third party stream server via web sockets. I have about 18 different web sockets open for one page. Firefox and Chrome handle this many open web sockets at once just fine. IE11 seems to have a limitation of 4 open web sockets at once. Once I open that 5th web socket, regardless of socket call to the third-party server, I get an error thrown by IE, which closes the socket and gives the general error "SecurityError" and expanding the proto section it gives me . Seems to be pretty generic errors from my searches. At first I thought there may be a trusted zone type issue with IE, but I've added the client site to my trusted zone as well as the server providing the data.
This post provides info on max number of websockets for Firefox & Chrome, but I don't see anything specific about IE. Are there any known limitations to IE and web sockets? Answered, see edit below.
This MDN site talks about increasing the max value, but again, I can't find anything about IE. Is there some IE setting to up the amount of open connections? Answered: see below edit.
EDIT: This site shows the max connections settings for IE. It looks like it's a registry setting in Windows that controls the amount of web socket connections. Interestingly enough, I don't have that registry Key anywhere, but there is still a limit for this. The page speaks of IE10, and I'm working with IE11 specifically. Does anyone know if there are registry settings for this in regards to IE11? Has anyone just added these feature web socket registry keys and solved this issue?
The MSDN documentation you referenced is clear on the default being 6 concurrent connections (which means if not specified in the registry, that's what you'll get); and, if the documentation doesn't specify differently, it's probably safe to assume newer versions of Internet Explorer act in the same way as version 10.
Try setting through group policy. It worked for me.
https://jwebsocket.org/documentation/reference-guide/internet-explorer-tips
In Firefox version 23, mixed content blocking behavior is added.It means that Firefox has blocked content that is insecure on the page you're visiting.It shows the shield icon in the address bar which blocks some uploads in my app.From development side how to turn off this behavior?? .I am in ruby on rails development.
Can anybody guide me??
You cannot turn this off remotely! Except in your own browser, of course.
That is: Your rails application cannot turn off mixed-content blocking in the browser.
This is a preference only a (skilled) user may change in her browser... But shouldn't in the age of Firesheep, etc.
Instead, you should make all your active content available via https.
Or downgrade to insecure http. Since you're essentially wanting to allow Man-In-The-Middle attacks anyway, because that's what mixed-content means, the result of using http in the first place wouldn't be that much different. The only difference would be that a MITM could stay passive in http-only, instead of having to actively modify data in https-mixed-mode. But, seriously, what percentage of your users would recognize an active MITM, who maybe even only runs a small targeted attack?
I think you are using firefox version below 23.0 my suggestion is to
first upgrade and then proceed
First Uninstall and reinstall Firefox using Ubuntu software center.
New version of Firefox is available in Ubuntu software center
Reboot the system
your firefox will be upgraded to 23.0 version
Is it possible to create a web app that, with the help of a central server, could create direct connections with other users of the same web app? I'm imagining a process similar to UDP hole punching.
I've read about the new WebSockets API in HTML5, but it appears you must initiate the connection with a WS-compatible server before the fully-duplexed connection can begin. I'm thinking moreso about a process to make direct connections between clients, with a server getting involved only in the initial handshake.
NOTE: Java applets don't count. I'm interested only in standard browser technologies.
Instead of intelligent guesses, here is an informed answer:
HTML 5 plans to allow peer to peer connections from javascript, but these connections WILL NOT BE RAW TCP.
The complete spec can be found at http://dev.w3.org/html5/websockets/
jrh
EDIT: with specific reference to peer to peer connections, check out these links:
Regarding peer to peer connections: http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer
Regarding broadcast connections to the local network: http://www.w3.org/TR/2008/WD-html5-20080122/#broadcast
Regarding TCP connections (in the encoded protocol): http://www.w3.org/TR/2008/WD-html5-20080122/#tcp-connections
Complete proposed spec: http://www.w3.org/TR/2008/WD-html5-20080122/#network
Its important to note that the capabilities are still being negotiated. It will be nice to be able to create "local chat" web apps :)
jrh
UPDATE 10/17/2012: This functionality now exists in Chrome Stable v22. In order to use this functionality in Chrome, one must enable two flags in chrome://flags:
Enable MediaStream
Enable PeerConnection
Then you can visit the AppRTC Demo Page to try out the demo. See the WebRTC - Running the Demos page for more detailed instructions on setting up Chrome to use the peer to peer functionality and enabling device capture.
UPDATE: The engineers at Ericcson Labs have a proof of concept in a WebKit build that does HTML5 Peer to Peer Conversational Video.
They have demonstrations in their blog of the technology in action, as well as diagrams and explanations on how the technology will work.
They are working on getting this stabilized and committed to the WebKit repository.
Yes, finally.
As of this writing (2017), WebRTC is now a standard part of most modern browsers (around 70% of those in use), and allows for multimedia streaming, peer-to-peer, and hole-punching.
Docs, sample code, and live examples for WebRTC can be found at html5rocks.com.
According to caniuse.com and html5rocks.com, the following browsers support WebRTC:
Full support: Edge 14, Firefox 22, Firefox Android 55
Partial support: Android Browser 56, Chrome 20, Chrome Android 29, Edge 12, Firefox 17, Opera 18, Opera Android 20, Opera Mobile 12, UC Browser Android 11.4
Future support (Q3 2017): Chrome for iOS 11, Safari 11 for iOS 11 and OS X 10.11
No support: IE, IE Mobile, Opera Mini
The saturation rate of WebRTC is limited on Apple devices, since Safari 11 is not yet released and requires iOS 11 or OS X 10.11. Though projecting from past upgrade trends, WebRTC should be available on around 75% of iOS devices by 2018, and 100% by 2020.
There are a number of reasons why this would be tricky:
Firewalls (even just plain NATs) would make this kind of connection difficult at a much lower protocal layer than even HTTP. With my IT security hat on, this seems like a wonderful way to open arbitrary ports on a machine, just by visiting a website - and so it would be aggressively blocked by virtually all corporate IT systems.
HTTP is inherently a client-server protocol. While it is reasonably easy to simulate duplex communications using long polling (as well as a couple of other techniques), it is not particularly efficient.
This would open a large hole for XSS attacks.
WebSockets is designed to solve the second of these issues, but (deliberately, I expect) not the other two. When they talk about peer-to-peer in the HTML5 spec, they are talking about full duplex communications between the server and the client, not between one client and another.
However, it would be simple to implement a proper network stack on top of websockets - with the proviso that all communication would still have to be done through the server. I have seen this done using long polling (a friend of mine at Uni wrote a full TCP/IP stack using long polling).
I second harshath.jr: you could very well have a server acting as a directory (exposing "origins" of each connected agent; origin being scheme+host+port as in draft-abarth-origin, with the scheme being either "ws" or "wss"). You could then initiate peer-to-peer WebSocket connections; the SOP being worked through thanks to CORS. Of course, this means that each agent (i.e. browser) would have to embed its own WebSocket server (à la Opera Unite).
In the mean time, do it the XMPP/IRC/etc.-way: no peer-to-peer connection but WebSocket connections to a central server (or network!) to pass messages to the connected agents (eventually using some specific WebSocket "subprotocol")
EDIT: note that all of this is actually outside the scope of HTML5 (all of those things were once part of HTML5 but have been split away into their own specs)
The Whole idea of Web Sockets was to solve the problems with Firewalls and proxies http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket