michaelw

vor 5 Monatendiscuss

Similar to LinkedIn's "verified" process, Porkbun uses a 3rd party: veriff.com. https://www.veriff.com/privacy-notice.

It appears that Veriff's data retention is set by their customers (in this case Porkbun). Porkbun's policy says that this information is deleted as soon as they have verified that you "pass." They aren't quite as explicit as saying that they require Veriff to delete it that quickly.

Unfortunately there's a giant loophole in Veriff's policies (emphasis mine):

  (5) Fifth, we store Personal Data only for as long as the retention of data is required by law, a contract *or is necessary for the provision or development of our Services or required for protecting us against legal claims.* At the end of the retention period, we shall permanently erase the Personal Data or anonymize it.

michaelw

vor 6 Monatendiscuss

From Hyrum's Law to AI generated unit tests to automatically validate implicit dependency contracts.

michaelw

vor 10 Monatendiscuss

Oh this brings back some fun memories. I worked with QNX for the ICON computer at Cemcorp and ESP Educational Software Products.

The OS was so clean but it lacked a lot of basic tooling. Back then there was no GUI or even a graphics library. We had to build or port a lot of things, including a VCS, from scratch. My editor of choice was JOVE (I couldn't get Emacs to build). I remember digging up various papers on graphics and creating our first graphics library.

michaelw

vor 10 Monatendiscuss

Please see my other reply about network costs. Bandwidth is a real cost that does not currently show up on the balance sheet because of Fastly's generous donations.

That said, I would love to see more organizations implement private staging repositories for their upstream package supply. This is where they can and should apply policies to protect their applications.

Developing a single multi-protocol or even multiple open source caching proxies will cost real time and money. I'd love to see more solutions here but at this stage it will take more than a few volunteers and a "PRs welcome" in the README.

michaelw

vor 10 Monatendiscuss

If the costs were all bandwidth related I would agree. Most open source package managers benefit from Fastly's generous donation of credits. Even if one ignores the single-provider-point-of-failure risk, the reality is that the development and operational costs of running package managers is much more than just networking bandwidth and more is needed.

Malware scanning, AI slopsquatting, and typosquatting are just a few of the things that package managers do today. Implementing emerging standards like Trusted Publishing ( https://repos.openssf.org/trusted-publishers-for-all-package... ), the Principles for Package Repository Security ( https://repos.openssf.org/principles-for-package-repository-... ), and improved infrastructure hardening will all important.

The key insight is that these are services that require development and operations budgets that scale with their usage.

michaelw

vor 10 Monatendiscuss

Original joint statement on the OpenSSF blog: https://openssf.org/blog/2025/09/23/open-infrastructure-is-n...

michaelw

vor 10 Monatendiscuss

Package managers are the app stores of software development. They are essential to the developer workflow and are key points of leverage with regard to supply chain security. They will be even more critical as AI-based development expands.

The root-cause problem is that package managers are funded like charities when they should be operating like non-profits. Their costs scale with usage but their donation-based revenue is dwindling. This problem has been partially masked by generous infrastructure donations but the operational costs are not just network and compute. There's a lot of security engineering development and ops in running a package manager service.

michaelw

vor 3 Jahrendiscuss

Host your own dependencies folks!

There are three major types of risk in software supply chain:

  - Correctness. Does the source have flaws (or backdoors) that allow it to be exploited.
  - Integrity. Was it tampered with from source to binary (typically to inject intentional flaws or backdoors)
  - Availability. Is it available for use in a build.

This last one is often ignored. It's less sensational and "nothing ever goes away from the Internet, right? Right???"

There are all kinds of nasty examples of dependencies going away. The two big patterns are:

  - Infrastructure availability. That's this case and yes, CDNs are a nasty point of failure. Wanna guess how many package managers depend on a single CDN?
  - Intentional delisting. This has happened often enough over the past few years. When the package maintainer throws their toys out of the pram and either removes the package from public access or effectively zeros it out. This can happen to the source too (hello colors.js)

The ideal is to have your build process be hermetic, not just from when you kick off the build but over a longer period of time. At the very least have an artifact management solution that you control as a caching proxy.

I'd like to see the major cloud providers caching all the major package repos inside their networks.

I'd also like to see multiple CDNs for every major package ecosystem.

I highly recommend reading https://slsa.dev

michaelw

vor 5 Jahrendiscuss

Here's a simple way to think about fuzzing. If you're not fuzzing your interface to find vulnerabilities, someone else is.

michaelw

vor 9 Jahrendiscuss

I didn't see anything about the many benefits that are not typically considered income by the IRS. Most notably, health insurance represents a significant extra cost that makes that 18% advantage look a little smaller. Add in 401K retirement matching and factor in the increased risk and the advantage probably goes away.

michaelw

vor 9 Jahrendiscuss

This is simply not true. In fact, working at Google will expose you to all kinds of interesting ideas and problems. Many of those problems will just sit there because Google can't prioritize them right now.

michaelw

vor 9 Jahrendiscuss

Let's count all the reasons not to leave:

1) If you don't have an amazing idea now, leaving won't make it easier. If anything it will be worse since you won't be constantly exposed to real-life problems.

2) Building great product is about a lot more than ideas. It's about execution, timing, scaling and a ton of luck.

3) After only two years at Google you're probably an L3 or L4 engineer. You have much to learn. Seriously. It probably took you a year to become productive so you've only scratched the surface. Go find a senior mentor and get them to talk about their journey. You'll be surprised.

4) Startups are hard. Don't believe the hype. Your startup will fail you. Even if the startup succeeds, you personally are unlikely to hit a payday. Remember the Golden Rule: Those who have the gold make the rules. The most likely outcome from any startup is that it fails. The second most likely outcome is that it fizzles and gets bought. Your equity would turn into a diluted options over 4 years.

