> If we summarize something in a legally ambiguous way have we undermined the original intent?

I share some of your concern. A written contract (including ToS) is supposed to capture an agreement between two parties, so if they later disagree on what was agreed, there's an unambiguous record. If one party isn't clear on the terms as written (say, because they only read the legally-ambiguous summary), then it's hard to say there was an agreement.

Unfortunately, these goals are often at odds: many websites/services feel the need to include lots of boilerplate to shield themselves from liability, and in the pursuit of precision, legalese is often jargony and inscrutable. In my opinion, we'd be better off if people didn't disclaim so much liability and were willing to take a chance on clearer but less established language. But there are societal reasons for those things that I can't really fix as an individual.

So, ideally, terms should be both legally precise and short/layperson-readable; in practice that's often not possible, which means any readable summary is necessarily ambiguous (otherwise, we'd just replace the terms with it). Given that existing ToS are often not layperson-readable, I think they're already failing to establish agreement, so I think that summaries, while clearly a non-ideal compromise, are a net positive.

> You start with the description being more of a goal for that section, than sporadically start switching to the "short version" of what your terms are.

I agree it could use more consistency and I agree the "shortest version" is better (many "goals for the section" barely have more meaningful words than the section title alone). It is how it is because summarizing is hard and our time is not unlimited. Definitely open to future revision.

For what it's worth, there is a "short version" at the top of each individual section; the table at the top is a further summary (hence "shortest" above). Given more bandwidth, I'd make each of the table sections expandable to show the "short version" as well.

> Also some minor issues with bolding some headers 4. Project Termination 4. Survival

Thanks. I suspect this has to do with the conversion from markdown (as they were written) to hamlet (for display). Opened an issue to track it. https://gitlab.com/snowdrift/snowdrift/-/issues/186

> As well as inconsistently formatting the short version. (I prefer the all bold version to help clearly show where the short part ends)

This was intentional; the bolded summaries are for two sections (warranty and liability) which, IIRC, are legally required to be emphasized. Usually that's done by putting the sections themselves in all caps (ugh), with the side effect of making them unreadable. GitHub's terms, on which ours are based, have a bold "Please read this section carefully; you should understand what to expect." in that section after the summary; we opted to just bold the whole thing. Maybe that's confusing, though, and we should just follow their lead.

> https://www.pritact.com/privacy-policy.html

I agree, it looks nice. :) Especially, I like putting the form of data collected as the first words of each sentence under "what we store". Having our "If you…" part first makes it read better but harder to skim. I'll propose changing that next time we modify the policy.

Aside, I looked at the home page and while I understood what your service does, it wasn't clear to me how it was delivered (app? website? dedicated hardware (joking)?). I don't think I would have figured it out if I hadn't seen a reference to app.pritact.com in the privacy policy.