I remember when Apple got ridiculed for running a commercial where they crushed a bunch of musical instruments and artist supplies into the shape of an iPad.
I guess if AI companies did the same, they would be crushing people into the shape of an input prompt.
Too bad Apple is still preventing the WebUSB spec from being standardized. They won't even make suggestions to get it through committee because WebUSB might cut into their native app store.
From: https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API
"WebUSB provides a way for these non-standardized USB device services to be exposed to the web. This means that hardware manufacturers will be able to provide a way for their device to be accessed from the web, without having to provide their own API."
Firefox's non-reasons are just as lame as Apple's non-reasons. These APIs aren't security risks, the user has to explicitly opt-in on every website that requests USB access, just like every other privacy-risky API that a website requests, like microphone and camera access. WebUSB is no different.
The only thing that has changed since camera and microphone access was allowed is that Apple now considers web apps to cut into their app store business, so they are unwilling to let any new APIs get approved that would make a web app as capable as a native app. This includes WebBluetooth and other APIs.
Apple is also getting sued by the DOJ for exactly this type of shady business practice.
And I don't really think what Firefox says is relevant, they are so cash-strapped I would not doubt that Apple pays them to have a negative opinion about new web APIs just so people like you can say "Firefox doesn't want it either".
The truth is there is no good reason to block WebUSB and WebBluetooth from becoming standards.
The user gets spammed with a million permissions popups a day and has no idea what they are actually accepting or what the risks are. The same looking permissions popup usually means something incredibly trivial like notifications or camera, while the webusb spec is exposing you to potentially high risks of damage to hardware or data theft.
>The user gets spammed with a million permissions popups a day and has no idea what they are actually accepting or what the risks are.
"A million" is quite the hyperbole. So let's just not do anything anymore because it might cause a permission popup? Or because some idiot might trust a scam website? That's your argument? Sorry, it's not a good argument.
>while the webusb spec is exposing you to potentially high risks of damage to hardware or data theft.
Please explain a realistic scenario where a website >that someone trusts< is going to "damage hardware or cause data theft".
I'll wait.
I don't care about someone's stupid grandfather that is going to find a way to get hacked one way or another - he's not a good reason to hold the rest of us back.
That’s the source of the issue. Apple sells products that are safe for someone’s stupid grandfather. WebUSB is not safe for people who don’t understand the implications. Which is most people.
>Apple sells products that are safe for someone’s stupid grandfather.
Then then they should be selling it in "grandfather mode". The rest of the non-stupid people that have iPhones (there are non-stupid people with iPhones, aren't there?) should be able to do what they want with their devices. But they can't because Apple puts profit over progress.
>The rest can choose a different browser.
Except on iOS you can't choose a different browser. Apple has blocked all other browsers on their mobile platform, so if you try to install Chrome, you're really just getting a Safari webview with a wrapper around it. It's just another example of abusive business tactics that the DOJ is suing Apple for.
On iOS you can’t use usb anyway. Even an actual app can’t use usb outside of the wrapper APIs for file access and stuff. So it doesn’t really matter what safari supports here. And on macOS you can use any browser you want.
That's nonsense. You have to opt-in on any website that is requesting USB access, just like every other useful but potentially privacy-risky browser API.
Plenty of sites ask for camera access, and that is typically a USB device. Plenty of sites ask for microphone accesss, which can be a USB device. And even if those aren't always USB devices, they are still very much a privacy risk that browsers all allow. USB access is no different, a website can't just do whatever it wants, you have to give it permission to use it first. And it doesn't have to be all-or-nothing either, it could be implemented to allow the browser to access only specific USB devices.
Apple is holding back progress in favor of profit. They profit when developers are forced to create a native app where Apple can extract 30% of revenue through the app.
It's not about if the camera is a USB device or not, it's about what the capabilities being exposed is. Web browsers aren't just handing over the webcam as an arbitrary USB device, they are presenting a media stream from them. Which means they can't for example send arbitrary commands, flash firmware, or do any of the infinite things a USB device might present.
I'm not giving any old website access to all of my USB devices. I'd expect to give a website I trust access to a specific USB device. I'm not sure why you think this has to be a willy-nilly free-access-to-everything feature.
Yes, I want to give access to site XYZ to a product purchased from site XYZ to do amazing things over WebUSB.
If that isn't the current spec, then change the spec so it's good.
But Apple just doesn't give a single shit to propose any changes because doing so would hurt their precious app store just a little bit.
I don't really think what Mozilla says is relevant, they are so cash-strapped I would not doubt that Apple pays them to have a negative opinion about new web APIs just so people like you can say "Mozilla doesn't want it either".
Vibe coding does not usually produce performant code, it produces spaghetti with the goal of making the user asking for work to be done to go away as soon as possible with a (often barely) working solution.
I recently vibe-translated a simple project from Javascript to C, where Javascript was producing 30fps, and the first C version produced 1 frame every 20 seconds. After some time trying to get the AI to optimize it, I arrived at 1fps from the C project. Not a win, but the AI did produce working C code.
I have no doubt that if I had done this myself (which I will do soon), with the appropriate level of care, it would have been 30fps or more.
Have you ever been to a live rock show and felt exhilarated during it, feeling connected to the crowd and the musicians and the music? AI won't replace that, and I feel bad for people who won't get to experience it because "AI is good enough".
I have. It's exhilarating. The feeling of involved in the crowd during a great live performance by excellent musicians is one of the best things I've ever experienced.
Not the person you're replying to but each have their time and place. When I have a lo fi playlist on I don't expect to feel exhilarated, connected to the crowd and the musicians.
>. It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.
The product is also a bit wonky and doesn't always provide the benefits it's hyped for. It often doesn't even produce any result for me, just keeps me waiting and waiting... and nothing happens, which is what I expect from a vibe coded app.
>That the server can send you a backdoor every single time, made just for you, and nobody else will ever know?
There is no "backdoor" when the browser is sandboxed. "backdoor" is a specific thing, I think you need to read up on it before you keep using it incorrectly:
>On the other hand, an app is sandboxed, too (on mobile OSes like Android and iOS). When you download it, you can check a hash that you can (if you want to) compare with a friend to see if they got the same app.
That isn't what "sandboxed" means, it has nothing to do with checking hashes. And no, mobile apps are not really sandboxed, they have full access to your mobile device once you install it and give it access - and let's be real, most people are just going to blindly click "allow" for anything the app requests after installing an app.
>With an app, there is intermediary (the "app store") that would need to collude with the developers to send a backdoor just for you, and even then you would still have the app binary as proof.
You keep referring to "backdoor", and I don't think you really know what that means.
>That's always a question I have with "secure" web services: if you use ProtonMail, you trust that Proton doesn't send you a web page that leaks your key. But if you trust Proton for that, what's the point of the end-to-end encryption? When you use the Signal app, the whole idea is that you don't have to trust Signal for the end-to-end encryption, at all.
That isn't how any of this works. The main value proposition of Signal is that we do trust its end-to-end encryption. Protonmail sending a "web page" that "leaks your key"? WTF?
It's obvious what GP meant - we can verify that the apps we download are the apps everyone else downloads.
We can't do this with Proton where our mail is supposedly end-to-end encrypted. They can easily view our mail if they can send us a different code when we load their site.
> That isn't what "sandboxed" means, it has nothing to do with checking hashes. And no, mobile apps are not really sandboxed
Apps ARE somewhat sandboxes and GP didn't mean than sandboxing == checking hashes. It was 2 sentences appearing one after the other.
Well, you can verify that the code that you downloaded is the same that everyone else downloaded. Even if it contains webviews.
Now if it contains webviews, it brings the security issue of... the webapps, of course.
Personally, I want an open source app. You can audit an open source app and even compile it yourself. You can't really do that with a website. And I don't mean just mobile apps, that applies to desktop apps, too. I wouldn't run a web-based terminal, for instance (do people actually do that?).
>Well, you can verify that the code that you downloaded is the same that everyone else downloaded. Even if it contains webviews.
Not impossible to do with websites, if the need to do it was there. It would take about 15 minutes to create a browser extension that could make a hash of all the files loaded, to compare with other users with the extension installed - but honestly that's just not needed because if you're connecting via HTTPS, then you're getting the files that are intended to be served, presumably not malicious if you trust the source. And if you don't trust the source, then why are you loading it to begin with??
>Now if it contains webviews, it brings the security issue of... the webapps, of course.
Web applications are sandboxed in the web browser. Very little issue with that, outside of browser bugs/exploits, but bugs and exploits are found in every system ever.
>I wouldn't run a web-based terminal, for instance (do people actually do that?).
AWS has a web-based terminal for EC2 instances. It's not a problem, a lot of people use it.
> And if you don't trust the source, then why are you loading it to begin with??
I trust that Proton (for example) has implemented E2EE in their services. I wouldn't trust them to handle my unencrypted data - I wouldn't trust anyone for that. I don't trust that their security is perfect - no one's security is. So if they're breached, they could serve me malicious JS. I don't trust they're impervious to government pressure or blackmail. By making sure the files served to me are the same as the files served to anyone else, I can be relatively sure I'm not targeted personally. People could also review those files to make sure they're not malicious.
> It would take about 15 minutes to create a browser extension that could make a hash of all the files loaded, to compare with other users with the extension installed
You completely underestimate it. I am absolutely certain that you cannot create a browser extension that meaningfully solves this problem in 15 minutes.
> Web applications are sandboxed in the web browser. Very little issue with that
Except that when we are talking about end-to-end encryption, the sandbox has nothing to do with it. The sandbox defends against something else, not the server serving you an end-to-end encryption program abusing it.
> AWS has a web-based terminal for EC2 instances. It's not a problem, a lot of people use it.
I genuinely can't see if you just don't understand the point being discussed at all, or if you keep saying off-topic things as a way to divert the discussion.
>You completely underestimate it. I am absolutely certain that you cannot create a browser extension that meaningfully solves this problem in 15 minutes.
You are absolutely wrong. I write browser extensions, I can spin up a new one in a minute, and the code to monitor and hash all resources loaded by a webpage is trivially easy to do. It would be simple to set up a server to allow comparing the hashes, in a POC. I'm not talking about making this a robust service that everyone can use, I'm only talking about how easy it is to do in a general way. It's far easier than you think it is.
>>>I wouldn't run a web-based terminal, for instance (do people actually do that?).
>> AWS has a web-based terminal for EC2 instances. It's not a problem, a lot of people use it.
>I genuinely can't see if you just don't understand the point being discussed at all, or if you keep saying off-topic things as a way to divert the discussion.
You're right, I certainly don't understand the nonsense you're trying to convey.
I'm also tired of this pointless internet interaction. Goodbye.
> I'm not talking about making this a robust service that everyone can use
Right. So you cannot do it. Thank you.
> I'm also tired of this pointless internet interaction. Goodbye.
Seems to me that you don't enjoy discussing with people who behave like jerks, which I admittedly did, just for you). You may not have realised it, but you started it. I am happy to disagree in a respectful tone, but you broke it first. Maybe that's something to think about in your next totally meaningful internet interaction, though it sounds like you like telling others that you know better because you are older.
>We can't do this with Proton where our mail is supposedly end-to-end encrypted. They can easily view our mail if they can send us a different code when we load their site.
That isn't a problem with how the web works vs how apps work, that's a problem with you trusting Protonmail.
If you really wanted to be secure sending an email or any communication, you wouldn't trust any third party, be it an app or a website - you would encrypt your message on an air-gapped system, preferably a minimal known safe linux installation, and move the encrypted file to a USB, and then insert the USB into a system with network access, and then send the encrypted file to your destination through any service out there, even plain old unencrypted http would work at that point, because your message is already encrypted.
The second you give your unencrypted message to any third-party on any device with an input box and a network connection, is the moment you made it public. If I had to be extremely sure that my message isn't read by anyone else, typing it into a mobile app or a web browser isn't the place I'd start - it would only be done as a last resort.
That is a problem with you not understanding how security works.
> If you really wanted to be secure
There is no such thing as "being really secure". There are threat models, and implementations that defend you against them. Because you can't prevent a bulldozer from destroying your front door does not mean that it is useless to ever lock it.
Even your air-gapped example is wrong, because it means that you have to trust that system (unless you are capable of building a computer from scratch in your garage, which I doubt).
Sending an encrypted over the Signal app is a lot more secure than sending an email over the ProtonMail website, which itself is more secure than sending it in a non-secret Telegram channel. It's a gradient, it can be "more" or "less" secure, it doesn't have to be "all or nothing" as you seem to believe.
>That is a problem with you not understanding how security works.
That's hilariously wrong.
>There is no such thing as "being really secure".
Sure there is. "Being really secure" isn't what I said at all, and it's a vague statement to make. You're reaching to create an internet argument, and I'm frankly bored of this, you're out of your depth.
>Even your air-gapped example is wrong, because it means that you have to trust that system
I'd trust a system that I set up. I'm not going to do it on a system that you set up, that much is for certain.
> (unless you are capable of building a computer from scratch in your garage, which I doubt).
I still have an EPROM burner, so yes, I could, and I have.
>Sending an encrypted over the Signal app is a lot more secure than sending an email over the ProtonMail website
If you really think that, then nobody should be taking security advice from you.
I'm really tired of this pointless internet interaction. Goodbye.
AlBugdy and the person you are replying to are literally right re: server delivered backdoors. Using E2EE applications in a browser moves the trust back from the client to the server.
> That isn't how any of this works. The main value proposition of Signal is that we do trust its end-to-end encryption. Protonmail sending a "web page" that "leaks your key"? WTF?
Yes and it's that you also trust the client, with a server that dynamically delivers code you have no way of knowing fully what payload it's sending you. An example of this vulnerability was discussed when it was pointed out that 1P, Bitwarden and others were susceptible to server side backdoors if used from the web in that research study that came out last month that was posted here.
> And no, mobile apps are not really sandboxed, they have full access to your mobile device once you install it and give it access - and let's be real, most people are just going to blindly click "allow" for anything the app requests after installing an app.
This is genuinely just not true, even if you click allow for all permissions on Android and iOS. An application on a non-rooted device doesn't have "full access."
Dude, I was here to talk about security, not to be judged on the quality of my English. What I get from your take is that your English is better than mine, but not your security knowledge.
> That isn't what "sandboxed" means, it has nothing to do with checking hashes.
I didn't say it had anything to do with it. I meant that NOT ONLY it is sandboxed, but ON TOP OF THAT you can check that you received the same code.
> You keep referring to "backdoor", and I don't think you really know what that means.
The only explanation I see for you not understanding what I mean by "backdoor" for the end-to-end encryption is that you have no idea how it works. If you're just being condescending about my language, go for it. Tell me I can't speak your language. But don't tell me I don't understand security, you have absolutely no idea what I know.
> Protonmail sending a "web page" that "leaks your key"? WTF?
You obviously don't understand how it works if this surprises you. I would gladly elaborate with anyone who is not a jerk, but that does not seem to be the case here.
"backdoor" isn't really an English thing, it's a tech thing. If you want to talk about tech, you need to know the terminology. This is not something like the difference between "there" and "their" and "they're". I did not correct your English grammar, I corrected your tech terminology.
>I would gladly elaborate with anyone who is not a jerk, but that does not seem to be the case here.
I was not "a jerk". You didn't seem to understand what a "backdoor" is in terms of tech, and I still don't think you do.
This pointless internet interaction is over. Gooodbye.
So you don't think wisdom is a thing that people acquire as they age?
I can tell you from experience that 22 year old people are generally lacking in wisdom. A few of them have a little bit, but overall 22 year olds are just as stupid as teenagers.
Most people don't have much wisdom by age 22. They do have plenty of hubris though.
If we're speaking about mental capabilities, there's nothing that I could do at 22 that I can't do now being over 50. If anything my wisdom gained from experience makes me more valuable and capable now. Everything you learn makes you stronger, and 22 year olds have not learned much by age 22.
I think wisdom is pretty unevenly learned and its not a guarantee 32 or 42 year olds or 82 year olds have it either. See our well aged POTUS. Either way you don't need wisdom to start working. So many of the "best" minds in various fields started working in that field at like 16, maybe dropped out of college and dug right in. Their initial intellect or specific circumstances allowed them to skip the normal path but really I think a lot of people would have a lot more success if more were allowed to start on real work earlier, and weren't being held back by process like this.
Again, just kind of sucks that you finally hit your stride in your career right as you feel your body and faculties declining with age. I don't think we get senile as soon as people notice you are definitely senile. I think it is a constant slide.
It seems like you think you have it all figured out, but you don't.
>So many of the "best" minds in various fields started working in that field at like 16,
Name them. Also, child prodigies exist but that doesn't mean the rest of us are dummies. You'd also be hard-pressed to find a child prodigy or someone like that as you suggest that is "at the top of their field" that doesn't think someone else is better than they are. There is no real "at the top of their field" in anything.
The only thing that I can detect that has diminished in my old age is my patience for pointless internet interactions like this one. I have better things to do. Goodbye.
> overall 22 year olds are just as stupid as teenagers
It's interesting to start by saying that "wisdom is something you accumulate with time", and right after implying that "being 22 is just the same as being 14" (not mentioning the fact that there was apparently a need to be disrespectful to them).
Pretty sure I know a few people "as stupid as teenagers" who would immediately see how this is a stupid take (and who may feel a need to say that this stupid and condescending take probably came from a "grumpy old man").
It's an IoT device, not a laptop. It does not really need 5ghz to fulfill its purpose as an embedded CPU, and adding 5ghz likely would require making some room for it by removing other functionality.
Yes and in some uses cases it works against you. 2.4 is incredibly crowded without adding 802.11 to the mix. My IoT admins would have less complaints if they could take advantage of my small cell 5Ghz spectrum. This isn't 2005 with widely deployed asymmetrical wireless networks.
I use ESP32s extensively. I also use wifi extensively around the house - I have about 8 wifi access points around the property, with a ton of commercial IoT stuff powered on including sensors, lights, cameras, you name it, I got it. It's about as wifi-congested as any house can get.
So, I was measuring about 250KBit/s on an ESP32, and I decided to test everything that might increase the speed. I tried all the available antenna options for the ESP32 including many exotic antennas using the IPEX antenna connector variant of the ESP32, the stock ESP32 pcb antenna, and several chip antennas. A couple of them got up to 300KBit/s.
I also decided to see what happens when I power everything else off except for a single wifi router. So I did that, and I found that the stock ESP32 pcb antenna still got only 250KBit/s, and the other antennas measured exactly the same as they did before shutting everything down, too.
So, I don't know... 2.4ghz seems fine to me from my anecdotal tests.
Can't you just underpower the antenna on a 2.4 radio if you need networks that don't bleed into each other as badly? Unless it's an issue because of the tiny antennas that usually come on microcontrollers.
True for devices under your control. But think venues with large BYOD counts. Add in that all client devices generally transmit at full power. End result is an environment with not a lot of headroom in the 2.4 space.
2.4ghz isn't the only problem - even cell towers have problems with large amounts of devices. And "large BYOD" events are not a normal use case for wireless, and even 5GHz will have problems in those situations.
I guess if AI companies did the same, they would be crushing people into the shape of an input prompt.
reply