Hacker News Reader

Comment by mankash666 | Hacker News Reader

Just curious - how's a raw SEC filing preferable to a reliable article summarizing it in non-legalese, providing context with the competition, etc.

Other than lawyers and economists, does anyone ACTUALLY prefer this raw filing?

EDIT: Adding my preferred link: https://www.cnbc.com/2018/02/23/dropbox-ipo-form-s-1-prospec...

View on HN

I always find juicy information in the S1 that doesn't get reported on right away. Off the top of my head:

* Reliance and risks of Zynga in the Facebook S-1

* Customer acquisition costs in the Blue Apron S-1

* Growth specifics and positioning of algorithms in the StitchFix S-1

* Infrastructure costs in the Snapchat S-1

Besides, an S-1 filing is not written in legalease, it's written in plain language. One of the target audiences is street investors so it's meant to be accessible. I'm looking forward to digging into this one.

This is my biggest concern with the Dropbox platform summed up in the filing:

* Our business could be damaged, and we could be subject to liability if there is any unauthorized access to our data or our users’ content, including through privacy and data security breaches.

They have made progress. They managed to get SoC II compliance for all of their offerings. They now offer HIPAA compliant hosting as well.

Not that long ago though (circa 2013) I remember a series of articles that made it clear that DropBox employees had access to customer data.

That spooked me enough to recommend folks pair it with https://www.sookasa.com/ if they were going to use it.

Dropbox, GDrive, Box, OneDrive, etc. aren't using zero-knowledge encryption, so it must be technically feasible for them to access user data. If a company has a forgotten password reset feature, it's a good sign that it's possible for them to access your data.

You have to trust the company providing the service, right? Of course in practice, accessing user data should be tightly controlled and require good business reasons and levels of approval.

