Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Privacy Safari Security Apple

Apple Declined To Implement 16 Web APIs in Safari Due To Privacy Concerns (zdnet.com) 120

Posted by msmash from the assuming-control dept.
Apple said last week that it declined to implement 16 new web technologies (Web APIs) in Safari because they posed a threat to user privacy by opening new avenues for user fingerprinting. Technologies that Apple declined to include in Safari because of user fingerprinting concerns include: Web Bluetooth - Allows websites to connect to nearby Bluetooth LE devices.
Web MIDI API - Allows websites to enumerate, manipulate and access MIDI devices.
Magnetometer API - Allows websites to access data about the local magnetic field around a user, as detected by the device's primary magnetometer sensor.
Web NFC API - Allows websites to communicate with NFC tags through a device's NFC reader.
Device Memory API - Allows websites to receive the approximate amount of device memory in gigabytes.
Network Information API - Provides information about the connection a device is using to communicate with the network and provides a means for scripts to be notified if the connection type changes.

Battery Status API - Allows websites to receive information about the battery status of the hosting device. Web Bluetooth Scanning - Allows websites to scan for nearby Bluetooth LE devices.
Ambient Light Sensor - Lets websites get the current light level or illuminance of the ambient light around the hosting device via the device's native sensors.
[...]
The vast majority of these APIs are only implemented in Chromium-based browsers, and very few on Mozilla's platform. Apple claims that the 16 Web APIs above would allow online advertisers and data analytics firms to create scripts that fingerprint users and their devices.
This discussion has been archived. No new comments can be posted.

Apple Declined To Implement 16 Web APIs in Safari Due To Privacy Concerns More

Apple Declined To Implement 16 Web APIs in Safari Due To Privacy Concerns

