Tariffs are easy, just pay them. Federal Motor Vehicle Safety Standards are harder... But maybe there's a loophole for commercial transport? or maybe they paid to have the testing done?
Which isn’t even really that prohibitive because Chinese vehicles beat Western pricing by five figures.
Plus, all the sensor equipment is made in China anyway. There’s almost certainly no way to have it manufactured in the US.
On top of that, fleet sales don’t have to deal with the antiquated dealer network laws in the US.
And of course American market car manufacturers refuse to produce vehicles that are like this one: space efficient and reasonably sized, instead opting for gigantic bean shaped SUVs with sloping rear roofs that rob you of cargo space while taking up maximum curb real estate.
Ford E-Transit is an electric van for a lot of money. But it looks like Ford wants to stop making them, and 2 seat models look much easier to find. But you'd be able to fit your board no problem.
Your Transamerica pyramid picture is incredible among really cool pictures you have there. Quite cool to photograph for wikipedia like this, the world needs more people like you!
The fact that so many people use FFmpeg and QEMU suggest that he is quite good at documenting, collaborating, and at least making his code remarkably clean and easy to follow. This already puts him way ahead of the average silicon valley senior software engineer that I've worked with. However, he does value independence so I don't think he would have been happy working at a faang-type company for long.
>Fabrice won International Obfuscated C Code Contest three times and you need a certain mindset to create code like that—which creeps into your other work. So despite his implementation of FFmpeg was fast-working, it was not very nice to debug or refactor, especially if you’re not Fabrice
The fact that SVG files can contain scripts was a bit of a mistake. On one hand, the animations and entire interactive demos and even games in a single SVG are cool. But on the other hand, it opens up a serious can of worms of security vulnerabilities. As a result, SVG files are often banned from various image upload tools, they do not unfurl previews, and so on. If you upload an SVG to discord, it just shows the raw code; and don't even think about sharing an SVG image via Facebook Messenger, Wechat, Google Hangouts, or whatever. In 2025, raster formats remain way more accessible and easily shared than SVGs.
This is very sad because SVGs often have way smaller file size, and obviously look much better at various scales. If only there was a widely used vector format that does not have any script support and can be easily shared.
All SVGs should be properly sanitized going into a backend and out of it and when rendered on a page.
Do you allow SVGs to be uploaded anywhere on your site? This is a PSA that you're probably at risk unless you can find the few hundred lines of code doing the sanitization.
Note to Ruby on Rails developers, your active storage uploaded SVGs are not sanitized by default.
It would be better if they were sanitized by design and could not contain scripts and CSS. For interactive pictures, one could simply use HTML with inline SVG and scripts.
Notably, the sanitization option is risky because one sanitizer's definition of "safe" might not actually be "safe" for all clients and usages.
Plus as soon as you start sanitizing data entered by users, you risk accidentally sanitizing out legitimate customer data (Say you are making a DropBox-like fileshare and a customer's workflow relies on embedding scripts in an SVG file to e.g. make interactive self-contained graphics. Maybe not a great idea, but that is for the customer to decide, and a sanitization script would lose user data. Consider for example that GitHub does not sanitize JavaScript out of HTML files in git repositories.)
At least with external entities you could deny the parser an internet connection and force it to only load external documents from a cache you prepopulated and vetted. Turing completeness is a bullshit idea in document formats.
Postscript is pretty neat IMHO and it’s Turing complete. I really appreciated my raytraced page finally coming out of that poor HP laser after an hour or so.
With SVGs you can serve them from a different domain. IIUC the issue from TFA was that the SVGs were served from the primary domain; had they been on a different domain, they would have not been allowed to do as much.
IIUC, an untrusted inline SVG is bad. An image tag pointing to an SVG is not.
<img src="untrusted.svg"> <!-- this is ok -->
<svg from untrusted src> <!-- this is not ok -->
I feel like this is common knowledge. Just like you don't inject untrusted HTML into your page. Untrusted HTML also has scripts. You either sanitize it. OR you just don't allow it in the first place. SVG is, at this point, effectively more HTML tags.
Also remember that if the untrusted SVG file is served from the same origin and is missing a `Content-Disposition: attachment` header (or a CSP that disables scripts), an attacker could upload a malicious SVG and send the SVG URL to an unsuspecting user with pretty bad consequences.
That SVG can then do things like history.replaceState() and include <foreignObject> with HTML to change the URL shown to the user away from the SVG source and show any web UI it would like.
Because displaying user-submitted images is pretty common and doesn't feel like a security footgun, but displaying user-submitted HTML is less common (and will raise more careful security scrutiny).
Would it be possible for messenger apps to simply ignore <script> tags (and accept that this will break a small fraction of SVGs)? Or is that not a sufficient defense?
I looked into it for work at some point as we wanted to support SVG uploads. Stripping <script> is not enough to have an inert file. Scripts can also be attached as attributes. If you want to prevent external resources it gets more complex.
The only reliable solution would be an allowlist of safe elements and attributes, but it would quickly cause compat issues unless you spend time curating the rules. I did not find an existing lib doing it at the time, and it was too much effort to maintain it ourselves.
The solution I ended up implementing was having a sandboxed Chromium instance and communicating with it through the dev tools to load the SVG and rasterize it. This allowed uploading SVG files, but it was then served as rasterized PNGs to other users.
It's definitely a possible solution if you control how the file are displayed. In my case I preferred the files to be safe regardless of the mechanism used to view them (less risk of misconfiguration).
No, svgs can do `onload` and `onerror` and also reference other svgs that can themselves contain those things (base64'd or behind a URI).
But you can use an `img` tag (`<img src="evil.svg">`) and that'll basically Just Work, or use a CSP. I wouldn't rely on sanitizing, but I'd still sanitize.
> But you can use an `img` tag (`<img src="evil.svg">`) and that'll basically Just Work
That doesn't help too much if evil.svg is hosted on the same domain (with default "Content-Type: image/svg+xml" header), because attacker can send a direct link to the file.
IMO, the bigger problem with SVGs as an image format is that different software often renders them (very) differently! It's a class of problem that raster image formats basically don't have.
I would have expected SVGs to be like PDFs and render the same across devices. Is the issue that some renderers don’t implement the full spec, or that some implement parts incorrectly?
They are reasonably consistent because there is a de-facto reference implementation (Adobe Acrobat) which, if your implementation does not match exactly, users will think your implementation is broken.
You definitely don't understand PDFs, let alone SVGs.
PDFs can also contain scripts. Many applications have had issues rendering PDFs.
Don't get me wrong, the folks creating the SVG standard should've used their heads. This is like the 5th time (that I am aware of) this type of issue has happened, (and at least 3 of them were Adobe). Allowing executable code in an image/page format shouldn't be a thing.
SVG can for example contain text elements rendered with a font. If the font is not available it will render in a different one. The issue can be avoided by turning text elements into paths, but not all SVGs do that.
More like HTML and getting different browsers to render pixel perfectly identical result (which they don't) including text layout and shaping. Where different browser don't mean just Chrome, Firefox, Safari but also also IE6 and CLI based browsers like Lynx.
PDFs at least usually embed the used subset of fonts and contain explicit placement of each glyph. Which is also why editing or parsing text in PDFs is problematic. Although it also has many variations of Standard and countless Adobe exclusive extensions.
Even when you have exactly the same font text shaping is tricky. And with SVGs lack of ability to embed fonts, files which unintentionally reference system font or a generic font aren't uncommon. And when you don't have the same font, it's very likely that any carefully placed text on top of diagram will be more or less misplaced, badly wrap or even copletely disappear due to lack of space. Because there is 0 consistency between the metrics across different fonts.
The situation with specification is also not great. Just SVG 1.1 defines certain official subsets, but in practice many software pick whatever is more convenient for them.
SVG 2.0 specification has been in limbo for years although seems like recently the relevant working group has resumed discussions. Browser vendors are pushing towards synchronizing certain aspects of it with HTML adjacent standards which would make fully supporting it outside browsers even more problematic. It's not just polishing little details many major parts that were in earlier drafts are getting removed, reworked or put on backlog.
There are features which are impractical to implement or you don't want to implement outside major web browsers that have proper sandboxing system (and even that's not enough once uploads get involved) like CSS, Javascript, external resource access across different security contexts.
There are multiple different parties involved with different priorities and different threshold for what features are sane to include:
- SVG as scalable image format for icons and other UI elements in (non browser based) GUI frameworks -> anything more complicated than colored shapes/strokes can problematic
- SVG as document format for Desktop vector graphic editors (mostly Inkscape) -> the users expect feature parity with other software like Adobe Illustrator or Affinity designer
- SVG in Browsers -> get certain parts of SVG features for free by treating it like weird variation of HTML because they already have CSS and Javascript functionality
- SVG as 2d vector format for CAD and CNC use cases (including vinyl cutters, laser cutters, engravers ...) -> rarely support anything beyond shapes of basic paths
Beside the obviously problematic features like CSS, Javascript and animations, stuff like raster filter effects, clipping, text rendering, and certain resource references are also inconsistently supported.
From Inkscape unless you explicitly export as plain 1.1 compatible SVG you will likely get an SVG with some cherry picked SVG2 features and a bunch of Inkscape specific annotations. It tries to implement any extra features in standard compatible way so that in theory if you ignore all the inkscape namespaced properties you would loose some of editing functionality but you would still get the same result. In practice same of SVG renderers can't even do that and the specification for SVG2 not being finalized doesn't help. And if you export as 1.1 plain SVG some features either lack good backwards compatibility converters or they are implemented as JavaScript making files incompatible with anything except browsers including Inkscape itself.
Just recently Gnome announced working on new SVG render. But everything points that they are planning to implement only the things they need for the icons they draw themselves and official Adwaita theme and nothing more.
And that's not even considering the madness of full XML specification/feature set itself. Certain parts of it just asking for security problems. At least in recent years some XML parsers have started to have safer defaults disabling or not supporting that nonsense. But when you encounter an SVG with such XML whose fault is it? SVG renderer for intentionally not enabling insane XML features or the person who hand crafted the SVG using them.
Yeah, I spent a bit of time trying to figure out some masking issues with a file I created in Inkscape but which chrome would butcher. Turned out to be opacity on a mask layer or something.
It's wild how often we rediscover that executing untrusted code leads to decades of whack-a-mole security. Excel/Word plus macros, HTML plus JavaScript, SVG plus JavaScript, ...
Does it need to be as complicated as a new format? Or would it be enough to not allow any scripting in the provided SVGs (or stripping it out). I can't imagine there are that many SVGs out there which take advantage of the feature.
If only there was a widely used vector format that had script support and also decades of work on maintaining a battle-tested security layer around it with regular updates on a faster release cycle than your browser. That'd be crazy. Sure would suck if we killed it because we didn't want to bother maintaining it anymore.
Uh... Flash was a genuine firehose of security flaws. I mean, yeah, they patched them. So "battle tested security layer" isn't wrong in a technical sense. But, yikes, no.
There is artistically no equivalent to Flash ever since it died. Nothing else has allowed someone with artistic skills but no programming skills to create animations and games to the same degree and with the same ease.
I'd say Roblox is absolutely filling that market need. And as mentioned elsewhere, the "animations and games" demographic has moved on in the intervening decades to social media, and tools like CapCut make creating online content easier than it ever has been.
Honestly I think a lot of the Flash mania is just middle aged nerds fondly remembering their youth. The actual tool was a flash in the pan, and part of a much more complicated history of online content production. And the world is doing just fine without it.
Sure, but that's because the media and forums change, not so much a point about tool capability. The equivalent of teenaged geeks hacking on flash games today is influencer wannabes editting trends in CapCut. If anything content production is far more accessible now than in the 90's.
Yeah, it's still insane to me that the SVG can contain scripts. Wholly unnecessary; the DOM subtree it defines could be manipulated by external scripts just fine.
Anyway, I just set `svg.disabled` in Firefox. Scary world out there.
Update: this breaks quite a few things. It seems legitimate SVGs are used more often for UI icons than random diagrams and such. I suppose I shouldn't be surprised. I'll have to rethink this.
I gather from the HN discussion that it's not simple to disable scripting in an SVG, in retrospect a tragically missing feature.
I guess the next step is to propose a simple "noscripting" attribute, which if present in the root of the SVG doc inhibits all scripting by conforming renderers. Then the renderer layer at runtime could also take a noscripting option, so the rendering context could force it if appropriate. Surely someone at HN is on this committee, so see what you can do!
Edit: thinking about it a little more - maybe it's best to just require noscripting as a parameter to the rendering function. Then the browsers can have a corresponding checkbox to control SVG scripting and that's it.
Disabling script execution in svgs is very easy, it's just also easy to not realize you're about to embed an svg. `<img src="evil.svg">` will not execute scripts, a bit like your "noscripting" attribute except it's already around and works. Content Security Policy will prevent execution as well, you should be setting one for image endpoints that blocks scripts.
Sanitizing is hard to get right by comparison (svgs can reference other svgs) but it's still a good idea.
I had the impression from elsewhere in this thread that loading the svg in some other way, then you are not protected. This makes a no-brainer "don't run these ever" option in the browser seem appealing.
> This makes a no-brainer "don't run these ever" option in the browser seem appealing.
Firefox has this: svg.disabled in about:config. It doesn't seem to be properly documented, and might cause other problems for the developer (I found it accidentally, and a more deliberate search turns up mainly bug tracker entries.)
That's apparently how 4chan got hacked a while back. They were letting users upload PDFs and were using ghostscript to generate thumbnails. From what I understand, the hackers uploaded a PDF which contained PostScript which exploited a ghostscript bug.
Yes but the primary issue was that 4chan was using over a decade old version of the library that contained a vulnerability first disclosed in 2012: https://nvd.nist.gov/vuln/detail/CVE-2012-4405
In one of my penetration testing training classes, in one of the lessons, we generated a malicious PDF file that would give us a shell when the victim opened it in Adobe.
Granted, it relied on a specific bug in the JavaScript engine of Adobe Reader, so unless they're using a version that's 15 years old, it wouldn't work today, but you can't be too cautious. 0-days can always exist.
True, I just considered that once you handle a PDF with so much care like if it was poisoned, it's perhaps better to send this poison to someone else to handle.
Really awesome design! It would be wise to replace some of those 3D printed parts with CNC parts, especially for places where a lot of strength is required (eyelets for those Peak Design anchors) or precision is required (lens mount). I myself have 3D printed some parts for my line scan camera too, so I can totally understand.
You seem to be implying that all automotive lidar are 1550 nm but that's not true. While there are lots of 1550 nm automotive lidars (Luminar on Volvo, Seyond on NIO) there are also plenty of 850 nm to 940 nm lidars are used in cars (Hesai, Robosense, etc). Those can pass through water and get focused to your retina, but they are also a lot lower power so they do not damage cameras.
Also although that energy longer than 1400nm is generally absorbed by the cornea and lens, it is still energy, and it is not a hard bandpass filter per se. Safety is relative at higher wattages.
NGL I thought sub 1550nm LIDAR had been banned for use in new automotive applications already? I clearly must be mistaken but I had thought that was the case.
Not banned. In addition to the Chinese lidars I mentioned, the Valeo Scala on Audi cars is 905 nm, and then there are also Ouster (865 nm), Innoviz (905 nm), Livox (905 nm) etc. The large spinning lidar on top of the Waymo Jaguar I-Pace is also purportedly 905 nm, although in the past they also had a swivelling 1550 nm lidar in the dome of the Chrysler Pacifica cars (situated just underneath a smaller spinning 905 nm one).
The eye safety threshold for 850/905 nm is a lot lower than 1550 nm, so they output way less power, but the much better sensitivity of silicon sensors makes up for it partially. You can also squeeze out more range using clever signal processing and a large optical aperture (which allows you to output more light, but since the light is spread out across the aperture, the intensity doesn't exceed the threshold). Typically, the range of 850/905 nm lidars is less than that of 1550 nm lidars though.
On the bright side, due to lower power, there hasn't been any instances (to my knowledge) of 850 nm and 905 nm lidars damaging cameras, whereas at least two different 1550 nm lidars have been known to destroy cameras (Luminar and AEye).
On the Luminar lidar website [1] they proudly advertise "1,000,000x pulse energy of 905nm".
Depends on the wavelength of lidar. Near IR lidars (850 nm to 940 nm, like Ouster, Waymo, Hesai) will be focused to your retina whereas 1550 nm lidars (like Luminar, Seyond) will not be focused and have trouble penetrating water, but they are a lot more powerful so they instead heat up your cornea. To quote my other comment [1]:
> If you have many lidars around, the beams from each 905 nm lidar will be focused to a different spot on your retina, and you are no worse off than if there was a single lidar. But if there are many 1550 nm lidars around, their beams will have a cumulative effect at heating up your cornea, potentially exceeding the safety threshold.
Follow up question that you might know: would multiple LIDAR sensor actually be additive like that? If you can stand a foot away from a car's LIDAR sensor and be unharmed, then can't you have:
x^2 sensors at x feet from you and have the same total energy delivered? If sensors are actually safe to look at from 6in or 3in, then multiple the above table by 4 or 16.
It seems like, due to the inverse square law, the main issue is how close you can get your eye to a LIDAR sensor under normal operation, not how many sensors are scattered across the environment. The one exception I can think of is a car that puts multiple LIDAR arrays next to each other (within a foot or two). But maybe I'm misunderstanding something!
Do you if there has been any work how lasers affect other animals and insects?
Am I being catastrophically pessimistic to think that in addition to swatting insects as it moves forward, the cars lidar is blinding insects in a several hundred meter path ?
I’m very optimistic about automated cars being better than most humans but wonder about side effects.
If we have automated anti-mosquito vehicles just roaming around, the world would be a better place. There might be some second order effects from removing mosquitoes that we haven't predicted, but fuck mosquitoes.
Unfortunately not all insects are mosquitoes, and one reason we have many fewer birds in (e.g.) the UK than when I was young, is the decline of insect life.
It does have graphics acceleration and you can even play AAA titles with fex [1] since last year. But many bells and whistles still don't work --- for example, the video decoding hardware, proper sleep, etc.
Anyway, I've been using it on my Macbook Air M2 and it works fine for my use case [3]. Pretty smooth.
From 2017-2023 I had Thinkpads and some Acer which was well supported by Linux and sleep was the worse part. On numerous occasions across different devices I'd put the laptop to sleep, put it in my bag, and pull it out in a coffee shop to find it was on and now the battery is down to 50%. Why is sleep so hard?
Ever since Microsoft added "modern standby" it's not a problem anymore. Chips became power-efficient enough that we can just "fake sleep" now, which means disabling all but one core and downclocking it to the lowest possible frequency. My AMD laptop was 400mhz, draining about 15% per day.
Say what you will about Microsoft, but sometimes a strong leader can make good things happen (TPM2 and modern standby)
Well it's being discussed on here in most linux laptops thread.
On x86 it's because linux relies on the acpi tables which vendors don't bother to do properly.
On Apple ARM hardware/linux it's because Apple don't bother releasing any docs.
On other ARM SoCs... not sure. In theory every vendor wants volume orders for phones so they should be able to sleep properly?
It's sad if you're an Apple hardware + software slave and used to just closing the lid on your laptop and having it basically lose no battery for days, especially since ARM.
I once considered making a spinning persistence of vision similar to this one specifically for visualizing lidar data from a spinning automotive lidar. The lidar has 128 beams and you could make a spinning array of 128 1D LED displays at exactly the same beam angles to recreate the point cloud from the lidar.
Anyway, I was too lazy to make it, but it's super neat to see that someone actually made something similar.
The externally spinning Waymo Laser Bear Honeycombs do indeed cause whacking and pinching and occasionally get gunked up with wet leaves and debris. One reason why they are like that is because these have very large fields of view. A cylindrical plastic cover seriously degrades optical quality especially when the beam is hitting it at a steep angle. Another reason is that it has a heatsink on the back of the spinny part. Earlier Waymos like the Firefly in fact cover up this lidar, e.g. on the "nose" and the side mirrors [1]. But they went back to leaving it exposed for better performance.
Likewise with the big spinning lidar on top, which was covered in the older Chrysler Pacificas but externally spinning in the newer Jaguar I-Paces.
[1] https://commons.wikimedia.org/wiki/File:Waymo_Zeekr_Vehicle_...
[2] https://commons.wikimedia.org/wiki/File:Waymo_Zeekr_Vehicle_...
reply