Rapid DHCP: Or, how do Macs get on the network so fast? - <AUTHOR> http://cafbit.com/entry/rapid_dhcp_or_how_do <comment><USER2> _> This network recognition technique allows the Mac to very rapidly discover if it is connected to a known network. If the network is recognized (and presumably if the Mac knows that the DHCP lease is still active), it immediately and presumptuously configures its IP interface with the address it knows is good for this network._

Ok, seriously? That isn't a bug in an implementation somewhere, but in fact a feature that Apple actually is proud of? Am I the only one who finds that if you get a room full of people sitting around with Macs at least one person gets their IP address stolen by someone else?

(edit: I just got downvoted, and then asked the people in the room with me, and they seemed to agree with my perceived correlation regarding the "another computer is using 22.214.171.124" issue... instead of just downvoting, maybe reply? It is actually quite common that DHCP leases on a network get reset for various reasons, and if you just jump on the network without revalidating your lease, you are actually quite likely to just "presumptuously" steal someone else's IP address.)

<comment><USER3> The DHCP stack in iOS does some profiling that should reliably detect whether it is, in fact, on the network that it expects. The most significant of which is the verification of the DHCP server's Ethernet address as correlated to IP.

If you are on a known network, your DHCP lease is still active, and network equipment is working as expected, all of these assumptions are safe. The most common failure scenario is where the DHCP server has lost its DHCP lease table. For many consumer routers, this will occur when the router is rebooted. If you have to reboot your router frequently, you should replace it. Even if you do encounter a failure mode, the error will clear a second or two later when a new address is negotiated via DHCP and the subsequent ARP update.

This is very clearly a trade-off. Devices like the iPhone and iPad are switched on and off very frequently. The difference between 10s to network ready and 0.3s to network ready is more than significant; it's monumental. This is especially true for devices whose use-pattern will involve frequent on-off usage.

If you're uncomfortable with this trade off, you should stay away from Apple devices. Personally, I'll take the 10s.

<comment><USER2> Down-thread of this comment, people have already discussed numerous issues with the assumption that DHCP leases are stable when not in use (such as that servers often choose to allocate out of an artificially small pool of addresses, and ping old addresses to determine if they are in use before simply reclaiming and reassigning them).

<comment><USER3> Like I said, if you're uncomfortable with the trade-off, avoid Apple devices. Personally, I only see the number of devices like the iPad/iPhone increasing, and I'm relatively confident that your normal user doesn't give a damn about any of this. They want the device to work when they turn it on.

I'd also argue that any DHCP server that applies that policy of artificially limiting the IP pool by re-issuing non-expired leases is an asinine implementation.

<comment><USER4>
      > They want the device to work when they turn it on.

If there is a collision, then this doesn't 'just work' when the user turns it on. Just sayin'. From the user's perspective the device should never fail, in any situation, for any reason... ever. Users don't care about trade-offs because they don't want to trade anything off, they want it all, 5 minutes ago.

<comment><USER5> > If there is a collision, then this doesn't 'just work' when the user turns > it on.

No, it just potentially kicks off another user. I've never been unable to acquire an IP because of this practice, I've just seen other people's wireless mysteriously give up the ghost when I connect with my iPhone or Mac. I would prefer to have the aggressive device, personally.

<comment><USER6> > I would prefer to have the aggressive device, personally.

So, by basic game theory, everyone implements 'asshole mode' in their devices. What happens on a technical level when every device behaves like that?

<comment><USER7> Router vendors start saving DHCP lease tables to stable storage and the issue is fixed?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I do not appreciate when my Mac just guesses a network setup and lies about being online instead of just waiting to see what is really there.

It not fun to delete or rename a wifi network while debugging connectivity issues, only to have m Mac lie and say it is still connected to the network that no longer exists.

</comment><comment><USER9> This is a great example of Apple's detail-oriented focus on real-world user experience, and helps explain why people prefer Macs even if they can't always explain why. Lots of little things just work better. You (where "you" == myself and many others, even if not /you/ personally) are left overall with an experience of less frustration.

<comment><USER10> Well, in that case they might not be following the protocol. And in some cases break the connectivity for others...

<comment><USER11> DHCP (rfc2131) doesn't really talk about IP exhaustion.

It's undefined behavior, and there's a bunch of people in here saying that server's have every right to violate DHCP leases, otherwise someone can take over a network by continually claiming all of a Class C by continually making DHCP requests.

That argument makes sense, but it goes very strongly against the grain of what I would think a DHCP lease meant, whcih is that it's a contract for a specific amount of time. If it is indeed a contract for a specific amount of time, the client has every right to claim what they're contractually obliged to. This was my initial assumption, and I believe it's Apple's rather valid assumption.

It's not a case of Apple not following the protocol. It's a case of the real world being more complex than the protocol.

<comment><USER12> Look at parts 3.1, 3.2, 4.4 and Fig. 5 of the DHCP protocol. They describe what a client must do on initialization. For example, section 3.2 describes what a client should do if they have a previously assigned addressed they would like to keep using. It seems to me the behavior here is very precisely defined.

Maybe a networking expert can correct me but it seems to me that those initial ARP requests before the DHCP request are not exactly in accordance with the protocol.

</comment></comment></comment></comment><comment><USER13> Anecdotally, my mac is absolutely horrible at connecting to my wifi. I often have to try multiple times and some times I give up, have to walk over to the router and restart it before I can get on. Probably an issue with the router ultimately, but I don't have this problem with other devices.

<comment><USER14> The only time Ive ever had issues with OS X connecting to wifi was while using a cheapo router that insisted on advertising its 2.4GHz and 5GHz networks using the same SSID.

Moving to a router that allowed them to be configured with different SSIDs resolved all my issues.

<comment><USER5> > The only time Ive ever had issues with OS X connecting to wifi was while > using a cheapo router that insisted on advertising its 2.4GHz and 5GHz > networks using the same SSID.

That is the default behaviour for an Airport Extreme.

</comment></comment></comment><comment><USER15> _There already exists a minimal DHCP client implementation in the Linux kernel, but it lacks certain features such as configuring the DNS nameservers._

I wonder if it is possible to use the kernel-level DHCP client to instantly request the IP address while asynchronously initiating the more functional user-mode dhclient?

Once dhclient is up, and the kernel DHCP client has obtained an IP address it could just pass that to the DHClient to make another DHCP request with the same IP but the additional DNS nameservers, etc. The DHCP server would just see this as a re-request for the same IP address from the same MAC address and would just re-ACK.

This would save the time it takes to initiate dhclient to then perform the initial IP address check + request.

EDIT: in fact, I don't get (from the OP's link) why dhclient couldn't just be forced to accept the IP address passed to it by the kernel DHCP client, and bind it with the nameservers/any other info locally without needing to make another round-trip to the DHCP server.

<comment><USER12> The whole kernel discussion seems to be a red herring. The reason the android device was so slow is because the DHCP server timed out twice on a DHCP request. Those two timeouts caused 10s of the 11s delay.

I think there probably was something wrong with the DHCP server configuration.

<comment><USER16> It timed out because it wasn't there, not because it was misconfigured. The tablet was revalidating its previous lease, which was from a different network - so it was sending the request to the previously-known server address.

<comment><USER12> I am pretty sure that request is supposed to be broadcast across the entire subnet.

</comment></comment></comment></comment><comment><USER17> This implementation by the Mac feels wrong. I mean it appears to work, but it seems like a violation of the protocol and can result in problems on the network. Maybe security issues (?). I'm not an expert in any of these things, but I'd love to hear a network protocol/security experts take on this.

<comment><USER18> This certainly smells fishy, the client is relying on ARP to assume its OK to reclaim that IP address before it actually gets the authoritative answer from the DHCP server. IP networking does not require that computers submit to dhcp, so depending on how you look at it, it probably doesn't run afoul of the spec.

I'd have to get a more detailed packet capture and reference some RFCs, but given DHCP isn't manditory, I don't think it would be harmful to the mac or network as long as the client's DHCP lease was still valid when it pulled this stunt, otherwise you could get multiple clients claiming the same IP address.

From a security standpoint rather than only revealing just your most recently DHCP-assigned address, you're revealing both the mac address of the nearest layer 2 device and gateway ip of (some nonzero number of) networks you've recently connected to. If a hostile network were to monitor the arp requests to successfully emulate a network the connecting mac had recently been connected to, the IP traffic prior to DHCP ACK that was abridged in the article would probably be sent again. Not knowing what it contained, I can't speculate as to if it would be any different than the network communication that would be done if connecting to a new network.

