Yeah, and the first thing I did this morning is to reenable it in order to access 5-year old cable modem. The "on-for-all" or off-for-all" feels kind of dangerous, it should be something I can enable for 192.168.. for example, and not for the whole world. As a matter of fact, for the local network it should be a default "on". IMHO, YMMV
Interesting MS<>Google partnership on the design front. Wish they had redesigned `<select multiple>` though. That's one component that really feels stuck a million years in the past
<select multiple> is in desperate need of a redesign. I made multi.js (https://github.com/fabianlindfors/multi.js) to fix this but hopefully browsers will take the matter into their own hands.
Native multi-selection is the worst. The fact that you have to hold down a modifier key to make multiple selections is a usability nightmare. I have rarely seen a person who knows how to use the native browser widget.
Even when you do know how to use it, it is just too easy to make a mistake. If there were 5 options already selected and you want to add a sixth, so you click it but you forgot to hold down the right key. Now the 5 previously selected options are gone with no way to get them back.
In general I like using native widgets because mobile browsers do a lot of work to make native widgets usable on phones, but <select multiple> is so bad on the desktop that I always replace it.
Depends on what you mean with an interaction. Technically it would be possible to stack write operations, so you could just keep a tag to a close proximity of the adapter, and keep writing messages one after another.
With the webnfc.app, you can only write a single NDEF message with single record of either URL or Text, during single interaction.
The NDEFWriter write()-method currently returns a promise which is resolved on a successful write operation and rejected on a failed write operation, so you would need to use async-await to be able to loop those writes like that. Here is a reference to the Web NFC API Write-operation: https://w3c.github.io/web-nfc/#writing-to-an-nfc-tag
The current OS permission models used by applications and drivers that interface with these peripherals are much less secure than those used by browsers.
I don't think you understand the comparison. Any native code that runs on your OS can do almost anything, like access your webcam. Code that runs in your browser can't do that unless you (the browser) grant the permission, or it finds a series of exploits.
If you are suggesting browsers shouldn't offer access to webcams etc at all, that would not make the world more secure because the web would just die and we'd all be back to running native code.
I'd say the opposite is true. With more powerful browsers, you are making web applications more powerful and remove the need for a desktop app.
Web apps, if built correctly, are probably more secure than desktop apps. Especially considering that you completely remove the need for user updates, since the website is updated by the developers.
Plus, webbrowsers implement a proper permissions model unlike native apps, especially on Android, used to do.
Sure, web browsers implement a proper permission model, but: the surface of a browser is enormous. Just the sheer magnitude of a modern browser gives me vertigo. Chrome has how many compilers? How much code to handle broken input?
Whereas most kernels are easy to understand (even relatively modern ones like seL4), also many parts of a browser are at the frontier of "applied CS".
If I were to build something relatively small today, I don't think I would feel safe if it had to run in a browser due to the enormous complexity of a browser. I just don't think it is possible to secure them fully.
Writing everything myself at least gives me a false sense of security in the sense that I at least believe I understand what is running :)
Okay, from a software engineering perspective you're 100% right. Browsers are a very complex system and they'll continue to grow. But try to see it from a user perspective.
You as a software developer know how your system works. You know what components you used, how to compile and install and how to secure.
Your average user (depending on the target audience) doesn't know anything like this. Most users are happy when their current installation works, they often don't want to update, without realizing that this comes with the cost of their security.
I feel like webapps are the easier way to keep users with no experience secure.
Curious if you're aware that mobile web usage dropped from 14% to 8% from 2014 to 2016[0]? And that according to Alex Russell[1], Google's internal telemetry has it well below 7% now. It seems to me that the opposite is true, that the irrelevance of the web on mobile will keep the web app versus mobile app division around essentially forever (web apps will be popular on desktop, and native apps on mobile). (Unless I was misunderstanding and you were saying, what's the difference? E.g., Facebook is Facebook, whether it's a web app or a native app.)
That's sort of proves my point. Many apps these days are just a web app with a launcher for your homescreen.
Lets say we have https://dynalist.io/. If you are going to open their web app in Safari and then open their iOS app - you will notice that UI is identical. Because it is the same UI! In one case you have to access it via a browser and the app is just the same frontend delivered to you as an iOS app.
PWA or something similar - is the future. Hence all those APIs in browsers.
The more features like this a browser has the less excuse manufacturers of connected devices have for relying on mobile apps.
We were moving too far into a world where anything connected required a mobile companion app that inherently has a lifespan because of how averse to legacy apps the mobile ecosystem is.
> What's fundamentally insecure about it? The permission model of the browser is better than that of desktop operating systems.
And yet, sites exfiltrate enormous amounts of behavioral information. Whereas with a desktop app, I can just put it in a sandbox without network access and I am 100% sure that no data gets uploaded to anyone.
I think we tend to focus too much on security as in whether some application can be exploited to get UID/ring 0 access (which is undeniably important) and not so much as in whether the application's creators can extract all kinds of personal information.
While unfettered access has larger consequences, it is a relatively rare occurrence, whereas unwanted extraction of personal/behavioral information happens continuously.
Who is this actually useful to though? These sorts of arguments get floated around all the time but the reality has been that digital privacy only draws attention when there's political capital like shaming a company that worked with the opposing party. The mainstream opinion, informed or not, has rapidly shifted towards the belief that after all these data breaches it's a lost cause because the information is already out there in triplicate. Hell, if someone genuinely wants to stalk Joe Random they can just pay give bucks to one of the many websites that compile and sell person searches.
On the other hand, people are scared of 'hackers', who are rarely presented accurately in media, taking control of their devices and spying on them or stealing whatever personal garbage is on their machine.
From that perspective there's almost zero reason to iterate in the direction you've suggested. Especially since, even if you got people to listen, they'll most likely just argue that if Microsoft, Google, Apple (who will probably keep doing their own thing) can't secure their data then no one can.
And from a company perspective this is similarly great, designing for a future where the OS is just a middle-man between the user and the browser means that you have more ability to wall out third parties and users who have problematic update needs/demands suddenly become much less problematic. Sure, the small fry will fight to prevent themselves from getting boxed out and succeed for a time. but you're a Megacorp who has bottomless resources to throw at development, you're looking at the long game. Eventually the cost to compete will simply be too high to be practical and when that happens you have a thoroughly cemented position in the future of the market and all it cost was forming a small alliance with other Megacorps.
Who else is there to object? China rolls their own way, Europe is trying a little but have yet to demonstrate the ability to overcome the obstacles that prevent them from being competitive, and when the American Fed does decide to take an interest it's for wildly exotic problem spaces (looking at you Ghidra and Tor).
The wall of text above TL;DR: "Just give up your privacy like everyone else and enjoy the web features you didn't ask for and you don't need." It's really not more that this.
> And yet, sites exfiltrate enormous amounts of behavioral information. Whereas with a desktop app, I can just put it in a sandbox without network access and I am 100% sure that no data gets uploaded to anyone.
I don't see how that has anything to do with the security of the platform itself. Sure, some desktop apps can be sandboxed. Others don't work without some form of network connection. It's up to the developers what to (not) do here.
> While unfettered access has larger consequences, it is a relatively rare occurrence, whereas unwanted extraction of personal/behavioral information happens continuously.
A website or web app can not access any personal information that you haven't entered into it or its "partners". If cross-site tracking is your concern, there are ways to mitigate that.
> Web is not inherently better for your privacy or security.
Nobody said that. The point I'm making is that it is not "fundamentally insecure and wrong", especially compared to native applications.
As for security, there's some nuance there, but legacy desktop applications that are exploited can certainly do more harm than anything running in a web sandbox.
Meh, only NDEF NFC protocol is supported. A little bit too restrictive. There are so many devices out there that could be configured from an authorised website but many of them use a proprietary binary tag format.
Hope they open it up a bit in the future. Just like they did with webUSB and webBT.
A. It unrelated but all of Google’s blog posts are unreadable on my iPhone. The text doesn’t appear, I just see the title. Hope it’s just me and google did t actually real safari compatibility.
> This version of Chrome removes TLS 1.0 and TLS 1.1. TLS (Transport Layer Security) is the protocol which secures HTTPS.