jjguy

Thank you for posting - I’ve enjoyed reading the outpouring of history and stories and hope it brings you the same sense of wonder it has me. Godspeed to you and your family.

Similar to all the rest of you HN lurkers, especially the grey beards - thanks for being here and thank for keeping the “hacker” in “hacker news” alive.

The beginning of the end, the moment when thr DMCA jumped the shark (for the broader world, not us tech geeks)

Remember that NYT article came out in 2018 that painted such a terrible picture of Elon (1)? A year later it showed up on my Facebook feed as a paid advertisement. Who pays to promote a year-old news article?

FTA:

> I assumed that device manufacturers update the software in their device about every month...he said they do it annually.

Those devices are at least _getting_ updates - there is a long tail of devices whose operational lifecycle [far] exceeds the vendor's support timeframe - in other words, they don't get patches at all N months after release.

The solution to these problems is straightforward - we've been managing it in software for a long time. EOL OSes, Long Term Support (LTS) OS releases, etc - but the device manufacturers are not as mature, and have not been making natural progress to do so.

And since this is HN - there is a startup hidden in the midst of all of this: an enterprise-grade IoT OS that "does security right." Sell to the device manufacturers, allow them to market it as "enterprise-ready" or some such. If the FCC guidelines here are approved, there will be a suddenly increased demand!

1 - https://www.wsj.com/articles/whats-in-a-hedcut-depends-how-i...

2 - http://www.hedcut.com/

The monthly subscription carries no commitment and you don’t lose data when not subscribed. So don’t think of it as “$xx per month commitment is so expensive!” But instead as “I’d happily pay $20 this month to support the research I want to do. Next month, we’ll see.” I’ve subscribed / stopped / resubscribed several times over the years as the time I have ebbs and flows.

Amazon sees the same potential - and risk - and has been quietly iterating for over a decade in the segment.

If you want to go seriously explore it as a product, I’d start with a deep dive study there and develop a few theories how you think you could be different enough to blow it wide open.

IANAL, but I negotiate a lot of enterprise SaaS agreements. When considering the SLA, it is important to remember it is a legal document, not an engineering one. It has engineering impact and is up to engineering to satisfy, but the actual contents of it are better considered when wearing your lawyer hat, not your engineering one.

e.g., What you're referring to is related to the limitation of liability clauses and especially "special" or "consequential" damages -- a category of damages that are not 'direct' damages but secondary. [1]

Accepting _any_ liability for special or consequential damages is always a point of negotiation. As a service provider, you always try to avoid it because it is so hard to estimate the magnitude, and thus judge how much insurance coverage you need.

Related, those paragraphs also contain a limitation of liability clause, often at capped at X times annual cost. Doesn't make much sense to sign up a client for $10k per year but accept $10M+ liability exposure for them.

This is just scratching the surface -- tons of color and depth here that is nuanced for every company and situation. It's why you employe attorneys!

1 - https://www.lexisnexis.com/lexis-practical-guidance/the-jour...

Not only will you learn a ton about shipping product in a startup (risking someone else’s money), but you will also grow your own network - including non-technical founder types.

This model worked for me. I spent twelve years with the US federal government. I had great tech and business skills, but it was all federally focused.

I joined the founding team of a startup, using my tech background. We got acquired 15 months in by a later stage startup. The resulting company IPO’d four years later. I joined another startup in the same industry as CTO just after their Series A, we got acquired two years later. Then I launched my own - 8 years after leaving the federal government.

It is a ton easier now, with all the relationships from the last two. (Not to mention the depth of knowledge on everything)

It is easy to think startups are all about the product & technology. But it is so much more!

This applies to every "connected device:" printers, cell phones, home routers, refrigerators, thermostats -- you name it. Michael DeGusta did a great infographic demonstrating this for Android phones in 2011 [1, 2]. Sadly, this hasn't materially changed in the eight years since. Just this year, Google added new terms to the Android license requiring security patches, but even then only for "popular devices." [3] Imagine those dynamics in the secondary and tertiary markets of printers and refrigerators.

As an industry, we've been to this rodeo before. The advancements we've made in operating system and core applications security over the last 20 years have more about patching speed and agility than shipping fewer bugs. However, those areas have backing and control from Apple and Microsoft, managing the end to end ecosystem. There is not a similarly equipped manufacturer of embedded operating systems with the scale to provide post-sale/post-deployment patching infrastructure.

