In my opinion this is mostly self-inflicted by Microsoft.
Sure some push for web-based solution has moved a lot of people away from desktop applications, but even before that Microsoft muddied the waters of native UI development.
Moving from User32.dll and GDI to GPU based rendering with WPF, might not have been the worst idea - and WPF is still going strong - but it's a clear cut, leaving old apps un-upgradable. So if companies need to eventually rewrite it, will they stick with desktop apps or move to "web apps"?
Unfortunately, Microsoft didn't stop there, but we've since seen a bunch of different attempts at new Windows UI libs to the point, where nobody trusts Microsoft anymore (remember Silverlight?) and everyone else is left confused by the chaos of an ecosystem.
There are 5%-ish code are contributed by other people, I feel really bad for not sharing the money with them. Anyway, I wish that GitHub offers the option to sponsor a project, not one single maintainer.
Honestly looks like a scam and your description of it makes it even sound more like one. Most of those fields you return in that docs page have nothing to do with k or qs and are equity pricing data you are buying from another third party.
Not a knock just being honest as it looks like you just don’t know so maybe this helps. Here is an example of a real company that scrapes k/q docs.
Question was about financials. The service is not only limited to q forms, obviously. Historical data or government trades are not available there. So you want me to share with the Internet all my data sources just to prove you it's not a scam?
You seem to be trying to promote a service and throw weird accusations that the service looks like a scam without even trying it, which is shameful tbh.
Again no disrespect, it’s blunt honesty. I am not promoting anything. I live in the US and work at the intersection of finance and software. Your site has quite literally zero details on it. It’s a bunch of fluff on the landing page. Why would anyone signup without any information about what they are signing up for. Your response to a question about sourcing it’s odd. You only mention 10qs which you built a scraper for but the docs you linked to don’t really have much in the way of 10q data. Some surface metadata but none of the guts of a 10q. Most of the data you linked to is market data that you would have to be sourcing through a third party. It’s just an odd response for someone like me who works in the industry that you mention 10q but none of the data is really what I would consider 10q data.
Wish you luck but don’t take honest opinions from someone who buys significant amounts of financial data as someone trying to promote a service. Just linking someone I would consider a competitor to yours in the Edgar space.
The question is about financials and nothing you linked to is about financials.
No disrespect but still accuse someone of a scam, right?
I specified clearly in the description of this service that I deliver financials, historical or congress/senate trades. I think it's obvious for someone working in finance that the last two cannot be fetched from quarter or annual forms. Things like revenue, eps, ebitda, pre/post earning moves (those use last, open prices too), are strongly-related to 10Q though.
I really don't care whether you like the landing page or not. I have two B2B clients for this API and 0% churn so far, which is the best metric I need to track right now. I will stop responding to this thread since I don't think it's productive for any of us.
When you do a check on https://haveibeenpwned.com/Passwords nothing is sent to the server. Instead the password is hashed locally and a list of the hash range is downloaded, which contains all the hashes and the number of occurrences.
The server doesn't receive the password, neither in plain-text nor hash form.
It would be easy enough to add this as a "secret" feature:
* user submits password
* gets hashed client side
* server compares it against stored hashes
* server also re-hashes the stored hash, and compares it against the hash received from the client
This would effectively mean that either entering the password, or the password hash would correctly match, since when entering the hash you are effectively "double" hashing the password which gets compared to the double hashed password on the server.
The upside is that users who don't understand hashing or don't feel like opening a sha256 tool wouldn't have to change their behavior or even be confused by a dialog explaining why they should hash the input, while advanced users could find out about the feature via another channel (e.g. hackernews).
The downside would be that it adds an extra hash step to every comparison on the sever. It's hard to know how expensive this would be for them.
Care to explain how you can tell what scripts gp was sent for the page https://haveibeenpwned.com/Passwords and what scripts he will be sent on future visits?
I encourage you to still share your ideas and thoughts. It doesn't need to be as a blog, but in general. :)
Don't censor yourself out of fear of what others might think or misunderstand.
Many may get confused and some might not like it, but there may also be a small group of people who understand, which if you fall silent couldn't be reached.
reply