4 ms·

I'm very aware of that, as I have worked for a big corporation with such policies for normal users. However I believe that for them browsers which directly acce

I'm very aware of that, as I have worked for a big corporation with such policies for normal users. However I believe that for them browsers which directly access real hardware will seem like an even bigger nightmare than users installing applications. And you still have the question on how the web app comes to the user: Through a dedicated intranet site? Makes sense if more than one user requires it, but the effort seems similar as packaging a native application and rolling it out automatically through the ITs deployment system. If only very few users (maybe only a single one) requires that hardware both approaches have a high overhead and supporting the device will be most likely rejected. Getting this web app directly from a third party site will be mostly out of question for the companies you are talking about. Besides the security implications then we also talk about reliability problems ("I can't use my USB device because internet is down...")

BinaryIdiot 11y ago
> browsers which directly access real hardware will seem like an even bigger nightmare than users installing applications. If you look at the spec it doesn't directly access hardware and it even acknowledges doing so could be a big security issue. You interface with an abstraction that sits above the hardware that won't give you direct access but, instead, access to a subset of options that pass through the abstraction. > Through a dedicated intranet site? Makes sense if more than one user requires it, but the effort seems similar as packaging a native application and rolling it out automatically through the ITs deployment system. I'm not sure how you can compare the rollout of a native application to all user computers versus publishing within an intranet. They are not even in the same league in terms of deployment. Intranet is far, far easier. The native application has to be pushed out, installed and verified. A web app simply has to have its link emailed to users. Hell you could even push out a bookmark over many IT management systems (which is far easier than dealing with pushing out an application).

BinaryIdiot 11y ago

> browsers which directly access real hardware will seem like an even bigger nightmare than users installing applications. If you look at the spec it doesn't directly access hardware and it even acknowledges doing so could be a big security issue. You interface with an abstraction that sits above the hardware that won't give you direct access but, instead, access to a subset of options that pass through the abstraction. > Through a dedicated intranet site? Makes sense if more than one user requires it, but the effort seems similar as packaging a native application and rolling it out automatically through the ITs deployment system. I'm not sure how you can compare the rollout of a native application to all user computers versus publishing within an intranet. They are not even in the same league in terms of deployment. Intranet is far, far easier. The native application has to be pushed out, installed and verified. A web app simply has to have its link emailed to users. Hell you could even push out a bookmark over many IT management systems (which is far easier than dealing with pushing out an application).