9 ms·

Hyper Text Markup Language ...why is a markup language for hypertext able to control my device's camera? Why have all the relevant standards bodies associated

Hyper Text Markup Language ...why is a markup language for hypertext able to control my device's camera? Why have all the relevant standards bodies associated with this language and protocol gotten on board with turning a markup display language into a full-blown OS?

jrockway 4y ago
Because it's the easiest way to distribute software. The alternative to standards is every browser vendor doing their own thing, and "this website only works on IE". Remember the bad old days of the web where every bank required Windows because their UI was implemented with ActiveX? Standards killed that and now you can view your bank account on Linux. WebRTC has its security downsides, but probably better than running a binary from the Chinese government as root so you can video call someone.
- unixbane 4y ago
  > Because it's the easiest way to distribute software. Not really, webdev is a pain just as much as making a native Windows app or Go binary. Programming is bullshit all the way down. The moment you try to do anything correct in absolutely any modern software stack or framework, you will have to do a bunch of hacks to indirectly force stuff into doing what's needed for your program to be correct. Of course in practice everyone just skips this part, contributing to the said problem. > Standards killed that and now you can view your bank account on Linux. But I literally can't view certain bank websites with Firefox.
  - jrockway 4y ago
    > webdev is a pain just as much as making a native Windows app or Go binary I didn't mean to imply it was easier for the programmer. It's harder! But it's easier for the end user. Click link, app loads. Next best thing to being bundled with the OS.
cyral 4y ago
It's not really controlling the camera. You need the JavaScript MediaDevices API for that. It just launches the mobile camera and requests that you take a picture, and the picture of never returned to the site until you confirm it. (Similar to any app that shows the "Take a Picture" or "Choose from Gallery" dialog when uploading an image. That is actually the default if you don't specify that the photo should come from the filesystem or camera) Regarding the web becoming its own OS.. there is no easier way to make cross platform applications these days. If every OS vendor could agree on some standard desktop API, there would be a lot more native apps.
onion2k 4y ago
I find it incredible that people still think HTML, a spec first published in 1990 when we were using 386s with CGA monitors, shouldn't have evolved to utilise some of the modern features available on today's computers and phones. Why wouldn't we want to be able to do useful things on the web with our devices?
- JohnFen 4y ago
  I'm not arguing that the trend is a bad one, but it does come with downsides that are significant for some. For instance, I certainly don't want every random website I might visit to have access to these abilities. It just strikes me as an unnecessary security risk.
  - dymk 4y ago
    It's a shim on top of a file picker dialog. Instead of taking a picture and picking the file from its saved location, it skips a step and lets you directly supply the file from the OS's camera app.
  - acdha 4y ago
    What exactly is the security risk? The browser intermediates all access and you already trust the browser to handle many other sensitive operations on your behalf. There's no way for a site to activate this without your approval or covertly without a full zero-day (probably two since most OSes also have recording indicators now). Contrast this with where we were in the bad old days: sites used things like plugins or Flash/Silverlight which had massive attack surfaces and, for years, inadequate privacy controls or sandboxing. Part of why this is in the browser now is that the browser developers realized that things were never going to get better if they left it to the disinterested developers at companies like Adobe, and now that's just a “can you believe we used to think this was normal?” historical trivia point.
    - JohnFen 4y ago
      The security risk is that advanced functionality is available to all websites. Even if the browser itself is actually a perfect sandbox (and I don't think that's a claim anyone would make), it's still a security problem because a lot of mischief can be done within those parameters, such as tracking, fingerprinting, and other forms of spying. > Contrast this with where we were in the bad old days In the "bad old days", you could decide not to install plugins, choose which ones to install, etc. You could customize the attack surface you're willing to present. That ability is seriously constrained now. Understand that my complaint is about web browsers allowing websites to do these things. In effect, it's allowing any random website to have the power of a natively installed application. This is a bad thing in my view because with native applications, I could decide which ones were and were not acceptable to me. That's extremely difficult now that the browser gives that power to every website.