(Even if everything else was application traffic, I don't anything about the udp/192 protocol for airports, but it may be spoken with assumptions made about the connected network and a vector worth exploring).

<comment><USER19> Regarding your security statement, I didn't get that from the packet capture. The Mac is sending an ARP request for the IP addresses of the DHCP servers of networks it's been on recently. An attacker would need to know the correct MAC address to respond with -- the Mac is not sending that out in the request.

If the ARP comes back with the cached MAC address for that network, the Mac continues using the valid DHCP lease it was given. It sends a DHCP request to renew that lease, and I assume would reconfigure the interface if the request fails and discovery has to start over.

From my recollection of the DHCP RFC, if a server hands you a lease for one week, you're allowed to use that address for a week, even if you go offline for 3 days in the middle. In practice, this may not be the case.

<comment><USER18> _the Mac is not sending that out in the request._

I could be wrong about this, as I haven't analyzed actual arp requests in ages, but from the article it appears the arp requests are unicast to the (at least in the example) cached MAC for the gateway.

<comment><USER19> Ah, after a closer look at the original article, I see that now. Curious that Apple would choose to unicast those requests.

<comment><USER16> It does this to verify that the DHCP server has the same MAC address as the one that it remembers. If the server that it remembers isn't present on the current network, the unicast packet should be ignored.

</comment></comment></comment></comment></comment></comment><comment><USER20> I've sat in many a meeting where the Macs "steal" all of the DHCP connections and I'm stuck watching the speaker instead of following TweetDeck.

<comment><USER21> I've had my wife's macbook bump mine off the network by stealing the IP my machine is using. Definitely an inconvenience when on skype.

<comment><USER22> Yeah, it does seem like slightly anti-social behaviour (basically, it's asking for forgiveness rather than permission). At least on your home-network, this seems like it could be fixed by assigning your machines permanent addresses or making the router give out much more long lived DHCP leases.

</comment></comment></comment><comment><USER23> Another nice trick of OS X is its use of IPv6, also for its multicast DNS (Bonjour) networking. This means you can have a bonjour session up and running long before you have an IPv4 address, especially in the absence of a DHCP server. It's what allows plugging a network cable between two macs and immediately start using NFS.

</comment><comment><USER24> Does anyone remember this? Princeton Information Technology: "iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address"

[http://www.net.princeton.edu/announcements/ipad- iphoneos32-s...](http://www.net.princeton.edu/announcements/ipad- iphoneos32-stops-renewing-lease-keeps-using-IP-address.html)

<comment><USER25> Very interesting. It sounds like they had some troubles getting this to a properly working state.

</comment></comment><comment><USER26> One of my favorite features from way back involved running a local X Server and a number of remote X clients tunneling over ssh. I close the lid, pick up the laptop and go for lunch. Come back and open the lid and wifi is reconnected immediately and the remote X clients and SSH shells are still alive and active.

And that was 6 years ago on a PPC iBook.

</comment><comment><USER27> Rather than asking why the mac is so fast, the correct question is "why the hell is dhcpcd so slow?". There's a full second before it does anything.

<comment><USER28> I think it's apples and oranges to some degree - a macbook pro with a venerable operating system versus a tablet with one that's still heavily in development.

Better to compare galaxy vs ipad tablets, or osx vs other unix vs windows

<comment><USER29> The tablet is using dhcpcd, which is plenty venerable.

</comment></comment></comment><comment><USER30> I'd like one person who's claiming this behavior is causing networking issues, is non standard, or is a security risk to provide proof.

Suppose for a second that Apple's networking stack ruined things for other users, were in violation of standards, or insecure. They'd be lambasted. Furthermore, their users would have a sub-par experience. Bad press and, more importantly, a poor user experience are two things Apple tries to minimize. They'll only put up with bad press when they perceive it to be at the long- term benefit of their business, as with the iOS App Store. I assert this is not one of those cases.

What seems more likely is that Apple decided device connectivity and wake- from-sleep performance is paramount, and then aggressively optimize to ensure Apple devices are awake and connected as quickly as possible. Period.

Users hate waiting for a machine (or phone) to wake up and, once awake, they hate waiting for it to be usable. It seems Apple saw this pain point and decided to do something about it. And, as breaking standards compliance or introducing security risks would do nothing more than bring bad press and anger or frighten users, they almost certainly optimized in a standards- compliant and secure manner.

I'm happy to be proven wrong. In the meantime, I'm going to appreciate the attention to detail and respect the work that went into providing this experience.

</comment><comment><USER31> The mac implementation is good for 99% of the times, since it is really fast, but the 1% of the times that it steals an ip adress it is really a pain in the ass. I don't mind to wait a few seconds to get a connection in the stardard way.

<comment><USER32> _...but the 1% of the times that it steals an ip adress..._

Could someone explain how we're imagining this might happen? If my Dell Precision laptop is using the contended IP Address, then why didn't its interface's mac address get returned by the ARP who-has request for that IP?

<comment><USER16> The problem may well be that specific ARP request - the one at 0.0180 in the original article. It appears to have a non-zero sender IP address, which means it doesn't conform to a classic ARP probe. The Dell Precision laptop, upon seeing an ARP request appearing to come _from_ itself, might well decide that an address conflict is occuring.

</comment></comment></comment><comment><USER33> Interesting. I have Arch Linux running on a Asus Eee pc and I was always happy that it was connected and ready to go as soon as I woke it up from sleep (including WiFi). I can access the internet within a second of waking it up. I'm using NetworkManager and I wonder if it isn't doing something similar? But then everyone else on Linux is claiming it takes much longer.

<comment><USER34> Huh, interesting. My Asus EeePC 1000 has the slowest network sign-on of any of my devices, but I'm running Ubuntu 10.04 on it. I wonder of Arch Linux has better Wi-Fi drivers or something. I the author of the original blog post, and I performed a similar protocol analysis on my EeePC. Surprisingly, the DHCP handshaking was actually pretty fast, it just seems to take a long time to establish the link. I should really upgrade the OS one of these days.

<comment><USER33> I have a EeePC 900A and the driver for wireless is by far the best I've experienced on Linux.

</comment></comment></comment><comment><USER35> It seems a little unscientific to compare logs from one machine connecting to a new networking and having to get a lease to another connecting to a network it's been on before.

<comment><USER34> It is unscientific. A more comprehensive study would analyze each device in a variety of well-defined scenarios, but in the interest of time I just took a few captures and put a couple under the microscope. I hope I didn't come across as trying to directly compare the tablet's ~11.8s startup on a fresh network to the Mac's ~0.03s startup on a known network. I know that the Mac is faster than my other devices via subjective observation, so I was mostly just interested in comparing the differences in the packets during this process.

</comment></comment><comment><USER36> So, as far as I understand, the issue pointed out here is that the Mac is sending ARP requests with a cached source IP address (which therefore could be already in use).

I wonder why it does that, as you can also send ARP probes originating from a source IP address 0.0.0.0 (and only having the MAC address set). I just tried it on linux:

arping -D -c 1 -I wlan0 172.22.36.1

The computer with 172.22.36.1 will happily send me back its MAC address.

So, is Apple doing something else here? Maybe relying on the router to not poison its cache and not reply at all if the IP is already taken.

<comment><USER3> There are three phases here:

1st phase is networking discovery. During this phase, the Mac is sending ARP who-has requests, which are "anyone out there" requests, not, "hey, I'm using this" requests.

2nd phase is the assumption. If the DHCP client in iOS is able to verify the Ethernet and IP address of the DHCP server match it's suspected network profile, and it has a valid DHCP lease record for that network, it assigns that IP to the interface and begins using it, at which point any potential ARP poisoning would occur.

3rd phase is DHCP negotiation. The first actual DHCP request goes out at 00.0140s, which is after the initial ARP network profiling, but before the interface actually comes up, so these actions could be considered asynchronous. Once the DHCP negotiation completes, any incorrect assumptions are abandoned and the DHCP issued IP would be used.

There appears to be a window of 1.0s where the device is using an assumed IP address. During this time, traffic transmitted on the network would "poison" the ARP cache, but IP conflicts are not an end of the world scenario in networking terms. Once the proper DHCP resolution occurs, the ARP table would be updated and the conflict resolved.

</comment></comment><comment><USER37> Interesting on the perspectives here. My macbook is faster at reconnecting than my linux laptop was, but it's still a few seconds. When I'm opening the lid, I typically still need to wait 2-4 seconds before the network is usable, sometimes it's a bit more. In comparison, it's still faster, but not 'instantaneous' as some people seem to suggest. Neither of my macbooks have been "instant" (but again, certainly faster than other hardware I've owned).

<comment><USER38> Huh, interesting. I have my Mac set up to require a password coming out of sleep. 90% of the time, by the time I've typed my password and hit enter, not only am I reconnected to my wifi network, but even Adium has had time to reconnect me to GTalk and finish fetching online contacts. It's amazing. When I'm in Linux I can't do anything with the network for a good 15 seconds after unlocking my screen.

<comment><USER37> I don't usually have a password requirement, so I have that much longer to notice it. But even when I did have a setup like yours, it doesn't take me that long to type brandy6 and hit enter. I'd still ending noticing a wait.

<comment><USER38> Huh, I wonder if there are just differences in the wifi chipsets and/or between the router(s) you and I have used that make the wait longer or shorter. Weird.

</comment></comment></comment></comment><comment><USER39> When coming out of sleep, my Macs often get a new computer name in the form of a " (N)" suffix; e.g., a Mac named "vision" will come out of sleep and mysteriously change its name (as reported in System Preferences->Sharing) to "vision (2)", then "vision (3)" after a subsequent sleep, etc.

It's annoying. I wonder if this rapid DHCP implementation has anything to do with that.

<comment><USER40> DHCP allows the computer to send a computer name to the DHCP server, the server can then dynamically set DNS entries based on the computer name.

DHCP is also allowed to send back a new hostname (the reason why on Mac's sometimes depending on the network you are connected to a different hostname is shown on the command line). What is most likely happening here is that your DHCP server is sending you a new hostname because it is not letting your Mac use its old lease for one reason or another.

<comment><USER39> I can't rule that explanation out, but I think it's unlikely in this case: my DHCP server knows the MAC address of all of my machines, uses a static MAC->IP mapping, and doesn't update DNS (which is also static). The IP and hostname (as reported by `hostname`) are always correct; it's just the name as reported in the Sharing preference pane and in Finder from other machines on that network that gets the " (N)" suffix.

</comment></comment></comment><comment><USER41> Are there any examples of corporate networks that would reject this approach? I worked on a project in a Wi-Fi environment in a warehouse and the network admins of the company pored over sniffer logs in great detail. Excessive ARP probes and non-standard DHCP behavior was especially frowned upon. I'm pretty sure the early ARP requests would have caught their attention.

It gets really problematic if you have several APs servicing one network. What to do if the client roams from one AP to another AP with the same ESSID? Assume it's the same network, in which case you can keep your IP or do you have to redo your ARP or the whole DHCP thing? In our case the client wanted to suppress everything including the ARP but in a general case that's probably not good, especially if the network is called 'linksys'.

Might be interesting to try with a Mac.

</comment><comment><USER42> I've always wondered why my Mac jumps right on the network, while other devices such as my Xbox 360 take a few seconds before the connection is there.

I'd be interested to see how the Google Chrome CR-48 handles DHCP since it seems like it takes a bit of time before getting online and allowing me to log in to it.

<comment><USER43> ChromeOS is based on linux, so I'd expect something similar to what Android does: userland dhclient with the same performance profile as the tablet he tested.

<comment><USER44> "Chrome OS" is Gentoo, not Android. One of my friends has a Cr47 and some hacking exposed dhcpcd inside, with some unspecified patching to bring it down to sub-second DHCP.

<comment><USER45> I believe that Android also uses dhcpcd, if I recall correctly from recently browsing the source code. I do not know whether or how Android's dhcpcd may be modified.

</comment></comment></comment></comment><comment><USER46> Yes, someone may have joined the network at your old IP address but that's ok. That first ARP is going to determine if that has happened already.

Am I right?

The author should try the same ethernet sniffing experiment but put a machine at the old address and see how the algorithm adapts.

</comment><comment><USER47> Everybody is discussing whether Apple is cheating and whether is it worth it, compared to the speed of connection of the Galaxy (0.03s vs 11s).

Note that the Galaxy takes more than 10s to connect because is trying to be clever. If it started just doing the DHCP negotiation it will get an IP in 0.7s.

Are the problems Apple devices create really worth saving 0.7 - 0.03s?

BTW, 0.7s is an awful long time to get an IP. Anybody knows why a router takes so long to answer?

</comment><comment><USER48> Is this a genuine problem for any non Mac users?

I do no use any Apple operating systems, but I have _never_ had an issue with WIFI connection and address assignment times on any platform that I have used with regularity.

On both windows and linux I am connected before I can even start an application.

</comment><comment><USER49> A second used to be a short time, now it seems like a _thousand milliseconds_.

You might find RFC 4429 IPv6 "Optimistic Duplicate Address Detection" interesting ...

</comment><comment><USER50> reading the _title_ i thought this has to do with RFC-4039 a.k.a rapid-commit- option for DHCP, which basically allows clients to acquire configuration parameters in 2-message exchanges rather than the usual 4...

</comment><comment><USER51> # /etc/init.d/networking restart

</comment><comment><USER25> I wonder if Apple has a patent on this technique.

<comment><USER52> They do : patent 20090006635

</comment></comment><comment><USER53>

</comment><comment><USER54> Congratulations! Your laptop does the equivalent of using the exit lane to jump ahead in traffic. There's bound to be an empty spot near the end, right?

<comment><USER5> The only reason that is a useful example to you is because that act is genuinely dangerous. There is nothing dangerous about swiping someone's IP and causing them to have to reconnect.

<comment><USER54> You're right. I guess it's more comparable to walking up to a checkout or a cash register without looking to see if anyone is waiting in line. Great UX if you don't look around you.

<comment><USER55> That's as bad as your exit lane analogy. If you want a checkout line analogy that actually somewhat fits the situation, here is one.

You pay for a cup of coffee at Starbucks, standing in line until it was your turn to pay. Then you pay and go sat down and drank some of it, while working on your laptop. You get caught up reading HN, and don't take a sip from your coffee for five minutes. You then want to take a sip.

What Apple is doing is like resuming finishing the coffee without going back to the checkout and trying to pay for it again.

<comment><USER54> Well, no, that's a bit inaccurate as well, if we want to have nice analogies, let's go with something like this:

You pay for a cup of coffee at a coffee shop. Nominally you get your own cup, and there isn't a limit on the amount of time you can keep it. However, the store occasionally and unpredictably runs out of cups. Also, at the start of a new day a new barista might occasionally come in, and they might not know which cups should still be considered owned. Because of this, everyone else has for years observed a simple procedure where you look to make sure it's your coffee you're about to sip. It's polite and it's just — what's the phrase — not a big deal. You get your coffee, leave for two days, come back and take a drink from the cup that looks like the one you got previously without as much as a glance inside or around.

<comment><USER5> Except I drink hundreds and hundreds of cups of coffee a day. When it takes 10 seconds every time to determine who's coffee it is, we need to come up with a new solution.

Yeah this analogy blows as well. What it comes down to is old world technology spends a ton of time on error correction like this and it's an easy place to increase efficiency & speed for portable devices. It's going to keep happening, get used to it.

<comment><USER54> Except it doesn't take 10 seconds. The time between the Galaxy Tab's proper DHCP discover and DHCP ACK was 0.653 seconds. You might notice a difference between that and the Mac's 0.031 seconds to DHCP-free link up if you blink fast.

This conversation makes me want to block Apple devices from any and all devices I control. Because hey, such anti-social network behaviour is going to keep happening. Because it's not a big deal. Because you're worth it. Good thing the network layer doesn't support such, uh, experience-enhacing features.

<comment><USER5> > Except it doesn't take 10 seconds. The time between the Galaxy Tab's proper > DHCP discover and DHCP ACK was 0.653 seconds. You might notice a difference > between that and the Mac's 0.031 seconds to DHCP-free link up if you blink > fast.

I unlock my phone and launch MobileSafari in less than a second, so it matters.

> This conversation makes me want to block Apple devices from any and all > devices I control.

So do it then. If it actually enhances your experience, why compromise for users that don't matter to you? That's my point. You don't need to enforce network neutrality on your own AP.

> Because hey, such anti-social network behaviour is going to keep happening.

As long as router manufacturers keep being cheap and expiring DHCP leases after a reset, yes it will.

> Because it's not a big deal. Because you're worth it.

Damn straight.

> Good thing the network layer doesn't support such, uh, experience-enhacing > features.

True, they should work on that. While their at it, add the ability to save DHCP tables before a reset and solve the actual problem here.

Even for new network discovery, 10 seconds is unacceptable on a portable device. Reconnects should be as quick as possible, no exceptions.

Sorry if you are offended that companies are actually working on improving this instead of insisting that it's good enough as it is.

<comment><USER54> Thanks for your reply.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER56> "This whole notion of being so proprietary in every facet of what we do has really hurt us." Steve Jobs, circa 1997

<comment><USER3> There is nothing proprietary about this.

<comment><USER56> Do you have any examples of other vendors using the last assigned address as a default?

<comment><USER57> Proprietary in the computer sense is generally taken to mean closed source or at least not made available to competitors or others. There's nothing to stop any other systems offering this kind of quick start DHCP service.

<comment><USER56> Except that it violates the specification right? I guess we're agreeing to disagree on the definition of proprietary. I can buy all of Apple's funky connectors through various suppliers, and maybe even fab them myself, but to me they're still proprietary. Sorry to be pedantic!

<comment><USER58> Which specification does it violate?

<comment><USER56> rfc 2131? seems to say the client can _ask_ for an unlimited lease, but the server can specify a finite one. this article seems to be saying that this thing will use the last one leased no matter how long it's been off the network

<comment><USER3> The DHCP client acts as expected. The behavior observed by the post author occurs before DHCP negotiation executes. I know this seems like a technicality, but it's the truth. The sniffing and assumed use of an IP address occurs outside the DHCP request/response cycle. It's used ahead of time, and discarded if the DHCP 'request' request is denied.

The only people bent about this are people who have any idea what's going on behind the scenes. In the rare cases where this is a problem, the issue is quickly resolved. If this were a "real" problem, we'd have seen a lot more issues by now. The Apple discussion boards would be lit up with complaints. They're not. This is a non-issue. Only pedants are stuck on the fact that there's no RFC for it.

<comment><USER34> And as several people have pointed out to me, it looks like there is indeed an RFC for it: RFC 4436, Detecting Network Attachment in IPv4 (DNAv4).</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Suspicion: Dropbox was REALLY hacked on Jan 2014 - andy-me http://andy.me/blog/2014/02/10/suspicion-dropbox-was-hacked-jan-2014

<comment><AUTHOR> It was a hoax. @1775sec later posted "Did anyone bother to do some research. lol. We made the Internet Reporters look like fools! That is what we did in your honor Aaron Swartz"

They've deleted most of their tweets, linked here: [https://news.ycombinator.com/item?id=7041212](https://news.ycombinator.com/item?id=7041212)

</comment><comment> andy-me In the blog post, I explain why I think they still got hacked. Maybe it was not @1775sec, but starting to get spam just after their downtime, is suspicious.

In any case, it's a suspicion, hard to confirm indeed.</comment>


Microsoft patents Operating System Shutdown - <AUTHOR> http://www.conceivablytech.com/2530/products/microsoft-patents-operating-system-shutdown/

<comment><USER2> Specifically they're patenting graceful shutdown of a graphical windowing environment, with a series of prompts to ask the user if they are sure that they want to terminate processes that cannot be gracefully stopped.

All of it seems blindingly obvious, but then it also doesn't look like a claim against any non-Windows OS would last 10 seconds in a court, as there are a ton of clearly Windows-specific claims.

<comment><USER3> Actually, I read the patent differently. They seem to be claiming that a series of prompts is slow to the user, and that they've invented a more efficient and faster system.

1) Non-GUI applications (or applications without a window) should be terminated automatically 2) Applications with a top window can veto, but when they do the other applications are removed from the screen, so that the user can focus on the application veto-ing. 3) Users can be presented with a "Shut Down Now" button, to force the shutdown, ignoring any application vetoes.

Also, remember the description is not part of the patent, only the claims section is. As far as I see, the claims are OS-agnostic.

<comment><USER4> I don't see that differently from what other graphical OS do; of course there are minor differences but both macosx and gnome (didn't check other linux GUIs) have something similar.

I'm not saying that they didn't copy it from windows, but I think the features were there before microsoft filed this patent (2005).

</comment></comment></comment><comment><USER5> So did they _file_ this patent, or were they _awarded_ this patent? I'm not familiar enough with patent terminology to tease this info out of the article.

<comment><USER6> Awarded. Link: [http://patft.uspto.gov/netacgi/nph- Parser?Sect1=PTO1&Sec...](http://patft.uspto.gov/netacgi/nph- Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/PTO/srchnum.htm&r=1&f=G&l=50&s1=7,788,474.PN.&OS=PN/7,788,474&RS=PN/7,788,474)

</comment></comment><comment><USER7> The flowchart seems to describe the current Windows 7 shutdown sequence. As much as I hate to say it: if this is so obvious, why hasn't any other operating system implemented it?

</comment><comment><USER8> As a patent on a process instead of on an actual product, how does this kind of patent tend to fare in the courts?

</comment><comment><USER9> Pity that they're incapable of actually implementing this properly.

<comment><USER9> Sod the d/vs, they really have utterly failed at implementing this properly.

In win7 on shutdown on various different computers I constantly get empty dialogs saying "waiting for the following windows to close:"

With an entirely empty dialog...

The actual offending programs are Outlook and Steam. But MS programmers screwed up the implementation of this patent.

Just another example of a patent being worth jack without implementation.

</comment></comment><comment><USER10> That's all right. Using my Mac I rarely have to anyway... and really wonder if I even need to.

<comment><USER11> Admittedly the parent post is somewhat fanboyish, but it's true that the macbook (and imac) sleep functions are light years ahead of most PC laptops. They sleep very quickly on closing the lid, and resume fast too... I've never found sleep to be as effective on Dells given to me by work.

<comment><USER12> Avoiding reboots in definitely preferred. I've heard very good things about Mac's sleep speeds, but I have a home built PC and Lenovo ThinkPad that do ok. They take around 5-10 seconds to go from in or out of sleep which is fast enough that I don't think about it and I usually only reboot to install Microsoft Updates, which is a different story.</comment></comment></comment>


Show HN: Couldn't find good tool to analyze MySQL Slow Query Logs so I made one - <AUTHOR> http://nk.gl/slow_queries/

<comment><USER2> What's the unique selling point of yours over pt-query-digest?

[http://www.percona.com/doc/percona-toolkit/2.1/pt-query- dige...](http://www.percona.com/doc/percona-toolkit/2.1/pt-query-digest.html)

<comment><AUTHOR> Well the one big difference is that mine is simply a website where you upload your log file, while pt-query-digest is part of a (apparently linux-only) toolkit that you have to download and install. This may not be a big issue if you have your own linux-based server and deal with these logs on a regular basis, but if you are on Windows and just want to do a one-off analysis I think my site is a much better solution.

In addition, since I am displaying the summary in a web browser I can add all sorts of nice enhancements you couldn't have in a simple console, for example:

      - Searching and sorting queries on the fly
      - Syntax highlighting
      - Visualization (like the queries/hour histogram)</comment></comment>


Show HN: LuaJIT assembler/assembly language for direct bytecode programming - <AUTHOR> https://github.com/rochus-keller/LjTools <comment><AUTHOR> Thanks for the suggestion. I think mostly people who want to use LuaJIT as a backend for another language, not primarily Lua programmers, might be interested in my work. Here is an article describing the project: [https://firstname.lastname@example.com/implementing-call-by- refer...](https://email@example.com/implementing-call-by-reference- and-call-by-name-in-lua-47b9d1003cc2)

<comment><USER2> > LuaJIT as a backend for another language, not primarily Lua programmers

Not exactly backend but that kinda fits my use case. I have a C embedded application that I need scripting on. Nothing unsecure from the user, from my own backend, but it requires a foreign function interface, and its a super constrained device.

Lua, JavaScript, forth, etc. None I've been able to find anything I like under 50 kB flash or are even slightly "friendly".

Found one in JavaScript was close, but it's an interpreted language which means every letter of code is a byte I need to transfer then have parsed.

I'll look into this. Esp if it's still possible to send just bytecode in.

<comment><USER3> I don't know if luajit runs in your device, but vanilla luajit supports generating and loading bytecode.

[https://luajit.org/running.html](https://luajit.org/running.html)

<comment><USER2> I think primarily it's the ffi I would be missing. This would get me a turing complete language but set up as an executable it's wrong for me.

<comment><USER3> Notice that if I remember correctly, you can generate bytecode on the PC (by using the luajit command) and have the resulting bytecode loaded through the C API on your device as if it were a regular script.

</comment></comment></comment></comment></comment><comment><USER4> Would you be interested in writing a short editorial on this for the Lua Digest newsletter?

[https://luadigest.netlify.app](https://luadigest.netlify.app)

</comment><comment><USER5> This is very interesting work! I am poking around CPython and Python bytecode to learn about compilation/VM/interpretation and I was thinking about writing cose directly in Python bytecode to play with.

The UI on top looks very handy!

Kudos

</comment><comment><USER6> Tangential, but what's LuaJIT's maintenance status?

<comment><USER7> I was also interested, here's the latest update: [https://www.freelists.org/post/luajit/Regular-releases- for-l...](https://www.freelists.org/post/luajit/Regular-releases-for-luajit- from-the-new-repo-and-future-roadmap)

It doesn't look like there's been a release since May 2017 though.</comment></comment>


From Congress, a Law [JOBS Act] Befitting a Sausage Factory - <AUTHOR> http://dealbook.nytimes.com/2012/04/03/from-congress-a-law-befitting-a-sausage-factory/?nl=business&emc=edit_dlbkam_20120404

<comment><USER2> >Grant Thornton asserts that the decline is a result of changes in market structure. One reason is decimalization — pricing stocks in cents rather than fractions — that took profits out of trading that had previously given brokers an incentive to list small companies.

Is there a simple explanation for why changing from fractions to cents would remove profits?

<comment><AUTHOR> Market makers make their money off the bid-ask spread, i.e. buying at the bid and selling at the ask (you and I, on the other hand, must do the reverse).

Before decimilisation the minimum spread would be 1/16 (or even 1/8th) of a dollar. Today it is not uncommon to witness penny (or even fraction of a penny) spreads. Thus, the minimum theoretical spread realisable from making markets in a security dropped by 84% ($0.0625 to $0.01).

If previously broker-dealer A had a cost of one cent per trade and broker- dealer B had a cost of half a cent per trade, it just meant that B-D B made more profit - he couldn't undercut A. Thus both would survive. Today competition has driven the bid-ask spread to cost delta so low that market makers need large volumes to break even on their operations - this kind of volume can only be realised in frequently traded securities, i.e. larger companies.

Essentially, the wider spread subsidised inefficient market making operations, e.g. the making of markets in smaller companies. The positive externalities of those activities may have outweighed the dead-weight loss of the implicit subsidy.

Note that there is a valid counter-argument that says fractional pricing meant a company that today has a penny spread and a company that today has a dime spread would be seen as equally profitable to deal in, on a unitary basis, from the market maker's perspective, while today the less liquid stock is far more profitable (again, on a unitary basis). Thus, by this line of logic, decimilisation _increased_ the incentive for market makers to make markets in less liquid securities, e.g. smaller companies.

</comment></comment><comment><USER3> > Congress simply doesn't understand financial markets and instead legislates > to the political winds.

Sure, and while we wait for that to change (never happen), let's allow people the freedom to make their own decisions about fundraising and investing. This bill is realistically the most we can hope for, especially in an election year.</comment>


The Unsettling Beauty of Lethal Viruses - <AUTHOR> http://blogs.smithsonianmag.com/artscience/2013/02/the-unsettling-beauty-of-lethal-viruses/

<comment><USER2> Neither E. Coli nor the malaria plasmodium are viruses, which I'm sure is the ignorance of the author rather the the artist. I'd expect better of the Smithsonian.

<comment><USER3> For the love of god. It's the very first fricking sentence of the article, too. I don't think I've ever quit reading an article so fast.

<comment><USER4> ignore the article, and watch the video near the end.

</comment></comment></comment><comment><USER5> ...if you want to learn about the _true beauty_ of viruses, learn about how they work, how their genetic code is written and "executed" to produce the simplest and smallest possible viable replicator (though not an independent replicator), grab a molecular virology textbook like [1] (it's not that hard - you can skim a more general molec bio book like [2], which is written in a style very friendly to all technically oriented people, including coders). Or check out a really cool virology blog - <http://www.virology.ws/> (by one of the authors of book [1]), though latest posts are more about politics and social implications than cool basic science.

I have a feeling that von Newman would be extremely fascinated by modern molecular virology if he'd be alive today, considering his interest for minimal universal replicators [3]. _If you think about it, modern computer science may very well owe its existence to von Newman's and Turing's interest in mathematical models of life itself!_

(...if you want to learn more about the topic above, just google "von newman universal constructor" or "turing morphogenesis" or "schrodinger what is life" and start exploring, I don't want to spoil anyone's fun of finding out about this for yourselves :) )

\--- [1] <http://astore.amazon.com/virologyws-20/detail/1555814433> [2] [http://www.amazon.com/Molecular-Biology-Cell-Bruce- Alberts/d...](http://www.amazon.com/Molecular-Biology-Cell-Bruce- Alberts/dp/0815341059/ref=sr_1_1?s=books&ie=UTF8&qid=1360312028&sr=1-1&keywords=Molecular+Biology+of+the+Cell) [3] [http://en.wikipedia.org/wiki/Von_Neumann_universal_construct...](http://en.wikipedia.org/wiki/Von_Neumann_universal_constructor)</comment>


Show HN: An iMessage Scheme REPL. scheme [at] irepl.im - <AUTHOR> http://irepl.im/

<comment><USER2> (I'm one of the creators.)

If you're curious about how we did it, take a look at <https://github.com/46Bit/irepl>. Messages Beta for Mac still has AppleScript bindings from iChat. We're (ab)using them to pass the iMessages to Heist and then reply.

<comment><USER3> That sounds like quite a workaround - I'm somewhat surprised that there aren't any reverse engineered iMessage (or Facetime) clients out there.

Would you happen to know if there is some technical or crypto reason for this?

<comment><USER4> When apple unveiled FaceTime, Jobs said it would be an open standard. Sadly it never came to be. I wonder why - that could easily be a competitive advantage over Skype or countless other _competitors_... Maybe a stupid patent (that Apple has licensed to use, but has no right to let others use it too) is the reason?

<comment><USER5> Actually I remember reading that part of the reason FaceTime hasn't turned into the open standard that Steve promised is that when he made that announcement at the event, this was the first time that anyone had heard of it being an open standard. The FaceTime team had no idea and then maybe he dropped it after meeting with them. It isn't referenced anywhere except in the video of the event and breakdowns of the event on blogs.

</comment></comment></comment></comment><comment><USER6> Ingenious.

I can't wait to see what other iMessage-based services pop up now that the AppleScript bindings are exposed.

</comment><comment><USER7> Haha, that is awesome.

</comment><comment><USER8> Good job chaps!</comment>


Ask HN: Becoming an [international] freelance consultant - <AUTHOR> Hi,
currently, I work part time as a contract programmer, travel the world, have personal projects on the side.
I am able to bring value in management processes, development processes, maintainability, software quality, QA, architecture and implementation.
Keeping my current freedom would be great though.
I am registered at computer futures Germany and France. They mostly have on-site jobs, full-time (that makes me doubt the travelling and remote possibilities.)
1)	How to get hired/ find awesome jobs? What are other job recruitment agencies which I should sign up for
        (especially international and remote wise)? 2)	Do I need to stop travelling or is that possible to do fully remote? What is your experience?
3)	Can I bring value by being on-site internationally? I am sceptical because jobs in France require spoken
        French, and jobs in Germany require spoken German (computer futures experience).
A few similar questions like "become an freelance consultant" are on hackernews and have some nice resources. I like to differentiate this question by asking for recruitment agencies or other ways of getting hired and I like to understand if being internationally available is a value or not. Nevertheless don't hesitate to link to other Ask HN posts.
My experience:
Java (Spring, Hibernate, …), Angular 2 , Agile Management, Distributed Systems (Master Degree), Microservices, Container (Docker), CI/CD (Jenkins), Software Quality (SonarQube), AWS, GCE, Azure
Thank you so much for helping me kick-starting this.
P.S. All books and other resource recommendations are highly welcome. <comment><USER2> My apologies in advance, I can't answer your question directly, but your post gave me pause and I might not be the only such person with these reactions.

I agree with @contingencies, Java is the only technology you mention. Many recruiters will probably not read past that if that isn't what they are looking for. There is nothing wrong with it, but it does lock you into being a "contract programmer" vs a "freelance consultant".

Are you making the transition from contract programmer to freelance consultant? If so, then you need to reposition your personal branding / marketing.

In order to deliver value as a consultant you will need a lot of person-to- person interaction. So, as you point out, you need to be able to communicate fluently with the stakeholders and the many people who are working on any given project.

Whilst emails, chat and phone calls are very useful, a lot of essential and (IMHO) critical communications takes place in person. That is basically why teleconferencing hasn't supplanted business travel. So whilst you can continue to travel, you will probably need to be located with the client for at least part of the time. In many organisations working "remote" causes concerns to management. Travelling from project to project is another matter.

In my experience, the best consultant opportunities arise when working for a major international consulting firm. Once you have established a solid track record in that environment it is possible to go freelance. Employers, like recruiters and agencies, look at your track record for proof that you can successfully complete the given assignment. As a freelance consultant you are expected to hit the deck running.

Then there is that massive stumbling block ... being freelance means that you have to market and sell yourself. Having gotten an assignment you need to track your hours, bill and collect. It is for these reasons that I have found working for a consulting firm is less stressful. When you choose your field and company well, travel becomes a given rather than an option.

<comment><AUTHOR> Thank you very much for your feedback and your advice.

Thank you, it is very good advice to position myself in an industry rather than technology.

Is there a way to find a good consulting firm or compare some?

</comment></comment><comment><USER3> My slightly aged but in my opinion still relevant general advice is this: [https://news.ycombinator.com/item?id=12744624](https://news.ycombinator.com/item?id=12744624) , in addition to this more elaborate blog post referred to in that comment: [https://bjoernkw.com/2013/04/28/starting-a-software- consulti...](https://bjoernkw.com/2013/04/28/starting-a-software-consulting- business/)

I also can't emphasise enough that you're in the business of solving problems, not in the business of creating software: [https://news.ycombinator.com/item?id=15761354](https://news.ycombinator.com/item?id=15761354)

Focus on particular industries or categories of business problems rather than specific technologies.

<comment><USER4> Can you comment on how creating a personal website affected your freelancing? Does it help significantly with receiving the leads?

<comment><USER3> It most definitely helps with being seen as a professional and as a business rather than an anonymous set of TLAs. I refer potential clients to the testimonials on my website and to blog posts relevant to the clients' problems.

The testimonials establish trust that I can deliver on my promise and indeed have done so for other clients in the past.

The blog posts give potential clients an idea of my expertise and perhaps can already help them with a problem they're having (like choosing a testing approach for their software, for example). Probably the most important aspect I learned about sales conversations is that those shouldn't be actually about selling but about trying to understand where the client is coming from, what his or her problems are and about trying to provide possible solutions right from the very start. The resources I provide on my website help me a lot with this.

In terms of getting new leads it's not like my website gets a whole lot of organic traffic from search engines. That does happen from time to time but by itself it wouldn't be enough for having a sustainable business.

What routinely happens though is that potential clients google my name and find my website as the first search result. Again, this helps with establishing a professional relationship and informing the client about what I can bring to the table.

I write regular blog posts (one per week at least) on subjects relevant or related to my business and post excerpts and teasers on social media and business networks like LinkedIn and XING. This helps a lot with getting new leads from my extended network (again, networking is key).

</comment></comment></comment><comment><USER5> My advice: Remove Java from your resume, or at least bury it at the end.

Rationale: Generally only relevant to Android development and bigco. Your major clients in consulting will be SME.

<comment><AUTHOR> I see, that is great advice. Thank you!

</comment></comment><comment><USER6> I'm really not sure what you're asking. Could you possibly clarify? You are already working as a contract programmer, which is a freelance of sorts, and already travelling the world. Are you saying that you travel on your personal time, i.e. when you're not working, but that you would now prefer to travel further afield (more than France and Germany) specifically to work on projects? Or are you saying that you are already travelling for programming work (France and Germany being examples of this), but that you now wish to transition into a more management-consulting focused role instead of programming, i.e. more involved in the business process and strategy end of things and less on the technical side?

<comment><AUTHOR> Thank you for your questions, those are really good.

" travel on your personal time, i.e. when you're not working"

Currently I am a software developer working 100% remote. So I travel for personal reasons or professionally (rarely) when I need to go on-site to a customer (of the company which employs me) to fix something or develop a solution. I really enjoy being location independent and would like to it that way. The comments about Germany and France coming from the job opportunities which I see online or at recruitment agencies, they are 95% on-site in towns or in different parts of Paris. That is not the type of travelling I am looking forward to. That's were the idea of an international freelancer comes from: I assume most well payed jobs need people on-site and mobility comes with a premium. So why not going to awesome destinations?

"when you're not working, but that you would now prefer to travel further afield (more than France and Germany) specifically to work on projects?"

Exactly I like to travel more than just France and Germany. I enjoy mobility/travelling on an international scale. But what I see from the most job positions is that they need people in Paris or in different towns in Germany. I like to avoid that.

"now wish to transition into a more management-consulting focused role instead of programming, i.e. more involved in the business process and strategy end of things and less on the technical side?"

Ideally I like to stay in technology as much as possible. But I like to avoid being a freelancer on Upwork and compete with low paid people from all over the world and getting Upwork type of jobs. I also enjoy a lot working with clients, doing their requirement analysis and getting solutions done rather than writing code.

So I am looking to increase my salary by doing what I enjoy and what I am good at. And I feel like I am hiding behind my computer just looking for "programming jobs". The point is I wish to keep my independent lifestyle and deliver the most value which I can possibly deliver.

Does that make sense?

</comment></comment><comment><USER7> > What are other job recruitment agencies which I should sign up for > (especially international and remote wise)?

Toptal has an interesting platform > [http://toptal.com/](http://toptal.com/)

</comment><comment><USER8> What I did was work for a company and then transition the job remote after 11 months.

I kept my "california" salary and actually earned a lot more money than when I was sitting in an office.

Best of luck!

<comment><AUTHOR> Thank you for sharing you experience.

Did you transition to remote work or did you try to move into the consultant direction?

<comment><USER8> I told my boss, while I enjoyed working for the company, I was unhappy living in San Francisco and I needed a change of scenery. I had a ticket to visit Vietnam (in 2 weeks) and I wouldn't come back to the office again.

Because he was happy with my services and I was a crucial part of the engineering team, he let me work remotely full-time w2 while I traveled around the world.

</comment></comment></comment><comment><USER9> I've been sitting at both sides of the table via TopTal. First I went through their interview process, which I didn't like and the experience afterwards wasn't great. More recently I helped to hire people via Toptal to work on a project I consulted for, and that was good. Really great developers, and what I can see they have a lot of flexibility.

However, have you considered remote work instead? There is more companies open to that setting and you can also have a good time flexibility. I work for game studio in Dublin - we offer fully remote setup, "unlimited" holidays and flexible working hours. Your skillset matches exactly what we need. But even if you aren't interested in making games for a living (python & java fullstack development) there is tons companies like us. I know because we have to compete with them for the best talent.

<comment><USER10> Hey, Is there any link to where I can apply?

<comment><USER4> Here: [https://www.digitgaming.com/careers/job- listings/](https://www.digitgaming.com/careers/job-listings/)</comment></comment></comment>


Career advice from someone who shouldn't be giving career advice - <AUTHOR> http://poetic.ly/blog/?p=1137

<comment><USER2> Liked the leverage bit. But it's tough getting it right. Guess the trick is to prevent them from taking you for granted, yet staying within reach so they don't give up on retaining you. Easier said than done.</comment>


Zoom sued for overstating, not disclosing privacy, security flaws - <AUTHOR> https://uk.reuters.com/article/us-zoom-video-commn-privacy-lawsuit/zoom-sued-for-overstating-not-disclosing-privacy-security-flaws-idUKKBN21Q10V <comment><USER2> Don't know what is going on at Zoom, but I suspected at least part of it sneaky. For example, about 3 or 4 weeks ago I heard about this company, and learned that it has R&D in China per its SEC filing at IPO. However, checked its website, the career section led me to [https://jobs.lever.co/zoom](https://jobs.lever.co/zoom), and there was ONLY one opening at China per the website (I remember it was a position at marketing department). Then I searched the company in Chinese media, and saw that they were hiring all types of engineers. That made me feel uncomfortable in buying its stock. Interestingly, now you look at the same career website, and China is removed from the list of city dropdown - maybe they are cutting off or "decoupling" the Chinese R&D?

<comment><USER3> Why is having engineers in China cause for suspicion? Lots of tech companies have engineers in China. Eg Microsoft.

<comment><USER4> Because the CCP has no qualms about threatening an employee's family to insert a backdoor or exfiltrate information, for one.

The decoupling has begun. Sentiment in the US toward China has never been as negative as it is now, from both sides of the aisle. I wouldn't be surprised if we even see sanctions against China after the dust settles on this COVID fiasco.

<comment><USER5> Let's get real here. The United States government is most certainly capable of doing everything we accuse China of doing and worse.

<comment><USER6> The US is no white knight. But it is not doing anything close to what the CCP does on a regular basis. When was the last time a Trump protestor or Obama protestor disappeared and was never heard from again? Or disappeared and show up again months later, 30 lbs lighter and apologetic about how wrong they were about the government?

<comment><USER7> In this sense yes, absolutely. China is known for doing grotesque humanitarian violations.

In another sense such as starting a war to deflect from problems at home, theres one champ and that is our democratic country.

Either one doesn't mean the other is doing something legitimate and is waranted shielding from criticism

<comment><USER8> The US does not start wars to distract from problems at home. That's conspiracy horse manure. Whether you want to believe it or not, every president that has ever started a conflict or US involvement in an existing conflict has felt the action justified on foreign policy reasons.

Those reasons might be something you object with, or even downright stupid in hindsight. But only in Hollywood is it ever a smoke screen for domestic issues.

<comment><USER9> USA, Russia, Turkey, China do exactly that throughout history. It is also an indicator of a failed/non functioning democracy, this is what surprises me about the USA (it IS a functioning democracy). I understand Russia and Turkey (been to both countries) are democracy-challenged and instead of solving their internal problems they create new external to divert the attention and seek "greatness" (one of the things that Trump* also proclaims).

Humanity needs to be great together.

Together we stand, divided we fall (said the poet).

*I don't vote in the USA so I don't care who they/you elect. If it would be Clinton or Bush (Sr/Jr) or Obama saying "screw the world we should care only about ourselves" I would be equally judgemental (you should hear me discuss politics with Russians (they can't see why their dictator is bad for them) (and now I will get downvoted by both Americans AND Russians :)

<comment><USER8> Please point to an example of the USA engaging in a war as a distraction from domestic issues.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I don't think this is likely to succeed -- Zoom can argue that the stock price has gone down because of "Zoombombing" and security/privacy concerns that have nothing to do with exact details of what was disclosed in privacy/security documents, which barely anyone reads anyways.

Also, it's awfully hard to argue losing shareholder value when the stock has still more than doubled in the end -- Zoom can easily make the plausible- enough case that it made the right tradeoffs in the end for shareholder value that allowed it to scale. (I'm not saying that's true, just that it's plausible.)

Could it be fined by the SEC for misstating key details in their public filing? Maybe, although these are tiny details. But a class-action suit by shareholders? This feels like a stunt to me. Also, since a suit by shareholders could depress the stock price further, this feels like a short- seller trying to profit, no?

<comment><USER11> > _Zoom can argue that the stock price has gone down because..._

Two general steps to a securities suit.

First, show the company defrauded investors. That can be as simple as omitting or mis-stating material information. (Zoom publicly claimed to use certain encryption standards that it didn't.) So the battle, here, will be around materiality. Critically, this step does _not_ typically require proving damages.

Once materiality is met, the second step is showing damages. At this point, the change in (and attribution of) stock prices comes into play.

Once fraud is shown, the company is in a bad place. Even if a particular investor faced no discernible loss, everyone who bought at higher prices will now sue. It also invites state and federal investigators to start pursuing management and senior staff.

> _this feels like a short-seller trying to profit, no?_

No. You have to disclose your positions when entering into a shareholder lawsuit. Shareholder lawsuits are comically common. And there is limited precedent for short sellers doing this.

 _Disclaimer: I am not a lawyer. This is not legal advice. Don 't buy or sell securities based on my internet comments._

</comment></comment><comment><USER12> Am i the only one struggling to use Zoom properly since they introduced the latest security changes? The slack integration (write /zoom to start a meeting) was working ok-ish even though we always had problem with the meeting not starting unless the host of the meeting was logged in (gosh...why so complicated?)

Now they added this waiting room, there is no sound notification to let you know that people are waiting. Doing daily standup become a sufference. It's crazy how quickly they lost us as users with literally two badly implemented features.

Happy to hear if any of you also had the same struggle and if there is a good alternative.

<comment><USER13> I would think that meetings being company users only by default could side step a lot of these clunky security measures. You would only need them for external meetings. No zoom bombing or war dialing issues with that default permission set.

<comment><USER14> The issue is that everyone with a gmail address is in the same "company", because they use your domain to determine what company you're in.

</comment></comment></comment><comment><USER15> Note that the lawsuit is a class action for shareholders of Zoom stock.

Filing: [https://i.judge.sh/natural/Babs/1-main.pdf](https://i.judge.sh/natural/Babs/1-main.pdf)

<comment><USER16> Interesting that shareholders are the one to fill a lawsuit.

<comment><USER17> In the US lying to users is merely frowned upon while lying to investors is illegal.

<comment><USER18> False advertising of services (amongst other things) is illegal in the US.

[https://www.law.cornell.edu/uscode/text/15/52#b](https://www.law.cornell.edu/uscode/text/15/52#b)

<comment><USER17> Yes, just this week the FTC brought a tech company to justice for false and misleading promises to users about information security:

> "We allege that Tapplock promised that its Internet-connected locks were > secure, but in fact the company failed to even test if that claim was true," > said Andrew Smith, Director of the FTC's Bureau of Consumer Protection. > "Tech companies should remember the basics—when you promise security, you > need to deliver security."[1]

Armed with clear and indisputable evidence of Tapplock's blatant lies, the bulldog enforcement lawyers at the FTC took the opportunity to make an example out of the company. After 18 months of hard-fought negotiations the FTC announced a settlement agreement[2] whereby the Commission agreed to resolve the matter in exchange for Tapplock's pinky promise to not get caught doing that again. Per the arduous terms of the settlement, Tapplock neither admits nor denies any of the FTC's allegations.

So when a company promises their users security that company better deliver security. Or else... absolutely fuckall will happen.

[1][https://www.ftc.gov/news-events/press- releases/2020/04/canad...](https://www.ftc.gov/news-events/press- releases/2020/04/canadian-maker-smart-locks-settles-ftc-allegations-it- deceived)

[2][https://www.ftc.gov/system/files/documents/cases/192_3011_ta...](https://www.ftc.gov/system/files/documents/cases/192_3011_tapplock_agreement_containing_consent_order.pdf)

</comment></comment></comment></comment></comment><comment><USER19> Good. There needs to be a serious crackdown on 'puffery' aka lying ( whether lying about product feature or anything else is irrelevant ). Fingers crossed and it will go beyond $2 credit on future Zoom services for affected users.

<comment><USER20> I'm betting the payout will be a custom emoji for affected users. Maybe a tinfoil hat. And the court will be ok with that so long as the lawyers get paid in hard currency.

<comment><USER21> Iirc this is a lawsuit by shareholders so I imagine users will get nothing.

</comment></comment></comment><comment><USER22> Will be interesting if Zoom is compelled to disclose their security architecture. On the same page can they be forced, in court, to make a statement on the interference by the Chinese government?

<comment><USER23> Is having keys compelled a surprise?

Chinese servers, operating in China legally, will usually have this issue.

It's serious yes, but I'm confused if it only applied to users in China?

I'm more concerned about the technical issues TBH - I assume most software sanctioned in China had to turn over keys.

<comment><USER24> Seeing as encryption is illegal in China, I don't think they will need to give up any keys.

<comment><USER25> >Seeing as encryption is illegal in China

Source for this? That would make any https site in china illegal.

<comment> kube-system Not an expert, but I searched and found this link which seems to explain it well:

[https://www.freshfields.com/en-us/our- thinking/campaigns/dig...](https://www.freshfields.com/en-us/our- thinking/campaigns/digital/data/china-rules-on-encryption/)

tl;dr: encryption is not completely illegal, but it sounds like it's pretty tightly controlled.

<comment><USER23> I didn't think they'd be foolish enough to completely ban it.

They're not comically evil, they just have certain incentives.

Key escrow meets those goals.

</comment></comment></comment></comment></comment></comment><comment><USER26> It's a bit odd how everyone's attacking Zoom when none of the other common solutions have proper e2e encryption either.

<comment><USER27> Do the other common solutions _claim_ to have e2e encryption?

<comment><USER28> Yeah. The problem here is that Zoom lied about it.

And, like, _why_? Sure, if no one ever caught them, e2e could be a reason to choose Zoom—but it's like lying on a resumé. Which, I guess is also a thing that happens sometimes, but it's generally understood to be a bad idea.

<comment><USER29> Because it was clearly botched marketing material rather than a coordinated plan. Hypothetical: somebody asked an engineer what kind of encryption Zoom used, the engineer responded somewhat vaguely and the marketing person heard "we encrypt between endpoints" as "end to end encryption" and then nobody noticed when reviewing the text.

<comment><USER30> Yeah right, oops

<comment><USER29> Yes it definitely is an "oops". I'm not excusing it, but offering an alternative explanation to the "zoom is evil" thinking.

If zoom was truly trying to market themselves as e2e, why is this only buried in one document rather than shouted from the hills?

<comment><USER31> They claim HIPAA compliance due to e2e encryption. That is far from an oops.

They updated their documents since, but last week they had documentation up that said they were HIPAA compliant due to end to end encryption.

<comment><USER32> Ooops. That sounds like it's going to hurt. If not, it sends the message "Hey, say you're HIPAA compliant, but it doesn't matter if you're not (wink wink)"

I develop electronics and firmware for medical devices, I have (almost) nothing to do with regulations compliance (except to the extent that I'm working on something where there is an intersection, like storage of patient data). But anyway, not a day goes by that I don't hear someone ask, "Is that HIPAA compliant?"

So yeah. Companies that have used Zoom based on that claim are probably going to extract some blood out of Zoom.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> This nonsense happens all the time with public companies. All it takes is a law firm with the gumption to file a suit claiming that the company misrepresented something material which resulted in a significant change to share prices.

</comment><comment><USER34> Not surprising. Crazy how zoom in the beginning of the crisis was hailed for helping folks get together, but now with all the highlighted security concerns they are receiving a ton backlash. Hopefully they can recover and learn from this.

<comment><USER35> I'm more shocked that this massive tech industry has like one decent solution to remote video conferencing. Maybe we really have gone too far down the road of making bullshit apps, and stopped solving real problems.

Shame on us.

<comment><USER36> Shame on the telcos who prevent residential customers from using the internet as intended. If everyone was given an IPV6 address block and freedom to accept outside connections from anywhere, none of this would be an issue.

<comment><USER37> >freedom to accept outside connections from anywhere

Without NAT from home gateways (like consumer routers) preventing inbound connections from the internet, security would be far more of a nightmare than it is today. Requiring that people manually forward specific ports is the best way to handle it. We would be seeing news about Blaster-like worms pretty much every week of the past 20 years, otherwise.

Also, even if it were a good idea, this still wouldn't solve the problem at all. The NAT-traversing capability of Zoom and other products is like 0.01% of the value they provide. You still need good software.

</comment></comment></comment></comment><comment><USER38> Does it count as lying when it's ridiculously obvious that you're lying?

<comment><USER39> Yes, and it's not so obvious to almost everyone.

</comment></comment><comment><USER40> I am beginning to get concerned also. The University of California has contracts with Zoom, and so many of us have moved over to using Zoom for all our research lab meetings, especially since the pandemic. We all know that China has pushed research espionage, with several convictions that I know about. The possibility of intimate ties with China raises the specter that Zoom is pushing video, or transcripts of that video through China, and hence through Chinese spy agencies, which would be really concerning.

Note: I love the Chinese people, and my Chinese colleagues. I do NOT like the oppressive, and frankly, evil and callous crimes committed by the Chinese government. Downvotes or upvote the comment as you will, won't change their crimes or my opinion..

</comment><comment><USER41> And I've heard nothing about TikTok [https://www.vox.com/open- sourced/2019/12/16/21013048/tiktok-...](https://www.vox.com/open- sourced/2019/12/16/21013048/tiktok-china-national-security-investigation)

</comment><comment><USER42> I guess investors who bought the wrong Zoom stock can't get in on the class action? ;)

[https://time.com/5792310/zoom-zm-stocks- coronavirus/](https://time.com/5792310/zoom-zm-stocks-coronavirus/)

</comment><comment><USER43> Looking back, there isn't actually any evidence that Zoom is not, as they put it, "encrypted from end point to end point". But it is clear that Zoom itself is kind of confused about the whole thing. I don't think that Zoom is all that good with technical stuff...

To have any assurance that a video conferencing system is actually secure e2e you would have to have access to the verified source code of the client programs and verify the identity of each and every participant. That is likely impractical so I think it is safe to say that you should not use _any_ video conference system provided by others to discuss secret things. If you absolutely must do so then you can set up a server under your physical control and then would not have to bother with e2ee at all.

<comment><USER44> Security audits are done all the time, for which access to the source is given. In Zoom's case, going through an audit from a reputable firm, may just be the answer of getting the public's confidence back.

And of course it's fairly extreme to claim you should not use any video conference system for any sensitive discussions; security is not black and white, and each situation deserves an appropriate level of security; it needs to be balanced with convenience. There are a lot of situations where I would prefer "mostly" secure communication, rather than no communication at all.

<comment><USER43> >There are a lot of situations where I would prefer "mostly" secure communication, rather than no communication at all.

We are not talking about "mostly" here for the video conference case. We are talking about a situation where most providers have access to the data of their users without very much work. If you are actually willing to confirm the identity of your correspondent using verified binaries you can get end to end protected communications ... if someone claims that they have something easier then they are lying. You can't beat the law of logic. The fact that anyone is even suggesting that Zoom could of been e2ee in any way that mattered is kind of depressing. I think we have some education to do.

Security audits are pointless unless you can confirm that the software that was audited is the software actually running on your device.

</comment></comment></comment><comment><USER45> How many of Zoom's recent issues can be explained by just bad engineering?

Because my personal gripes with Zoom are mostly about its quality as a software product, which I find to be abysmal for my use cases.

<comment><USER46> From a purely functional standpoint, that is -- does this software do what I need it to do?, I have had absolutely no problems with zoom.

What issues have come up for you?

<comment><USER45> I don't really want to go through the laundry list of issues I have because none are critical, just the software is very rough around the edges on Linux. It just feels less than flushed out, and I've had a million little problems and bugs that I've reported and never heard anything back (as a paying user!).

<comment><USER14> > on Linux

I think I found your problem. While Linux is big here on HN, all Linux users probably represent .001% of their paying customers.

In other words, it makes no business sense for them to do anything to retain you.

</comment></comment></comment></comment><comment><USER47> Can Apple be sued for the same? I'm reminded of their advertising against windows for security, but their products have had a myriad of security flaws over the years.

</comment><comment><USER48> my employer currently signs up for zoom, apparently managed via our SSO- solution. so far so good.

Right now, I got an email from Zoom, not showing any relation to my employer or mentioning its name: "congratulations for signup, use your account now". Ok. Password reset yields an usable basic account. Seems like somehow Zoom created a personal account for me with my work email. As I didn't get the activation email I got on my private spam-account, I assume somehow they got/requested all the employees email-adresses and automatically created private accounts, not related to the actual business acc..

What the actual f __* is that?!? And yeah, I think conceptually this is the same behavior as shown by the ad /malware/spam campaigns ca. 2003. I wonder what had happened if I had just typed a password when signing in with my account... Maybe they just grab the passwords of the illiterate users and check them by trying to login with the university website? (that's sooo userfriendly!)

<comment><USER49> I set up Zoom for our company and nothing like this happened. It seems much more likely (than your wild conspiracy theory) that your company added a "basic", rather than "licensed" account for you and you got an email as a result.

<comment><USER48> no, don't know what kind of mess they made; the official login is via SSO (and works with <companyname>.zoom.us). to my understanding the account is typically created on login there (otherwise we would sync our whole list of employees with 100s of services...). and even if it was just a random invitation sent to an email they bought somewhere, it doesn't really explain how I could reset the password for my email then (without ever activating an account)?!

It might be a messup from someone but it's definitely strange and I just didn't sign up there, yet got spam and had a working basic account...

<comment><USER49> > otherwise we would sync our whole list of employees with 100s of services

Could also have been created with SCIM and you're in a particular SCIM group that other folks are not in.

<comment><USER48> ok, that's interesting. And this is a really creepy thing from a privacy standpoint...

<comment><USER49> Not really, it's not your privacy if it's your work account/email.

</comment></comment></comment></comment></comment></comment><comment><USER50> Blows my mind that a shareholder might have a cause of action for this.

1) Buy volatile stock with recent IPO

2) Sue them for their volatility

3) ?????

<comment><USER51> > Zoom documentation claims that the app uses "AES-256" encryption for > meetings where possible. However, we find that in each Zoom meeting, a > single AES-128 key is used in ECB mode by all participants to encrypt and > decrypt audio and video. The use of ECB mode is not recommended because > patterns present in the plaintext are preserved during encryption.

[https://citizenlab.ca/2020/04/move-fast-roll-your-own- crypto...](https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a- quick-look-at-the-confidentiality-of-zoom-meetings/)

<comment><USER52> You know, I had never considered being a shareholder and using said standing to sue a company into security best practices when they lie about it, considering regulation has failed to create the appropriate incentives.

<comment><USER51> Neither have I, but figured I'd link this since it is more than likely why they are suing

</comment></comment></comment></comment><comment><USER53> This culture of biting the feeding hand has to stop somewhere.

<comment><USER54> Well no, the shareholder is the feeding hand, giving money.

Actually, Zoom is accused of misbehaving and biting the feeding hand. And yes, this shouldn't have happened.</comment></comment>


Alkaline Water Is Booming and Big Soda Is Pouring In - <AUTHOR> https://www.bloomberg.com/news/articles/2019-06-10/is-alkaline-water-really-better-essentia-coke-join-drink-trend <comment><USER2> > _Alkaline water is basically purified water—often with salt added for > electrolytes and baking soda—that has a higher pH level, making it less > acidic._

For anyone who wondered what the heck alkaline water is.

Salt is sodium chloride and baking soda is sodium bicarbonate; one would think that pretty much the last thing that people in first-world countries need in their diet is more sodium.</comment>