Alternative to TripIt = TripWaffle

[RooFlyer]

Key point of differentiation: tripit will only process booking emails from certain vendors. Tripwaffle will literally process any confirmation from any provider- think of the most obscure ferry operator or Alaskan dog sled tour... we'll import it into your itinerary.

Thank you. As it happens, I never or only very rarely use the import via email option for TripIt. The itineraries contain a whole lot more information than just the event being considered and I am reluctant to send it off to some company overseas, feeding some possible profitable sideline where they sell all the related information.

 

[Daver6]

Thank you. As it happens, I never or only very rarely use the import via email option for TripIt. The itineraries contain a whole lot more information than just the event being considered and I am reluctant to send it off to some company overseas, feeding some possible profitable sideline where they sell all the related information.

To be fair, websites cost money to run and developers need to eat (and drink wine). Totally understand your concern but when a website is "free" for the user, the owners need to at the very least recoup costs somehow.

Is it an alternative for TripIt ( per the OP) or Flighty? For instance does it handle hotel bookings, rail, concerts, other activities, with inputs for things like cost, confirmation, like TripIt? Does it produce a visual timeline so you can see possible overlapping or conflicting events of different types?

From playing around with the site a bit, yes it seems like a complete replacement for TripIt plus more. If certainly gives the timeline with a heap more generated information too.

 

[RooFlyer]

To be fair, websites cost money to run and developers need to eat (and drink wine). Totally understand your concern but when a website is "free" for the user, the owners need to at the very least recoup costs somehow.

As the saying goes, if something on the web is free then the user is the product.

If you look at the type of data aggregation that is possible on these types of sites, it leaves Qantas’s so-called big data in the shade

To be honest, I’m not all that hung up about privacy but if I can enter the data manually, I can at least preserve a tiny little bit more.

 

[kpc]

From playing around with the site a bit, yes it seems like a complete replacement for TripIt plus more. If certainly gives the timeline with a heap more generated information too.

Assuming Tripwaffle updates with flight delays, boarding gates etc, Tripwaffle at this stage is free cf to Tripit Pro which you have to subscribed to for a fee for this information.

 

[tripwaffle]

As the saying goes, if something on the web is free then the user is the product.

If you look at the type of data aggregation that is possible on these types of sites, it leaves Qantas’s so-called big data in the shade

To be honest, I’m not all that hung up about privacy but if I can enter the data manually, I can at least preserve a tiny little bit more.

It's a valid concern, given it's standard operating procedure by everyone from mobile carriers to reward programs to innocuous looking calculator apps.
Not something we do, nor ever plan to. Quite the opposite of our love-thy-user mantra.
All that said- it's possible to manually add events in tripwaffle, with a bare minimum of details.

 

[tripwaffle]

I think you need to differentiate between editor and (second) traveller. Eg, someone makes their assistant an editor, they wouldn't want their bosses stats showing as theirs.

Thinking through all the various scenarios of why users might want to share a trip, we've come up with this proposal for 5 different roles.
Feedback very welcome.

 

[Airbumps]

Never heard of this app but just signed up - Love it so far - This is a LOT easier than managing my trips solely in my Google Calendar!! Thanks @tripwaffle

I'm a little hesitant to be uploading my booking reference numbers and name etc to a third party website though....anybody got any thoughts on that from a security or privacy perspective?

 

[pauldab]

So the issue I have is that you need to use apple or google to log in on a pc.

I would prefer not to have it associated with either account and just create an account with an outlook email

This is probably the showstopper for me, I refuse to use sso or shared auth providers with unrelated websites as I have a unique email address for every service under my personal domain name and my “actual” email address is never known to anyone. This also allows me to quickly shutdown an address and reduce my exposure if a service I use suffers a breach (which I have had to do multiple times when Dropbox, Optus, VN Air and others lose possession of my data).

I see the advantages for a dev to not have to roll their own auth backend when using this type of login process for users but it does assume incorrectly that everyone has either an apple or google account.

 

[tripwaffle]

Never heard of this app but just signed up - Love it so far - This is a LOT easier than managing my trips solely in my Google Calendar!! Thanks @tripwaffle

I'm a little hesitant to be uploading my booking reference numbers and name etc to a third party website though....anybody got any thoughts on that from a security or privacy perspective?

Thank you for giving us a look.

Security/privacy is a long discussion, but let me do my best to address the associated risks in brief...

Scenario: Malicious app
Counter: publishing on the official Apple/Google app stores involves a lot of scrutiny and security checks. Large teams at these orgs work to counter bad actors from publishing bad apps. Not bulletproof, but also very very hard to evade the current checks.

Scenario: personal data is intentionally exploited
Counter: if this was our incentive it would be way more effective/easier to launch a product in the ecommerce/finance/banking/crypto space.

