Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Pelm (YC W22) – Plaid for Utilities

pelm.com

Post reply on HN
Print view View original

61–70 of 91 posts

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#61

Post by renewiltord »

zomglings wrote: post #59

I used to work at a startup which did the same thing for health records. In fact, our frontend plugin was also called "Connect". As an end user, it sounds like you will take my credentials for my utility provider, log into their website with those credentials, extract my data, store it in a normalized form in your DB, and expose it through your REST API. Is this true? If so, while you are logged in, you will also hav…

Do they actually? My provider only lets me edit those details (with a low quality preview of first 4 digits and a CC icon). Interesting that yours makes those visible to you. You literally can't get those out of my provider. The data doesn't make it out.

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#62

Post by drewkim »

ok_dad wrote: post #54
drewkim wrote: post #45

Earlier quoted context omitted.

Thanks for the feedback; as an early stage startup with two employees, we'll often miss things here and there, so I appreciate the callout for how we can improve our docs. While we may not be established right now and have some work to do, I'm confident we can build an amazing developer experience given time. UtilityAPI might have very detailed docs, but we think the end to end usability is still lacking. This has be…

I would have the docs much more specific on the results that you'll get back. I think from the looks of it, you're using some automated doc builder which takes your internal specs for the endpoint (like the OpenAPI spec or whatever) and outputs "examples" and the other doc pages. Here is what you have now for an example response body, which is very lacking: { "account": { "id": "string", "unit": "string", "account_nu…

Thanks for the great advice! We've created more detailed responses, so hopefully there's now a clearer picture of the output for each endpoint. We've added the more implementation-heavy recommendations (like changing the request body for interval data and splitting the address schema into multiple fields) to our roadmap to be implemented shortly. Really appreciate the scrutiny; way better to work everything out now than having developers run into usability issues. Please let us know if there's anything else you notice!

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#63

Post by drewkim »

renewiltord wrote: post #61
zomglings wrote: post #59

I used to work at a startup which did the same thing for health records. In fact, our frontend plugin was also called "Connect". As an end user, it sounds like you will take my credentials for my utility provider, log into their website with those credentials, extract my data, store it in a normalized form in your DB, and expose it through your REST API. Is this true? If so, while you are logged in, you will also hav…

Do they actually? My provider only lets me edit those details (with a low quality preview of first 4 digits and a CC icon). Interesting that yours makes those visible to you. You literally can't get those out of my provider. The data doesn't make it out.

This is also what we've encountered so far...though it's probably safe to assume at least a few providers have looser security protocols.

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#64

Post by qqqwerty »

ziggus wrote: post #53
drewkim wrote: post #45

Earlier quoted context omitted.

Thanks for the feedback; as an early stage startup with two employees, we'll often miss things here and there, so I appreciate the callout for how we can improve our docs. While we may not be established right now and have some work to do, I'm confident we can build an amazing developer experience given time. UtilityAPI might have very detailed docs, but we think the end to end usability is still lacking. This has be…

The founders may have energy industry experience - which is what you want, since it's the operating domain and they'll have industry information and contacts that 'outsiders' won't - but they seem to have a pretty strong development team: https://utilityapi.com/team .

The founder is pretty active on hn[1]. And coincidentally, his most recent comment is about why it makes sense to work at an energy company as part of market research.

[1] https://news.ycombinator.com/threads?id=diafygi

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#65

Post by ggpsv »

drewkim wrote: post #60
zomglings wrote: post #59

I used to work at a startup which did the same thing for health records. In fact, our frontend plugin was also called "Connect". As an end user, it sounds like you will take my credentials for my utility provider, log into their website with those credentials, extract my data, store it in a normalized form in your DB, and expose it through your REST API. Is this true? If so, while you are logged in, you will also hav…

You nailed it! First guarantee is that nobody is manually going in and poking around your account details since the process you've described happens entirely programmatically. Now, we could program our system to do things other than what's mentioned. However, we're quite disinterested in (actually, emphatically against) ruining our trust/reputation with customers (plus the general public) given our dependence on such…

Take this as constructive feedback.

I don't doubt your intentions but these guarantees don't hold their weight relative to the sensitivity of the data that you will safeguard. Despite the process happening programmatically, developers will still have access to the backend where this occurs. Who has access to this backend? What's stopping any of your engineers from peeking at the database where the credentials are stored? Is this data encrypted at rest and transit? What sort of information is this process logging to either first-party and third-party services? Will the code be audited? What sort of compliance certifications are you planning to obtain?

Maybe you do have answers to these questions so if you do I suggest that you communicate how credentials are properly safeguarded. The guarantees that you mention in this comment don't inspire confidence as a) they can't be taken at face value b) makes me doubt you are taking the due diligence required to manage this data.

Take a look at these examples of companies supporting their claimed guarantees:

* https://1password.com/soc/

* https://plaid.com/safety/

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#66

Post by westurner »

drewkim wrote: post #6
samwillis wrote: post #3

Two questions: How are you connecting to the users energy supplier, I assume most don't have their own apis and so you are having to save the users login credentials? If so you should list the security measures you are taking to ensure that are safely stored. This is much like how developers had to connect to banks before they started supporting standard apis. Which utility companies can you currently connect to? Aga…

Great callout. Passwords are encrypted using a 256-bit AES cipher and are never persisted or shown to developers in plaintext. We currently support PG&E and SCE with a ComEd integration landing within the week.

What does it cost a utility to add e.g. read-only OAuth token support to their customer-facing app?

FWIU, it's pretty easy to add OAuth support to any HTTP API endpoint with e.g. Nginx auth_request or by integrating an OAuth library with automated tests into the application at the url routes, if nothing else.

Do you have a "Guide for utilities who want users to have a safe third-party read-only API", a Developer portal, or like a decision tree for which script to read a decision-maker or a front-line lackey who doesn't know anything about APIs?

Does Pelm integrate with Zapier? https://zapier.com/platform

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#67

Post by mcbishop »

kolanos wrote: post #43
dmitrygr wrote: post #30

We NEED to stop training users to give away passwords for account X to services that are not X. We NEED to! This is what enables phishing to work! It normalizes this! Please do not do this! Next time some old lady loses her life savings due to phishing, you'll know that in some small part plaid and this helped. They trained her that it is ok to provide her password to someone.

If utilities gave them any other way, I'm sure they'd be using it.

The three major California utilities have an oAuth 2.0 option (PG&E's is called Share My Data). I wonder if Pelm has considered supporting that.

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#68

Post by drewkim »

ggpsv wrote: post #65
drewkim wrote: post #60

Earlier quoted context omitted.

You nailed it! First guarantee is that nobody is manually going in and poking around your account details since the process you've described happens entirely programmatically. Now, we could program our system to do things other than what's mentioned. However, we're quite disinterested in (actually, emphatically against) ruining our trust/reputation with customers (plus the general public) given our dependence on such…

Take this as constructive feedback. I don't doubt your intentions but these guarantees don't hold their weight relative to the sensitivity of the data that you will safeguard. Despite the process happening programmatically, developers will still have access to the backend where this occurs. Who has access to this backend? What's stopping any of your engineers from peeking at the database where the credentials are sto…

Thanks for the feedback! To answer your questions: - Myself and my co-founder - Credentials aren't stored in plaintext and the encryption key isn't universally available; "peeking" at the db is quite difficult - Data (I'm assuming you mean credentials) is encrypted at rest and in transit - Only business logic and errors are logged: e.g. when processes are completed and why things are breaking - Yes, eventually - Definitely ISO 27701 & SOC 2, perhaps others

Our process for safeguarding credentials is mentioned further down in the thread.

I'm not sure what more guarantees we can give to inspire confidence other than statements taken at face value. We don't have the scale or resources to undergo rigorous third party auditing at the moment. On the other hand, one of the first conversations my co-founder and I had was about hiring a security engineer as soon as we could afford one; we definitely take the matter seriously. Did you have any other ideas of ways we can showcase our commitment to security/privacy other than "trust us"? I do agree it's not the best method but am unsure of alternatives.

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#69

Post by djbusby »

drewkim wrote: post #68
ggpsv wrote: post #65

Earlier quoted context omitted.

Take this as constructive feedback. I don't doubt your intentions but these guarantees don't hold their weight relative to the sensitivity of the data that you will safeguard. Despite the process happening programmatically, developers will still have access to the backend where this occurs. Who has access to this backend? What's stopping any of your engineers from peeking at the database where the credentials are sto…

Thanks for the feedback! To answer your questions: - Myself and my co-founder - Credentials aren't stored in plaintext and the encryption key isn't universally available; "peeking" at the db is quite difficult - Data (I'm assuming you mean credentials) is encrypted at rest and in transit - Only business logic and errors are logged: e.g. when processes are completed and why things are breaking - Yes, eventually - Defi…

You could let the utility companies, which users already "trust" evaluate and then recommend/sign-offs on your engine? Or just have the utility embed your engine and bill them?

Re: Launch HN: Pelm (YC W22) – Plaid for Utilities

#70

Post by ggpsv »

drewkim wrote: post #68
ggpsv wrote: post #65

Earlier quoted context omitted.

Take this as constructive feedback. I don't doubt your intentions but these guarantees don't hold their weight relative to the sensitivity of the data that you will safeguard. Despite the process happening programmatically, developers will still have access to the backend where this occurs. Who has access to this backend? What's stopping any of your engineers from peeking at the database where the credentials are sto…

Thanks for the feedback! To answer your questions: - Myself and my co-founder - Credentials aren't stored in plaintext and the encryption key isn't universally available; "peeking" at the db is quite difficult - Data (I'm assuming you mean credentials) is encrypted at rest and in transit - Only business logic and errors are logged: e.g. when processes are completed and why things are breaking - Yes, eventually - Defi…

This should be written down somewhere! I glanced through the website and I couldn't find any mention of the security/safety measures taken other than the UI screenshot where it says "securely connect your utility account".

If I were interested in purchasing this service I would want to know how much I can trust you with my credentials. Perhaps having a page or section in the docs that explain the security measures would be an improvement. There are other ideas in another comment similar to this one.

Post reply on HN