HN user

jacquesgt

486 karma
Posts7
Comments78
View on HN

While hinting is disabled for most fonts, there are some fonts that require hinting to render correctly. We have to support hinting for those fonts, and it was easier to make it secure by rewriting hinting in Swift than it would have been to comprehensively identify every font created by those foundries.

If you want to help improve the security of OS software through the magic of memory safe languages, the team that did this work is hiring: https://jobs.apple.com/en-us/search?search=Spear&sort=releva...

Knowledge of Swift not required. If you know your way around OS software, can reason about the security of the code you write, and are excited about writing exhaustively tested software, we’d love to talk to you.

We’re hiring for roles in kernel/systems and userspace. Like the Platforms SOTU mentioned, we’re using Swift at all layers of the software stack now. https://www.youtube.com/live/yl2jsIoMfDU

I had the pleasure of leading the effort to ship Swift in the Secure Enclave back in 2022. Now I have multiple teams working on accelerating the transition to memory safe languages. We’re showing that with good planning and a relentless focus on testing, we can improve security, performance, and functionality. And we get to have a ton of fun working with some amazing colleagues. It’s the most enjoyable and impactful work I’ve ever done in my career.

Apple | Software Engineer | Cupertino, CA/San Diego, CA/Portland, OR/Austin, TX | Onsite

We’re the team that designs and develops the operating system for the Secure Enclave used in iOS, tvOS, watchOS, and macOS devices. We develop the full software stack, including the L4 microkernel, runtime libraries, hardware drivers, and more. We work very closely with Apple’s Silicon Engineering Group to help design the Secure Enclave hardware.

This is a great place to work if you’re into some combination of embedded, operating systems, and security.

Apply here: https://jobs.apple.com/en-us/details/200120834/trusted-kerne...

Apple | Software Engineer | Cupertino, CA/San Diego, CA/Portland, OR/Austin, TX | Onsite

We’re the team that designs and develops the operating system for the Secure Enclave used in iOS, tvOS, watchOS, and macOS devices. We develop the full software stack, including the L4 microkernel, runtime libraries, hardware drivers, and more. We work very closely with Apple’s Silicon Engineering Group to help design the Secure Enclave hardware.

This is a great place to work if you’re into some combination of embedded, operating systems, and security.

Apply here: https://jobs.apple.com/en-us/details/200120834/trusted-kerne...

Apple | Software Engineer | Cupertino, CA/San Diego, CA/Portland, OR/Austin, TX | Onsite

We’re the team that designs and develops the operating system for the Secure Enclave used in iOS, tvOS, watchOS, and macOS devices. We develop the full software stack, including the L4 microkernel, runtime libraries, hardware drivers, and more. We work very closely with Apple’s Silicon Engineering Group to help design the Secure Enclave hardware.

This is a great place to work if you’re into some combination of embedded, operating systems, and security.

Apply here: https://jobs.apple.com/en-us/details/200120834/trusted-kerne...

You may be right about the averaging. From rereading the accident report, the Pilot Flying took back control of the plane after the Pilot Not Flying engaged his controls and tried to pitch down.

But, it’s the same basic idea. The PNF thought he’d gotten control of the plane, and didn’t understand why his input wasn’t having an effect. He didn’t get feedback from the stick telling him a different input was being honored. And neither pilot appears to have been fully aware that they were in a flight control mode where there was a risk of stalling. The PF especially never seemed to have made that connection, and the PNF took a fairly long time to call it out. As a result, the PF may not have been aware that he needed to actively keep the angle of attack inside the flight envelope.

So, PNF tries to pitch down, but isn’t aware the plane got put back into a mode where he isn’t in control. PF is pitching up, but isn’t aware the plane switched to a mode where this could lead to a stall. That’s the similarity I was getting at.

Part of the issue may have been that the plane had slowed down so much that the stall warning stopped (it disengages below a certain airspeed apparently). When he stopped pulling up, the plane sped up and the stall warning started again. Pull up again, plane slows down, stall warning stops.

AF 447 wasn’t all that different from this situation. One of the co-pilots was trying to pitch the nose down to recover from the stall. The other was panicking and trying to pitch up. The plane averaged their inputs, without giving feedback via the stick that this was happening. It wasn’t until very late in the flight that they figured out what was happening, and then it was too late to recover.

Obviously there was some significant pilot error in this case, but a big contributor mag have been that the pilot who was trying to correct the stall didn’t understand that the plane was ignoring his input because of the averaging.

I used to work in the industrial controls industry. The systems are often designed by application engineers working for the industrial control equipment’s manufacturer or distributor. In the case of distributors, the engineering work is often provided for “free” and paid for with the markup the distributor applies over their cost to purchase the components direct from the manufacturer. Those same application engineers will be involved with helping to make the sale. If a customer asks “can I connect this to the Internet?”, any response other than “of course!” is liable to result in a talking to from the sales manager for that account.

