7 ms·

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 priva

by j-pb 6y ago

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.

girst 6y ago
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/ https://mozilla.github.io/standards-positions/ [2]: https://developer.mozilla.org/en-US/docs/Web/API/Battery_Status_API https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...
- j-pb 6y ago
  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.
  - girst 6y ago
    >because the existing implementation was too mature. That's not what I gathered from their official response to the deprecation[1]. But the major problem with WebSQL for Mozilla seems to be this: >We don’t think it is the right basis for an API exposed to general web content, not least of all because there isn’t a credible, widely accepted standard that subsets SQL in a useful way. Additionally, we don’t want changes to SQLite to affect the web later edit: and once again: security might have been a deciding factor, too[2]. [1]: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... [2]: https://news.ycombinator.com/item?id=18685296 https://news.ycombinator.com/item?id=18685296
    - j-pb 6y ago
      Yet years later there is still no good solution for that space and IndexedDB is a total clusterfuck. I'd be far more worried about the mess at the core of the web, css and rendering, than about exploitable bugs of SQLite. The fact that a RCE in SQLite is HN worthy is indicative of that. Browsers have tons of RCE that are fixed every year, but it happens silently because everybody is so numbed to it. The quoted argument is a copout of them. HTML is also a "Living Standard" a.k.a. we just implement whatever we feel like, and write it down once we feel like it has stabilised a bit. They could have done the same for SQL, but NoSQL was en vogue at the time so they pretended that SQL needs to somehow hold up to much higher standards than the usual mess they produce. SQLite is probably one of the few pieces of software that is actually trustworthy, unlike the dumpster fires of C++ and feel good essays, that we call browsers.
      - vertex-four 6y ago
        Web standards are meant to have multiple independent implementations. That’s pretty much the entire reason that Google pays for Firefox at this point. “Everyone should just use SQLite” is a slippery slope to “everyone should just use Blink”.
        j-pb 6y ago
        Blink is exactly a good example on why starting out with SQLite would have been a good idea. Blink is a fork of Webkit, an engine soo much better than the alternatives, that it almost over-night became the de-facto standard. Did webkit ruin the web? Eventually apple and google disagreed and blink was forked of off webkit. The same thing would have happened to SQLite as the foundation of a living WebSQL spec. It's ironic that Mozilla pushed IndexedDB through, yet they were among those too lazy to provide their own implementation. Instead they simply dump everything into SQLite, same strategy done by Apple. They left it to google to implement the only differing implementation based on LevelDB. But hey, it's totally important to have multiple independent implementations...
        vertex-four 6y ago
  - sitkack 6y ago
    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".
    - j-pb 6y ago
      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.
      - jandrese 6y ago
buran77 6y ago
I don't like that Apple has this tight-fisted control over the app store but I'd hate it even more if websites got the same freedoms as apps. For better or worse there is some sort of diligence being done when an app is accepted in the app store and there is a chance it gets booted out if it abuses power. There is no such mechanism for web sites. Once this is out there there's no taking it back, there's no reigning it in, we're stuck with it. Deprecating these APIs is harder than just not implementing them in the first place. Each of these APIs is sold as a life improving feature but put together you basically end up giving way too much access to any website. Because you know most users will not understand the problem and will just accept which is like sideloading APKs from random corners of the internet. And it's not their fault, you can't be literate in every field. Even as an expert you'd have a hard time deciding if a certain feature is used legitimately or the site will piggyback on it to screw you over. That's why you pay $1000 for a phone, so the manufacturer protects you from these risks.
- deleted 6y ago
  [deleted]
- jfkebwjsbx 6y ago
  I agree overall, but: > That's why you pay $1000 for a phone, so the manufacturer protects you from these risks. is wishful thinking. You pay 1000$ because that is what people is willing to pay.
  - buzzerbetrayed 6y ago
    > You pay 1000$ because that is what people is willing to pay. And they are willing to pay that, at least in part, because > the manufacturer protects you from these risks Not sure what point you're trying to make. Your logic is circular.
    - jfkebwjsbx 6y ago
      The average customer is not paying 1000$ for getting "protection from those risks", and it is that customer that drives the price, not the average user in HN. And that is assuming they are trying to "protect you", but that is a different discussion.

