bri3d

So, the real thing that's happening here is:

* Google drop "real" Android source-code updates to OEMs _and_ the public every half.

* But they ship four Pixel updates, including documentation + SDKs.

* Now they added new APIs in a Pixel-only update.

* Google also drop security update backports to "trusted" OEMs monthly (which GrapheneOS have had access to for years).

So, there are now Pixel-exclusive app features on the Pixel SDK version which isn't available to OEMs - but, it's highly unlikely any app developer would actually depend on these new APIs, since Pixel marketshare is tiny to begin with. This in essence just makes Pixels a weird beta-testing device for what will come out a quarter later to "normal" devices, which is sort of an odd business decision, but also a weird thing to get really mad about, in my opinion (I do see what GrapheneOS are trying to do, with having OEMs saber-rattle about not getting features on the same cadence as Pixels, it just doesn't resonate very loudly for me).

However, the API headline seems to bury a deeper lede; in the thread, GrapheneOS also claim that the quarterly Pixel releases contain security content which is not appearing in the monthly backports. This is quite bad and very sloppy if true, since the Pixel releases can easily be patch-diffed and exploits backed out of them. I'd be interested in seeing this enumerated in more depth.

CA v. Altai (where the abstraction-filteration-comparison principle comes from) and SAS v. World provide pretty strong positive evidence that clean room is a valuable technique in both the US and Europe.

I do agree with you that the term is misused (it’s almost completely irrelevant here, anyway) and over-applied, but “not having ever been in a position to see or access the source code” is proven, especially in SAS v World, to be a pretty strong defense that’s worth pursuing in some re-implementation scenarios.

By not having void air space in between cylindrical cells like you'd get with two 18650s? It's mostly just a matter of packaging.

Pouches can be made to have better volumetric density than cylindrical cells quite easily, which is why laptops aren't generally full of cylinder cells anymore; the challenge is just providing them enough external support/compression and swelling allowance, which can be accomplished through chassis design.

I read this as the chunks are 64 bytes and thus each chunk is split over 9 frames. I haven’t looked yet but it’s probably an ISO-TP esque framing protocol.

Yeah, that’s a good way to summarize what people are mad about; they basically moved all of the calibration from onboard to offboard diagnostics, and then thwarted most efforts to access the offboard diagnostics.

Automotive is similar and I’m a bit worried for EVs; for ICE autos there’s enough emissions related regulation that some diagnostics and manuals are accessible, but for EVs there’s nothing much stopping a Deere style complete lockdown.

Newer Deere equipment has a lot of components that have to be adapted using DSA - turbo actuators, various hydraulic sensors, various suspension leveling sensors, fuel injectors, interior displays, and anything SCR related are the big ones. Basically, any sensor that needs a calibration step or triggers an emissions code, or a few intentionally vehicle locked modules (ECM).

Palantir sell consulting services ("forward deployed engineering") around graph and map database platforms, using data supplied by customers. Some of their customers ask them to make surveillance aggregation systems, others ask them to make totally banal and random enterprise software (this is why you commonly see freak-outs around hospitals buying "Palantir," for example; usually they are operating as consultants making some kind of medical records warehousing system owned by the customer).

Samdesk provide risk analytics using traditional risk analysis investigation and research, which they have now welded an "AI platform" to, like everyone does these days. They aggregate crime and protest data to make a map of "places your employees might be at risk" and sell it to companies.

Samdesk would be a Palantir _customer_ if they liked parting with their money, not a competitor; Palantir operate at a much "lower level" and don't do the data collection or research on their own.

I don't agree that this particular trait of macOS makes an implementation at the layer WINE implements (full API+ABI) any harder or easier. Certainly, vertical integration makes OS porting (ie Asahi) and lower level emulation more difficult, since the hardware and firmware's contract with the OS is entirely proprietary and can be freely changed from revision to revision, but something like WINE operates many layers above this anyway.

There's a reasonable argument that the Win32 API was designed to be more stable than the Mac OS one and this makes WINE's task easier, but this sword is double-edged: while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used. With the continued proliferation of Windows UI frameworks and OS subsystems, it becomes difficult to argue that Windows is any easier than Mac OS would be to implement at an API layer.

I do think there is an argument to be made that Win32 was more straightforward and felt more tractable when WINE _started_, and therefore the project was able to scale with the problem space, while OS X started from a "larger" place and was therefore more daunting, but this again is a timing and traction argument more so than a purely technical one.

No? Windows also has its own graphics subsystem, compositor, and an even bigger set of user land UI/forms/controls libraries than Mac OS. It really is just a critical velocity / adoption / time thing, there’s nothing strongly technical separating Mac OS API/ABI translation from Windows ala wine.

I don't think this is new with LLMs (finding an exploit based on a few words offhand has always been a fun part of exploit development), but it's scaled and democratized to mass exploitation of low value targets. Backing exploit PoCs out of patches, commit messages, and random overheard or over-read sentences is a practice as old as vulnerability research. The difference with LLMs is that an explosion in actors "skilled enough" (human or not) has enabled sloppy / low-skill "exploit the whole Internet" actors in a way they weren't previously enabled.

I do agree with the author's ideas, though; most of these are things that should have been done much sooner, and I suppose it's good in a sense that there is a forcing factor now.

> The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.

I strongly disagree with this notion from even a conceptual (much less legal) level; the point of compilation is not to erase the algorithms the programmer implemented, just to optimize and implement them.

> You can compile a decomp into the same binary, but that's only to prove functional equivalence.

This is like saying that a translated book is only "functionally" identical to the original; there's a lot of precedent in copyright law for this not being the case, and I don't think any argument revolving around the transformativeness of the compilation process would fly at all.

Yes, I agree with you (see my sibling post), but it's not what the post I replied to was saying.

It seems like it could go either way to me in the US (not a lawyer, but someone who has a fair amount of experience in reverse engineering / fair use issues).

On the one hand, it is fairly clear that producing source code with the explicit goal of reproducing a 1:1 binary is in no way transformative, so that's out. This would be a really hard argument to even attempt.

On the other hand, these projects are mostly free, intended for owners of the game to play the original game on a different platform or in a modified format, and not likely to have a negative effect on the original work's desirability or value. And, the reproductions aren't complete and alone usually produce limited to no value to a consumer (usually, they won't start without the original game files). These are the other important factors considered in fair use determinations and generally go the way of these being OK.

So, it's hard to say. With reverse engineering and copyright in the US in general, context is crucially important; something that would be completely illegal for one purpose (ie - decompiling and recompiling a competitor's software to distribute it without a license or use it internally without purchasing it would be obviously illegal) could be OK for another one.

Most of these projects carefully distribute only the source code representation of the binaries, for this reason, relying on the consumer to acquire / own the art assets and copyrighted material (logos, trademarks, etc.).

Only server, as far as I know. Server is now either high-density E core (Sierra Forest) or low-density P core (Granite Rapids), but desktop and laptop are heterogeneous still; laptops are getting even more heterogeneous because they have P-Cores, E-cores, and Low Power Island cores.

There’s a technology fundamental driving the short form aspect too, current video models are all trained on <500 frame sequences and struggle to generate long shots. There are a lot of attempts in the literature to improve cross-generation coherence but there needs to be an architectural breakthrough or significant scaling improvement before longer continuous shots are practical. So you’d be making a really ADD feature film at the moment.

Android has a proprietary HAL on both ends; the userspace interfaces to drivers are not the same as on "normal" Linux for almost any devices (baseband, video acceleration although this is at least EGL based, cameras, sensors, audio DSP, hardware media codecs, etc.), so by the time you replace every component of the OS, you've just made AOSP without the useful security parts.

> The advantage being, we can manage packages using a regular Linux distro

It's much easier, more plausible, and more logical to sandbox a regular Linux package-managed distro inside of Android, which numerous solutions exist for.

Friction drive e-bike conversions were popular years ago.

They generally:

* Wear tires surprisingly quickly

* Absolutely suck in any form of weather or terrain condition (dirt, rain, etc.)

* Have ~20% less efficiency than any other drive form.

But, they are easy, and they do work.

> Wait until they find out your mechanic has unfettered access to your car's OBD port when you hand them the keys

Surprise! “They” did find this out and UN155/156 regulate a bunch of protections against local “attackers,” often to the detriment of right to repair.

With respect to 2), I don't think this should work architecturally even if the DRAM controller has knobs which can be accessed, because the guest's RAM should be encrypted with keys that can't be recovered in this way.

