Apple declined to implement 16 Web APIs in Safari due to privacy concerns - <AUTHOR> https://www.zdnet.com/article/apple-declined-to-implement-16-web-apis-in-safari-due-to-privacy-concerns/ <comment><USER2> > 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](https://github.com/mozilla/standards-positions/issues/58)

<comment> seph-reed 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...](https://www.midi.org/specifications- old/item/table-2-expanded-messages-list-status-bytes)

Full Disclosure: I made a web synth and really want to be able to use midi to play with it.

<comment><USER3> 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.)

<comment> seph-reed This is just a philosophical standpoint, but I think supporting the interests a small group of experimental pioneers is generally more useful than their numbers would imply.

The idea that "staggering few" is a negative disappoints, given it has almost always been the "staggering few" who've progressed humanity.

</comment></comment></comment></comment><comment><USER4> 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.

<comment><USER5> 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.

<comment><USER6> I like having apps that work and feel the same. I can bring my knowledge from one app to another. I can develop expertise on a platform. The web is culturally unable to do that.

Look at a sophisticated web app, like Google Docs. This has a menu bar, which is a bad copy of the native Mac menu bar. Web apps are copying native app conventions, to try to be more familiar. But they're also _eroding_ those conventions.

Eventually only click and swipe will be left. And this problem is not going to be solved by Web MIDI or whatever.

<comment><USER7> I think you're trying to say that Mac OS or Windows native apps have pretty much the same UI/UX conventions which makes it easy to use any app on that platform. And that Web Apps have UI/UX that is less consistent than apps across OS's.

I can't say I agree with this. There are a ton of MacOs apps that implement fully custom GUI (first one that comes to mind is Jira native Mac app which looks nothing like a Mac app I've seen before)

I agree web apps are likely eroding OS conventions though. The Jira app is an example of that (they decided to make their native app look and behave the same as the Jira Web App instead of using standard MacOS GUI conventions.

It's a tough trade off.

<comment><USER6> Yeah and Spotify is another one. Electron is clearly at work here, probably in your Jira example too.

These apps are frustrating for someone accustomed to the Mac UI. Basic interactions (like context menus) don't work at all, or work in unexpected ways. I have no idea what these apps can do because they all have a unique UI vocabulary. So I don't try.

I think Apple has really dropped the ball on this. They ought to have spotted and embraced the web's great strengths early. Ephemeral, zero-install apps, using native components - that's the platform I want. Though I understand how others may disagree.

</comment></comment></comment></comment></comment><comment><USER8> 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.

<comment><USER9> 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.

<comment><USER10> 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?

<comment><USER11> 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"?

<comment><USER12> 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_.

</comment></comment></comment></comment></comment><comment><USER13> 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-...](https://9to5mac.com/2019/12/09/apple-safari-privacy-feature-ads/)

<comment><USER14> 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.

<comment><USER15> 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.

<comment><USER16> 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)

<comment><USER17> >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?

<comment><USER18> 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.

</comment></comment></comment></comment></comment></comment><comment><USER19> 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.

<comment><USER20> 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.

<comment><USER21> I don't entirely understand your argument: I would love to use those things in the browser; in fact I do. But those are precisely the things I don't want to give random web API access to!

<comment><USER20> Then don't. But if a web form at a coffee place wants to ask you for payment, it should be able to call up the WebPayment API to ask for one time permission, to which you can acknowledge. I shouldn't need a native app to do it.

And once you acknowledge that asking for access to spend your credit card is ok on the Web (and it is, because Apple supports the W3C Payment Request API), why do you think it is far worse to plug into a USB device, and be prompted to ask if your Web page can access it. There are any number of reasons to do this, like Arduino projects, IoT devices, etc.

I use a Chrome app that lets me install APKs over USB thanks to this API. Super helpful for installing built artifacts from a Continuous Integration result page for example.

Or maybe you're at an airport, or your company, and you want interact with a vending machine through NFC or BlueTooth. Why is a one-off permission tied to that one use any worse than the previous example of payment approval.

Most of the people responding on HackerNews seem to think Web apps can use these APIs without requesting user permission.

<comment><USER6> > I use a Chrome app that lets me install APKs over USB thanks to this API

What the fuck.

> Most of the people responding on HackerNews seem to think Web apps can use > these APIs without requesting user permission.

Nobody will have malware sideloaded because it requires clicking an OK button?

Most of the web is scams. Search for _anything_ and most links will be scams. From that perspective, these APIs are profoundly reckless.

<comment><USER20> You can't side load something by clicking an OK button, you have to put your phone into developer mode and click a "trust this computer" dialog on your computer AND also click ok in the browser.

And yes, if you have a continuous integration system building your binaries in the cloud it is helpful to be able to install them without going through a damn store process. You are installing your OWN apks that you compiled with this extension I'm talking about.

>most of the we is scans

Talk about hyperbole. The only time I've ever encountered harmful scams is when I searched for pirated content.

The web is the most useful human invention since the PC era. Most of peoples time in apps is spent in social media consumption. I'll take web content over TikTok and Instagram any day.

</comment></comment></comment></comment></comment></comment><comment> j-pb 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.

<comment><USER22> 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.

<comment><USER23> 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.

<comment><USER24> > 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.

<comment><USER23> 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.

<comment><USER22> > 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.

</comment></comment></comment></comment></comment></comment><comment><USER25> 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.

<comment><USER23> > ... 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.

<comment><USER26> 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.

<comment><USER23> > 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.

</comment></comment></comment></comment><comment><USER27> 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.

<comment><USER28> Why is accessing this via a native app better than accessing it via web browser?

<comment><USER29> 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.

<comment><USER30> 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.

<comment><USER29> 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.