by j-pb 6y ago

girst 6y ago

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/ https://mozilla.github.io/standards-positions/ [2]: https://developer.mozilla.org/en-US/docs/Web/API/Battery_Status_API https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...

j-pb 6y ago
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.
- girst 6y ago
  >because the existing implementation was too mature. That's not what I gathered from their official response to the deprecation[1]. But the major problem with WebSQL for Mozilla seems to be this: >We don’t think it is the right basis for an API exposed to general web content, not least of all because there isn’t a credible, widely accepted standard that subsets SQL in a useful way. Additionally, we don’t want changes to SQLite to affect the web later edit: and once again: security might have been a deciding factor, too[2]. [1]: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... [2]: https://news.ycombinator.com/item?id=18685296 https://news.ycombinator.com/item?id=18685296
  - j-pb 6y ago
    Yet years later there is still no good solution for that space and IndexedDB is a total clusterfuck. I'd be far more worried about the mess at the core of the web, css and rendering, than about exploitable bugs of SQLite. The fact that a RCE in SQLite is HN worthy is indicative of that. Browsers have tons of RCE that are fixed every year, but it happens silently because everybody is so numbed to it. The quoted argument is a copout of them. HTML is also a "Living Standard" a.k.a. we just implement whatever we feel like, and write it down once we feel like it has stabilised a bit. They could have done the same for SQL, but NoSQL was en vogue at the time so they pretended that SQL needs to somehow hold up to much higher standards than the usual mess they produce. SQLite is probably one of the few pieces of software that is actually trustworthy, unlike the dumpster fires of C++ and feel good essays, that we call browsers.
    - vertex-four 6y ago
      Web standards are meant to have multiple independent implementations. That’s pretty much the entire reason that Google pays for Firefox at this point. “Everyone should just use SQLite” is a slippery slope to “everyone should just use Blink”.
      - j-pb 6y ago
        Blink is exactly a good example on why starting out with SQLite would have been a good idea. Blink is a fork of Webkit, an engine soo much better than the alternatives, that it almost over-night became the de-facto standard. Did webkit ruin the web? Eventually apple and google disagreed and blink was forked of off webkit. The same thing would have happened to SQLite as the foundation of a living WebSQL spec. It's ironic that Mozilla pushed IndexedDB through, yet they were among those too lazy to provide their own implementation. Instead they simply dump everything into SQLite, same strategy done by Apple. They left it to google to implement the only differing implementation based on LevelDB. But hey, it's totally important to have multiple independent implementations...
        vertex-four 6y ago
- sitkack 6y ago
  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".
  - j-pb 6y ago
    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.
    - jandrese 6y ago

buran77 6y ago

I don't like that Apple has this tight-fisted control over the app store but I'd hate it even more if websites got the same freedoms as apps. For better or worse there is some sort of diligence being done when an app is accepted in the app store and there is a chance it gets booted out if it abuses power. There is no such mechanism for web sites. Once this is out there there's no taking it back, there's no reigning it in, we're stuck with it. Deprecating these APIs is harder than just not implementing them in the first place. Each of these APIs is sold as a life improving feature but put together you basically end up giving way too much access to any website. Because you know most users will not understand the problem and will just accept which is like sideloading APKs from random corners of the internet. And it's not their fault, you can't be literate in every field. Even as an expert you'd have a hard time deciding if a certain feature is used legitimately or the site will piggyback on it to screw you over. That's why you pay $1000 for a phone, so the manufacturer protects you from these risks.

deleted 6y ago
[deleted]
jfkebwjsbx 6y ago
I agree overall, but: > That's why you pay $1000 for a phone, so the manufacturer protects you from these risks. is wishful thinking. You pay 1000$ because that is what people is willing to pay.
- buzzerbetrayed 6y ago
  > You pay 1000$ because that is what people is willing to pay. And they are willing to pay that, at least in part, because > the manufacturer protects you from these risks Not sure what point you're trying to make. Your logic is circular.
  - jfkebwjsbx 6y ago
    The average customer is not paying 1000$ for getting "protection from those risks", and it is that customer that drives the price, not the average user in HN. And that is assuming they are trying to "protect you", but that is a different discussion.