Or to illustrate the convenience to the point of the article, being reverse engineering; not necessarily to critique their security practices here. Being easy to reverse engineer is not necessarily a weakness of security (as the inverse would simply be obscurity).
I can't find a USB-C PD adapter for a laptop that uses less than 100W. As a result, I can't charge a 65W laptop from a 65W port because the adapter doesn't even work unless the port is at least 100W.
I've noticed that GAN PD's 100w and 65w adapters output is actually less (both do not charge my laptop) than lenovo 65w charger (the one with a non-detachable usbc cable). Cable does not matter, tried with many of them including ones providing power from other chargers.
It seems totally random, and you cannot rely on watts anymore.
There's a fair number of misleading our outright wrong specs if your buying from amazon or the like. And even if you're buying brand name, the specs can be misleading. They often refer to the maximum output of all the ports, not the maximum output of a port.
So a 100 watt GAN charger might be able to deliver only 65 watts from it's main "laptop" port, but it has two other ports that can do 25 and 10 watts each. Still 100 watts in total, but your laptop will never get it's 100 watts.
Not every brand is as transparent about this, sometimes it's only visible in product marketing images instead of real specs. Real shady.
> Cable does not matter, tried with many of them including ones providing power from other chargers.
That might not necessarily be the right conclusion. My understanding is: almost all USB-C power cables you will enounter day to day support a max current of at most 3A (the most that a cable can signal support for without an emarker). That means that, technically, the highest power USB-PD profile they support is 60W (3A at 20V), and the charger should detect that and not offer the 65W profile, which requires 3.25A.
Maybe some chargers ignore that and offer it anyway, since 3.25A isn't that much more than 3A. For ones that don't and degrade to offering 60W, if a laptop strictly wants 65W, it won't charge off of them.
So it's worth acquiring a cable that specifically supports 5A to try, which is needed for every profile above 60W (and such a cable should support all profiles up to the 240W one, which is 5A*48V).
(I might be mistaken about some of that, it's just what I cobbled together while trying to figure out what chargers work with my extremely-picky-about-power lenovo x1e)
I have a dell laptop that uses a usbc port to charge, but doesn't actually use the PD specification, but a custom one, so my 65w GAN charger falls back to 5v 0.5a and isn't useful at all. I'd bet dollars to donuts that your Lenovo is doing similar shit.
For this specific issue I'm surprised, I have used all kinds of USB PD chargers for my laptops and all of them but one are less than 100W, with no problem at all.
The ones I use most are 20W and 40W, just stuff I ordered from AliExpress (Baseus brand I think).
This laptop uses a weird barrel jack so I have to try to find something USB-C-to-this-specific-barrel-jack. So far I haven't found anything that doesn't require 100w, as everything on the planet is just rebrands from the exact same Chinese factory.
> Traditional capabilities last forever, unless there is some sort of support for revoking already issued capabilities, and those mechanisms tend are far from straightforward.
Capabilities don't have to hold the actual permission to access the object. Capabilities can simply hold a provenance that can be used to verify the source of the access. If that access is then revoked from that source, the capability doesn't need to change at all. This is similar to how generational arenas work in some game engines, IMO.
AFAIK Android performs something similar to this with the storage URLs that are provided to apps, which will be different depending on which picker provided the file/media, etc. Apple probably also does something similar, but I'd imagine with objects rather than strings.
> Capabilities don't have to hold the actual permission to access the object. Capabilities can simply hold a provenance that can be used to verify the source of the access. If that access is then revoked from that source, the capability doesn't need to change at all.
Which complicates the initial premise that
> capabilities are the simplest model in the world. You hand out objects. You can call methods on the object. What that method call has access to depends on the permissions on the object, not your permissions.
Which is exactly what the parent said. Capabilities sound simple at first, but require complex machinery to work.
> Capabilities can simply hold a provenance that can be used to verify the source of the access. If that access is then revoked from that source, the capability doesn't need to change at all
This is basically using access control lists to mimic a capability system [1]. The capability folks did something similar in "Polaris", their layer atop Windows XP that enforced principle of least authority by default. If only MS had taken that and run with it.
How equivalent this is to ACLs depends on what "provenance" means here.
One of the strategies with capabilities is that I do not hand you the capability that I own to X. Instead, I create a proxy Y that can make requests of X, and then hand you the capability to make requests of Y.
If I later stop Y, you lose access.
This can be viewed as a kind of provenance. The history of how the access came to be is reflected in the actual capability. The downside, obviously, is that we've added overhead. But this strategy can allow us to do a number of interesting things. Like split an existing capability into multiple finer grained ones.
"Construct proxy" need not be a primitive in the core system though. If message passing is the only means of communication, then interposition to create facets or attenuate permissions naturally follows. This works with ACLs too. All you need to do is restrict the rights amplification authority to discriminate what a capability actually points to, but this is a rights amplification operation and so should itself be a capability that's closely held. DCCS did this right, IIRC.
Yes. Just as we can build an ACL on a capability system, we can build a capability system on an ACL.
But this approach is more natural in a capability system. You have to write software differently for dealing with "I got permission through an ACL" versus "I got information through a capability". So when the default expectation is, "I get a capability," the right abstraction is already there for "...and this capability has something more behind it."
> This is basically using access control lists to mimic a capability system
Is it? My understanding is access control lists are typically static, and on resources, defining what is allowed to access them, or on processes/threads/etc, defining what they are allowed to access. If you get a capability from something, and that something eventually becomes invalid, making the capability invalid, is keeping track of that necessarily an access control list? Is any data structure double-checking operations like that always necessarily an access control list? If each capability has a reference to a parent that it relies on to remain valid, does that mean each capability stores an access control list for itself?
If your answer to all of these is "yes, that's an access control list" then my response would be to start ignoring the presence of an access control list as it ceases to mean much of anything.
Rivian's infotainment system uses Google Maps which I am not a big fan of. I wish they would support CarPlay in addition to everything else, so that I wouldn't lose my maps.
I prefer Google Maps. Apple Maps lead me astray too often and though they are better than they used to be they still give weird directions (such as using more obscure state route names for roads rather than the dominant Interstate Higway name).
CarPlay would be a complete non-issue for me, its absence would even be a positive. I just use my phone anyway; integrating it with the car is just added hassle and one less thing I have to worry about remaining compatible 5-10 years from now.
> The nice thing about Apple Intelligence is that it has an easy to find off switch for customers who don't care for it.
Not even only that, but the setup wizard literally asks if you'd like it or not. You don't even have to specifically opt-out of it, because it's opt-in.
I checked out the linked GitHub repo https://github.com/ecosyste-ms/package-manager-resolvers and it appears to be just a README.md that collects summaries of different package managers? How do I know these weren't just LLM-generated?
I feel it's not that controversial to treat LLM output as unreliable without proper verification. So even if the output were accurate, if it's LLM-generated without proper verification I don't trust it.
reply