Zero-knowledge alternatives like Spideroak exist, but this approach makes them sacrifice features. (and doesn't appear very popular based on market share)

It's not as black and white as all that. In the early days, it was probably a trivial operation for any employee to examine any customer's dropbox content. Hopefully these days the prod machines and backups.are walled from all but a rotating team of SREs, whose own actions on them are subject to audit.

Early at my days at Syncplicity, (a Dropbox competitor,) I specked out what was needed for true client-side encryption with no ability to decrypt on the server. It's very easy to do, from a technical standpoint.

(We solve the problem by letting our large customers run their own servers, with their own authentication via single sign on.)

The problem is that the user experience for client-side encryption is awful! Every shared folder will need its own key, and users would need to manage and share their keys outside of our system. That is not sustainable.

But then the major feature set breaks down. Want to access your files in a browser? Not with client-side encryption. Want to email someone a hyperlink to a file? Not with client side encryption.

The major lesson is that the world operates on trust. We can only stay in business if our customers trust us.

> The problem is that the user experience for client-side encryption is awful! Every shared folder will need its own key, and users would need to manage and share their keys outside of our system. That is not sustainable.

But then the major feature set breaks down. Want to access your files in a browser? Not with client-side encryption. Want to email someone a hyperlink to a file? Not with client side encryption.

I do all of this with Boxcryptor. I might be misunderstanding you - do you mean decrypt it without first downloading it from the browser? Because yes, that’s not strictly possible.

But Boxcryptor implements a small wrapper around directories and generates a public/private key pair tied to email addresses. You can client-side encrypt a file with your - or anyone else’s - public key by moving the file into the directory. You can also change the file’s encryption to add or revoke access by multiple users.

If you wrap Boxcryptor around your local Google Drive, Dropbox, Box, etc. directory, it automatically client-side encrypts, then uploads new files. Then you can share a hyperlink to share encrypted files without exchanging keys with anyone. The usability is so great I’ve been able to use this with non-technical clients. You can even use your own key pairs.

There's also no deduplication with client-side encryption.

In the traditional model, yes. But if you're willing to make sacrifices... see previous discussion on this topic when it came up with Mega, de-duplication, and client-side encryption: https://news.ycombinator.com/item?id=5084261

Doesn’t homomorphic encryption allow for this?

http://ieeexplore.ieee.org/document/7255226/

No. It doesn't.

Can you explain?

The whole point of encryption is that you cannot meaningfully compare 2 pieces of plaintext.

Homomorphic encryption doesn't change that.

The only way to compare plaintext is to decrypt the whole thing. So either you must trust a centralized org (like dropbox today), or you must trust a single centralized key (that could be done with homomorphic encryption).

(Also the best homomorphic algorithms still make small programs take days to execute)

Consider a scheme in which:

Each user generates a symmetric "user key", kU.

The plaintext of each file (or without loss of generality, block of data, etc.), pFile, is encrypted with a randomly generated symmetric key, kFile, producing the ciphertext cFile. pFile is also hashed with a cryptographically strong hash, producing hpFile. kFile is then encrypted with hFile, producing ckFile. The user encrypts pFile with kU, producing chpFile. Finally, the user takes the first N bits of hpFile (for N on the order of, say, 16 or 32), producing hpFileTrunc. The user then submits hpFileTrunc to the server.

The server is, semantically, just a list of 3-tuples: (cFile, ckFile, hpFileTrunc).

The server sees if it knows of the existence of records with the same hpFileTrunc value as the client's submission. If so, it returns them to the client.

The client then tries, for each record returned by the server, decrypting ckFile2 with the client's hFile value, potentially producing kFile. If this is successful, the client then decrypts cFile with kFile, producing pFile. Finally, it compares this pFile to the original. If it matches, a match has been found, and the client exits the loop. If not, (or if either of the two decryption steps failed), it continues to the next record the server returned. If there are no more records, the client instead submits the tuple (cFile, ckFile, hpFileTrunc) to the server, which stores it.

Finally (whether or not a match was found), the client stores chpFile locally, to be used when retrieving the file.

To retrieve the file, the user decrypts chpFile with kU, producing hpFile. They truncate hpFile, producing hpFileTrunc, and submit it to the server. They perform the same process described earlier to retrieve the matching pFile.

(Note: truncation may also be replaced by, or combined with, a second round of hashing.)

With this scheme, assuming secure primitives (authenticated encryption and hashing), I don't believe it's possible to learn any information about a file unless you already have its contents.

So the server can tell if you're accessing (storing or retrieving) a particular file if and only if the server knows what it's looking for.

TL;DR: you can totally construct a scheme that allows meaningful comparison of plaintexts!

But... this is probably a bad thing. Comparison of plaintexts is a vulnerability: the server being able to see who's storing a particular "bad" file has a real impact on privacy. And likely more subtle impacts, too...

The whole point is to allow for comparison of large plaintext files that are stored by many users. Think of mp3s, or large avi files, or, say, a linux kernel image, or ...

> The server sees if it knows of the existence of records with the same hpFileTrunc value as the client's submission. If so, it returns them to the client.

And by doing this, provides a way for clients to verify if any user on the file storage server has this file. So if I wanted to know if your mozilla thunderbird has a mail I have the source to, I simply try to store this and get these duplicate records.

Most people would consider this extremely unacceptable.

> The client then tries, for each record returned by the server, decrypting ckFile2 with the client's hFile value, potentially producing kFile. If this is successful, the client then decrypts cFile with kFile, producing pFile. Finally, it compares this pFile to the original. If it matches, a match has been found, and the client exits the loop. If not, (or if either of the two decryption steps failed), it continues to the next record the server returned. If there are no more records, the client instead submits the tuple (cFile, ckFile, hpFileTrunc) to the server, which stores it.

Why would the client have the keys to files stored by other users ?

Unless you mean that you can only deduplicate within a single client, in which case that's of much more limited use (and I might add, your encryption scheme is way more complex than it needs to be).

> And by doing this, provides a way for clients to verify if any user on the file storage server has this file. So if I wanted to know if your mozilla thunderbird has a mail I have the source to, I simply try to store this and get these duplicate records.

Yes. This is the reason you don't want this property (being able to deduplicate encrypted files)!

But you can provide it, while still providing meaningful security against other attacks.

The client has the keys to files stored by other users because the keys are the hashes of the plaintext, and the client can hash its own plaintext when it has the file.

(Note a trivial modification to this scheme, solely client-side, allows for certain files to be totally secure, with the cost of them being exempt from deduplication)

> The client has the keys to files stored by other users because the keys are the hashes of the plaintext

Personally I find only people explicitly authorized have the key to be the whole point of security. And you're suggesting this as a solution to the problem that organizations providing file storage could see what files you're storing.

Under this scheme, it wouldn't just be that organization, but everybody who is a client, that could see what files you're storing (or at least verify if you're storing a particular file or not)

So I find your assessment:

> But you can provide it, while still providing meaningful security against other attacks.

Very dubious indeed, especially given the context of securing centralized file storage, where the whole point would be to deny others access.

I mean it's a true statement, because you don't specify what "other attacks" are.

I posit that given that this system leaks the plaintext of your files I find it strictly worse than just giving Dropbox or Microsoft access to my files.

> Under this scheme, it wouldn't just be that organization, but everybody who is a client, that could see what files you're storing (or at least verify if you're storing a particular file or not)

You can do this today, with Dropbox or whatever else- anything that does deduplication, if it saves bandwidth by not asking for files it already has.

You can't tell who is storing a particular file- only if anybody is. Does this leak information and impact privacy? Yes! But it still provides other useful properties.

If you have a copy of a file, you can see if anybody else does- a boolean value. (And if the server is malicious, it can tell who does (if it logs).) If you don't have a copy of a file, you can learn absolutely nothing about it.

So, for example, if a user uploads a, uh, personal image to the service- with Dropbox, in theory (they likely have strong organizational and technical controls against this sort of thing, mind you) if the server is malicious they can view that image.

With this scheme, the server can't.

On the other hand, if you, say, save a file containing only your social security number- or a similar low-entropy value- the server can crack the hash and decrypt that file. That's the price you pay for being able to deduplicate.

(Perhaps one could only deduplicate large files- thus handling the case of movies, music, Ubuntu ISOs, large system files, etc. To implement selective deduplication- if you want a file to not be deduped, replace all uses of its hash with, instead, a unique random value to identify the file. Server requires no modification.)

For a single user with no need to share access, you can also just stick everything in a VeraCrypt vault stored on Dropbox. Dropbox seems pretty good at updating only the parts of the vault that have changed, versus the entire (sometimes huge) vault file. I've heard OneDrive updates the entire vault file every time, although I haven't experimented with it myself.

Dropbox's client uploads binary diffs to make updates to things like your VeraCrypt value efficient. Using a modified librsync last I heard. Sounds like OneDrive is missing this feature.

https://www.dropbox.com/help/syncing-uploads/upload-entire-f...

https://github.com/dropbox/librsync

The point of that section of an S-1 is to try and disclose every possible risk so that investors can't accuse you of hiding risks later on.

So, when quoted out of context it sounds really extreme.

I wonder how spideroak.com compares.

Do you have a 5-second summary of what you mean by "Growth specifics and positioning of algorithms in the StitchFix S-1"? Just the fact that they use algorithms to tailor individual boxes, or do you mean something more specific?

I currently work at an e-commerce company and there has been a ton of debate around how "algorithmically driven" Stitch Fix actually is. The general feel in the space from non-technologists is that computers cannot do this job well now and won't be able to do it well in the near future. Stitch Fix makes it a major brand point that computers are an important part of the process. So the real question is - are they making this point because it's true or because it helps their valuation (tech co. 5-10x multiples instead of ecomm 1-4x multiples).

The way Stitch Fix talks about it in their S-1 makes it seem like the latter is the priority. I'm not yet convinced that the practical value driven by algorithms at Stitch Fix is up to par with how much they talk about it.

I was interested in growth to understand both their growth rate but also to get a feel if it was driven by increasing user acquisition costs like Groupon, Blue Apron, etc or if it was organic.

I've worked in fashion before and I'm a machine learning pratictoner now.

I never tried myself but it seems quite feasible to build a decent profile of someones taste in fashion from a bit of data.

Fast fashion gave us the logistics (no more 9mo from concept to store). But Zara and friends still supply only the major trends. We're still missing for someone to reliably market the "long tail".

> I never tried myself but it seems quite feasible to build a decent profile of someones taste in fashion from a bit of data.

I've thought about this as well. How would you personally try to build this profile for users, then market to them based on it?

You could initially present a user some images to assess it's preferences and use some recommender system (collaborative filtering), a la Netflix.

That could give you an starting point. But I believe the main issue is that fashion products have, by definition, short shelf life, so you can't run the algos on SKU data. Then you can use deep learning on product images + user categorical data to try to predict preferences, maybe simple binary classification?

I guess using images as input should give better features than textual description.

> You could initially present a user some images to assess it's preferences and use some recommender system (collaborative filtering), a la Netflix.

You would have to tag the hell out of these photos, right? Disambiguating preferences is the challenge -- the user may have liked images #3 and #7, but why? Specific items, or the color palette, or the silhouette, or just the model? A post by Chicisimo on the front page addresses these hurdles [1].

I've also seen some of these image recognition apps in action -- they pick up on patterns and color very well, but struggled with silhouette.

[1] https://hackernoon.com/how-we-grew-from-0-to-4-million-women...

Seeing what people themselves like doesn't sound a good way to determine what fashion they'd buy. Fashion is about a consensus largely established by a cabal of sellers; users surely want to find out what is fashionable? Fashion is mainly about what other people like.

Oh, that's largely a myth. These seller do have some influence, but it's much less important than what they want you to perceived. Fashion tastes comes from a lot of sources and some is part of your identity.

That's part of what makes this industry hard.

Ask them for access to their Facebook photos, get them to tag themselves and then build an embedding of their fashion choices.

> Stitch Fix makes it a major brand point that computers are an important part of the process

(which even if you disregard everything else is a really good line to take if you're after recruiting good machine learning engineers!)

You hit the nail on the head. They also reveal this strategy through their data science "thought leadership" posts, which are seemingly meant to appeal to data folks (own your code! add value through modeling! don't worry about collaborating with engineers!) but do not reflect the realities of industrial data science.

(Note: I'm biased and tweetstormed about Stitch Fix's most recent blog post earlier today. https://twitter.com/achompas/status/967085860763193345)

Chris Moody knows more about this than anyone in the world, and everything he writes about on the Stitch Fix blog seems so far ahead of what other people are talking about I really do believe that they have a real technology advantage.

It seems similar to talking to people at Google in the early days. The thing that they cared about from an engineering point of view seemed weird and they language was alien. 3 years later the rest of the world hits the same problem and I remember the conversations and think "oh so this is what they were talking about".

Give us the dirt on this one!

There's nothing shocking and I think that bodes very very well for Dropbox. It looks like a solid foundation with great growth.

The standouts to me were -

* They cut costs on an absolute and relative basis for the last two years. This is fantastic and I hope the trend continues.

* I don't understand how the $112 ARPU number foots with their pricing. They are telling a story that "teams" is driving growth but on the surface that's not reflected in the ARPU number. There's some sort of promotional discounting that's happening that isn't exposed here. I hope that they are aggressively managing their promo strategy internally because unchecked it can tank a whole company (see GAP).

* No idea where they expect new users to come from given they have 500M accounts. Presumably people have 2+ dropbox accounts (personal + work). I'm interested to know how many unique active users dropbox has.

> Presumably people have 2+ dropbox accounts (personal + work).

I'd imagine there's quite a few with dozens, as they offer more space (up to a bit over 30 referrals) if you refer new users. I remember "referring" myself with a new email address whenever I'd need an extra 250 MB.

>> No idea where they expect new users to come from given they have 500M accounts.

500M accounts, but only 11M paying users.

What keeps them from making money (asking, not being facetious)?

If they maintain the current trend of lowering costs, keeping headcount growth in line with revenue, and continuing to achieve economies of scale in sales and marketing then they will show a profit in the next couple of years. They don't promise any of this in the S-1 because they need to be extremely conservative in their statements to the public.

To be honest I'm not super familiar with the comps to know how good or bad their numbers are relative to others. But just from their own reporting they look like they are on track. That's not by accident. It's very likely that constructing this trend has been a major focus for the company in the last few years.

Why infrastructure costs in Snapchat ? Doesn't look special ?

SNAP's infrastructure story in the S-1 filing was a mess. They had 2016 revenue of $404M with a cost of revenue of $451M. A 5 year, $2 billion dollar vendor lock-in to Google. They basically admitted that Google has them completely by the balls and it costs them $3 per user per year to keep the servers on. Both of these independently are very very bad, together it's a disaster.

Facebook was at $1/user/year in their S-1, Twitter was < $1.

From the SNAP S-1:

"We rely on Google Cloud for the vast majority of our computing, storage, bandwidth, and other services. Any disruption of or interference with our use of the Google Cloud operation would negatively affect our operations and seriously harm our business."

"We have committed to spend $2 billion with Google Cloud over the next five years and have built our software and computer systems to use computing, storage capabilities, bandwidth, and other services provided by Google, some of which do not have an alternative in the market."

They also committed to a 1 billion dollar deal with AWS soon after that: http://fortune.com/2017/02/09/snap-inc-signs-big-aws-deal/

For a B2B SAAS company...what's the ideal user cost of infrastructure? (I understand that it depends on the service..but a ratio of profit per user vs cost per user should be close no?)

I forget which report it was in but the average tech-focused startup spends 10-15% of revenue on infrastructure. Mature businesses spend ~5%.

The ideal cost is as low as possible without sacrificing future scaling needs or development velocity. At some point, you'll start to experience diminishing returns.

It usually goes POC->Cloud provider->Your own gear

apart from the bigger companies (like Fb), have there been any major SaaS companies (esp. B2B but I guess that's trying to be too narrow so B2B & B2C) that have moved from Cloud to their own Data Center? (I know Etsy comes to mind...but apart from them?).

Dropbox: https://techcrunch.com/2017/09/15/why-dropbox-decided-to-dro...

Github: https://githubengineering.com/evolution-of-our-data-centers/

Backblaze: https://www.backblaze.com/blog/our-secret-data-center/

Twitter: https://blog.twitter.com/engineering/en_us/topics/infrastruc...

LinkedIn: http://www.datacenterdynamics.com/content-tracks/design-buil...

FastMail: https://www.fastmail.com/help/ourservice/security.html

Stack Overflow: http://highscalability.com/blog/2014/7/21/stackoverflow-upda...

Wikipedia: https://meta.wikimedia.org/wiki/Wikimedia_servers

OpenStreetMap: https://blog.openstreetmap.org/tag/infrastructure/

The Internet Archive: https://www.theregister.co.uk/2017/11/16/head_like_a_memory_...

Gitlab tried, but didn't have the necessary in-house experience before they made the attempt: https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-t...

Instagram was migrated from AWS onto Facebook's infrastructure: https://www.wired.com/2014/06/facebook-instagram/

WhatsApp was migrated from IBM to Facebook infrastructure: https://www.cnbc.com/2017/06/07/facebook-planning-to-move-wh...

Hacker News and Pinboard (acq. Delicious) run on a single server.

It's not hard, but you do need to know what you're doing and have resources to do it (most orgs rent colo space in someone else's datacenter, they don't build their own). There's a reason AWS margins are so high (which leaves a lot of cost savings to be had when your workload isn't highly variable). Any questions, email is in my profile. I spent ~16 years building data centers, hosting environments, infrastructure, etc.

Many SaaS companies not only lack the ops experience needed to run their own infrastructure (which may be only problem of perception, for me running stuff on dedicated HW in colo center seems like less hassle than dealing with things like AWS) but also the common sense required to not over-engineer the scalability of their solution in the early phases (which falls squarely into the YAGNI teritory, as you can run surprisingly large stuff on two or three physical low-end 1U servers).

It surely depends on how much users pay for the service, and how high the non-software costs are.

But in any case, the examples given are B2C free to use products which are generally going to provide... not a ton of revenue per user.

I thought Dropbox's revenue mainly comes from it's business clients - B2B is more $ compared to B2C although B2C might be more profitable as customers might pay the $10/1TB and not really use that much anyways)

Their paying users have increased, but the revenue per user has decreased (based on the S1...which I assume is because of enterprise deals).

This is from the SNAP S1 not the dropbox S1

Note that the modern gospel is any net business dont give a crap about costs, only growth and the ability to raise money.

This has been explicity stated by the saas business ‘gurus’

So even at 3$ per user that goes lower pretty quickly.

Plus they get alliance w/goog. Aws is a force but if i had a choice id have goog as a best friend over amazon.

Preferably id build my own data center and keep those assets.

> modern

If by modern, you mean 2015. Things definitely changed by 2017.

Their infrastructure commitments are ridiculously high.

"In its disclosure, Snap has said that it is contractually obligated to “spend $2 billion with Google Cloud over the next five years and have built our software and computer systems to use computing, storage capabilities, bandwidth, and other services provided by Google.” Of the current losses at Snap, more than 80 percent of those funds go straight into Google’s pockets."

https://www.recode.net/2017/2/7/14526832/snap-ipo-snapchat-s...

https://www.forbes.com/sites/quora/2017/02/22/could-snapchat...

https://www.cnbc.com/2017/02/09/snap-cloud-bill-aws-google-c...

EDIT: @dfee How that revenue is recognized is usually based on when the services are delivered, but I am not an accountant.

Imagine the sales commission on that one. “Here’s a $10B - Closed Won”.

When talking about deals that are the enterprise valuations of Fortune 500 companies, do you value the sale as if it were an acquisition? Or, some other way?

Yeah except imagine instead when you should be due that commission but then they find a creative way to bake it into a new cushy position that they carve out just for you (with no more comms on other deals) and they pay that comm out to you over 5-10 years. And in the process, putting you in a position you dislike in an effort to hope you'll leave some of it at the table.

$2 billion, not 10.

Still a good reason to become a AWS or GCP sales engineer.

Lots of others have chimed in with examples of interesting tidbits to be found in "raw" securities filings that don't get included in press summaries. My personal favorite is the "efficient factoring" risk factor from an old RSA Security, Inc. 10-K[1]:

The Company’s cryptographic systems depend in part on the application of certain mathematical principles. The security afforded by the Company’s encryption products is based on the assumption that the “factoring” of the composite of large prime numbers is difficult. If an “easy factoring method” were developed, then the security of the Company’s encryption products would be reduced or eliminated. Even if no breakthroughs in factoring are discovered, factoring problems can theoretically be solved by a computer system significantly faster and more powerful than those currently available. If these improved techniques for attacking cryptographic systems are ever developed, the Company’s business or results of operations could be adversely impacted.

[1] https://www.sec.gov/Archives/edgar/data/932064/0000950135000...

Any mention of the NSA paying them to keep a dodgy RNG in there?

https://www.reuters.com/article/us-usa-security-nsa-rsa/excl...

This may not be a very well-received comment due to the securities fraud he has been convicted for, but in Martin Shkreli's YouTube lessons on investing (Really aimed towards future day traders / full time investors, but good points are made) he says the sec.gov site is the best place to take in content and he showed after you get used to the ( ugly ) government site layout, you can actually get to the information you need quickly. But day traders and full time investors probably fit your category of economists.

It's weird though that people who actually cause their investors to lose money go Scott free because of connections and to my understanding shkrelis investors all made huge profits, one going so far as to say it was the best investment of his life.law is law but clearly there is something wrong here.

>Other than lawyers and economists,

Investors. The prospectus filing is informative and you don't have to read it all to get good idea of the company.

The summary from CNBC omits all the details and you can't even trust it to have the numbers correctly because if they screw it up, it has no legal consequences for them.

As a rule I prefer an original source to an interpretation of a source by someone who gets paid based on the number of clicks generated.

well, there's less chance of advertisements, and it gets to the point rather quickly

i am not an economist or lawyer and prefer it

i don't have to worry about a writer/editor injecting personal opinions that i could care less about

> and it gets to the point rather quickly

In a mere 160 pages. Unless you know what to look for it most certainly does not get to the point rather quickly.

then i guess i know what to look for to satisfy myself, I'm not speaking for everyone here, just responding to OP's question

Learning curves can have solid payoff.

Primary sources are generally preferable to breathless editorializations, especially when - as here - they are not in fact written in professional jargon. Any adult of average intelligence and education should be able to get the gist of a prospectus.

Feel free to link to "news" (read: opinion) posts about the filing.

SEC filings aren't hard to read after you've been through a few and know what to look for.

I was really excited to see they cut their infra costs while supporting more revenue (bottom of page 71), that bodes very well for their future prospects.

@ultrasaurus indeed. Wall street wants us to stay away from sec filings. However they are structured data. I am running a project to make sec filings easily searchable(today) and understandable(in the future) at https://www.instant10-k.com/ We currently have 10-k & 10-Q filings for US companies and 6-K filings for foreign companies.

The risk factors section is pretty close to a good summary.

> Other than lawyers and economists, does anyone ACTUALLY prefer this raw filing?

Apparently they do, since it's at the top of HN. If they didn't, it wouldn't be at the top. Alternatively, my guess is that many HN people saw this document, upvoted it, and then went to Google for more context.

most everyone in the finance industry does

it contains the "source" facts with limited embellishment. there are all kinds of regulations that essentially result in SEC filings being fairly standardized, limited-BS documents. you dont have to worry about distilling commentary and opinion with fact, generally

for commentary and context, equity research reports are generally helpful as long as you're aware of the inherent bias. articles online can also be helpful, but generally the quality varies, and you have to spend commensurately more time fact checking

once you learn how to ctrl-f the right terms and understand the general skeleton of each type of report, it is actually pretty easy to find the relevant information

Reply on news.ycombinator.com