Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TIL: You can access a user’s camera with just HTML

austingil.com

Post reply on HN
Print view View original

231–240 of 240 posts

Re: TIL: You can access a user’s camera with just HTML

#231

Post by acdha »

account42 wrote: post #225
acdha wrote: post #162

Earlier quoted context omitted.

> If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward. This isn't true on any popular browser or platform. Single-page scrolling using the keyboard, mouse, or touchscreen is built-in for all common browsers and scrolling even extremely large documents has been fine for at least a decade – unless you load it up with tons of JavaScript even in…

> You can't, and also wouldn't want to since that's inherently unstable (e.g. I resize the window slightly and all of the links break). What you can do is what people have been doing since around 1993 and put anchors on logical sections, paragraphs, etc. so you have a linkable stable anchor which doesn't depend on the window or font size. Except there is no way to expose such anchors to the user without cluttering up…

> > You can't, and also wouldn't want to since that's inherently unstable (e.g. I resize the window slightly and all of the links break). What you can do is what people have been doing since around 1993 and put anchors on logical sections, paragraphs, etc. so you have a linkable stable anchor which doesn't depend on the window or font size.

> Except there is no way to expose such anchors to the user without cluttering up the display.

1. Using unobtrusive anchors isn't that bad as far as clutter goes — if you have a discrete octothorpe or paragraph symbol consistently at the start or end of a paragraph it's not the end of the world, especially if they're styled to be in the margin outside of normal text flow.

2. Since approximately late 1995, people have used JavaScript to only display those symbols on hover/focus. This works well and is pretty common around the web.

I'm not saying that there isn't room for improvement such as Chrome's extension but when there's 3 decades of common usage for something you say can't be done it suggests that the probably isn't that it's impossible but that there isn't enough social pressure to make publishers _want_ to publish books as HTML. Examples of massive documents are easy enough to find (e.g. W3C specs) so I'd prefer to spend time thinking about why other people aren't (e.g. DRM) and what you can do about the real problems.

Re: TIL: You can access a user’s camera with just HTML

#232

Post by distances »

codethief wrote: post #119
totetsu wrote: post #9

This is a site that shows the camera feed full screen and inverts in with css https://nega.radioac.dev/ I hacked it together in half an hour to give people a way to look at the uninverted version of my inverted analogue photos with their phones at exhibitions. most people were more excited to play with it on their phone than by the photos I took days making. :'( [edit oops this javascript ]

I'm getting a blank screen on Firefox for Android :(

I also had a blank screen. I found that I had denied camera permission for Firefox at some point. Keeping it that way

Re: TIL: You can access a user’s camera with just HTML

#233

Post by claytongulick »

moring wrote: post #226
account42 wrote: post #224

Earlier quoted context omitted.

Oh please, "loads of crash bugs" are not and were never inevitable. And for the user experience, an exception that prevents you from doing what you want is not even that much better than a hard crash. And let's not pretent that users are ever given a choice in the quality vs. cost tradeoff except for looking for a different program entirely. And even that is often not an option because the software needs to interact…

> We shouldn't excuse mediocre software just because the market puts up with mediocrity. The market has stopped putting up with mediocre software and chose higher-quality alternatives. The one thing that is not obvious to developers is that the market considers faster software with less features, hard crashes and limited portability as much worse than the web-based alternatives.

The market also likes software that ships faster.

With html + js, we're able to deliver a great user experience in a fraction of the time.

Also, the desktop bundlers are getting better over time.

Re: TIL: You can access a user’s camera with just HTML

#234

Post by JohnFen »

acdha wrote: post #191
JohnFen wrote: post #178

Earlier quoted context omitted.

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"…

> 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…

> No, it can't. It's an HTML attribute which enables some mobile browser UI around the standard behaviour.

I wasn't talking about this particular ability. I was talking about the risk of browsers being effectively operating systems in their own right. That puts me in an untenable position -- I have to determine the safety of every web site, which is a thing that is effectively impossible to do.

> with complete user control.

Not even close. I have to install and use several addons in order to muster a somewhat reasonable amount of control. And even then, the control I have is far from "complete".

> 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.

It's certainly easier to "trust the sandbox", except that the sandbox allows far too much nefarious activity in order to be able to trust it.

Modern web browsers are inherently problematic because of the combination of presenting powerful abilities to websites, and that it's impossible to know if a website is using those abilities responsibly (and most -- especially large commercial websites -- aren't, as near as I can tell).

Re: TIL: You can access a user’s camera with just HTML

#235

Post by acdha »

JohnFen wrote: post #234
acdha wrote: post #191

Earlier quoted context omitted.

> 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…

> No, it can't. It's an HTML attribute which enables some mobile browser UI around the standard behaviour. I wasn't talking about this particular ability. I was talking about the risk of browsers being effectively operating systems in their own right. That puts me in an untenable position -- I have to determine the safety of every web site, which is a thing that is effectively impossible to do. > with complete user c…

> > with complete user control.

> Not even close. I have to install and use several addons in order to muster a somewhat reasonable amount of control. And even then, the control I have is far from "complete".