It's definitely a good research topic because there are a lot of moving pieces and having this kind of primitive might weaken one of them in a useful way, but at least at the top level, you couldn't just swap one guest's DRAM bank with another and get their confidential memory contents back this way.

No, because the two platforms often don't share the same underlying kernels; this has been one of the main issues and complaints with ROCm/MIOpen since the start, although they are catching up slowly.

This is actually a corollary to the point I was making about "CUDA" usually also including a ton of the included kernels and not just referring to a crappy programming environment; translating mid-level C that does math between two runtimes wouldn't be hard for an LLM, but translating "doBigDNNThingNVidiaGaveMeInAKernel()" to "doBigDNNThingByHandBecauseAMDDoesntSupportIt()" isn't a rote translation at all.

Of course, once you accept that it's _not_ "why don't you just translate it," you _can_ iteratively use an LLM to implement the ThingNVidiaGaveYouInAKernel, but it probably isn't well-trained, yet, on low-level AMD optimization tricks, so the kernel you end up with will likely be slower than the CUDA one.

ZLUDA is still alive. AMD sponsored it and the project was briefly halted during a dispute with them, but it’s been making steady progress.

It doesn’t really make sense for AMD themselves or most use cases, though; any compatibility shim just adds problems on top of problems, and for AMD, entrenching a competitors technology even more never really seemed like a great idea.

