Requesting ConEd access! I bet you could partner with solar companies to compare what their own software rates vs. what's actually metered back to the grid. I can see Sunny Portal to monitor my solar panels, and I can log into ConEd to see my grid usage... but I cannot combine the two. This might let me do that.
Launch HN: Pelm (YC W22) – Plaid for Utilities
71–80 of 91 posts
Re: Launch HN: Pelm (YC W22) – Plaid for Utilities
#72We 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.
This is my reaction every time I see a service like this. In addition to training users that is somehow okay to just give up your credentials to a 3rd party, you are now indefinitely allowing the storage of passwords in a fully reversible format on a platform you have no control over.
Despite all the best efforts by any company engaging in this practice to protect your passwords, these entities are setting themselves up to have a huge target on their back. The technology they employ relies on being able to decrypt passwords programmatically which means it becomes visible on the server’s RAM and could potentially be triggered to decrypt the password as part of an attack. Given that a majority of people use the same passwords for multiple services, it is likely an attacker would be able to determine credentials for someone’s bank or email account via a credential stuffing attack.
Plaid with a bank that does not support oauth scares the hell out of me and I have backed out of using services because this was the only way to enter bank details. I am still shocked that this is largely considered an okay practice.
Re: Launch HN: Pelm (YC W22) – Plaid for Utilities
#73A very quick question: Where can I find a list of energy companies with data already available in your API?
Thanks.
Re: Launch HN: Pelm (YC W22) – Plaid for Utilities
#74Hey, friendly founder advice. Your opening hero and sub text does nothing to actually describe what your API is. This text you wrote would in my opinion be way better "We are building an API that allows developers to access energy data, such as electricity usage or billing data, from utilities." Change it to "An API to access your users utilities" sub text: "Our API gives you access to your users energy data, such as…
[deleted]
Re: Launch HN: Pelm (YC W22) – Plaid for Utilities
#75A very quick question: Where can I find a list of energy companies with data already available in your API? Thanks.
They're listed on the bottom of our home page
Re: Launch HN: Pelm (YC W22) – Plaid for Utilities
#76Requesting ConEd access! I bet you could partner with solar companies to compare what their own software rates vs. what's actually metered back to the grid. I can see Sunny Portal to monitor my solar panels, and I can log into ConEd to see my grid usage... but I cannot combine the two. This might let me do that.
That's a great idea! We've identified a use case with solar companies for aiding in sales...this is a great additional case.
Re: Launch HN: Pelm (YC W22) – Plaid for Utilities
#77I 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…
Have you considered sending users to the website to update payment information? Or if not, do you perform the PCI auditing process for your handling of payment information through your systems?
I don’t personally need the answers to these pair of questions, but I wanted to put them on your radar if they’re not already. I trust Plaid far enough to scrape account providers for me, but I do not trust Plaid far enough to provide Plaid my payment details — even if Plaid could theoretically construct them, that’s just not the relationship I want with a data conduit provider.
Re: Launch HN: Pelm (YC W22) – Plaid for Utilities
#78The unique selling point of such this kind of API service would be that the application/producing consuming this API doesn't need to indirectly ask for their consumer's credentials.
Re: Launch HN: Pelm (YC W22) – Plaid for Utilities
#79I work on the JSON API (I dare not call it REST) layer at Exelon. This is neat. Did you know we have some OpenAPI docs now? I saw you mentioned ComEd in another comment :)
That is really cool. Is it available to the public?
If not, I’d love to get a more accurate estimate from solar companies without having to fish around for my average usage.
Re: Launch HN: Pelm (YC W22) – Plaid for Utilities
#80I 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…
While I respect your current intentions, I cannot take you at your word in perpetuity because I understand the pressures that come from:
1. Running such a business as an entrepreneur.
2. Running such a system as an engineer.
As an entrepreneur, are you promising your customers clean data regardless of the source? Are you promising AI magic? Are you promising a maximum failure rate?
From an engineering standpoint, how will you deal with portals changing their frontends and breaking your scrapers at any time?
I cannot know what you will do in response to these pressures, but I do know that the temptation will exist to build a system that puts a human in the loop to manually collect data from portals, to manually evaluate scrapers, to manually sift through the data and figure out what kind of Machine Learning models you can use to make your business function more effectively.