WebKit will not implement:
Ambient Light Sensor
Geolocation Sensor (background geolocation)
User Idle Detection
WebKit took the lazy way
"@webkit’s first line of defense against fingerprinting is to not implement web features which increase fingerprintability and offer no safe way to protect the user. Here are some examples of features we have decided to not implement […]:"—webkit.org/tracking-preve….
We definitely know it's the case. I guess WebKit can say it's our of their hands. The other questions is why aren't they participating in the standards discussion to add their concerns and ideas to the spec.
I Read the content of webkit.org/tracking-preve…
Had the exact same question... Everything can be used for fingerprinting. Why are those specifics any different in that regard ? And if there's a problem with those specs why not improve them to include fingerprinting avoidance ?
Any API you add is code to write. Bugs are inevitable. Not all will be discovered & mitigated in time by good people or software finding them or preventing exploits.
The only way to win is not to play at all.
But I doubt WebKit team won't change minds given Google's dominance.
Google Chrome, Microsoft Edge, and Samsung Internet AFAIK; yes, all based on the same codebase. That's why I said there are two webs now, two visions, two futures. That's bad for the web. Those APIs in particular are just an anecdote. The fork is much bigger looking forward.
My intent was to correct the person who said that Firefox already had these APIs. I hope the fork can be minimized. All the browsers have a strong interest in working together, even though we may have different values and incentives. Even if it doesn't look like it on Twitter.😆
As a dev in a EdTech company we have so many valid use cases I'd like to demonstrate. We don't want to ignore Webkit/Safari and we hope that Webkit doesn't want to ignore the educational reasons for these APIs.
Most of these things have a public issue. If you add a comment explaining your use case, it helps. Here's the one for Web Bluetooth. That said, in this case our concern is privacy and security more than lack of use cases. bugs.webkit.org/show_bug.cgi?i…
I def. don't want to waste both of our time if this isn't useful. I've seen mixed messages about the desire of wanting to find a security model that Apple is happy with. If Apple doesn't want to find a model that works, I guess we'll leave it there, as sad as that might be
I struggle to see how giving web apps access to bluetooth is less secure or good for privacy than for native apps. You can only allow it for installed web apps, and handle permissions just like native apps. Does it all come down to not being able to review the web app code?
Websites can exploit bugs in additional code, maybe w/o interaction. The exploit in API code doesn't even have to do with the API. But apps can do bad things only if downloaded.
Apple's App Store can revoke apps & forbids some forms of dynamic code, so less attack surface.
Of course, there's Safe Browsing by Google to protect you from some websites but this will only work if there's evidence to gather that a website is doing something nefarious. Websites are more ephemeral than apps. People are more likely to think twice before loading an app.
Well, if web apps could only access those APIs when installed, and if made clear to the user that by installing one it has more control over the device, I bet they'd also think twice before doing it. Add a system like Google Safe Browsing to revoke the right for a web app... 1/3
... But enabling the creation of powerful applications being able to run on any device with a single codebase is not in the interest of Apple, and this is the real reason it is not happening (yet) I believe. 3/3
App Store can’t detect most fingerprinting within apps, that’s not true. Yes, it’s part of the Terms and Conditions, but you know… Facebook, TikTok, they are still there up and running. AppStore doesn’t review source code.
The lazy way is not thinking how you can offer some features while keeping privacy. This is not API or privacy, that’s stupid thinking. We can do better. Anyway, it’s fine if they want to take that road, but users should have a choice. On iOS-iPadOS they don’t.
But "prompt the user" is even lazier, since for many of these apis, you can't expect informed consent from users - especially on the web where the code can change under you feet without user notice. So Apple (and Moz) don't work on a proper solution, and Google is option is YOLO
I agree it's on the lazy side to say prompt is good enough. But Moz and Apple could really help shape the APIs. To flat out say these are dangerous and they won't implement, esp from Apple who allows these APIs on their native apps without even prompting in some cases
On native the trust model is different: you install and run code that is signed by the OS vendor, and that's who you trust. Very different from the open web model, even with prompts. Prompts are only good when the consequences are clear for users.
I understand that trust model, but Apple is claiming they won't support due to fingerprinting concerns, why is fingerprinting not a concern in their native apps?
(we had a similar discussion before 😅)
Native apps have it because their distribution model is different: basically signed packages. That's why we built the same kind of apis for FirefoxOS (now used in KaiOS) with access gated to only signed code. Just opening to the web at large is problematic.
That doesn't prevent it from happening, just if they get caught. Users may want to choose to be in control of their own privacy, rather than trust Apple. Since the web is an open platform, vendors could work together to make APIs that allow this choice, without endless prompts.
Looks like no good solution has been found for things like WebUSB... I mean, it's cool that you can reflash an Android device from Chrome, but there is no way I would trust a random web site with that capability. And trusting an origin is not enough, since servers can be hacked.
That’s basically the premise of my question - I don’t know if there is a debate about whether the web even *should* be a universal app platform, or if it’s always just a debate about how it will get there.
(I ask because I don’t want my browser being a second OS)
Because I barely have control over who gets to run code on my devices, when I visit a website. Browsers have yet to show that they can be trusted with current APIs - just install an ad/tracking blocker and marvel at the number of things it will block, and wonder what it didn’t.
I've seen those concerns raised and they made sense early on. It appears they didn't come back to the table to re-engage with those that continued to work on the security model, but rather they just stuck with that original thought and didn't have any desire to try for a solution
I thought we talked fingerprinting, but ok: I would much rather grant specific, limited access to device X from trusted site Y than being required to install a random binary (with full system permissions) to e.g. bridge to a FitBit or do RGB on a keyboard
But these same people are installing binaries and allowing system wide permissions without understanding that's what they're doing. Which is why to me a security model that is specific and targeted makes it easier for less technical people to understand what they are allowing
Also, on OSX Safari, it seems extremely easy to get tricked to malware (maybe something about their slightly 'hidden' current download?) I had to help clean my wife's Mac *often* until I switched her to Chrome
which is why a permission model based on permission prompts is not applicable for these apis... If the users can't give informed consent, don't ask them questions. Find another way to secure the platform.
I can agree that permission prompts for some APIs is not the right approach and being able to just prompt when a user lands on a page like with push notifications is not the right approach pretty much ever 😒
Sorry...was actually thinking about my youngest who just recently finished kindergarten :D (who often click on whatever shiny button comes up in apps - to much frustration for the parents). My eldest is starting to connect MIDI and BLE units (so upgraded her to Android/Chrome)
If @Apple was serious about the fingerprinting, they would randomize pointer (and gesture) events - but those don't directly cannibalize the AppStore (and they might still claim they have valid patents here ;))
Sure, the two models are different. You don’t want the Web to be curated the way app stores are (no matter how imperfect and perhaps hypocritical that curation may be).
I’m not saying it doesn’t suck. But the security & privacy have to work.
WebUSB (and Serial API) is extremely valuable to enterprises moving from native solutions connecting to existing hardware in the field. I've helped a few. Besides a theoretical FUD article in Wired (I think it was), we have seen no issues.
Apple puts lots of resources in Safari, so I won't call them lazy. But I agree they can be more creative in finding compromises. For example only three values for the Battery API. Or time slots for sites using the Magnetometer, making fingerprinting much harder.
Lazy is not trying alternatives, or at least open it to discussion. Such as: you can enable features by origin, similar to an Origin Trial, so if you abuse them, control is taken out. If they can create their own CPU architecture they can find a solution if they want to.
The web platform directly competes with the app store (which they quality control and take a heavy % from). It makes sense for them to see mobile Safari as a content consumption app rather than a platform for native-like experiences.
Well you can use another browser I guess? And with iOS 14 you’ll even be able to set another one as default ¯\_(ツ)_/¯
The sad truth is that most people don’t care / don’t bother to inform about privacy so I’m a fan of apple „enforcing“ privacy measures to protect those users.
That's not true. On iOS and iPadOS 14 WebKit is the only engine supported. Firefox, Chrome and Edge there are just using the same WebKit engine. It's fine if Apple wants to ensure users for their software. The problem is.... No competition allowed
I wasn’t aware of that, thanks for the information! Then I guess it would be cool if Apple made some of the stuff that some people might need optional but „off“ by default in the engine. They can then leave it off in Safari and allow other browser devs to implement a toggle.
every source of user-specific data is a way to fingerprint that user.
Here's a way of using almost every API on that list in fingerprinting:
And if you disable some or all of them, that's another way of fingerprinting you \o/
Maybe they also should prevent us browsing the internet, that would be really protect our privacy... Not adding W3C features is lazy. It like a system administrator blocking all ports except 80 because of security.
Why not allow them only for PWAs that the user itself approved? What about push notifications? What they are saying is a lie, it's to protect the App Store. They killed the Flash Player for "web standards" and they are the only ones blocking them now.
I don't think apple has much incentive to want to do something that actually makes PWAs better (like this would!).
I think they just want the minimal implementation of PWAs for basic coverage use-cases, while always remaining behind native apps.
I think of it the other way around with Chrome being the new Internet Explorer, introducing new features that are supposed to make the experience better but at the expense of standards other browsers follow. I can’t use many websites because they support Chrome-only features.
That's reasonable too especially on desktop. I've just personally felt it more with Safari limiting me in the mobile Web-based AR space. Apple taking away things that once worked without warning hurt me at work.
It's like saying, don't want air pollution? Stop breathing.
Don't like Google? Stop using the internet.
It's virtually impossible, Pandora's box.
Talk for yourself. Knowing battery status can help some webapps not to turn on some features or warn the user before. You don't want websites to know that super private data from your device. Fine. Choose a browser or a setting. Choice and transparency is needed, not dictatorship
I'd rather not have a million features fingerprinting me in a browser, thank you very much. I don't want to have a popup for every single potentially piece of private data, geolocation and notifications are enough and I rarely want to enable it.
Which is fine. Who is criticizing what you want? No one is forcing anyone to enable or use an API. Do you want to browse with Lynx? you can do it. With Firefox and Tor, you can do it? Well... Actually not on iOS and that's the discussion about.
The thing though is making it an open standard, and therefore for every device, means features most users don't want to have to worry about, that can be used to fingerprint their devices now have to be toggled for any site that wants to use it.
How do you define which features most users want? BTW these are open standards. All of them started the discussion years ago. I didn't participate in the standards meetings but I've been told that Safari participates only on the ones they pick and they don't propose alternatives
just because they didn't drink the same coolaid they drink at Google HQ doesn't make them not participating
the modern web "standards" and complexity have gone the way of ietf and I'm not surprised it's getting push back
web was never designed to be a glue
Which is fine. They can choose what product they want to offer and compete. I'm perfectly fine with that. However, if a user wants to make a different choice on iOS or iPadOS, they can't. Users should have freedom to drink the same coolaid as Google if they want to.
That's great. I'm not against a pure private content only browser. On most platforms you can make a choice of what do you want as a browser. The problem on iOS at least is that you don't have a choice. That's the whole issue.
If you don't make it a default to block access or configure access, major privacy issues by default. Block access, what's the point of incorporating it in? If you make it a notification, then you're going to get a million more of those "X websites wants to know Y".
So the freedom of choice only works one way, only when it matches your desire 🤔 there are many ways to desire your choice of not loading GA on any website; no ways to desire other people's choices on iOS.
Supposedly, we have the choice to decline cookies on every website but the average user knows how hard it is to find the decline button.
It's really not a freedom of choice, it's more of a, "we will frustrate you till death until you click on that accept button."
tend to disagree with hdevalence pretty consistently but he does, in fact, speak directly for my own interests and feelings here as well. I do not want to empower the FAANGs to blowtorch these changes into open standards for the web
People need to do proper job and think about specific use-cases vs benefit and not just lazy-link naively changing hardware types, that just asks for blood.
it needs to be abstracted and granular, not wholesale either like either blanket Yes/No
I'd probably be fine with a site knowing if my battery level is above or below 50%, but I'm not fine with a site knowing my battery level down to the individual percent. I don't think any site needs that many extra bits of fingerprinting info.
Here's a novel solution...
WRITE A FUCKING PLATFORM-SPECIFIC APP.
Browsers do not need to replicate everything the platform can do, badly, with zero consideration for privacy, and with no way for the platform to say 'fuck you'.
Platform-specific apps give the user even less control: you can't block ads on them, you can't even do most of the basic UI stuff that browsers allow (storing in a tab, bookmarking a specific place, zooming or enforcing various preferences). xkcd.com/1174/ …
… However, there's an obvious compromise solution which would give the best of both worlds: platform-specific helper apps for browsers, which would request the platform permissions (but not the browser) and supply the web API on behalf of the browser via IPC. …
… BUT I imagine IPC between apps is completely shitty and it would be difficult for webkit to bundle things like geolocation into a separate platform app so as not to request the permission from the platform. So we end up with this entirely useless artificially created dilemma.
I emphatically agree, but sadly, saying that something “should not” exist doesn't make it go away: evil has this weird tendency of persisting to exist despite our best efforts to persuade it otherwise. 😑
I didn't say efforts to remove evil were inevitable! I said it's not enough to think it shouldn't exist for it to go away. Ad blockers are a way to get rid of ads: merely saying that ads shouldn't exist isn't. But maybe you had a specific effort in mind?
If your web app needs to look at battery level to determine features to keep enabled or disable, you need an app closer to the metal, not a web app. A web app would not be appropriate for this use case.
It bothers me how much this screams, "We know better than developers" and "users can't make decisions for themselves." Do I want a bunch more tracking? No. But this enables a ton of useful features DEPENDING on the site and application.
It's exactly what you think based on name:
That’s not from spec wicg.github.io/webusb
You can read
FileAPI also suffers from a similar vuln. Do you suggest FileAPI to be pulled as well? Or rather, you might argue, FileAPI is more useful than WebMIDI and therefore we don't need more point of exposures, esp. when those aren't as necessary?
The sheer number of permissions to grant or deny is by itself enough for a very unique fingerprint. Not to mention the huge attack surface provided by all those APIs. Each piece of code is a potential vulnerability waiting to be exploited.
Yes. I acknowledge this point. I stop at being disappointed and say that's understandable. I guess for web apps to use MIDI, users have to download something else to interface. And I really hope that people judge carefully where they download things from.
That I agree with, for mobile platforms. But what about desktop environments? I'm totally fine if there's a mismatch between mobile and desktop in terms of APIs enabled. It just seems safer for people to use MIDI through the web rather than have them download something malicious.
Once you have an API that is widely being used, you can't go back and withdraw or deprecate it easily. You can only try to fix all the bugs, as Adobe tried with Flash. Finally, it will be laid to rest, after decades of issues. This is the real win of the 2007 iPhone.
> @webkit took the right* way.
Web browsers were meant to be content consumption platforms. Their slow evolution into code execution platforms has been horrifying; that's what apps are for. The lack of a pure content browser for the web makes the web inherently unsafe.
By merely checking which permissions a user granted on all those APIs you can fingerprint them quite well. Of course you could give websites fake data but that makes things even more complicated. They have to make some sense to not be pointless, so bits of revealing info again.
There is no good reason for a web app to have access to any of these.
“Just make it a setting!”
It would have to default to OFF for all of these, since most users never change settings, or ask for every website (which would also be a nightmare)
That stuff is useless at best, incredibly harmful at worst. Web MIDI? Web NFC? Cmon, are we trying to turn each browser into something like FirefoxOS? If that’s the point, better to fork WebKit and create a separate OS out of web specs
That is so sad. @Apple must really consider it. Many of these features are implemented in @UnoPlatform for #WebAssembly, and it does not make sense to limit them like this. That's what user permissions are for, isn't it?
I don't think this is lazy. More likely to be strategic.
Apple make a lot of money from apps that they control and monetize through the AppStore.
Why on earth would they want to implement a standard that's explicitly designed to be open and not owned?
I'm in favour of these features, but I checked a few of the intents to implement/ship and it looks like Google noted "no signals", uncertain or even negative signals from other browser vendors at the time. Isn't it up to Google to make sure other vendors are on board beforehand?
I agree the WebKit line doesn't seem to add up - for instance Safari can already watch you through your camera, access media devices etc, and in practice it's all fine because of permission prompts and other mitigations. But on Google's side, I do wonder:
The Web has been forked.
We have two web platforms moving forward: the Chromium web and the rest, or the rest and the Chromium web. Both will probably claim to be the original one.
I can't pick one side. The fork is bad for the ecosystem, and it'll probably get worse with time.
Is funny see adult people agreeing with Apple thinking that Apple care for privacy.
Apple just don't want AppStore competition, that's why you can't even use another browser engine instead oldware Webkit.