HackerTrans
TopNewTrendsCommentsPastAskShowJobs

jbaviat

no profile record

Submissions

Bose will brick SoundTouch speakers in 2026

bose.com
3 points·by jbaviat·9 mesi fa·1 comments

Reviving PyMiniRacer: A Python <> JavaScript Bridge

bpcreech.com
47 points·by jbaviat·2 anni fa·14 comments

Show HN: Cloud Security Lounge – Datadog video series on cloud security

youtube.com
2 points·by jbaviat·3 anni fa·0 comments

9M people city, 170km long and 200m wide

neom.com
1 points·by jbaviat·4 anni fa·1 comments

comments

jbaviat
·4 mesi fa·discuss
I _do_ believe the author implied universality on purpose.

That’s also close to the YC motto: “make something people want”.

Or as Paul Graham puts it: be good. https://paulgraham.com/good.html
jbaviat
·8 mesi fa·discuss
How about using tor to help with DNS redundancy? https://en.wikipedia.org/wiki/Tor_(network)
jbaviat
·9 mesi fa·discuss
Quoting Bose:

| Bose SoundTouch systems were introduced into the market in 2013. Technology has evolved since then and we’re no longer able to sustain the development and support of the cloud infrastructure that powers this older generation of products. We remain committed to creating new listening experiences for our customers built on modern technologies.
jbaviat
·2 anni fa·discuss
I used to live in France. We had no A/C, enough climate consciousness not install it, though our east-facing windows were bringing important heat at sunrise. We had awnings installed, with an HomeKit connection, so we could automatically have them closed before sunrise, and opened once the sun would leave this face of the building. We saved a few degrees in this way.
jbaviat
·2 anni fa·discuss
> There’s a plethora of other problems that make flying cumbersome

How about CO2 emissions?
jbaviat
·2 anni fa·discuss
PyMiniRacer (original) author here. PyMiniRacer is definitely a way to run insecure code, but as pointed, the several CVEs in V8 require measures beyond "just" relying on PyMiniRacer to make it safe.

For the record PyMiniRacer was victim of a CVE itself https://nvd.nist.gov/vuln/detail/CVE-2020-25489 - a heap overflow, my mistake.

1. Total control over what APIs the user's code can call: you kinda got it... users can just do plain JS 2. Memory limits: you got it 3. Time limits: you got it, but the current model is unreliable when used at high levels of CPU and a high number of threads.

And thank you so much bpcreech for taking back the ownership of PyMiniRacer!
jbaviat
·3 anni fa·discuss
I built a tool to extract ROP gadgets from binaries [0], which got noticed by a guy at Apple, and I ended up spending 4 years there. And this guy became Sqreen CEO and my (incredibly awesome) cofounder.

[0] https://github.com/aviat/skyrack
jbaviat
·4 anni fa·discuss
[Disclaimer: I worked in Apple Red Team]

What if this isn’t a good news for 99% of Apple users?

That’s obviously an amazing measure for the 1% high targets out there.

But what about the other 99%? Does that create an incentive for Apple to strengthen Lockdown Mode security to the detriment of the regular mode (should we call it Unsafe Mode)?

I’m afraid that this architecture will make it harder to prioritize security features or fixes for the 99% users. Developers bandwidth is limited, they can’t fix all bugs. Hence if you have to choose between one bug impacting the 1% most important users (from a security standpoint) versus one bug impacting the 99% others, which would you choose?

Would such an architecture have led to the emergence of Blastdoor[1] - which attempts at mitigating iMessage attachement exploits, but is now useless in Lockdown mode?

My hope here is that by reducing attack surface, Lockdown mode will make exploits much easier to fix (as they’ll target a limited area), allowing to strengthen the system core while freeing bandwidth to implement longer term, Blastdoor like mitigations.

[1] https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...