While I don't want to discuss the quality of any distro vs Windows, there is a big reason most of us use free software: because it is free.
Whether for you it is because of free as in freedom or free as in beer specifically, quality may not have much to do with it.
In EU at least you can almost get free as in beer Windows, you can buy a fully legal 2nd hand (resold) Windows license for about $10, the price of a fancy beer.
This is bad enough that I'm going to stop serving cgit. I've been doing cvsweb, then subversion, then cgit over my home server for many many years and for the first time ever this is annoying my own bw usage.
It's ridiculous also how you ban an IP then 1 second later another one picks up from where the first one left on.
This still would allow one to "strobe" the power line making it impossible for a human to see the LED but the camera could still capture snapshots and at a decent framerate even.
Naw the LED stays on a little longer after you stop capturing image data. They either have burned in firmware or a simple circuit (RC and comparator) that stops your attack.
I think that this is not true -- the achievements mentioned here are hardly ground breaking and mostly build on work that was already done years before LLMs were a thing.
There are things that the "open source movement" dreams about, and one just has to search around... E.g. like codecs, Qualcomm's aptX lossless, adaptative, and other more recent variations.
It's not new capabilities, it's new levels of access. Reverse engineering this stuff used to be a very tedious process which required a lot of specialised skill. Which is why most devices haven't been reverse engineered or hacked despite being full of low hanging fruit.
I kinda remember that the counterargument Google used is that only devices with a special attribute would ever be available through WebHID, ensuring that such older devices would never be exposed.
Cue my surprise when it turns out you can use WebHID to program a Minidisc / Net-MD device [1], so.. they never did implement that filter, apparently. I mean, certainly it is useful, but ... What The F., Google?
The user has to first specifically pick the device from the list and grant the website access. If a user is confused by a permissions prompt and has no idea what is going on, the default path is to reject the permission.
In the real world the default action for a user when presented with a permissions popup is to accept it because they get asked 20 times a day, have no idea what the implications of it are and just want to get on with their day.
So software designers need to avoid asking the users to approve potentially highly dangerous things.
This is untrue. Chrome's "acceptance rates" for proceeding through its bad SSL cert warnings used to be pretty high, but with a redesign they basically flipped the numbers so most people didn't proceed to connect to the site. Similarly with cookie banners, where making it more difficult to say no (by e.g. moving a decline button to a second interaction layer) meaningfully raises acceptance rates; if users were just blindly accepting everything, then there'd be no reason to make it harder to say no. Apple's App Tracking Transparency (ATT) prompt has users overwhelmingly answering no even years after introduction (though of course opt-in is increasing). A study on permission prompts in Android found that the main factor in first-use denial rates was whether users thought the app needed the permission it was requesting or not, showing some actual comprehension of what they're being asked. Another found higher denial rates if the frequency of the prompt was on every access instead of once, rather than apathetic blanket acceptance.
Design prompts for potentially dangerous actions so refusal is easy and what's being asked is legible, and people will refuse plenty.
I think Safari does this with popups & downloads. Tiny little icons that barely appear [to change]. Can annoy me when I miss them but sometimes I figure maybe it’s for The Greater Good.
You realize that most of the time that you are giving access to an older HID device, you are giving the website permission to convert that device into a persistent backdoor forever? No matter if you later close the browser or revoke the permission -- the damage has already been done? Most devices predating WebHID and the like have almost no protection (why would they?), and you can corrupt or even entirely replace the firmware quite easily. heck, NetMD is one example (the browser can overwrite its firmware with no trouble!), as are the devices listed in TFA .
It is basically the same reason most desktops do not give the logged in user access to /dev/hidraw*, even though it makes a shitton of sense and would simplify many things greatly.
This is one of the few areas where I think Mozilla did the right thing without question.
WebUSB has been live in Chrome for 9 years and nothing happened. Compare to all the features that result in people getting hacked every day. Your threat model is ridiculous.
Look, I find it funny that I find myself arguing on the other side of the discussion that I'm frequently on, but here is where I draw the line, and I think what is ridiculous is to think otherwise.
How many hoops Google asks you to go to install an Android app ? (Androids amounts to basically the most sandboxed environment one can have today; malware installed there can practically do _nothing_) MANY. Centralized register of apps and remote blacklisting, a lot of permission prompts, password check, and they are even literally pushing to even have a physical 24h cool-off period if you skip the centralized register.
How many hoops does Google ask you to go an allow a random website unfettered access to destroy your hardware? One. Permission. Prompt. In a bubble prompt, that barely registers above noise compared to other permission prompts browsers ask.
Of course these are two ridiculous extremes, but they exemplify the point. There is a reason a browser won't allow a random website to write over random sectors of your hard disk just because you said "accept" to a bubble-style permission prompt about wanting to "save files to your hard disk". The line has to be drawn somewhere, and allowing what basically amounts to raw access to IO ports just after a single permission prompt listing the device name is where I draw it. Any user, even knowledgeable ones, is simply going to be _incapable_ of truly understanding the risks behind allowing this access.
I would be much more in favor of allowing random IPC to services in your local computer (after a permission prompt) than this., something that is equally useful if not more than allow raw access to HID.
Devices need to be hidden behind drivers that multiplex and control access to the device at the OS level. A bus that was never meant to be exposed to user-level access should not be exposed to random programs much less websites. This is not security, this is "mistake prevention" level, in the same way operating systems disallow a random user-level program from overwriting the hard disk.
And do not read this as "devices should sign their firmwares and what not". That is (for me) definitely the wrong take but literally the only take that is left on the table due to Google's stupid behavior.
> How many hoops Google asks you to go to install an Android app ? (Androids amounts to basically the most sandboxed environment one can have today; malware installed there can practically do _nothing_) MANY. Centralized register of apps and remote blacklisting, a lot of permission prompts, password check, and they are even literally pushing to even have a physical 24h cool-off period if you skip the centralized register.
I 'member (and miss) the old Android days before everything became the locked down hellscape Android is these days. And I also member why it became that way, there was a loooot of bad actors exploiting that open model.
For operating systems it's similar. DOS/Windows up to and through ME didn't have the concept of different user levels, the file system didn't allow for it, and if you had physical access to the machine it was trivial to corrupt and subvert it. Only with Windows XP, Microsoft switched the consumer OS to NT and its multi-user model.
And so it will be for WebUSB et al. First it will be a pretty open and unrestricted world, and only if there turns out to be a significant problem, security will (need to) be tightened.
WebHID being used to access a microphone is risky though. Microphones are already often exposed to web browsers, so asking for microphone access wouldn't be out of the ordinary.
Maybe MD drives aren't really at risk, but things like HID peripherals definitely are.
> AT&T bakes the width into the mnemonic (movb, movw, movl, movq [...] Intel’s syntax is to prefix the memory operand with byte, word, dword, or qword, but Odin’s just uses the Odin type system directly.
In GAS you can skip the width suffix from the mnemonic, and in most Intel assemblers you can skip the memory type operators like byte. They happily guess it from the operands. The problem is that on x86 (but also other ISAs, even if to a lower extent) the different operand sizes have a lot of side effects, which is why everyone just makes the operand size explicit, up to the point that apparently the author/LLM believes that it is mandatory to specify them.
This kind of defeats the headline of the article...
Tomorrow you need to pass a 128 bit int into two registers and your fancy syntax then also becomes a messy bunch of hacks. This is why everyone's inline assembly syntax looks like that, because they want to cover the weird cases (gcc's one is almost like an history book). You're normally using inline assembly for when you have some ridiculous corner case, if not, then what you ought to use is more akin to intrinsics...
Also it forgets Watcom C, which does have a complete but messy syntax for inline assembly (which combines nicely with its ability to specify really weird calling conventions).
> Tomorrow you need to pass a 128 bit int into two registers and your fancy syntax then also becomes a messy bunch of hacks.
There are no 128-bit integer registers in x64 or arm64 or riscv64. There are operations that represent 128-bit scalar operands/results by storing the top and bottom halves in two 64-bit registers. From what I can gather, it would look something like this in Odin for x64:
my_asm_mul :: asm(a: u64, b: u64) -> (c, d: u64) [
a -> d = %rax,
c = %rdx,
] {
mul b
}
my_mul :: proc(a: u64, b: u64) -> u128 {
hi, lo := my_asm_mul(a, b)
result := (u128(hi) << 64) | u128(lo)
return result
}
> the different operand sizes have a lot of side effects
Which we have massive tables for each form which track those side effects and clobbering information too.
> author/LLM
I am the author, and not an LLM.
> Tomorrow you need to pass a 128 bit int into two registers
Okay? There are no 128-bit integer registers on AMD64, ARM64, nor RISCV-64. So I have no idea what you are on about. And note they are templates, so if you want 128-bit integer support, you can just wrap that template in a procedure and handle the behaviour yourself.
Have extremely different performance characteristics, yet would map to the same code:
ld1d dst, p0/z, [base + idx<<3]
Imo this makes reading the assembly quite bothersome. I'm already not a fan of ARM64 doing the mnemonic overloading, but at least you can figure out the operation by looking at the same line further to the right.
Also, maybe I missed it, but how are you dealing with things like the /z modifier, pre/post-increment load/store and load pair? Or things like TBL/ST4/LD4?
Oh and how are the types going to work for RVV, where the type can't be determined at compile-time in all situations?
So the parameter is marked as a predicate with zeroing or whatever, and then `pred` is just a normal operand as the binding section specifies everything.
This is not current behaviour yet but it I am considering it when I need to specify this for even AVX-512 and RISC-V behaviour (which has multiple different possibilities).
>Which we have massive tables for each form which track those side effects and clobbering information too.
No, you have tables _of the instructions that the compiler codegen may use_. You have no tables of what someone may use inside inline assembly, because for most architectures it may not even be possible to build such tables in the first place!. That's a reason why usually you rely on the users specifying the side effects manually for these cases.
> Okay? There are no 128-bit integer registers on AMD64, ARM64, nor RISCV-64. So I have no idea what you are on about.
You have no idea why you would need to pass a 128 bit int in two registers if there are no two 128-bit integer registers? Am I missing something here?
Even rdtsc is already returning a 64-bit into two registers (another x86 idiosyncrasy I suppose), rather than "two separate return values", something the examples kind of gloss over.
> No, you have tables _of the instructions that the compiler codegen may use_.
That's a distinction without a difference.
> ...because for most architectures it may not even be possible to build such tables in the first place!.
Name the architectures and the specific instructions; do not be hypothetical. In certain runtime-dependent cases like AVX-512, the clobbering is runtime-dependent which then can be explicitly stated by the user.
> You have no idea why you would need to pass a 128 bit int in two registers if there are no two 128-bit integer registers?
I completely understand, my point is that you would pass the two 64-bit parts into separate registers. There are no 128-bit integer registers on the platforms we care about, but if they did exist, supporting them would be trivial. So if you want to pass an 128-bit integer, it will have to be done in two registers, which is literally the point. `asm` templates are not necessarily meant to be used bare all the time, but sometimes it is better to wrap them in a procedure with the correct calling convention too (e.g. "c" or even "naked") if you want to utilizes Odin's native 128-bit integer types as part of the parameters.
> Name the architectures and the specific instructions; do not be hypothetical.
You realize you're asking for a list of instructions that are not used by codegen but exist in the ISA? Because it is practically infinite.
Even a plain old "in" in x86 may go from clobbering only the target registers to clobbering memory to clobbering about _every_ register (e.g. under vmware). And there's a million like these on any architecture.
Short of generically saying all clobber everything, I really don't know how can you build a table here.
And you are forgetting that the problem does not only extend to the compiler here, but to whoever is writing the assembly, because you may be using some register that may or may not be clobbered on depending on which 'mul' instruction operand size was used by the previous one!
> So if you want to pass an 128-bit integer, it will have to be done in two registers, which is literally the point
Some inline assembly syntax (e.g. Watcom) does support return an int64 as 2 registers. Are you understanding this as me asking to change the instruction to return the value in one register or something? What I'm saying is that it supports mapping its 64 bit native type (which is either two registers or always in memory, I don't care) to an inline assembly snippet that uses/returns an int64 value in two registers.
This is just an example of the reason inline assembly syntax grows unwieldy, and there are more! Just about any 'letter' of gcc's extended ASM is another one.
You seem to be trying to implement something like intrinsics here, with a very limited view of what people use inline assembly for, and that's fine, but it simply falls short, and that is why you have a hard time explaining the decisions behind inline asm syntax.
From the same lunacy that forces me to write my 30-something character Wi-Fi password on a "secure password field" that only shows me the last character, almost ensuring that I will make an unlimited number of typos and spend way too much time for something that should only take 30 seconds.
It's not clear who it is protecting against, it does not seem to be effective at protecting against anything at all, it is actively annoying to the user, and has no way to disable. Perfect example of the usual "security theater" feature.
That seems oddly user hostile for apple. Especially for Wi-Fi passwords, which are a very common thing to share. Android has had a feature for years that generates the password as a plaintext-encoded QR code so you can share a wifi password without the other party even needing to type it in. And at least on my pixel 9, I have a toggle on the password entry field to toggle visibility.
I don't have an iOS device handy to compare against, but it surprises me that Apple wouldn't also recognize that Wi-Fi passwords in particular are extremely common things to share.
Unsecure: open Shortcuts, tap Gallery, search “Adjust Clipboard”. Add to Action Button folder and run from Action Button. - Or add “Dismiss Siri and Continue” action after “Get Clipboard” so you can say “Siri, Adjust Clipboard”.
Type in the still-unreasonably small window, tap Done, paste password. (Then clear clipboard I suppose and consider privacy implication if your clipboard syncs to Mac.)
This is often said but if you want to "diagnose" something then the terribly limited Android shell is about the last place you want to be, and a sandboxed one on top of it is worse ....
reply