Turing_Machine 4y ago
That ship sailed about 20 years ago.
mschuetz 4y ago
Because its the securest way we have to launch any app on any device. With binaries, any binary might be malicious and therefore I can only trust and run a very small amount of selected binaries. With web apps, I can launch whatever I want without compromising my system.
- autoexec 4y ago
  > With web apps, I can launch whatever I want without compromising my system. What makes you think web apps can't enable exploits that compromise your system? Anything that can run code on your machine enables attacks. Even Javascript that gets run in browsers have enabled attacks on the local system. If anything web apps decrease your security since a binary can be vetted and verified as unchanged, but when you open a web app you're at the mercy of whatever it is and does in that moment.
  - zarzavat 4y ago
    That may be plausible in some limited cases (iOS) but on most platforms opening an untrusted native app is much more risky than opening an untrusted website. For example, a native app has access to the file system, which is all that is necessary to enable ransomware attacks.
    - autoexec 4y ago
      > For example, a native app has access to the file system web apps also have access to the file system, although there are extra steps https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API https://developer.mozilla.org/en-US/docs/Web/API/File_System... Here's a shell! https://rreverser.com/webassembly-shell-with-a-real-filesystem-access-in-a-browser/ https://rreverser.com/webassembly-shell-with-a-real-filesyst... Webassembly is overwhelmingly used for malware (https://www.crowdstrike.com/blog/ecriminals-increasingly-use-webassembly-to-hide-malware/ https://www.crowdstrike.com/blog/ecriminals-increasingly-use...) but at least it's usually just mining cryptocurrency. I'd guess it's only a matter of time before it's commonly used for much worse.
advisedwang 4y ago
You might as well ask why is HTML able to access files for file form uploads.
0xbadcafebee 4y ago
Path of least resistance. The same reason every single new network service has to be tunneled through a stateless client-server text protocol on a single tcp port. Doing anything less hacky would require more work/money/cooperation. Foundations are expensive, scaffolding is cheap.
golergka 4y ago
Because technologies evolve in surprising ways, and coming up with future-proof names for things is hard, and renaming existing things even harder.
eyelidlessness 4y ago
This is exactly what you’re implicitly asking for: deferring functionality to the OS. It doesn’t give the browser access to your camera (despite the title), it allows the browser to facilitate uploading a file produced by the camera. To the browser it’s no different than any other file input, which was standardized in HTML 3.0. To the OS, it’s not meaningfully different from opening a file picker dialog. To the user, it requires direct interaction to invoke, and while it can be abused it has the same limitations as any other file input, i.e. nothing is uploaded without further affirmative action by the user. This is much better than the JS standards which give sites the power to request interactive access to the camera (after asking permission).

jrockway 4y ago

Because it's the easiest way to distribute software. The alternative to standards is every browser vendor doing their own thing, and "this website only works on IE". Remember the bad old days of the web where every bank required Windows because their UI was implemented with ActiveX? Standards killed that and now you can view your bank account on Linux. WebRTC has its security downsides, but probably better than running a binary from the Chinese government as root so you can video call someone.

unixbane 4y ago
> Because it's the easiest way to distribute software. Not really, webdev is a pain just as much as making a native Windows app or Go binary. Programming is bullshit all the way down. The moment you try to do anything correct in absolutely any modern software stack or framework, you will have to do a bunch of hacks to indirectly force stuff into doing what's needed for your program to be correct. Of course in practice everyone just skips this part, contributing to the said problem. > Standards killed that and now you can view your bank account on Linux. But I literally can't view certain bank websites with Firefox.
- jrockway 4y ago
  > webdev is a pain just as much as making a native Windows app or Go binary I didn't mean to imply it was easier for the programmer. It's harder! But it's easier for the end user. Click link, app loads. Next best thing to being bundled with the OS.

cyral 4y ago

It's not really controlling the camera. You need the JavaScript MediaDevices API for that. It just launches the mobile camera and requests that you take a picture, and the picture of never returned to the site until you confirm it. (Similar to any app that shows the "Take a Picture" or "Choose from Gallery" dialog when uploading an image. That is actually the default if you don't specify that the photo should come from the filesystem or camera) Regarding the web becoming its own OS.. there is no easier way to make cross platform applications these days. If every OS vendor could agree on some standard desktop API, there would be a lot more native apps.

onion2k 4y ago

I find it incredible that people still think HTML, a spec first published in 1990 when we were using 386s with CGA monitors, shouldn't have evolved to utilise some of the modern features available on today's computers and phones. Why wouldn't we want to be able to do useful things on the web with our devices?