<comment><USER30> > 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...](https://addons.mozilla.org/en-GB/firefox/addon/multi-account- containers/)

[1] [https://news.ycombinator.com/item?id=18053079](https://news.ycombinator.com/item?id=18053079)

<comment><USER27> >> 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.

You're either trolling or clueless. Everyone needs a web browser. There are basically 2 of them. These are used (or necessary) to access a lot of things in today's world, from ordering a pizza to accessing government publications. Nobody NEEDS one particular web app. We can avoid installing apps, but not standards compliant web browsers.

<comment><USER30> You seem to be agreeing with me, yet you're accusing me of either trolling or being clueless.

If you use Firefox Containers, you avoid untrusted native code, _and_ you avoid persistent cookies tracking you around the web.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> 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.

<comment><USER32> 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.

<comment><USER33> 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...](https://www.schneier.com/blog/archives/2016/11/firefox_removin.html)

Every additional API added to the browser makes the risk of such side effects greater.

<comment><USER34> > 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.

</comment></comment></comment></comment><comment><USER35> 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.

</comment><comment><USER36> 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

<comment><USER37> 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](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."

</comment></comment><comment><USER38> 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.

</comment><comment><USER39> 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.

<comment><USER40> And you people don't seem to understand that UX doesn't need be the same. Websites can make the prompts default to no, even hiding them by default behind an icon.

There's no reason you can't make the UX cater to the use case such that it's clear and secure by default.

It's just tiring dealing with people who channel their hatred for JavaScript essentially into nerfing the only truly open platform we have, one with far better primitives than the native ones and with a massive potential that is only held back by the feet dragging of every major company (Google and Apple both).

Then you go to HN where you'd expect we could agree that a web that complemented apps if done well should exist, and instead we have nerds gaslighting other nerds using every fake reason they can find (my dad wouldn't understand the notification, or, good because I don't want powerful sites) when in reality they just lack any imagination that would easily allow them to have both worlds, thus keeping those who do have some imagination stuck in this special hell of having to re-make the same points over and over.

</comment></comment><comment><USER41> And better PWA support and notifications also privacy issue?

<comment><USER42> To their credit, those weren't put on this list (which I was half expecting).

</comment></comment><comment><USER43> Browsers should just bundle all the advanced but privacy concerning APIs into a single App permissions dialog that you get on the domain you visit and that's it. That should include everything JS except simple DOM manipulations, so you don't have to completely disable it as most _regular_ websites just need a few hover events and image carousels. When a website needs to be an _app_ , the web _can_ and _should_ act as an application delivery platform with proper permission dialogs and installation prompts. Separate the concerns and you're done, instead of this farce, but of course when an OS company is focusing only on short-term revenue rather than empowering their users in the long run, they would be blind to solutions like these.

</comment><comment><USER44> 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.

</comment><comment><USER45> 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.

</comment><comment><USER46> 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?

<comment><USER47> 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.

</comment></comment><comment><USER48> 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).

</comment><comment><USER49> 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).

</comment><comment><USER50> 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.

</comment><comment><USER51> > So far, Apple said it:

> \- Removed support for custom fonts. This means only presenting built-in > fonts which are the same for all users with the same system.

I really hate this. I'm opinonated on typography and rely on userscripts to replace fonts I think to be subpar (Arial, Times New Roman, etc.) with ones with higher quality. Since ~2 years ago Safari has lost the ability to designated any font with custom 'font-family: ' CSS other than built-in fonts, totally breaking my use case. I hadn't use Safari as my daily driver browser since then despite its privacy benefits.

</comment><comment><USER52> So assuming these are standards pushed through the W3C process, is it fair to say Safari isn't standards compliant?

<comment><USER53> You could say something similar about Firefox then.

</comment></comment><comment><USER54> The page visibility API should be on the list.

It's none of your business if I'm looking at your page or not.

<comment><USER20> 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.

<comment><USER54> > 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...

FYI I've managed to find an addon for firefox that blocks this API. No noticeable difference in battery life.

<comment><USER20> > Next you'll be telling me that pages should be able to use the camera

They already do have access to the camera through the getUserMedia APIs, and WebXR has Gaze Tracking. Even your iPhone allows camera access through the Web.

<comment><USER54> I am at least asked permission for camera use, as far as I know. Not so for the visibility API.

If gaze tracking or camera access is to be allowed without permission, I would consider that a gross violation of privacy.

<comment><USER20> Well many of the APIs Apple rejected asked for permission.

If asking permission is what it takes for Safari to implement something than they could suggest a modification with permissions.

Flat out rejecting everything comes across as Microsoft style aggression back when MS was actively seeking to kill open platforms in favor proprietary APIs.

Apple could even suggest tying permissions into the App Store and require web domains to be signed and approved by app stores for the permissions to work, but not presenting alternative proposals suggests they are not interested in making the Web better.

The whole App clips thing is kind of ludicrous because it's a text book example (eg paying a parking meter) that the Web model excels at. The fact that they didn't choose the web for that is telling. WeChat for example has deployed such mini apps for years in China to support interactions with vending machines, restaurants, etc by simply scanning a QR code. It works brilliantly and didn't need an App Store.

<comment><USER54> But the argument there is also quite reasonable - the UX of popping up boxes for this stuff is terrible, it annoys people and they just start clicking "Yes" all the time or "no" all the time.

And this is because, while there clearly are good and valid web apps that use this functionality, the web is also a cesspit of abusers who will use any means they can to track, trace and infiltrate.

I don't know what the solution is, suffice to say I haven't really seen a good one yet, and until such time as one comes along I am happy using a browser that either lets me turn this stuff off in a blanket fashion or flat out doesn't include it.

Mildly lower friction on payment apps is not enough of a trade-off

</comment></comment></comment></comment></comment></comment></comment><comment><USER55> > 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?

<comment><USER56> 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.

</comment></comment><comment><USER57> 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.

<comment><USER28> 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.

</comment></comment><comment><USER58> I assume this means that APIs such as [https://developer.apple.com/documentation/uikit/uidevice/162...](https://developer.apple.com/documentation/uikit/uidevice/1620042-batterylevel) are not available for their instant apps (the so called "Clips") ?

<comment><USER59> 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.)

</comment></comment><comment><USER60> And yet there's still no reason why they won't add Web Notifications to iOS Safari.

</comment><comment><USER61> 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.

</comment><comment><USER62> 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)

</comment><comment><USER48> 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".

<comment><USER63> Gopher is what you're after.

</comment></comment><comment><USER64> How a proximity sensor can be used for fingerprinting?

</comment><comment><USER65> 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.

<comment> yoz-y It can certainly help tracking but the measure is very coarse. Basically an enum of 6 values.

</comment></comment><comment><USER66> 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.

</comment><comment><AUTHOR> 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...

<comment><USER67> On Safari, when a website wants access to my webcam, it asks me.

<comment><USER68> Cool, so Apple "can" add features to Safari. They should add more.

<comment><USER69> 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.

<comment><USER68> > 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.

</comment></comment></comment></comment></comment><comment><USER70> Cute how Apple wants to make their "users" believe they have an exclusive deal on breaching their privacy.

<comment><USER47> 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.

<comment><USER20> Apple has been increasing displaying rent seeking behavior more and more recently. They're not just trying to make money from HW.

</comment></comment></comment><comment><USER71> Ahhhh the new Internet Explorer...

<comment><USER72> Wrong story, this one isn't about Chrome.</comment></comment>


Simple Bitcoin wallet encrypt&backup script - <AUTHOR> https://github.com/mrkva/BitcoinBackup.sh