Since this is Hacker News, I'll point out the enormous opportunity to anyone who can address that problem. Can you provide an "enterprise class embedded OS" to device manufacturers and address post-deployment updates? Can you provide infrastructure device manufacturers can use to manage post-deployment updates themselves? Do you have a better approach to it? There's a burgeoning multi-billion dollar market waiting for a few leaders to take it over.

1 - https://theunderstatement.com/post/11982112928/android-orpha...

2 - img link is broken in his post, the graphic itself: http://media.theunderstatement.com/016a_android_orphans.png

3 - https://www.theverge.com/2018/10/24/18019356/android-securit...

That exercise is excellent to teach kids how to count in binary and why computers are based on it.

Design your data schema first, then design your queries and finally your data lifecycle pipeline. Run some estimates on the order of magnitude for inserts, query rates, query types and storage sizes - then compare those numbers to the real-world perf of the various graphdb solutions. In general, compared to more typical solutions, you have more expensive inserts, query costs and storage sizes in exchange for more expressive queries. There aren't many application where those cost tradeoffs make sense.

Source: Twice now (2012 and 2018) I've reviewed available graphdbs for storage of enterprise security data when doing the initial platform technology selection. Both times the team fell back onto more traditional approaches.

I searched online, had family in the medical research hunt for papers and finally made an appointment with a renowned allergist in DC - I flew there just for the appointment.

I left disappointed. My allergy is too unusual, there is no research available. What I need does not exist. For the common allergies - like kids and nuts - there are plenty.

The net/net from my experience is seek out an allergist, and be very specific in your requests.

In addition to kenneth’s very practical perspective on the technical challenges, the other consideration is that you are simply not worth the trouble.

Grabbing audio, video or picture content worth blackmailing someone with is time-consuming, above and beyond the technical challenge. There is not an at-scale monetization path for an attacker to make it worth his time for the general user.

High-profile folks like Comey and Zuckerburg change that decision calculus - they are likely to be individually targeted for many reasons. You are not.

Gibson had a vision of an Internet with decentralized social media, including decentralized code execution, 35 years ago, and we have not yet realized it - or anything remotely close.

1- https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...

https://twitter.com/id_aa_carmack/status/193480622533120001

1. Compromise is inevitable 2. Default-allow products always fail 3. 1 and 2 are not opinion or marketing spin, just simple truths 4. As an industry, we are still learning 1 and 2

Security is slowly shifting from an administrative IT function to an operational function. In IT, the business value comes from the products and people are a tax required to administer the products. In security operations, the business value comes from the people, products are just tools in their toolbag. [c]

Keep walking this dog and you realize basic IT activities for core infrastructure are critical for security, to the point the CIO will report to the CISO -- unless the CIO steps up. [b]

So - in short - your frustrations are accurate, but the winds are shifting. Companies will incresingly value top people for their internal staff/blue teams. It's going to take a few more years, but I believe it is inevitable.

[a] - https://www.linkedin.com/pulse/my-four-cybersecurity-princip... [b] - https://www.linkedin.com/pulse/cio-report-ciso-j-j-guy [c] - https://www.linkedin.com/pulse/cio-report-ciso-why-j-j-guy

Also written in the 60s, it reflects upon their experience with how to convey uncertainty in prose, in a meaningful and consistent manner. Imagine an analyst writing a two pager for the President, who is going to use it to decide go/no go on a covert action. It's a big, ugly and complex situation - with a mixture of highly confident assessments, educated guesses and total speculation. Synthesizing it into something simpler is The Art of Writing; doing so while not losing the anecdotal quantification of uncertainty of the discrete issues is a more unique skill.

If you are in a position where you write about uncertain situations, it's worth the read. I'm a security guy and frequently find myself in that role (think annual risk assessments and estimating the likelihood of a successful attack). It's been a go-to reference for many years to refresh my thinking.

- new cost

- depreciation per year

- increasing maintenance costs per year

The "F-150" assumption was used to estimate new cost and depreciation over time.

You should not discount the data based on a single model, but it is wise to recognize those three variables can diverge significantly between models - enough to change the outcome.

A lot of the teams employ contractors alongside the USG employees, with higher pay ranges.