Online Shop Till You Drop With Your Friends On Plurchase(techcrunch.com)
techcrunch.com
Online Shop Till You Drop With Your Friends On Plurchase
http://www.techcrunch.com/2009/10/09/online-shop-til-you-drop-with-your-friends-on-plurchase/
22 comments
It's like being stuck in a shoe store with your wife and her female friends. Forever.
Haha! Thanks. I've lost count of the number of times I've heard: I'll check it out, but I'm not telling my wife about it..
Do you guys plan to also have integration within facebook .... like update the newsfeed, mini-feed etc like Facebook Connect Site ?
We do already. Sadly we need ways for people to find the interface. It's hard when Amazon takes up 90% of the screen, so all of our interface things are not easy to find.
Lol, ahhh, I almost feel out of my chair after reading this.
I think you should make plurchase completely public, so that I can see everyone (and they can see me). That way, I don't have to invite my friends to shop + I can spy on other people (making it fun even when none of my friends are online).
We plan on supporting both public & private. Mostly just UI work to add the public functionality. One idea: when in a public shopping group/room, we'd replace the little preview boxes with a stream of just-product-pages as people visit them.
you can also keep track of how people browse the site from page to page, etc. and draw lots of good stats. e.g. similar to amazon's "people who bought these also bought..." or "people who viewed this ultimately bought..." but globally across multiple sites
Yeah, we can have all kinds of fun things once we have a few thousand daily users. We could do stuff like: pair you with other camera shoppers if you're interested in cameras specifically, allow you to help other people shop for specific things (personal shopper), find out what people ultimately purchased when they looked at your current product, what other stores users visited when looking at the current product, etc
[deleted]
[deleted]
I noticed that they are using CDN from day one. What's the rational behind it? How much complexity the CDN integration adds to the code and procedures? Is the number of images they load an important factor here? I think they are loading only few images of their own. (I'm not criticizing, just asking).
Actually, I was just bored. I meant to take it out but forgot about it... I was trying to get a high score in YSlow ;-).
If you look into the CSS, it still references the non-CDN images and Safari is actually somewhat stupid -- it loads both sets of images even if the CDN images override it. The homepage actually loads slower with the CDN images (but I get a higher score on YSlow :-P )
If you look into the CSS, it still references the non-CDN images and Safari is actually somewhat stupid -- it loads both sets of images even if the CDN images override it. The homepage actually loads slower with the CDN images (but I get a higher score on YSlow :-P )
Isn't that borderline phishing, Seriously? I'm thinking about a naive visitor, who doesn't have an account with Plurchase. If s/he now tries to login to Zappos, Plurchase sees and handles her/his username & password. This is a simple man-in-the-middle attack.
It is somewhat man-in-the-middle, but not much different than your browser-side plugins... some browser side plugins load external javascript into your webpages so it wouldn't be significantly different. Wesabe.com (personal finance site like Mint) allows you to enter in your financial data directly into their system, and also provides a firefox plugin that will fetch that financial data should you be worried about Wesabe's security. However, few people have used their firefox plugin for doing it.
There is a huge difference. I'm not bothered one little bit about logged-in / opt-in users or those who chose to install a plug in. My concern is specifically with a visitor who did not register and have no clue of what's going on.
I'm not sure I understand here... plurchase is similar. You have to visit our site to shop on amazon or related store.
I'm afraid merchants won't like this idea at all. Their domain name is hidden. Users bookmark plurchase instead of the merchant's site and there are endless opportunities to implement comparison shopping on top of it. I also wonder about SSL and certificates once it's checkout time.
This looks like an endless legal and technological battle against merchants. I'll be very intersted in the outcome because obviously wrapping sites via a proxy is a powerful technique for many things.
This looks like an endless legal and technological battle against merchants. I'll be very intersted in the outcome because obviously wrapping sites via a proxy is a powerful technique for many things.
If a merchant doesn't want to be on our site, all they have to do is ask and we'll remove them.
The merchant is our friend. We bring them customers and sales. We avoid the things they hate, like linking customers away to another site. We also have some future features in mind that they'll really like.
We're also willing to let them run plurchase on their own servers, and in the future, will offer white-label functionality.
The merchant is our friend. We bring them customers and sales. We avoid the things they hate, like linking customers away to another site. We also have some future features in mind that they'll really like.
We're also willing to let them run plurchase on their own servers, and in the future, will offer white-label functionality.
I'm having difficulty seeing the value in this idea. It seems that Plurchase is going to be relying heavily on retailers to make this idea succeed. But, if I'm Zappos, Amazon, or any other online retailer, I don't want Plurchase -- or any other service -- hijacking my website via their own proxy, for any reason, and/or redefining my customer's experiences in any way.
And when the Plurchase team approaches online retailers and gives them ten reasons why allowing Plurchase to do this will ultimately help the retailer make more money, they are going to be met with a wall of skepticism, and rightly so.
It's always easy to rationalize how your ideas (that primarily benefit you) will benefit others too, but actually getting other people to agree with your passion and sign on with your business model is an entirely different story.
My 2 cents!
And when the Plurchase team approaches online retailers and gives them ten reasons why allowing Plurchase to do this will ultimately help the retailer make more money, they are going to be met with a wall of skepticism, and rightly so.
It's always easy to rationalize how your ideas (that primarily benefit you) will benefit others too, but actually getting other people to agree with your passion and sign on with your business model is an entirely different story.
My 2 cents!
I'm not too sure of the technology that goes on behind your proxy but I just had an issue connecting to the server from behind my corporate firewall. Is this something you guys plan on tackling?
I think a lot of people shop online at work and many of those are behind firewalls. A quick online search threw numbers at me like 50% and scaling upwards to like 75% as you get into the "facebook generation."
Btw, great product. I also love how when I tried to test if it was a browser issue and loaded up IE that it notified me that my browser was "too old."
I think a lot of people shop online at work and many of those are behind firewalls. A quick online search threw numbers at me like 50% and scaling upwards to like 75% as you get into the "facebook generation."
Btw, great product. I also love how when I tried to test if it was a browser issue and loaded up IE that it notified me that my browser was "too old."
I don't know why it wouldn't work behind a firewall though -- everything goes through port 80. I use it behind a firewall too. Maybe your corporate firewall does more than just firewall packets, does it block sites with questionable content as well?
Probably. Maybe just me though? Anyone else?
I mean plurchase loads, just unable to connect to the server. So the tools worked but the social networking did not.
I mean plurchase loads, just unable to connect to the server. So the tools worked but the social networking did not.
The blog (http://blog.plurchase.com/) contains a few frequently asked questions about tech, etc
The tech is probably harder than it looks on the surface.
The tech is probably harder than it looks on the surface.
Have you guys talked with a lawyer yet? You're building a time bomb, where you'll be ignored right up to the point you're making a bit of money, then sued by any number of other people. This is not a great business plan.
You really need to talk to a lawyer. Maybe they'll tell you this is hunky-dory, but I'd be surprised. Not talking to a lawyer isn't going to save you any hassle in the future.
You really need to talk to a lawyer. Maybe they'll tell you this is hunky-dory, but I'd be surprised. Not talking to a lawyer isn't going to save you any hassle in the future.
Plurchase definitely has an opportunity to draw in the female demographic, as they are usually the ones who enjoy social shopping in the real world. I'm a little skeptical if a large majority of male users would want to use this service, but it may attract a lot of male users who are into collecting and socializing about merchandise, shoes, or clothing.
In general I am not a big fan of any kind of browser plug-in or frames but plurchase has done it real well. My GF asks for my opinion on a lot of her online purchases (of course what I say really doesn't matter). But this will be a great way to substitute the back-and-forth email chain.
Plurchase uses a neat idea to act as a proxy for shopping sites. They don't seem to be storing passwords before sending them off to the actual sites (which is good). I hope it takes off. Good luck!
Also, since all of your actions go through them, they attach their affiliate codes to every purchase. It's a better way of bringing in revenue than littering your site with ads of teeth falling out.
Are they still active during the checkout? If they do that with credit card data then Visa is entitled to sue them for violating under PCI DSS at 500k per day of offense.
Plurchase is just a reverse HTTP proxy server looking for an application.
It's not too hard to do something similar in perl.
1) start off by downloading a copy of CGIProxy: http://www.jmarshall.com/tools/cgiproxy/
2) Setup an apache server running CGIProxy
3) Hack the interface box at the top of the screen to include: facebook integration, a meebo chat box, etc...
The problem is that this sort of thing tends to _really_ upset webmasters. So, you'll need to restrict proxy sessions to specific domains (zappos.com, etc...) from which you've received approval to run an open proxy against.
It's surprising how far you can take this with one server; what you want to do is to port CGIProxy so that it runs on a custom HTTP epoll server, instead of on Apache. Brad Fitzpatrick has some great perl code on CPAN that shows you how to do this.
Once you have CGIProxy running on epoll (with epoll enabled in the kernel config, of course) you can easily handle thousands of concurrent clients on a single Amazon EC2 (small) instance.
You can disable proxification for images and media to enhance throughput (and to cut down on your bandwidth usage).
This is basically all that Facebook platform is -- a glorified reverse HTTP proxy.
Reverse HTTP proxies are a neat hack. But, the excitement tends to wear off once you realize that's all they really are. The underlying websites against which you are proxifying retain all of the true value. Plus, you are beholden to their TOS (Terms of Service).
Some of the earliest applications of reverse HTTP proxies (back in the 90's) were for anonymizing web sessions. That tends not to work too well, because no one wants to assume all of that liability.
An obvious application of reverse HTTP proxies would be to create an "enhanced" Craigslist: facebook integration, chat windows, better site search, LSA-based suggestions, etc.... This sounds like a great idea until you realize that the Craigslist TOS prohibits this sort of thing -- as do most websites. Even if the TOS is vague about this, it's only a matter of time before you get shut down -- no one wants a middleman proxying traffic between their website and their customers.
Remember when an ISP in Texas was inserting ads into people's browsing sessions? They were using reverse HTTP proxies.
I haven't even discussed the security implications of this. It's trivial to setup an HTTPS reverse proxy. CGIProxy even works with an SSL-encrypted GMail session. Think about that: all of your username/password data is being handed to a 3rd party middleman in plain text.
Even if the middleman running the reverse HTTP proxy is the nicest guy in the whole world, the security of your data now depends on two different companies getting their security protocls correct: (1) the company running the HTTP proxy, (2) the back-end website.
I'm sure the intentions behind Plurchase are excellent. But, this is a _very_ bad idea.
The only way to fix this situation, would be to to license an "enterprisey" white-label reverse HTTP proxy to e-commerce sites for internal use behind their firewall. For instance, Plurchase could license a "reverse HTTP proxy social networking applicance" to Zappos as a way to retrofit "social networking" features onto the existing Zappos website. That would address many of these issues. But, it's an entirely different business. Plus, the "web accelerator appliance" model has never worked very well.
Eventually, all features get folded into the underlying platform.
It's not too hard to do something similar in perl.
1) start off by downloading a copy of CGIProxy: http://www.jmarshall.com/tools/cgiproxy/
2) Setup an apache server running CGIProxy
3) Hack the interface box at the top of the screen to include: facebook integration, a meebo chat box, etc...
The problem is that this sort of thing tends to _really_ upset webmasters. So, you'll need to restrict proxy sessions to specific domains (zappos.com, etc...) from which you've received approval to run an open proxy against.
It's surprising how far you can take this with one server; what you want to do is to port CGIProxy so that it runs on a custom HTTP epoll server, instead of on Apache. Brad Fitzpatrick has some great perl code on CPAN that shows you how to do this.
Once you have CGIProxy running on epoll (with epoll enabled in the kernel config, of course) you can easily handle thousands of concurrent clients on a single Amazon EC2 (small) instance.
You can disable proxification for images and media to enhance throughput (and to cut down on your bandwidth usage).
This is basically all that Facebook platform is -- a glorified reverse HTTP proxy.
Reverse HTTP proxies are a neat hack. But, the excitement tends to wear off once you realize that's all they really are. The underlying websites against which you are proxifying retain all of the true value. Plus, you are beholden to their TOS (Terms of Service).
Some of the earliest applications of reverse HTTP proxies (back in the 90's) were for anonymizing web sessions. That tends not to work too well, because no one wants to assume all of that liability.
An obvious application of reverse HTTP proxies would be to create an "enhanced" Craigslist: facebook integration, chat windows, better site search, LSA-based suggestions, etc.... This sounds like a great idea until you realize that the Craigslist TOS prohibits this sort of thing -- as do most websites. Even if the TOS is vague about this, it's only a matter of time before you get shut down -- no one wants a middleman proxying traffic between their website and their customers.
Remember when an ISP in Texas was inserting ads into people's browsing sessions? They were using reverse HTTP proxies.
I haven't even discussed the security implications of this. It's trivial to setup an HTTPS reverse proxy. CGIProxy even works with an SSL-encrypted GMail session. Think about that: all of your username/password data is being handed to a 3rd party middleman in plain text.
Even if the middleman running the reverse HTTP proxy is the nicest guy in the whole world, the security of your data now depends on two different companies getting their security protocls correct: (1) the company running the HTTP proxy, (2) the back-end website.
I'm sure the intentions behind Plurchase are excellent. But, this is a _very_ bad idea.
The only way to fix this situation, would be to to license an "enterprisey" white-label reverse HTTP proxy to e-commerce sites for internal use behind their firewall. For instance, Plurchase could license a "reverse HTTP proxy social networking applicance" to Zappos as a way to retrofit "social networking" features onto the existing Zappos website. That would address many of these issues. But, it's an entirely different business. Plus, the "web accelerator appliance" model has never worked very well.
Eventually, all features get folded into the underlying platform.
Most reverse proxies do the easy stuff, but all the hard stuff is still on the client side javascript/flash code. It'll probably take you a few hours to hack up one of the existing proxies out there and get "almost" what plurchase has, but you'll soon see that menus won't render in amazon and links just won't work because the link menu system is completely dynamically constructed so most proxies won't take you this far. We have an html rewriter written in javascript on the client side to solve some of those issues. We also have a javascript rewriter written in javascript to proxify the javascript code. If you right-click view-source on one of the proxified frames, you'll see that we go to great lengths to make things work under the cover.
Also, you might notice that you can't ignore all images & static assets, some of the image requests actually modify cookie information so you may need some different level of proxying there -- same goes for css/javascript assets. You'd be surprised what websites do under the cover. Even with all of our technology, there are still some sites that don't function properly and may require some tweaking on our proxy engine. I tested kayak.com yesterday on our proxy and it almost works but there are still some weird issues going on that I'll have to debug further. I mentioned most of these details in a blog post -- had this been the web 1.0 days, proxying might actually be easy, but we wouldn't have the speed of modern javascript interpreters.
I agree with you on some of the ToS stuff that we'd have to potentially work with merchants on. And since we're white-labeling based on domains, we can remove them if they don't want us there, but proxying shopping sites is unlike other sites -- they want customers to buy stuff. Anything that causes a customer to convert better is in their best interest. Large merchants were actually interested in this, but they didn't want partnerships until they saw traction.
Also, you might notice that you can't ignore all images & static assets, some of the image requests actually modify cookie information so you may need some different level of proxying there -- same goes for css/javascript assets. You'd be surprised what websites do under the cover. Even with all of our technology, there are still some sites that don't function properly and may require some tweaking on our proxy engine. I tested kayak.com yesterday on our proxy and it almost works but there are still some weird issues going on that I'll have to debug further. I mentioned most of these details in a blog post -- had this been the web 1.0 days, proxying might actually be easy, but we wouldn't have the speed of modern javascript interpreters.
I agree with you on some of the ToS stuff that we'd have to potentially work with merchants on. And since we're white-labeling based on domains, we can remove them if they don't want us there, but proxying shopping sites is unlike other sites -- they want customers to buy stuff. Anything that causes a customer to convert better is in their best interest. Large merchants were actually interested in this, but they didn't want partnerships until they saw traction.
CGIProxy has full javascript support.
It also handles cookies and can dynamically determine whether or not it should proxify images and CSS assets.
CGIProxy also handles flash.
In fact, CGIProxy can fully proxify an SSL-encrypted GMail session out-of-the-box.
CGIProxy is _very_ mature technology. Take a look at the source code -- it handles 100's of special-cases.
Some of the special-cases that CGIProxy handles are truly bizarre. Reading through the CGIProxy source code is actually pretty fascinating.
This brings up an interesting point. If you're interviewing a software engineering candidate, ask them what their favorite language is. Next, ask them to write a simple HTTP server in that language. Finally, ask them to write a reverse HTTP proxy that works with the server they just wrote. This is a surprisingly effective way of separating the wheat from the chaff. Most people with CS degrees are completely incapable of doing this.
It also handles cookies and can dynamically determine whether or not it should proxify images and CSS assets.
CGIProxy also handles flash.
In fact, CGIProxy can fully proxify an SSL-encrypted GMail session out-of-the-box.
CGIProxy is _very_ mature technology. Take a look at the source code -- it handles 100's of special-cases.
Some of the special-cases that CGIProxy handles are truly bizarre. Reading through the CGIProxy source code is actually pretty fascinating.
This brings up an interesting point. If you're interviewing a software engineering candidate, ask them what their favorite language is. Next, ask them to write a simple HTTP server in that language. Finally, ask them to write a reverse HTTP proxy that works with the server they just wrote. This is a surprisingly effective way of separating the wheat from the chaff. Most people with CS degrees are completely incapable of doing this.
I downloaded to take a look at the source, they do things that are similar to us actually, and they do have lots of great special case handling that we might use for reference later. One crazy thing that we do that isn't done here is the storage of cookies, we actually temporarily store cookies on the server side so that we can do fancy things with it -- sending around the shopping cart, transfer of shopping state etc.
However, if you've tried using it, you'll notice that it isn't perfect either... they show slashdot.org as an example, but lots of things are broken on it. Most of the javascript stuff doesn't work. Slashdot was a javascript light site a year ago, but now they use tons of fancy javascript like most sites. Their cookie support also seems to be broken -- not sure why. Although I will admit that James did quite a bit of amazing work in just 12k lines of perl code. The perl code is pretty decent too.
It's easy to get a proxy that works on 95% of the code, all the hard stuff is in that last 5% -- that's what we spent most of the time on :-)
However, if you've tried using it, you'll notice that it isn't perfect either... they show slashdot.org as an example, but lots of things are broken on it. Most of the javascript stuff doesn't work. Slashdot was a javascript light site a year ago, but now they use tons of fancy javascript like most sites. Their cookie support also seems to be broken -- not sure why. Although I will admit that James did quite a bit of amazing work in just 12k lines of perl code. The perl code is pretty decent too.
It's easy to get a proxy that works on 95% of the code, all the hard stuff is in that last 5% -- that's what we spent most of the time on :-)
I evaluated cgiproxy at the beginning of this project, along with a variety of apache mods and other libraries. cgiproxy didn't work for most of the merchant sites that I checked. Was an oversight to ignore them thereafter though. Like you said, they've put a lot of time into special cases, and we can learn things from them.
Their primary goal is anonymous browsing. Ours is collaborative shopping, or more specifically, adding new functionality to existing sites. Our proxy lets us do amazing things with client state, image scraping, and more. A different tool for a different problem.
Their primary goal is anonymous browsing. Ours is collaborative shopping, or more specifically, adding new functionality to existing sites. Our proxy lets us do amazing things with client state, image scraping, and more. A different tool for a different problem.
It rewrites the flash and javascript so that they call your reverse proxy instead of the original domain?
Yes.
Well it doesn't seem to work all the way. I'm not sure what you meant when you said it has "_full_ javascript support" and is "very mature technology". I tried it out with amazon.com and none of the menus seem to be working...
Feel free to give it a run through: http://bit.ly/5WVsw
(this is cgiproxy 2.1beta19 running on mod_perl on a fresh lenny instance -- no ssl configured here)
Feel free to give it a run through: http://bit.ly/5WVsw
(this is cgiproxy 2.1beta19 running on mod_perl on a fresh lenny instance -- no ssl configured here)
I wonder how much of your resources will be bound long-term trying to keep up with ever-changing frontend code of the different shops and sites. It's something that keeps most of the teams doing javascript injecting browser plugins really busy.
once we get our selenium farm going, hopefully not much. it takes about 10-15 minutes to write a script for a specific site. We just need tests that will validate our scripts against each site every day.
No comments about raves yet? Peace Love Unity Respect. Shopping.
voice chat would be great. as would be the ability to "take over" the mouse so that I can present items (using the house as a pointer) to my friend
Why would someone use this instead of sharing links and discussing items on IM/facebook or googlewave in the future?
Interesting. It seems like the plurchase concept of social shopping is a subset of social browsing.
This bad boy runs on the JVM! Very slick JRuby and Java(hibernate...)
I like the idea.
FWIW, my wife, who loves shoes, says she thinks it's neat.
FWIW, my wife, who loves shoes, says she thinks it's neat.
You can use it on Amazon too. Just type 'amazon' into the search/go-to box.
Grats guys!
There are so many times when I try pasting a shopping link to friends in chat, and when they click thru, it breaks because either
There are so many times when I try pasting a shopping link to friends in chat, and when they click thru, it breaks because either
(1) GTalk / chat client garbles the URL
(2) something in the query string was unique to my account
(3) some kind of cookie / session interplay made the link fail.
On the other, I am married to a shoe fiend who spends her free time chatting with her shoe fiend friends ... and this site worries me greatly.