5,640 karma · joined May 12, 2016
Clients that renew based on ARI can also help Let's Encrypt avoid disruptive load spikes since ARI signals can spread out renewals.
If you want to see what this looks like, look at the .mm files here:
https://github.com/mozilla/gecko-dev/tree/master/widget/coco...
If you want a specific file to look at with good examples of how this works, here's one:
https://github.com/mozilla/gecko-dev/blob/master/widget/coco...
Basically what you're looking for is being able to make Obj-C calls (e.g. [[ChildView alloc] initWithFrame:r geckoChild:this]) from within what is otherwise normal C++, and vice-versa.
https://github.com/memorysafety/ntpd-rs
Server functionality and NTS support is on the way.
I hope this being on HN doesn’t make more people believe that communicating like this is a good way to get attention.
Divvi Up is a privacy-respecting system for the collection of aggregate statistics, being built by Internet Security Research Group. We allow application owners to collect user data, telemetry, survey results, or other data and produce useful aggregates over that data without being able to determine any individual's measurements.
We're looking for an additional software engineer.
https://www.abetterinternet.org/careers/divvi-up-sw-eng/
ISRG also operates the Let's Encrypt certificate authority. Divvi Up is a new ISRG project and we hope to have similar impact with it!
In short: we believe the Xen architecture allows for the creation of more secure systems (i.e. with a much smaller TCB, which translates to a smaller attack surface). We discuss this in much greater depth in our Architecture Specification document:
Billions of people rely on Let's Encrypt (ISRG) to operate critical digital infrastructure for a more secure and privacy-respecting world. Living up to such great responsibility starts with hiring excellent people and providing them with an environment in which they can do their best work.
People generally do their best work when they're able to live their best lives outside of work. All of our position are remote so you can live near whoever, or whatever, is most important to you. Competitive salaries and 100% 401(k) matching help you to reach your financial goals. Top-tier health insurance gives you peace of mind and great options for staying healthy.
Multiple positions:
They need to stop building massive new infrastructure every time. Aside from the environmental issues, it seems like it almost always comes at massive cost to the citizens of the host country. Our world deserves better, and we have plenty of other sports we can watch in the meantime.
We are already working on plans for DNS. BGP has been in the back of our minds for a while but we haven’t had the bandwidth to start seriously looking into that yet. If you have ideas get in touch!
The issue is that we said in our CPS that the lifetime was exactly 90 days, and then we did something different, even if just by one second. The problem here is behavioral consistency with our own published policies.
We now just say “less than 100 days.” An unfortunate side effect of being more specific and informative in these documents (e.g. saying our certs have 90 days validity) is that it ups our chances of noncompliance if we are off on something by a bit, even if it is a meaningless bit. There is an incentive to not be so specific so as to avoid situations like this.
The question of whether or not revocation should happen has to be asked whenever a certificate compliance issue is being discussed, regardless of how serious the issue is. That is a normal part of the process of evaluating an incident thoroughly.
We do not plan to revoke any certificates as a result of this issue.
An aside - I love how informed many of the commenters here are, thanks to you all for helping to explain what's happening!
In this thought experiment, like the rat, you have no say in what constitutes being treated “well enough.”
If I was given total control over your life and made you work for me, would you be ok with that so long as, according to me, I treated you well enough? I doubt it.
That isn’t the point though. This is not a debate about whether anyone thinks the rat is being treated well.
The rat did not consent to this (because it can’t), so this is, factually, forced labor. I am ok with it in this situation, but let’s call it what it is and express gratitude for what the rat did to clean up human messes.
Second, you can’t do something heroically if you either 1) don’t know what you are doing and what the risks are or 2) there are no risks. Take your pick, but either way it isn’t heroic. The rat did a great thing for us but hero is not the right word.
The old-style extensions were so powerful because they could put their API tentacles very deep into the rendering engine. Mozilla paid a huge price for allowing that though - it was very difficult to change the behavior of many parts of the rendering engine without breaking extensions. Much of what you'd think was just internal implementation detail was actually API surface accessible to those extensions. The workarounds added a bunch of internal complexity. It really slowed down the pace of development.
I get that some people mourn the loss of that style of extension, but dropping it was an important decision that should have happened much earlier. There were other issues with the old-style extensions (e.g. security) but making the pace of development uncompetitive should have been enough to doom it.
It has nothing to do with engineering resources, and we always wanted native context menus, but they were not customizable enough to meet the perceived needs of web, XUL, and extension developers at the time. People expected to be able to change colors and layout with CSS, for example. The native APIs put heavy limitations on what you could do with a native context menu and it was just not compatible with the expectations of people building against the rendering engine at the time.
There was some discussion of switching back and forth between native and non-native menus based on styling, but that got complicated quickly and it wasn't thought to be worthwhile.
It sounds like perceived needs have changed, and maybe the native APIs allow for bit more flexibility now. Glad it's happening, excited to see how well it works!
It’s probably .com because it’s for Mozilla Corporation as opposed to Mozilla Foundation.
ISRG plans and coordinates investments in moving open source software to memory safe languages. We have a strong preference for working on these plans with maintainers and developers, and then funding them to execute the plan.
Once we have a plan prepared, and, ideally, maintainers/developers on board, then we pitch it for funding. Once someone (e.g. Google) funds the project, then ISRG handles contracts with the project developers/maintainers to get the work done. In some cases maintainers may be on board but want us to find a contractor to actually do the work.
In both of the first two projects, and in most future cases, the money that Google (or another company) provides will largely go to project maintainers / developers.
Since most unsafe code is C or C++, Rust usually makes the most sense for rewriting one component at a time. It integrates with C and C++ very cleanly because it has good FFI and no runtime.
If we were rewriting more projects from scratch and integration with existing C and C++ code was not important, we might use other languages more often. I don't expect we'll attempt to rewrite many pieces of software from scratch.
Source: I run the memory safety initiative at ISRG.
We have a memory safety initiative in which we plan and fund projects to move popular open source software to memory safe languages. For each plan we make we seek a funder - in a couple of cases now that has been Google, but it may be others in the future.
We are in the "middle" of the financing in the sense that funding passes through us, but the memory safety initiative is coordinated primarily by us. We select projects and work with maintainers to make plans. Part of that coordination we perform is matching up projects with funders like Google, and then managing the contracts and overseeing the work to completion.
> What is left out of the title is that they do not provide funding to the current authors/maintainers of these open source projects. Instead, they fund an organization that will rewrite these tools.
This's not what's happening. Here's what is:
ISRG plans and coordinates investments in moving open source software to memory safe languages. We have a strong preference for working on these plans with maintainers and developers, and then funding them to execute the plan.
Once we have a plan prepared, and, ideally, maintainers/developers on board, then we pitch it for funding. Once someone (e.g. Google) funds the project, then ISRG handles contracts with the project developers/maintainers to get the work done. In some cases maintainers may be on board but want us to find a contractor to actually do the work.
In both of the first two projects, and in most future cases, the money that Google (or another company) provides will largely go to project maintainers / developers.
If you buy through a VAR and/or Dell reps you don't pay the price on the website. What you actually pay is typically significantly lower. I don't think anyone actually buys servers like these by just ordering from the website. We (Let's Encrypt) certainly don't.
These are expensive servers, crossing into six digits, but not $200k.