[HN Gopher] Should the Web Expose Hardware Capabilities?
___________________________________________________________________
Should the Web Expose Hardware Capabilities?
Author : cpeterso
Score : 42 points
Date : 2021-01-06 15:40 UTC (7 hours ago)
(HTM) web link (www.smashingmagazine.com)
(TXT) w3m dump (www.smashingmagazine.com)
| alkonaut wrote:
| Browsers should have an entropy budget of just a tiny number of
| bits. It's not ok to know my screen resolution, it's not ok to
| render fonts and read back the pixels. Exposing more hardware
| capabilities would be used a thousand times for fingerprinting
| for every time it's used for a legitimate purpose (just like the
| canvas pixel readout).
| backing wrote:
| You're so right it is messed up !
|
| Some services even refuse to serve if one changes the UA, which
| is only one tracking capability. Though a blank or custom UA is
| worse, everyone should spoof the one in the onion browser.
|
| User agent switch is currently "not available" on android
| Firefox.
| pjmlp wrote:
| With the tiny percentage of Firefox market share, and iDevices
| worldwide market share, the Web is effectively a synonym for
| ChromeOS, regardless of how Apple and Mozilla might think about
| it.
| munhitsu wrote:
| Just No
| nexuist wrote:
| I don't see why web apps should be handicapped compared to their
| native versions. If it was as easy to download, install, and run
| native apps, we would be having the same exact conversations in
| regards to security and portability. In fact, we already are
| having these conversations in regards to sideloading on iOS and
| Android devices, and it seems like HN agrees that sideloading
| should be supported by the OS vendor. The user should be allowed
| to do what they want with their purchased hardware. There should
| be no walled garden dictated by a few multi-billion dollar
| corporations.
|
| So how come this gets twisted on its head when it comes to web
| apps? The user should be allowed to do what they want, right? So
| why shouldn't I be allowed to use web apps that interact with
| bluetooth or USB devices? Why should your philosophical arguments
| on which software on what platform is allowed to do get in the
| way of my very real productivity and desire to use my computer
| the way I want to? Why should I _have_ to use native apps if I
| don't want to? As a web developer, why do I need to learn Qt or
| GTK or whatever to ship something useful to end users, when I
| already know HTML and JS and could easily deliver my product if
| the right native API was exposed?
|
| And for all the arguments about performance: I never see anyone
| complaining about un-optimized native apps even though we have
| all used them before. Remember splash screens? Random freezes?
| Running out of RAM because some random app in the background
| decided to malloc 80GB for some godforsaken reason? How is that a
| better experience than a web app running in a sandboxed tab you
| could easily kill whenever you want?
| phkahler wrote:
| >> I don't see why web apps should be handicapped compared to
| their native versions.
|
| For starters, native apps have too many permissions already.
|
| Second, if you run a native app it should require explicit
| permission for internet access (perhaps at install time) so you
| have some idea if local data is going somewhere. Web apps are
| implicitly assumed to have internet access.
|
| This should be fairly obvious, and the notion of granting more
| local access to arbitrary outsiders should be distressing. The
| fact that google and web sites feel entitled to everything on
| and about you computer says a lot about them. If they were
| humans with that lack of boundaries and sense that what's yours
| is theirs, we'd label then narcissists or psychopaths (not sure
| which).
| wieghant wrote:
| Yet we are as of right now where even our OS will go behind
| our back and act like malware to collect data even when we
| explicitly say no.
|
| The native apps are also all trending to online first and
| cache offline.
|
| I don't understand how a native app going behind your back
| and asking only for internet connection permission (and not
| hardware) is viewed as more secure. Why do we trust these
| native apps more?
|
| Arbitrary psychopathic outsiders have already been here for
| quite a while. Even if you're running super paranoid homebrew
| linux distro.
| Arnavion wrote:
| Indeed, OSes already have privilege access mechanisms like
| GPO on Windows and SELinux / AppArmor / Flatpak on Linux to
| restrict installed binaries.
|
| Then all that goes out the window when the 100 MiB gorilla
| named /usr/bin/browser wants access to everything anyway,
| connects all that privileged information to other people's
| computers, and then implements its own entirely separate
| privilege access mechanisms in userspace to make that secure.
| 13415 wrote:
| I agree that it doesn't need to be about security. If web apps
| had to be installed on browsers similar to the way they are
| installed on the operating system, they would be acceptable.
| The current system that they run automatically when you visit a
| web page is obviously unacceptable, but that could be changed.
| The lack of standards and GUI features is also not that bad.
|
| For me it's more about pricing and freedom. Server and
| computing costs force most web apps to be subscription-based
| and I'm extremely picky about subscriptions. First, there is
| often data lock in, of course, and it's often very deliberate
| with no viable export options. That's unacceptable to any
| reasonable person both on desktops and with web-based apps.
| Second, subscription-based applications are universally too
| expensive. If I turned all desktop software I currently use
| into equivalent subscriptions my monthly bill would be insanely
| high, an additional 200 to 500 euro per month. To most people
| including me that's just not affordable. It just doesn't add
| up. There is no market where people buy 20 different apps at
| $15/month each.
|
| Almost everyone uses free desktop apps and a few paid ones.
| backing wrote:
| > I agree that it doesn't need to be about security
|
| This.
|
| You're litterally using a personal computer with at least
| personal data on it, passwords in a password manager,
| passwords in your browsers, website account sessions (!) all
| on your drives and folders. Everything accessible by ALL
| programs you execute.
|
| The more info Javascript has and therefore the server, the
| more attack vectors open up to just inject code into your
| browser and leverage code execution on host (recent CVE on
| firefox and Chrome !).
|
| Or into your slack electron's chrome. Or any spyware app.
|
| All your keystrokes accessible also !
|
| Consider using a virtual machine or container to isolate the
| apps from your data so that they can't access it. If needed,
| mount a folder between host and guest for purpose-only
| sharing.
|
| Or at least think about it or other measures.
| michaelt wrote:
| _> So how come this gets twisted on its head when it comes to
| web apps?_
|
| It's the Windows 95 security model:
|
| Some things I trust, and I'm happy giving nigh-unlimited power,
| so I run them natively.
|
| Other things I _don 't_ trust, and I want them in a sandbox
| where they can't mess things up. That sandbox is the browser,
| and having it be very secure is a high priority for me.
|
| Poking more and more holes in the sandbox, together with a
| philosophical belief that the inside of the sandbox should be
| no more restrictive than the outside of the sandbox, is not
| compatible with that philosophy.
| Technically wrote:
| > If it was as easy to download, install, and run native apps,
| we would be having the same exact conversations in regards to
| security and portability.
|
| Mobile platforms have invested in restricting apps by ability.
| There's no such way to exert this control over web apps with
| current browsers.
|
| For instance, how to you stop a page from snooping your
| keystrokes? At best you can disable javascript entirely.
|
| The browser really, really, really needs to adopt the sandbox
| model used by the rest of the operating system for this to make
| _any_ sense, and right now the browser is more of a gaping hole
| in your wall than a sandbox.
|
| > The user should be allowed to do what they want, right?
|
| You'd need to do a hell of a lot of footwork to actually enable
| users to make decent decisions about random code found on the
| internet. I don't trust anyone technical I know to do this,
| much less people who don't understand what's going on.
| Jonnax wrote:
| The problem is that the web browser runs every URL that a user
| visits and whatever that page links to. This means that it's a
| privacy risk.
|
| Look at this site which looks at the fingerprintable bits of
| data that is available from a web browser:
| https://amiunique.org/fp
|
| The web browser leaks a lot of specific information about the
| user. Which can then be combined with other information to
| uniquely track a user on the internet.
|
| Why does the web browser need to make available the list of all
| fonts on a user's machine? Installing any combination of extra
| fonts makes you significantly more unique.
|
| Same with GPU model.
|
| The article talks about WebUSB. And how it was used to phish
| people's Yubikeys:
|
| https://www.wired.com/story/chrome-yubikey-phishing-webusb/
|
| The user isn't consenting to that.
| mrec wrote:
| > _Why does the web browser need to make available the list
| of all fonts on a user 's machine?_
|
| In many cases I think the question is more "what
| functionality would the web browser need to break to
| __prevent __pages detecting X, and is that worth it? ".
|
| I remember doing this kind of detection years ago for an
| (entirely benign) chart authoring webapp; you don't want to
| offer a font for client-side rendering if the client doesn't
| have it. You can generally assume that the `monospace` and
| `serif` fallbacks are different, so if you have one layout
| box with text in `font-family:FontToDetect,monospace` and
| another with the same text but `font-
| family:FontToDetect,serif` and they both come out the same
| width, it's good odds that the user has that font. [EDIT:
| originally got that backwards due to brainfart]
|
| Nowadays the existence of `@font-face` makes that particular
| problem mostly obsolete, but the same general principle
| applies all over.
| SahAssar wrote:
| > The user isn't consenting to that.
|
| AFAIK webUSB was always behind a consent dialog. That attack
| was based on getting consent, and the authors seems to say so
| at a talk about it (or a similar attack):
| https://www.youtube.com/watch?v=pUa6nWWTO4o
|
| It's still very bad, but not nearly as bad as you say it is.
| MaxBarraclough wrote:
| > So how come this gets twisted on its head when it comes to
| web apps? The user should be allowed to do what they want,
| right?
|
| The web needs to be secure against untrusted code, so it makes
| sense that there might be things you can do in a native
| application that you can't do in the browser.
|
| > Why should I _have_ to use native apps if I don't want to?
|
| It's not an affront on your freedoms to impose sensible
| restrictions on browsers' capabilities.
|
| > As a web developer, why do I need to learn Qt or GTK or
| whatever to ship something useful to end users, when I already
| know HTML and JS and could easily deliver my product if the
| right native API was exposed?
|
| If you want to use your web-dev skills to build native
| applications, there are various frameworks that let you do
| exactly that. You can call C/C++ functions from Electron. [0]
| Of course, you also have the option of learning and using C++
| for your own GUI code, with frameworks like Qt.
|
| > Remember splash screens? Random freezes? Running out of RAM
| because some random app in the background decided to malloc
| 80GB for some godforsaken reason? How is that a better
| experience than a web app running in a sandboxed tab you could
| easily kill whenever you want?
|
| This is a straw-man. The people you are caricaturing are just
| people who want technically excellent software. This includes
| (but is not limited to) the efficient use of computational
| resources. No-one is pining for the instability of Windows 98.
|
| [0] https://stackoverflow.com/a/39569062/
| alkonaut wrote:
| I think the danger lies mostly in apps that both access my data
| and hardware _and_ the web. For local apps accessing hardware
| or data, I can often control whether it sends that data
| elsewhere.
|
| A web app almost by definition uses the network, so if I give
| it access to my camera or my file system then it's very hard to
| know exactly if or where that data is sent.
|
| This isn't perfect for native either, the dialog to accept
| network usage is basically a blanket grant to connect anywhere
| or send anything.
| wieghant wrote:
| Exactly. But for the savy it's easier to see from network tab
| in dev tools where your data is sent.
|
| No such luck with native apps. I don't almost never use
| wireshark to figure out what my native apps are doing.
|
| Also. The entire argument falls apart when you factor in the
| ability to proxy data. E.g google.com -> bit-shady-site.com
| -> for-sure-shady-site.com
| benjaminjosephw wrote:
| The mad arms race for browser functionality smells a lot like an
| Embrace and Extend strategy by the big players. If browsers
| implementations are impossibly complex for anyone other than
| large companies to implement then the concept of "open standards"
| doesn't mean what it used to.
|
| I'm looking forward to the inevitable renaissance of the Open Web
| which respects the fact that the internet is for end-users[0].
| I'm sure there's a million cool things a web page _could_ do but
| that doesn't mean that's what users want. The web needs more end-
| user participation, not more functionality. An end-user focused
| web would focus on security and simplicity over novelty. I'm not
| sure where this all went so terribly wrong but I'm convinced that
| it won't always be like this. Disruptive change is something our
| industry is very good at.
|
| [0] - https://tools.ietf.org/html/rfc8890
| emteycz wrote:
| Are you sure your view aligns with the rest of users? I know
| many people who are happy that the browser has became a very
| capable app platform - both end users and app vendors. Now the
| end users are asking for more functionality - I see it daily in
| my line of work - and that needs new browser features.
| jaywalk wrote:
| Are you seriously implying that browser functionalities are
| currently simple enough for entities smaller than "large
| companies" to implement?
| benjaminjosephw wrote:
| No. The opposite. I'm trying to say that open standards
| aren't really open if they can't be broadly implemented.
| jaywalk wrote:
| So in order for you to consider a standard "open" it has to
| be simple? We aren't allowed to have open standards above a
| certain level of complexity?
| timw4mail wrote:
| Breadth of current standards is more of an issue, I would
| argue. As the number of browser standards has increased,
| the number of browser engines (and platforms capable of
| running those browser engines) has decreased, and the
| computing power needed for web browsing has increased.
| spankalee wrote:
| I was looking at some niche MIDI hardware recently and it had a
| link to a configuration app - which was just a web page on their
| site that used WebUSB.
|
| That's exactly what I want out of web apps - no install, secure,
| cross platform, immediately useful, and importantly - accessible
| to the providers.
|
| The configuration page is Chrome only for now, which sucks, but
| hopefully Apple and Mozilla will come around.
| c22 wrote:
| I was playing with some ancient hardware pretty recently that
| got configured via serial port. The configuration program was
| included on a cd-rom (one of those weird miniature ones). I had
| to find a USB-serial adapter as well as an external USB cd-rom
| drive in order to make it all work. I also had to install
| Windows XP into a virtual machine.
|
| No idea if a simple web page using WebUSB would have worked
| better for me, the original manufacturer seems to have folded
| up over 10 years ago and their website no longer resolves.
| sfink wrote:
| Sure, the WebUSB feature set is nice. Care to address any of
| the points made in the article?
|
| There's a reason why security and features are in constant
| tension; it doesn't really work to just ignore security when it
| happens to be features that you want.
|
| You'd better hope that your niche hardware isn't reprogrammable
| via USB to become an ethernet device that snoops all of your
| network traffic and injects attacks. It's pretty safe to assume
| that there is no such attack now. But if it ever happens at any
| point in the future, then either you'll get hacked, or your
| device will be blocked and the configuration app will stop
| working.
| [deleted]
| austincheney wrote:
| I read the article and the hesitation to expose various details
| through the web, what the article describes as the conservative
| approach, is absolutely valid. The biggest problem with exposing
| anything to the current web is complete exposure to anonymous
| strangers (loss of privacy) and all the security implications
| that come with that.
|
| It doesn't have to be that way. The crux of the web is HTTP,
| which exposes a pseudo-anonymous session-less client-server
| model. I am working on an application that inverts HTTP to a non-
| anonymous session-oriented server-client model exposing a GUI in
| the browser.
|
| The goal isn't privacy, but exposing new capabilities that only
| make sense in a private environment. There are numerous things
| people are willing to do on their desktop that would be absurd to
| do over the web. For example: there is no reason cross-platform
| file transfer should be challenging. Simply expose a slice of the
| file system to the net on a computer you own to somebody you
| trust and they can get what ever files they need at their
| convenience and discretion, like copy/paste from one folder to
| another folder except those folders are on different computers.
| The way the web currently works this isn't practical. The closest
| thing is a shared storage space in the cloud, like DropBox.
|
| Other potential capabilities include remote application access,
| remote hardware access, built-in media sharing (think non-
| proprietary video conferences/presentations), and synchronizing
| things between your various personal devices.
| Animats wrote:
| No way. Most of the web is to some extent hostile. Already it
| wants to know too much about you. Usually, though, it can't do
| that much to you.
| Technically wrote:
| As long as I can surround it with a prophylactic, I don't see the
| issue.
| rektide wrote:
| Very much in favor of standards like the one the article focuses
| on, WebUSB. Author links Suz Hinton's excellent talk, which goes
| through a bunch of projects & background & culminates with an
| Arduino programmer on the web[1]. Sue talks about this as a much
| friendlier interface than a lot of her other work, with the
| already excellent avrgrl programming project[2].
|
| in contrast, the author presents Mozilla's view,
|
| > "Because many USB devices are not designed to handle
| potentially-malicious interactions over the USB protocols and
| because those devices can have significant effects on the
| computer they're connected to, we believe that the security risks
| of exposing USB devices to the Web are too broad to risk exposing
| users to them or to explain properly to end users to obtain
| meaningful informed consent."
|
| while i do not disagree with the risks, i for one think this
| clawing for absolute security, this idea that the web must only
| allow a narrow enough path that nothing ever goes wrong, is
| death. there is indeed great cause for Fear Uncertainty and Doubt
| (FUD)[3], but we have to do it anyways.
|
| and frankly, most usb devices are pretty boring & isolated. yes
| you can hurt a usb flash drive if you do the wrong things to it,
| you can install an autorun.inf nasty malware. yes you can play
| gross sounds or listen on a usb sound card. but few devices are
| going to do anything to the system. mostly it's a bunch of mice &
| keyboards.
|
| there's such amazing tension between those who want to secure &
| lock things down, & those who still have hope, who see the web as
| one of the few remaining ways to keep doors open, to leave
| something neutral & available & capable about for humanity to
| use, without endless gatekeeping rigamarole. nothing comes close
| to the web for being able to get your idea out there, the web is
| the epitome of online, and in spite of much danger & scariness,
| it seems obvious- my soul yearns to amplify & enhance & empower
| ourselves more with this amazing, unique, utterly special system.
|
| [1] https://www.youtube.com/watch?v=IpfZ8Nj3uiE#t=20m
|
| [2] https://github.com/noopkat/avrgirl
|
| [3] https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt
| sfink wrote:
| The Web has certain properties that it relies on for its
| existence. This isn't "clawing for absolute security", it's
| recognition that if you push the Web just a _little_ too far,
| it 's dead. As in, it's not the Web anymore, will gradually
| become useless for many existing purposes, and will have to be
| replaced by something else borne out of its ashes.
|
| "The Web but without worrying quite as much about its
| security/privacy characteristics" is simply not the Web. Same
| as "the Web but without stressing so much about backwards
| compatibility". It would be a great thing, perhaps, but it's
| something different and would evolve very differently. (In
| particular, it would lack some of the core reasons why the Web
| has competed successfully with native apps.)
| cesarb wrote:
| > and frankly, most usb devices are pretty boring & isolated.
| yes you can hurt a usb flash drive if you do the wrong things
| to it, you can install an autorun.inf nasty malware. yes you
| can play gross sounds or listen on a usb sound card. but few
| devices are going to do anything to the system. mostly it's a
| bunch of mice & keyboards.
|
| With Thunderbolt/USB4, a USB device is not only a USB device;
| it's also a PCIe device. Upgrading its firmware (USB is
| commonly used for firmware update, but it could also be done
| through exploits on non-firmare-update endpoints) means the
| attacker now has control of not only a USB device, but also a
| PCIe device.
| corty wrote:
| And control of a PCIe device (with the usual lazy broken
| drivers that just ignore IOMMU) means full read and write
| access to all physical memory adresses, including OS kernel,
| firmware and NMI RAM areas and all applications. This gives
| an attacker the capability to compromise the hardware in very
| permanent ways. Nothing to take lightly or brush off as
| security absolutism.
| kube-system wrote:
| Browsers already expose _way_ too much about hardware. We shouldn
| 't be trying to shove privileged APIs into a web browser for the
| rest of the world to exploit -- at a very minimum we need
| abstraction layers that completely isolate web apps from the
| hardware they run on. We should make hardware work with a browser
| rather than making it work with the web.
| devwastaken wrote:
| They do, but you don't need exposure of information by default.
| All of those features should be explicit opt in when prompted,
| same as phone apps.
|
| But browsers won't remove that data exposure by default because
| advertising data and captcha systems. Torbrowser gets it right.
| mtgx wrote:
| Yeah, tell that to Google who pushed for default access for
| WebUSB and Web Bluetooth.
|
| Reminder why it's bad to have a surveillance company have so
| much control over the web through its products.
| kube-system wrote:
| I don't think being opt-in is a solution to the problem. Most
| people will click anything if it lets them read the page
| they're trying to view, and nefarious actors will take
| advantage of this. We'll just end up with an internet that
| doesn't work unless you opt-in.
|
| I think the solution is: if you can't add the functionality
| in a way that doesn't expose information about the user's
| system, don't add it.
| kitsunesoba wrote:
| One possibility might be to report to all sites that
| permission has been granted, but only actually grant
| permission once the user has specifically chosen to do so.
| sfink wrote:
| Yeah, opt-in is an attractive nuisance when deciding things
| like this. It's a good way to argue that something should
| be allowed because you did your due diligence and warned
| the user, but in practice it provides very poor security
| (for the reason you give). At the end of the day, no amount
| of purism and theory can ever outweigh the actual effects.
| devwastaken wrote:
| At that point don't have a computer. Don't have software.
| Native applications do significantly more hardware
| identification. It's not opt in and you're not told what's
| collected and for what purpose. People install applications
| all the time they don't know what they're doing.
|
| You're not going to get browsers behind the idea of burning
| the ground they walk on. Many of the features that end up
| used for tracking are things people very much like having.
| Threading, webgl, webrtc, etc.
|
| No doubt some sites will create barrages of opt in
| notifications - don't use these sites. Walmart, facebook,
| amazon, etc, are not going to make you complete opt in for
| everything to proceed. Even if they do - you know it exists
| and can spoof that data with your browser if you want.
| kube-system wrote:
| That's a defeatist comparison. We treat native
| applications differently than web browsers because it is
| useful to assume a default level of trust when we browse
| the internet. This applies not only to users, but to
| institutions, OEMs, system integrators, etc.
|
| > You're not going to get browsers behind the idea of
| burning the ground they walk on.
|
| Maybe not Google, but Mozilla and Apple seem to consider
| privacy before they implement new potential holes into
| their browsers.
|
| > Many of the features that end up used for tracking are
| things people very much like having. Threading, webgl,
| webrtc, etc.
|
| The cat is already out of the bag with these already-
| implemented features. My point is that we 1) shouldn't
| make it worse, and 2) should work to replace these with
| better options. Users don't care whether their chat app
| uses webrtc or not -- they just want their application to
| work. The bad technologies we use don't _have_ to be the
| way they are. Once upon a time the internet relied on
| ActiveX controls, Java Applets, and Flash, but we 've all
| since moved past those bad technologies as well.
|
| > No doubt some sites will create barrages of opt in
| notifications - don't use these sites.
|
| Honestly, this is not a solution. We shouldn't ignore
| momentum, because when designing global standards, the
| problem is more than just about _you or me_ , it's about
| the architecture and expectations that are being created.
| To use my ActiveX example above -- in some places, for a
| period of time, it was impossible to do online banking
| without using IE because every bank used ActiveX
| controls.
| devwastaken wrote:
| "The bad technologies we use don't have to be the way
| they are" They're not bad technologies, and you can't
| just 'replace them' and fix the problem. How do you
| replace P2P and not have IP exposure or a tech that's
| exactly the same by a different name? That's physically
| impossible.
|
| How do you replace webgl without identifying information
| on shader support and GPU model? You don't, that
| information is given by shader compilation itself.
|
| These technologies are nowhere the same as activex, flash
| or java. All of those technologies were not built to be
| safe. They were built to give functionality browsers
| lacked. Now we have far safer methods of doing this
| thanks to better features.
|
| Users want their stuff to work, for that to happen you
| have to have the features necessary for it. Those
| features are why you can listen to spotify or join voice
| calls on a browser instead of installing everyones native
| application which has access to everything.
|
| If you don't want a browser capable of that then use a
| fork of torbrowser or similar. We will not change
| anything by trying to reverse the market without actual
| proof of harm. Instead we can advocate for opt ins to the
| information these features have given by default.
| kube-system wrote:
| > How do you replace P2P and not have IP exposure or a
| tech that's exactly the same by a different name? That's
| physically impossible.
|
| Who said we need to "replace P2P"? WebRTC's security
| issues are not predicated on it being a P2P technology.
|
| > How do you replace webgl without identifying
| information on shader support and GPU model?
|
| There are _already_ ways to draw things in browsers that
| don 't require this information to be leaked. The simple
| answer to your question is "abstraction".
|
| > These technologies are nowhere the same as activex,
| flash or java. All of those technologies were not built
| to be safe. They were built to give functionality
| browsers lacked.
|
| This statement will, one day be just as true about webRTC
| and webGL as it is today regarding ActiveX, Java, and
| Flash.
|
| While I don't have a time machine, I do have full
| confidence that new technologies will be created that
| solve today's problems.
|
| > Users want their stuff to work, for that to happen you
| have to have the features necessary for it.
|
| Before Javascript and Canvas this is literally why
| ActiveX, Java, and Flash were used. But since we have
| those better alternatives now, we use them instead.
| some_random wrote:
| No absolutely not, we don't need more ways for advertisers to
| destroy people's privacy.
|
| Solve that problem and maybe.
| vbezhenar wrote:
| I would trade my privacy for better functionality and/or
| performance any day.
| some_random wrote:
| Ok, but would you make that trade for not just yourself but
| everyone? Including those who are threatened by physical
| harm?
| vbezhenar wrote:
| That should be an option for everyone to decide.
|
| Just an example. Right now if two websites want to use http
| s://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.mi...
| they'll download it twice because of "privacy". That's
| nonsense and I'd turn off that misfeature if I could.
| johnklos wrote:
| No.
| ArtWomb wrote:
| We're already there with WebAssembly SIMD & WebGPU. I don't know
| how to interpret it any other way than "exposing hardware" to the
| browser interface. And I have ANR'd my own machine required hard
| reboot. What I think could become standard is a modal pop up
| warning. In the same manner that WebRTC media streams requires
| explicit permission to access a users web camera. Herein lies
| dragons, abandon all hope and enter at your peril.
| corty wrote:
| No.
| bzb6 wrote:
| Without clicking: no
| rektide wrote:
| I sense great fear within you.
|
| "Fear is the path to the dark side. Fear leads to anger. Anger
| leads to hate. Hate leads to suffering."
|
| Yes, these capabilities bring will inevitably bring about some
| down-side, some negatives. But they are 100000% worth it.
| Endless cool things will spring from this that would be
| impossible any other way.
|
| Give people power. Give people capabilities. Don't run, don't
| hide, don't put your head in the sand. Do it. Be brave. Enable
| better worlds to come.
| bzb6 wrote:
| I don't want the web doing cool things. I want the web to be
| fast, boring, and private. Leave the cool things to native
| apps.
| rektide wrote:
| It sucks, this tension of people that insist the web be the
| one thing they want, that anyone wanting anything else be
| unable to get it. I don't know how to deal with
| conservatives. Never have.
| sumtechguy wrote:
| On the surface it sounds like 'hmm sure why not' then you
| stop and think about it. It is a security/privacy nightmare
| waiting to happen. Much like ActiveX and java apps were. I
| suspect webassembly will end up in the same place.
| Frankly it will be used by some small segment of web
| applications that are cool like you say. At best I fear the
| majority of the use would be just to fingerprint us more to
| show us more soap/shoes/drugs to buy. At worst it would end
| up being a never ending pit of security vulins. We have
| tried this sort of tech before it worked badly in the end.
| So a bit of caution is not unwarranted.
| cesarb wrote:
| No discussion about this subject can be complete without
| mentioning ActiveX. It's the extreme endpoint of this path: a
| signed ActiveX control had full access not only to hardware
| capabilities, but also software capabilities. That much access is
| nowadays widely considered as having been a mistake.
| api wrote:
| Normally I think rules like Betteridge's Law of Headlines are
| lazy, but it is strong with this one.
| viktorcode wrote:
| Web? Yes. Browser? No.
|
| It is very convenient to have a standard API for accessing
| hardware over the internet. But marrying this API with browser
| will inevitably create security nightmare, as previous decades of
| web technologies taught us.
|
| As a solution I would propose another API layer, between browsers
| and the host OS. When a browser requires access to a certain
| hardware capability it requests the access via this API from the
| OS. The OS is actually the one where this capability support is
| implemented and vetted, leaving browsers code much leaner than it
| is now.
| kitsunesoba wrote:
| I really like this idea, because it'd enable true per-site
| permissions for hardware access -- currently one has to give
| the browser access to everything and trust its ability to
| restrict access as needed and keep sites cordoned off from each
| other. The browser itself would no longer need exceptional
| privileges (compared to other types of apps) in order to
| function as a platform.
| wintorez wrote:
| I was thinking about something similar the other day. At the
| moment, we have 2 webs. One is for websites, and the other one
| is for apps that happen to run in web. I when apps run in the
| browser mode (with address bar, tabs, etc.), they should run in
| sandbox mode, but once you "install" the app (similar to add to
| home screen on mobile), they should be treated like a native
| app.
| lrossi wrote:
| I wish browsers would aim to become lighter, not heavier. One
| already needs a ton of RAM, a fast CPU and a decent graphics card
| to render smoothly webpages that consist of basically just text
| and a few images. It's ridiculous.
| sfink wrote:
| But they're not just text and a few images. They're text, a few
| images, and megabytes of advertising (and often tracking) JS.
|
| The site creators will argue, with some merit, that the crap is
| necessary to provide income in order for them to create and
| maintain the site.
|
| You can make the browsers lighter, but they wouldn't browse
| today's Web. Which is fine; I'm all for getting away from the
| shitshow that is today's Web, but simply making browsers
| lighter weight would not be a winning Jenga move.
| gabereiser wrote:
| No, the browser can use hardware to accelerate but the web should
| remain agnostic.
| bergstromm466 wrote:
| So basically the question is: should corporations keep betraying
| users by giving away their hardware specs?
|
| Why are we asking this question? It should be up to the
| individual but it's not - and hasn't been for years. Virtue
| signaling.
| EvanWard97 wrote:
| Regardless of where anyone thinks the maximas are in software
| trade-off space, developers are going to experiment shipping
| software at new points anyway, as markets at known points become
| saturated and exploration again becomes worthwhile in
| expectation.
|
| The aspect of this collective optimization process that seems
| particularly helpful and tractable to focus on is ensuring that
| users know the risks and benefits of their various options.
|
| I'm more interested in seeing web platforms point users to
| excellent, impartial 3rd party analyses of their options and
| their associated risks/benefits, rather than stomp out innovation
| that some people clearly think is worth trying.
___________________________________________________________________
(page generated 2021-01-06 23:01 UTC)