dmdeller

I was reading the Tailscale docs one day and I stumbled across this support page, which has similar vibes: https://tailscale.com/docs/reference/faq/ipv6

It was somewhat unexpected to find section headings such as "Is IPv6 a failure?" in the product support documentation, but I thought it was interesting and informative nonetheless.

Good analysis.

This is a result of trying to retrofit a series of tighter security measures on top of a system that was not originally designed for them, in a way that is both understandable to users but also doesn't break back-compat with APIs (and therefore a lot of existing third-party apps that are seldom updated) too badly. I'm not saying Apple did a perfect job here, but it's a hard problem.

Yes, the problem could probably be "solved" by adding more UI, but "more UI" is not always a good solution. The more UI that exists, the less likely the user is to successfully navigate it. On the other hand, adding additional complexity to an existing UI is also fraught with potential for new bugs and edge cases. Again, not defending the status quo, but I can see how it might have ended up like this.

This is worth spending more time on trying to improve, and perhaps it is reasonable to expect better from an almost-$4tn company. But at the same time, a potential solution is far from easy or obvious, and there is a risk of making things worse if not done with an extreme level of thought and consideration.

(Alternate pessimistic take: A large number of users don't care or read anything, they just click "allow" on anything that gets in their way. A smaller set of users are terrified and disgusted by repeated invasions of the privacy and click "deny" on everything. None of these implementations are doing any good for either group. The allow/deny design pattern is badly broken and in need of rethinking.)

Thanks!

Check out Bootstrap's 'Default navbar' example. It does this. http://getbootstrap.com/components/#navbar-default

It doesn't matter what people thought. The complaints were coming from people at big companies with legal departments. The lawyers' job is to make sure there are no legal vulnerabilities, the same way it's your job to make sure your code doesn't contain any vulnerabilities. Intent is irrelevant.

I was also quoted the $1000/month price, and followed up with this same question. I was told it was separate from (in addition to) all other service pricing.

Prepaid plans across all US carriers generally have all taxes and fees included in the advertised price, except for standard sales tax (if your state/locality normally charges it).

You can now also use !s which is the same as !sp.

Note that it works as either a prefix or a suffix - it might be easier to put the insertion point at the end of the text box.

If you're using Safari, you can use my Safari extension to do this with a toolbar button or keyboard shortcut: http://horizon-nigh.org/re-search/

Rooms is a separate app, also made by Facebook, but (AFAIK) unrelated to the Groups app which is the subject of the article.

I have a separate local user account on my computer for work. When I start work in the morning, I switch to the work user and all of my personal stuff goes away. When I'm done with work at night, I switch back, all my personal stuff comes back and work goes away. It's almost like having a separate computer.

People often look at me like I'm crazy when I tell them this. I haven't quite figured out why.

If I need to look up some personal thing in the middle of the day, I reach for my phone. If I find I've been reaching for my phone too much that day, I get up and put it on the other side of the room. Now every would-be distraction requires me to physically move my entire body.

The story continues: after that court case, Apple added a special, obfuscated 'stolen from Apple' icon to the firmware, in case they ever had to go to court over something like this again. http://www.folklore.org/StoryView.py?story=Stolen_From_Apple...

Here it is: https://news.ycombinator.com/item?id=8441230

Thanks. I thought I remembered reading about this same issue some time ago. Seems like a rather slow response from Dropbox, doesn't it?

The banks' monitoring software is in fact a hassle for me. I've only ever had legitimate purchases denied. The retailer's order flow is not usually optimised for this case, requiring a tedious, often manual process to get my order reinstated, while at the same time often causing the retailer to treat me with suspicion (they can't tell why the charge was denied the first time, and are sometimes reluctant or unable to retry the same card again).

As far as I can tell, Final is not really about reducing fraud, which, as you correctly state, is mostly a non-problem for customers. Instead, its value is in increasing my personal convenience, by reducing the annoyances the credit card companies force me to deal with as a direct result of their absurdly outdated technology.