The CUDA runtime coming with a gazillion reasonably decent kernels (DNN, BLAS, CUTLASS) and a concurrency system (NCCL) is a big deal; especially in the “early days” very few researchers or development runtimes were even writing their own kernels or dealing with CUDA C++ extensively, they were wrapping the ones NVidia gave them.

I do agree that it’s really not great, and I also have never been a strong believer in the CUDA moat overall; as the need for GPUs moves from research to production (inference), companies are plenty willing to build software from scratch anyway (and we see this with AMD GPUs being in plenty high demand in the datacenter and enthusiast market now).

He gave a talk at Defcon.

Certainly not at these frequencies and corresponding high capacitance values; getting 22nF out of a PCB even with ECM would require quite a large surface area and at 220GHz you can't have that since your wavelength is so short; you'd just be making a giant resonator instead.

A sizable percentage of datacenters use open loop water spray towers, but the alternative, forced air exchange (ie add more giant fans) uses more electricity. It’s fairly complex to quantify which is “better” or “worse” but there exist data centers that evaporate a ton of water and send it elsewhere. (for what it’s worth I agree most of the anti datacenter hype is overblown and driven by specific poorly designed gas turbine powered installations).

That's not how this works, at all.

Visual approach is a specific IFR procedure. It's basically designed to expedite and simplify the landing process in situations where the pilot can see the airport and traffic allows - instead of flying a detailed set of waypoints provided by an approach plate (via RNAV/GPS, ILS/VOR/DME, or vectors), the pilot and ATC both agree "hey, you can see the runway and/or traffic, you got this now" and the pilot lands.

By asking for a visual approach and getting approved, then not subsequently asking for another approach, the PIC was flying visually. There's nothing more to it. There's no nuance or gotcha here, and nothing seems procedurally incorrect or even out of the ordinary.

"Canceling" IFR just means concluding the flight plan and "closing the file;" which they were given the option to do in the air or on the ground, but it's not relevant to the approach they chose to fly.

The root cause of this incident is clearly pilot error; the pilot specifically chose to fly a visual approach without adequate visual reference and descended into terrain.

There are proximate causes too, which may or may not relate to the GPS jamming and for which more information is required. For example - did the pilot choose to request the visual approach because they didn't want to fly an RNAV approach in case GPS was inaccurate, or because they didn't want to burden ATC? or did they just choose the visual approach because they could see the airport and it's easier that way? Was this in line with any guidelines from their operator? We don't know that yet. And there's some chance that without GPS jamming, a secondary safety system (GPWS, moving map, etc.) may have saved the pilots from their decision. But these things are all secondary.

Simulink, Labview, Bosch ASCET are all pervasive in control systems engineering, especially in European automotive applications.

> It's a zero day in some caching proxy who may not have had that threat model in mind. I guess its primary purpose is caching packages, not restricting internet access.

In many if not most environments where I have seen these used, they are used to bridge an access boundary and are absolutely security critical. Frequently (and probably in this application, too), they are used for security enforcement in an architecture where CI doesn't have Internet access, but does need to download packages. This is a pretty big deal for a lot of big companies; historically they have relied on stuff like package proxies to help protect them from supply chain compromises like post-install script exploits by preventing CI from being able to detonate an arbitrary Internet payload; if a supply-chain worm were to incorporate this exploit, it would be a lot scarier and more potent. Actually, from the supply-chain worm standpoint, this is arguably a bigger finding than a Docker escape - I suspect we can look forward to more shenanigans in this space coming soon.

It's "just" a restructuring; the previous setup was a really bizarre financial product where Citizens Bank gave you a 24-month 0% personal loan to buy an iPhone, but Apple would also buy your phone and loan out and sell you a new one every 12 months.

Now it's just a normal lease product with a 0% money factor through Klarna, that also works across Apple.

What this does is gives Apple more "price flexibility" (aka, they can raise prices more easily, which was probably a lot of the driver for this), but also gives consumers more buying power flexibility since it's a simple product that works across the board rather than a bizarre iPhone specific optimized financial instrument.