6 ms·

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 s

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.
    - acdha 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. No, it can't. It's an HTML attribute which enables some mobile browser UI around the standard <input type=file> behaviour. The only thing it allows for tracking is whether your browser supports that attribute, which narrows it down to about 60% of the browsers in the world: https://caniuse.com/html-media-capture https://caniuse.com/html-media-capture The only way you're breaking that is if you have the kind of exploit which could break just about anything and in that case the argument would be more along the lines of “we should remove JavaScript entirely” since that's been a source of orders of magnitude more security problems. > 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. Your choice was to enable a massive operating system-scale level of functionality in Flash/Silverlight or not be able to use many popular sites. Since those plugins were managed separately from the browser they did not follow the same secure development practices or sandboxing which the browsers were using, and many users either did not update them or did so on a schedule far slower than the update schedule Chrome or Firefox kept. > In effect, it's allowing any random website to have the power of a natively installed application. … with complete user control. That's exactly what you say you want in the next sentence and it's far better from a security perspective because trusting a browser's sandbox is a lot easier to evaluate than having to individually review every native application you install. Installing native applications should be seen as a relatively rare activity because they expose you to more risk and are harder to evaluate.
grumbel 4y ago
There is nothing wrong with HTML evolving, the problem is that it has evolved in the completely wrong direction. HTML should be a document language, yet it has barely improved in that in the last 20 years and is still missing really basic features (e.g. long-form document support). Instead it can talk to my Bluetooth devices and my camera. Something went very wrong in the evolution of HTML. It's nice that we have a portable app platform now, but I really wish that would be a separate thing from the document centric Web, which slowly but surely is getting killed and replaced by a bunch of always-online apps.
- onion2k 4y ago
  HTML should be a document language, yet it has barely improved in that in the last 20 years and is still missing really basic features (e.g. long-form document support). I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML. Instead it can talk to my Bluetooth devices and my camera. Something went very wrong in the evolution of HTML. That's not HTML though. That's not even really browsers and JavaScript. It's just Google and Chrome, and even then it's mainly there so it's available in ChromeOS more than the Chrome-the-browser. They just happen to share the same 'engine'. A random webpage is not hax0ring your bluetooth devices. They're very tightly coupled, so sometimes it's hard to see where one stops and the other begins, but Web Bluetooth has nothing to do with HTML. You only need look at the compatibility chart to see that - https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...
  - grumbel 4y ago
    > I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML. If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward. You can't bookmark a scroll position either and neither can you link it. If you split the document into multiple HTML files, you complete break the ability to search across the whole document. Performance also breaks down with long form documents. There is of course .epub, which fixes some of those short comings, but epub is not part of the Web, not supported by any browser and requires a separate app. So it really doesn't fix the fundamental problems either. There is also 'link rel=next/prev' that in theory would allow working around some of those issues as well, but that hasn't been supported in any browser as far as I know. If HTML would be any good at handling documents we wouldn't still be using PDF all the time.
unixbane 4y ago
>Why wouldn't we want to be able to [run interactive apps] web with our devices? Because the web is for hypertext, which means static content. Images, text, video and audio clips, tables, code snippets, etc. Of course even that subset it does unimaginably bad, okay? Interactive web apps fucking suck, so that takes care of that 50%. For the other 50%, which is document viewing, why in the hell would I want pages to be able to move stuff around and create their own custom UIs and color schemes for every document I view? That use case is for magazines, a content-free medium. It's actually hilarious how people think hosting their library documentation on some stupid website like readthedocs.io, or publishing scientific journals behind IP blocklists (aka misconfigured bullshit from some charlatan sysadmin) is "progress".
- onion2k 4y ago
  Because the web is for hypertext, which means static content. Thats what hypertext meant originally but it's evolved and moved on. The spec is literally called "HTML The Living Standard". You don't get to claim it's fixed and can't change. It just isn't.
  - hardnose 4y ago
    The distinction is between growth and creep. Growth is when your spec matures to serve the original purpose even better than it used to. Creep is when your spec decides to achieve other, new purposes. HTML has been a victim of ridiculous amounts of creep, to the detriment of growth. Creating static web content isn't really easier or cleaner now than it was in the 90s, but the protocol DOES now permit the remote end to interrogate your computer for almost as much info as the freakin' SysInternals suite.

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.
  - acdha 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. No, it can't. It's an HTML attribute which enables some mobile browser UI around the standard <input type=file> behaviour. The only thing it allows for tracking is whether your browser supports that attribute, which narrows it down to about 60% of the browsers in the world: https://caniuse.com/html-media-capture https://caniuse.com/html-media-capture The only way you're breaking that is if you have the kind of exploit which could break just about anything and in that case the argument would be more along the lines of “we should remove JavaScript entirely” since that's been a source of orders of magnitude more security problems. > 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. Your choice was to enable a massive operating system-scale level of functionality in Flash/Silverlight or not be able to use many popular sites. Since those plugins were managed separately from the browser they did not follow the same secure development practices or sandboxing which the browsers were using, and many users either did not update them or did so on a schedule far slower than the update schedule Chrome or Firefox kept. > In effect, it's allowing any random website to have the power of a natively installed application. … with complete user control. That's exactly what you say you want in the next sentence and it's far better from a security perspective because trusting a browser's sandbox is a lot easier to evaluate than having to individually review every native application you install. Installing native applications should be seen as a relatively rare activity because they expose you to more risk and are harder to evaluate.

