Hi!
I’m a bit concerned about how you connect and authenticate to services. It seems to involve some sort of screen sharing, remote desktop, or VNC process during authentication. No hard feelings, but I don’t feel safe authenticating in this way. I would expect that you would redirect to the IDP so that I could authenticate directly there. Currently, you display the IDP login on a remote computer where I have no control over how my password is handled. Are there any plans to fix this?
/m
Following this as i saw so many answers from people but would love to read an official statement from rabbit
Agreed. I literally didnt go through with linking doordash bc i am on some other computer/server completely linking my login. Amateur type stuff imo
Hey Folks,
We did a blog post about this a while back, let me know if it doesn’t clear things up from a, “how does it work” perspective 
https://engineering.rabbit.tech/lam-security-architecture-overview
If we were planning for “1-off integrations” - I agree, a traditional OAuth approach would work here. Manage a single app, ensure you request appropriate scopes, and move on. The problem is, we aim to support ANYTHING a person can do with a computer… not just what’s available via an OAuth session + the downstream API.
Remember when Mint came out in 2006? The Plaid API didn’t exist yet, so they simply requested and stored their customer’s banking passwords in order to auth. As a customer, I had to decide for myself, “Is the value Mint provides worth the additional risk I expose myself to”. Fast forward to today, and no one would dream of attempting an integration like that, because the Plaid API exists, and you can use it to get OAuth access to nearly any banking provider with a website.
I think of my R1 + rabbithole like I would a housekeeper. If you want to have your house cleaned while you aren’t home, you have to give them a key. Once they have the key, they have unfettered access to your house. You weigh the value being provided against the risks, and either trust them with a key, or you don’t.
As “agent technology” matures - I think we’ll eventually have a Plaid equivalent, and I’m eager to adopt it when it arrives. But until then, I think the solution we’re using today is a good starting point, and we’ll keep iterating over time (But I totally understand if we haven’t earned enough trust for a key to your doordash yet :))
I really appreciate the explanation about the LAM architecture and how you address the security issues.
Go on, most of us support your hard work! 
Thx I hope it reads as “providing clarity” vs “defensive” - because I love the feedback … sometimes I just write a book of a response instead of a few sentences 
In fact I recognize that the tone of the article definitely has an explanatory and not at all defensive slant 
Moreover some few words in excess are better than some shrinked sentences.
Thank you for your swift and transparent reply! Personally, I find that the risk/reward balance favors not sharing my credentials until you have proper OAuth authentication in place. Others might assess the balance differently.
Is this supposed to be a comforting reply to a genuine question? If so, it fails miserably.
“Yes our implementation is bad, but you gotta risk it sometimes, right?!”
That’s a ridiculous, and amateurish statement. You’re asking for people’s Apple ID for Music connections. How could you possibly need more than standard oAuth or normal authentication just to get the toy to play music?
This is a solved problem and if you want to try and do other stuff beyond that you should offer an actual secure connection to do it.
One additional concern about this approach of authentication on remote-vm-machine…
With Spotify I have an issue that once I login in the rabbithole (happens probably in US) and then any of my devices prompt for logon (but they do it from Poland/Europe) - then Spotify classifies this as account hacking and resets a password making all my devices unlinked from the account.
That have to be solved somehow with multiple IP locations of remote-vm-machine for LAM - or with some proxy servers in close-to-user location. So that they can impersonate me and my current location.
Any ideas here?
Thank you for the feedback, I’ll try to come across as less of an amateur in the future
For clarity - my goal is transparency, not a false sense of security. The articles I linked accurately describe how our integrations work.
If you read them and decide, “that’s not for me”, I totally understand - we want our customers to make decisions based on their own risk tolerance.
I’m sorry I couldn’t be of more help - but I hope you have a good day anyway
Thanks @pablomano - this is definitely something we’re working on solving as soon as possible. When will it be done? I don’t know 
Is your feedback valid, and are we actively working to resolve it? 100%
So, just to be sure, Rabbit’s official response is that there is just no possible way to offer a normal connection method to Apple Music to just play music? I’ve heard the copy and paste response before about a connection via API or oAuth would not work for the LAM. Let’s assume that part is true, but if this was just included as a feature to let us play music, rather than harvest data, that again just not true is it?
I was able to make it work from Canada.
Mine has been working for the last 3 days.
I think the problem here is that they have decided on a very ambitious goal: to replace humans operating graphical computer interfaces with user interface automation driven by user intents. This means they want unlimited access to do everything a human would be able to do in a user interface, regardless of whether there is an API available. If I understood Jesse correctly during the pickup event, they want access to all your credentials, for example, via 1Password, to seamlessly access all your services for you.
I believe they have good intentions with this approach. Their architecture seems to be well thought out, as credentials are stored in a separate vault and are only used in temporary runners/containers that are discarded after each use. However, this means you need to trust them with keeping your credentials, which I don’t.
For several reasons, I think this approach will prove to be too difficult and too dangerous to achieve.
I would prefer if they allowed the LAM to operate both on UI automation and API integrations. For example, integrations they provide, such as Apple Music, Spotify, and Uber, would use APIs, while user-trained actions would use UI automation. API integrations should, of course, use proper OAuth authentication.
@mattdomko feel free to correct me if needed
1000% this.
Canada is not that “far” away from US servers as European one
Maybe a workaround is - I should use my account on Spotify via VPN linked to US for a day and then config rabbit …