Scenario: personal data is unintentionally exploited through incompetence
Counter: This is the biggest "trust me" one, but if it helps, I personally have over 30 years experience in app development including previous tech founder role at a NASDAQ listed web app with millions of daily visitors. Also, given the numerous breaches of large organisations (hello booking.com), I'd argue there's a case for agile/savvy tech teams handling the responsibility of your data vs the disinterested employees at random airline/travel agent/GDS/hotel/car rental place.

A couple of actual example of our commitment to this responsibility...

1. We don't ask for or store passwords (Google/Apple sign-in instead)
2. We don't ask for access to your email inbox (too big of a risk to you)
3. We purge all forwarded booking emails within 7 days of receiving them (no benefit to storing them)

Anyway, hope this reassures the (rightfully) wary.

 

[moa999]

As has been seen in a few cases of boarding passes being uploaded to socials with surname and booking ref, flights have been cancelled - so this is a risk with some airlines and I presume hotels.

To an extent using Google or Apple auth, and being app only, probably reduces this risk, though note some individual preference to use unique logins.

As @tripwaffle says there is probably an element of trust me.. though you have a similar situation with your ISP and/ or email provider who could theoretically access the same info.

 

[tripwaffle]

This is probably the showstopper for me, I refuse to use sso or shared auth providers with unrelated websites as I have a unique email address for every service under my personal domain name and my “actual” email address is never known to anyone. This also allows me to quickly shutdown an address and reduce my exposure if a service I use suffers a breach (which I have had to do multiple times when Dropbox, Optus, VN Air and others lose possession of my data).

I see the advantages for a dev to not have to roll their own auth backend when using this type of login process for users but it does assume incorrectly that everyone has either an apple or google account.

Not sure if you're an Apple user, but quite a few of our existing users signup using Apple's email anonymisation feature (example below).

From our end, all we see is "[email protected]"

 

[Daver6]

This is probably the showstopper for me, I refuse to use sso or shared auth providers with unrelated websites as I have a unique email address for every service under my personal domain name and my “actual” email address is never known to anyone. This also allows me to quickly shutdown an address and reduce my exposure if a service I use suffers a breach (which I have had to do multiple times when Dropbox, Optus, VN Air and others lose possession of my data).

I see the advantages for a dev to not have to roll their own auth backend when using this type of login process for users but it does assume incorrectly that everyone has either an apple or google account.

I think if there is a breach, your email address being known is the least of the concerns. The benefit is more in linking you between sites but that's probably happening anyway with various tracking cookies or if making purchases, your credit card. Also IP/browser finger printing will be used to track you between sites.

There would be a very minor benefit in reducing exposure to a credential stuffing attack, but so minor compared to using MFA on your accounts as well as different passwords.

Not saying there is no benefit, but in the grand scheme of things and IMHO, the effort isn't worth the minimal benefit. However, everyone has a different risk tolerance.

 

[pauldab]

I think if there is a breach, your email address being known is the least of the concerns. The benefit is more in linking you between sites but that's probably happening anyway with various tracking cookies or if making purchases, your credit card. Also IP/browser finger printing will be used to track you between sites.

There would be a very minor benefit in reducing exposure to a credential stuffing attack, but so minor compared to using MFA on your accounts as well as different passwords.

Not saying there is no benefit, but in the grand scheme of things and IMHO, the effort isn't worth the minimal benefit. However, everyone has a different risk tolerance.

I’ve been using unique email addresses as a 2nd factor for nearly 20 years, long before OTP and MFA became more prevalent.
There is no change to how I work versus someone with a single email address - the domain is setup with a catchall forwarder to my actual mailbox.
This has also alerted me to unauthorised information sharing by companies where I have submitted privacy complaints against them so I view this way of managing my online identity magnitudes better than just being known as <me>@gmail.com

Not sure if you're an Apple user, but quite a few of our existing users signup using Apple's email anonymisation feature (example below).

From our end, all we see is "[email protected]"

View attachment 504003

Sure it may but as you state this is only available for apple users and I don’t see this as any advantage as the emails involved will still be forwarded to whatever address is registered on the appleid (meaning that apple know about this association) and the randomString provided to the service is not shown to me if setup and thus does not give enough visibility of the true source for the account.

It also creates an apple only passkey stored only in the keychain of the device (not provided to a 3rd party password manager like Bitwarden where it can be used in any browser) and as I am typically reluctant to install an app, I tested and can confirm this also does not work in a privacy first browser (DuckDuckGo) with the auth request triggering the sign in with apple workflow but no login at all, the site remains on an unauthenticated session (even after I set the browser to treat your domain as trusted for the purposes of cookies and localstorage).

 

[tripwaffle]

the randomString provided to the service is not shown to me if setup and thus does not give enough visibility of the true source for the account

Minor fyi ... Settings > [your name] > iCloud > Hide My Email to list them, their usage and remove/block them.