grumbel 4y ago

There is nothing wrong with HTML evolving, the problem is that it has evolved in the completely wrong direction. HTML should be a document language, yet it has barely improved in that in the last 20 years and is still missing really basic features (e.g. long-form document support). Instead it can talk to my Bluetooth devices and my camera. Something went very wrong in the evolution of HTML. It's nice that we have a portable app platform now, but I really wish that would be a separate thing from the document centric Web, which slowly but surely is getting killed and replaced by a bunch of always-online apps.

onion2k 4y ago
HTML should be a document language, yet it has barely improved in that in the last 20 years and is still missing really basic features (e.g. long-form document support). I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML. Instead it can talk to my Bluetooth devices and my camera. Something went very wrong in the evolution of HTML. That's not HTML though. That's not even really browsers and JavaScript. It's just Google and Chrome, and even then it's mainly there so it's available in ChromeOS more than the Chrome-the-browser. They just happen to share the same 'engine'. A random webpage is not hax0ring your bluetooth devices. They're very tightly coupled, so sometimes it's hard to see where one stops and the other begins, but Web Bluetooth has nothing to do with HTML. You only need look at the compatibility chart to see that - https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...
- grumbel 4y ago
  > I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML. If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward. You can't bookmark a scroll position either and neither can you link it. If you split the document into multiple HTML files, you complete break the ability to search across the whole document. Performance also breaks down with long form documents. There is of course .epub, which fixes some of those short comings, but epub is not part of the Web, not supported by any browser and requires a separate app. So it really doesn't fix the fundamental problems either. There is also 'link rel=next/prev' that in theory would allow working around some of those issues as well, but that hasn't been supported in any browser as far as I know. If HTML would be any good at handling documents we wouldn't still be using PDF all the time.

unixbane 4y ago

>Why wouldn't we want to be able to [run interactive apps] web with our devices? Because the web is for hypertext, which means static content. Images, text, video and audio clips, tables, code snippets, etc. Of course even that subset it does unimaginably bad, okay? Interactive web apps fucking suck, so that takes care of that 50%. For the other 50%, which is document viewing, why in the hell would I want pages to be able to move stuff around and create their own custom UIs and color schemes for every document I view? That use case is for magazines, a content-free medium. It's actually hilarious how people think hosting their library documentation on some stupid website like readthedocs.io, or publishing scientific journals behind IP blocklists (aka misconfigured bullshit from some charlatan sysadmin) is "progress".

onion2k 4y ago
Because the web is for hypertext, which means static content. Thats what hypertext meant originally but it's evolved and moved on. The spec is literally called "HTML The Living Standard". You don't get to claim it's fixed and can't change. It just isn't.
- hardnose 4y ago
  The distinction is between growth and creep. Growth is when your spec matures to serve the original purpose even better than it used to. Creep is when your spec decides to achieve other, new purposes. HTML has been a victim of ridiculous amounts of creep, to the detriment of growth. Creating static web content isn't really easier or cleaner now than it was in the 90s, but the protocol DOES now permit the remote end to interrogate your computer for almost as much info as the freakin' SysInternals suite.