Your gut reaction is not wrong. That being said, I think it's wise to pick the right time to leverage this capability. Our resources are extremely limited at the moment in comparison to one of the most aggressively litigious entities in our space.
Southwest fares integrated with other airlines is pretty much the reason why I'd install something like this. Also, getting sued might be good PR, you could probably spin that into some great news coverage. Streisand effect.
I don't know which is the biggest, there are a lot of known unknowns still floating around. Will we run out of money before we monetize? Will we have to deal with constant lawsuits? Will other innovators in the space attempt to move in our direction? Are there enough travelers willing to install an extension? Will google be google and shut us down? The ever present bus factor. All of these are legit concerns that are going into our crowdfunding risks disclosures. All are things to manage.
I don't think this is a big city thing. I live in a medium sized city in the states and I hate going to the airport. 20-30m commute there, parking, walk, wait in line, go through the scanner, inevitable pat downs, cinch back up the belt, etc. Not what I look forward to. On our long term feature list is adding commute time and time to get through the airport to the timeline view as an optional setting, as well as potentially factoring that into our pain algorithm. This is really handy when you're flying to/from a big city like London or NYC, where airport choice my matter at a particular day/time. A similar long term add is factoring in having to go through customs on a layover. This is another awful part of the flight experience we can track and influence decision making through.
Re: codes: yup, that's a bug and will be fixed (or at least the obvious one will be...)
Re: performance - this is on our radar, and we'll keep chipping away at making things a little better as we go. We do have some limits based on system characteristics, but the primitives available to chrome extensions for system information are limited (praise WECG - there's a lot of bad that can be done with too much info).
Re: ballpark dates - This is on our radar, but is both a thorny interaction and below the priority of a few other things users commonly request. No firm commitments on dates as such... but yes, it's a useful tool when you know you want a "May" vacation, and you want a reasonably priced flight that is comfortable.
We don't handle the booking, we redirect you to the travel site that we found the best price on. Many online travel search agencies and metasearch sites can put together itineraries the airlines don't offer directly.
As a simple example, United probably isn't going to offer a flight where one leg is on United and another is on American. Yet, it might be substantially cheaper or less painful to take that flight. Certain codeshares may be more profitable for them to hawk, to the point where they will only show certain legs when the more profitable flight is booked. They may also choose not to show flights that are already profitable based on bookings (e.g. takes 75 economy seats to make flight with legs A->B and B->C profitable) when a similar flight (A->D, D->C) is underbooked and could use some more folks aboard. There are probably a thousand other reasons...
1.) When a user reports an issue to us, it is much easier to find any issues in our error reporting stack. if we have their name and email address attached to the issue as opposed to asking them for all the search terms, time of issue, etc. and then hunting through to see if we've already found (and hopefully fixed) the issue. This practice started when we were a paid subscription, and I've found it useful to continue, especially with a very small team supporting a set of highly asynchronous interactions with scripts running across multiple websites and pushing data back to a common source.
2.) There are contractual requirements for some of the data that we've purchased to be protected from copies of those databases being made. Placing it behind an auth wall and leveraging account based rate limiting for API endpoints met our partners' needs.
The short answer is because certain airlines behave in ways I can best describe as 'scummy'. Some airlines are now demanding anti-consumer provisions when they do deals with travel sites, such as insisting that sites hide cheaper flights, hide multi-airline itineraries, and hide certain booking options. We think this compromises the user experience heavily and erodes trust - you don't know if you're getting the best possible flight. Being a browser extension gives us the ability to show the lowest fares without going through airline servers or airline contracts, since we can search and compile all the data from your browser.
Candidly, the Firefox extension framework is significantly nicer. Blam'ing chrome.runtime.lastError.
There's a lot of small amounts of work to get everything working right using the webext module. We're slowly chipping away, we've eliminated all our dependencies on chrome specific modules in the last month while working on other functionality, but we're a really small team right now with competing priorities, so this will get more priority as we get more people on the team.
There shouldn't be any reference to a subscription. Can you let me know where you saw one? We used to have this setup as a paid extension, but pivoted away as that business model didn't work as well as we'd have liked.
Re: privacy and data. You can certainly review the settings we request and our terms of service - we ask to run the extension on a number of travel sites we interact with. We only collect your search intent data, progress around searching, and other similar lifecycle events as your search to aid us in product development. That being said, our long term monetization strategy is to sell search intent data - not your personal or financial data, and definitely not showing ads.
>Signing up and Purchasing a Subscription. When you purchase a subscription to our Services, your credit card information, billing information, and any other financial information necessary to complete your purchase (“Payment Information”) is processed by our third-party payment processor, and we do not collect, store, or process your Payment Information. After you purchase a subscription to our Services, we will receive your email address from Stripe as confirmation of your subscription purchase. For more information, please see the “Payment Processing” section below.
>we automatically receive information about your interactions with them, such as the contents of your searches, the length of time you spend on a page, objects such as hyperlinks you click on, the airlines you prefer, and the dates and times of your visits.
>We and our third-party partners may collect information using cookies, pixel tags, or similar technologies. Our third-party partners, such as analytics and advertising partners, may use these technologies to collect information about your online activities over time and across different services.
>We may receive personal information about you from third parties such as the websites we send you to book your travel and combine it with other personal information we have about you.
>Vendors and Service Providers. We may share any personal information we receive with vendors and service providers retained in connection with the provision of our Services.
>We do not rent, sell, or share personal information about you with nonaffiliated companies for their direct marketing purposes unless we have your permission.
*emphasis mine
>We may use analytics services such as Google Analytics and Sentry to collect and process certain analytics data. These services may also collect information about your use of other websites, apps, and online resources.
>We may transfer your personal information to service providers, advisors, potential transactional partners, or other third parties in connection with the consideration, negotiation, or completion of a corporate transaction in which we are acquired by or merged with another company or we sell, liquidate, or transfer all or a portion of our assets.
>We may also disclose your personal information with your permission.
>There is no accepted standard on how to respond to Do Not Track signals, and we do not respond to such signals.
While I recognize that most of this is standard practice among the data thieves, I thought it pertinent to call out your simplistic glossing over of your data thieving intent.
Hipmonk was a valuable service and one that I'd gladly pay for, but my data is worth way more than that.
BTW - You and I both know that if I specify "Do Not Track" then I don't want you to track anything about me.
Adding alliances is on our near term roadmap. Should be live before the end of the month. Feel free to drop me an email (max AT flightpenguin DOT com) and I'll let you know when it's out.
