Niels Leenheer

Thanks! I will definitely follow up on that 😄

Web Day Out next week in Brighton is going to happen. Booked my flight and have my ticket. Now for the hotel. Never been to any conference in Brighton before. Any hotel tips? Does anybody know where the speakers are staying?

I really was hoping the MacBook Neo was going to be the successor to the 12 inch MacBook, but I don’t think is for me.

I loved my MacBook. It was underpowered, but it was small and light enough to carry it with me at all times. That made it great.

But the Neo is the same weight as the Air.

I’m way too busy to attend Web Day Out. Have an in-person meeting on Wednesday evening at home and another call on Thursday afternoon. There is no way I can be in Brighton next week. No way. Impossi…

Okay. It seems I just bought a ticket.

That time when you ask Claude about something and it suggest that you use your own software... And recognises the similarly in name between you and the author... (no relation I assume!)

It got mentioned by @jason-williams.co.uk in his talk about Temporal 😄

AMS ✈️ LCY. And already landed. Literally 10 minutes from touchdown to DLR station. On my way to #SotB26.

Me without looking at the photo: is it Bramus?
Zooms in at photo… 😂

The web you want A two day conference about the web, with some time to think between the two days. April 17, 2026, and June 10, 2026.

🎤 Care about the future of the web?

The Web You Want is a free community event in Amsterdam on digital ethics, sustainability & accessibility.

Submit a talk or workshop by Feb 17 and help shape the conversation.

👉 the-web-you-want.org

Promotional banner for “Fronteers Dark Mode” with the headline “Friday night. Frontend. Fronteers Dark Mode!” in bold black text on a bright yellow speech-bubble shape. Below it, the text invites people to join on Friday, October 2nd 2026, at Cinema De Witt in Dordrecht for an intimate evening of frontend talks and community vibes from 3PM to after midnight. The background shows a lively evening courtyard scene outside a cinema, with people sitting at tables, chatting under warm string lights, and a modern glass entrance glowing in the night. Colorful decorative shapes frame the top corners of the image.

+++ Tickets are now on sale for Fronteers Dark Mode 2026! 🥳 +++

📍 Oct 2 · Cinema de Witt, Dordrecht
🕒 3PM – ~midnight
🎤 5 talks
🍽️ 2-course dinner included

Relaxed after-work vibes, long breaks & great conversations.

🎟️ €99
👉 fronteersconf.org

(Fronteers members: €49)

Current mood: Portishead

I'd love to be more helpful and discuss this and try to find a way forward. I've been thinking about this since 2017. I've talked to people from Apple about this on multiple occasions.

And I don't have a solution. But I don't think your proposal is helping either.

That is completely true. And they are right. Not having WebBluetooth is safer. But so is not having webcam support. And gamepad support and downloading binaries. But they do support that.

It is a balance between security and usefulness.

I think WebBluetooth is useful. They do not, apparently.

At the same time I also see standards position that either misunderstand the capabilities and privacy and security risks, or on the other hand seem to object on a more fundamental level.

Now on a fundamental level, that I can understand. Any feature you add, adds a new surface for vulnerabilities.

I also think that Chrome's approach has been solid so far. This technology has been available in ~75% of all browser for years without any known issues.

Now it is good to be critical and think about how it can be improved.

It's not that I think Chrome is right and WebKit/Mozilla are wrong.

But I have been working with these APIs since 2017 and have created numerous demos both on the web and device side, and implemented this in real world web apps. So I am intimately familiar with the capabilities and limitations.

So you need a blocklist in any case. You - and Mozilla - claim that is unsustainable. But the Chromium project has been doing that for the last 8 years.

And yes, what if a device has a hidden buffer overflow vulnerability. I counter that with what if does advertise it is a public device and still has a vulnerability. The same potential for a security issue still exist regardless what it advertises.

There is no fingerprinting concern. The example stated is not existing. Scanning devices has - for good reason - never been implemented.

And the security concern is overstated.

Devices are already designed to be public devices because that is how BLE works. The web is not special in that regard.

I did. I’m sorry, it is just not well thought out.

You are proposing to hide legacy devices. And for fictional modern devices allow the manufacturer to block third party websites from connecting to a device.

And the concerns in that document are misguided.

No. Having manufacturer opt-in is worse.

Because then the manufacturer can decide what users do with their devices. They can restrict to only their apps. And even worse, that restriction is turned on by default.

And worse. It will only hurt the web. It won't restrict any other platforms.

I think this is also moving to the wrong direction. Bluetooth is open by default. I don’t want it to be closed by default.

I don’t want manufacturers to decide whether I can connect to their device or not. It is my device. And I don’t want to be forced to use native apps to work around that.

Happy? No. But I also won’t be happy when I can’t use any existing devices.

A limited implementation that can’t connect to the devices I want isn’t any better than no implementation.

And besides that... Bluetooth devices already signal intent that you can connect to it. It already offers services. You don't need another flag for that.

There is no difference between a browser connecting to it or a native app. There is no special hardening that the device needs to do for the web.

Yeah...

I'm not sure this will convince Mozilla or Apple to spend their money on this.

Well.. they can't just add it.

Because both run software that may or may not be hardened to support WebBluetooth. It would be up to the individual author of the app that runs on it to add it...

So, yes it would make things more secure. It would make it so secure that nobody can use it to connect to any actual devices.

And if nobody uses it. Why implement it? Why spend the time, money to do this at all?

So I don't think going on this path will convince other browser to implement.

My main objection would be that it would make WebBluetooth completely unusable for the billions of existing devices, and probably most future devices, because there is zero incentive for makers to add this flag.

So for any browser it would be a waist of resource to implement WebBLE at all.

Yes, I fear that is the case as well.

And maybe there are some more fundamental objections to these kinds of capabilities. Be it security or something else. Tweaking the spec a little bit to move the balance slightly more to security and less functionality won't solve those objections.

But we cannot "fix" the reality that security or access control is done on the application or device level and not the protocol level. That is inherent to BLE. That is how 4.7 billion shipped devices already work.

That is just something that we have to accept.