[HN Gopher] Apple declined to implement 16 Web APIs in Safari du...
___________________________________________________________________
Apple declined to implement 16 Web APIs in Safari due to privacy
concerns
Author : coronadisaster
Score : 330 points
Date : 2020-06-29 10:16 UTC (12 hours ago)
(HTM) web link (www.zdnet.com)
(TXT) w3m dump (www.zdnet.com)
| dheerendra73 wrote:
| Lot of people on this thread are saying that put these behind
| permissions and call it a day! You people don't understand that
| not everyone is tech savvy and understand permissions well. My
| dad keeps giving on permissions on any website asking on his
| Android device as he just wants to get rid of them.
|
| Think about how many websites you visit and how many apps you
| install. I bet second number is way smaller than first one. When
| installing apps - you put some trust into app and lot of non tech
| people understand same (thankfully taught by antiviruses to not
| install random thing). People are not willing to install lot of
| apps but always willing to visit websites to "check it out".
|
| Privacy fundamentally limits UX and there is direct trade-off. I
| believe Apple is doing right thing to protect privacy of millions
| of non tech people.
| larme wrote:
| So many web developers keep pushing to give web the same power as
| native apps. "What's the difference between a PWA and native app?
| Why web cannot access the same api?"
|
| So I want to ask another question: "What's the difference among
| knives, guns and missiles. Why almost everyone can buy a knife,
| but need a license to buy a gun, and may never able to buy a
| missile (even with enough funds)". One possible (and obvious
| )answer is because guns and missiles are more powerful than
| knives, we want to give them more restrictions.
|
| Now can we reverse the logic and say, if we are able to decide
| the power of items, we should give items with less restriction
| less power? Let's limit our discussion on a mobile device, it's
| very easy to visit a website. But if you want to use a native
| app, you need to go to the app store, tap the download button,
| confirm, wait until the download is finished and the app is
| installed, and then finally open it. The app was also reviewed by
| the app store beforehand. This makes a difference. In fact, I
| think the ubiquity of web means we should never allow it to have
| the same power of what an native app can have.
|
| And people are talking about the monopoly of apple. But if web
| become THE operating system one day, google will be a more
| dominant monopoly. They control both the implementation of the os
| (chrome) and the entry (search engine).
| Lio wrote:
| I'm sad that this is necessary.
|
| Most comments here seem to of the "Good no one should write a web
| page that accesses bluetooth and I don't care if you want to do
| that".
|
| This is sad for me because I would like to be able to write web
| pages that talk to smart turbo trainers and other health devices.
|
| Now you might say why not write a app to do that but personally I
| prefer accessing stuff from web pages.
|
| I find apps restrictive as a user. For example there is no way to
| block ads in an app and often no way to zoom or select text.
|
| Again you might be fine with that but I just wanted to offer an
| alternative opinion.
| jfkebwjsbx wrote:
| > ... web pages that talk to ... health devices ... there is no
| way to block ads in an app
|
| Wait, what?? Why on earth would you use _an app with ads for
| health devices_?!?
|
| Moreover, why on earth are you using apps with ads for
| _anything_?
|
| Please, please, please, pay for your apps and games. Stop
| making everything an ad service. The race to the bottom in the
| web and mobile world is disturbing.
|
| Would you want to pay for your house plumbing by being forced
| to watch an ad every time you shower? Think about how dystopian
| that sounds. There are even Black Mirror episodes on that.
| hvis wrote:
| > Wait, what?? Why on earth would you use an app with ads for
| health devices?!?
|
| GP said they want to _write_ a web app that talks to health
| devices. And that they like the web platform because it's
| easy to block ads shown to you by other web apps.
|
| I will add that it's also easier to detect/block tracking.
| Browsers such as Firefox even try to do this for you these
| days. And to generally examine what the app is doing (e.g. by
| running it in JS debugger).
|
| Yes, paid apps usually (but not always) remove ads. They keep
| the telemetry, though.
| Lio wrote:
| > ... web pages that talk to ... health devices ... there is
| no way to block ads in an app
|
| You've selectively mixed two paragraphs to change the meaning
| of what I actually said.
|
| I did not say I want to use apps with ads with health
| devices, at all. That's a complete straw man.
|
| I said I want to access my own sports equipment via Bluetooth
| from a webpage I've written myself.
|
| I also said that I dislike apps because the user looses
| control over things like tracking, selecting text, zooming
| and whether adverts are shown.
| zerocrates wrote:
| On the privacy end of things, ads certainly aren't helping,
| but a pretty large number of even paid apps are happily
| vacuuming up data and sending them to the developer and often
| third parties (vendors of analytics/debugging platforms in
| particular). I tend to think of an app for most things as a
| _loss_ of privacy and try to avoid using them when possible.
| jfkebwjsbx wrote:
| > a pretty large number of even paid apps are happily
| vacuuming up data and sending them to the developer and
| often third parties
|
| Please name some examples. I certainly do not have not use
| nor know about any paid software that "vacuums" my actual
| data or tries to track me.
|
| > analytics/debugging platforms
|
| You cannot compare anonymous, aggregate details about
| overall usage of an app or crash stacktraces (which is what
| most paid/OSS apps do) to the kind of identification webs
| do for ads.
|
| Again: native apps do not care about showing personalized
| ads to you nor their business depends on it.
|
| > I tend to think of an app for most things as a loss of
| privacy
|
| Mobile apps from vendors like Facebook definitely. Normal
| paid/OSS desktop software, no.
| ricardobeat wrote:
| There are many apps that continue to show ads even in their
| paid version / upgrade. Might not be an option for him?
| jfkebwjsbx wrote:
| I would seriously consider any alternative vendor or simply
| living without the app. No serious health device will show
| you ads of any kind in their software.
|
| There is a modern overreliance on apps for everything these
| days.
| ryandrake wrote:
| I think it's about user expectations. As a user, when I'm
| browsing the web, I expect to be reading primarily text, with a
| hyperlink here and there, maybe some images. If I need to
| interact with the web site, I expect to see text input fields,
| a "submit" button of some sort, etc. When I click on a link and
| browse to another web page, I expect to see something similar:
| Hypertext, images, maybe a form field or two. I don't expect to
| have a peripheral attached to my computer get its firmware
| updated.
|
| The APIs listed in the article are so far outside what I would
| expect to be a HTML browser's business. It's ridiculous. If I
| want to do any of these, I'll install an application to do
| them.
|
| Installing an application is a nice speed bump. It's a
| deliberate action that the user has to take and think about.
| When I hand over my root password to my installer, or when my
| operating system asks me, "Do you really want to install this
| application?" it gives me the opportunity to pause and reflect
| on what I'm doing here. Who is the company behind this
| application? What access to my life am I giving it? Am I OK
| with running this application on my _personal_ computer?
| Sometimes, after reflection, I hit cancel and get rid of the
| installer.
|
| This whole contemplative speed bump goes away when rando web
| site written by rando developer, getting paid by collecting
| who-knows-what can suddenly do a Bluetooth scan or talk USB to
| one of my devices, merely by my issuing a GET request.
| remus wrote:
| I think this is a pretty narrow vision of what the web can
| be. For example, text + hyperlinks excludes things like
| google maps and youtube, which are quite literally world
| changing pieces of technology.
|
| For sure there is a balance to be struck in terms of how much
| access we allow other people to our phones and computers, but
| let's not kill off whole classes of novel applications before
| they've even had a chance to be built.
| Nursie wrote:
| No, let's do that. Please.
|
| Web sites have no business looking at my devices, nor using
| other APIs (I was disappointed not to see the page
| visibility API on the linked page too).
|
| If you want a dynamic app delivery framework, perhaps it's
| time we find a way to do that which doesn't massively
| overload what many expect is just an informational service.
| dancemethis wrote:
| Cute how Apple wants to make their "users" believe they have an
| exclusive deal on breaching their privacy.
| threeseed wrote:
| What possible motivation would Apple have for doing this.
|
| They aren't an advertising company and they make money from
| selling hardware not from selling data.
| cromwellian wrote:
| Apple has been increasing displaying rent seeking behavior
| more and more recently. They're not just trying to make money
| from HW.
| kennydude wrote:
| And yet there's still no reason why they won't add Web
| Notifications to iOS Safari.
| raxxorrax wrote:
| Really good move from Apple. Normally I don't see problems, but
| until we regulate ad tech, properties from this will be used for
| fingerprinting.
| dathinab wrote:
| They surly can be used for fingerprinting, but they also can be
| guarded with requiring user opt in permission, one which maybe
| clearly informs the user how the API can be abused and warm them
| to only s allow it if they know what they are doing. Which is
| fine given that most usage are for more advanced use-cases.
| (Through some come from the Firefox OS use-case and might be
| better if not to be implemented as close to all current usage
| would be abuse, e.g. the proximity API).
| tekstar wrote:
| Ubiquitous web midi support would enable a new and better round
| of patch management and sharing collaboration around music
| hardware. It's a shame it won't come to safari. For example see
| elk-herd for managing the Elektron digitakt.
| systemvoltage wrote:
| IMO we need to stop giving more permissions to browsers.
| Everytime I install a new browser (I am intentionally not taking
| sides about _which_ browser), the first thing I do is disable
| notification, microphone access, webcam, and location access.
|
| All applications that want to interact with system level hardware
| needs to go through the system vendor. Get proper driver cert,
| developer account with their physical company address.
|
| I have a special distaste for plugins, extensions, PWAs, and even
| <canvas> tag. Browsers ditched system UI and favor of CSS driven
| UI elements which created the soup of unimaginable mess,
| inconsistency and lack of quality of UI in the browser. And this
| is just UI, the level of scrutiny given to a browser extention is
| insanely passive. Extensions get bought and sold like a hot
| commodity and no one bats an eye.
|
| I can't use a system level blocker (such a Little Snitch) to stop
| an extension from communicating to the internet without blocking
| the browser itself rendering it useless. I need to resort to a
| horrifying mess of blocklists and a Raspberry pi hoping to catch
| one of these domains in its hole.
|
| I personally want a browser to display HTML, may be some
| interaction with the DOM to help out (check all boxes using
| jQuery for example) and that's all. I don't want anything more.
| cromwellian wrote:
| Prior to canvas, you had Flash and server-side rendered round-
| tripped graphs. You really think this was better?
|
| Browsers bring friction-free exploration, literally "surfing".
| Hit the back button, or clear all your caches, and you're done,
| but otherwise, it's fire and forget.
|
| The installable App model creates "shit work". Everytime I
| install something, it permanently takes up both screen real
| estate, and storage, and creates a cleanup task for me to
| delete it at a later date. Steve Jobs said "don't give your
| users shit work", well, app install and uninstall is shit work.
|
| I don't want to install stuff, I want to use stuff and get work
| done, and want things to go away if I don't want them without
| having to become a System Janitor.
|
| You complain about notification janitor work, which is fair,
| but native apps have the same problem, my iphone is deluded
| with notification spam.
|
| The whole app model is a complete reversal of decades of
| movement to thinner clients, back to the Windows model.
|
| Every time I go to a new restaurant, a new milk tea place, a
| new airport, or a new airline, they're asking me to install
| their native app. How many god damned
| United/American/SFO/InAndOut/FiveGuys/Chipotle/Starbucks/et al
| apps do I need on my device?
|
| And no, "Instant Apps" are a worse solution to this. Why do I
| need to download a friggin 5mb iOS executable, even if it isn't
| perma-installed, just to display a form with 4 boxes on it to
| pay for a parking meter.
|
| Form-filling is literally the use case for SGML from the
| beginning.
|
| No, we don't need a native-locked-down-walled garden for every
| physical point of sale in the real world. And since Apple will
| never own 100% of the market, this means developers will end up
| needing to write, x2, silly little point of sale apps which
| clog up people's phones.
|
| Ephemerality, transparency, portability, are desirable
| properties in addition to security and privacy. Apple leans too
| much on the latter at the expense of the former with relatively
| dubious justifications that could be fixed with better design,
| instead of refusing to participate in improving the specs to
| meet the desired properties.
| murermader wrote:
| Maybe thats all you need from the browser. But I am happy that
| the browser can do all that stuff.
|
| I can use BigBlueButton to participate in lectures, talk, share
| my webcam, even my screen. And why I should I care, if I can at
| any time, revoke that permission?
|
| I use many web apps, which are incredibly sophisticated, from
| TickTick for todo lists, to LucidChart for creating diagrams,
| to google docs do collaborate on documents, to notion for
| creating documentation. I could go on for days.
|
| I am happy, that the browser is as feature packed as it is,
| because it allows for so many wonderful apps, that wouldn't
| have been made otherwise, if they had to be made with any other
| technology, that is not as easy to develop cross platform
| applications for.
| youngtaff wrote:
| At least one of the API's listed (requestIdleCallback) is
| available behind the Experimental Features switch in Safari on
| iOS13.5
|
| Apple seem to take a more cautious approach but it would be good
| to see some more of those API's available in Safari
|
| We don't need a battery API but understanding whether a device is
| in low power mode would be useful
| nnx wrote:
| The listed "Idle Detection" is a different spec that is way
| more invasive than requestIdleCallback (which seems on track to
| be deployed more generally in Safari).
|
| It's about detecting user idleness, including in the case the
| user has another tab active, not a way to queue and coalesce
| bits of work at an "idle" moment to optimise for latency and
| battery life.
|
| The Idle Detection spec at https://github.com/WICG/idle-
| detection says it itself:
|
| "As opposed to the requestIdleCallback, this is not about
| asynchronously scheduling work when the system is idle."
| johnhenry wrote:
| I'm really excited about the new permissions model that Apple
| is using. Perhaps in time -- after some testing -- they will
| gradually enable these APIs, as they are quite useful.
| thayne wrote:
| There may be some legitimate fingerprinting concenrs. But given
| the list of API's it's hard not to see this as Apple crippling
| PWAs to prevent them from replacing native iOS apps (and hurting
| Apple's revenue from the Apple tax).
|
| And maybe I'm missing something, but wouldn't the fingerprinting
| concern be mitigated by the fact the app has to ask for
| permission before using the API? If an app that doesn't have to
| do with MIDI asks for permission to use my MIDI device, I'm going
| to be instantly suspicious.
| Joeri wrote:
| I don't even want these 16 api's. I want a way to do
| notifications and a way to store more than 50 mb on ios. Sure,
| make me and the user jump through hoops to make sure I'm not
| abusive, but with those two there are a ton of apps which I can
| build as pwa's.
|
| The app clips feature they showed? That should have been a qr
| code triggered pwa with notifications, except everybody had to
| build it as an app because they couldn't do notifications, and
| then apple used the cumbersome nature of those apps as the
| reason for app clips. It's the snake eating its own tail, and
| I'm getting IE6 vibes because microsoft also strategically
| stopped improving IE for web apps because they wanted to push
| app developers to native because of the improved user
| experience. Yeah, the web is worse, but worse is better.
| larme wrote:
| I'm very glad a web page cannot store 50mb data and send
| notification to me.
|
| You only think from a developer's perspective. What if you
| are the user receiving 50 notification requirement a day from
| a web browser?
| [deleted]
| untog wrote:
| What if you are a user receiving 50 notifications a day
| from an app? You block them. Same with the web app.
|
| People have very strict mental models of what "the web" and
| "native" should do but they're not actually based on
| anything. There's no actual reason why a web app sending
| you notifications (which it has to prompt for permission to
| do) is different to an app doing it. From the non developer
| perspective the divide makes no sense.
|
| Not to mention the privacy argument by Apple feels
| disingenuous. The reason people are so outraged by tracking
| on the web is because they know it's happening. Meanwhile
| native apps include bundles from Facebook to implement sign
| in with Facebook and it does whatever it wants. But because
| you can't inspect and check no one talks about it.
| danudey wrote:
| Then you tap on the notification and say "turn off" and
| then it stops happening.
| chvid wrote:
| Exactly. This is about making sure web apps are not as powerful
| as native apps.
|
| One thing is the revenue generated by the App Store but suppose
| JavaScript web apps were just as powerful and well integrated
| as native apps; then why use native apps at all? Why have an
| App Store at all? Why have a Mac or an iPhone if any device
| with a modern web browser would do?
|
| When Huawei tried to create their alternative to Android. The
| big thing missing wasn't the hardware or the operation system.
| It was the App Store with your map app, your banking app, your
| scooter app and so on.
|
| The App Store and the proprietary development platforms for
| Android and Apple has become a way to keep their duopoly in
| place.
| mavhc wrote:
| Isn't Google the one implementing all these APIs though?
| thayne wrote:
| But for google, the benefits of having richer web apps on
| which they can show you ads and have app developers pay
| google for ads may be more valuable than any revenue they
| lose from the app store.
| cthaeh wrote:
| Or, google isn't as anti-competitive and anti consumer as
| apple. what a shocker.
| suyash wrote:
| PWA's have always lagged behind Native Capabilities, even when
| API's exist the performance has been poor for high performance
| apps so the comparison doesn't quite make sense to me.
| suyash wrote:
| PWA's have always lagged behind Native Capabilities, even when
| API's exist the performance has been poor for high performance
| apps so the allegation doesn't quite make sense to me.
| kyranjamie wrote:
| Almost certainly an excuse to further suppress PWAs.
| osrec wrote:
| Despite this, I believe PWAs will eventually win, and Apple
| will be forced to comply if they wish to stay relevant.
|
| Their browser share dropped a little recently
| (https://gs.statcounter.com/browser-market-share). If that
| continues, it'll certainly irk them!
| exacube wrote:
| Consider that browser share usage could shift around as
| device usage shifts around during a pandemic.
| osrec wrote:
| I don't disagree, but would you expect such a significant
| drop in Safari usage?
| tuxone wrote:
| Are you all serious about this ask for permission thing? Good
| luck explaining MIDI, HID, NFC and so on to the average Joe, in
| a small popup. We already have enough "I agree" buttons popping
| over the screen. Web should be built for everybody, it's not
| the nineties anymore.
| MatekCopatek wrote:
| Sure, but Apple could solve that by requiring a user action
| to show that popup dialog. Or they could even block
| everything by default and force you to give permissions
| manually. That way average Joe is blisfully unaware of
| anything and completely safe while you just have to suffer a
| minor inconvenience of whitelisting that one legit website
| the first time you use it.
| danudey wrote:
| Do you honestly think that Apple would lose enough money by
| implementing Web MIDI for Safari on iOS that this would be even
| the most remote consideration? Like, the Safari team was in a
| meeting about Web MIDI and some manager said "but think of the
| impact on our stock options!" and they all went "oooooh" and
| scrapped it?
|
| Or is it that Tim Cook was looking at Apple's balance sheet and
| decided that they couldn't afford to lose the 30% cut of all
| the MIDI-capable iOS/iPadOS apps that could be completely
| replaced by a web app?
|
| The reality is that the real cost of this feature to them would
| be developer time; it would be a colossal waste of their
| limited WebKit/Safari developer resources to implement Web MIDI
| rather than something that would actually be used by more than
| a scant sliver of a percentage of Safari users.
| bartread wrote:
| > If an app that doesn't have to do with MIDI asks for
| permission to use my MIDI device, I'm going to be instantly
| suspicious.
|
| Sure, _you 'll_ be suspicious, but I seriously doubt you're the
| average user. I bet a very large proportion of Safari users
| have no idea what a MIDI device is and some significant portion
| of them wouldn't think twice about granting those permissions.
| mavhc wrote:
| I'd assume the small percentage with a midi device who are
| going to music app websites would be more likely to know
| mynameisvlad wrote:
| Anyone can request MIDI permissions.
|
| The parent comment implies a bad actor using the API for
| something like fingerprinting, and a common user who may
| have never even heard of MIDI, let alone have a device.
| keriati1 wrote:
| Yep, seems like apple made another move against the web.
| whalesalad wrote:
| Safari has been my primary browser for a few years now. Nothing
| beats the performance on macOS and no other tech giant is going
| to respect and fight for your privacy the way Apple does.
| jamesgeck0 wrote:
| > Web MIDI API - Allows websites to enumerate, manipulate and
| access MIDI devices.
|
| This API is actually a bit horrifying from a security
| perspective. In addition to allowing you to use MIDI keyboards as
| input devices on websites, it also allows websites to send binary
| firmware updates to MIDI devices. The reason is that it's common
| to use custom firmware to backup/restore settings and enable neat
| effects and functionality on MIDI devices.
|
| Mozilla's engineers have reasonably pointed out that an attacker
| utilizing Web MIDI could use MIDI devices as a stepping stone to
| launch an attack against the user's PC outside of the web
| sandbox. One such attack might be by reprogramming the device to
| appear as a standard USB computer keyboard and "typing" commands
| to the host.
|
| At least one well known manufacturer has vouched for the
| technical safety of their musical instruments, noting that
| they're physically designed in such a way that the MIDI firmware
| can't alter USB firmware. But there's no way to know that every
| MIDI device has been similarly well designed.
|
| As neat as Web MIDI is, I think Mozilla and Apple probably made
| the right security call here.
|
| https://github.com/mozilla/standards-positions/issues/58
| grawprog wrote:
| I'm curious now that I read this, this means that web midi can
| access the virtual midi devices created under alsa on linux
| also? Which means if you have it routed to other software using
| Jack or aconnect, websites could send midi notes directly into
| whatever software your midi device is routed through?
|
| So theoretically then, could a Jack aware payload be created
| that runs in the background, say disguised as a vst or ladspa
| plugin and when a user browses a malicious site, this site
| could, recognize the malicious midi device, create connections
| to other software and gain access through possible buffer
| overflows or other things?
|
| It seems like a stream of midi notes could itself possibly
| cause a buffer overflow in certain programs. Muse and
| rosegarden are a bit buggy as is and frequently crash for me.
| From what i can tell there's a lot of midi aware audio software
| that likely contains a bunch of avenues for exploits and when
| you throw virtual midi devices into the mix capable of doing
| far more than hardware midi devices...
| cocoggu wrote:
| It's still possible to partially implement it while keeping it
| safe by excluding sysex messages. Probably more than 90% of the
| end users will never need sysex messages so why bother?
| jjtheblunt wrote:
| > so why bother?
|
| maybe 10% is enticing for those who create botnets
| dkersten wrote:
| I'm pretty sure GP meant why bother implementing sysex
| messages.
|
| Personally, I think that's the solution. Provide access to
| the most common and safe features while disallowing the
| unsafe one. You'd still get far more functionality than you
| have now and only sacrifice a little in exchange for safety
| (vs not having any at all).
| jjtheblunt wrote:
| yeah it will be interesting to see how it evolves
| BiteCode_dev wrote:
| Besides, I know they want to turn the browser into an os, but
| it's not one.
|
| It's sandboxed from the os and limited to some use cases, which
| is the point. I don't want something capable of hot loading
| code from any web site to have the capabilities of my OS.
| robbrown451 wrote:
| The browser is indeed an application platform. Even
| HackerNews is an app, although it uses a minimum of browser
| functionality.
|
| Maybe you don't want things like videochat or paint programs
| or music learning apps to run in a browser, but lots of
| people do.
|
| Imagine if Firefox said "we're not going to let any web page
| access the camera"... their market share would probably drop
| in half overnight.
| postalrat wrote:
| Then disable those permissions.
| jfkebwjsbx wrote:
| Average users won't do it.
| [deleted]
| BiteCode_dev wrote:
| Manual security = no security
| koonsolo wrote:
| I wonder if and when the splitup will happen between the
| "text" web and "app" web.
|
| I know you can disable Javascript, but this is still
| different.
| robbrown451 wrote:
| What would Hacker News be? How about email apps such as
| Gmail or Yahoo mail?
| gsich wrote:
| There are email clients.
| dheera wrote:
| It's kind of sad though because it's still 10X easier to
| build a browser app than a native app simply because of the
| wealth of highly-usable stuff written for JS.
|
| Every time I have to build a GUI in Linux I just build a
| webapp that connects to a TCP backend on localhost because
| that way I can just build a beautiful UI in HTML/JS/CSS and I
| don't have to deal with the mess that is GTK, QT, TCL, TK,
| and all that crap.
|
| Android programming is another can of worms and I'm frankly
| fed up with Gradle updates breaking my project every update
| and needing 79+ files, multiple cludgy steps for signing
| APKs, zipalign (wtf) and other crap just for a Hello World.
|
| What would be nice to have is "installable" apps that use the
| webkit rendering engine but have full access to the system
| including directly opening TCP ports and direct access to
| /dev. These would have to be trusted apps obviously. Websites
| that load code without consent should be restricted, of
| course.
| ogre_codes wrote:
| > Every time I have to build a GUI in Linux I just build a
| webapp that connects to a TCP backend on localhost because
| that way I can just build a beautiful UI in HTML/JS/CSS and
| I don't have to deal with the mess that is GTK, QT, TCL,
| TK, and all that crap.
|
| I suspect this has more to do with the state of native
| Linux development tools versus Javascript dev tools then it
| has to do with the general case. Dev tools for Windows and
| iOS/ MacOs are fairly straight forward. Not sure about
| Android, since my burning hatred of Java has removed my
| desire to mess with that platform entirely. (I know Kotlin
| exists, still not interested)
|
| _Update_ : I'm basing my comment of what it's like based
| on the quoted comment, not making an assertion about how
| good/ bad it is.
| XaspR8d wrote:
| > Dev tools for Windows and iOS/ MacOs are fairly
| straight forward
|
| Are they? It's probably been a decade since I touched a
| native GUI (and I was without a mentor and working on
| already-old software) so I legitimately don't know. Using
| something like Visual Studio's form builder was fine
| enough, but it was not a very expressive toolset as I
| recall.
|
| Web you can get started "instantly". Your browser covers
| most of the tooling you need and you can tweak any live
| site.
|
| I don't _like_ that that 's how it is. From an abstract
| perspective I'd rather not be working on web because it
| seems like we're trying to make a better car by building
| a bicycle inside of it. But the low bar for entry is hard
| to beat.
| noir_lord wrote:
| I had to get back into C# a year or so ago to build a
| commercial internal production management application,
| WPF with XAML was exceptionally pleasant to work with and
| the final product just worked with few issues.
|
| It felt weirdly like writing Vue-like code.
|
| Microsoft nailed it imo, VS2017 and C# have come along
| way since I used to do .net 3.5 stuff.
|
| I really liked C#, it's http and a sync/await stuff was
| excellent.
| ogre_codes wrote:
| > Web you can get started "instantly". Your browser
| covers most of the tooling you need and you can tweak any
| live site.
|
| Obviously you can splat some HTML into a browser and get
| instant results, but once you start talking about apps
| with even moderate amounts of interaction, the simplicity
| of web apps falls away quickly. If you are talking about
| a sophisticated app, I don't think the complexity is any
| less when you are using javascript/ React versus Swift/
| UIKit. The big win I've seen for javascript/ web apps is
| the fact that you are reasonably platform independent,
| obviously if you use Chrome and Chrome specific APIs,
| that falls away too.
| kitsunesoba wrote:
| > Dev tools for Windows and iOS/ MacOs are fairly
| straight forward.
|
| Can't speak much for Windows, but the Apple dev story is
| pretty good. Platform SDKs are deep and capable, if
| sometimes not well documented, and there's a clear
| "right" way to do most things. One can build a "world
| class" app with nothing but Swift+UIKit and few or no
| third party libraries. SwiftUI is rapidly improving this
| too, bringing a fully native "modern" reactive approach
| that works across all Apple OSes.
|
| Xcode can be a cantankerous beast at times but it's been
| getting a lot better in recent releases.
|
| > Not sure about Android, since my burning hatred of Java
| has removed my desire to mess with that platform
| entirely. (I know Kotlin exists, still not interested)
|
| It's slowly improving but still very much a mess. Jetpack
| Compose looks to be poising itself as the SwiftUI of
| Android and that will no doubt improve things, but I have
| doubts that Android development will ever be as nice as
| iOS development is.
| cromwellian wrote:
| Well, IntelliJ Idea is a fantastically better IDE than
| XCode from a functionality standpoint, and Kotlin +
| Compose is IMHO, better than SwiftUI. Compose isn't a
| SwiftUI clone, it's a pure-functional memoization
| framework with compiler support.
| ogre_codes wrote:
| > IntelliJ Idea is a fantastically better IDE than XCode
| from a functionality standpoint
|
| This is not my experience, I've never quite cared for all
| the finicky setup needed to get things right, and it
| always feels a bit laggy. (Though IntelliJ is a world
| better than Eclipse).
| robbrown451 wrote:
| Sending binary firmware updates (sysex) is not a necessary part
| of the API... they don't have to implement that, and if they
| do, they can ask for additional permissions.
|
| Allowing you to use a keyboard as an input device is incredibly
| powerful, and even that can be handled much as camera and
| microphone is: you give the site permission.
| [deleted]
| henriquez wrote:
| Fun fact: for quite a long time Chrome skipped over the user
| permission step in the Web MIDI spec, always allowing access
| and silently giving ad networks a list of connected USB MIDI
| devices with no user consent:
|
| https://www.obsessivefacts.com/blog/2018-10-20-chrome-allows...
|
| Here's what appeared on porn site xhamster.com once newer
| versions of Chromium got around to implementing the permission
| check (SFW-ish):
|
| https://www.obsessivefacts.com/images/blog/2020-04-04-the-ja...
| tyingq wrote:
| Guessing it was for additional browser fingerprinting.
| polycaster wrote:
| That seems a bit far fetched.
| rezmason wrote:
| If this pun was intended, I'm phoning the World Court.
| dkersten wrote:
| Why? All kinds of details are already being used for
| fingerprinting
| tyingq wrote:
| Not sure why that's more odd than other crazy
| fingerprinting techniques actually in use. Keep in mind
| no midi devices would need to be present for
| fingerprinting. Different failure modes, etc.
|
| Especially in the porn industry where the end users are
| likely using incognito mode or a VPN.
| microtherion wrote:
| I still don't understand how WebMIDI would be used for
| fingerprinting of the vast majority of users who don't
| have any MIDI devices connected to their machine.
| Someone wrote:
| I would guess quite a few browsers or operating systems
| would implement at least one virtual MIDI device, so that
| sites wanting to play MIDI would work. Those virtual
| devices wouldn't all be identical.
| windowsworkstoo wrote:
| Because thats what you want when fingerprinting....the
| few users who have one connected gives you probably quite
| and accurate fingerprint for those users.
| tyingq wrote:
| Here's a jsfiddle: https://jsfiddle.net/wj69s4fh/
|
| I get different types of failures and messages from
| different versions of Chrome, Firefox, and IE. None of
| which have any midi devices. Those errors, or the
| structure of the resulting object if it succeeds, are all
| fingerprint inputs.
| amatecha wrote:
| Yeah, ran it in Chrome, the browser didn't say a thing
| whatsoever and I see MIDIAccess object in JS console.
| Nice to know the browser just allows this entire API by
| default.
| seph-reed wrote:
| Why not just limit allowed midi status to: Note On, Note Off,
| CC, Aftertouch, and Pitch Bend? Or maybe be readonly?
|
| Is there a way to escalate that I'm not seeing? AFAI remember,
| all programming is done through status messages 11110000 and
| above.
|
| https://www.midi.org/specifications-old/item/table-2-expande...
|
| Full Disclosure: I made a web synth and really want to be able
| to use midi to play with it.
| anyfoo wrote:
| Better yet, reasonably abstract the raw MIDI protocol away
| with something that has suitable security and privacy
| properties for the web, and translate it to MIDI on the host.
| In any case, the current proposal does not seem to cut it.
| lioeters wrote:
| Exactly. Apple can choose to implement what they consider to
| be a safe interface for WebMIDI. Instead, they refuse all of
| it?
|
| In my opinion, Apple has an incentive to keep the web
| crippled in some aspects, and this is just another symptom of
| that deeper underlying cause.
|
| Well, I guess if I ever need WebMIDI features, I'll put a
| banner for Safari users to switch to Firefox.
|
| (Or.. Maybe Firefox on iOS is forced to use the same engine
| as Safari..?)
| danudey wrote:
| I agree that it would be nice to have a limited amount of the
| Web MIDI spec, but bear in mind the staggering few people who
| actually have MIDI devices, and the even more staggering few
| of those people who want to use whatever website has midi
| support for its features.
|
| To answer your question about why not to just limit the API:
| because that would be another data point to use to
| fingerprint users, and because the amount of engineering time
| that would have to go into Web MIDI support (including
| testing, security auditing, etc.) would never be worthwhile
| compared to putting those same developers on something that
| might be beneficial to vastly more users.
|
| (Also note that Firefox made the same decision to implement
| nothing at all.)
| strbean wrote:
| I don't see why the API should even allow enumerating
| devices. Put that behind a browser dialog. Webpages don't get
| to enumerate directories/files on your system - they pop up a
| file picker dialog. The same should happen with device
| selection. Once you've granted the site access to a device,
| it can ask you to associate a name with the handle, and
| provide whatever shiny device selection / device management
| UI it wants.
| Jonnax wrote:
| Yeah. It's crazy to me that they haven't decided to create
| some abstract virtual midi instrument. That you can instruct
| the browser to pass through to your devices.
| Daishiman wrote:
| It's a shame, but it proves just what a futile affair it is to
| retrofit ancient protocols that never had to consider host
| security. Especially because MIDI is so elegantly simple!
| alerighi wrote:
| What is the problem if the user give the permission to do so?
|
| I don't get this let's not allow this web api because it's
| dangerous, well you only move the problem to an application
| that the user installs on his PC.
|
| If the permission mechanism is correct there is no danger, a
| web applcation wants to access my MIDI interface or my USB or
| Bluetooth or whatever and it can. Isn't the same for mobile
| applications and permission?
|
| So maybe and I say maybe we could stop having to ship an entire
| Chromium engine with Elecron just for a web application to
| access devices or files on the computer.
| Jonnax wrote:
| Because people don't expect their web browser to be able to
| brick their hardware.
| searchableguy wrote:
| Then change the expectations. Native apps aren't much
| better as far as privacy goes. Users should absolutely
| verify everything they use.
| ppeetteerr wrote:
| Native apps go through an approval process
| edoceo wrote:
| Correction: __some __native apps on __some __platforms
| danudey wrote:
| Correction: Native apps on the platform this thread is
| about.
| dkersten wrote:
| Sure but for a long time web has been touted (rightly or
| wrongly) as this safe sandboxed convenient distribution
| platform. The expectation is very much still that a
| website shouldn't be able to harm your computer and that
| expectation isn't going to change any time soon.
|
| In top of that, less technically inclined people don't
| even expect native applications to be able to harm their
| computer and we haven't been able to change that
| expectation.
| _trampeltier wrote:
| That's why I have almost no Apps on my phone. Just a lot
| of different browsers. I think the new mobile Vivaldi
| browser is the first with an option to switch of the 3d
| sensor for the website
| oneplane wrote:
| Because users are users and they win inevitably do the wrong
| thing. Normally not such a big deal, but with the
| interconnected world a compromised user is a big problem.
| It's used as a stepping stone to compromise others, cause
| problems to other systems by using them as slaves in a botnet
| or simply using them to send spam.
|
| Users need to be protected against themselves as long as they
| can't take responsibility for their actions.
| evv wrote:
| If the user is going to be tricked on the web, they can be
| tricked in other ways. If the web doesn't support MIDI,
| users will just download MIDI malware as an app.
|
| By your logic, the web should not have video support
| either, because users are users and it will inevitably be
| misused.
|
| If you were serious about addressing this: We need clear
| and robust and granular permission dialogs on web and
| native apps. Ideally they'd be consistent across
| web/native, which would help users trust their software,
| and understand the permissions they give.
| mavhc wrote:
| And then we need to crowd source what the default should
| be for each site, because otherwise every site will have
| 100 permission popups
| forgotmypw17 wrote:
| Couldn't we hide the rarely used features behind a
| checkbox in advanced settings?
| searchableguy wrote:
| One point not discussed here is by relying so much on app store
| and apple's walled garden, what do you do when china or other
| country ask apple to remove certain apps?
|
| Bypassing geo block on websites is easy and there isn't a
| single source of truth on the web like app store is for the
| users. Can apple explain why they took down apps on the request
| of china in HK and how do you think that will play out when no
| web apps can work reliably on apple devices?
|
| Censorship is a huge problem for app stores. They censor
| anything sexual but sexuality is part of human nature. They
| censor anything politically charged but it's part of human
| nature too. I hope the anti trust fine plays out.
|
| Apple can protect the privacy of people by making it harder for
| them to be vulnerable by choice. People here point towards
| stupid users when saying that a normal user won't be able to
| connect usb and enable a feature. Why can't the same happen
| with browsers or apps on ios? Why the $99 fee just to side load
| apps? Why the need for a mac?
|
| Just admit it's for profit seeking reasons. Ads in your app
| store are a proof of that.
| spankalee wrote:
| The alternative is that users download executable to apply
| firmware updates. Then the attacker doesn't even need to find a
| hardware vulnerability!
| msoad wrote:
| Google's developer relations team have done a good job convincing
| web devs that those APIs are pushed by Google to enable "Amazing
| PWAs", yet we haven't seen them used by any major app. People are
| choosing to download native apps for more sophisticated
| applications.
|
| However Google is pushing those APIs because they know tracking
| people without cookies in future is a big challenge for them and
| they need new ways of tracking people.
|
| So sad that Google has taken over the web. From the most used
| browser (Chrome) to the content hijacking (AMP) to the standards
| (PWA). All to sell you to advertisers.
| bad_user wrote:
| On Android you can use web apps in Firefox, with content
| blocking powered by uBlock Origin and Privacy Badger. This is
| because Android allows real Firefox, engine and all and Firefox
| implements the web push API.
|
| This gives you unmatched privacy. As I've said elsewhere too,
| see this Facebook page listing apps that share data with them
| via FB's SDK and marvel at how privacy friendly your iOS device
| really is:
|
| https://www.facebook.com/off_facebook_activity
|
| The notion that Apple is not implementing the web push API for
| example, for privacy reasons, is stupid.
| danudey wrote:
| "Your off-Facebook activity is currently turned off."
|
| Seems fine to me?
| drevil-v2 wrote:
| The problem with having an Android phone is that then you
| have to actually use the damn thing.
|
| On a more serious note though, in iOS 14 app developers are
| responsible for any SDK's their app uses including data
| egress.
| nojito wrote:
| Rhe fact that people don't realize PWAs are the next push by
| Google to regain control is shocking.
|
| The number of hackernews threads calling out Apple for not
| supporting PWAs is just as insane.
| untog wrote:
| I don't really understand: the PWA APIs are W3C APIs, they're
| not created by one company. Mozilla fully supports them.
| ocdtrekkie wrote:
| Just because they're standards doesn't mean they aren't
| standards written and promoted chiefly by Google. Mozilla
| also has pushed back on some of them, despite the fact
| that... Mozilla supporting them isn't a good argument since
| most of their revenue also comes from, you guessed it:
| Google.
| asjw wrote:
| I don't have to go full PWA to make useful apps
|
| And don't have to go through an app store, creating an
| account, paying Apple, waiting for their opaque reviews
| and giving them 30% of whatever amount I make through my
| app.
|
| Android has Firefox, thanks to Apple iOS doesn't.
| spideymans wrote:
| Interesting thought. I wonder if there's a genuine threat of
| google "AMP-ifying" PWAs. And by that, I essentially mean
| Google using their properties to exert control over PWAs,
| just as they have with web articles and other content. Given
| Google's virtual stronghold over the web, I'd assume so.
| luckylion wrote:
| > However Google is pushing those APIs because they know
| tracking people without cookies in future is a big challenge
| for them and they need new ways of tracking people.
|
| Why would it be? They have the search data, they know what you
| clicked on, they have GA on 60-80% of sites, they have plenty
| of information, tracking and profiling users isn't the issue.
| Tracking and profiling users _legally_ is what 's hard.
| untog wrote:
| You have to build these APIs before people use them, and a lot
| of what Google has been building into Chrome is stuff native
| apps can do, so the use-case is clearly there.
|
| IMO native apps are capable of _far_ more invasive privacy
| violations than the web is. But for some reason they 're given
| a very free pass by comparison.
| breakfastduck wrote:
| They're given a very free pass because it's incredibly easy
| to block a native app from sending data back or even
| connecting to the internet at all.
|
| You have a lot more control over something that's running
| locally than something running serverside that simply using
| the client to harvest data.
| jfkebwjsbx wrote:
| Well, because native apps are intended to be trusted. They do
| not have a motivation to invade your privacy: proprietary
| apps are usually paid upfront and risk their future clients,
| open source can be inspected.
|
| Instead, the overwhelming web business model is "free to use"
| (akin to f2p in games). That means ads and other monetization
| side channels become _the_ priority of the app, not the app
| itself.
|
| And that is for trusted web apps. Let's not even talk about
| the fact that you are executing random code every time you
| visit any webpage. That just does not happen with native
| apps.
| untog wrote:
| That's not true at all! Free native apps abound. Web apps
| tied to subscriptions are also plentiful.
|
| Open source is neither here nor there: both web sites and
| native apps can be open source. In fact, the web is unique
| in allowing you to actually inspect the source that is
| running on your machine, you have no way of verifying that
| the code in an open source repo is what actually runs
| inside your iOS app.
| strbean wrote:
| > In fact, the web is unique in allowing you to actually
| inspect the source that is running on your machine
|
| To be fair, this is changing with WASM. On the other
| hand, there are tons of obfuscation opportunities with
| native executables that don't exist for WASM.
| jfkebwjsbx wrote:
| > Free native apps abound.
|
| Yes? I haven't claimed there aren't free native apps.
|
| > Web apps tied to subscriptions are also plentiful.
|
| Fair, but most of the ones I know are usually technical
| apps or they offer something else that is not about
| software (for instance, storage more than the app).
|
| > the web is unique in allowing you to actually inspect
| the source that is running on your machine
|
| That is not unique, nor true.
|
| Uniqueness: you have apps made in scripting languages
| everywhere. Even for compiled languages it is a decision
| not to give you the code, not a technical one.
|
| Truthness: many webs are obfuscated on purpose like
| native apps are.
|
| > you have no way of verifying that the code in an open
| source repo is what actually runs inside your iOS app.
|
| False, you can definitely verify that a binary matches
| the source code in deterministic builds and even provide
| debugging symbols etc. The fact that many projects don't
| care about that does not mean there is "no way", it just
| means the overwhelming majority of users do not care.
| untog wrote:
| What about Facebook? A native app, free, tied to a
| business and utterly motivated to violate your privacy.
|
| > False: you can definitely verify that a binary matches
| the source code in deterministic builds
|
| If I want to check an app I have installed from the iOS
| App Store matches the code provided in an open repo, how
| would I go about doing that?
|
| >Truthness: many webs are obfuscated on purpose like
| native apps are.
|
| True. But their underlying behaviour, i.e., what data
| they send and where they send it, is viewable and
| blockable by browser extensions.
| coliveira wrote:
| Native apps are not handling my bank account passwords.
| They're also not collecting data about my consumer behavior
| with the goal of displaying more ads. This is a big
| difference.
| CaveTech wrote:
| > Native apps are not handling my bank account passwords.
|
| You're conflating browsers (Chrome, Firefox, etc) with user
| applications. User applications are still not handling your
| bank passwords.
|
| > They're also not collecting data about my consumer
| behavior with the goal of displaying more ads.
|
| lol? Absolutely wrong here.
| untog wrote:
| > They're also not collecting data about my consumer
| behavior with the goal of displaying more ads
|
| This is my original point. They 100% absolutely are. Look
| at some of the ad and tracking frameworks for native apps.
| Somehow no one cares.
| Abishek_Muthian wrote:
| If PWAs die, we will be struck with this duopoly in smartphone
| OS for foreseeable future as native apps are the ones which
| help them retain their position.
|
| If we want upcoming pure Linux smartphone OS, Sailfish or any
| other platform which protect the mobile computing from becoming
| proprietary; we need web apps & PWAs to grow and capture
| significant market.
|
| Apple's treatment towards PWAs has been well known as PWAs are
| the only threat for its Appstore monopoly in iOS.
| EastSmith wrote:
| Name three PWA apps please. I know I've built two PWA POC
| some time ago (using service workers and Notification API),
| but I've never use any PWA in the wild.
| Abishek_Muthian wrote:
| Not sure which region you're from, so I've included the
| filter for you[1]. These are from famous companies, every
| major apps uses PWA in some part of their app.
|
| [1]https://developers.google.com/web/showcase/region
| zdragnar wrote:
| My last employer (a business to business company)
| exclusively went down the web app route, with some minimal
| PWA features, because their clients genuinely preferred not
| having to go through the app store to install it on their
| (often personal) phones. Whether they bookmarked the
| website or "installed" it to their home screen or only used
| it from their laptop / desktop was entirely up to them, and
| they never had to deal with the app upgrade hassle.
|
| Tastes vary, I suppose.
| bad_user wrote:
| > _Name three PWA apps please_
|
| Fastmail, Facebook, Twitter.
|
| None of them work on iOS due to lacking web push
| notifications. All of them can work on Android as PWAs and
| as PWAs they are more secure and privacy friendly (not only
| due to less permissions granted, but also because you can
| protect yourself with uBlock Origin et all).
|
| Keep in mind that your personal experience is an anecdote.
| NovemberWhiskey wrote:
| > _Fastmail, Facebook, Twitter._
|
| I don't Android, so I really don't know - but are those
| PWAs the only or primary options for most users on the
| Android platform?
|
| If not, they're really just "native apps which are also
| available as PWAs", and without data on relative adoption
| rates it's not really very useful information.
| asjw wrote:
| But a billion+ users do Android on a 99$ phone
| strbean wrote:
| Are you talking specifically about add-to-home-screen /
| offline capabilities? Because PWA is a very broad term, and
| most descriptions I've seen consider those features
| necessary to be a PWA.
|
| Ignoring those two, you get damn near every major web app.
| All of Google's applications, Facebook, Twitter, etc. etc.
| Abishek_Muthian wrote:
| This is a good question.
|
| You can enable add-to-home-screen for websites with a
| single meta tag, <meta name="mobile-web-
| app-capable" content="yes">
|
| e.g. Here's one of my website with that tag[1],
| Ironically this feature was introduced by Apple and is
| considered part of PWA specs.
|
| But for the sake of this discussion, let's consider PWAs
| to be one which uses app manifest[2] and uses some high
| level device features.
|
| [1]https://needgap.com
|
| [2]https://web.dev/what-are-pwas/
| strbean wrote:
| Woops! I left off the word "don't" in regards to those
| features being necessary to be considered PWAs!
| impassionedrule wrote:
| Twitter
|
| Firefox Send
|
| Spotify
| fzzzy wrote:
| I love that firefox send is on this list. Thank you.
| MintelIE wrote:
| Nah people can just program in Java again.
| spideymans wrote:
| From a developer's point of view, I can see the value in PWAs
| (for them), but as an end user, I really don't see the
| benefit of PWAs over native apps. The UX is almost always
| severely degraded when compared to their native counterparts
| (even if the feature set is ostensibly identical). Why would
| I use a Twitter PWA, when the native app provides a much
| better UX?
| Spooky23 wrote:
| PWA's or web experiences are "good enough".
|
| I would never use a social network native app, ever, as the
| category has a history of abusing privacy, poorly utilizing
| resources or any number of other things.
|
| For business, it's a much easier decision. If I can do what
| I need to do in a PWA, why futz around with iOS, Windows
| variants, and multiple versions of Android apps? App Stores
| are a much bigger PITA than shipping web code, and I don't
| have the time, budget or care to make a polished user
| experience for employees.
| mikewhy wrote:
| Why would I use the Twitter app, when I can get the same
| out of the PWA and not have to download a hundred meg
| update every week for "bug fixes and improvements"?
| danudey wrote:
| Every time I load the page for a tweet in their PWA on
| iOS it gives me an error, and then I reload the page and
| it works fine.
|
| Why would I use the Twitter website, when I can get the
| same out of the app, it loads faster, and it actually
| works consistently? Plus I don't have to log in in app
| webviews all the time.
| ogre_codes wrote:
| Or just use Tweeetbot, it weighs in at 7.2MB and the last
| update was 8 months ago.
| Eugeleo wrote:
| Maybe in the case of Twitter it makes sense (I'm not
| using Twitter myself), but in general, as the OP notes,
| the UX is worse with PWAs than it is with native apps.
| So, to rephrase your comment to reflect this
|
| > Why would I use the app, when I can get /something
| worse but workable/ out of the PWA and not have to
| download a hundred meg update every week
|
| And then the answer might be --- because your phone has
| 128 gigs of memory, your home wi-fi has unlimited
| bandwidth, and the updates all get downloaded
| automatically while you're sleeping, you might decide to
| go for the better UX in exchange for _nothing at all_.
| zuhsetaqi wrote:
| Downloading a PWA isn't smaller and it also needs updates
| just like a native app. And the answer to your question
| is the comment you replied to.
| the_gipsy wrote:
| Why on earth would I use a native app for twitter? It's all
| static content browsing, this has been solved decades ago
| with the web.
|
| The occasional tweet I may send is just an input field and
| a file upload maybe.
| Longhanks wrote:
| This is a perfect example of a HN reader being out of
| touch with what the vast majority of users actually want.
| There are plenty of reasons people want a native twitter
| app: state restoration, integration with system services,
| push notifications, better user experience, better
| accessibility, fewer ways to track the user, better
| permission model, ...
| ficklepickle wrote:
| You think native apps have fewer ways to track the user?
| Then why does every social site push users to their
| native app? Just so they can get less info? Seems
| unlikely to me.
| mypalmike wrote:
| "Out of touch" is an unfair characterization. Not
| everyone wants what you think they want.
|
| I specifically do _not_ want push notifications from
| Twitter or almost any other app aside from calendars and
| alarms. Having Twitter notify me about every stupid
| online interaction was causing my life to be buried in
| constant distraction. Without a doubt, my life is better
| without it, and I don 't think that's an unusual
| perspective.
|
| Also, I would be curious about your reasoning that
| running an app gives fewer ways to track the user. I
| would tend to believe the opposite.
|
| *Edit: 1 minor typo
| the_gipsy wrote:
| What is state restoration? All I want is to go back to
| where I was, a normal website does that ( e.g. HN).
| Integration with what? I _literally_ just wanna browse
| twitter, like, retweet, and occasionally compose one.
| Push notifications, they work on every system except iOS.
| Better UX is using URLs that I can open and share. Better
| accessibility is HTML that blind users can use. Native
| apps track you much, much more than websites and can 't
| be uBlocked. Permission model is as good as native, if
| not better because users blindly give native apps all
| permissions (see Instagram).
|
| You haven't made a single point, on the contrary, web
| wins on ALL of them.
|
| The one single point you can make but you didn't, is that
| native apps often (but not always) feel smoother or more
| responsive. Which shouldn't be an issue on browsing
| static content.
| asjw wrote:
| Vast majority of users go back home and browse on their
| laptops because a big screen is better than a credit card
|
| Vast majority of users will use whatever you throw at
| them, especially if they're friction free (no account
| needed, no credit card, no updates, no space occupied,
| immediately available, even on slow networks, etc. etc.)
| fulafel wrote:
| Native apps are hard to develop and publish through app
| stores compared to PWAs, and many users don't have access
| to Play store.
|
| Web apps are also more strongly sandboxed which is
| important considering how much of Android install base is
| running on devices without security updates. (Android
| devices notoriously stop getting them after only couple of
| years after device launch, or even sooner)
| ogre_codes wrote:
| > From a developer's point of view, I can see the value in
| PWAs (for them), but as an end user, I really don't see the
| benefit of PWAs over native apps.
|
| I suspect the bigger demand for PWAs is for non-consumer
| apps. If you are selling to businesses or building internal
| apps for a business, often delivering a multi-platform +
| web app with decent performance/ UX, often a PWA or PWA +
| Web platform is the way to go.
|
| > Why would I use a Twitter PWA, when the native app
| provides a much better UX?
|
| This is why I think vertical/ internal apps make a lot more
| sense for PWAs. If consumers have a choice on what they
| use, they are going to opt for the faster/ better
| integrated app and PWAs can't compete. For a purchasing
| manager, the difference between a cross platform PWA and
| delivering 2 native mobile apps plus a web app can easily
| be tens or even hundreds of thousands of dollars in
| development costs.
|
| (FWIW, I work on a large SAAS web app/ PWA which obviously
| colors my perceptions)
| andybak wrote:
| The advantage of a PWA might be that it exists compared to
| the native equivalent that doesn't.
|
| I'm interested in the many quirky apps and niche
| experiments made by people who won't or can't make cross
| platform native apps.
|
| It's this stuff I care about. I don't care about whether
| you faang of choice chooses to go native or not.
| larme wrote:
| hn miss the old internet where content is the king
|
| hn also ask for more apis that make the internet such a shithole
| today, so we can make more useless web "apps".
| m0xte wrote:
| Gopher is what you're after.
| skc wrote:
| So assuming these are standards pushed through the W3C process,
| is it fair to say Safari isn't standards compliant?
| dijit wrote:
| Good; and to those saying "why not just make it an opt-in pop-
| up". How do you feel about cookie pop-ups?
|
| I bet you just click accept, I know I do.
| azangru wrote:
| Accept cookies, yes; but decline the requests for the sites to
| send me push notifications. And decline when Google asks me to
| enable geolocation if I don't want to.
|
| And of course I just leave the site if it gets obnoxiously
| needy and invasive.
| flanbiscuit wrote:
| > Magnetometer API - Allows websites to access data about the
| local magnetic field around a user, as detected by the device's
| primary magnetometer sensor.
|
| I have never heard of this API, what's a use case for it?
| Sharlin wrote:
| The same as with native apps, sensing the device's orientation.
| For AR, navigation, what have you.
| alexdw_mgzi wrote:
| If you had access to the magnetometer, you could make a
| navigation compass. Or, you could animate a map to rotate as
| the phone rotates. It might be good for implementing a
| GeoCaching helper app as a website.
| aogaili wrote:
| And better PWA support and notifications also privacy issue?
| johncolanduoni wrote:
| To their credit, those weren't put on this list (which I was
| half expecting).
| EugeneOZ wrote:
| How a proximity sensor can be used for fingerprinting?
| merb wrote:
| besides the nfc api, which might be feasible with a good privacy
| the api's are simple not needed.
|
| nfc would be a good idea to make authentication over nfc devices
| feasible or nfc checkout. we basically developed a native app,
| just because we needed to access an nfc reader for "tag"
| authentication. it does not more things. printing works over ipp,
| server-side.
|
| the app basically does two things: - nfc reading - barcode
| scanner reading (basically they work like a hid keyboard device,
| so it doesn't really use any hid device driver or anything, we
| just detect it by watching how much keystrokes per ms are coming
| in. (which would be possible with in a webapp, aswell)
| [deleted]
| [deleted]
| ed25519FUUU wrote:
| Everything on this list seems like it would be extremely useful
| in tracking people. The approximate memory API? That, along with
| geolocation, could effectively unmask you across the web.
| yoz-y wrote:
| It can certainly help tracking but the measure is very coarse.
| Basically an enum of 6 values.
| darrinm wrote:
| Why is it ok for native apps to do all such (and more)
| fingerprinting, utilized across apps, and not the web? Maybe I'm
| saying this backwards, why aren't native apps given the same
| restrictions?
| threeseed wrote:
| Because native apps are vetted by Apple.
|
| And on the app install page there is verified data about the
| developer which you can use to contact/sue them if they violate
| your privacy. Good luck getting access to that information for
| a web app.
| phkahler wrote:
| Those APIs should not exist. Web site creators need to stop
| acting like they are entitled to access whatever they want on
| someone's computer.
|
| I dont care about your unique SaS usecase, these are invasive.
| Make a native app if that's what you need.
| jonny_eh wrote:
| > Make a native app if that's what you need.
|
| i.e. Make binary that includes a web browser just for this one
| web app.
| azangru wrote:
| Why is accessing this via a native app better than accessing it
| via web browser?
| joeblau wrote:
| I wouldn't have any problems giving these APIs access via the
| web, but one challenge with the websites is that I'm never
| 100% sure that when I "retract" a permission or say "stop
| tracking me" that it's done. I think that if access to these
| API's were wrapped in some sort of Privacy API that
| superseded each website's privacy and data collection polices
| I would be more comfortable with this. These changes just
| seem like something Google threw over the wall to get things
| working with Chrome and every other browser developer said
| "no thanks".
| danaris wrote:
| Creating these APIs doesn't just grant access to them to
| well-thought-out PWAs with a clear use case.
|
| It grants access to every shady malware ad that wants to
| siphon your data and that of everyone around you.
| azangru wrote:
| > It grants access to every shady malware ad that wants to
| siphon your data and that of everyone around you.
|
| Can't native apps do so as well?
| danaris wrote:
| Well, first of all, there's a massive difference of
| threat scale between "the apps I have personally chosen
| to download and install" and "every website that I visit,
| even if only for a moment."
|
| Second of all, there's no App Store review process for
| malicious websites. An app that wants to harvest your
| data will at least have to have some vaguely plausible
| useful purpose in order to even have a chance to try.
|
| So I don't know about you, but personally, if you were to
| ask me, "Do you think a restriction that reduces the
| number of people able to harvest your data in this
| particular way by about 90%, or is it totally useless if
| it's not 100%?", I'd say go for the 90% solution rather
| than just throwing up my hands and saying it's hopeless.
| rjmunro wrote:
| Forcing someone to install a native app not only lets the
| maker of the app siphon the users web browsing data, it
| also allows them to siphon all data from their machine,
| including bank details, passwords etc, and often opens
| security vulnerabilities that allow people who aren't the
| app maker to do the same.
| danaris wrote:
| At least on an iPhone, it's nearly impossible to get bank
| details and passwords with a native app unless you're
| using some incredibly sophisticated techniques.
|
| Forcing them to install a native app also _massively
| reduces the number of people_ who are going to actually
| let you in.
| mercer wrote:
| To what degree is this true for App store apps too though?
| What with the Facebook (sign-in) SDK and all? Honest
| question.
| phkahler wrote:
| With app store apps I am told what permissions they need
| and I usually opt to not install them, but it's hard to
| get by without a web browser these days.
| phkahler wrote:
| From a tech point of view browsers are switching the roles of
| client and server. It's getting to be like X windows or
| something.
| evgen wrote:
| I am less likely to accidentally give you permission over my
| computer to do shady shit if I am forced to install an app vs
| happen to click the wrong link on my browser.
|
| The difference is intent. By installing Chrome I do not
| intend on giving up every last bit of privacy and control
| over my computer, they just want to trick me into doing so by
| stuffing functionality into web APIs that should never have
| been web APIs in the first place.
| MaxBarraclough wrote:
| I don't follow this line of thinking at all.
|
| If you're questioning whether they're trustworthy, you
| should be going out of your way to _avoid_ installing their
| native app, preferring a web-based solution instead.
|
| > By installing Chrome I do not intend on giving up every
| last bit of privacy and control over my computer, they just
| want to trick me into doing so by stuffing functionality
| into web APIs that should never have been web APIs in the
| first place.
|
| Is Chrome really so bad about accidentally granting
| privileges (webcam, say) to websites?
|
| Perhaps there's a more privacy-oriented browser that lacks
| such functionality entirely? Sounds like a good idea, come
| to think of it.
| evgen wrote:
| That is just the point. I can avoid installing their
| native app, but it is much more difficult to opt out of
| these insidious and unnecessary web APIs. This is
| especially the case when the leading browser happens to
| be created by a data collection company.
|
| Yes, Chrome is bad at managing privileges and leaking
| data back to Google and any other web site that is smart
| enough to know how to ask for it. Avoiding browsers that
| implement this and shaming sites that use the APIs is
| apparently the approach that will be necessary going
| forward.
| MaxBarraclough wrote:
| > it is much more difficult to opt out of these insidious
| and unnecessary web APIs
|
| I don't know what you mean by this. A native app has far
| more access to your machine than a website has. If you've
| installed untrusted native code, it's game over.
|
| Are you thinking of web-trackers like the infamous
| Facebook 'Like' button tracking you around the web? We
| have a solution to that, and it doesn't involve trusting
| native apps. Firefox Containers sound like just the
| ticket. [0]
|
| > This is especially the case when the leading browser
| happens to be created by a data collection company.
|
| > Avoiding browsers that implement this and shaming sites
| that use the APIs is apparently the approach that will be
| necessary going forward.
|
| As far as I know Chrome doesn't leak browsing data back
| to Google any more than any other browser, not counting
| features like auto-complete. If you want a Google-free
| browser, though, you can either go with Firefox, or a
| Firefox derivative, or go with an alternative like
| 'ungoogled-chromium' [1]
|
| As for shaming, I have very little confidence that this
| could work. The 'cookie law' gave websites the choice
| between not using tracking cookies, or showing a popup
| announcing to the user that the website uses tracking
| cookies. In response, virtually the entire web now shows
| a popup announcing their use of tracking cookies. Many of
| us thought the law would have a sort of shaming effect,
| but it didn't.
|
| _edit_ I 'm ignoring the option to click the 'Deny'
| button that the popups are required to give. I wonder how
| many people click to deny. I don't think I've ever seen
| hard numbers.
|
| [0] https://addons.mozilla.org/en-GB/firefox/addon/multi-
| account...
|
| [1] https://news.ycombinator.com/item?id=18053079
| azangru wrote:
| > The difference is intent. By installing Chrome I do not
| intend on giving up every last bit of privacy and control
| over my computer
|
| You make it sound as if Chrome will expose your private
| data and the control over your computer to everyone who
| cares to use it.
|
| Aren't you in control over what you allow to access on the
| per-site basis?
| evgen wrote:
| > Aren't you in control over what you allow to access on
| the per-site basis?
|
| You mean the same way you are in control over what data
| tracking you allow and what cookies can be set on a per-
| site basis? In theory perhaps, in practice no.
| azangru wrote:
| > You mean the same way you are in control over what data
| tracking you allow
|
| I am still confused. How is it different from the native
| app situation? How can you be sure which of your data is
| being tracked by the Facebook app, or Twitter app, or
| Instagram app, or whatever the cool kids use these days?
| evgen wrote:
| While it seems paradoxical it can go in both directions,
| where sometimes the app is the danger; the question is
| about the choices available. Here is an example for you.
| I know more about how Facebook operates and what its app
| does than most people. I have opted not to install the
| Facebook app on my iPhone and instead use m.facebook.com
| for the few occasions in which I need to interact with
| Facebook.
|
| WebKit on the iPhone limits the APIs that a web site can
| access. An app has fewer limits, even on an iPhone. This
| means that with a VPN, a decent DNS server, and some
| content blockers on the iPhone I can limit what data
| Facebook has access to in ways that an app does not
| allow. This is only possible because I have the choice
| between the app (with fewer limits and protections) and a
| restrictive browser environment. If the browser provided
| all of the goofy APIs Google wants to shove down people's
| throats I would have a much more limited set of options.
| tgv wrote:
| IMO, it's not the web-developers, it's the web-site owners. The
| devs (well, the small sample I know) is not interested in
| collecting user information to make a better fingerprint.
| cptskippy wrote:
| It's usually marketing teams who aren't thinking about
| privacy implications, just how to perpetuate or further
| engagement.
|
| Seemingly innocuous features they devise to streamline
| engagement often come with huge privacy implications and I've
| had to shoot down ideas many times in my career that were
| well into the realm of creepy.
| chipotle_coyote wrote:
| I admit to a bit of head-scratching over some the comments here.
| The most common criticism on HN of Apple's approach to native iOS
| apps is the way they're locked down through sandboxing and
| various restrictions in the name of privacy. But a major
| criticism running throughout these comments of Apple's foot-
| dragging on supporting various Web APIs is that we should be
| using PWAs because, compared to native apps, they are locked down
| through sandboxing and various restrictions in the name of
| privacy. And... huh.
|
| Yes, I get that in the first case it's Apple setting the
| restrictions and maintaining the control, and in the latter it's
| ostensibly open and not controlled by any one party. It's a good
| principle. But it's easy to forget that the first steps toward
| web apps were largely taken by _Apple_ back in 2007, with Steve
| Jobs enthusiastically talking about the "sweet solution" they
| had for installing third party apps on the iPhone: web apps.
| There's a future we can imagine where if Apple had stuck to their
| guns and really ramped up their APIs, PWAs would have taken over
| mobile computing a decade ago. But they didn't, and the reason
| they didn't is because both developers and users hated them.
| Hated hated hated.
|
| "But those web apps sucked and modern ones are much better!" Yes,
| I agree! But to _users,_ the difference between going to the app
| store for their platform and downloading Twitter and going to the
| Twitter web site and tapping "Save as Web App" is pretty
| minimal, and there is _no_ effective difference between the two
| once they 're installed. Well, I take that back; I don't think a
| web app can provide a sharing extension, or be automated through
| Shortcut actions, or offer Siri suggestions. So actually, I'd
| rather have the real app still, thanks.
|
| And, on point for privacy concerns, for me this isn't as much
| about "trusting Apple" as not trusting web sites. Yes, I'm sure
| there are valid reasons for all of these APIs to exist, but when
| push comes to shove, I'd rather go through the extremely mild
| inconvenience of having to download an iPad MIDI sequencer as a
| web app than discover that a web site -- or an advertisement on a
| web site -- has used that to track me or even deliver a malicious
| payload to me.
| Nursie wrote:
| The page visibility API should be on the list.
|
| It's none of your business if I'm looking at your page or not.
| cromwellian wrote:
| So if a page is running a computation in the background, for
| example, rendering some real time chart or something, you'd
| rather it continue to do work and waste battery life, then to
| throttle itself?
|
| But then you'll say "well the browser should just throttle any
| tab i'm not looking at" (which it already does), but then
| you'll complain the first time an app you actually want live
| updating doesn't work properly.
| Nursie wrote:
| > So if a page is running a computation in the background,
| for example, rendering some real time chart or something,
| you'd rather it continue to do work and waste battery life,
| then to throttle itself?
|
| Yep, that's the behaviour I expect. If I want you to stop
| I'll close you.
|
| > But then you'll say "well the browser should just throttle
| any tab i'm not looking at"
|
| Why would I say that? I explicitly don't want pages to act
| differently when I'm not looking at them. If they're updating
| when I'm looking at them then they should keep doing that
| when I flick away to something else.
|
| It's a privacy issue and it's a functionality issue. It's
| literally none of the page's business whether I have it in
| view or not.
|
| Next you'll be telling me that pages should be able to use
| the camera and face sensing tech in smartphones to detect if
| I'm looking in the right direction. For my convenience of
| course, nothing to do with advertising, tracking,
| analytics...
| dreamcompiler wrote:
| I still think the right way to do this stuff is to "support" the
| APIs but have them produce random data so the site cannot refuse
| to work if the API is not supported. The best way to deal with
| fingerprinters is to flood them with garbage.
| SergeAx wrote:
| So, basically, Apple users are doomed to stay inside their walled
| garden in the sake of privacy (which mostly means that Apple is
| reserving access to their private data solely for itself). No
| functional-rich PWAs for them. Well, it is always people's
| (customer's) choice.
| coronadisaster wrote:
| Here is Apple making it harder for the web to compete with closed
| wall gardens. Web apps could require the same permissions for
| accessing hardware as mobile apps do. On Firefox, when a website
| wants access my webcam, it asks me, for example...
| selectodude wrote:
| On Safari, when a website wants access to my webcam, it asks
| me.
| jonny_eh wrote:
| Cool, so Apple "can" add features to Safari. They should add
| more.
| sixstringtheory wrote:
| That's one opinion. Another opinion is that they don't have
| to implement "standards" that other companies come up with
| just so they can further infiltrate the systems in place on
| their platform.
|
| Who says Apple shouldn't just make Safari a hypertext-only
| browser and let the consumers vote with their wallets and
| their feet?
|
| Honestly I'd prefer that.
| jonny_eh wrote:
| > Who says Apple shouldn't just make Safari a hypertext-
| only browser and let the consumers vote with their
| wallets and their feet?
|
| Me! I'm a consumer with a wallet and feet. And I would
| like Safari to have more features.
| coronadisaster wrote:
| ok, so they just want to take the choice out of the user's
| hands
| j-pb wrote:
| 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 wrote:
| 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...
| j-pb wrote:
| 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 wrote:
| > _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...
|
| [2]: https://news.ycombinator.com/item?id=18685296
| j-pb wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| There are at least three implementations of IndexedDB.
| Two are built on top of SQLite, but are different
| codebases aside from that, as far as I'm aware - I don't
| think Mozilla just merged in Webkit's IndexedDB
| implementation. Firefox's implementation came out well
| before Safari's, for a start.
|
| What would be your opinion if everybody just decided to
| use Google's implementation of WebRTC wholesale, rather
| than building out their own systems? What if Mozilla
| decided to rebase on top of Blink, and give up on
| building its own rendering engine, tomorrow?
| j-pb wrote:
| I wouldn't mind if they realise that their implementation
| is bad enough to be replaced, it would be a win for all.
| The implementations would start to diverge again anyways.
| The engineering time saved by piggybacking of a working
| implementation can the be reinvested into improving the
| fork massively, or into simplifying the design and
| specification.
|
| Like I said, webkit and blink are the perfekt example for
| this.
|
| As for the first point. It doesn't really matter if they
| have their own glue code, all the important parts are
| shared.
| vertex-four wrote:
| Right, so the web was a wonderful place when IE6 was the
| only browser anyone developed for, and for the short
| period of time when Chrome was the only browser anyone
| developed for. This definitely didn't affect anyone's
| ability to choose a browser which met their needs, and
| definitely didn't result in half-baked and overly complex
| specifications being forced through the standards process
| by the only browser vendor with any power.
|
| If Google got their way, we'd be shipping modified LLVM
| bitcode to clients ("PNacl"), and every browser would be
| shipping some random fork of LLVM stuck in the past
| forever. If Microsoft got their way, GMail would be an
| ActiveX plugin.
|
| Gecko has _massive_ improvements over Webkit /Blink, btw
| - WebRender is huge.
| j-pb wrote:
| You're forming a false dichotomy, and you're mistaking
| competition of code with competiton of institutions.
|
| Having different organisations with different goals is
| what prevents these scenarios.
|
| Otherwise the webkit blink thing wouldn't have been
| successfull.
|
| Mozilla could also have forked blink and started
| replacing it with rust, and you would've gotten the same
| improvments.
|
| Mozilla could have taken SQLite as a foundation, started
| a living spec, and immediately begun translating the
| codebase to rust. The effort would have been the same as
| for their half assed IndexedDB stuff, but the result
| would have been much better.
|
| It doesn't matter where a code base comes from, it
| matters where it goes to. And when it comes to diversity
| of implementation the repelling forces of different
| ideas, viewpoints and aesthetics that normally result in
| dreaded project forks, work for the advantage of all in
| browsers.
|
| Conways law: The software of projects reflects their
| social structure.
| sitkack wrote:
| 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".
| Mikhail_Edoshin wrote:
| I was under the impression that the "by specification"
| idea was generally tossed out with HTML 5, where the
| specification started to describe the current
| implementation. And this was cheered by everybody. What
| has changed?
| bzbarsky wrote:
| The specification describes what implementations should
| do to be interoperable. As opposed to what someone wishes
| implementations were doing but has no hope of convincing
| them to do, which was the major change with HTML 5.
|
| But the fact that there are multiple implementations
| remains. and it remains a goal that one should be able to
| create a _new_ implementation by implementing the spec.
| Notably, this goal was not achievable with the pre-HTML-5
| specification.
|
| In the specific case of WebSQL, if someone were to
| actually create a specification for it that didn't boil
| down to "run this exact version of SQLite and pass things
| on to it", that would have allowed for the "possible to
| create an implementation from the spec" goal to be
| achieved. But no one ever stepped up to do that.
| j-pb wrote:
| 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 wrote:
| How would you migrate to a different SQL implementation?
| It would have to be 100% SQLite compatible in the early
| days because that's what all websites would expect. It
| makes migration nigh impossible.
|
| That said, as long as the SQL implementation they choose
| is free and open source I'm not sure this is such a bad
| thing. I mean we are also stuck with Javascript in the
| browser and that hasn't been a total disaster. The whole
| point of standardization is to choose one particular
| solution and have everybody use it.
| j-pb wrote:
| I think your second argument also applies to the first
| no? Any technology that is implemented in a major
| browser, be it JS, Webkit, SQLite has incentives to port
| it to other platforms. Web developers don't expect 100%
| compatibility, they are so used to things behaving
| differently and broken across browsers that it's actually
| surprising if something just works from time to time.
|
| If anybody was expecting 100% compatibility all the time,
| we wouldn't get any new standards, and would all use
| chromium.
| acdha wrote:
| > 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".
|
| You need to think about the barriers to implementation:
| if everyone ships SQLite, developers will inevitably
| write code which depends on that exact implementation and
| anyone shipping something new will need to copy it -
| including unintentional behavior and bugs - to work with
| existing sites. That is extremely expensive and might
| lock in something we're going to regret later if someone
| finds a behavior which wasn't intended for this context
| and has security or performance issues.
|
| Anyone working on the web should be especially sensitive
| to this since we came close to having the specs for all
| web technologies be "whatever IE6 does".
| GoblinSlayer wrote:
| Also SQLite wasn't designed to run untrusted SQL code.
| It's an embeddable SQL engine, not a web SQL engine.
| j-pb wrote:
| That doesn't make it any less of a solid foundation for a
| web SQl engine.
|
| It's like getting gifted a car, and complaining that
| you'd rather have winter tires. So you start building one
| from raw metals.
| j-pb wrote:
| How is that different from what we have now?
|
| Living specs don't give any guarantees, yet they still
| "pave the cow paths" while keeping ridiculous bugs and
| behaviours for backwards compatibility, and breaking
| existing specs for convenience. It all depends on the
| person dealing with the problem.
|
| Nobody expects compatibility with existing specs, why
| should they for WebSQL? Especially when it's a living
| standard.
|
| If those things were true, we would all use the same
| browser by now and never see new standards, and Blink and
| Webkit would have never diverged from another.
|
| Open source quarrels basically guarantee a steady supply
| of competing forks.
| orf wrote:
| > 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".
|
| The point is that they would clearly never, ever diverge.
| Any sqlite quirks (of which there are plenty) would be
| enshrined into the backwards-compatibility requirements
| of any browser that used it. Plus building a database
| isn't simple - so why not just use sqlite? Setting out to
| fork or rewrite sqlite is not a task that makes any
| sense.
| j-pb wrote:
| The exact same argument could have been made for Blink
| and WebKit, which didn't turn out to be true.
| sitkack wrote:
| 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.
| j-pb wrote:
| 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...
| sitkack wrote:
| 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.
| j-pb wrote:
| The birth and death of javascript
| [deleted]
| buran77 wrote:
| 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.
| asjw wrote:
| > so the manufacturer protects you from these risks.
|
| Gigabytes of pictures in an archive called "the fappening"
| say a different story.
| [deleted]
| jfkebwjsbx wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| buran77 wrote:
| > they are trying to "protect you"
|
| They certainly are trying to protect you but I am not
| naive to think it's out of the kindness of their
| corporate heart. It's because that's what many people
| want right now. Apple tried to compete with Google and
| Facebook at their own game, predictably lost, so changed
| the rules of the game. Which was a brilliant strategy and
| if next year they change their stance I will happily
| reconsider my opinion.
|
| And people don't have to know explicitly every feature
| and how it's achieved technically. The phone is now
| almost a commodity, like toothpaste. You buy one because
| that manufacturer built a trust. You probably buy
| Colgate, Sensodyne, or OralB (Crest). But not because you
| carefully analyzed their chemical composition, or pored
| through study after study. You just trust one, a friend
| or dentist recommended it, it just works for you, and so
| on.
|
| That protection the phone affords you may not be
| immediately apparent but enough people start noticing
| eventually even if they don't understand the underlying
| technical part.
| asjw wrote:
| A thousand dollars is 1/12 of the average Chinese annual
| salary
|
| That's why they buy 99$ phones
|
| You're comparing a few millions people living in SV with
| billions of people making less than 10 dollars a day and
| assuming that they have the same PPA and that they
| represent the entirety of the World's user opinions
| and/or will
| [deleted]
| Jyaif wrote:
| I assume this means that APIs such as
| https://developer.apple.com/documentation/uikit/uidevice/162...
| are not available for their instant apps (the so called "Clips")
| ?
| djrogers wrote:
| This is not related to developing App Clips, just Safari.
| (Aside -not sure why you're using such a derisive tone with
| that 'so called' stuff - companies name technologies for many
| good reasons, so just go ahead and use the name.)
| postalrat wrote:
| Nobody would care if Apple allowed other browsers on their mobile
| platforms. The problem isn't what APIs they do or don't support,
| it's their refusal to allow alternatives to WebKit.
| traveler01 wrote:
| Ahhhh the new Internet Explorer...
| acheron wrote:
| Wrong story, this one isn't about Chrome.
| manishsharan wrote:
| Good. Those APIs were awful. If your website needs to know the
| battery status or other such information , you need to be writing
| an app which I will never download.
| Cthulhu_ wrote:
| There is a use case for that kind of API for PWA's that a user
| would install, e.g. fullscreen games or applications that
| change their behaviour if battery is low (or network is slow).
| But those are far and few between.
| WrtCdEvrydy wrote:
| It's a choice between walled garden browser or walled garden
| market. The anti-trust lawsuit will probably be interesting.
| bilal4hmed wrote:
| I dont think you are going to see Apple get in to any anti
| trust. What you will see is Google get broken up, with Apple,
| Tencent, Huawei, Microsoft etc swooping in and buying those
| pieces up.
|
| You need a strong single Apple so that we can have our
| singular place to buy smartphones.
| WrtCdEvrydy wrote:
| Bundling of the browser to the platform and making other
| browsers non-viable is probably covered under the previous
| Microsoft case law.
| pcmaffey wrote:
| What if battery status was used to triage tasks? Wait to do
| something intensive if you're low, etc. Seems like a respectful
| enhancement.
|
| If theses APIs are only accessible with user consent, I don't
| see the problem.
| cstuder wrote:
| It's not easy. Mozilla ran into the privacy implications of
| the battery status API a couple of years ago: It was so
| precise that it allows the mentioned fingerprinting: https://
| www.schneier.com/blog/archives/2016/11/firefox_remov...
|
| Every additional API added to the browser makes the risk of
| such side effects greater.
| lopis wrote:
| > It was so precise
|
| Then make it less so. Browser APIs can - and do - lie to
| their users. For example, if you try to query the color of
| a visited link, you won't get the actual color, but instead
| you get the default link color. This is to prevent an old
| bug that let you basically harvest a user's browsing
| history.
| philistine wrote:
| I've heard so many people complain on HN about Safari's lack of
| support for APIs. Before now, we didn't have a public
| justification why Apple refused to implement them. Now we know.
|
| The price of a Safari user in the ad market is going down, and
| it's exactly what should be happening. I'm very happy with Apple.
|
| https://9to5mac.com/2019/12/09/apple-safari-privacy-feature-...
| Sayrus wrote:
| Safari already implements API that leaks enough information to
| uniquely fingerprint a device.
|
| For instance, the Audio API. You can test it using OpenWPM
| [1][2] and you will get the same ID in both normal and
| incognito mode. And this is only one of many things not blocked
| by default. ETAG tracking is pretty popular on pixels.
|
| I'm not saying they aren't right, I'm just saying that they are
| somehow doing more PR than anything else. And as other comments
| are calling out, this makes it even harder to compete on IOS
| using PWA (How is a website asking for permission different
| from an app? Can't we have a permission framework just like
| apps?).
|
| [1] https://audiofingerprint.openwpm.com/
|
| [2] https://github.com/mozilla/OpenWPM
| reaperducer wrote:
| _Safari already implements API that leaks enough information
| to uniquely fingerprint a device._
|
| What's your point? Because one API can be used for something,
| Apple should let Safari be a free-for-all?
| needAnAltHN wrote:
| "privacy" the new excuse for monopolistic practices.
|
| Apple users hate to hear they believe the marketing, but it
| doesn't get more clear cut than twisting these things to be
| positive.
| manquer wrote:
| Outside this list Safari's support is limited or nor for many
| other APIs. MediaRecorder and many WebRTC APIs have no clear
| roadmap for support.
|
| Many APIs including getUserMedia and all of WebRTC are not
| supported in _WkWebView_ (only way Firefox /Chrome works on iOS
| due to Apple policy blocking them from building their own
| browser) Means some apps will only work in iOS-Safari and not
| in iOS-Chrome/Firefox.
|
| None of this has to do with privacy, being able to record media
| locally without sending to STUN/TURN server increases privacy
| not reduce it.
| fastball wrote:
| Except "privacy" as a justification is BS.
|
| You can implement these APIs while at the same time requiring
| _explicit_ permission from the user before a web application
| can use them. This preserves privacy while also giving users
| the option to have much more powerful web applications.
|
| Apple doesn't want to implement these APIs because currently if
| you want access to these things on iOS, you need to go through
| their walled garden App Store, where they get a big chunk of
| any revenue you might make on such a service and can nerf
| competitors and all the other anti-competitive stuff they're
| doing.
| oscargrouch wrote:
| I've seen Apple get away with this bad monopolistic behavior
| through hypocrisy more and more.
|
| Apple is denying people their real rights to install whatever
| they want in their own machines, forcing everything to go
| through their app store, where they have the last word of who
| can or cannot distribute software to the platforms they have
| created.
|
| They know that if they use the common "we are thinking of
| your well being" their customers and fans will just believe
| they are a good-willing company with no other interests than
| their users safety and well being.
|
| I don't know why the majority of the crowd here in HN, who
| use to be so harsh in pointing out this kind of behavior in
| companies like Google and Microsoft, have this blindness with
| everything that has to do with Apple.
|
| It will worth nothing, if after have defeated this beast with
| GNU, Linux, the Web, open software revolution, etc.. we end
| up not protecting what we have achieved so far, because
| somehow one company trying to secure their profits and its
| position in the market, get away with behaviors that can
| ultimately destroy the culture of freedom, open-source
| software and ultimately, digital rights, which our
| legislators are not prepared to defend, really understanding
| the threats and the dire future they represent if we dont
| uncover the true intentions behind this BS.
| jodrellblank wrote:
| Recently I've seen a jump in the number of random sites
| popping up a "this site wants to access VR hardware" dialogs
| in FireFox; news articles nothing to do with VR or
| visualisation. I don't have any VR devices.
|
| How do you do this bit " _requiring explicit permission from
| the user before a web application can use them_ " without the
| fallout of "its just a hundred thousand popups and you're
| done!" on every page?
| Sayrus wrote:
| I'd argue that what Firefox do with the tilting icon for
| Push Notification is not that bad. I'm surprised they do
| not do the same for other type of permission as they are
| these request popups are equally annoying.
|
| However, I have to admit that displaying one icon per
| permission would not scale great when having a dozen of
| them.
| fastball wrote:
| Easy. You don't have them in popups, you have them in a
| dropdown that the user selects themselves. Websites then
| need to learn to fail gracefully if not given certain
| permissions, otherwise consumers need to stop using those
| websites.
|
| The solution to privacy concerns is not "nuke
| functionality", it's "don't let websites abuse
| functionality for tracking purposes".
|
| Just like how with native apps on iOS, the solution is not
| "don't let apps ever access GPS data", it's provide a UX
| that makes it fairly easy to choose and don't provide
| permissions to apps that don't need them.
| badwolf wrote:
| Just the constant "this website would like to send you push
| notifications" on every last damn site.
| spideymans wrote:
| Part of me wishes that browsers dropped support for web
| push notifications entirely. Or at least bury it in the
| browser settings somewhere. At best, they provide
| marginal value to me, and at worse, they're just spammy.
|
| My parents aren't techsavy at all, so when they get those
| push notification requests, they just hit "accept". They
| now get dozens of spammy ads sent to them via push
| notifications (eg, "30% off sale, buy now!")
|
| I've disabled web push notifications entirely, but I
| still get JavaScript-based prompts asking me for
| permission to turn on notifications. I already explicitly
| said no, yet web developers still feel compelled to find
| workarounds to interrupt my work and ask me for
| permissions (why?).
|
| I get that in theory, web notifications are supposed to
| be valuable, but in practice its been nothing more than a
| constant annoyance for me.
| buran77 wrote:
| > requiring explicit permission
|
| Except on the long term that would have no effect in
| empowering users. We all know that when faced with a deluge
| of permission requests, or pressured by the fact that enough
| people have already accepted and it's the entry price to
| collaborate, people will just hit accept and be done with it.
|
| They only need to get the foot in the door and then you'll
| find that plenty of stuff ends up conditioned on you giving
| them access. Every one of these APIs is a Trojan horse. Past
| experience just proves that they will be hijacked for
| purposes that don't do the user any favors.
|
| Look no further than JS which is there to enrich the web to
| benefit users but 99% of it is garbage slid under the door to
| benefit site owners. That's because plenty of things that
| should work just fine without it are now tied into it,
| disable JS and the site experience breaks.
| dmix wrote:
| Those EU "accepts cookies" boxes have done an amazing job
| at making people ignore every popup on the internet.
| jonny_eh wrote:
| > Except on the long term that would have no effect in
| empowering users. We all know that when faced with a deluge
| of permission requests, or pressured by the fact that
| enough people have already accepted and it's the entry
| price to collaborate, people will just hit accept and be
| done with it.
|
| How is that any different from apps on the App Store?
| kalleboo wrote:
| The App Store can enforce things like "users can deny
| permissions and the app still works for anything else" or
| you get booted out of 50% of the US market. A web site
| can say "oh, you denied access to location? Well, I won't
| let you continue at all until you do". We saw this on
| Android - on install apps would require a raft of
| permissions, but if all your friends were on Facebook
| you'd be compelled to accept them all anyway.
| dafoex wrote:
| A way this could be solved would be to provide websites
| with an interface that appears to be the system with no
| devices attached (or dummy devices in the case of devices
| that are always present, such as a power adapter) and
| only connect the real device when the user give
| permission. If the website thinks it has permission, but
| finds no device, it must have to fail gracefully or at
| the very least ask the user to connect a device (like a
| midi keyboard).
| fastball wrote:
| My opinion is informed by my experience with JS.
|
| I love the web that actual dynamic logic on the frontend
| has allowed. I want more of that, not less.
|
| The alternative to web apps that can do these things is
| native apps that can do these things. If you don't think
| native apps are tracking your behavior, you are sorely
| mistaken.
| buran77 wrote:
| > I love the web that actual dynamic logic on the
| frontend has allowed.
|
| I think you missed my point, I also truly love that 1% of
| useful stuff that JS brings and wouldn't want to lose the
| functionality. But I absolutely hate the other 99% which
| I have no control over or I have to jump through uMatrix
| hoops to control.
|
| Let's put it another way. You probably love that
| electricians and plumbers exist to fix your stuff. But if
| once you let them in they could invisibly camp in any
| room of your house without you even knowing where they
| are and what they're doing, would you still open the door
| for them?
|
| These APIs can either give you a relatively broad "Allow
| on this site" option, or they can flood you with granular
| choices. The first opens the door for them camping in bed
| with you. The second is like someone triggering your
| alarm every 5 seconds until you disable it. Accept all.
| Then they can camp in bed with you.
|
| Doesn't your experience tell you the same?
|
| > If you don't think native apps are tracking your
| behavior, you are sorely mistaken
|
| You see, this is _exactly_ what I meant. "Those guys are
| screwing you over so it's OK if these ones do too". This
| is how the "screw the user over" arms race happens where
| everybody tries to outdo the others with even more
| invasive techniques, and users take it because each is
| just a slight escalation from before. When native apps
| were adding these "features" someone loved them for one
| reason or another. Frog in hot water.
|
| P.S. Example of how the innocent battery API access can
| be sold as "to save battery" and then repurposed to screw
| you over:
|
| https://metro.co.uk/2019/09/27/uber-charge-battery-
| lower-107...
| floatingatoll wrote:
| Unequal progress of privacy improvements on the web and
| app fronts does not make it okay to walk back progress on
| the web front just to provide API parity.
| fastball wrote:
| If the only way to have privacy is to nuke functionality,
| then I'd rather have the functionality.
|
| Luckily you can have both, despite Apple wanting to
| pretend otherwise.
| buran77 wrote:
| > Luckily you can have both
|
| I have a bridge to sell you...
| vanviegen wrote:
| Please just explain your point, instead of being snarky.
|
| I think there _are_ ways to get (a bit of) both. It 's
| not simple though.
| Karunamon wrote:
| The point (which I _vehemently_ disagree with) is that
| prompting for permission is insufficient because
| illiterate users will just click accept on the dialogs.
|
| So apparently we now have to restrict all interesting
| functionality in the name of keeping the lowest common
| denominator from shooting their metaphorical feet. If
| there's a more charitable way to read their stance, I'd
| love to hear it.
| buran77 wrote:
| > The point (which I vehemently disagree with) is that
| prompting for permission is insufficient because
| illiterate users will just click accept on the dialogs.
|
| I had 2 points actually, which I thought I made very
| legibly. I didn't think they they need a fourth reading
| but here we are... They are both solidly confirmed by
| present day reality. 1) is what you mentioned already. As
| seen with cookie prompts, app permissions, actual
| scientific studies, etc. if you pester people with alerts
| and popups they are desensitized and start ignoring and
| accepting them. 2) is that once you give a website
| permission you lost control. They lack even the modicum
| of oversight apps receive.
|
| > So apparently we now have to restrict all interesting
| functionality
|
| All? Hyperbole much? Or did you just decide that these 16
| APIs are the crux of "interesting functionality" and
| freedom? It doesn't matter how much you allow there's
| always going to be someone to shout "they restricting
| _eeeeverything_ around here ". This is what security and
| privacy measures do, restrict _some_ things because the
| benefit doesn 't outweigh the cost/risk. All those
| features are sold as "essential" when in fact most of
| them at best address some minor nuisance. Then they're
| promptly hijacked for nefarious purposes because there's
| always going to be some wannabe coder who insists that
| his website needs to know my battery level for some
| (undoubtedly good) reason.
|
| Care to ponder how we got here in the first place? With
| every piece of tech around trying to steal data from you
| one way or another, usually in a dishonest way? There's a
| reason Google is championing this and it's not that they
| want to give you "interesting features".
|
| It's always a compromise and for the past decade+ we've
| been compromising a lot more on the privacy side. If you
| truly believe you can have both privacy and _aaaaalll_
| interesting functionality in the real world you 're
| either naive or sitting on a gold mine.
| Karunamon wrote:
| > _It doesn 't matter how much you allow there's always
| going to be someone to shout "they restricting
| eeeeverything around here"._
|
| A good example here would be the MIDI interface getting
| blocked because it allows binary uploads via certain
| control message, as well as device enumeration.
|
| If privacy is the main issue with this API, then the
| allowed control messages that the API would accept could
| be limited strictly to note on, note off, key velocity,
| etc.. things that have no realistic possibility of data
| leakage or compromise.
|
| But instead, no, we lose the whole thing, even though a
| more nuanced approach (and in this case, one that's easy
| to implement - MIDI being rather straightforward) would
| satisfy any privacy concerns.
|
| So with that in mind, the fact that a privacy-respecting
| alternative exists, no. I don't believe for a hot minute
| that that this is all about privacy - that is mere
| marketing fluff. I instead believe it is Apple is using
| privacy as a pretext for ensuring that PWAs remain as
| gimped second-class citizens on the platform in
| furtherance of their lock-in.
| gerash wrote:
| next headline: "Apple devices won't display any video other
| than those from tv+"
|
| Apple bros on HN: "Good! finally someone standing up to the
| BigTech abuse of privacy"
| otterley wrote:
| Apple has the ability to put every submitted app through
| rigorous analysis before publication on the App Store to look
| for forbidden behavior, in order to protect their customers.
| They don't have that ability with arbitrary websites.
| oscargrouch wrote:
| So you trust a third-party, a company, to define what is
| 'forbidden' for you to install, if they say they do this
| "to protect our customers"?
|
| At least in democracy we can elect the people who define
| whats allowed or forbidden to us, and they can only do it,
| in the constraints of a constitution.
|
| If we let companies get away with it, we are allowing them
| to create shadow states, a sort of new digital feudalism,
| where our digital overlords can control a big part of our
| lives. (Remember that we are going to a process of
| digitalization of our lives and experience, with IOT, AI,
| smart gadgets, to take into account how powerful a entity
| who can control all of this can be)
|
| Today, its just Apple. But with people normalizing this
| kind of behavior, it will be more and more over time, til
| its too late for all of us.
|
| By enforcing other browsers to use their implementation of
| Web platform, for instance, they knew they could control
| the Web from being a good contender to their exclusive
| application platform.
|
| This kind of action alone, should be outlawed, because is
| pure uncompetitive behavior, not to say its hurting their
| customers freedom to choose whats best for them, and that
| actually have nothing to do with the privacy or safety of
| their users.
| otterley wrote:
| You vote with your wallet. If you don't want to patronize
| Apple, go with Android, or find some other phone and
| browser vendor.
|
| Also, you mention without evidence that Apple's actions
| have no relation to the safety or privacy of users. Are
| you claiming that their actions are merely a pretext, and
| that Apple provides no such value, or that they have no
| such intent? If so, how do you know?
| searchableguy wrote:
| You made the same point before but again, how did tiktok,
| facebook and all the other crap gets past it? What about
| all the other chinese spyware?
| lifty wrote:
| I sympathise with the walled garden App Store argument. I
| hate it that Apple keep such a tight grip on the application
| distribution channel. At the same time, I really hate the
| trend where browsers are operating systems and I use native
| apps whenever possible.
| user5994461 wrote:
| I don't want random web sites I open (and their ads) to ask
| permission to scan bluetooth in my area and use usb devices
| connected to my computer. A website has no business doing any
| of that. There is no justification for these API to exist.
| capableweb wrote:
| Same argument could be made for JS in general. The
| justification for those APIs to exist is because developers
| want to implement features using them, same as with JS in
| general too.
| Alex3917 wrote:
| > I don't want random web sites I open (and their ads) to
| ask permission to scan bluetooth in my area and use usb
| devices connected to my computer.
|
| Why not? It makes complete sense for something like a
| website that backs up the photos stored on your camera.
| What's even the counter argument, that if people want to
| back up their data they should have to pay Apple?
|
| If you've granted a website access to a restricted API, the
| browser can just paint a flashing red border around the
| website or whatever, similar to how people configure their
| terminals when they're SSH'd into prod.
| nemothekid wrote:
| Because every other site will start asking you to scan
| Bluetooth when some ad network starts using it to
| fingerprint you
| mitchdoogle wrote:
| I don't want random sites to ask to use anything on my
| computer. It's like a popup ad - it's annoying and blocks
| the site. Sure, there are legitimate use cases, but if
| it's anything like push notifications it will be heavily
| abused and far too many sites will ask for permissions.
| halostatue wrote:
| I'm tired of websites asking if I want to enable push
| notifications from them. The answer is, and will always be,
| GTFO.
| Hedja wrote:
| In most browsers, you can go into settings and default it
| to block without asking.
| joking wrote:
| most sites use a html modal to ask for the permission,
| and if you answer yes they make the request to the
| browser api which shows his own modal.
| Sayrus wrote:
| I don't want _most_ websites doing this. There are some
| websites (especially PWA) where they are definitely useful
| and can replace a heavy client.
|
| Maybe it shouldn't "asking for permission" but "giving your
| permission" explicitly. If you don't need such an API, you
| would never be bothered by it if the model is opt-in
| without notification/popups.
|
| I understand the problem you have with websites asking for
| permissions, especially push notifications permissions, as
| they keep showing up. And I do definitely agree that having
| a website that does not need any of these permissions ask
| for it would be even more annoying but there are definitely
| cases where I'm glad a website can help me out (and I don't
| have to download a heavy client that might or might not
| have tracking and analytics in it)
| ornxka wrote:
| >There are some websites (especially PWA) where they are
| definitely useful and can replace a heavy client.
|
| How can this be so when the web browser itself is a heavy
| client?
| Sayrus wrote:
| You could argue that, however, I don't think it change
| the fact that you already have it installed. So, in my
| honest opinion, it is indeed replacing a __second __heavy
| client that you might have installed if you browser did
| not have this capability.
| josephcsible wrote:
| Unless you only use one such website ever, then it's a
| win for the browser to be the heavy client instead of
| having separate ones for each.
| jfkebwjsbx wrote:
| Why would you ever want a PWA when a native version
| exists?
|
| And "heavy client" is a fallacy. Operating systems come
| with runtimes too. _Very_ complex native app can be
| _very_ small in size if it uses the native controls and
| APIs. They can be KB in size. Any asset is going to be
| bigger than the binary itself.
|
| The web-as-native apps are the ones that are huge,
| because they embed a behemoth (a browser) which is akin
| to an entire operating system.
| ta576248_743568 wrote:
| PWAs run from the browser sandbox which is generally much
| stricter than restrictions for native apps. Permission
| systems for native applications seems to be starting to
| follow browsers (flatpak, snap, .appx, etc.), but don't
| offer nearly the ability to restrict what a native app
| can do like the browser does.
|
| In theory native apps are "trusted", but I think for the
| vast majority of users the trust between a companies
| website and app are equivalent, vetted the same, and
| probably do an equivalent amount of tracking if not more
| by the native app (facebook SDKs are pretty common in
| native mobile apps).
| jfkebwjsbx wrote:
| I talked about paid or open source productive software,
| usually desktop based, nor ad-riddled mobile apps with
| the Facebook SDK which by definition are _not_ trusted.
|
| Mobile apps are increasingly sandboxed too, like
| websites, precisely because of that.
| fastball wrote:
| I disagree. I want that. Therefore a website does have
| business asking for those things.
| fennecfoxen wrote:
| You're wrong. Therefore the developers' effort should not
| be wasted, and certainly not while exposing their users
| to privacy risks, exploits, and such other dangers as
| will inevitably arise when placing the capabilities to
| perform sensitive operations in software which also deals
| with untrusted input from the Internet.
| [deleted]
| Sayrus wrote:
| This is definitely going to be downvoted.
|
| Isn't App store apps (Not reserved to Apple's one, this
| also works for Google, Microsoft and many others)
| untrusted code too? It runs with even more privileges
| than your browser's code and have access to more
| fingerprinting information if that's what it is going to
| do.
|
| As far as I see it, a PWA with these permissions has less
| privacy risks than a native application I can find on a
| store. I'd really like to understand how installing an
| app is not an issue but having the access from the
| browser is. Is it simply the permission framework that is
| broken and you don't trust it to not leak information
| when the API is disabled?
| otterley wrote:
| _Isn 't App store apps (Not reserved to Apple's one, this
| also works for Google, Microsoft and many others)
| untrusted code too?_
|
| Apple puts every submitted application through an
| enormous battery of automated (and sometimes manual)
| tests and disassembly to look for malicious or non-
| permitted behavior before publishing apps to the App
| Store. They don't have that ability with random websites.
| searchableguy wrote:
| How did facebook, tiktok and many others get past through
| that lol?
| fastball wrote:
| How can I be "wrong" about wanting these features?
| They're features that I want. I literally can't be wrong
| about that.
|
| > capabilities to perform sensitive operations in
| software which also deals with untrusted input from the
| Internet.
|
| But native apps _don 't_ deal with input coming from the
| internet? If that's what you think, you're... wrong.
| fennecfoxen wrote:
| > But native apps don't deal with input coming from the
| internet? If that's what you think, you're... wrong.
|
| If you're going to write a native app, I am not subject
| to any of its radical security implications every time I
| try to browse the Web in general, and we are no longer in
| conflict.
| close04 wrote:
| Apps go through some for of validation by the
| "gatekeepers", and as a user you curate them a bit, you
| install the trustworthy looking ones. I mean you have a
| greater degree of control over what apps you install and
| use.
|
| Now what's the level of control anyone has over a
| website? In your lifetime you visited many orders of
| magnitude more websites than apps. How do you plan on
| validating every link you ever click on? Every redirect?
| Browsers are the front line on the internet, they face
| the biggest threats because they can't afford to work in
| a walled garden with curated content. You are one minor
| bug away from giving access to your USB connected devices
| to some random website without even realizing.
|
| I don't think anyone is arguing that you are wrong about
| what you want. Just that what you want is wrong. Like a
| kid wanting more sugar, they can't spell diabetes so it
| can't be a problem. You're selling your privacy for
| trinkets and that wouldn't be anyone else's concern if
| there wasn't a critical mass of such users pushing
| everyone in the same direction. Every questionable
| decision made by companies was made with the (ignorant)
| backing of people like you who saw the shiny feature and
| couldn't see past that. And again, you have every right
| to want whatever you want no matter how smart or dumb
| that may be. But don't be so shocked when people call you
| out on it. It's only because you brought just your own
| personal preference into the discussion instead of the
| merits of giving up every shred of control over your
| stuff in exchange for some marbles.
| rstupek wrote:
| Also a website you approve of today can be totally
| different tomorrow without you knowing of the change. The
| domain can expire, be picked up by scammers/spammers/porn
| hosters and you've given them the access to things you
| wouldn't intend to.
| searchableguy wrote:
| I don't understand. The same can happen to apps. Apps can
| remotely change behavior and update OTA. Do you think
| people verify the code before clicking auto update on
| their phones?
| andrekandre wrote:
| > Do you think people verify the code before clicking
| auto update on their phones?
|
| thats a very good reason then for an app-store to enforce
| rules and code checking then, isnt it?
| kilburn wrote:
| Following your analogy, we should _erradicate_ candy from
| this world and never allow anyone to produce more. This
| way surely kids won 't get candy-induced diabetes.
|
| There are perfectly valid reasons to want usb/bluetooth
| support for websites: fingerprint readers, smartcard
| readers and plenty of special-purpose hardware that would
| be useful to access through some web apps.
|
| Does this mean every site should have access to all your
| hardware? Of course not. Let's make sure you have to
| bless a site to allow such access, make sure that the API
| can only be used from https-enabled (and trusted)
| origins, etc..
|
| Your position of "just no because I don't see a need for
| it today" is a very close-minded one...
| [deleted]
| close04 wrote:
| > Following your analogy
|
| But you're not following the analogy. You just took it
| word for word and attacked something that wasn't even the
| point of it. You may as well have said "but websites
| aren't made of sugar".
|
| I made concrete points on why websites shouldn't be
| trusted with such access. You did more of what was shown
| before, rattled the trinkets. And the use cases you
| listed don't seem like something you can't achieve now
| with existing APIs or dedicated apps, which makes more
| sense.
|
| Stands to prove that the point of the analogy is more
| appropriate than ever: people can't understand the
| problem, let alone the solution.
| danaris wrote:
| You (or a small minority of users) actively wanting it is
| not sufficient justification for creating APIs that will,
| with near-certainty, enable additional widespread
| surveillance and data gathering of the public by entities
| whose only interest is in profiting from that data, not
| better serving the public.
| johncolanduoni wrote:
| They didn't mention the biggest one that people (including me)
| complain about, which is the push notification API. That's
| intellectually honest of them (it inherently requires explicit
| permission before activating for a particular origin), but
| pointing to these far less likely to be used APIs is not making
| a good case for neutering PWAs on privacy grounds.
| afrcnc wrote:
| Firefox doesn't support them either. Most of these are
| implemented on Chromium, for Google's ChromeOS primarily.
|
| They're kinda useless for web browsers, but people see them in
| Chromium and believe they must be there for a reason other than
| ChromeOS. Apple and Firefox are doing it right. These things
| don't have a place in browsers.
| whoopdedo wrote:
| There's an unintended consequence in this, though. Which is
| that if you don't use an ad blocker you'll see the lowest cost,
| and thus lowest quality of ads. So in addition to keeping a
| private presence you're required to use an ad blocker. And
| services which have built their business around being ad-
| supported will see you as a deadbeat. Which motivates them to
| be more aggressive in upselling you, or denying service if you
| don't whitelist their ads.
| reaperducer wrote:
| _Which is that if you don 't use an ad blocker you'll see the
| lowest cost, and thus lowest quality of ads_
|
| I haven't worked with web ads in a while, but from what I
| remember when I did, people with little data on file with the
| advertising networks got more ads, and better ads, because
| there was no record of them having seen the high-paying ads
| already.
|
| The longer you surfed, and the longer you were tracked, the
| lower quality the ads became.
|
| Again, I haven't been in this arena for a while, but that was
| true at the time, as told to me by the president of one of
| the larger non-FAANG advertising networks, over coffee.
|
| But it's all a red herring anyway, isn't it? Are there any
| people out there saying, "I wish there was a way to give
| Google more information about me so that I can see better
| quality ads!"
| Wowfunhappy wrote:
| > Which is that if you don't use an ad blocker you'll see the
| lowest cost, and thus lowest quality of ads.
|
| Is this a thing? Do people in demographics which are less
| appealing to advertisers also see more intrusive ads?
| philistine wrote:
| To me, intrusive ads mean ads which intrude on my privacy.
| So if you use Safari, no, you will not see more intrusive
| ads, quite the contrary.
|
| Those ads might be terrible chum bucket stuff, but they
| would not be intruding into your privacy.
| the_gipsy wrote:
| Native apps are much, much more privacy-invasive.
|
| Apple _forces_ you to use those. You have no choice, like on
| other platforms.
___________________________________________________________________
(page generated 2020-06-29 23:00 UTC)