jacquesgt
Joined 16 years ago
Karma
486
Submissions
87
Member since
Oct 30
Recent submissions
Comment · 4 months ago
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.
Comment · 4 months ago
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.
Comment · 1 year ago
Liron is an incredible photographer. Well worth checking out his instagram at https://www.instagram.com/liron_gertsman_photography
He and another photographer recently did a project to photograph a bird in front of erupting volcano. I’m really looking forward to seeing that one.
Comment · 3 years ago
The names of some birds still reflect this. For example, the ring-necked duck has a ring around its neck that’s almost impossible to see a on a live bird.
Comment · 6 years ago
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...
Comment · 6 years ago
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...
Comment · 6 years ago
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...
Comment · 7 years ago
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.
Comment · 7 years ago
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.
Comment · 7 years ago
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.
Comment · 7 years ago
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
Comment · 9 years ago
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?
Comment · 9 years ago
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.
Comment · 9 years ago
I believe they're Zigbee Home Automation, not ZLL. Either that or they're improperly reporting that they support ZHA instead of ZLL, which causes issues for 3rd party bridges like Philips Hue. https://developers.meethue.com/comment/2686#comment-2686