I keep getting the same one from a certain car dealership every few months. Apparently handwritten address on envelope, real ordinary first-class postage stamp (even placed at a slight angle, so it doesn't look like a machine did it). Postmarked from a different state than the dealership is in. No return address.

Open it up though, and the deception ends immediately. Just your usual tacky, glossy printed brochure.

Google, Apple and Microsoft, all have the power to delete those apps from your device.

This is been public knowledge for as long as the App Store has existed: http://www.macrumors.com/2008/08/11/30-million-in-app-store-...

Jailbreakers found it almost immediately: http://forums.macrumors.com/showthread.php?t=549203

It's not just billing that is the problem. These third-party services send the carrier a list of numbers to subscribe, and the carrier simply takes them at their word that those numbers have opted in, without having any idea whether this is actually true.

Technically, the third-party could simply make up a list of random (but valid) numbers, send them to the carrier to subscribe, and the carrier would do it. There is no technical means in place to stop this. The only thing that (in theory) stops it is the carrier noticing the high number of customer complaints and deciding not to do business with the third-party any more - a clear conflict of interest, since deciding to ignore the problem benefits the carrier financially.

What many of these services do is toe the line, by enticing a customer to give up their phone number for some completely unrelated reason, and bury somewhere in the fine print that they are signing up for a recurring charge on their phone bill. The customer has absolutely no idea that this is happening unless they read through pages of legalese. This way, the charges are technically opt-in, even though no reasonable person would describe it as such.

https://en.wikipedia.org/wiki/Cramming_(fraud)

The brain-dead simple technical solution for this is for the carrier to check with the customer before adding a charge to the bill. There is no reason not to do this.

Or maybe just get rid of for-pay SMS services altogether. In the age of smartphones they are useless.

Exactly. Apple does not refer to this icon as the 'share' icon in official documentation. It is actually the 'action' button[1]. As in, I have some data in this app, and I want to do something with it outside of this app. Hence, the symbol of an arrow moving outside of something.

Many of the possible actions resulting from tapping that icon (on iOS) may be unrelated social sharing (e.g., copy, save to photo library, assign to contact, etc.).

[1]: UIBarButtonSystemItemAction; https://developer.apple.com/library/ios/documentation/uikit/...

For those who may not have gotten the reference, I've cuil'd it for you: https://en.wikipedia.org/wiki/Cuil

Where do you keep the decryption key?

If it's stored in the same place as the encrypted password, then you have gained no security over storing it in plain text.

If it's stored in a separate system, then you have substantially increased the complexity of the system, and in general, a more complex system is harder to implement securely.

The Verizon versions of iPad Air, iPad Retina Mini, iPhone 5S and iPhone 5C are identical to those sold for AT&T and T-Mobile, and will work on any of those three networks[1]. (It's different/more complicated for older devices.)

Also, an agreement Verizon signed when buying their LTE spectrum from the FCC says that all Verizon LTE devices must be carrier-unlocked out of the box[2].

However, Verizon will refuse to activate any device that was not originally sold for use on its network (they use a unique device hardware ID for this). AT&T and T-Mobile don't do this.

Therefore, for maximum flexibility, buy Verizon versions of recent Apple devices. You can then switch to AT&T or T-Mobile (not Sprint), or back again to Verizon, at any time, as many times as you wish. This is what the author did[3].

[1] http://www.apple.com/iphone/LTE/

[2] https://en.wikipedia.org/wiki/United_States_2008_wireless_sp...

[3] http://www.caseyliss.com/2014/5/21/tmo-vs-vzw-plans

AWS, Azure, Heroku, App Engine, Parse, and similar services aren’t free, easy, or automatic.

I don't know why he lumps in AWS with Heroku. At least when I read AWS, I think of EC2, which is very similar to Linode or Digital Ocean (which he is complimentary of). I suppose there's also Elastic Beanstalk, which is more similar to Heroku, but I doubt that's what most people think of when they read 'AWS'.

Ideally, your servers should be disposable and easily recreated. The only backups you should need are your source code (which should include any required server-setup scripts) and your database’s data.

Ugh, please don't mix server-specific setup scripts in with your app source code. Now when you want to switch from CentOS to Ubuntu, you're hosed. The server environment should be able to host your app without any modifications to the app itself, and the code that makes this environment ready to host an app should be separate from the app code, so that you can drop it into a different kind of environment at any time. This is one of the main ideas behind http://12factor.net.

Why does any computer have a key which is far more often used for accidental data destruction than any useful purpose? Do the people who make the computer ever bother to ask this question?

Answering my own hypothetical: Mac keyboards (including the full-size 108-key models) don't have an 'insert' key, nor any key that does what you describe.

And sensible languages don't have buffer overflows, either...

Glad to see this! Anyone know if group calls are still planned? I thought so, but no mention of it in this post.

Minor point, but note that video with >2 people on Skype requires a premium account ($10/month). I'm not sure if you also need a subscription to Xbox Live ($50/year/Xbox).

Not free ongoing.

Chromebox, plus everything you need for video meetings. Starting at $999.

includes first year's $250 management & support fee

source: https://www.google.com/intl/en/chrome/business/solutions/for...

I have the $30/5GB plan, and couldn't get auto payment to work via the web site after several tries. Finally I resorted to calling 611. Whatever the customer service agent did to my account finally made it stick.

Most large companies simply have no way to escalate a real bug report.

For the sake of comparison, it seems worth mentioning a hosting provider that takes an explicit stance in their policies against things like this happening, to the extent that they actually named their company around the idea: https://www.nearlyfreespeech.net/help/abuse

Unfortunately, NFSN's technology stack is so far behind the times that it's hard to use them for much of anything these days. I'm not affiliated with them, just a long time customer.

XMPP is not technically well-suited to mobile devices. It was designed with a base-level assumption that any client will maintain a constant TCP connection in order to receive messages. This doesn't fit well with mobile devices, which spend most of their time 'off' and try to have as little software running concurrently as possible in order to save battery life. Some mobile XMPP clients have come up with various clever workarounds, but all of them are hacks. For example, by keeping the 'real' XMPP connection open indefinitely on a remote, third-party server, and then communicating with the mobile app using a custom proprietary protocol that doesn't have this assumption.

A new protocol is needed. In fact, just the other day there was a story on HN where the original creator of XMPP said the same thing: https://news.ycombinator.com/item?id=6849755 The merits of his proposed solution are another matter, though.

Not a direct answer, but: by law, any cell phone can still place calls to 911 with the SIM removed. We can probably extrapolate from there.