TOS & security concerns

[tmas]

Has anyone had any direct communication with Monarch regarding this project (or unofficial API access in general)? I'm very interested in using it (and using it to integrate Monarch with a webapp I already use to manage my personal finances), but my primary concerns are:

• TOS violations (the TOS specifically states that scraping and any type of automated access is forbidden)
• The current auth process directly handling user credentials.

I've seen some public comments from Monarch employees on Reddit indicating that they want to add a public API at some point, so I'm hoping we might be able to convince them to update the TOS. Even if they don't update the actual text, just getting some reassurance from Monarch that they'll provide a warning before banning anyone for using this package would be good enough in my book.

I have some ideas around how to create a significantly more secure auth process (via household sub-accounts and/or the Give Access to Financial Professional feature), but I'm not sure I want to spend time implementing them if I could just get banned by Monarch afterwards. If we could get an official blessing and an automated path to create Financial Professional accounts, I think it would be possible to create a secure auth process like:

1. App/script creates Financial Professional account
2. User shares access with the Financial Professional account
3. App logs in as Financial Professional account automatically and accesses the user's data
4. User can revoke access at any time, and must re-share access every 60 days. This could be a bit annoying, but 60 days seems long enough that it's worth it for the security benefits. The most secure option right now would be sharing a session token, which has a much shorter lifetime than 60 days.

The API is probably a bit different for Financial Professional accounts, but I imagine it's broadly similar - if we're lucky, we'd just need to add a single header or field to specify an ID for the user account we're trying to access.

In the short term, assuming it doesn't break the existing implementation, it may be worth recommending that people create a sub-account with a one-off password using the Household feature and use that to access the API. I imagine most people use this package for local scripts, but there's a chance somebody is running a webapp and collecting credentials from other users (which could include reused passwords).