Comments Filter:

  • Opt-in? (Score:5, Interesting)

    by reanjr ( 588767 ) on Monday June 29, 2020 @11:03AM (#60241954) Homepage

    Why not allow opt-in? These seem like legit features that people might want to use.

    • Re:Opt-in? (Score:5, Informative)

      by AmiMoJo ( 196126 ) on Monday June 29, 2020 @11:12AM (#60242002) Homepage Journal

      In the case of the Bluetooth and NFC API's it because allowing users to opt-in would mean they were not forced to use Apple approved apps.

      The Bluetooth and NFC APIs are designed to remove the need for dedicated apps, instead you can just go to a website. So say it's something like a payment processor with Bluetooth (very popular devices, much cheaper than a card payment terminal) you could just use the manufacturer's website, after all you need connectivity to process the payment. But then Apple couldn't control it like they do with the manufacturer's app, which must be approved for the App Store and can be removed at any time for any or no reason.

      • Sure, give away privacy for a little convenience (Score:5, Insightful)

        by Geoffrey.landis ( 926948 ) on Monday June 29, 2020 @11:54AM (#60242206) Homepage

        Yes, that. But, also, allowing bluetooth scanning is a means for the website to identify and track the person.

        That's the way privacy leaks away: there is some outwardly visible benefit to the API, but it also allows websites to track your every move.

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          Bluetooth scanning is worse than merely giving away privacy.

          You're also giving permission to any malware on the site you're visiting to survey possible attack surfaces.

          • Given you need to do this on a per site, per visit basis it's a risk that many will take.

            • > Given you need to do this on a per site, per visit basis it's a risk that many will take.

              Why is this music composition website trying to access my MIDI devices? It's probably tracking me!

              (Apple's view of people who don't pay them 30% of revenues.)

        • Re: (Score:3)

          by AmiMoJo ( 196126 )

          All they have to do is have a message saying "are you sure, this can be used to track you?" and limit it to one time while the site is open.

          • All they have to do is have a message saying "are you sure, this can be used to track you?" and limit it to one time while the site is open.

            Which is exactly what Safari does with web-based location requests... so it would seem they should be amenable to this approach with other APIs.

          • All they have to do is have a message saying "are you sure, this can be used to track you?" and limit it to one time while the site is open.

            IIRC, I think there is a bit more nuanced "Temporarily-allow" feature built into the upcoming Safari on Big Sur. I don't remember the details, but it was during the Big Sur demo in the WWDC Keynote, which starts at 1:08:00.

          • Re: (Score:3)

            by Kisai ( 213879 )

            People get annoyed with popups and just hit OK to everything, since the site's already learned they can get away with this for GDPR. So if a site goes "sorry, enable bluetooth to continue" it's just a slippery slope of trash.

        • Yes, that. But, also, allowing bluetooth scanning is a means for the website to identify and track the person.

          And that doesn't change anything when you opt in on a feature level, e.g. Chrome. You can "scan" all you want. The only time you'll ever see anything other than zero is if the user specifically intervenes. There is no "scanning" to be done, and as such there is no privacy concern.

          That's the way privacy leaks away

          Only if you completely screw the implementation.

        • You could do what VMWare does. Set up a virtual network card and any virtual machine (or in this case, browser) wishing to access it only sees the virtual BT adapter, not the real physical one. You can then block scanning at the virtual device level, with bluetooth connect requests using the physical device to scan. You connect to the desired device via your physical BT adapter settings, which the VM/browser then sees as the only device in its scan using the virtual BT adapter. The problem for BT would see
        • It's 100% a privacy risk; the question, in Apple's case, is why something is OK for an app to do if it requests a given permission(depending on the details, potentially a vague basket of permissions under a single name that users can reasonably be expected to not understand in detail) but not OK for a website to do if it requests a given permission.

          If the answer is that "we just don't allow that, period, way too risky"; or "because high probability of relatively nasty javascript trick violation of same o

      • Re:Opt-in? (Score:5, Informative)

        by edwdig ( 47888 ) on Monday June 29, 2020 @12:53PM (#60242462)

        Apple has been hardcore cracking down on Bluetooth access for the past year or so. Tons of apps were silently using bluetooth in the background to scan for devices designed to track people as they entered stores. That's why recent iOS versions now prompt you to approve bluetooth access for each app.

        Denying bluetooth access from Safari is just a natural extension of this.

    • I imagine Apple is aware enough of their user-base to know many people will just blindly click accept without realizing the ramifications of that decision. Chances are they would rather wait for these API's to close up some of these holes before implementing them, if at all, and most iPhone users are perfectly fine not knowing these features exist or will take Apples word on it.

      I am not always a fan of Apple but they do lead the way on privacy concerns among-st the tech giants, something their walled garde

      • I imagine Apple is aware enough of their user-base to know many people will just blindly click accept without realizing the ramifications of that decision.

        So, what you are saying here? Is Apple, who claims that these apps will be used to track user data, tracked their users via data to determine how it would be received?

        When did we all accept Alice in Wonderland as a future way to live?

        • I'm just saying Apple is likely aware that a large portion of their user-base are people that just want normal smartphone stuff and aren't all that tech-savvy and aware of the nitty gritty of the world of user-tracking, API vulnerabilities and other minutiae of the modern internet. I don't even think Apple would need a ton of user-tracking to make that determination.

          The number of Apple users who read this move and make an Android their next phone I imagine are 1%. Easy choice for a company that wants to

          • I'm just saying Apple is likely aware that a large portion of their user-base are people that just want normal smartphone stuff and aren't all that tech-savvy and aware of the nitty gritty of the world of user-tracking, API vulnerabilities and other minutiae of the modern internet.

            Not just the Apple user-base, of course. You have described the entire device user base.

        • No, but they are a bajizllion dollar super-company. You can bet they focus-group and study the hell out of anything they do. They don't *need* to put tracking shit everywhere, and generally they don't.

          • No, but they are a bajizllion dollar super-company. You can bet they focus-group and study the hell out of anything they do. They don't *need* to put tracking shit everywhere, and generally they don't.

            You mean like the "Do not track" that was opt-out in Safari?

            I guess after half a decade, yes, they have enough data. And if you think they all the sudden stopped collecting data to improve their hardware, a CORE TENANT OF THEIR COMPANY FOR YEARS, you truly are living under a rock.

            • No, but they are a bajizllion dollar super-company. You can bet they focus-group and study the hell out of anything they do. They don't *need* to put tracking shit everywhere, and generally they don't.

              You mean like the "Do not track" that was opt-out in Safari?

              I guess after half a decade, yes, they have enough data.
              And if you think they all the sudden stopped collecting data to improve their hardware, a CORE TENANT OF THEIR COMPANY FOR YEARS, you truly are living under a rock.

              First off, it's "tenent" (as in "codicil"), not "tenant" (as in "renter").

              Second, all data-collection is clearly set forth in their Privacy Policy, and is Opt-Out-able.

              And name one tech company who doesn't do this; because it actually does provide useful information regarding how users actually, er, use their products?

              As long as it is disclosed, and can be stopped, I have no problem with it.

              • First off, it's "tenent" (as in "codicil"), not "tenant" (as in "renter").

                lol, the grammar police. You obviously knew the intent of what was meant and still decided to convict my phone for bad voice dictation.

                bravo, keyboard warrior, bravo!

                • No, the word you were looking for is TENET, meaning a principle or belief, especially one held in common by a group or people or an organisation.

        • I imagine Apple is aware enough of their user-base to know many people will just blindly click accept without realizing the ramifications of that decision.

          So, what you are saying here? Is Apple, who claims that these apps will be used to track user data, tracked their users via data to determine how it would be received?

          When did we all accept Alice in Wonderland as a future way to live?

          OMFG! Just Stop It!!!

          You know bloody damned well that the truth is, a huge majority of all users on any platform will blindly "Click-Through" any and all warnings, no matter how dire, just to get to teh Kitteh Pictures!

          FFS, it's not an "Apple Users" thing, and no "User Tracking" need be done to predict that long-established fact regarding user-behavior.

          Jeebus!

    • Re:Opt-in? (Score:5, Insightful)

      by Geoffrey.landis ( 926948 ) on Monday June 29, 2020 @11:14AM (#60242010) Homepage

      Why not allow opt-in? These seem like legit features that people might want to use.

      Because details of exactly what you are opting into, and what they will do with that opt in, is always hidden away under layers and layers of garbage.

      The part "sure, I think I'll opt in to this, it might be useful" is highlighted, and the part "This will allow any website you go to to track who you are and every click you make in the future" is hidden away under legal jargon on page 9 of the user agreement.

      • Re: (Score:3)

        by DarkOx ( 621550 )

        Also the very presences of a lot of these things presents a target. Lets say there is some exploitable flaw elsewhere. So you got some code execution now what. You might have all sorts of limitations:

        how do make a network connection to call home?
        how large can your payload be?
        what version of this library or that is present?
        what can't the user be prevented from seeing that will look suspicious?

        A lot of these problems get solved when suddenly the payload does need to get you a 'shell' or do much mischief itsel

      • Because details of exactly what you are opting into, and what they will do with that opt in, is always hidden away under layers and layers of garbage.

        No it's not. We're talking about core functionality here. It doesn't matter what you claim, what you opt into is hardware access. No need to read any legalese or even a privacy statement. Slashdot could ask all it wants, it doesn't get Bluetooth access, or screen brightness sensor access until there's a reason for it to have so.

        A massive amount of functionality of a browser is already opt in, not implementing the functionality due to privacy is a complete bullshit excuse as currently there's no difference t

        • No it's not. We're talking about core functionality here. It doesn't matter what you claim, what you opt into is hardware access. No need to read any legalese or even a privacy statement. Slashdot could ask all it wants, it doesn't get Bluetooth access, or screen brightness sensor access until there's a reason for it to have so.

          Precisely! By turning this functionality off, Slashdot doesn't get Bluetooth access or screen brightness sensor access or any ot this, no matter how nicely it asks and pretends it has a reason to have it.

          • It's off by default. Why not turn your entire computer off and never turn it on again. That way privacy is preserved too. Oh wait, you actually *want* some functionality too don't you and despite the way you come across privacy is not your singular goal.

            Guess what. I'm using Chrome, and Slashdot doesn't have access to my Bluetooth devices either, even if it wanted it.

    • If you want those features you can use an open source forked browser :shrugs: If they don't provide them shop elsewhere where they do. That's the great thing about open source isn't it.

    • Why not allow opt-in? These seem like legit features that people might want to use.

      If they don't like this restriction, people are free to run Chrome, FireFox, or whatever browser they wish on their Mac.

      There is a bit more of an argument on iOS/iPadOS, because all browsers on those platforms must be WebKit-based; but those Devices are generally seen as being somewhat more privacy-sensitive that non-Mobile ones.

      But I think that Apple got it right on this one. "Fix your security holes, then we'll talk."

      So, the bigger question is: "Why isn't the response 'Do you have any suggestions on how w

    • Why not allow opt-in? These seem like legit features that people might want to use.

      By that same token, builders should install decrepit staircases in buildings. After all, reaching the second floor is an entirely legitimate use case, so people will likely want to use these decrepit staircases. Let it be opt-in and people can make their own choices, right?

      Well, no. Installing decrepit staircases is a terrible idea, just like adding support for insecure APIs.

      If we already know a design is inherently bad, why would any reasonable builder/maintainer of code allow that design to be used? They'

      • Re: (Score:2)

        by green1 ( 322787 )

        Your alternative is to have a building with a second floor, with all sorts of desirable things up there, but no staircase at all.

        Maybe instead we should focus on building a better staircase?

        I'm fully willing to admit that these features could potentially be misused, But so could every single function of the phone. If you really wanted the phone to be fully secure you wouldn't allow it to be turned on in the first place. the fact that you bother to have a bluetooth and nfc transceiver implies you see the use

        • Your alternative is to have a building with a second floor, with all sorts of desirable things up there, but no staircase at all.

          I was most certainly NOT suggesting that we simply throw our hands up in the air and go "well, it's either unsafe staircases or nothing, so we're stuck with nothing".

          I deliberately chose an analogy that would make it clear there was legitimate utility—perhaps even necessity—in the things being done by these APIs, but that I also believed there are obvious ways to improve the situation. I then spent the entire back half of my post laying out an example of how one might do so, which I thought made

    • Because apple knows what's best for you...

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      Why not allow opt-in? These seem like legit features that people might want to use.

      It is opt-in. It's just not enabled in the Apple provided Safari browser.

      But no one is saying you can't write your own browser for iOS. The only restriction is it has to use the built in WebKit renderer, but is free to do whatever else you want.

      Custom webbrowsers are more than just a fancy skin on top of a renderer - things like extensions, APIs and other stuff can be added to make your browser different.

      Just like Firefox for

  • And let the user select in the browser which one to use, whether it's a soft-MIDI implementation, or selecting an installed MIDI hardware device.
    Therefore all Safari users would report 1 MIDI device in the enumeration and it would be the only one that could be selected. That would stop user fingerprinting.

    Also add in user opt-in, as with audio/video capture.

    I guess the Bluetooth could also be done with an in-browser proxy like the above.

  • Battery status? (Score:3)

    by bagofbeans ( 567926 ) on Monday June 29, 2020 @11:17AM (#60242030)

    Give me one user friendly reason for a website to see battery status...

    • To determine your credit status. https://money.cnn.com/2016/08/... [cnn.com]

    • Quote: "Give me one user friendly reason for a website to see battery status..."

      Intel Asistant is a website that uses an installed program to access many info. Instead if those web APIs were available, it could do all that work without installing anything in your system and check the battery before install any critical software update (like graphic drivers, BIOS updates, etc.)

    • Re:Battery status? (Score:4, Insightful)

      by ljw1004 ( 764174 ) on Monday June 29, 2020 @12:39PM (#60242426)

      Give me one user friendly reason for a website to see battery status...

      If I'm building a point-of-sale or embedded device of some sort. It has no screen, no borders, no widgets; it's just a device that displays nothing other than a touch-sensitive webview full-screen. The user can't switch apps, can't do anything other than interact with this full-screen webview. The developer wants to write their software as a webview rather than an app because it makes it easier to provision and update. The device has a battery, and needs some way to display battery life.

      • Re: (Score:3)

        by ceoyoyo ( 59147 )

        Lazy developer friendly isn't user friendly.

      • Re: (Score:2)

        by nmb3000 ( 741169 )

        The developer wants to write their software as a webview rather than an app

        When the only tool you know how to use is a hammer...

        The very fact that you can't access low-level device status seems like it should preclude using a website for an embedded application.

    • Give me one user friendly reason any program anywhere needs access to battery status, and then just s/program/website and s/operatingsystem/browser and you will have joined the rest of us in 2020.

      The idea that a browser is something you use to visit websites sounds like a concept from the turn of the century. Remember that it's 2020 and for several years already you could run a whole Windows 95 emulated from within your browser itself https://win95.ajf.me/ [win95.ajf.me] to say nothing of the fact that many people these d

    • Some of the APIs (like that one) seems like they were designed so that the browser could work as a sort of mobile OS which is exactly what Firefox OS was. So they may have been originated back then.
      Also, I follow Firefox development closely and I've seen some APIs being deprecated over the years since apparently were only used on Firefox OS.

  • Privacy or Strategic Hobbling? (Score:3)

    by mileshigh ( 963980 ) on Monday June 29, 2020 @11:21AM (#60242042)

    Begs the question whether Apple is afraid that overly-powerful WebApps might cut into regular iOS apps? We already know that Apple is looking to services to fuel its next leg of growth, services like their App Store.

    WebApps require no App Store, no 30% tax, no approvals, no platform-dependent implementation, no Mac-based development hardware, no iOS developers, no...

    Or maybe they're worried that the browser will become THE operating system, making the underlying platform irrelevant. No wonder Google is pushing for this.

    If Apple were truly concerned about privacy, I can easily envisage policies designed to limit access to, say, the NFC reader without out-and-out banning access to all comers.

    • Re: (Score:2)

      by Luthair ( 847766 )
      I was going to point out that Apple isn't exactly known for being fast to implement new web APIs, this could just as easily be that they were so slow that the rest of the industry found out there was a problem before Apple got around to working on Safari.

    • BTW just in case you didn't know: to "install" any webpage as an "app" just open it in Safari, press Share, then select Add to Home Screen and follow prompt.
      Voila, there's an icon for it like any other app.
      To "uninstall" just press & hold, delete it.

      • Re: (Score:2)

        by Merk42 ( 1906718 )
        Wow that seems kinda clunky, if only there was some web standard way of doing it.

      • BTW just in case you didn't know: to "install" any webpage as an "app" just open it in Safari, press Share, then select Add to Home Screen and follow prompt.
        Voila, there's an icon for it like any other app.
        To "uninstall" just press & hold, delete it.

        That actually goes back awhile, doesn't it? But it's easy to forget that it exists...

    • Begs the question whether Apple is afraid that overly-powerful WebApps might cut into regular iOS apps? We already know that Apple is looking to services to fuel its next leg of growth, services like their App Store.

      WebApps require no App Store, no 30% tax, no approvals, no platform-dependent implementation, no Mac-based development hardware, no iOS developers, no...

      Or maybe they're worried that the browser will become THE operating system, making the underlying platform irrelevant. No wonder Google is pushing for this.

      If Apple were truly concerned about privacy, I can easily envisage policies designed to limit access to, say, the NFC reader without out-and-out banning access to all comers.

      Your memes are beyond tired.

      And besides that; are utterly ridiculous.

  • Web Bluetooth and security (Score:4, Insightful)

    by Bookwyrm ( 3535 ) on Monday June 29, 2020 @11:21AM (#60242050)

    "Web Bluetooth - Allows websites to connect to nearby Bluetooth LE devices."

    I have to admit, this sounds like a really, really bad idea on the face of it. I can appreciate that it certainly opens up some interesting potential functionality, but I doubt OS security models are up to this. That is, even if the web browser is sandboxed, if a website can connect to Bluetooth devices outside of the security sandbox, then the OS should put the Bluetooth device in them same sandbox as well.

    I certainly wouldn't want to use a Bluetooth LE keyboard with a web browser if a website might be able to directly connect to the keyboard.

    • Given the implementation requires you to specifically select which bluetooth device is able to be accessed by each website, not on a per website basis, but even on a per *instance* basis. The ability to prevent access to your keyboard is still well and truly within your control.

    • Re: (Score:2)

      by shess ( 31691 )

      "Web Bluetooth - Allows websites to connect to nearby Bluetooth LE devices."

      I have to admit, this sounds like a really, really bad idea on the face of it. I can appreciate that it certainly opens up some interesting potential functionality, but I doubt OS security models are up to this. That is, even if the web browser is sandboxed, if a website can connect to Bluetooth devices outside of the security sandbox, then the OS should put the Bluetooth device in them same sandbox as well.

      I certainly wouldn't want to use a Bluetooth LE keyboard with a web browser if a website might be able to directly connect to the keyboard.

      Yeah, but imagine having an IoT device which vends a config URL via Eddystone beacon, which takes you to a web page that lets you configure the device. Versus downloading an app which invariably is going to ask for location and contact permissions. I mean, damned if you do, damned if you don't, but I think I trust the webpage in Chrome more.

  • I'm not Apples biggest fan (Score:4, Insightful)

    by Viol8 ( 599362 ) on Monday June 29, 2020 @11:33AM (#60242122) Homepage

    But in this case they've made the right decision. The security sandbox that browsers should implement is being increasingly and deliberately shot full of holes by whichever steering committee is responsible for these decisions no doubt aided by fat brown paper envelopes from vested interests. And frankly given the ability of those who are laughable called themselves web "developers" to write even basic secure and bug free code the last thing I want is their code to have even more power on my system.

    • I disagree. The security sandbox has been pretty much developed with security and privacy in mind, and effectively every additional proposed feature of the past 5+ years has been opt in on a per site or in some cases on a per instance basis.

      It makes it difficult to take Apple seriously about the privacy implications of bluetooth when it is impossible to track a user based on bluetooth enumeration without having them click multiple things for each websites across which they are being tracked.

      As for your brow

      • Oddly enough yes I do use browsers to visit websites. How else do you suggest one visits them, using the fucking bus?

        As for the rest of that drivel, what a clueless post.

        • Oddly enough yes I do use browsers to visit websites. How else do you suggest one visits them, using the fucking bus?

          Congratulations on completely missing my point.

          As for the rest of that drivel, what a clueless post?

          I suggest you re-read it when you're not drunk. Or you can continue to pretend that running full blown software from within a browser is not a thing and join that amish community you so strive to be part of.

          • Re: (Score:2)

            by Viol8 ( 599362 )

            If you ever had a point it headed for the hills long ago. No one uses the browser "as a mini OS" unless they're web developers or idiots (not much difference frankly). The rest of us use proper applications.

  • I don't like where this is headed.... (Score:5, Interesting)

    by FrankSchwab ( 675585 ) on Monday June 29, 2020 @11:38AM (#60242152) Journal

    A long, long time ago, the precedent was set in the PC world that installing a program required Administrator privileges, because the program might need to install privileged components (drivers, services, etc). User pushback generally prevented much f*ckwittery from program installers.

    Then Companies got pushier and pushier about the limits of what was acceptable to install - ever tried to use Adobe Acrobat without it's always-running update service? Thoughtful users got busy, and tired of fighting back against the constant barrage of limit-pushing installs. Less-than-throughtful users (sadly, the vast majority) said "oooh, shiney", clicked through the security warnings and didn't give a crap about the keyloggers, system monitors, and persistent tracking, logging, and surveillance that the latest program installed, as long as it enabled them to watch cat videos or pretended to give them secure chat with their friends. And, we're stuck with the model - these days I just assume that every program I install - whether from a "reputable" company or not - installs what I consider malware alongside their main functionality.

    And, with the Chrome focus on turning the browser into the PC replacement, the same insidious trend is occurring. Let a website browse through all my files in the background? Sure, you don't have anything that you're ashamed of there, do you? Let a website scan for all the devices in my house, and communicate with them? Sure, you bought them all from reputable manufacturers who keep them secure and fully patched, right? Let a website turn on all the cameras and microphones in my house, and listen continuously - sure, why not, I might have fallen and can't get up.

    And we'll accept this because those who care are tired, and those who don't will say "Oooh, shiney".

    Crap.

    • Re: (Score:2)

      by Merk42 ( 1906718 )
      Yes, it's much better if you let Apple's proprietary apps do the same thing. They know what's best, now give them, and only them, money for their hardware and walled garden like a good user, and even more money if you're a good little developer.

      • You are being sarcastic but it helps to prevent the scenario the OP described. I would rather pay for my hardware/software with money than with my personal information. For some people, money is worth more than their personal information.

        I think Android and Windows users make compromises that threaten general privacy which, in the long run, threaten democracy because big data allows those who would manipulate the public a means to do so that outpaces most people's understanding of these practices. You criti

    • "User pushback generally prevented much f*ckwittery from program installers."

      Not a chance. There is very little push-back from users on "program installers" in regards to admin privileges. The default ask for admin perms has already trained people to readily grant admin permissions without any thought.

      Even installing a video game still asks for permissions most of the time. Microsoft has even developed an entire Servicing Stack around installations to further remove user say from installs.

      "And we'll acce

    • And, with the Chrome focus on turning the browser into the PC replacement, the same insidious trend is occurring. Let a website browse through all my files in the background?

      That is not how anything related to a browser as an OS works. Literally all access to the OS requires additional user interaction, a model that is far more secure that the traditional "an installed program can do pretty much anything" model of the past. It's kind of like adopting the mobile security model on the PC, on a per website/app basis, on a per function basis giving the user far more control than they ever had in the past.

      It's no Chrome focusing on turning the browser into a PC replacement, it's the

    • Re: (Score:2)

      by ceoyoyo ( 59147 )

      A long, long time ago, we used to make fun of users who clicked on any random executable someone sent them by e-mail.

      Now we've bypassed the click. We all just automatically run any random code a website decides to send us.

  • It is amazing how fast our phones are turning into devices with everything useful for spying businesses to monetize on the grave of our privacy.

  • Like other commentators, there are a few of these that I agree with (ie Network Information API, Geolocation Sensor, User Idle Detection, and maybe, Device Memory API) some that I think will hurt adoption of Apple devices in the future, or users moving from Safari to Chrome because the lack of connectivity hurts the user experience (Bluetooth, USB, NFC) and some which are WTF (I can't see my personal privacy being violated by battery level, ambient light level or magnetometer information).

    The problem with p

    • Re: (Score:3)

      by Malc ( 1751 )

      I can't think of any reason why I'd want to share any of these with a web site. If the website becomes unfunctional because of this, so be it, I will move on. If I really want something, I will use a compatible browser in a VM, leaving me securer by default most of the time.

    • Re: (Score:2)

      by PPH ( 736903 )

      Device Memory API

      I have 640K. Deal with it. Bill says it's all you'll need.

  • No no no, simply NO (Score:4, Informative)

    by TheDarkMaster ( 1292526 ) on Monday June 29, 2020 @12:16PM (#60242310)
    You should not give hardware access for a web page, period.

    • Re: (Score:2)

      by JMZero ( 449047 )

      That sounds great. To start off, I think we should remove Slashdot's access to your keyboard. If you don't like this response, maybe you should also remove its connection to your monitor.

      • Go back to humor school, because it was very clear that you failed miserably.

        • Re: (Score:2)

          by JMZero ( 449047 )

          It wasn't a joke. I was pointing out that perhaps you hadn't considered your comment before submitting it, and maybe you should slow down.

      • Re: (Score:2)

        by PPH ( 736903 )

        Slashdot's access to your keyboard

        Slashdot doesn't have access to my keyboard. My keyboard has access to Slashdot (in spite of the best efforts of all the users out there with mod points).

        • Re: (Score:2)

          by JMZero ( 449047 )

          Slashdot absolutely has access to your keyboard. For example, if you put your cursor in a comment box and start typing, Slashdot reads the keys you're pressing in order to record your comment. Regular javascript can read a variety of input from keyboard and mouse, some of which users might not expect.

          In any case, your normal keyboard interaction - eg. typing a comment - with Slashdot is fine, because you, as a user, understand it and can control it.

          Where privacy breaks down is where the user isn't given ch

          • Re: (Score:2)

            by PPH ( 736903 )

            if you put your cursor in a comment box and start typing, Slashdot reads the keys you're pressing in order to record your comment.

            Slashdot doesn't know whether that is my keyboard or I just cut and pasted text from another window. So I'll argue that Slashdot/Web Apps/Browsers don't have keyboard access. They receive keyboard input, mediated by several layers of operating system services and filters. If I move my cursor out of the web page focus, there is nothing that the page can do to regain it.

            • Re: (Score:2)

              by JMZero ( 449047 )

              [quote]Slashdot doesn't know whether that is my keyboard or I just cut and pasted text from another window.[/quote]

              Slashdot could distinguish these sorts of things if they wanted to - javascript gets fairly fine grained information about keyboard events. Of course, you could write a browser/extension to lie about key events/state, but you could also make a browser that lies about your magnetometer or whatever. It's true that there's several layers of abstraction and indirection between javascript and your

    • Re: (Score:1)

      by green1 ( 322787 )

      How did you post this without using your hardware keyboard?

    • You should not give hardware access for a web page, period.

      Of course you should. It just needs to be managed by an interfacce. Excuse any typos here I can't see what I'm doing because the webpage has no access to my graphics card and my browser is just showing a white screen.

  • The less coding apple does the better it is for ios stability, apple is terrible at writing software.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close