Surfly - Surf together on the web | Hacker News Reader

Surfly - Surf together on the web

surfly.com

55 pointsspreeker39 comments

Surfly.com is not easy to use outside of a mobile device or tablet (anything without swipe navigation).

You seem to be acting as a proxy and so I am sending all my passwords to your site so you login on my behalf.

I guess the better approach would have been to load the website on client end and only send the DOM to your server OR the other client directly.

We've considered that, but if you want to share everything that is being shown, you will also need be able to have access to that as well.

If you do it purely through some sort of script include, you will not be able to hook into 3rd party widgets for example and there are more things that are problematic.

Yes, I understand there would be issues on sending passworded resources that are linked within the page. In my case, you would have to recursively send all the resources of the current page to the other client.

Good work though!

Also, because you are acting like a proxy AJAX based DOMs seem to cause errors?

We take this into account, we sandbox the website in such a way that AJAX request will work properly.

Sweet! I'm loving this site.

This is a really good idea, personally it may come in use when working next to someone and they want to copy some code or help you've just located for them. Save sending them the url, and in google hangouts/traditional screenshare the spectator is unable to interact with the webpage (highlight/copy content).

Not just that, the quality of screensharing is much lower than the quality you get with Surfly. You can see a comparison here: http://www.surfly.com/blog/2013/11/05/google-helpouts---even...

The example you give is exactly how we use it ourselves to plan milestones and review code with remote workers. Read more here: http://www.surfly.com/blog/2013/10/31/using-surfly-for-remot...

Looks just like the open source togetherJS by mozilla.

https://togetherjs.com/

It's more similar to an experiment that preceded TogetherJS, Browser Mirror: https://github.com/mozilla/browsermirror

In TogetherJS both people are basically browsing like normal, but it communicates what's going on between the people (so for example you can see the other person's mouse), and synchronizes select things like forms. With the model of Surfly and Browser Mirror, one browser is the source, and the other is viewing what that other browser does. Everything "happens" on the source browser. This is in a session like this both people are logged in as the same person and seeing exactly the same thing, while with TogetherJS each person is logged in as themselves.

The difference is that with TogetherJS you will not be able to handle websites that require login. Surfly can handle that in a secure way.

Next, Surfly just works on any website - without the need to write a single line of code. For example, you can use it right now on GitHub. If you wanted to have such functionality with TogetherJS you would have to modify your website accordingly (i.e., by using a special version of the Ace editor).

So how exactly do you handle sites that require logins?

Only the controller fires the HTTP requests. The viewer just gets DOM updates, so cookie's (session secrets) or password will never be send to the follower.

I do not quite understand, sorry. I am concerned about security.

Why am I allowed to login into say, Trello.com, while I am on surfly.com domain? Shouldn't my browser's cross-domain security policy prohibit this practice?

Is it all being done through a proxy? If so, is it not true that a lot of sites don't work over proxy?

[Edit] And if it is indeed proxy, doesn't that mean you can read my password(s) in clear text?

The proxy is needed to make sure that we can modify the content in such a way that it works correctly during the session. We sandbox the site so that everything keeps works correctly. I'll go deeper into this in a blog post soon.

The connection to the proxy is encrypted and if the site you login also uses https, your password will never be send in clear text over the wire. Since form submissions are not actually replayed on the viewer's side, we only keep them for the time of the request and only in memory. For those companies who want to control the security fully we are working on a on a solution that can be installed on-premise.

TogetherJS works on any website too! Just grab a Firefox addon (https://togetherjs.com/togetherjs.xpi) or Chrome extension (https://chrome.google.com/webstore/detail/towtruckcrx/hpobkk...)

Yes, but you can't send your friend the surfly link. You have to ask your friend to also install the addon before you can collaborate on the same website. Extensions are cool, but not practical in the real world scenario.

First impression before I saw the video was "Oh no, haven't this been tried before". But 2 seconds in, I love the idea. This can be perfect for client product training sessions.

this is pretty cool! will be really cool for support/webinars.

I also understand its an early product, because on the spectator's screen, the HTML does not seem to be rendered properly.

With that said, (and as much as i hate to do feature requests), please allow us to speak via the mic. cheers!

This reminds me of a blog post I wrote a year ago about proxy technology:

http://www.deanmao.com/2012/08/28/modify-a-site-you-dont-own...

I did it the same way -- parse & rewrite js code, and have a server that stores the same cookies that your browser would. The browser js code also contains the same js rewriter so that it can handle stuff like eval(). It also had to do lots of header manipulation since there are lots of headers that have domain-name based security, like CORS for example. The one I wrote works great with js-heavy sites like gmail or facebook.

What would be really useful is that if it would, somehow, support sites behind a firewall or a VPN.

The service could work locally, with perhaps only the interactive events synced across the clients. As far as I see it, everything passes through the surfly servers, so I'd be reluctant to "surf together" on any sites that require logins.

Just thought it's funny that my startup's name and color scheme are so similar, despite the fact that the products are not even remotely related: http://www.survly.com/

https://twitter.com/HackerNewsOnion/status/39753991050192486...

OP how do you deal with mobile/non-responsive websites? specially when the functionality of the mobile version is considerably limited from the full desktop one.

We send over the state of the DOM of the person who presents to the person that follows. So the guy that follows the session will see the same thing as the guy that controls it. We also synchronise the viewport fe, so if the controller resizes the window and the site adjusts accordingly the follower will see the exact same thing.

We don't have every corner case covered yet - but we're working on it.

It breaks my site. Dropdowns don't work. And, when logging in, it grabbed the input and threw the username and password into the url.

How is this different from https://togetherjs.com/?

I've answered this already somewhere below.

But the biggest difference is the use case, you would use TogetherJS to add collaboration on your site by writing a bit of code. You would Surfly to share your web session with someone else (no need to code, works on any website), use it to explain things, demonstrate your app or give remote product demo's.

Would be great for demos, but unfortunately it doesn't work with the canvas element on my website hashtagify.me

Thanks for reporting, we just looked at your site and saw a different issue causing this problem, we'll push out a fix somewhere tomorrow. This fixes your pretty hashtag cloud.

Great, I'll try your service instead of desktop sharing the next time I'll have to show the service to some user. Thx

Unfortunately doesn't work with our site: www.peecho.com

Thanks for reporting, we'll look into it.

"Scroll to see more" - Fine.. lets press "Page down"... Hm... nothings happens...