<comment><USER2> I'm sure this is fine, but in general I'd want to be sure that anything touching the wallet.dat is safe. Keeping a liquid store of value on one's pc opens it up to new malicious apps knowing exactly what to target. A major client-side security breach would look really bad for bitcoin.

<comment><AUTHOR> Well, it's open source :) But you're right - better check twice every single process.</comment></comment>


Ask HN: How do you use your HN favorites? - <AUTHOR> I save a lot of good posts to HN favorites.  But I usually never get around to doing anything with them.<p>How do you use your HN favorites? <comment><USER2> I wrote some tools to search your HN favorites and export them to CSV or HTML in both JavaScript and Python.

Check out [https://gabrielsroka.github.io/getHNFavorites.js](https://gabrielsroka.github.io/getHNFavorites.js) or to view the source code, see JS: [https://github.com/gabrielsroka/gabrielsroka.github.io/blob/...](https://github.com/gabrielsroka/gabrielsroka.github.io/blob/master/getHNFavorites.js) or Python: [https://github.com/gabrielsroka/gabrielsroka.github.io/blob/...](https://github.com/gabrielsroka/gabrielsroka.github.io/blob/master/getHNFavorites.py)

Previous discussion, other tools and more info:

[https://news.ycombinator.com/item?id=22788236](https://news.ycombinator.com/item?id=22788236)

</comment><comment><USER3> My HN Favorites are very limited. Only those comments that I feel to be timeless or the kind of ones that you specifically don't look for, but has some thought provoking stuff. I add a comment to favorites maybe once in 3 or 4 months. When I favorite a comment, I end up on the page of all my favorites. I take a few mins to go through them.

Other threads/pages of value, that are based on specific topics are filed away in my Zim Notebook, to be referenced when there is a need.

<comment><AUTHOR> I guess I also use my favorites as a sort of bookmark system. This tends to crowd what is in there.

</comment></comment><comment><USER4> I don't use HN favorites. I use Safari bookmarks because they are synced across devices automatically, easily searchable, and encrypted. If I didn't use Apple products I'd probably use a paid bookmarking service like pinboard.

I don't understand why people use website-specific bookmarks like HN or Twitter favorites.

</comment><comment><USER5> Write-only bookmarks and reading list.

</comment><comment><USER6> The stuff that I want to keep a list of, in order to avoid losing it.</comment>


How Ben Franklin made America the land of invention - <AUTHOR> http://kalman.blogs.nytimes.com/2009/07/30/can-do/

<comment><AUTHOR> Other than finding it generally inspirational, I particularly liked the artifact of Benjamin Franklin's daily schedule card/to-do

<comment><USER2> If you like that you'll love his autobiography:

<http://www.gutenberg.org/etext/148>

It's a short read. It's in my top five of all time.

</comment></comment><comment><USER3> Very innovative. But a segue is missing. Ben Franklin's innovations are shown. Other modern world innovations are shown. How Ben Franklin inspired those world innovations is not shown. A link is missing.

</comment><comment><USER4> Fascinating collection. I really enjoyed just looking at these pictures. Thank you for sharing.

</comment><comment><USER5> relentlessly resourceful...</comment>


You don't have to be stupid to work here but it helps - <AUTHOR> https://aeon.co/essays/you-don-t-have-to-be-stupid-to-work-here-but-it-helps <comment><USER2> This article may alternatively be summarized as: "A theory of why Dilbert is so popular..."</comment>


Phones without headphone jacks are phones with DRM for audio - <AUTHOR> https://boingboing.net/2016/06/22/phones-without-headphone-jacks.html <comment><USER2> Yes, you _could_ use it for DRM audio, if we suddenly start seeing phones and corresponding headphones actually supporting it. That'd also be possible with existing headphone jacks.

It seems like baseless scaremongering to me. Especially since jackless phones could still potentially use analogue audio (USB-C sideband pins).

</comment><comment><USER3> But... what if the DRM-encumbered digital jack has an officially authorized analog adapter? That doesn't fix the DRM problem, but it does allow for the same uses as before, particularly if it also supports mini-TOSLINK for S/PDIF. Note that since S/PDIF doesn't have a compatible DRM, it's possible it would be disabled even if a jack were still present.

<comment><USER4> Why would the rights holders agree to this? Note that analogue outputs on video equipment is usually treated with Macrovision or similar.</comment></comment>


Scientists Want to Rebuild Tesla Tower to Solve World's Energy Crisis - <AUTHOR> http://www.messagetoeagle.com/articles1/teslatowerrebuildtry.php

<comment><USER2> "See also:

Did Nikola Tesla Unintentionally Detect Signals From Another Civilization?"

Okay... Back away, slowly...

Do not make any threatening gesture.</comment>


Ask HN: Any todolist sidebar as Googledesktop one? - <AUTHOR> Do you know any todolist that can be locked as Desktop sidebar and not browser sidebar. Full time visual persistent. Just stay there on right side. With android synchronisation. ? <comment><AUTHOR> And same question for android. Any persistent sidebar todolist? Else some programmer want to partner to develop it? All design is ready on my side.</comment>


Ask HN: What is your source for political news? - <AUTHOR> <comment><USER2> Might not be the best one, but The Economist quite decently introduces us to many political issues around the world.

</comment><comment><USER3> MSNBC, nytimes.com, washingtonpost.com, politico.com, thedailybeast.com, and fox news. I check out Fox because they will have the GOP and rightwing viewpoints featured prominently. Sometimes Fox has some things you won't see elsewhere, but usually I marvel at how one-sided, misleading and prejudiced the "conservatives" are. By prejudiced, I mean: how much they distort and throw hate at Democrats and the left.

<comment><USER2> I second NYTimes</comment></comment>


How Stripe's COO approaches company-building [audio] - <AUTHOR> https://lattice.com/resources-for-humans/coo-stripe/?HN <comment><USER2> importance of thinking through whether to have your company organized functionally or around business can't be overstated. Functional orientation makes lack of accountability and can lead to bureaucratic culture and Business orientation can lead to silos and coordination failure.

</comment><comment><USER3> Title should say "company-building".

I was expecting something about how she physically approaches the office.

<comment><USER4> I misread the title as "announces company building", as if they were going to build a Stripe campus.

</comment></comment><comment><USER5> Seriously,why is it that anything,I mean,almost anything about Stripe is almost always occupied front page in Hacker News? Moderator bias?

<comment><USER6> People vote.

<comment><USER7> I think he's saying some of those people could be Stripe employees.

<comment><USER5> Thanks.I am suspecting this as much.If you pay attention for a while in HN,you will notice what I am saying here.

<comment><USER8> HackerNews has sophisticated anti-ringvoting protections, and as dang has explained many times in the past, these or other moderation systems and policies are not relaxed for YC companies; if they were, the community would lose all trust in HN [1].

Also, alleging astroturfing or shilling is explicitly against the guidelines [2]. The right thing to do if you suspect this is flag the post and email the moderators - email@example.com.

There's a far more innocent and likely reason why Stripe gets lots of exposure here: they're in the most successful handful of companies to emerge in the past few years anywhere in the world, and people like learning about what successful companies do.

Which is not to say that it's not boring to see the same kind of content over and over, but again, the right approach is to flag and move on, not allege underhanded conduct without any evidence.

[1] [https://hn.algolia.com/?query=dang%20pg%20chair&sort=byPopul...](https://hn.algolia.com/?query=dang%20pg%20chair&sort=byPopularity&prefix&page=0&dateRange=all&type=comment)

[2] [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER7> > lso, alleging astroturfing or shilling is explicitly against the guidelines > [2]

Thanks for letting me know I wasn't even aware of this.</comment></comment></comment></comment></comment></comment>


Real-Time Stream Processing as Game Changer in a Big Data World - <AUTHOR> http://www.infoq.com/articles/stream-processing-hadoop

<comment><USER2> That's amazing! The entire title is made up of buzzwords!

<comment><USER3> read the title and decided against clicking</comment></comment>


Ask HN: What do I do next? - <AUTHOR>

For kicks and giggles (and honestly to keep my mind sharp), I built a memetracker. It is a good mental vacation from the day job.
It leveraged a lot of my technical interests in algorithms and machine learning. I put the result on the web, and am watching my statcounter flat line. Well, I get some hiccups when my gf visits.
So I guess the internet isn't a "build it and they will come" kind of place. Reality Checks are hard.
I'm not sure what I should be doing next to get the word out. Is there some magic I should be doing. Any veterans out there know what I should do?
Advice and pointers would help. <comment><USER2> The site itself doesn't have content, it has a content aggregation service. That makes it hard to spread in a viral fashion, especially when it's an untargeted service spread amongst many verticals. It's useful, but the "wow check this out" factor is missing.

One improvement would be to add a comment system and rely on UGC to keep people around. But then you have to devise a way to populate stories and make the site look livelier than it is, which may require some kind of comment bot.

Another thing you could do is start drilling down to smaller and smaller niches and try to become a top search result in those, and then work your way back to the huge verticals you currently have. As it is, you are basically competing head-to-head with Google News.

<comment><AUTHOR> Yeah, we don't have content ourselves, our value add is the ranking and filter service. Also, allowing you to see the conversation across the web.

UGC would be tough, because I'm at a chicken and egg state right now as you pointed out. And crap comments would lead to more crap comments. Imagine if Quora or Hacker News had a comment bot. Sets a bad tone for the future.

i guess there may be a flaw in my initial strategy.

when training my algorithm (and as i make iterations), I compare the results to google news to make sure we're as good if not better. That's why a lot of the initial top-level categories match up pretty closely.

Sports vs sports <http://sports.rawsignal.com/> [http://news.google.com/news/section?pz=1&cf=all&ned=...](http://news.google.com/news/section?pz=1&cf=all&ned=us&topic=s&ict=ln)

However, once I'm more confident in the algo, I'll let it loose on something more niche, like college football

<http://collegefb.rawsignal.com/>

that's how we can differentiate from google, but i never realized that having too many options would paralyze people.

maybe if i release each vertical under its own domain . . .

<comment><USER3> I think that nailing down the smaller more focused categories is the way to go. If you can make it both more relevant and more focused it would be both different and useful providing a real reason to give it a try.

<comment><AUTHOR> sure i can work on that next. what initial categories would rock your world?

also, should i brand each category as its own site, or is the current model ok?

<comment><AUTHOR> ok, i put up baseball, basketball, and football:

<http://football.rawsignal.com/> <http://basketball.rawsignal.com/> <http://collegefb.rawsignal.com/> <http://baseball.rawsignal.com/>

had to refungle some code to speed up our analysis, but it should be working. hope you like it.

</comment></comment></comment></comment></comment><comment><USER3> First step: share a link.

<comment><AUTHOR> what are good places to share a link?

The main vertical I'm focused on right now is tech: <http://tech.rawsignal.com/>

although I built other verticals that seem to be working already. Not sure where to share it that would interest people who like tech.

<comment><USER4> Right here.

Regards

</comment></comment></comment><comment><USER3> I'd love to be able to filter or have the system filter even further. For example in sports, just baseball or football not all sports.

<comment><USER3> I do see that you have something that sounds like this coming under your coming soon section so you may already be working on this.

<comment><AUTHOR> yeah. the algorithm I built takes a little training per topic/vertical, but after the initial training, it just starts learning.

I have a long list of potential topics that the algorithm would be good at. pretty much any sports topic it would kick butt on.

My brother keeps telling me I need to split up sports too. Basically, the initial verticals were to stress out the algorithm to make sure it would work on various concepts and still keep things interesting.

Basically, you could imagine every concept <http://alltop.com/> tracks running through my algorithms.

Thanks for the feedback though. That's the kind of information that really helps a hacker getting started.</comment></comment></comment>


Microsoft needs wizards (1984) - <AUTHOR> https://groups.google.com/forum/m/?fromgroups#!msg/net.jobs/CTGh9MHaaWc/qe2ekUD0LE8J

<comment><USER2> _"we never do anything stupid because some manager/MBA/suit-type has power without knowledge."_

The Times They Are a-Changin'

</comment><comment><AUTHOR> Replace "wizard" with "ninja" and this post would fit right in on any tech job board today.</comment>


Microsoft joins the Linux Foundation - <AUTHOR> https://techcrunch.com/2016/11/16/microsoft-joins-the-linux-foundation/ <comment><USER2> I'm fairly certain all of 2016 is a mass-hallucination. Or something.

In all seriousness though, I don't think this is surprising. Visual Studio on macOS is more surprising to me. Azure runs on Linux and that's a really, really big business for Microsoft. And they've also built a Linux Subsystem into Windows.

Rock on Microsoft, rock on.

<comment><USER3> We're really committed to doing our best on being good members of the global developer community, just watch Connect(); // 2016 where this was announced and is streaming live right now. We've got a few more announcements coming :).

[https://connectevent.microsoft.com](https://connectevent.microsoft.com)

<comment><USER2> Awesome! Way back when, I was a huge Microsoft fanboy, until Mac OS X came out, then I hated Microsoft...then I used a Windows Phone from day one until just before Microsoft bought Nokia. And I own a Surface. Definitely come full circle.

</comment></comment></comment><comment><USER4> Wow, this simply would never have happened under Ballmer. It is really great to see what Microsoft is able to do under Satya Nadella. I like what I'm seeing and it will keep Linux honest.

Hell hath frozen over.

<comment><USER5> I'd really like to see some windows compatibility layer for Linux to run Windows applications.

<comment><USER2> Maybe Microsoft will pour a bit of support into WINE?

</comment></comment></comment><comment><USER6> Everyone forgot about [https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish](https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish)

Join Ubuntu into windows add windows-specific hooks and additions for open- source software to build against destroy the backward compatibility end linux

this is what they have always done, why should this time be different

</comment><comment><USER7> Worrying news, when looking at Microsoft's strategy in the past [https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish](https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish)

<comment><USER8> The Linux Foundation may have just accepted a Trojan Horse (or rather, a Redmond Horse). I hope it turns out for good for all. I'd love to see better contributions to Linux. If Microsoft can help make Wine better, then the playing field could be level. But it is scary to think that so many years of open source software available on Linux will eventually be available to Windows users without being ported to Windows, and then Linux suffers more. Hopefully it will be good for all.

</comment></comment><comment><USER9> The lesson that everyone should take here is that corporations change in ways that we could never imagine. (For those that are younger they may not remember Microsoft calling Linux a virus and setting its entire salesforce in motion to spread FUD against Linux).

So, we need to reflect on whether giving corporations our personal data makes sense over the long term rather than just giving it to them because its easy today.

</comment><comment><USER10> Joining a table for open discussion is great, no matter how you look at it.

Also see: [https://news.ycombinator.com/item?id=12967770](https://news.ycombinator.com/item?id=12967770)

</comment><comment><USER11> I think this is great news. Also Shows Microsoft big cow is no longer Windows but Azure. This means software is a commodity, they're really in the infrastructure rental business

</comment><comment><USER12> Well, the hell just frozen. Satya Nadella seems to have really changed MS. Great for them, especially, that I believe Windows to be their worst product.

</comment><comment><USER13> It seems good, but i have doubt, about virus in windows, the can affected to linux too. I don't like that

</comment><comment><USER13> It's seems so good but i have doubt for the virus environment, that's can affect linux users.

</comment><comment><USER14> Am I crazy to have thought this had already happened? What is it I'm think of instead?

</comment><comment><USER15> Trying to destroy linux from the inside. And they are letting them. So sad. But when Microsoft takes over there will always be beautiful minds creating new systems.

</comment><comment><USER16> cant believe I have lived enough to read this news!!

</comment><comment><USER17> What a year!</comment>


Yes I am, Stan. Me too. Deeply frustrated with Firefox. - <AUTHOR> http://rovivor.com/2008/05/yes-i-am-stan-me-too-deeply-frustrated-with-firefox/

<comment><USER2>
      Moreover, I know that I will be facing with more crashes with a beta.

Firefox 3.0b5 hasn't crashed once on my laptop (Ubuntu) or desktop (Vista), and I've been using it since it got released.

On top of that, I can't imagine what you have done to your Firefox 2-install, if it crashes that often and you reach that high CPU- and memory usage.

Something besides the main Firefox install must be fubar'ed...

<comment><USER3> "Firefox 3.0b5 hasn't crashed once on my laptop (Ubuntu)"

You've disabled Flash then, I assume. I can't keep the browser on for much more than an hour here without Flashblock.

Beta 5 is certainly faster and less memory-profligate than 2.0 was, though.

<comment><USER4> _"Firefox 3.0b5 hasn't crashed once on my laptop (Ubuntu)"_

Has for me and maybe it is because I have flash enabled for fox2... thanks for the tipoff.

</comment></comment></comment><comment><USER5> I wasted 2 years of my life working heavily with the Mozilla/XULRunner/FF codebase. The code base is huge and is organized in a manner that makes tracing memory issues very difficult. Unfortunately there are also cultural reasons why things are unlikely to improve in the future. There are simply too many cooks in the kitchen at mozilla, it is very bureaucratic and the engineering team as a whole gets sidetracked by details that don't solve the serious issues in the "platform."

The webkit team is small and agile and was chosen as the web rendering platform for Android, Adobe AIR and the iPhone. For better or worse, WebKit is going to eat Mozilla's lunch.

In a past essay PG suggests that a few people working on a new browser would be a cool project. I completely agree. A tri-platform browser based on WebKit with a wrapper for media (video, audio) and a clean plugin API would be amazing.

</comment><comment><USER6> I really thought I could never switch away from Firefox because of all of the extensions I "couldn't live without," but I started playing with Webkit nightlies a few weeks back and never looked back. It's faster, launches quickly, eats less memory (look! It's only at half a gig!), and has high-res scrolling. The last one, albeit small, is killer for me. Reading articles on the web is a whole difference experience when you have good font rendering and truly smooth scrolling. I use keyboard shortcuts to turn off the location and bookmarks bars most of the time to make the browser get out of my way and let me use my webapps. Goodbye, Firefox!

</comment><comment><USER7> I have Firefox on a Mac, with 23 extensions installed. Very occasionally, it bombs (usually when leaving Gmail) but otherwise it's been fine. Maybe the people who have problems should try, you know, just closing it now and then. Not exactly a high-tech solution, but it works OK for me. Having said that, I often run my computer and Firefox for days at a time.

I would be interested in the alternatives, but afaict they don't exist. Another browser with extensions like Adblock, Web Developer Toolbar, Firebug, etc? I doubt it.

<comment><USER8> Does anyone else have these gmail-crashing problems (e.g., when leaving gmail's site)? I looked at their FAQs and it suggests some problem with firebug, but even with it disabled I often get crashes.

<comment><USER7> It only crashes when I try to _leave_ gmail, and then only about 10% of the time, so it's not a big deal. I think I disabled Firebug when on Gmail. It only started when the latest version of Gmail was introduced, so I suspect it's a bug at their end, but tracking it down could prove awkward.

</comment></comment></comment><comment><USER9> "I am thinking of moving to Opera permanently" - stop thinking about it, just do it.

<comment><USER10> I'd use Opera permanently if it only had a decent inline spell checker. All the options that I've tried don't really cut it.

</comment></comment><comment><USER11> I'm running Firefox 3.0b5 on a PowerBook G4. I seem to have random crashes multiple times a day. Currently, it is fairly common to find that Firefox has crashed upon wake up from sleep. Performance is snappier than FF2, but it is far less stable. I expect that much of this will be sorted out prior to the final release. That said, if it weren't for a couple of extensions that I use regularly, I'd be inclined to make the switch to Safari.

<comment><USER12> You know, that's probably the DOS protection ;)

Over a year ago, if you were using firefox on an ajax enabled site making periodic request to the webservers, firefox would request all the requests it missed while being asleep (hibernate mode) at once when the computer came back to life. :-)

</comment></comment><comment><USER13> I'm running 3.0b5 on a macbook pro with only a few extensions, and it crashes constantly. I upgraded because 2 seemed to crash even more.

</comment><comment><USER14> I am currently just waiting for Safari's Web Inspector tool to reach par with Firebug before I switch to it over Firefox permanently

<comment><USER15> Firebug is a killer app. I would need something like that on another browser before I moved anywhere.

<comment><USER16> Addblock and greasemonkey would be on my cannot-live-without list, also.

<comment><USER17> Mine would be firebug and vimperator.

</comment></comment></comment></comment><comment><USER18> Memory is cheap, guys. 1 gb ram costs ~$30 at newegg.

<comment><USER19> Ah, yes, that most excellent justification for crappy software:

Developer: "It's OK if our program runs slow, processors are getting faster all the time." User: "Your program runs slow..." Developer: "Then get a new computer! More RAM! Faster processor! They're cheap!"

(The user does so. 6 months later, a new version of the software is about to be released...)

Developer: "It's OK if our program runs even slower, processors are getting faster all the time." ...

</comment></comment><comment><USER20> camino.</comment>


Encryption must come standard - <AUTHOR> https://medium.com/@mobitar/encryption-must-come-standard-b5ba7b87a422#.5jl46rj28 <comment><USER2> I'd love to see more web apps that use WebCrypto to encrypt data on the client side, but WebCrypto has a problem. It's hard to trust programs that run on the web. Even if the app promises to encrypt user data, someone in control of the server could read any user's data by singling them out and sending them a different version of the site JavaScript that leaks the user's encryption keys. This means you must trust the server every time you load the web app. Even ServiceWorker apps are affected by this because the browser always checks the server for updates to the worker JavaScript and it does not support any form of code-signing.

The best way to improve the state of client-side crypto on the web would be to close this hole and enable some kind of trust-on-first-use for the web, but it's difficult, because this model of trust is at odds with how the web works. Cyph apparently does something resembling trust-on-first-use on the web by serving a ServiceWorker from a HPKP enabled domain and throwing away the private key, but that's not really what HPKP was designed for.

<comment><AUTHOR> Yeah, it's a tricky topic. For apps that aren't social networks, I think we need to begin trending towards running our own servers and clients. This may not make sense in most cases, but in the case of say, personal notes, this seems obvious. This is why I'm working on an open protocol for encryption and ownership of notes at [https://standardnotes.org](https://standardnotes.org).</comment></comment>


Ask HN: How did my phone figure out my SO's name and that we were having dinner - <AUTHOR> Last night I was having dinner with my girlfriend and my phone gave me a notification saying something like "Silenced your phone for Dinner with $HER_FIRST_NAME $HER_LAST_INITIAL" (with the variables replaced)
The notification came from an app I've had for a while that puts my phone on silent when I have a calendar event, but I never made a calendar event for having dinner with my girlfriend. I searched all my calendars on my phone and found that there was never an event titled "Dinner with $HER_FIRST_NAME $HER_LAST_INITIAL", nor were there any calendar events for that night at all.
I can see how an app could guess that I'm having dinner based on the time and my timezone. But how did it know the name of the person I was having dinner with?
Edit: For reference, my girlfriend is not using that app, and she's using an Android phone, while I'm using an iPhone. This is the app that gave me the notification:
https://itunes.apple.com/us/app/autosilent/id474777148?mt=8 <comment><USER2> I'm going to say Siri Suggestions

</comment><comment><USER3> scary but not surprising.</comment>


The Year of Mobile Payments - <AUTHOR> http://techcrunch.com/2015/04/19/the-year-of-mobile-payments/

<comment><USER2> Does anyone know how these services are secured? What do I need other than a phone to send money to someone? What happens if I lose my phone?</comment>


Did Blowing Into The NES Cartridge Really Work? - <AUTHOR> http://www.mentalfloss.com/blogs/archives/142550 <comment><USER2> As a wee lad in the last millennium I was an authorized Nintendo repairman.

Blowing on the cart sometimes worked, if there was errant dust or fluff in the way. But in the long run the salty moist air would cause a corrosive layer of gunk on the contacts. Normal procedure was to open each cart and clean them with a good eraser then an alcohol wash.

The bigger problem was bad design in the original NES. The cart plugged into a component that looked like a harmonica and then pressed downwards, levering against a pretty heavy spring. This perpendicular stress caused the contacts to break, first causing contact flakiness, then failure. The SuperNES and GameBoy fixed this problem with a vertical insertion that carried over into the N64 and others.

<comment><USER3> The force was actually borne by the contacts? Man. You'd think they would have put the contacts on something more flexible, and transmit the force with the outer covering.

<comment><USER2> Yep. I think the idea was to make it behave like the toploading VCRs which were around at the time: insert then press down. Very often customers would refer to the cartridges as "Nintendo tapes".

<comment><USER3> Sure, the American NES was deliberately designed that way in order to not look so much like a video game device, because everybody was paranoid due to the video game crash having happened recently.

I'm really asking a mechanical question. Basically, if you're going to build an insert-and-press-down device, it would make sense to have a mechanical system to handle all of that _separately_ from the electrical contacts. Basically, you'd have the cartridge slide into some kind of device which captures it and has the springs and latches to make the system work as desired. Within that device, you'd also have the electrical contacts with the cartridge, but set up so that the fragile electrical contacts don't actually transmit the spring's force, which goes through the outer frame instead. You made it sound like the force got transmitted directly through the electrical contacts without any separate spring-loaded device, which seems like a pretty obvious failure point.

</comment></comment></comment></comment><comment><USER4> Or if you're really brave you could just replace the 72-pin reader:

[http://www.amazon.com/Nintendo-NES-Cartridge-Slot- Replacemen...](http://www.amazon.com/Nintendo-NES-Cartridge-Slot- Replacement/dp/B004FO6PZG)

<https://nuxx.net/wiki/NES_72-Pin_Edge_Connector_Replacement>

I did it on mine in college -- and then I did it for my suite-mate after he noticed that I never had any problems with my NES -- and then I did it for everyone on my floor who had an NES... :) Works like brand new.

<comment><USER5> Alternatively, if you're really, really brave, you could do what I did: disassemble the NES down to the header, and use a small screwdriver to bend the pins slightly back into position.

However, it is easy to bend them _too_ far, and increase the insertion force required to actually load the game. Or worse, snap off one of the contacts.

I did this with an NES that I purchased for $5 off eBay (over 10 years ago), and have had no problems since. I believe this was a year or two before the 72-pin replacement was widely available.

<comment><USER6> That's not really being brave ; I mean, it's not dangerous. The NES is very serviceable.

<comment><USER5> I guess I forgot to mention that you have to play Mumblety-peg after bending each pin.

</comment></comment></comment></comment><comment><USER7> I was an kid pre-NES, and got an old system at a yard sale for my kids. I quickly learned that I could reseat it 20 times, clean it with alcohol, pencil eraser, whatever sane tactic, none of them worked as often as blowing into the cartridge.

I had never heard of blowing into the cartridge before. I didn't get the technique from other kids, and I had never had to do it with Atari, Intellivision, C64, or any other system. I learned it out of desperation, and it worked. I don't care what scientific evidence or common sense points to the contrary, it worked.

<comment><USER8> Completely agree. I was the kinda kid that built his own crystal radio and endless science kits like that.

I used alcohol QTip and blowing, both self-discovered methods. And both equally effective, but solved different problems.

</comment></comment><comment><USER9> I obviously havent matured very much because the 10 year old in me wants to say "nah-ah blowing works every time"

Perhaps I was kidding myself all those years but I swear the games would work after blowing on them. Oh well not the first time Ive found a fundamental of life was all a lie (and yes the trick to getting Nintendo games to work was a fundamental life skill back then)

<comment><USER10> I actually think it wasn't blowing on them that did it, but the act of blowing on them and then inserting the cartridge more deliberately the next time. And each time after that, being more deliberate. It was the act of putting it in 'just right' that did it, not blowing at all.

</comment></comment><comment><USER11> What always worked for me was inserting a 3x2 Lego piece, oriented vertically, between the cartridge and the top of the NES container. This pushed down the game by about 3-4mm. This trick was common knowledge in the neighborhood where I lived during the mid 80s.

<comment><USER12> Our trick was that once the cartridge was pushed down, you could slide it left and right a tiny bit into place until the pins lined up, then it would work.

</comment></comment><comment><USER13> So I used to pull out Unibus cards from the PDP-11 and rub the contacts with a pencil eraser to get the corrosion off them. HP machines of course had literally gold plated connectors which did not corrode pretty much ever.

</comment><comment><USER14> The trick that always worked for me was to insert the cartridge and then pull it out just enough to where the near edge of the cartridge would just barely scrape against the console as it was pushed down. This was far more effective than blowing on the cartridge.

<comment><USER15> I did that too! Man, this article is taking me back...

<comment><USER16> Taking you back?

My house mate and I are currently moving through our Killer Instinct phase on SNES, and I just lent my NES to my 18 year old sister and her boyfriend who borrow it regularly.

I'm taking this article very seriously, as I am from the family of people who blew in the cartridges (and the console) up until I read this :)

<comment><USER17> Is it really worth it the risks to play on the real thing? I don't have my NES anymore (my parents convinced me to give it away when I got an N64), but I think that I'd still use an emulator and boot it only once every few months rather than risking breaking it. And using It Might Be NES (emulator for the PS1/One/2) on a CRT TV is almost the same anyway ;)

Now, I realize there's no point in having something without using it, but my point is if parsimony isn't a better policy.

</comment></comment></comment></comment><comment><USER18> It was a revelation when I decided to try actually cleaning the contacts on a NES. The results of a little alcohol and a brush made of folded notebook paper earned me the reputation of a magician in my circle of friends.

</comment><comment><USER19> The "Placebo Effect" isn't "something tricking you into thinking it works" - it's the fact that _having_ a belief that something works produces better outcomes. I doubt that the mental state of the child has any detectable or consistent effect on the function of the console.

<comment><USER20> He probably meant to write "Superstition".

</comment></comment><comment><USER21> This is the second report I've read that says that it doesn't help. But there's something these reports are missing, because the simple fact is that it DID work. I've personally proven the hypothesis a hundred times in my childhood: (re)insert cartridge X times -- doesn't work -- blow -- works. It was extremely rare that blowing did nothing in my experience, and the solution in those cases? blow harder.

</comment><comment><USER22> After reading the sidebar about the kid who licked his cartridges, I completely forgot about the original article.

<comment><USER23> That used to work with ISA cards in the late 80s for me :)

It made the corrosion worse in the long run but it worked good enough for a bit.

A friend of mine used spit as solder flux as well once. Worked quite well.

</comment></comment><comment><USER24> I always found that if blowing no longer worked, that I could plug it into the Game Genie loader and it would usually work. I suspect because the fit into the Genie was much tighter and the pins were less worn or corroded.

<comment><USER25> Definitely. Around my old neighborhood, Game Genie was a highly prized accessory if only for that reason. Cheating was all well and good, but having your Nintendo actually work? That was the real advantage!

</comment></comment><comment><USER26> The Game Genie is a mini cartridge that attaches to a game cart (to apply cheats/mods through a code-entry screen). This combo is then inserted into the NES, Game Genie-first. The combo is too long to be pushed down, and the NES door remains open while playing.

I never understood why you don't need to push "down" the Game Genie; a bare cart would never function unless pushed down...

Nevertheless, every game I had that would not work in the NES would work just fine with the Game Genie attached (and you can always choose to enter zero cheat codes). The Game Genie seemed to make everything a bit tighter. When inserted into the NES, there isn't much wiggle room, if I recall.

edit: Wikipedia says, "Therefore, the Game Genie was designed in such a way that it did not need to be depressed in order to start the game. This design put even more stress on the ZIF socket than standard game insertion, bending pins and eventually causing units to be unplayable without the Game Genie present." <https://en.wikipedia.org/wiki/Game_Genie>

<comment><USER27> you didn't need to push down on the game genie, because the "push down" was to enable the CIC lockout chip. Galoob spent a considerable amount of time (and legal fees) bypassing the CIC chip. this allowed all games to run without problems on most NES systems.

</comment></comment><comment><USER28> The trick is to filter the cartridge opening with your shirt THEN blow into it.

<comment><USER29> I did that as well, but I don't think that actually makes anything better. Your breath is very moist and when you blow through your shirt, you're still getting essentially all of it.

</comment></comment><comment><USER30> I'm surprised seeing those photos of the game boards outside their cartridges. Not only are they _much_ smaller than the cartridge, but they are really just some memory and the lock-out chip!

<comment><USER31> The article didn't include any pictures of Famicom carts, but basically, they're about half as tall as NES cartridges. I haven't popped open any NES games, but I'd have to guess most, if not all NES games just used a Famicom sized board to simplify manufacturing. Here's a comparison shot of the NES and Famicom versions of Super Mario Bros. 3:

[http://www.vintagecomputing.com/wp- content/images/smb3j_labe...](http://www.vintagecomputing.com/wp- content/images/smb3j_label/nesfam_2_large.jpg)

While most later systems featured mostly standardized cartridge designs, Famicom carts wildly vary in color and design from publisher to publisher. They're quite pleasing to look at:

[http://famicomblog.blogspot.com/2009/12/aesthetics-of- famico...](http://famicomblog.blogspot.com/2009/12/aesthetics-of-famicom- cart.html)

Another piece of trivia: The Famicom had a 60 pin cartridge port, while the NES had a 72 pin cartridge port (iirc they removed a few pins, relocated a few from the Famicom's bottom port, and added pins for the lockout chips). A few early games literally consisted of a Famicom game board plugged into an internal 60-to-72 pin adapter. So, for a while, the cheapest way to get a Famicom converter was to rip apart a cheap game like Gyromite and hope it was part of a certain run. You can see the converter clearly here:

[http://www.vintagecomputing.com/wp- content/gyro/gyro7_big.jp...](http://www.vintagecomputing.com/wp- content/gyro/gyro7_big.jpg)

As for technical details, you're mostly on the dot, but most later games also featured mapper circuitry to allow the NES to address more memory. Some boards used simple 7400 series, while others used customs ICs, some of which were fairly expensive, to expand the system's capabilities. Simpler ones just allowed for more complex bank switching schemes, while the most expensive ones featured things like interrupt generators and additional sound generating hardware. The sky is the limit for what you can stuff in a game cartridge, so the NES and SNES were designed to be very expandable through their cartridge ports. That's part of what makes cartridge-based games special to me; they're not just data on a disc, they're full-fledged hardware extensions of their host console.

</comment></comment><comment><USER32> I used to blow in them, but I found that the double cartridge technique (putting two in at a time causing the pins to press harder) worked a lot better. Sometimes if things were really bad a 'snap-in' technique would work. To perform this technique you insert the cartridge partially and then apply downward pressure causing the cartridge to forcefully jump into the slot. This was likely very bad for the system :)

<comment><USER5> Didn't the front-loading NES have a metal bar across the top of the loading mechanism? How were you able to fit a second game past that?

<comment><USER32> It goes on top of the bar :). This means the game you are playing is depressed much lower than usual.

</comment></comment></comment><comment><USER33> I don't think I ever blew into my NES cartridges, but I remember taking them out, giving them a gentle shake with the connector end pointing down, and putting them back in. I expect doing this was as much a placebo as blowing (it's not as if there were chip crumbs stuck in there), but it made me feel like I was doing something productive. :/

</comment><comment><USER34> I had a religious friend that would force us all to hold hands and say a prayer. It worked half the time too.

</comment><comment><USER35> Is it possible the moisture caused by blowing into the cartridge allowed for better electric conductivity?

</comment><comment><USER36> We all thought it worked :) All of my friends with NES growing up encountered the same problems overtime. It was clearly a design problem as described in the article. The SNES was so well designed, I still use it to this day (almost 20 years later).

</comment><comment><USER27> Holy crap, everyone is wrong. I didn't think I'd see this day on HN.

The reason people resorted to blowing in the cartridges is because of the CIC chip. The so-called "Lock-Out" chip on the NES is responsible for the Blinking power button and games not working.

"Sometimes," I hear some of you say, "You'd take the game out, put it back in, and it'd sometimes work. Why?" Well, imaginary question-asker, because the a faulty CIC will work sporadically. if the code passes the CIC check, it continues without issue. if the CIC fails halfway through your game, your game doesn't stop working. If you power cycled the system, then you'd notice the CIC failure. Blowing on the cartridge worked for the same reason doing 200 pushups will make water boil.

Nesdev.org has a decent amount of information about this chip on their wiki, if anyone's interested.

TL;DR - clip two pins on the CIC chip, never blow in a NES cartridge again.

<comment><USER37> I'd say they're not wrong as much as just not addressing that particular complaint.

<comment><USER27> They were addressing whether or not blowing in a cartridge fixed a problem. The same problem the CIC lockout chip was responsible for.

Therefore, they were addressing whether or not ignoring the CIC lockout chip fixed or alleviated a problem. clearly, it does not.

Perhaps you can explain how ignoring the cause of the entire problem, blaming the cartridge slot, and then working from a false presumption mean that they're not wrong?

</comment></comment></comment><comment><USER38> In my experience, DS cartridges are far worse than NES cartridges for this issue. I don't know how they corrode the way they do, but I've sent my carts to Nintendo numerous times for replacement.

</comment><comment><USER39> What a stupid article. You're supposed to _cough_ into the cartridge, not blow in it. Then you insert the cartridge, slap the system's sides twice, and power on

</comment><comment><USER40> I remember using rubbing alcohol on a q-tip against both sides of the connector. That seemed to work well when blowing on it and rubbing it with your shirt didn't.

<comment><USER41> Isopropyl alcohol as sold in US drugstores/grocery stores is about 30% water, though, and the alcohol evaporates a lot faster. So for the most part, those who were cleaning their cartridge edge connectors with rubbing alcohol might as well have been breathing on them or using water by itself.

One thing I couldn't tell from the article was whether those fingers actually were bare copper, or gold plated. If they were bare copper, I'm amazed that they lasted a week. If they were gold-plated, then the connection problems would have been strictly in the harmonica connector inside the console itself, at least until people started using pencil erasers. Blowing on the cartridge itself would certainly have had no effect.

Another possibility is that Nintendo made the mistake of flashing gold directly over copper when they should have used an intermediate layer of nickel for passivation. This would probably result in connections that were better than bare copper would have provided but not as reliable as a proper surface treatment would have been.

</comment></comment><comment><USER42> That "experiment" tested whether excessive blowing damages a working cartridge, not whether target blowing fixes a damaged cartridge.

</comment><comment><USER43> What about the Sega Master System ? I remember blowing my cartridges (also, I'm not in the US), but I may be confusing.

</comment><comment><USER44> I thought blowing into the NES cartridge flipped the cosmic bits inside so that it may be played once more?

</comment><comment><USER45> Article had a way too low signal/noise ratio. Way too verbose.

</comment><comment><USER46> I got a NES a few days ago with some games. Yes, blowing into the cartridge works just as it always has. It can take 10 tries without blowing without getting any video/audio, but blowing another game once or twice and the game is on.</comment>


How can I use transpilation or a VM to safely run code in the browser? - <AUTHOR> http://stackoverflow.com/q/42776357/3229684 <comment><AUTHOR> Disclaimer/full disclosure: this is my own question that I just asked on SO. I'm surfacing it here because I think it will be interesting to the HN demographic. Opinions/feedback/discussion about this type of post is welcome.

I'm guessing almost everyone here has an SO account so feel free to answer there directly and/or also comment here.</comment>