JohnFen 4y ago
I'm not arguing that the trend is a bad one, but it does come with downsides that are significant for some. For instance, I certainly don't want every random website I might visit to have access to these abilities. It just strikes me as an unnecessary security risk.
- dymk 4y ago
  It's a shim on top of a file picker dialog. Instead of taking a picture and picking the file from its saved location, it skips a step and lets you directly supply the file from the OS's camera app.
- acdha 4y ago
  What exactly is the security risk? The browser intermediates all access and you already trust the browser to handle many other sensitive operations on your behalf. There's no way for a site to activate this without your approval or covertly without a full zero-day (probably two since most OSes also have recording indicators now). Contrast this with where we were in the bad old days: sites used things like plugins or Flash/Silverlight which had massive attack surfaces and, for years, inadequate privacy controls or sandboxing. Part of why this is in the browser now is that the browser developers realized that things were never going to get better if they left it to the disinterested developers at companies like Adobe, and now that's just a “can you believe we used to think this was normal?” historical trivia point.
  - JohnFen 4y ago
    The security risk is that advanced functionality is available to all websites. Even if the browser itself is actually a perfect sandbox (and I don't think that's a claim anyone would make), it's still a security problem because a lot of mischief can be done within those parameters, such as tracking, fingerprinting, and other forms of spying. > Contrast this with where we were in the bad old days In the "bad old days", you could decide not to install plugins, choose which ones to install, etc. You could customize the attack surface you're willing to present. That ability is seriously constrained now. Understand that my complaint is about web browsers allowing websites to do these things. In effect, it's allowing any random website to have the power of a natively installed application. This is a bad thing in my view because with native applications, I could decide which ones were and were not acceptable to me. That's extremely difficult now that the browser gives that power to every website.

Turing_Machine 4y ago

That ship sailed about 20 years ago.

mschuetz 4y ago

Because its the securest way we have to launch any app on any device. With binaries, any binary might be malicious and therefore I can only trust and run a very small amount of selected binaries. With web apps, I can launch whatever I want without compromising my system.

autoexec 4y ago
> With web apps, I can launch whatever I want without compromising my system. What makes you think web apps can't enable exploits that compromise your system? Anything that can run code on your machine enables attacks. Even Javascript that gets run in browsers have enabled attacks on the local system. If anything web apps decrease your security since a binary can be vetted and verified as unchanged, but when you open a web app you're at the mercy of whatever it is and does in that moment.
- zarzavat 4y ago
  That may be plausible in some limited cases (iOS) but on most platforms opening an untrusted native app is much more risky than opening an untrusted website. For example, a native app has access to the file system, which is all that is necessary to enable ransomware attacks.
  - autoexec 4y ago
    > For example, a native app has access to the file system web apps also have access to the file system, although there are extra steps https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API https://developer.mozilla.org/en-US/docs/Web/API/File_System... Here's a shell! https://rreverser.com/webassembly-shell-with-a-real-filesystem-access-in-a-browser/ https://rreverser.com/webassembly-shell-with-a-real-filesyst... Webassembly is overwhelmingly used for malware (https://www.crowdstrike.com/blog/ecriminals-increasingly-use-webassembly-to-hide-malware/ https://www.crowdstrike.com/blog/ecriminals-increasingly-use...) but at least it's usually just mining cryptocurrency. I'd guess it's only a matter of time before it's commonly used for much worse.

advisedwang 4y ago

You might as well ask why is HTML able to access files for file form uploads.

0xbadcafebee 4y ago

Path of least resistance. The same reason every single new network service has to be tunneled through a stateless client-server text protocol on a single tcp port. Doing anything less hacky would require more work/money/cooperation. Foundations are expensive, scaffolding is cheap.

golergka 4y ago

Because technologies evolve in surprising ways, and coming up with future-proof names for things is hard, and renaming existing things even harder.

eyelidlessness 4y ago

This is exactly what you’re implicitly asking for: deferring functionality to the OS. It doesn’t give the browser access to your camera (despite the title), it allows the browser to facilitate uploading a file produced by the camera. To the browser it’s no different than any other file input, which was standardized in HTML 3.0. To the OS, it’s not meaningfully different from opening a file picker dialog. To the user, it requires direct interaction to invoke, and while it can be abused it has the same limitations as any other file input, i.e. nothing is uploaded without further affirmative action by the user. This is much better than the JS standards which give sites the power to request interactive access to the camera (after asking permission).