Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 19
  1. #1
    New Coder
    Join Date
    Nov 2012
    Posts
    26
    Thanks
    1
    Thanked 0 Times in 0 Posts

    javascript and hardware access

    I'm new to javascript, but I'm learning fast and loving it. I'm concerned about the lack of hardware access javascript is allowed. Is there any movement to let it have full control just like a native app does? I feel like if browsers created a better security model in them, they could basically have a UAC sort of thing going on. Where if a mobile site wants to access their hardware the browser detects that and prompts the user to allow access or not.

    People download native apps all day long and they have access to hardware and nobody thinks twice. If you don't trust a website then don't allow access. It's not that much different than just not installing it if it was a native app.


    So is there a push for something like this? Are there some security standards browsers are building into them to allow this? I mean to a web app the browsers IS the operating system so it would make sense to have the browser have better security around it, which would then put the power in the users hands and allow us programmers to make richer web apps.

  • #2
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,350
    Thanks
    11
    Thanked 589 Times in 570 Posts
    native apps like you describe still run sandboxed, unless you get into rooted/jailbroken OSs; there is no "hardware access".

    javascript can output on the screen, printer, local files, vibration, internet, and speakers.
    javascript can input from the system clock, a remote URL, touchscreen/mouse, local file system, tilt/acceleration sensors, GPS/compass, microphone, camera, address book, spoken words, keyboard, joystick, and wheels.

    what are you missing ?
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #3
    New Coder
    Join Date
    Nov 2012
    Posts
    26
    Thanks
    1
    Thanked 0 Times in 0 Posts
    Unless I'm mistaken things such as GPS and camera require some sort of proxy. That's not direct access to these things. The sandbox modes for native apps still have more freedom then web apps. This means things like Phonegap just don't count. They fill the, no pun intended, gap, but it's not the same because it's still being translated to a native application. PhoneGap is basically there because javascript isn't given this freedom in browsers. I guess that's what I was trying to get at. Just let javascript access these features from the web. Make browsers more like OS's where they have higher security and let the users decide what to trust and not.

    I think storage is the biggest thing. The 5 MB, 10 using your library, is still pretty limiting when dealing with the big picture. I'm not talking about just mobile devices when talking about web apps. PC web apps is where the future is app also, but it requires access to more freedom of storage.

  • #4
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,641
    Thanks
    0
    Thanked 649 Times in 639 Posts
    It all depends on where you are running JavaScript - as a desktop app or on a web server it has far more access than it has in a web browser.

    Any other language running in a web browser would have the same restrictions or would present a huge security hole the way activex on IE6 did where anyone using that browser probably has a bazillion viruses and other nasties find their way onto their computer every week - I think most zombie computers used in DoS attacks had the appropriate software installed via activex in IE6.
    Last edited by felgall; 11-30-2012 at 07:55 AM.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #5
    New Coder
    Join Date
    Nov 2012
    Posts
    26
    Thanks
    1
    Thanked 0 Times in 0 Posts
    I just feel like if the browsers worked in more of a sandbox mode and were more like OS's then what's the difference between installing a program, and navigating to a website that acts like a program. If the browsers had UAC or some other level of security it would allow the users to control what web app can act on their computers.

  • #6
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,350
    Thanks
    11
    Thanked 589 Times in 570 Posts
    Quote Originally Posted by RickP View Post
    Unless I'm mistaken things such as GPS and camera require some sort of proxy.

    I think storage is the biggest thing. The 5 MB, 10 using your library, is still pretty limiting when dealing with the big picture. I'm not talking about just mobile devices when talking about web apps. PC web apps is where the future is app also, but it requires access to more freedom of storage.

    you are mistaken, these are features native to web apps:

    • navigator.geolocation.getCurrentPosition

    • <input class="mobile" type="file" accept="image/*" capture="camera" placeholder="images" />
    • <input class="mobile" type="file" accept="audio/*" capture="microphone" placeholder="audio" />
    • getUserMedia()


    on devices which use webkit, you can use indexedDB or webSQL to store more than 5MB. chrome in particular keeps it unlimited.

    i checked PhoneyCrap out a while back but was unimpressed; it's better just to write the web app than locked-in app that doesn't have the same touch features as it's siblings.

    if you consider desktop-installed webapps like HTA files, moz packages, chrome's crx-based apps, and other solutions like AIR, i think you'll find elevated permissions relative to a normal webpage.
    the security models for these systems varies, but you can get unlimited disk access, x-domain ajax w/o cors, quieter (no yellow bar) existing API access for stuff like GPS and storage, and several other capabilities to boot. Each system offers a little more or less than others in some areas, but with the array of options available even at this early point in serious html app dev, you can find a workable solution for almost any computing challenge.
    Last edited by rnd me; 11-30-2012 at 06:58 PM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #7
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,641
    Thanks
    0
    Thanked 649 Times in 639 Posts
    The difference with running a script inside a browser is that as it has access to and from the server if it also has access to and from the desktop then that would give the server access to install whatever anyone wanted onto your desktop.

    Scripts running in desktop applications (eg. via AIR) do not have access to the server and scripts running on the server do not directly have access to the desktop and so scripts running in those locations do not have the security issues that exist where someone could have their server side script use something running in their web page that deletes everything from your hard drive when you access their page or fills your hard drive completely with garbage or viruses when you access their page or simply installs software in the background allowing them to use your computer however they like whenever you are connected to the internet (eg. in DoS attacks).

    There are enough concealed goat tracks that exist that get used to install nasties onto people's computer without their permission that opening up a 50 lane super highway by giving JavaScript access to read and write files is not really a good idea.

    Anyway JavaScript has always had a very limited file access via cookies and now has a greater level of local file access using localStorage but those storage areas are the limit of where JavaScript in a browser can read and write to locally so as to keep the potential security issues to a minimum.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #8
    New Coder
    Join Date
    Nov 2012
    Posts
    26
    Thanks
    1
    Thanked 0 Times in 0 Posts
    @felgall I just feel like there is so much potential here but we paralyze ourselves with fear. I have to imagine there are ways a browser could protect us against such things. Prompt us for elevated permissions by a site if we trust it. I think the day will come and I think people will be more pickier about the sites they access & trust that are applications. A good number of sites will still just be your basic sites, but the application sites will on a different level of trust. Like if google docs could directly access your harddrive without any sort of proxy people would allow elevated rights for that because they trust Google (most people). I don't see anything wrong with that and I think it adds a very powerful dimension to web apps.

    @rnd_me I'll have to check those out. That helps solve GPS and camera, but harddrive access is a big one I think.

  • #9
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,350
    Thanks
    11
    Thanked 589 Times in 570 Posts
    Quote Originally Posted by RickP View Post
    @rnd_me I'll have to check those out. That helps solve GPS and camera, but harddrive access is a big one I think.
    there a major problem for that under IOS: it has no filesystem; there are no sd cards or directory browsers...

    google does allow hard drive access to docs using their sync technology.
    same for M$ with skydrive+office+lync.

    amazon has related functionality for lower-level APIs, mainly directed at paas customers, but available RESTfully as well.

    we all known that you can drag files (and folders in chrome) into javascript apps. chrome lets you drag single files out. the new download attrib on <A> allows a named-file to be saved, a step up from dataURLs. you may even be able to drag that named-file-link from a page to a folder and watch the file appear before your eyes.

    extensions are able to write to the disk in most browsers. there might even be a way to do it with greasemonkey, i know it provided nonSOP ajax for example.


    hta files on windows can read write the disk at will using FSO, an interface not unlike node.js's fs lib.

    speaking of node, you can run it locally and use cors/jsonp to talk to http://localhost:9000 or whatever. this works well for home-brew power apps, but i don't expect grandma to get node working on her mac...

    you can also code javascript that run in windows with full permissions using the little-mentioned command "jsc.exe" to make a command-line .net exe.
    that exe can monitor the downloads folder for incoming "commands", and shuttle data around as needed. you can do the same pattern in an hta file, which can run invisibly; not on the taskbar.


    while some type of uniform access might be nice, don't hold your breath.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #10
    New Coder
    Join Date
    Nov 2012
    Posts
    26
    Thanks
    1
    Thanked 0 Times in 0 Posts
    google does allow hard drive access to docs using their sync technology.
    Yeah but it's a client side download though like dropbox. Doesn't count in my fantasy world

    there a major problem for that under IOS: it has no filesystem; there are no sd cards or directory browsers...
    Data is stored on disk in some fashion. Making folders and such isn't a requirement with what I'm talking about. Being able to create persistent data on the harddisk of the client machine, however one would read/write this I don't really care, is all the point really is that I'm trying to make. I can do this with local storage (it's just very limited compared to the gigs clients have) and I have no idea where the data is being stored. Honestly I don't care where it's being stored as long as I have a way to read/write it. I don't even care if I can't access other app files as that's not critical.

    This is a nice sandbox mode that works just fine. So if javascript apps were able to read/write data it would be contained by the browser of it's access to it's own "app" location. That way you couldn't just delete everything on a users harddrive. The threat would more so be using up all the disk space, but you can get around that I think by letting the user decide and the app ask. No harm in that. Let the user have control. They know how much harddisk space they have and if I want the new client side google web app to use up 1 gig of my harddisk I should be able to do so at my own risk. Not much different than downloading it and installing the same desktop app. It's about trust and user control that would make this work.

    we all known that you can drag files (and folders in chrome) into javascript apps. chrome lets you drag single files out. the new download attrib on <A> allows a named-file to be saved, a step up from dataURLs. you may even be able to drag that named-file-link from a page to a folder and watch the file appear before your eyes.
    You are just downloading those files. It's a proxy to get around the fact that we can't access client harddisk. All these things are hacks around that 1 fact. It means you have to be and stay connected to the internet to make this work. With cache manifest the app could be 100% client ran without needing the internet accept for the initial download (which basically becomes a seamless install with benefits). Even if internet is available if nothing changed on the server side local cache is used making load times faster.


    I know how things are today, I'm living it like we all are, but I don't think that doesn't mean we shouldn't push the envelope and dream bigger. All apps as web apps with available offline mode (where the app makes sense to not require internet access) running 90% client side code with ajax to hit the server for the other 10% communication it requires. Page reloads being a thing of the past. One code base to rule them all

    I know it'll take some time but I think it'll get there.

  • #11
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,641
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by RickP View Post
    @felgall I just feel like there is so much potential here but we paralyze ourselves with fear. I have to imagine there are ways a browser could protect us against such things.
    Those things where there it is reasonable to do that already prompt for permission so it isn't a matter of fear.

    The latest browsers also allow communications between different locations provided that the appropriate code is used in BOTH places. Currently this is possible between different sites loaded into the browser at the same time and between a web page from one site and server site processing on a different site.

    Also localStorage is available for saving data that would normally be saved in a file but which can't be because of the security issues with allowing JavaScript in the web browser access to any files. So carrying on the analogy from what is already available writing to localStorage and reading from there provides one side of what is necessary for a web page to communicate with a separate local application. So all that would be needed is for the application to be able to interface with the file that the browser is using for localStorage for JavaScript to be able to communicate with a desktop application safely.

    There is no fear involved in these security considerations - there were literally many thousands of security holes in Internet Explorer 6 because of the way it implemented access between web pages and the computer. So it has been a matter of blocking those things which have already been shown to be major security issues (the patch for those holes in IE6 went by the name IE7) and then carefully working out secure ways to re-implement those things that can be done safely in a safe way. Mostly it involves having both sides of the process giving permission for the access to the other side through setting up specific mechanisms for the communication that require specific code in both places.

    Anything that allowed JavaScript running in a web browser to write files to anywhere on the hard drive WOULD permit someone to fill your entire drive with whatever they like - if the process has to ask permission first then they just need to break into a major web site that everyone trusts and distribute their files through that site.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #12
    New Coder
    Join Date
    Nov 2012
    Posts
    26
    Thanks
    1
    Thanked 0 Times in 0 Posts
    Anything that allowed JavaScript running in a web browser to write files to anywhere on the hard drive WOULD permit someone to fill your entire drive with whatever they like
    Th standard/api should be considering the browser as it's OS and should be exposing how you interact with all the same things the OS does in a similar fashion (hard disk, graphics card, sound card, other attachments). Then it's up to the OS to handle that correctly. Therefore I want to be able to make "files" in my own domain space. Say each domain gets it's own virtual space (/home) but can't see outside of it's domain space, and disk space is requested/required just like when we install a program. It checks that there is enough disk space for what the program is, so should web apps be able to. The first time you go to a web app it should be able to tell you it's going to use up x amount of hard disk space and does the user agree to that? Once the user accepts that's how much space is allocated and no more unless prompted otherwise.

    So the question is why is the standard not taking it far enough (from what I see)? They seem to be worried about security (that's the fear I'm talking about). That's not their job, it's the browsers job to worry about security, it's the standards job to say this is what you need to implement and they just don't seem to be taking it far enough from my perspective.

  • #13
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,641
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Quote Originally Posted by RickP View Post
    They seem to be worried about security (that's the fear I'm talking about). That's not their job, it's the browsers job to worry about security, it's the standards job to say this is what you need to implement and they just don't seem to be taking it far enough from my perspective.
    It iis the browser that implements the version of JavaScript that it runs and so it is the browser that is concerning itself with security.

    Also modern browsers do have their own file system that works as you suggest called localStorage.

    Since browsers can run on a range of devices - computers, phones, televisions, refrigerators etc most of which don't even have the other peripherals you referred to there is no point in implementing interfaces to peripherals which only rarely exist. Computers are the only devices that the browsers run on that have those peripherals and more and more web access is being done through the growing number of other devices. Even with computers the browser doesn't know what peripherals exist - it relies on the operating system it is running on to handle that. For example when you print a web page it is the operating system that asks where you want to print it - not the broweser - as the browser doesn't even know or care whether the device it is running on has access to a printer.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #14
    New Coder
    Join Date
    Nov 2012
    Posts
    26
    Thanks
    1
    Thanked 0 Times in 0 Posts
    For example when you print a web page it is the operating system that asks where you want to print it - not the broweser - as the browser doesn't even know or care whether the device it is running on has access to a printer.
    That's sort of my point. The browsers need to start acting more like operating systems, and javascript/html standard can accelerate that by pushing the standard to require more from these browsers. It's not as if the browser, that is an install on the device, can't query the OS to get the info and then pass it along to the browser to expose to javascript.

    Local storage is a good step but it's still lacking in the space field. I've said that already and will keep saying it. We should be able to request from the user how much space our site wants (if over a certain value) and they should be able to allow that. Prompt vs them manually just giving the same to all sits, and per web domain not web page. That makes a big difference in how it's implemented today, and what apps can be made.

    Your other point is valid only if we expect very specific API's. Generally peripheral API's are pretty generic. It's not as if Windows knows every single peripheral that will be invented. That's what a generic driver interface is for. We should be able to query for it, then use it if it's there.

  • #15
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,350
    Thanks
    11
    Thanked 589 Times in 570 Posts
    Quote Originally Posted by RickP View Post
    Local storage is a good step but it's still lacking in the space field. I've said that already and will keep saying it. We should be able to request from the user how much space our site wants (if over a certain value) and they should be able to allow that. Prompt vs them manually just giving the same to all sits, and per web domain not web page. That makes a big difference in how it's implemented today, and what apps can be made..
    not Localstorage, that's a bad idea. 5mb is likely going to be the cap for some time. The reason is that the browser must load all the localStorage data before the page uses it for the first time. Loading more than 5mb on a phone could take a noticeable while, so it's not something you want to do every page load.

    On the other hand, if you load it after the page, there will be a delay on-demand as all values are loaded, not just the single key requested. This causes a pause in the app, which is no good either...



    all that said, i agree with your demands for more space. I am working on a xbrowser async storage system (~75% done) that uses a high-level interface to save, load, list, and delete named objects. I cram all storage providers into a common and simple async interface to be able to seamlessly stack up providers on-demand. For example, using localstorage and indexDB, we can store 10mb uncompressed. webSQL is much more, 50mb. my system would let you use all three from one code point, without even knowing which of them are specifically installed on that browser. I figured out the indexeddb stuff so you don't have to.
    Last edited by rnd me; 12-03-2012 at 06:43 PM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •