81–90 of 127 posts
>Don't Talk to Corp Dev it sounds kinda edgy, especially that "corp dev" bonus points that "dev" seems to refer more often to "developer" than "development"
No one outside tech in this field would ever think of "Dev" as "Developer".
It's not edgy at all. It's just the name for the job. This is how people refer to themselves as. E.g. "I work in corp dev".
Earlier quoted context omitted.
I understand what TLS does, but an argument that "we live in a world of disinformation" is not a substitute for having a well defined threat model and for many websites, particularly sites that broadcast information or download binaries which might already be signed or have hashes distributed via alternate means, there does not need to be a threat that requires TLS to address it. Like it or not, it is up to the infor…
Like others have said, I agree that stating that TLS does not garuntee security. But, plain unencrypted HTTP does mean insecure. For a good discussion into why _all_ websites should use HTTPS, and the many different ways that not having the connection secured is actively harmful and why should not be done in the modern era. https://www.troyhunt.com/heres-why-your-static-website-needs ... Not having your site as HTTPS…
No, it does not. These are bold statements made without evidence that your personal preference should override the threat model of information owners -- that they must worry about something they have looked at and chose not to view as a threat. I once had a website that had Hebrew drills, so you could look up the construct forms of various nouns and other grammatical information. I did not care if an attacker in a coffee shop or other public network was trying to intercept that site and give a victim incorrect Hebrew words. It was not a threat in my threat model. So I did not use https. My website, my information, and I know the threat model to use. My site would not have been more "secure" if everything was encrypted. There would be no meaningful benefit to anyone from me doing that, and being a security professional, I was not interested in security theater, but only actual security.
> We should _never_ expect regular non-technical users to have all of their threat models in mind
Correct. That is why the threat model of the information owner is what determines what a site serves. Information owners generally do have a threat model in mind. It is, after all, their information, their website, and their security policies that matter. They are the ones in a position to decide whether they care if their http responses are altered or not in targetted attacks on public networks. Obviously a site that accepts credentials or displays sensitive information is very different from a site that displays verbal patterns. The fact of the matter is that in many cases, there is no need to care and no real security benefit to encrypting the site.
>"What happened to Don't be Evil?" I asked. "I don't think corp dev got the memo," he replied. Why is it that every company that starts with good intentions eventually succumbs and becomes that which they claimed to not like?
But people in groups also don't have morals or ethics because being in the group allows them to not take responsibility for their actions, ie, "the group decided", not "I decided".
Earlier quoted context omitted.
Like others have said, I agree that stating that TLS does not garuntee security. But, plain unencrypted HTTP does mean insecure. For a good discussion into why _all_ websites should use HTTPS, and the many different ways that not having the connection secured is actively harmful and why should not be done in the modern era. https://www.troyhunt.com/heres-why-your-static-website-needs ... Not having your site as HTTPS…
> I agree that stating that TLS does not garuntee security. But, plain unencrypted HTTP does mean insecure. No, it does not. These are bold statements made without evidence that your personal preference should override the threat model of information owners -- that they must worry about something they have looked at and chose not to view as a threat. I once had a website that had Hebrew drills, so you could look up t…
Except it's often the user who is on the hook for the risk. You mustn't outsource your threat model to someone who doesn't necessarily care about you. Unless you're a sufficiently qualified security expert to be able to judge whether this instance is safe, the only reasonable policy is to never connect to a http website (or one that uses cloudflare, since they offer fake https to their customers).
Is there a reason he doesn't have HTTPS on his site? Firefox throws up a giant warning when I try to visit.
I actually sent him a cold e-mail in Nov/2020 on that matter to which he promptly replied (in less than 1h) that his site "just doesn't have https". So he's aware of that. IMHO it'd be a small effort for improving his readers experience (and security).
I wonder how analogous this is to “don’t talk to VC associates” advice. Corp dev is interested in buying a company, any company, at a low price but even once corp dev is sold they’ll have to sell the deal to someone who matters. People confuse “this corp dev person is interested” with “this company is interested”. If you’re not actively looking to sell, _definitely_ don’t bother taking the meeting unless there’s a ch…
Does this person look good in his job if he does a deal with me, or can he look good in his job if he just meets with a bunch of people like me?
VC associates and others who look good merely from having lots of meetings (deal flow) are much more likely to be wasting your time.
Earlier quoted context omitted.
Wouldn't acquisition talks be covered in NDAs to prevent precisely this?
Most NDAs do include prohibitions on either disclosure of information or use of information (for any purpose other than the contemplated transaction). But some big SV companies refuse to include the second prong, which means they won’t tell anyone your secrets but are free to use them to squash you. Intel’s NDA is notorious for this.
I've worked with (but not in) CorpDev in two large enterprises, and I've had a startup acquired via CorpDev. Paul is overstating his case to the point of it becoming bad advice. Just like there are good VCs and bad VCs, there are good CorpDev teams and bad CorpDev teams. The mistake many founders make, however, is confusing the quality of the brand with the quality of the CorpDev team. The best approach is not a simp…
For a founder who doesn’t otherwise have interest in talking to corp dev, what is this if not a waste of time?! This 100% takes focus away from building your business.
Earlier quoted context omitted.
I don't doubt it for a start up... but I also wonder what value that is vs. 18 months of work and turn that into a deal that is really a loss, and the customer struggles to use the product ... and now you've got a big dominating customer who is going to continue to eat up time ... I wonder how many profitable customers could be had in that time.
I've lived situation. Large co bought one of our systems, as their internally built systems weren't up to the task. We sold it at effectively break even. This was in part due to my business partner's view that we could turn this into a bigger deal. Well, no. We couldn't. The "customer" wanted specifically to see how we did what we did, in order to copy this. It took me a while to figure it out, but I did, and we woun…
Can you elaborate? Is this because they'll infringe anyway, then use their big legal budget to game the system?