I do not get this kind of complaint. Every thing you consider an important part of your life today (including cars and smartphones) started out as toys for rich kids. Complaining about it is asking to go back to the stone age, because all the advancements since were brought to you by someone's desire to make money and someone else being rich enough to afford it, till economies of scale made the poor old you able to afford it too.
Doesn’t work anymore. Our apartment building has a few providers and people were trying to report an outage with ASNs specified and suggesting they check BGP advertisements and so on. It turns out our Google Fiber microwave dishes were misaligned.
Support has costs. Fine. I consider purchases under $500 to not include support, and treat them all as "sold as is"
However, if I need support and cannot reach a real living breathing human in under 30 min regarding any purchase over $500, I hang up, call AmEx and file a chargeback, citing inability to gain support. So far they have backed me every time. If enough people do it, chargeback costs send the message.
The architecture has been changed fundamentally. AFAIK the old windows 2000 had flaws beyond repair. On the other hand the UI overlay build on UI overlay built on UI overlay, making everything a html page etc was terrible direction
God WinME was such hot garbage. Windows 2000 Workstation ran everything that ME ran. I fucking gamed on it, and did everything. It was faster and more stable, than ME. I never understood why people I knew who were computer nerds ran that steaming pile of shit.
Auto hiding scrollbars and useless online help even when you don't have an Internet connection. Ah, and gray on gray, 1px borders and usage of titlebars as window content. And Automatic Updates, Automatic Restarts, Automatic Encryption (they know the key), Automatic ID ( you are a good citizen and don't want to make anything stupid).
Basically it boils down to “trust us, we won’t do what this guy is warning you we might do”
Forgive me, but that’s not convincing. The post even admits that it is entirely possible to do it. It just says that it will “antithetical“. Many antithetical things have been done in the past. It won’t be the first.
There was a member of the FIDO Consortium in a Keepass PR comment section implying that they would blacklist Keepass as a "responsible party" if they didn't remove sharing/export functionality that Google, Apple and others had at the same time.
These bodies need industry involvement/support (I've worked in similar WGs at both Red Hat and Microsoft), but it's very easy to engage in behavior that could easily be ladder-pulling.
What that Keepass X GitHub PR comment section was discussing was giving users a way to export their passkeys to an unencrypted file on disk, which would have allowed for attackers to convince non-technical users to export all their passkeys and then send them to an attacker.
I believe person who commented on that GitHub PR was trying to explain that instead of implementing export to plaintext file on disk, it would be a better idea to implement the Credential Exchange Protocol, which was almost finished at the time.
> no one supported exporting passkeys at the time and I believe the only ones who supported passkey sharing of any kind was Apple
What exactly is the practical difference between "sharing" a key and "exporting" it?
As it is, Apple's Passwords app as of today absolutely allows importing and exporting of Passkeys ("Transfer to another app").
> I believe person who commented on that GitHub PR was trying to explain that instead of implementing export to plaintext file on disk, it would be a better idea to implement the Credential Exchange Protocol, which was almost finished at the time.
This is a very diplomatic presentation.
This was in Tim's very first reply:
> To be very honest here, you risk having KeePassXC blocked by relying parties (similar to #10406).
> I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
> Asking you to put basic protections in place and collaborate with the ecosystem/industry is hardly "anti-user-choice mentality".
"Sure would be a shame if the industry had to block your tool from our standard."
> which would have allowed for attackers to convince non-technical users to export all their passkeys and then send them to an attacker.
I mean, if you can convince a user to do that, there's not much more needed to say "and you can set a password on the encrypted export so it's all secure!" and get an encrypted export too.
> Fast forward to today... and it looks like there's movement towards doing exactly that:
Oh, it only took 2 1/2 years. Most of which was waiting on the FIDO Alliance to actually define a standard:
> > I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.
> There are hundreds of encryption options to choose from. Sure, we can choose AES-256-GCM. To what end? If no other product implements that encryption option, then exporting becomes worthless for portability.
> Define the standard first (just pick one or two), then publish it. There is no need to spend time debating the choice, plenty of great options to choose from.
Indeed, at the time:
> This is out of scope for the protocol and data format. Neither -and to use the working names here- CREEP (CREdential Exchange Protocol) nor CEF (Credential Exchange Format) should make any determinations about how the importer, exporter, or platform should store their keys, but we'll say that it should be secure.
But Tim didn't mention any such thing. As to this claim:
> it would be a better idea to implement the Credential Exchange Protocol, which was almost finished at the time
"was almost finished"?
CXP is still in "Working Draft" status as of today, where it has been for 2 years.
CXF (the format) is a "proposed standard" as of today.
I read it as "your actions might push relying parties to use attestation to be able to block you", not as "we, the FIDO consortium will block you". (How could they? There's no signer identity to block without attestation!)
That said I don't agree with the substance of the comment; it's effectively an appeal to security by obscurity/unavailability of user-friendly insecure export methods.
I see we went from feigned concern over consent to just open hypocrisy. Telling, and a very appropriate representation of American policy. I wonder why your global power is waning?
Those with power setting the rules is the way the world worked long before America. It never changed nor could it, as anyone with power would eventually tire of being told how to live
I think you are desperately trying to universalize the particular as a way to reconcile the two conflicting ideological frames you're trying to uphold, and I think your country exhibits the same ideological crisis.
As a simple counterexample to this universalism, think of the European Union. Germany and France could impose their will on smaller neighbors (and did, in less enlightened times!), but they don't, because y'know, they actually believe in rule of law, consent and consensus.
Or as an example closer to home - the Canada / US relationship before recent American aggression.
Things don't have to work by unilateral aggression. It is a specific ideological choice, it is not a law of nature. Now I understand it might feel different while enveloped in said ideology (it literally determines what we perceive to be possible after all!), the same way a Muslim fanatic would attribute everything to Allah's plan, but I'm not really interested in self-justifications.
My dude, Hungary being fined by the club it signed up for makes your point only if your point was that the library dominates you with their late return fees. Not only did Hungary consent to these rules, it could've at any point withdrawn consent through Article 50.
Additionally, this is from 2024, Hungary has since democratically elected a government on the express platform of getting rid of the wannabe dictator that got them fined.
You've mistaken the mere existence of enforcement for domination, just like you keep mistaking ideological preference for natural law.
Also notice the words you used: "attempting self-determination". Weren't you just making the point that might makes right? In that view, Brussels has the power, Hungary doesn't, News at 11, yada yada.
But nobody actually lives by "might makes right", you included. As soon as its somebody you're sympathetic to, the cold realism drops and we're back to consent and sovereignty. That is my point. It's just a line people use to defend power arrangements they like, to be dropped for ones they don't.
There is a reason we consider annual results. A year is a natural complete cycle. There isn’t equal amount of demand in January as in June for almost any product.
So taking one good week and multiplying it by 52 (or 4 x 13 as the case may be) is at least naïve and realistically — deceptive.
Now let's think for a second about why you would ever want to report it that way. There is not one good reason other than hiding your actual measly revenue.
What makes a ROM hard? I'm ignorant of the details of chip design, but I'd expect just a large array of essentially open or closed connections. Is that incorrect?
plus row and column decoders that get more and more complex with size. but consider the size of the weights. convert to mm^2. Gawk at the resulting value
Qwen 3.6-27B is 56 GB of weights. Let's round to 550Gbit. NOBODY makes huge ROMs in modern SoCs, but if we assume it is as dense as the densest TSMC N3 SRAM, this is 33.5 Mbit/mm^2
Then your weights are 16,400 mm^2 !!! The maximum reticle-size N3 die is ~800 mm^2 so you cannot make it.
But, you might say, SRAM is 6 transistors. ROM might be just one. So 1/6 of that... 2730 mm^2... which is still too big to manufacture.
reply