Convopage
See the entire conversation
WebKit will not implement:
Web Bluetooth
Web MIDI
Magnetometer
Web NFC
Device Memory
Network Information
Battery Status
Ambient Light Sensor
Proximity Sensor
WebHID
Serial API
Web USB
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….
Tracking Prevention in WebKit
WebKit has implemented tracking prevention technologies, spanning from 2003 with Safari 1.0 until today.
webkit.org
184 replies and sub-replies as of Jul 14 2020
So, if these features are present in native apps, are they not a risk there as well?
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 ?
Tracking Prevention in WebKit
WebKit has implemented tracking prevention technologies, spanning from 2003 with Safari 1.0 until today.
webkit.org
A Firefox person stated on the thread that they won't support these APIs either, for similar reasons. Even Chromium-base Brave removes a number of these APIs. It's Chrome that is the odd one out.
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.😆
I appreciate this response 😊. You've told me before that real world use cases are helpful for driving attention to APIs. What's the best way to summit use cases for the need of Web Bluetooth?
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…
More use cases could lead to more focus on finding a good solution, but we're not sure there is one.
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
If the security, privacy, and device independence concerns can be addressed, that would be great. I'm just pointing out that this is a hard problem.
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?
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
...to run on all Apple devices as soon as blacklisted, and you get something more secure than macOS where you can install apps from anywhere without Apple being able to revoke them. 2/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
No bc apple gains atleast 100 bugs/year for allowing your app in the store and for you to use these features, therefore it's safer. 😉
#LogicalConclusion :P
On a serious note: I'm aware that Apple reviews those apps and if necessary rejects them.
However it still is a bad excuse to just not support a more open web imo. 😕
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.
Although I would like the features, I'm glad there's a browser that takes privacy serious. What do you mean with taking the lazy way?
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 😅)
twitter.com/fabricedesre/s…
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.
Because the trust model of the app store (reviewed apps) makes it possible for Apple to kick out of the store apps that misbehave.
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.
Also for what it's worth both Apple and Mozilla helped work on these APIs and raised concerns as early as 2009.
Does anyone ever just say “stop wanting all these bad ideas” when people (mainly Google, AFAICT) propose hooking the web up to some new hardware thing it has no business being connected to?
I would not say the web has no business connecting to some hardware. It's about figuring out safe conditions to do it.
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)
There is that debate. It’s a difficult debate. No one has produced anything even remotely resembling a decisive argument either way in twenty years.
why does the web have no business in connecting to device hardware?
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
Honestly, I haven’t seen any recent indication that these APIs can be provided without fingerprinting. There was a permissions & consent workshop last year but it didn’t yield that much progress.
The app doesn't have random access to all kinds of USB connected hardware - you do realize that, right? Did you actually work with it or is this just theoretical fear?
I chaired the Device APIs WG, and before that the Web APIs WG. I’ve worked on this problem for Vodafone, Canon, Samsung.
I don’t know man, look it up maybe?
Fair enough, but why the fingerprinting fear from how WebUSB works then? The app has no access until granted (no random listing). Also, it only allows access to interfaces not grabbed by the system.
how does that guarantee that this will not damage your device?
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
People who understand what a binary or system permissions are are not the relevant constituency.
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
Granted, with an app store you have some general guarantee for security by the provider, I acknowledge that
Well...you should see some of the things I have to remove from my daughters' phones every week. How is TikTok still in the stores btw? ;)
Exactly, some guarantee. But people feel that Apple is keeping them safe just because they download an app from the store. This is just not true
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 😒
IMO, these discussions will just go around in circles until Apple allows other browsers on iOS. Then 'kindergarden' and 'pro' modes can be a choice.
What a condescending way to talk about users. What's next? The "stupid" vs "clever" modes?
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 ;))
It's just tough to hear Apple express this concern about fingerprinting but fingerprinting can be done within a native iOS application too, so it's not unique to the web APIs
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.
Web devs should never have been given the opportunity to see swipe gestures, let alone all this stuff
They don’t particularly want. I don’t think they’ve ever seen the web as too important.
Never been sure whether it’s vague disregard or commercially driven. I fear the latter.
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.
I wouldn't say that, Steve Jobs saw the web as very important - made a very direct point that Apple supports HTML5 - and touted it as a way to build apps.
WWDC 2010: Steve Jobs on the platforms
We support two platforms at Apple. Two. The first is HTML5, a fully-open, uncontrolled platform that is forged and defined by standards bodies. We fully supp...
youtube.com
Good find.
Do you think @tim_cook shares that view?
No idea, and quite frankly the last few years of Apple's decisions keeps pushing me back to Windows/Linux. I begrudgingly accepted a MacBook with my new employer but will insist on a PC next time.
And last few serious bugs I had to track down before a delivery of a new project, 3/4 of them were Safari bugs
there's no good reason for any of these features to exist at all
no alternatives or discussion will make any of them a good idea
Sure. Whatever you say seems to be the truth
Users don't know the permission they have granted, don't know they can list them, so don't expect them to revoke them.
My mom is nearly 80. She's a user.
Of course they have the choice, that’s one of the reasons they (I) choose iOS : preserve privacy. Otherwise there’s android
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
Can’t you write your own browser from scratch? Are we forced to use WebKit for browser Apps?
That's correct. developer.apple.com/app-store/revi… rule 2.5.6
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.
Cool, I'm on Android for the customizability, but I'm seriously thinking about buying an iphone now.
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:
gist.github.com/TomyLobo/07bf5…
And if you disable some or all of them, that's another way of fingerprinting you \o/
gist:07bf50526811a144fbb6908807d42b50
GitHub Gist: instantly share code, notes, and snippets.
gist.github.com
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.
Sensible thing would be to limit sensitive features to installed web apps. @getify yelled about this a while ago.
It's one solution. Privacy budget is another one. They are many. But just removing everything is kind of 🤷♂️
(sorry @getify I didn't mean 'yelled', that was either autocorrect or it being very early in the morn here in the UK)
That's why you have permissions on them 🤔
Webkit/Safari is the new Internet Explorer 6. Keeping us from doing all sorts of cool crossplatform stuff.
Wow that’s what I call a hot take.
Well, she ain't wrong!
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.
I didn’t even know mobile browsers could do AR, but that’s probably because I only use mobile Safari. 😁
Or maybe people could build native apps rather than the PWA garbage. Have no interest in the web as an operating system. If I could throw a switch and make the web go back to nearly static, I would.
You can. Just drop whatever browser garbage you are using and install Lynx. You'll be happy with it lynx.browser.org
None of this belongs in a webapp. This is the systemd-ification of the DOM.
good, websites don’t need to know my battery status or memory usage
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
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.
Users aren't running around crying because webapps can't access their battery status. Only webdevs are. Stop pretending to represent the users. We know this is about you.
I am talking for myself, this is what I want my browser to do.
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".
arguments about freedom of choice would be more compelling if web developers respected user choice — for instance, your website doesn’t let me choose whether I want to load Google Analytics or not.
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.
this is not the counterpoint you think it is lol
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
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/ …
App
(no description)
xkcd.com
Ads should not even exist in platform-specific apps. Next?
Thinking of evil things as inevitable and efforts to remove them as ultimately doomed is how they get through in the first place.
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.
Websites don’t need to run battery-impacting useless Javascript in my browser either. *no user* needs this.
Let’s be real, not even native apps do that most of the time, I don’t trust that a web dev at company X won’t just use it to track me.
Sounds like you should prob make a native app rather than a website.
Sure, so you're OK with native apps having that info but not web apps?
(Note: obtaining user consent is a given in both cases)
"Here, let me show you a list of features we wont implement, because it would mean our profitable walled garden will become less valuable"
“Darn! That means I have to actually learn and code for the platform itself instead of staying in my comfort zone!”
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.
Yeah definitely no on USB. That would be a nightmare.
Did you read the spec? It might not be what you think based on the name. The same with WebBluetooth
Oh ok. Nope I didn’t read anything 😂
It's exactly what you think based on name:
"WebUSB provides a way for websites to connect to users' USB devices. A web browser that implements WebUSB enables a web application to expose USB device services using JavaScript without the need to install any drivers"
That’s not from spec wicg.github.io/webusb
“WebUSB provides a way to safely expose USB device services to the web. (…) With this API hardware manufacturers will have the ability to build cross-platform JavaScript SDKs for their devices.”
You can read
Building a Device for WebUSB | Web Fundamentals | Google Developers
This article explains how to build a device to take full advantage of the WebUSB API.
developers.google.com
cvedetails.com/cve/CVE-2019-5…
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?
> @webkit took the right* way.
Ftfy.
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.
“Lazy way”
Orrrrrrrrrrr maybe, just maybe, there are legit privacy and security issues around most of these.
Also, Mozilla has taken a similar stance with several of these.
That's exactly the point. Privacy and security issues over accessing your Clipboard didn't take the same way
Async Clipboard API
Safari 13.1 adds support for the async Clipboard API.
webkit.org
From what I understand, Apple is planning to change this to restrict clipboard access and prompt users whenever an app or website requests access to it.
I wanna fingerprint my users I wanna fingerprint my users I wanna fingerprint my users!!!!
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)
The web should not be an end user applications platform.
It is called attack surface reduction.
Guess who’s too lazy to fork WebKit and implement these? You.
Guess who doesn't understand how iOS and Apple work? Come on. No? Nothing?
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
Permission prompts...
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?
Oh yes. That's how Web Bluetooth API works. Thanks god
When I upgraded to iOS 13 and opened a few store apps and got asked to enable Bluetooth, I was just like “ah so you were secretly tracking me!” and shut that shit off.
pretty bad, especially webusb, webbluetooth and midi.
These are key features for many web apps. I use the first two intensively for two projects.
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?
Sure. This problem is also Chrome's responsibility. I never said something different.
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:
Is there that much difference between unilaterally shipping a non-standard feature, and shipping a feature with a spec that nobody else is interested in?
I'd add I'm not trying to contradict your criticism of WebKit here, I just think it's worth keeping some balance in the discussion
You can't express everything in life in just one tweet 😉 twitter.com/firt/status/12…
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.
They were right about Flash though.
Interesting take of webkit and apple to not implement new native features
There are some caveats to using them currently as well. Faced these issues first-hand :)
Ahan do share the experience. Definitely native features are very new and web is just trying to adopt them!!