←back to thread

428 points coronadisaster | 3 comments | | HN request time: 0.158s | source
Show context
j-pb ◴[] No.23677662[source]
So basically everything that would allow web apps to become capable enough to provide a viable alternative to their App store.

If they really cared about privacy they'd auto-generate their new privacy labels based on a websites api access pattern, and put them in an easy to access place.

They should also simply ask the user for permission if a privacy critical api is being accessed, same as we do with the microphone and gps. Or if they want to prevent users from being bothered, they could make them opt in as others have pointed out. So you have to manually go to the privacy label, and select the stuff you want to allow.

I'd love to be able to plug midi devices into my phone. Implement pwa games that use local bluetooth connections for gameplay with friends in the train. Or be able to access my 3d printer from my phone without having to release a ridiculous App store app.

replies(2): >>23677767 #>>23678183 #
girst ◴[] No.23677767[source]
nearly all of those APIs are also considered 'harmful' by Mozilla[1]. Some have even been disabled after implementation because of this[2]. These were developed by Google for Chrome OS, and besides the privacy issues, they substantially increase attack surface for security vulnerabilities.

[1]: https://mozilla.github.io/standards-positions/

[2]: https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...

replies(1): >>23677812 #
j-pb ◴[] No.23677812[source]
Mozilla also killed WebSQL because the existing implementation was too mature...

I don't know what they're driven by, but it's not pragmatism.

replies(2): >>23677865 #>>23678381 #
sitkack ◴[] No.23678381{3}[source]
There is too much opinion in your statement.

Mozilla opposed it, rightfully so, in that it would dictate that SQLite be the implementation used everywhere. Mandating the inclusion of SQLite is not a spec.

As much as I like SQLite and looked forward to it being in 2/3 of browsers, Mozilla made the right call. The web should be implementable entirely by the specification.

Google likes to define the spec as the identity function of the implementation. Popeye specs, "I yam what I yam and dats all that I yam".

replies(3): >>23678572 #>>23679440 #>>23681816 #
j-pb ◴[] No.23678572{4}[source]
WebSQL would have been a spec, could have been a living spec too. Start out with SQLite in all the major browsers, and then gradually have them diverge. Blink and Webkit started the same way. Independent implementation does not mean "implementation of uncommon history".

But somehow "paving the cowpaths" doesn't apply to tech that they don't find attractive.

Similarly, and that is actually a statement loaded with opinion, I've seen way to many self proclaimed "spec hackers" at mozilla. People who relish in the joy of writing out ideas, I mean who doesn't love building castles in the skys, but who completely ditch the implementation. It doesn't matter if you have the most beautiful spec in the world if the implementations are shoddy, or if it specifies the wrong thing.

Web specs are the modern hackers "waterfall" design process. Sure everybody talks a lot, and there are many pretty documents that come out of it. But once you start implementing the stuff, you start to realise that all your assumptions were wrong, and now you've made a mess.

I think specs actually produce less diverse implementations. Because they are so easy to write, in comparison to code, and because writing them doesn't give you immediate feedback on when you've reached a good minimal feature set, it's almost inevitable that you end up with way more stuff than you actually need. There is a reason that there are essentially only 2 Multitrillion dollar companies that can keep up with that mess. And mozilla would have died long ago if google wasn't keeping them alive to avoid anti-trust investigations.

In all fairness Living Specs try to acknowledge this, but somehow we still collectively pretend that they are more than mere documentation, that by calling them a "specification" instead of "documentation" they somehow make the web run.

Specs don't run the web. Code does.

replies(4): >>23679256 #>>23679275 #>>23679316 #>>23679433 #
sitkack ◴[] No.23679433{5}[source]
There is a lot to unpack in your post, but I get the gist.

You are free to use SQLite on Wasm, in your browser, you break no one and no one breaks you.

Wasm was designed well from a spec and community perspective, Google matured and Mozilla matured and in the end all the browser vendors go together and designed something that lots of folks can implement w/o multimillion dollar development efforts.

You know, I have written web apps that use SQLite and Lua running in the browser. They shouldn't be included inside the browser and nor should browser vendors have to worry about it.

replies(1): >>23680087 #
1. j-pb ◴[] No.23680087{6}[source]
Well that's kind of a different argument. But one I can get well on board with.

We should kill JS, and EVERY WebSpec, except for WASM and WASI. Take the best parts of html and css and implement a virtual dom / immutable data driven document format for WASI.

Focus all our efforts on carving useful capabilities for WASI and end this web nightmare once and for all.

Not realistic, but a man can dream...

replies(1): >>23681891 #
2. sitkack ◴[] No.23681891[source]
It is realistic and at some point, one of the browsers will be a shell that runs Wasm and browser updates will just be Wasm.
replies(1): >>23682610 #
3. j-pb ◴[] No.23682610[source]
The birth and death of javascript