[HN Gopher] TIL: You can access a user's camera with just HTML
___________________________________________________________________
TIL: You can access a user's camera with just HTML
Author : feross
Score : 365 points
Date : 2022-09-06 15:31 UTC (7 hours ago)
(HTM) web link (austingil.com)
(TXT) w3m dump (austingil.com)
| superasn wrote:
| Another cool website that I came across a few days ago is
| https://vdo.ninja/ (create reusable invite option) which also
| uses the HTML camera APIs to connect your mobile phone to OBS.
| Both the audio and video quality I get from my phone is at par or
| sometimes even superior to my laptop's webcam. This video
| tutorial(1) explains the setup really well.
|
| Kudos to whoever made this free site and also the modern browser
| tech for making this possible.
|
| (1) https://www.youtube.com/watch?v=ArVDKf2QK1s
| TechSquidTV wrote:
| The one and only Feross randomly gracing our presence :clap:
| encryptluks2 wrote:
| That is pretty cool. Been wanting to create a site with a blurred
| backdrop effect around text, but a camera background to simulate
| an augmented reality style. Wish something like this could work
| on desktop as well though. It is a shame really that more
| features don't get encapsulated into elements recently and
| everything is some JS API that then companies use some bloated
| framework to utilize.
| bastawhiz wrote:
| You can't do what you're describing with just HTML, but it's
| only a handful of lines of js to get a media stream from
| getUserMedia and pipe it into a video element. In fact, it's
| probably more HTML than js.
| bob1029 wrote:
| We've been using this approach for a long time in a B2B setting.
| The fallback to a file picker is really elegant for our use cases
| wherein some users operate on an old-school desktop PC rather
| than a mobile device.
|
| The state of the modern web is pretty incredible now. There
| really isn't any kind of application that I would feel
| uncomfortable building this way in 2022.
|
| For me, native has evolved into pure overhead (unless you need to
| light up some shiny device-specific feature that will inevitably
| become deprecated within 2-3 years). I also understand those who
| believe their product's main selling point is that it exists as
| an offering in the various app stores. For us, we actually have a
| value proposition beyond "it has a native app icon".
|
| If I had to attribute my confidence in the web to any one
| specific aspect, it would have to be CSS grid by a very wide
| margin. Realizing that I could achieve the _exact_ layout I want
| on any range of viewport _without_ having to pull down a 3rd
| party dependency was a huge step for me.
| dakrulski wrote:
| I can't get over the fact, that he is using "a public internet
| URL" to tunnel the traffic to his local server, just to watch it
| on his phone. What he should have done: - Make his local server
| listen on his local ip like <<local-lan-ip>>:3000 instead of just
| 127.0.0.1:3000 - Connect his cellphone to his local lan with
| wifi. - Look at the site on <<local-lan-ip>>:3000 on his
| cellphone.
|
| I would never make a connection from a public Domain to my local
| machine just to test something. It's just too risky.
| jonas-w wrote:
| Same. It's very weird that he did that. It is even more work
| and doesn't bring him any benefit.
|
| I want to know if he had any reason to do so.
| bot41 wrote:
| Maybe he can't connect his phone to the same network the local
| server is on? Maybe he wants to share the URL to people not on
| the same network?
| sunjester wrote:
| "This website has been temporarily rate limited"
| alwillis wrote:
| Same. But it's in Google's cache and I was able to read it from
| there.
| tambourine_man wrote:
| I'm getting a Cloudflare rate limit warning. I didn't know this
| was a thing.
| crtasm wrote:
| It's not just proxying the site, it's using
| https://workers.cloudflare.com/
| mrb wrote:
| Mirror:
| https://web.archive.org/web/20220906155028/https://austingil...
| pmontra wrote:
| > all of those unsupported browsers are actually desktop browsers
| where there isn't a front facing or back facing camera
|
| Any laptop sold in the last 10+ years?
| stakkur wrote:
| Reason #368 why I cover all cameras and disable mics by default,
| and only uncover/enable when in use.
| ezfe wrote:
| cyral wrote:
| You cover your phone camera? This only works on mobile and pops
| up the native Android/iOS camera which requires you to actually
| take the picture (and at least on iOS, asks you to confirm you
| would like to use the photo before going back to the website)
| Silhouette wrote:
| I habitually cover the camera on my phone when I'm not using
| it. It's just common sense for any connected device running
| complicated software without hardware switches to turn the
| sensors off reliably. The latter would be better of course
| but there wasn't a practical option for it last time I was
| looking for a new phone.
| ridgered4 wrote:
| Last time I looked only the pinephone had hardware
| switches, and they were under the case making it kind of
| clunky to turn them on and off.
| Silhouette wrote:
| It's definitely a niche market at the moment. It really
| shouldn't be given the implications of connected devices,
| sensors like cameras and microphones, and where those
| devices get taken by many of their owners. I believe we
| would have a much safer and more resilient society today
| if the norm had become for connected devices to follow
| the principle of least privilege and for there to be
| complete transparency about how any kinds of sensors and
| any kind of remote communication operated. But apparently
| the market has spoken (even though in most cases it was
| only given one "choice" of what to say).
| officialjunk wrote:
| i do, but only the front facing camera though pointing at my
| face.
| stakkur wrote:
| Yep, I do.
| kazinator wrote:
| Currently doesn't work on the desktop: you get a file picker.
| See:
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
|
| If you care about desktop users at all, you can't use this,
| except in a mobile-only version of your site or application.
| murkt wrote:
| I have a webcam for capturing pictures on my "desktop", so
| browser could use that. Not sure if it would be useful
| tialaramex wrote:
| Hmm. I couldn't find an indication of whether this requires
| Secure Context (ie only works with HTTPS or localhost) ?
|
| Secure Context seems (coupled with the permission check) like
| it's an appropriate requirement here but I didn't see whether
| it's actually enforced, and obviously as an HTML attribute rather
| than say a Javascript API it might have been forgotten.
| MrStonedOne wrote:
| Secure context has never applied for form data and i see no
| reason why it would here.
|
| If it's acceptable to send the picture as a file upload over
| http then i see no reason why it wouldn't be acceptable to send
| a webcam captured picture.
|
| Why do you think it should or would?
| advisedwang wrote:
| MDN [1] does not list the Screen Capture API, so presumably the
| capture HTML element is not included either.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/Security/Secure...
| destructionator wrote:
| Actually a pity it doesn't work on the non-mobile; many of my
| computers have webcams now and it is kinda convenient to have
| this (and of course, you ought to always be able to bypass the
| camera as a user. really perhaps it should be part of the file
| picker itself but lol those things are so overloaded already)
| humanistbot wrote:
| Works on my desktop, using Firefox 104.0.1.
| cyral wrote:
| Did you by chance click the JavaScript demo that totetsu
| posted? That demo uses the JavaScript MediaDevices API to
| stream the camera, which is different than the original post
| that is a file picker that opens the camera on mobile.
| totetsu wrote:
| 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 ]
| cyral wrote:
| Note that this uses the JavaScript MediaDevices API to stream
| the camera, which is different from OP's link (which is a file
| picker input that launches the mobile camera instead of going
| to the photo gallery)
| lelandfe wrote:
| However, 'filter: invert(1)' on top of the OP's approach
| should do the same.
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/filter-
| func...
| anamexis wrote:
| OP's approach doesn't display the camera image on-page at
| all.
| djmips wrote:
| Doesn't show my actual camera but a virtual one. So I guess it
| would need an option to select which camera to use.
| j7j7j7j7 wrote:
| It said with just HTML.... that site requires Javascript.
| bpye wrote:
| Do you have a link to any of your photographic work?
| justusthane wrote:
| That is awesome! I don't blame your guests for wanting to play
| with it :)
| [deleted]
| codethief wrote:
| I'm getting a blank screen on Firefox for Android :(
| jonas-w wrote:
| Agreed! Don't see anything.
| Unearned5161 wrote:
| do you perhaps have the phone laying on a table? that's what
| it was for me hahahaha
| OJFord wrote:
| Works for me on the same.
| recursive wrote:
| I'm getting a cert error. Subject is *.fortinet.com, not
| nega.radioac.dev.
|
| Edit, the second: Disregard. It's definitely a corporate
| middlebox on my end.
| totetsu wrote:
| Maybe you're behind a firewall with some filtering, and it
| doesn't like the domain name or something? browsers treat
| '.dev' domains a bit more strictly than the norm, so the
| browser doesn't like the redirect?? that's just my guess
| sorry.
| unknownaccount wrote:
| Can you elaborate on how browsers treat .dev differently?
| its the first im hearing of this and it sounds interesting,
| thx.
| mminer237 wrote:
| The entire TLD is on the HSTS preload list, so .dev
| domains are only accessible via HTTPS. You can't use them
| unencrypted.
| Vendan wrote:
| fortinet is a cyber security software company, that makes a
| product called fortigate that does SSL MITM to decrypt and
| monitor/filter your traffic. Probably want to poke your IT
| team or get very concerned about your ISP...
| [deleted]
| googlryas wrote:
| Hey, get back to work!
|
| - your boss
| rany_ wrote:
| My guess is that some corporate filter blocked it because of
| the "nega" subdomain. Kind of sounds like the racial slur.
|
| Edit: it doesn't help that the domain is `radioac.dev`. So
| *NEGA.R*adioc.dev
| OJFord wrote:
| Wouldn't that be a ridiculously dumb heuristic to employ?
| actually_a_dog wrote:
| Who ever said corporate IT was smart?
| renewiltord wrote:
| Works for me.
| Waterluvian wrote:
| A lot of totally valid opinions out there about this, but I
| personally _love_ how the browser is becoming a very well-
| featured sandbox for shipping applications.
|
| For personal fun and learning, I'm making a complete 2D video
| game in ideally less than 1MB. It has 60fps graphics, full
| spatial audio, and gamepad support, all because the browser has a
| lot of these APIs that didn't exist when I was starting out my
| career. The only issue I'm having so far with the user experience
| is the desire to assume complete control of your keyboard the way
| a traditional PC game would, because browsers really don't want
| you to own _every_ key.
| na85 wrote:
| >A lot of totally valid opinions out there about this, but I
| personally _love_ how the browser is becoming a very well-
| featured sandbox for shipping applications.
|
| Unfortunately what's convenient for you as a developer is more
| often than not hostile and awful UX for me as a user.
|
| Too often, developer convenience trumps good UX.
| secondcoming wrote:
| Why would anyone want, or let, a webpage assume full control of
| their keyboard?
| Waterluvian wrote:
| Me, because I want to see how much I can make a web browser
| video game feel like a native game.
|
| Other than that... I'm not sure even I'd want to allow a
| webpage to do that.
| dekhn wrote:
| ssh terminal
| robotnikman wrote:
| One thing I miss about adobe flash was the software available
| to create flash games and animations. It was relatively easy to
| use and felt like it had a good combination of graphical tools
| and scripting to allow you to create what you wanted
|
| I wish there was something similar for but for modern browsers,
| taking advantage of HTML5 and all the browser API's available
| now which previously required a plugin like adobe flash.
|
| As you mentioned the API's and capabilities are there, built
| right into the browsers now. I just wish the tooling was
| better.
| codetrotter wrote:
| The Adobe Flash authoring software has a successor called
| Adobe Animate. I've only ever exported to MP4 video files
| with Animate, but I know Animate has some HTML5 export
| options. But I don't know how comfortable it would be to use
| for creating graphics and animations for actual JavaScript
| games and/or web applications.
| LAC-Tech wrote:
| _I personally _love_ how the browser is becoming a very well-
| featured sandbox for shipping applications._
|
| For me the big thing holding it back is IndexedDB.
|
| Actually in the process of designing a software solution that
| needs to work on desktop and mobile, and be able to write
| mission critical data while offline.
|
| As much as I'd love to just make one responsive web app - I
| just can't trust the safari or even chrome browsers to not
| /dev/null users data if it feels like it.
| djbusby wrote:
| Are you using A-Frame?
|
| https://aframe.io/
| Waterluvian wrote:
| Wow that's snazzy! But no, I'm using PixiJS because my game
| is 2D.
| coding123 wrote:
| The thing I don't like about the browser becoming that is that
| every web page will now have tons of prompts. Something we were
| trying to kill off with IE years ago because too many people
| just click "accept".
|
| The thing I like about it is what you just said.
| dekhn wrote:
| I used to think the browser could be a sandbox, but its
| evolution to one has been mighty slow- decades to pick up some
| basic features any desktop application developer has been able
| to take advantage of, easily, for decades.
| mkl95 wrote:
| WebGPU feels like a godsend, I hope it gains popularity ASAP.
| Waterluvian wrote:
| Yeah!
|
| Any time I've tried to use WebGL... pain.
| merelysounds wrote:
| > I personally _love_ how the browser is becoming a very well-
| featured sandbox for shipping applications.
|
| Same.
|
| My latest project is a waveform generator for wavetable
| synthesizers [1]; there are visualizations, as well as handling
| audio (not real time but still). I was surprised that I could
| build that as a web app and achieve good UX and performance.
|
| [1]: https://merely.xyz/waves
| gofreddygo wrote:
| I know nothing about this. It looks cool. I want to learn
| more. Where do I start ?
|
| DDG search does not help much [1], [2]
|
| Any pointers ?
|
| 1: https://duckduckgo.com/?q=waveform+generator+for+wavetable
| +s...
|
| 2: https://duckduckgo.com/?q=wavetable+synthesizers&ia=web
| comboy wrote:
| https://learningsynths.ableton.com/
| coupdejarnac wrote:
| I love the Fourier transform animation.
| srcreigh wrote:
| You're down. I want to see your site! When can I see it?
|
| And your domain is really cool too. I presume it's like a
| self deprecating math joke.
| merelysounds wrote:
| I had a typo in url (wrote .xys instead of .xyz, fixed
| now), thanks for letting me know.
|
| The .xyz pun was not intended, but it does make a lot of
| sense for a math related app. Thanks for spotting that too!
| srcreigh wrote:
| Cool! some early feedback:
|
| - Very hard for me to find the play button.. took like
| 10s of looking. I looked at the segment buttons
|
| - Accidentally, I got some really cool sounds by mashing
| the play button to overlay it. Not sure why it gets
| distorted if it should be playing the same waves. But it
| sounds cool
| angrygoat wrote:
| This is very cool, although I was just playing around with it
| and my cat cast me a filthy look and raced away at high
| speed. Your warning about playing the sounds is well given!
| :)
| fsckboy wrote:
| you should talk/reference a bit more about the fourier
| transform aspect https://www.geogebra.org/m/t9uspumz
| lucideer wrote:
| 100%
|
| And also doing this declaratively makes it so much easier to
| secure & build well-thought-out privacy & consent UX around.
|
| An imperative API has so many variations on implementation
| approach for the end-developer / API consumer that the
| combinatorics become much more challenging for browser
| implementers.
|
| (obviously imperative APIs for doing this already exist, but
| the existence of this declarative API at least makes limiting
| imperative API access less draconian/severe as a measure).
| valenterry wrote:
| Yes!
|
| And that's much better than Apps, where you are forced into an
| unfavorable ecosystem.
| z3t4 wrote:
| If you make a manifest file and listen to the install event
| users can add your game to their home screen. Aka. PWA. Then
| you can listen to most keys! Works for chrome on desktop and
| all major mobile browsers. Safari don't have the install event
| and need to be "installed" manually
|
| I have made a web editor that uses this. There is an example
| pwa app Https://webide se/
| croes wrote:
| >because browsers really don't want you to own _every_ key.
|
| Wouldn't be really a sandbox anymore if they could
| osrec wrote:
| Thanks for saying this, as I know a lot of people on HN have
| very negative feelings towards this trend. Personally, I feel
| the browser is a great way to stop reinventing the wheel, and
| the APIs abstract away a lot of the heavy lifting. They pretty
| much get you 80% of the way there, and the last 20% is where
| you can really add the stamp of "uniqueness" to your
| implementation.
|
| The fact that the browser is also heavily sandboxed is another
| big benefit. I personally feel safer using a web app than a
| native app on any device, any day. You just don't know what a
| native app might be doing in the background, but with a web
| app, I feel things are much more transparent.
|
| I can potentially see a future where you could deploy docker-
| like containers directly from the browser, while keeping the
| same fine grained controls that a browser allows. Then it
| really would make the web a truly flexible, infrastructure
| agnostic application delivery platform.
| _Algernon_ wrote:
| The browser is inefficient. Use a modern website on a ten
| year old laptop and it is close to unusable because of modern
| web dev practices. That laptop is still perfectly usable for
| a lot of things.
|
| The modern web drives obsolescence second only to gaming, but
| while gaming is user driven and entertainment focused (i.e.
| not essential), the web is megacorp driven and also includes
| necessary modern infrastructure.
|
| That is all around a bad thing.
| meltedcapacitor wrote:
| "modern web practices" may be more to blame than the
| browser. It's possible to make lean fast things running on
| browsers (within reason), but the culture is nobody gets
| fired for bloat. It's ubiquitous, same for mobile apps,
| server side, etc.
| loudmax wrote:
| There's no desktop standard. Desktop operating systems are
| either proprietary or niche. Any application you write
| needs to be ported again to each operating system
| separately.
|
| The web is the closest thing there is to a ubiquitous
| operating system. And with the development around WASM,
| performance and efficiency is getting closer and closer to
| native. That's along with built-in security and sandboxing.
|
| This is all around a good thing.
| PaulDavisThe1st wrote:
| > Personally, I feel the browser is a great way to stop
| reinventing the wheel
|
| This is an optimistic take on the near- and mid-term
| evolution of software. What makes you think that working
| inside the browser will stop wheel reinvention? Have you not
| tracked the endless reinvention of "the right way" to do
| interactive app development inside the browser?
| bonestamp2 wrote:
| If I understand you comment correctly, WebAssembly is on a
| path to give you that web based container that can be as
| powerful as your computer allows while still being sandboxed
| in the browser.
| psychoslave wrote:
| https://tomassetti.me/wasi-how-to-run-webassembly-code-
| outsi...
| ryandrake wrote:
| It just feels like every time software developers can't (or
| won't) build things cross-platform, users end up with bigger
| and bloatier solutions and poorer experiences.
|
| First, it was cross-platform UI toolkits and OS abstractions
| like Qt (require users to use a big, "lowest common
| denominator compromise" library )
|
| Then, it was web apps (require users to provide a browser)
|
| Then, it was Electron and friends (ship the whole browser
| with the application)
|
| Then, Docker and containers (ship the whole OS with the
| application)
|
| Where do we go from here? Ship an entire physical PC to the
| user pre-loaded with the application? We keep trading away
| the end user's resources and convenience to gain developer's
| time and resources. All to keep (badly) solving the "Well, it
| works on my computer" class of problems.
| account-5 wrote:
| I've being wondering about this myself for a personal
| project.
|
| I don't want to have to code the project in multiple native
| languages, and likely wouldn't be able to without massive
| amounts of time learning each language.
|
| Similarly I want access to native APIs, some of which
| browsers don't have. And I don't want to run a website to
| host my app.
|
| I'm currently learning dart/flutter due to this. IMO it is
| the answer. You may disagree.
| MereInterest wrote:
| > Ship an entire physical PC to the user pre-loaded with
| the application?
|
| I'm going to guess that there will be a few intermediate
| steps, with the additional goal of removing rights to your
| own computer.
|
| After Docker and containers, an image for a virtual
| machine, to provide a kernel and not just the libraries.
|
| After virtual machines, a connection to a remote machine,
| to avoid downloading the entire image and reduce your
| first-use bandwidth.
|
| After connections to remote machines, a "co-located
| server", with an abstraction layer between using the remote
| machine to reduce first-use bandwidth and using the machine
| in your house to reduce latency.
|
| Which is all to say that I wouldn't be surprised if it
| happened that way over the next 10-20 years, resulting in
| you renting the computer that sits in your own house.
| madelyn wrote:
| > Ship an entire physical PC to the user pre-loaded with
| the application?
|
| A phone (hi iOS), a video game console, a smart appliance,
| etc. are examples of this.
|
| Building cross platform, native applications is expensive
| (comparatively) to building web applications.
|
| I made an FM synthesizer in the browser using WASM and the
| webaudio api just for personal use. I wouldn't have made it
| if I had to write it as a native app, because native apps
| are a time sink and annoyance to me (I mean, I'm on linux
| anyways. I probably have to use either GTK or QT
| anyways!!!)
|
| Demand for software is MASSIVE right now, and making
| shipping easier, even if the end product isn't as fast,
| does have value.
|
| Though yeah, I wish Slack was faster too.
| MaxBarraclough wrote:
| > A phone (hi iOS), a video game console, a smart
| appliance, etc. are examples of this.
|
| Related to this: iirc, games for the Xbox One (and
| presumable the latest generation 'Series' consoles)
| always run in a VM, with their own kernel and graphics
| drivers.
| water8 wrote:
| Could be for backwards/intergenerational compatibility
| because and hardware is no longer standardized for a
| console generation
| choeger wrote:
| You're absolutely correct. IMO, the reason is, to a large
| degree, ineptness of software engineers. It simply doesn't
| _pay_ to hire or train high-quality SEs, if you 're not
| google or Amazon (and even they probably only hire and pay
| the best to prevent competition).
|
| Instead, the industry as a whole hands out more
| "productive" tools, i.e., the abstraction layers you
| mentioned, in order to build ever more trivial applications
| (that don't work properly in most of the cases anyways).
|
| I think that we're in a downwards spiral at this point:
| Business doesn't make enough money per line of code to hire
| or train really good engineers. Tries to push out more
| software, resulting in more crap. Software quality sinks.
| Business makes even less money per line of code. Engineers
| throw the towel and are replaced by less experienced
| people. Rinse and repeat.
| gumby wrote:
| I agree with what you wrote 99% but draw a different
| conclusion.
|
| The 1% where I don't agree: most developers aren't
| engineers. These days companies hire engineers for stuff
| that is hard and important. But most do not need that.
|
| And my impression is that that is a good thing. There's
| been a real democratization of development which means
| there's a lot of software being written. Most
| applications I see are fundamentally CRUD apps, and while
| I'm a bit fearful of the security of the banking apps,
| the massive frameworks are at least designed (implicitly
| at least) to reduce complexity and steer people towards
| some "best practices". Any kid today can build something
| that only a couple of decades ago (or less) really did
| need serious engineering.
|
| We've followed the same path before. Rich people used to
| hire chauffeurs who didn't just drive but performed
| maintenance on the cars. Then people knew how to change
| tyres, gap their spark plugs etc. Now people know how to
| turn the key and steer around the road, hopefully not
| killing too many people in the process. Next, they'll
| only need to know how to step into the vehicle.
|
| We should be glad software is going that way. It's not
| like that will reduce employment for engineers.
| rektide wrote:
| I see so much growth & positivity, so much can-do-ism.
| Everyone's doing great things, but in particular the web
| has brought about a much higher access to systems that
| seem much safer for users, much more sandboxed, with
| better
| tools/extensions/navigability/accessibility/hackability,
| that have much more open source activity going on than
| native (which has been to huge benefit in so many ways:
| to productivity, to learning, to exploring, to having
| fun, to creating social cultures & groups).
|
| > _I think that we 're in a downwards spiral at this
| point_
|
| I'm mainly writing a reply just to say: I have huge hope
| we're on an great upward ascent & have made things
| increasingly better.
|
| > _IMO, the reason is, to a large degree, ineptness of
| software engineers._
|
| I sometimes encounter less than optimal code or
| solutions, but the amount of times that it matters is
| unbelievably little. Focusing on really good engineers
| making really excellent decisions is, not, to me, a
| critical issue in most places. I think there's a lot of
| value in just finding the budget to support open source
| engineers, in trying to support good community efforts,
| like Web Incubation specs, like Bytecode Alliance. Time &
| care, about doing good things for community, over time,
| is the incomparable advantage, is the prime requirement
| of turning acceptable/passable/maybe-a-little-defect-y
| code into something that really works well & serves &
| is/has-become enduring.
|
| > _Instead, the industry as a whole hands out more
| "productive" tools, i.e., the abstraction layers you
| mentioned,_
|
| I see so little harm to using the good, well embraced,
| ultra productive, mid-industrial toolset we've grown
| into. And I see so little benefit to trying to go any
| other way. We should respect resource consumption, and
| some apps (webapp and native both) do bad jobs, but the
| layers mentioned seem like a vanish point of concern, far
| far far down where I think computing needs to be dwelling
| & caring & trying to do better. There's so few examples
| that there are real gains to be made from abandoning the
| layers we have; efforts like react-native show we can do
| basically the same high-production technioques at a
| native layer, but the rewards for doing it native have
| almost never materialized; just using the web stack
| continues to be good.
|
| I think there are far more productive things to be
| debating & discussing, as we decide where to orient
| ourselves & the next steps of computing to. Worrying
| about these stacks has infected too much of the online
| discourse time spent, has become a mind-virus.
| jcynix wrote:
| > You're absolutely correct. IMO, the reason is, to a
| large degree, ineptness of software engineers.
|
| Hmm, software engineers? IMO the culprits are "greedy"
| managers who didn't like (and still don't like) common
| libraries, file systems etc. Motto: "It must be my
| standard, or else ..." Where's the common (license free
| and secure, encryptable) standardised file system, to
| exchange data between all platforms, including digital
| cameras and other gadgets? Where's the graphics API? Java
| tried to answer some of these questions, but failed
| miserably IMHO.
|
| My experience: as soon as I learned to use some API or
| framework, at least two new APIs or frameworks showed up
| posing as the best thing since sliced bread. Sorry for
| the sarcasm, but I lost my optimism regarding software
| development some years ago.
| ravenstine wrote:
| > Then, Docker and containers (ship the whole OS with the
| application)
|
| To be fair, that's shipping the _kernel_ and needed
| packages with the application. That's pedantic, I know,
| and while what you said is _technically_ true, removing
| one level of abstraction from the description really
| changes the meaning significantly. The Linux kernel on its
| own is something like 10 megabytes.
|
| EDIT: What I've said is not exactly correct. If you're not
| running Docker on a Linux host, then you'll have a Linux
| kernel running in emulation but it's not shipping with
| containers. Not sure what I was thinking. I believe this is
| closer to the truth.
| easrng wrote:
| I thought docker used the host kernel with a different
| rootfs?
| ravenstine wrote:
| Apologies... I've been thinking in Docker For Mac Land.
| Yes, I think what you're saying is correct if you're
| running Docker on a Linux host.
| cpuguy83 wrote:
| Containers don't ship a kernel, just the userspace.
| [deleted]
| rafram wrote:
| > Ship an entire physical PC to the user pre-loaded with
| the application?
|
| Maybe not _that_ , but it's becoming popular to run high-
| intensity programs on a remote server and stream video to
| the user's machine, both for pretty sensible reasons (e.g.
| Stadia for games) and totally nonsensical ones (e.g. Mighty
| for Google Chrome). It's mainframes all over again!
| rektide wrote:
| Operating systems like WebOS, KaiOS/Firefox OS, ChromeOS
| largely do away with many layers of the stack, by making
| the web technology front & center. I do think you're right
| that perhaps some layers could go, but I think native apps
| & much of the native OS itself are far closer to the
| LaserDisc technology[1] that we can get rid of.
|
| Reciprocally, on the server, there's definitely traction
| strong traction with webassembly being the de-facto
| platform for glue/extensions/user-code, owing to it's super
| sandboxing & capability systems like WASI. Being able to
| take any langauge, compile to wasm, and distribute & safely
| run that module has been a huge upgrade, and a very nice
| bit of platform that historically wasn't really
| available/commonplace on "native".
|
| Your issue with "Electron and friends" is wrong. As you
| say, Electron does at present bundle a whole browser in
| each app. But many "friends" have new approaches. Tauri
| recently went 1.0, and generally builds off the already
| available WebView that all major OSes include[2]. I'd be
| interested to see what kind of fear/concern you'd present
| if Electron also had a more respectful shared-library
| usage-pattern.
|
| [1] "Writing an App is Like Coding for Laserdisc"
| https://shkspr.mobi/blog/2022/09/writing-an-app-is-like-
| codi... https://news.ycombinator.com/item?id=32723192 (153
| points, 1d ago, 184 comments)
|
| [2] "Tauri [1.0] - Electron alternative written in rust"
| https://news.ycombinator.com/item?id=29807022 (558 points,
| 8mo ago, 419comments)
| MR4D wrote:
| > Ship an entire physical PC to the user pre-loaded with
| the application?
|
| Ironically, that's essentially what IBM did with
| mainframes.
|
| Another example of what's old is new again.
| arghwhat wrote:
| 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 .ost
| usecases, mainframes do have some really cool tech,
| including their new CPU designs with quite interesting
| cache layouts.
| MR4D wrote:
| 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
| rented everything from IBM, and paid one lease price.
| amelius wrote:
| The problem with HTML is that it is not a layered
| technology. It's all or nothing.
|
| And sadly it will get more complicated over time.
|
| I just figured that at some point we should start over with
| a very simple sandbox that allows to run all the webgl
| renderers, javascript interpreters, css parsers, and
| whatnot, _inside_ it. This simple sandbox would also be
| more secure, because of its simplicity.
| noduerme wrote:
| >> Ship an entire physical PC to the user pre-loaded with
| the application?
|
| Believe it or not, I've done this, and I have to maintain a
| small fleet of them now. The software in question functions
| as a server/database for a mobile app that's only used by
| employees on a given job site. It was deployed before
| Docker was a thing.
| rgersten wrote:
| Any chance you're blogging about the process? I'd love to
| follow along, as I dream of doing the same thing one day.
| Waterluvian wrote:
| I really really should. I want to un-abandon my home page and
| maybe start writing about it there. FWIW the code is here:
| https://github.com/ablakey/kestrel
| johnfn wrote:
| We're certainly veering off-topic, but I'd love to hear about
| which game engine you ended up using!
| Waterluvian wrote:
| Because the entire point is to learn and not actually to ship
| a product, I wrote my own. The biggest libraries I use that I
| didn't write are HowlerJS for audio, PixiJS for graphics, and
| React for UI. The actual "game engine" is a very primitive
| one I wrote myself. You can see it here:
| https://github.com/ablakey/kestrel/blob/master/src/Engine.ts
|
| One of the best things about NIH-ing my own engine is that I
| don't need to make it generic, meaning one less layer of
| abstraction to complicate implementation and debugging.
| cyral wrote:
| And theres a LOT more APIs than people realize:
| https://developer.mozilla.org/en-US/docs/Web/API
|
| Some interesting ones:
|
| - Screen recording/capture
|
| - Battery status
|
| - Barcode Detection
|
| - Bluetooth
|
| - Sensors (e.g. Accelerometer)
|
| - Wake/screen lock
|
| - Color picker
|
| - Vibration
|
| - MIDI
|
| - USB
|
| - Contacts picker
|
| - Presentation (AirPlay, Chromecast)
|
| - Virtual reality
| easrng wrote:
| A lot of those are Chrome-only.
| shusaku wrote:
| Any former geocities member us surely aware of the MIDI
| capability!
| andyhedges wrote:
| Couldn't you play a WAV too? But they were too massive at
| the time for most peoples bandwidth.
| mattl wrote:
| <bgsound>
| monocasa wrote:
| Not just playing MIDI files, but interfacing with MIDI
| controllers (including ones that weren't designed to be
| accessible over the web leading to RCE).
| whywhywhywhy wrote:
| USB/Bluetooth is underrated because it means you can ship
| hardware products that can have their firmware updated or
| connect and sync with a web service without having to
| build/ship/maintain a whole app for it that will eventually
| stop working after an OS update.
| spaghettiToy wrote:
| Is Bluetooth good yet?
|
| I had issues as recent as last year's new products.
|
| But otherwise I love the concept of hardware access with
| HTML. The embedded guy in me thinks the future is going to
| be crazy. I can't quite wrap my head around the
| possibilities.
| autoexec wrote:
| My guess is that hardware access with HTML will mostly
| bring about remote exploits and massive privacy problems.
| I disable all of it.
|
| I also keep Bluetooth disabled on my mobile devices. It's
| used extensively to ID and track people and their
| devices. For things that don't move and are only ever
| paired to a single thing (like a speaker) it works fine.
| Most of the complaints I hear about bluetooth are from
| people who pair multiple devices to a single source and
| want to easily switch between them.
| david12345 wrote:
| Hell, you can even root an android phone via the browser!
| https://protonaosp.org/install/web
| lucideer wrote:
| These are all Javascript APIs. I think what's particularly
| notable about the OP is that it's HTML.
| spaghettiToy wrote:
| I'm here for the JS comments.
|
| I'm amazed at how quickly I can throw together a front end
| feature in JavaScript on my otherwise html site.
|
| Really all of web impressed me over the desktop/app
| counterparts. I wrote and read to/from a php database with
| less than 2 hours of time. Laravel has me doing user
| authentication + useful coding in less than 40 hours after
| the tutorial.
| cyral wrote:
| Yes but the person I'm replying to is talking about JS APIs
| naillo wrote:
| Old enough to remember when the accelerometer didn't require
| permission to access.
| dheera wrote:
| Yeah you could use the vibration API and accelerometer API
| as a very low bitrate TX/RX system for devices on the same
| table and close enough.
|
| No permissions required.
| chrisweekly wrote:
| I vaguely recall there being some early-days
| accelerometer-based webapps that absolutely destroyed
| batteries, because the high-resolution accelerometer
| checks required responsible throttling / debouncing. So
| gating it behind permissions makes some sense to me.
| codethief wrote:
| Me too but I'm glad it does now and I don't have fear (web)
| apps that exploit the accelerometer as microphone.
| adrr wrote:
| It was useful an API to detect if a client was faking their
| user agent or was a bot. When I worked for a neo bank we
| abuse all the APIs to detect if client was a real person or
| not without having to use captchas.
| megous wrote:
| Most of these are not available in chrome or firefox.
| tinus_hn wrote:
| Unfortunately many of these leak identifying datapoints so
| due to abuse they are now blocked.
| amalcon wrote:
| I recognize that this kind of thing is useful to the developer,
| of course, and we've gotten a lot of neat things this way.
|
| My worry is basically that the absent functionality is the best
| thing about the web as a user. Take the notification API: One
| of the nice things about web pages and apps is that they stop
| bothering me once I close them; not so if I accidentally permit
| notifications! Fortunately I can turn that whole feature off,
| but at first I found myself wondering who ever thought that
| would be a good idea.
|
| Yes I picked an extreme example, and I don't actually mind some
| of these things. I wish there were a permission pop-up before
| playing sound at all. Also, WebGL does concern me, since heavy
| GPU usage can draw a lot of power. Things like gamepad support
| and spatial audio (if they are behind permission pop-ups) don't
| really bother me, though.
| johnfn wrote:
| I don't know, this seems like a good compromise to me. Some
| apps (calendar) would be absolutely crippled without them.
| For everything else, I've just never turned them on in the
| first place.
|
| > I wish there were a permission pop-up before playing sound
| at all
|
| The browser can't actually play sound unless 1) it's
| triggered as the result of a user action (such as a mouse
| click) or 2) if you've often listened to sound on that page
| in the past.
| amalcon wrote:
| My answer to this is that the calendar just does not need
| to be a web app. Weakening a primary advantage of
| everything else on the web just so that my calendar can be
| a web app seems like a poor trade-off.
|
| Re: sound, "Triggered as the result of a user action" is
| _not_ a high enough bar.
| shadowgovt wrote:
| Calendars are far more useful as web apps than other
| incarnations; you can open them anywhere and don't have
| to carry a specific artifact with you to do it.
| dijit wrote:
| a web _view_ for caldav is just fine (and how I use
| outlook currently); but for _notifications_ a proper
| program is definitely preferable.
| nathants wrote:
| the flashing/buzzing/squawking device in your pocket does
| this quite well.
| lcnPylGDnU4H9OF wrote:
| > the calendar just does not need to be a web app
|
| And the chat app, and the email app, and the social media
| app (other opinions about social media notwithstanding).
| I think each of these things have their own legitimate
| use for notifications.
|
| I guess it's the point of "weakening a primary
| advantage". I don't see how it's weakened (or rather, I
| don't see how it's a problem) when the notifications are
| on a per site permission. Especially so when the
| notifications can be turned off completely per browser.
|
| > Re: sound, "Triggered as the result of a user action"
| is not a high enough bar.
|
| I'm with you on this. Although it took until this thread
| for me to realize that sound _at all_ should be a
| permission.
| notatoad wrote:
| this seems like a pretty silly criticism - you have a feature
| that is both gated behind a per-site permission prompt and
| that has an option to globally turn it off, and you're still
| grumpy that it exists?
|
| if you don't like it turn it off. arguing that things
| shouldn't exist just because you choose not to use them is
| pretty selfish.
| amalcon wrote:
| I mean... it does exist now, and I don't advocate taking it
| out since people have probably come to rely on it for some
| reason. Defaults matter, though, and I suspect[0] that a
| minority want this default.
|
| [0]- With only anecdotes supporting my suspicion; I haven't
| done a rigorous study.
| lupire wrote:
| It seems silly to ask for a release to be crippled just
| because a _page_ does something obnoxious inside its own
| space. The solution to that is a URL allowlist or
| blocklist.
| dahfizz wrote:
| I love the idea of a good cross platform sandbox to ship apps.
| I think it's really unfortunate that we chose a web browser to
| be that application platform.
|
| The underlying technology is terrible. HTML and CSS are for
| displaying documents. Things which should be trivial to add to
| an application UI (add a ListView, anchor element X to be left
| of element Y, etc) are nigh impossible without using some
| bloated toolkit anyway. JS is a slow and brittle language to
| work with.
|
| The fact that the web became an application delivery platform
| is an unfortunate historical accident that I am not sure we can
| recover from.
|
| If we devoted 10% of the engineering that went into "web
| technology" into an actual dedicated cross platform application
| platform, it would be way better than the web is today. Faster,
| less bloat, better technology so that we don't need frameworks
| on frameworks to do a hello world, etc.
| lmkg wrote:
| There is a possible future where HTML and JavaScript are
| relegated to historical shims for WASM and <canvas>. I don't
| know if this is a _good_ future or not, but you want a future
| with cross-platform apps freed from "web technologies"
| that's probably the one that's most achievable from the state
| of things today.
| elina123 wrote:
| 1023bytes wrote:
| Demo is on MDN https://developer.mozilla.org/en-
| US/docs/Web/HTML/Attributes...
| paulirish wrote:
| A more minimal demo: https://simpl.info/mediacapture/
| (Everything remains local)
|
| AFAIK, this feature is mobile only.
| doliveira wrote:
| In this topic, I wish more tools like databases, Big Data
| services, etc used WebSocket-based protocols. It would unlock so
| many cool applications straight within the browser.
| elina123 wrote:
| rektide wrote:
| Great seeing coherent cool capabiliites mase so east, taking &
| growing thr input element like this.
|
| It does make me more than a bit sad how the web is bifurcating
| between mobile & desktop. We keep justifying it to ourselves,
| saying, yeah, that's not as important on desktop, and nit
| implementing. This pile of discrepancies built by non-
| implementations keeps growing though & it's not cool. Web Share &
| Web Share Target not being on desktop is another mobile only
| example, of more tech that's just good for PWA's in
| general/everywhere.
| hughes wrote:
| I feel like the default file input behavior is more user-
| friendly. Giving the user a choice between taking a new photo or
| uploading an existing one just seems way more flexible, and this
| is already how the file input works without the `capture`
| attribute.
| spicybright wrote:
| Same. Phones have really good default native UIs for these
| "old" style input forms.
| sam1r wrote:
| Anyone else denied access to the page due to rate limiting??
|
| >> Check back later once traffic has gone down.
| EastSmith wrote:
| So not only Cloudflare does not serve the website, it also
| serve another site with links to Cloudflare.
| taftster wrote:
| Yup. This happens sometimes when a site is linked from the HN
| home page.
| dtparr wrote:
| Yeah, looks like it's been slashdotted. (Or whatever the
| appropriate verbing of an aggregation site is in 2022).
| matbatt38 wrote:
| I think its "hugged to death" nowdays
| acejam wrote:
| "This website has been temporarily rate limited"
|
| TIL you shouldn't run a blog on Cloudflare Workers due to rate
| limiting.
| judge2020 wrote:
| This only applies to the free plan[0] - Higher plans work for
| excessive RPS, but of course it'll balloon your bill with
| millions of requests.
|
| Given this is a blog, a better solution would've been
| Cloudflare Pages[1], which is their own static site hosting
| service and provides unlimited requests/bandwidth for free.
|
| 0: https://developers.cloudflare.com/workers/platform/pricing/
|
| 1: https://pages.cloudflare.com/#pricing
| l1am0 wrote:
| Would be good to replace the screenshot in the article with a
| live updating can i use widget: https://caniusewidgets.com/html-
| media-capture
| hn92726819 wrote:
| This doesn't work at all without JavaScript. I much prefer the
| picture to a blank region.
|
| Slightly tangent, but it seems like more services are no longer
| offering fallbacks. Twitter recently got rid of its tweet text
| fallback, and the caniusewidgets doesn't offer a png fallback
| (at first glance). https://github.com/badges/shields uses svg
| so you can do this without complaining about bandwidth too.
|
| Would be funny to include this in an article about yet another
| privacy-breaking feature of web.
| j7j7j7j7 wrote:
| Linda703 wrote:
| buro9 wrote:
| Archive link:
| https://web.archive.org/web/20220902181141/https://austingil...
| 0xbadcafebee wrote:
| There are several websites that offer both screen capture and
| camera video/audio capture, and thus recording, purely through
| HTML5. It's pretty slick.
| polyrand wrote:
| HTML media capture is superb. I have successfully used it in
| production, and I was surprised by how simple it was and how well
| it worked. I learned about it from here[0].
|
| It's cool because if you have an app that requires users
| uploading pictures, you just need an HTML <form>, an <input> with
| `capture`, and a few lines of code in the backend. I thought I
| would need to do some JavaScript gymnastics, and it ended up
| taking just an afternoon to design, develop, and deploy.
|
| [0]: https://anssiko.github.io/html-media-capture/
| mxfh wrote:
| This and the _Web Speech API_ were quite unexpected things to
| discover lately. Even quite robust browser support, besides
| speech recognition missing on Firefox.
|
| Didn't expect to have that easy access to TTS/Speech Synthesis.
|
| https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_...
|
| https://www.google.com/intl/de/chrome/demos/speech.html
| mmastrac wrote:
| I suspect we're still waiting on Firefox's multi-language
| speech database in Common Voice to get processed into some
| useful offline learning models. We can't be that far away from
| a googleless speech input world.
| hardnose wrote:
| 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?
| advisedwang wrote:
| You might as well ask why is HTML able to access files for file
| form uploads.
| 0xbadcafebee wrote:
| 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.
| jrockway wrote:
| 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.
| golergka wrote:
| Because technologies evolve in surprising ways, and coming up
| with future-proof names for things is hard, and renaming
| existing things even harder.
| eyelidlessness wrote:
| 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).
| cyral wrote:
| 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 wrote:
| 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?
| grumbel wrote:
| 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 wrote:
| _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_Bluetoo...
| grumbel wrote:
| > 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.
| onion2k wrote:
| Those are all flaws in browsers, not HTML. In the case of
| bookmarks that's not even a part of HTML.
|
| There's nothing stopping browser vendors solving the
| problems you're talking about but then you'll probably
| worry that browsers are becoming operating systems or
| something.
| acdha wrote:
| > 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 the ranges of thousands of pages
| will be at least as snappy as a PDF.
|
| > You can't bookmark a scroll position either and neither
| can you link it.
|
| 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.
| JohnFen wrote:
| 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.
| acdha wrote:
| 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 wrote:
| 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 wrote:
| > 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
|
| 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.
| dymk wrote:
| 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.
| Turing_Machine wrote:
| That ship sailed about 20 years ago.
| mschuetz wrote:
| 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 wrote:
| > 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.
| zikduruqe wrote:
| https://critter.camera
| uneoneuno wrote:
| Have you used this before? This looks great - much lower
| overhead than what I was doing with a Pi, USB camera, and
| motionpi
| zikduruqe wrote:
| I have, but limited usage. Just for monitoring the dogs when
| I'd run to the store or something. I've had it bookmarked for
| years in the event one day I needed it for something.
| spicybright wrote:
| What an awesome idea! Was thinking of doing raspi craziness for
| capturing birds out my window.
|
| Why do that when you can duct tape an old phone to the window
| lol
| _tom_ wrote:
| There are apps for turning old phones into dashcams and
| security cams, too.
|
| Why waste an old phone?
| Starmina wrote:
| Not the same but for a more _pro_ approach and allowing to
| stream to a RTSP Server I use LARIX Broadcaster, which is
| both available on android and iOS and it 's just superb to
| turn an old phone into a camera, ofc you'd need an other
| software to actually detect movement and such from the RTSP
| feed. Scrypted can do that (for example)
| zikduruqe wrote:
| A friend of mine swears by https://zoneminder.com
___________________________________________________________________
(page generated 2022-09-06 23:00 UTC)