You have per-site authorization for each different feature, and those can be one-time, ongoing, one prompt per day, etc. Now, yes, I'm sure you can come up with some policy like “I want to only allow camera access when I'm holding down the left meta key” but it's important to remember that the alternative is people downloading and running native code. Do you really think that's going to be _better_ than a modern browser?

> Modern web browsers are inherently problematic because of the combination of presenting powerful abilities to websites, and that it's impossible to know if a website is using those abilities responsibly (and most -- especially large commercial websites -- aren't, as near as I can tell).

The browsers fully disclose when something is being used. You can't tell what they do with the data but that would be the case in any alternative model and I trust the browser UI a lot more than a prompt which that company implemented in their own app.

Re: TIL: You can access a user’s camera with just HTML

#236

Post by hardnose »

onion2k wrote: post #213
unixbane wrote: post #207

Earlier quoted context omitted.

>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…

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.

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.

Re: TIL: You can access a user’s camera with just HTML

#238

Post by dataangel »

moring wrote: post #226
account42 wrote: post #224

Earlier quoted context omitted.

Oh please, "loads of crash bugs" are not and were never inevitable. And for the user experience, an exception that prevents you from doing what you want is not even that much better than a hard crash. And let's not pretent that users are ever given a choice in the quality vs. cost tradeoff except for looking for a different program entirely. And even that is often not an option because the software needs to interact…

> We shouldn't excuse mediocre software just because the market puts up with mediocrity. The market has stopped putting up with mediocre software and chose higher-quality alternatives. The one thing that is not obvious to developers is that the market considers faster software with less features, hard crashes and limited portability as much worse than the web-based alternatives.

I think this is the wrong take away. The market made a few specific decisions:

1) Users don't want to deal with installation.

2) New developers are attracted towards the least steep difficulty incline -- learn HTML first, then some CSS, then some JS. At each stage you can do something visible and useful, and the next step is within your grasp.

3) Most investment goes towards companies adding value to the web, and companies that do that will tend to use web technologies first.

I think crashes have very little do with it. In my experience web apps have just as many stability problems and broken features. Also important that #2 means that developers that can work on systems where web solutions can't work (things that really need C++ because of realtime requirements) are paid a substantial premium. So the market has also decided the people who can do native well are more valuable.

Re: TIL: You can access a user’s camera with just HTML

#239

Post by moring »

dataangel wrote: post #238
moring wrote: post #226

Earlier quoted context omitted.

> We shouldn't excuse mediocre software just because the market puts up with mediocrity. The market has stopped putting up with mediocre software and chose higher-quality alternatives. The one thing that is not obvious to developers is that the market considers faster software with less features, hard crashes and limited portability as much worse than the web-based alternatives.

I think this is the wrong take away. The market made a few specific decisions: 1) Users don't want to deal with installation. 2) New developers are attracted towards the least steep difficulty incline -- learn HTML first, then some CSS, then some JS. At each stage you can do something visible and useful, and the next step is within your grasp. 3) Most investment goes towards companies adding value to the web, and com…

> 1) Users don't want to deal with installation.

That is definitely one of the top selling points for web-based solutions, agreed.

> 2) ... At each stage you can do something visible and useful

BTW is this still true in 2022? My totally out-of-nothing guess would be that SAAS offerings and website builders have made people with HTML + minimal JS knowledge next to useless.

> 3) Most investment goes towards companies adding value to the web, and companies that do that will tend to use web technologies first.

OTOH, I have been involved in a project where the web was found to be superior to the alternatives. It does have to do a lot with (no) installation, though. A related project, OTOH, is moving their UI from Swing to the Browser. While this is just the UI, the remaining code was written in Java, not native.

I think I do agree with the claims as long as Java/C#/similar get added to the "native" side of the argument, because I really see them eating C/C++'s lunch, and this is only going to accelerate with Java becoming more and more independent of a separate JVM installation.

> Also important that #2 means that developers that can work on systems where web solutions can't work (things that really need C++ because of realtime requirements) are paid a substantial premium

I haven't found this to be true, but my experience is limited, and it probably depends on country / region.

Re: TIL: You can access a user’s camera with just HTML

#240

Post by arghwhat »

MR4D wrote: post #138
arghwhat wrote: post #130

Earlier quoted context omitted.

Eh? Mainframes are and always were general purpose computers, and run stufd like Linux just fine. Nowadays they are mainly meant as machines with extreme reliability guarantees, from things like running multiple processors in lockstep to detect spontaneous processor errors, but they're still just computers. While their cost makes them hugely impractical for .øst usecases, mainframes do have some really cool tech, inc…

I never commented on the specificity, rather I pointed out this quote "Ship an entire physical PC to the user pre-loaded with the application." Replace "PC" with "Mainframe" and the sentence was true (at least back when mainframes were a thing. The software came pre-loaded with the hardware, and IBM shipped it to you and set it up for you. You couldn't buy an app without paying for the hardware. Technically, you rent…

That sounds more like a case of "you're buying an app for our mainframes, so you'll need something to run it on".
Post reply on HN