5) In another 3 years at Google you'll save so much money that you'll have an entirely different set of financial options

6) Your long term career impact and financial success will actually be better off if you find a way to apply your ideas and passions within Google.

7) You are currently surrounded by some of the smartest software people in the world working on some of the hardest problems.

8) Look for a transfer to one of Google's SE Asian offices. Lots of interesting projects there.

To be blunt, it sounds like you're finding out that working as a software engineer is, well, work. It is. That doesn't mean you can't find your passion in what you do.

Buy yourself your own computer and work on your dreams at home while receiving the engineering and execution experience of your lifetime. Actively seek to learn more about your craft from a company that is still writing the book on this. Take advantage of internal instruction opportunities to expand your skillset (where else will you get paid to learn about ML from some of the best). Once you've earned your stripes at Google you'll be able to work anywhere on a just about anything. You'll also find that you actually understand the realities of product development and software engineering in ways you do not today.

I started working at Microsoft in the late 80s. I'm now at Google as a PM. I've done a bunch of startups and consulting along the way. My career has spanned over 30 years and there's no doubt in my mind that it was the time at Microsoft that gave me experience, skills and opportunities I would never have had elsewhere.

If your heart is set on the romance of startups, go find it. You'll learn a lot there too. Just don't do it because you're bored of work.

PM me if you want an extended version of this with Google insider specifics.

michaelw

vor 11 Jahrendiscuss

You can do some pretty cool stuff when you're an MVNO. No need for custom dialers (which wouldn't be much fun on iOS anyways).

The system uses inbound calls, calling history and contacts to learn how to handle outbound call. User preferences control the defaults.

Get a call from Fred on the first number, all calls to Fred will use that number. Make a call to Mary with the second number, future calls to Mary will use the second number.

Throw in multiple sets of contacts from your work and personal email accounts and it's going to be pretty smooth.

Full disclosure: the co-founder is a friend. I have no involvement in Mast though.

michaelw

vor 11 Jahrendiscuss

A white label uber like app for use by municipal taxi authorities.

There's no need to throw the baby (taxi regulation) out with the bath water (getting a taxi is usually inconvenient).

michaelw

vor 12 Jahrendiscuss

The author of this article is http://en.wikipedia.org/wiki/Bob_Kohn

  "Bob Kohn is the founder, Chairman and CEO of RoyaltyShare, Inc., an outsourced royalty processing solution for the music, book publishing, brand licensing, and motion picture industries."

From his own site http://www.bobkohn.com/ :

  "Bob is the co-inventor on a patent covering a web-based royalty system and user interface."

It comes as no surprise that he wants the publishers to band together and "pull all their books from Amazon and throw their weight behind a law-abiding alternative."

I'm not saying he's wrong but it's disingenuous not to mention that in the blurb at the end of the article. Instead he's described as a lawyer and author.

michaelw

vor 12 Jahrendiscuss

A good move by Fluke. The Fluke product retails for 10x the price but it's still a nice gesture.

michaelw

vor 12 Jahrendiscuss

http://en.wikipedia.org/wiki/Full_disclosure_(mailing_list)

  Full disclosure is a lightly moderated security mailing 
  list generally used for discussion about information
  security and disclosure of vulnerabilities. The list 
  was created on 9 July 2002 by Len Rose and is 
  administered by John Cartwright.

The wikipage goes on to list some notable zero-day vulnerabilities.

michaelw

vor 12 Jahrendiscuss

Take a look at flexbox. http://css-tricks.com/snippets/css/a-guide-to-flexbox/

michaelw

vor 12 Jahrendiscuss

While I agree with what SICP says, the function in this case isn't really a function. It's not something a caller will ever invoke explicitly. It exists to provide a closure that can be initialized with the injected parameters.

Pretend for a moment that Javascript had macros (sweet.js where are you?) and the Angular syntax was more explicit:

  myModule.provider ProviderName
  inject $scope, $document, SomeOtherDependency
  {
    your code here
  }

The last thing you'd expect is a syntax where the injected dependency names were chosen by the implementor of the provider.

Javascript's greatest weakness is that it's native syntax is poorly suited for creating language like extensions. The result is that things like modules, imports, etc. tend to be very verbose and noisy.

michaelw

vor 12 Jahrendiscuss

This has less to do with Angular and more to do with Javascript's general inability to express a useful DSL for anything.

I think your ad hominem and somewhat hyperbolic complaint would be more credible if you supplied more concrete examples of how Angular caused your product to be two months late. I'm not saying you're wrong. I'm just saying that nothing in your comment actually makes your point.

My team has made very effective use of Angular and far from making us late it has saved us considerable time.

We treat Angular not as an abstraction or framework but as a toolkit for doing the following:

  * Extending the browser's built-in HTML and CSS with our own custom behaviour.

  * Two way databinding between our application data and the DOM

  * Architecting small testable / mockable components

For what it's worth, there are some angular-isms that I truly dislike. In particular, angular.module is a bug farm for early angular developers. Also, without ngmin, Angular's "provider" declarations is both noisy and error prone. The truth howerver, is that these are minor problems and are easily discovered and fixed immediately.

Submissions

Xkcd Simulation for Real Packages

Hyrum's Tests

Open Infrastructure Is Not Free: A Joint Statement on Sustainable Stewardship

Introduction to HTML5 Desktop Apps With Node-Webkit

Google i/o fail. Again

It's not like we didn't see this one coming: a new attack vector on cars

150rpm proton motors in mitochondria

comments