The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or click here to continue anyway

Surfly Technology Surfly Documentation

Surfly Technology

This chapter is dedicated to explaining how Surfly works compared to other solutions, as well as creating a better understanding of our co-browsing software. This will make it easier to implement our API and understand the code.

Co-browsing vs. Screen-sharing

There are countless co-browsing and screen-sharing solutions on offer. Sometimes it is not immediately clear what the differences are between them. First of all, let's filter down to the distinction between co-browsing and screen-sharing.

Unlike co-browsing, screen-sharing does not limit itself to the web browser. With a screen-sharing solution you are able to share your complete desktop. There are some benefits to this, but from a security perspective it's not the safest solution. Would you feel comfortable giving others access to your computer? So there's a bond of trust that needs to exist between users.

Also, screen-sharing solutions are pixel-based, which means that the controller constantly takes snapshots of the screen and then sends these to the other side in compressed form. The drawback of this approach is that screen updates are slow and of low quality.

What most screen-sharing and co-browsing solutions, other than Surfly, have in common, is that both rely on external software that needs to be installed by both users. This makes it unsuitable for most web situations as people are often unwilling to install extra software that circumvents the browser's security measures.

Javascript solutions

With Javascript based solutions, a widget is created in which the Javascript of the original page is being loaded. This process requires a lot of bandwith since requests from the user in control continuously need to be sent to the website, then to the co-browsing solution, then back to the controlling user as well as the followers.

There are also many limitations to this approach. One major issue is that the iframes loaded from another domain have a different Javascript scope. This means that, because of the cross domain policies, these iframes can't be controlled by the Javascript that the co-browsing solution sends over to the users. Second, audio and video are usually not synchronized. Furthermore, it is unsafe to handle logged-in sessions, as they are usually only possible if login credentials are sent to the followers; otherwise the followers do not have access to session-specific data.

Co-browsing with Surfly

Surfly distinguishes itself by using a unique combination of Javascript and a smart content rewriting proxy. This is how it works:

This approach enables us to overcome cross-domain policies and have all elements on the site (including iframes) function correctly within the co-browsing session. This means that audio and video are synced as well. In addition, all visual updates can be efficiently captured. The proxy approach also allows us to provide both the user and the agent with a very smooth co-browsing experience that is much faster than other solutions.

In comparison:
JS Based Co-Browsing Surfly Pixel Based Co-Browsing ScreenSharing High Quality No setup required Works with iFrames No Installation or Extension Required Can be Integrated in Existing WebApp Works with legacy web technology (activex, flash) Can share your desktop

How the session works

Now it's time to start implementing Surfly. This can be done in three ways:

How you choose to implement our API depends on how deeply you want to integrate it into your website and your workflows. In sales for instance, you might want to use Surfly to demo your website or product and make this a more captivating and interactive experience for all users. This could already be done through an integration with the admin panel or a basic Javascript implementation.

In support, you might want to co-browse together with your client to guide them through the website, and create designs together or help them fill in forms. For the latter you might have to deal with sensitive information, so Surfly provides the option of limiting co-browsing to certain pages on your website, or to mask data in form fields for other users.

You could also integrate Surfly into your already implemented helpdesk software using the REST API. You might want to add your client's location to the queue based on their IP-address for instance, so that your helpdesk agents have some background info when they join them in a Surfly session.

Surfly could also be used for educational purposes, as a lot of learning platforms use our API to create an online class room. Or maybe you would like to add Surfly as a social tool to your website to allow your users to shop together.

Surfly can be integrated in many ways, together with other software solutions. Our API is completely rebrandable according to your wishes, and it can even be made into a fully transparent layer that lays on top of your website. But most importantly, for us, safety comes first, so all Surfly sessions are HTTPS secured. Also, we even offer the option of installing the servers for you on premise.

Basic requirements

On-premise hardware requirements

The maximum number of concurrent sessions will depend on the provided hardware and the type of usage.

Required production (virtual) hardware
System requirements
Setup requirements

Continue reading on