Few of the incentives in that industry lead to good security. More details here: https://news.ycombinator.com/item?id=3260127

I'm not seeing how it's unpredictable and inconvenient. It's predictable if the stack address can be leaked (via a frame pointer leak, for example). It doesn't seem that inconvenient. Instead of including the address of a gadget in the chain, include the gadget xor the leaked stack address. What's the unpredictable and inconvenient part that I'm not seeing?

I feel like I’m missing something here. An infoleak is required to successfully ROP against ASLR (otherwise the attacker doesn’t know what to overwrite the return address with). Once an infoleak is available, the address of the stack can be leaked. I’m not really sure this does much beyond requiring attackers to modify their existing exploits.

Their theory is spelled out pretty clearly in the article. There are 1800 taxicabs permitted to operate in the city and many more Ubers/Lyfts.

The fact that people who use Uber and Lyft have to wait less is nice for them, but not so nice if the extra cars for hire circling for fares results in slower commutes for public transit users.

Yes, the treatment of their employees in the workplace is very much Google's business. Accomodating LGBT employees is not only the right thing to do, it's also supported by many of the binary/cisgender/straight/non-queer/what have you employees at workplaces like Google.

But see also:

In particular, I’m still conflicted about whether all those type system extensions were warranted. Certainly immutability helped with things far beyond safe concurrency. And so did the side-effect annotations, as they commonly helped to root out bugs caused by unintended side-effects. The future for our industry is a massively distributed one, however, where you want simple individual components composed into a larger fabric. In this world, individual nodes are less “precious”, and arguably the correctness of the overall orchestration will become far more important. I do think this points to a more Go-like approach, with a focus on the RPC mechanisms connecting disparate pieces.

Not that I’m speaking for everyone on HN, but the problem is generally with wide-ranging surveillance of the entire populace in the hopes that they can data-mine their way to victory. Figuring out techniques like this to surveil actual terrorists and criminals based on probable cause is what the police and intelligence community should be doing.

How to C in 2016 11 years ago

Which is a perfect example of why their approach is better. Less arithmetic to get right with their approach.

This is a remarkably content-free posting.

People become corporate do-nothings because it’s easy to become disconnected from the act of creating when you’re at a big company. Even at the best big companies, employees can just do things that look like work that aren’t, and you wouldn’t be able to tell.

I’ve seen this at startups and big corporations. People seem to get fired for doing nothing productive with about the same frequency at both. What are some examples of do-nothingism that occurs at big successful corporations?

Startups can’t survive blindly following buzzwords or whatever trend is hot because you actually have to know what’s coming in the future and be right. That’s all there is. If you chose the wrong market, or you’re wrong about what people want, then you’re toast.

In the age of the acquihire for failed startups, this is especially laughable. With plenty of money for early stage deals, and the likelihood of an acquihire or other soft landing if things go badly (followed by funding for a new idea a year or two later), it’s the best environment in years for startups to blindly follow trends and spout buzzwords.

That's the point. Paris is the second-lowest on that list. The other places listed are all Parisian suburbs.

"Because they exiled all future high rises to some far neighborhood like La Défense, they were segregating growth."

AFL isn’t a source-level fuzzer. It interposes between the compiler and the assembler to add instrumentation to assembly code emitted by the compiler. Shouldn’t it be possible to do the same thing via binary rewriting or emulation in cases where source access isn’t possible? The first one would be hard and the second one would be slow, but I don’t think there’s anything about AFL’s approach that would stop this from working.

Slimy is telling a woman she can't be called a cofounder because "she's a girl". Slimy is threatening to fire a subordinate if they won't date you. Slimy is ignoring complaints from an employee about sexual harassment. Slimy is firing someone for trying to exercise their rights to not be harassed.

Using clear language to communicate boundaries isn't slimy at all. It's reprehensible that she (allegedly for the pedants in the crowd) even had to say those things. Building a case when no one does anything about a pattern of continued discrimination and harassment it's slimy at all; it's exercising your basic human and legal rights.

What was the alternative? Not documenting the abuse so that it could get dismissed as a he said/she said argument? Deciding between putting up with the abuse or throwing away all the hard work she put into the company?

Apparently her options were to be slimy by documenting her case, or to get dismissed as a bitter woman who was blowing things out of proportion because she got dumped. Nice.

Hello, Stranger 12 years ago

It’s covered in the article:

"The benefits of connecting with others also turn out to be contagious. Dr. Epley and Ms. Schroeder found that when one person took the initiative to speak to another in a waiting room, both people reported having a more positive experience. Far from annoying people by violating their personal bubbles, reaching out to strangers may improve their day, too."

People aren't complaining about the mistake itself, but about the US government requiring Ibrahim to spent 8 years and $3.5 million dollars to correct the mistake. They could have done a review when the lawsuit was filed, and they could have agreed to settle the lawsuit after the mistake came to light during depositions. As far as we know, they didn't do either of those. That's what the gp is implying might be exceptional and worthy of awarding fees.