2600hz is hosting a FreeSWITCH boot camp! Get in on the action to learn the ins and outs of FreeSWITCH! The FreeSWITCH Bootcamp is an intense three-day training, providing in-depth coverage of FreeSWITCH installation, configuration, maintenance and programming so that you can build your business. The bootcamp will be hosted in the brand new office in beautiful San Francisco. Go into the bootcamp as a Novice — and come out as a FreeSWITCH guru. Early bird pricing lasts until November 27th, but register now as there are limited spaces available! https://goo.gl/zbS4tP
Machine learning and artificial intelligence in messaging will become commonplace.
Who would have thought that the most personal and manual form of interaction between humans can be mechanized? Years a go, it started with presence and instant messaging. People found out ways to communicate other than the phone call. Today, messaging is so prevalent that you have to take it seriously:
What is interesting, is how artificial intelligence is starting to find a home in messaging apps – consumer or enterprise ones – and where this all is headed.
I couldn’t care less at this moment if the interface is textual or speech driven. I might cover this in a later article, but for now, let’s just assume this is the means to an end.
Here are a few examples of what artificial intelligence in messaging really means:
The Silent AdministratorYou are in a conversation with a friend. Chatting along, discussing that restaurant you want to go to. You end up deciding to meet there next week for lunch.
I do this once a month with my buddies from school. We meet for lunch together, talking about nothing and everything at the same time. For me, this conversation takes place on WhatsApp and ends up as an event on my Google Calendar.
Wouldn’t it be nice to have that event created auto-magically just because I’ve agreed with my friends on the date, time and place of this lunch?
This isn’t as far fetched as it seems – Google is already doing similar stuff in Google Now:
Google Now is currently connecting to apps on the phone through its Google Now on Tap, giving it smarts over a larger portion of our activities on our phones.
Why shouldn’t it connect to Hangouts or any other messaging service scouring it for action items to take for me? Be my trusted silent administrator in the back.
A few years ago, a startup here in Israel, whose name I fail to remember, tried doing something similar to the phone call – get you on a call, then serve ads based on what is being said. Ads here are supposed to be contextual and very relevant to what it is you are looking for. I think this is happening sans ads – by giving me directly what I need from my own conversations, the utility of these messaging services grows. With a billion users to tap to, this can be monetized in other means (such as revenue sharing with service providers that get promoted/used via conversations – booking an Uber taxi or a restaurant table should be the obvious examples).
In the enterprise space, the best example is the Slackbot, which can automate interactions on Slack for a user. No wonder they are beefing up their machine learning and data science teams around it.
Knowledge base ConnectivityThat “chat with us” button/widget that gets embedded into enterprise websites, connecting users with agents? Is it really meant to connect you to a live agent?
When you interact with a company through such a widget, you sometimes interact today with a bot. An automated type of an “answering machine” texting you back. It reduces the load on the live agents and enables greater scalability.
This bot isn’t only used to collect information – it can also be used to offer answers – by scouring the website for you, indexing and searching knowledge bases or from past interactions the live agent had with other users.
I recently did a seminar to a large company in the contact center space. There was a rather strong statement made there – that the IVR of the future will replace the human agents completely, offering people the answers and support they need. This is achieved by artificial intelligence. And in a way, is part of the future of messaging.
Speaking with BrandsIf you take the previous alternative and enhance it a bit, the future of messaging may lie with us talking to brands from it.
As messaging apps are becoming platforms, ones where brands and developers can connect to the user base and interact with them – we are bound to see this turning into yet another channel in our path towards omnichannel interactions with customers. The beauty of this channel is its ability to automate far better than all the rest – it is designed and built in a way that makes it easier to achieve.
Due to the need to scale this, brands will opt for automation – artificial intelligence used for these interactions, as opposed to putting “humans on the line”.
This can enable an airliner to sell their flight tickers through a messaging service and continue the conversation around that flight plans with the customer throughout the experience – all within the same context.
The Virtual Assistant / ConciergeSiri? Cortana? Facebook M? Google Search?
These are all geared towards answering a question. You voice your needs. And they go searching for an answer.
These virtual assistants, as well as many other such assistants cropping up from start ups, can find a home inside messaging platforms – this is where we chat and voice are requests anyway, so why not do these interactions there?
Today they are mostly separated as they come from the operating system vendors. For Facebook, though, Facebook M, their concierge service, Messenger is the tool of choice to deliver the service. It is easy to see how this gets wrapped into the largest messaging platforms as an additional capability – one that will grow and improve with time.
Why is this important?Artificial Intelligence is becoming cool again. Google just open sourced their machine learning project called TensorFlow. Three days go by, and Microsoft answers with an open source project of its own – DMTK (Microsoft Distributed Machine Learning Toolkit). Newspapers are experimenting with machine written news articles.
Messaging platforms have shown us the way both in the consumer market and in the enterprise. They are already integration decision engines and proactive components and bots. The next step is machine learning and from there the road to artificial intelligence in messaging isn’t a long one.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post The Role of Artificial Intelligence in Messaging appeared first on BlogGeek.me.
This week we had a number of features and a very important security fix listed below. It is highly recommended that you upgrade as soon as possible to avoid this vulnerability and you can find out more about the 1.6.5 release here. Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! This week we have Martin O’Shield from Windy City SDR! And head over to freeswitch.com to learn more about FreeSWITCH support.
Security issues:
A bug allowing for a remotely exploited DoS attack through custom crafted network traffic via JSON has been fixed. We classify this issue as High Severity. A patch was added by Anthony Minessale in commit 4bdca81 to resolve this issue. All versions from 1.4.4 through the previous release are vulnerable. We highly recommend updating to the current release version as soon as possible.
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7392
New features that were added:
Improvements in build system, cross platform support, and packaging:
The following bugs were squashed:
The FreeSWITCH 1.4 branch had this week’s previously mentioned security fix and a bug fix back ported as well as the release of 1.4.26. And again, keep in mind that 1.4 is quickly moving toward end of life and won’t be supported any longer except for high level security issues.
Why buy into legacy?
Last week, Cisco made another acquisition in the WebRTC space. This time, Cisco acquired Acano. Acano is a rather new company that started life in 2012 – close to WebRTC’s announcement.
Acano makes use of WebRTC, though I am not sure to what extent. There are 2 reasons Cisc lists for this acquisition:
To me, scalability comes from thinking of video conferencing in the mindset of WebRTC – WebRTC services are mostly cloud based and built to scale (or at least should be). Old video conferencing models thought at the scale of a single company at best, with business models fitting the high end of the market only.
That brings me to why. Why is Cisco buying into legacy here?
If there’s anything that is interesting these days it is what happens in the realm of messaging. And for Cisco, this should mean Enterprise Messaging. I already stated earlier this year that Enterprise Messaging is a threat to Unified Communications.
Don’t believe me? How about these interesting moves:
Which brings me back to the question.
Why buy into legacy? At scale. With interoperability. Using fresh technology. But legacy nonetheless.
Why not go after Slack and just acquire it outright?
When Cisco wanted a piece of video conferencing, they didn’t acquire RADVISION – its main supplier at the time. It went after TANDBERG – the market leader.
Then why this time not buy the market leader of enterprise messaging and just get on with it?
Congrats to the Acano team on being acquired.
For Cisco, though, I think the challenges lie elsewhere.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post For Cisco, Slack Would Have Been a Better Acquisition than Acano appeared first on BlogGeek.me.
The FreeSWITCH 1.6.5 release is here! This release contains everything since version 1.6.2. This is a pretty big release for the 1.6 branch so upgrading now is a really good idea. This is a routine maintenance and security release and the resources are located here:
Release files are located here:
Security issues:
A bug allowing for a remotely exploited DoS attack through custom crafted network traffic via cJSON has been fixed. We classify this issues as High Severity. A patch was added by Anthony Minessale in commit 4bdca81 to resolve this issue. All versions versions from 1.4.4 through the previous release are vulnerable. We highly recommend updating to the current release version as soon as possible.
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7392
New features that were added:
Improvements in build system, cross platform support, and packaging:
The following bugs were squashed:
The FreeSWITCH 1.4.26 release is here! This release contains everything since version 1.4.23. And this is a pretty big release and one of the final routine maintenance releases for the 1.4 branch so upgrading now is a really good idea.
The FreeSWITCH 1.4 branch is reaching end of life and the FreeSWITCH Team highly recommends beginning your migration to the 1.6 branch.
This is a routine maintenance and security release and the resources are located here:
Security issues:
A bug allowing for a remotely exploited DoS attack through custom crafted network traffic via cJSON has been fixed. We classify this issues as High Severity. A patch was added by Anthony Minessale in commit 4bdca81 to resolve this issue. All versions versions from 1.4.4 through the previous release are vulnerable. We highly recommend updating to the current release version as soon as possible.
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7392
Improvements in build system, cross platform support, and packaging:
The following bugs were squashed:
ORTC, WebRTC, H.264, VP8, RID, RtpEncoding, Simulcast and much more. Google, Microsoft and Hookflash leading the discussion, join us!
http://ortc.org/2015/11/04/w3c-ortc-cg-meeting-10-november-20-2015/
Testing WebRTC is tricky.
If there’s something I learned this past year from talking to companies when showcasing the testRTC service, is that vendors don’t really test their WebRTC products.
Not all of them don’t test, but most of them.
Why is that? Here are a few reasons that I think explain it.
#1 – WebRTC is a niche for them – an experimentYou’ve got a business to run. It does something. And then someone decided to add communications to it. With WebRTC no less.
So you let them play. It isn’t much of an effort anyway. Just a few engineers hammering away. Once you launch, you think, you’ll see adoption and then decide if it is worthwhile to upgrade it from a hobby to a full time business.
The thing is, there’s a chicken and egg thing going on here. If you don’t do it properly, how will adoption really look? Will it give you the KPIs you need to make a reasonable decision?
WebRTC is rather new. As an industry, we still don’t have best practices of how to develop, test and deploy such services.
#2 – It’s a startup. Features get priority over stabilityMany of the vendors using WebRTC out there are startups. They need to get a product out the door.
It can be a proof of concept, a demo, an alpha version, a beta one or a production version. In all cases, there’s a lot of pressure to cram more features into the product and show its capabilities than there are complaints about its stability or bugs.
Once these companies start seeing customers, they tend to lean more towards stability – and testing.
As we are seeing ourselves by running testRTC (=startup), there’s always a balancing act you need to do between features and stability.
#3 – They just don’t know howHow do you test WebRTC anyway?
VoIP?If you view it as a VoIP technology, then you are bound to fail – the VoIP testing tools out there don’t really have the mentality and mindset to help you:
The flexibility and fast paced nature of the web and WebRTC aren’t ingrained into their DNA.
Web?If you view this as a web technology, then you’ll miss all the real time and media aspects of it. The web testing tools are more interested in GUI variability across browsers than they are with latencies and packet loss.
While web tools are great for testing web apps, they don’t fit the VoIP nature that exist in WebRTC.
#4 – They don’t have the toolsYou know, if you wanted to test WebRTC a year or two ago, your best alternative was to use QA teams that click manually on buttons – or build your own test infrastructure for it.
Both alternatives are wasteful in resources and time.
So people sidestepped the issue and waited.
These days, there are a few sporadic tools that can test WebRTC – changing the picture for those who want to be serious about testing their service.
Don’t take WebRTC testing lightlyI just did a webinar with Upperside Conferences. If you want to listen in on the recording, you can register to it online.
Whatever your decision ends up being – using testRTC or not – please don’t take testing WebRTC implementations lightly.
The post 4 Reasons Vendors Neglect Testing WebRTC Services appeared first on BlogGeek.me.
One OS to rule them all?
It seems like Apple has decided to leave its devices split between two operating systems – Mac and iOS. If you are to believe Tim Cook’s statement, that is. More specifically, MacBook (=laptop) and iPad (=tablet) are separate devices in the eyes of Apple.
This is a strong statement considering current market trends and Apple’s own moves.
The iPad ProApple’s latest iPad Pro is a 12.9 inch device. That isn’t that far from my Lenovo Yoga 2 Pro with its 13.1 inch. And it has an optional keyboard.
How far is this device from a laptop? Does it compete head to head in the laptop category?
Assuming a developer wants to build a business application for Apple owners. One that requires content creation (i.e – a real keyboard). Should he be writing it for the Mac or for iOS?
Tim Cook may say there’s no such intent, but the lines between Apple’s own devices are blurring. Where does one operating system ends and the other begins is up for interpretation from now on. One which will change with time and customer feedback.
Apple had no real intent of releasing larger iPhones or smaller iPads. It ended up doing both.
Microsoft Windows 10Windows 10 is supposed to be an all-encompassing operating system.
You write your app for it, and it miraculously fits smartphones, tablets, laptops and PCs. That’s at least the intent – haven’t seen much feedback on it yet.
And I am not even mentioning the Surface Tablet/Laptop combo.
Google Chrome OS / AndroidGoogle has its own two operating systems – Android and Chrome OS. Last month Alistair Barr informed of plans in Google to merge the two operating systems together.
The idea does have merit. Why invest twice in two places? Google needs to maintain and support two operating systems, while developers need to decide to which to build their app – or to develop for both.
Taking this further, Google could attempt making Android apps available inside Chrome browsers, opening them up to even a larger ecosystem not relying only on their own OS footprint. Angular and Material Design are initiatives of putting apps in the web. A new initiative might be interpreting Android’s Java bytecode in Chrome OS, and later in Chrome itself.
Who to believe?On one hand, both Microsoft and Android are consolidating their operating systems. On the other, Apple doesn’t play by the same rule book. Same as we’ve seen lately in analytics.
I wonder who which approach would win in the end – a single operating system to rule them all, or multiple based on the device type.
The post Can Apple Succeed with Two Operating Systems When Google and Microsoft are Consolidating? appeared first on BlogGeek.me.
This week the FreeSWITCH team added a built in bandwidth test to the verto communicator and a calculated RTT value to help with detecting congested network links. This week we have David Taht joining us on the ClueCon weekly call to talk about FCC firmware policies. Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! And head over to freeswitch.com to learn more about FreeSWITCH support.
New features that were added:
Improvements in build system, cross platform support, and packaging:
The following bugs were squashed:
The FreeSWITCH 1.4 branch had a bug fix added this week.
The following bugs were squashed:
The Accounts Manager App is a dynamic web portal providing multi-tenant functionality for worry-free scaling. Manage all of your accounts, and provide granular control to ensure customers have an enjoyable experience. Set limits for trunks, create call restrictions and manage credit balances – all within the App.
The Accounts Manager App has consolidated customer relationship management within a single User Interface. Accounts can be set up remotely, enabling you to sell across the continental United States. You no longer need to worry about logging into separate systems or figure out what client is on which platform.
What Accounts Manager Provides
Unified and Intuitive Interface
Add and edit new accounts and sub-accounts, monitor customers, select a carrier strategy, maintain service plans and restrictions - in one interface.
Simplifying Account Set-Up
Set up accounts for all of your customers. Create business account names, add the admin contact or manage the account yourself.
Set Limits and Create Call Restrictions
Create and set limits for your customers that include inbound, outbound, and two-way trunks. Set up call restrictions based on tolls, location, Emergency Dispatcher, and manage your customer’s credit balance.
Manage Permissions
Manage what your clients can and can’t view. This includes user and account settings, billing options, inbound and outbound trunking, and UI errors.
A long, boring straight line.
In some ways, WebRTC now feels like a decade ago, when every time we said “next year will be the year of video”. For WebRTC? Next year will be the year of adoption.
Adoption is hard to define though. What does it really means when it comes to WebRTC?
WebRTC has been picked up by carriers (AT&T, Comcast and others if you care about name dropping), most (all?) video conferencing and unified communication vendors, education, banking and healthcare industries, contact centers.
While all is well in the world of WebRTC, there is no hype. A year and a half ago I wrote about it – the fact that there is no hype in WebRTC. It still holds true. Too true. And too steadily.
The chart below is a collection of 2 years of data of some of the data points I follow with WebRTC. I hand picked here 4 of them:
In all of these cases (as well as other metrics I collect and follow), the trend is very stable. There’s growth, but that growth is linear in nature.
There are two minor areas worth mentioning:
Some believe that the addition of Microsoft Edge will change the picture. Statistics of Edge adoption and the statistics I’ve collected in the past two months show no such signs. If anything, I believe most still ignore Microsoft Edge.
Where does that put us?Don’t be discouraged. This situation isn’t really bad. 2015 has been a great year for WebRTC. We’ve seen public announcements coming from larger vendors (call it adoption) as well as the addition of Microsoft into this game.
Will 2016 be any different? Will it be the breakout year? The year of WebRTC?
I doubt it. And not because WebRTC won’t happen. It already is. We just don’t talk that much about it.
If you are a developer, all this should be great news for you – there aren’t many others in this space yet, so demand versus supply of experienced WebRTC developers favors developers at the moment – go hone your skill. Make yourself more valuable to potential employers.
If you are a vendor, then find the most experienced team you can and hold on to them – they are your main advantage in the next years when it comes to outperforming your competitors when it comes to building a solid service.
We’re not in a hyped up industry as Internet of Things or Big Data – but we sure make great experiences.
The post WebRTC Demand isn’t Exponentially Growing appeared first on BlogGeek.me.
There’s a new home for the WebRTC Data Channel – it found its use lately in context.
Ever since WebRTC was announced, I’ve been watching the data channel closely – looking to see what developers end up doing with it. There are many interesting use cases out there, but for the most part, it is still early days to decide where this is headed. In the last couple of weeks though, I’ve seen more and more evidence that there’s one place where the WebRTC Data Channel is being used – a lot more than I’d expect. That place is in adding context to a voice or video call.
Where did my skepticism come from?
Look at this diagram, depicting a simplified contact center using WebRTC:
We have a customer interacting with an agent, and there are almost always two servers involved:
The logic here is that the connection to the web server should suffice to provide context – why go through all the trouble of opening up a data channel here? For some reason though, I’ve seen evidence that many are adopting the data channel to pass context in such scenarios – and they are terminating it in their server side and not passing it direct between the browsers.
The question then is why? Why invest in yet another connection?
#1 – LatencyIf you do need to go from browser to browser, then why make the additional leg through the signaling server?
Going direct reduces the latency, and while it might not be much of an issue, there are use cases when this is going to be important. When the type of context we are passing is collaboration related, such as sharing mouse movements or whiteboarding activity – then we would like to have it shared as soon as possible.
#2 – FirewallsWe might not want to go through the signaling server for the type of data we wish to share as context. If this is the case, then the need to muck around with yet another separate server to handle a Websocket connection might be somewhat tedious and out of context. Having the WebRTC data channel part of the peer connection object, created and torn down at the same time can be easier to manage.
It also has built in NAT and Firewall traversal mechanisms in place, so if the call passes – so will the context – no need to engineer, configure and test another system for it.
#3 – AsymmetryAt times, not both sides of the session are going to use WebRTC. The agent may as well sit on a PSTN phone looking at the CRM screen on his monitor, or have the session gateway into a SIP network, where the call is received.
In such cases, the media server will be a gateway – a device that translates signaling and media from one end to the other, bridging the two worlds. If we break that apart and place our context in a separate Websocket, then we have one more server to handle and one more protocol to gateway and translate. Doing it all in the gateway that already handles the translation of the media makes more sense for many use cases.
#4 – Load ManagementThat web server doing signaling? You need it to manage all sessions in the system. It probably holds all text chats, active calls, incoming calls waiting in the IVR queue, etc.
If the context we have to pass is just some log in information and a URL, then this is a non-issue. But what if we need to pass things like screenshots, images or files? These eat up bandwidth and clog a server that needs to deal with other things. Trying to scale and load balance servers with workloads that aren’t uniform is harder than scaling uniform work loads.
#5 – Because We CanLet’s face it – WebRTC is a new toy. And the data channel in WebRTC is our new shiny object. Why not use it? Developers like shiny new toys…
The Humble WebRTC Data ChannelThe data channel has been around as long as WebRTC, but it hasn’t got the same love and attention. There’s very little done with it today. This new home it found with passing context of sessions is an interesting development.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post WebRTC Data Channel find a home in Context appeared first on BlogGeek.me.
This week the FreeSWITCH team added support for early media with a 180 to mod_sofia and continued the expansion of mod_hiredis limit functionality. This week we have Justin Grow from Flowroute joining us on the ClueCon weekly call. He will be talking about Flowroute APIs and configuring FreeSWITCH to work with Flowroute.
Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! And head over to freeswitch.com to learn more about FreeSWITCH support.
New features that were added:
The following bugs were squashed:
The FreeSWITCH 1.4 branch had a bug fix added this week.
The following bugs were squashed:
A few use cases where WebRTC can be found in gaming.
When WebRTC first came out, everyone were in frenzy trying to figure out which verticals will end up using WebRTC. One of the verticals that keeps popping up, but never sticking around for long is gaming.
When discussing WebRTC and gaming, there’s more than a single use case – there are a few dominant one; and I wanted to share them here this time.
#1 – Social GamesRemember Cube Slam? Google’s first demo of WebRTC, where you can play a game with someone else and see him on the other side?
That was a demo. Jocly Games is the best example I have. Jocly Games offer turn by turn board games where your opponent is another player somewhere. If you wish, you can see each other during the game by the help of WebRTC. I’ve interviewed Michel Gutierrez, the CEO of Jocly Games two years ago.
Roll20 does a similar thing for multiplayer RPG games.
#2 – Motion SensorWhile I haven’t seen any serious game using this, the fact that you can get a camera feed into a game means you can track movement. And if you can track movement – you can use it to control something.
How about a game of Snake?
#3 – Multiplayer GamingMultiplayer games require synchronization between players. The better the connection the more responsive the game. And where latency is important, there’s room for WebRTC’s data channel.
Two and a half years ago, Mozilla released a proof of concept of sorts. Its own WebRTC demo, focused on the data channel. It was a game called BananaBread. It is a first person shooter where the players communicate their positions and actions directly with each other using the data channel.
This year, I reviewed a book about multiplayer game development in HTML5. While the WebRTC part of it was skinny compared to the rest, it did mention its capability.
In the wild, I haven’t seen any evidence of this being used a lot. I assume it is due to the relative complexity of implementing it and taking care of cases where some players can’t use the data channel or must relay it via TURN servers.
#4 – Controller and DisplayThis is something I haven’t seen up until recently, and now I’ve seen it several times in the same month.
AirConsole uses this technique. To some extent, Ericsson’s Remote Excavation demo takes the same approach.
The idea is one device holds the controls over the other. In our case, a game controller and the PC/console running the game (on a browser of course). Once the two pair up using a WebRTC data channel, the latency involved in passing commands from the controller to the device are minimized.
What am I missing?4 different typical use cases. None used in any popular game. None considered “best practices” or common approaches to game development.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post Is there any Room for WebRTC in Gaming? appeared first on BlogGeek.me.
There has been more noise about WebRTC making it possible to track users. We have covered some of the nefarious uses of WebRTC and look out for it before. After reading a blog post on this topic covering some allegedly new unaddressed issues a week ago I decided to ignore it after some discussion on the mozilla IRC channel. But this has some up on a the twitter-sphere again and Tsahi said ‘ouch’, here are my thoughts.
ClaimsThe blog post (available here) makes a number of claims about how certain Chrome behavior makes fingerprinting easier:
First, there is a claim that the way Chrome caches certificates changed recently:
In the past, Google Chrome used to generate a new self-signed certificate for every WebRTC PeerConnection. But now (using Chrome 46, or maybe earlier as i did not check) it generates a self-signed certificate which is valid for one month and uses it for all PeerConnections of a particular domain.
The code used to demonstrate this behaviour is rather odd, too. It uses the getStats API to the query the fingerprint, which is also available more easily in the SDP.
Chrome has cached certificates in this way for about two years, this is not real news. One of the reasons for this is that it is rather expensive to generate the current private keys for DTLS, especially on mobile devices. In the future, there will be more control over this behaviour. Neither Firefox nor Edge currently cache certificates.
To be fair, the WebRTC team made a serious blunder here. Until Chrome 45, the certificate was not cleared when cookies were cleared, only when all data was cleared. The bugfix for this only appeared in the Chrome 47 release notes:
Issue 510850 DTLS cert should be cleared when cookies are cleared
Cross-Origin TrackingSo this part is not really news. The second claim made in the blog post is that this enables cross-origin tracking:
To test this go to http://www.kapejod.org/tracking/test.html and to http://kapejod.org/tracking/test.html. Open the network tab of Chrome’s developer console and compare the urls of the requested “tracking.png”. They should contain the same fingerprint, now!
They do. Now, let’s look at this test page:
// make up some random id var transactionId = 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {var r = Math.random()*16|0,v=c=='x'?r:r&0x3|0x8;return v.toString(16);}); var fragment = document.createDocumentFragment(); var div = document.createElement("DIV"); div.innerHTML = '<iframe src="http://kapejod.org/tracking/identify.html?'+transactionId+'" width="1" height="1" style="display:none;"/>'; fragment.appendChild(div); document.body.insertBefore(fragment, document.body.childNodes[document.body.childNodes.length - 1]);It includes the URL http://kapejod.org/tracking/identify.html. Let’s also look at the code there as well. It executes the code shown above and logs the fingerprint to the console:
console.log('your fingerprint is: ' + fingerprint);Now why is the fingerprint the same? Well, the iframe is always included from kapejod.org. Which means the Javascript is executed within the context of this origin.
So Chrome can use the persisted fingerprint. As well as any cookies and localStorage data. The attack surface here is no worse than setting a cookie.
Another thing related to this (and I am surprised this has not yet been mentioned) are the deviceIds returned by navigator.mediaDevices.enumerateDevices. Those are also persisted with the same lifetime as cookies. The W3C mediacapture specification has a paragraph about security and privacy considerations on this:
The identifiers for the devices are designed to not be useful for a fingerprint that can track the user between origins, but the number of devices adds to the fingerprint surface. It recommends to treat the per-origin persistent identifier deviceId as other persistent storages (e.g. cookies) are treated.
Again, WebRTC and other HTML5 techniques increase the fingerprint surface. But by design, this is not worse than cookies or equivalent techniques like localStorage.
Incognito ModeLast but not least the blog post makes claims about the incognito mode:
But to make it generate a new one you have to close ALL incognito tabs. Otherwise you can be tracked across multiple domains.
Again, this behaviour is consistent with the incognito mode behaviour for things like localStorage. In both Chrome and Firefox. In incognito mode, open a site, set something in localStorage. Open another tab. Close first tab. Navigate to same site. Check localStorage. Boo!
tl;drThere is no real news here. In Germany, we call this ‘olle kamellen’.
{“author”: “Philipp Hancke“}
Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates and news of technical WebRTC topics or our individual feeds @chadwallacehart, @victorpascual and @tsahil.
The post OMG WebRTC is tracking me! Or is it? appeared first on webrtcHacks.
Announcing an upcoming free webinar on the challenges of WebRTC testing.
This week I took a trip to San Francisco, where the main goal was to attend WebRTC Summit and talk there about the challenges of WebRTC testing. This was part of the marketing effort we’re placing at testRTC. It is a company I co-founded with a few colleagues alongside my consulting business.
During the past year, we’ve gained a lot of interesting insights regarding the current state of testing in the WebRTC ecosystem. Which made for good presentation material. The session at the WebRTC Summit went rather well with a lot of positive feedback. One such comment made was this one that I received by email later during that day:
I liked much your presentation which indeed digs into one of the most relevant problems of WebRTC applications, which is not generally discussed in conferences.
My own favorite, is what you can see in the image I added above – many of the vendors our there just don’t make the effort to test their WebRTC implementations properly – not even when they go to production.
I’ve identified 5 main challenges that are facing WebRTC service developers:
The slides from my session are here below:
Overcoming the Challenges in Testing WebRTC Services from Tsahi Levent-levi
That said, two weeks from now, I will be hosting a webinar with the assistance of Amir Zmora on this same topic. While some of the content may change, most of it will still be there. If you are interested, be sure to join us online at no cost. To make things easier for you, there are two sessions, to fit any timezone.
When? Wednesday, November 18
Session 1: 8 AM GMT, 9 AM CET, 5 PM Tokyo
Session 2: 4 PM GMT, 11 AM EDT, 8 AM PDT
Test and Monitor your WebRTC Service like a pro - check out how testRTC can improve your service' stability and performance.
The post WebRTC Testing Challenges: An Upcoming Webinar and a Recent Session appeared first on BlogGeek.me.
Phosfluorescently utilize future-proof scenarios whereas timely leadership skills. Seamlessly administrate maintainable quality vectors whereas proactive mindshare.
Dramatically plagiarize visionary internal or "organic" sources via process-centric. Compellingly exploit worldwide communities for high standards in growth strategies.
Wow, this most certainly is a great a theme.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.