Unfortunately for the 2023 Nissan Leaf has a CAN gateway module. Basically, it's like a firewall or gateway to filter out CAN writing commands commands so you can't directly talk to the car with open tools through the OBD-II. Basically, it's a read-only port that's only when the car is powered on. Unfortunately a lot of cars are now starting to do this. I guess I'm gonna have to make a modified version of CAN tap cable for an unrestricted OBD-II port. :( https://docs.openvehicles.com/en/latest/components/vehicle_n...
It's frustrating but completely expected. OEMs are realizing that telemetry and post-sale software subscriptions are their next major revenue stream. Locking down the CAN bus behind a gateway is always framed as a 'security feature', but the real goal is killing third-party observability and locking you into their proprietary ecosystems. The fact that we have to splice into CAN tap cables on hardware we fully own just to read our own telemetry is absurd.
Are we protecting the owner of the vehicle from fully accessing the vehicle that they own? On my 2011 car I can hook into the OBDB port under the dash and have full access to everything but the alarm system (requires its a separate programmer), and it's safe: drivetrain modifications require the engine to be powered off to apply.
Or is it theft we're protecting everyone from? The main (technological) cause of which lately has been the one-CANbus-to-rule-them-all idiocy that has taken over car makers, including putting the alarm and locking systems on the same unmoderated, unauthenticated CAN bus as everything else in the car. So a quick light pop and you're able to talk to every system in the car. We're back to solving a problem that didn't need to exist in the first place, if car makers had just thought this through before rolling it out to everything.
The correct solution here is to not further restrict the personal freedom of property owners but instead to stop designing and building systems that require stupid, and somehow always dystopian, solutions to even more stupid problems.
Ok so what do you propose? Split the CAN bus into multiple, put security-critical parts on its own isolated network that you can't write to... Well now you've made the situation even worse for the owner than it currently is. Almost anything interesting on the bus can be considered security critical, so the owners would get access to nothing but boring telemetry....exactly what they get through the read-only gateway.
Proper security requires authentication and freedom-preserving authentication has to have owner-controlled credentials. That's the only way forward. Who cares where they run which bus. Encrypt/authenticate everything and give the owner a way to set their own key. Now we just need to figure out a way to make this a law...
Regarding the 30% cut. Developers can actually generate steam keys and publish them on third-party sites which can be redeemed by users on Steam. Developers then get 100% of the profit.
But they're only limited to 5000 keys. beyond that requires special approval, which is not given if the game is being sold more outside Steam than inside.
The complaint is that the platform they are using for advertising, distribution and/or community isn't giving them enough free keys? Just want to make sure I understand the relationship and expectations.
> Are the developers allowed to sell those keys for less than the Steam price?
I believe so. However, even if it's not I don't see any other platform allowing you to use their service and sidestep platform fees. Someone mentioned above that there might be limitations for the number of keys, but I'm not aware.
That would require GNU/Linux distros to un-GNU themselves or even almost all Linux software un-everthing. The current Linux desktop architecture is built upon everybody compiling stuff per distro and per version. Everything is built on the assumption that "some people" will choose a subset of packages and versions and curate and do the work again and again to obtain binaries that can only work with that specific curation.
I think it is practically impossible to fix Linux desktop without reinventing it under a single entity like AOSP or BSDs.
Regardless of which way you slice it, it is really neet to be able to automate more aspects of our lives than ever before. It's not so much about the framework we use, the fact that we have the endpoints to use them.
reply