Archive for March 6, 2018

Tuesday, March 6, 2018 [Tweets] [Favorites]

Keeping Your Safari Data Private

Apple (via Bob Burrough):

Apple products are designed to do amazing things. And designed to protect your privacy.

At Apple, we believe privacy is a fundamental human right.

And so much of your personal information — information you have a right to keep private — lives on your Apple devices.

Your heart rate after a run. Which news stories you read first. Where you bought your last coffee. What websites you visit. Who you call, email, or message.

Every Apple product is designed from the ground up to protect that information. And to empower you to choose what you share and with whom.

I don’t find Safari’s privacy options very empowering. There are lots of features to protect your from the sites you visit, but that’s only half the story. Safari’s user interface doesn’t mention which user data is sent to Apple’s servers. In fact, iCloud stores your bookmarks and Reading List, open tabs, and even your full browsing history (excluding private windows).

There is no granular control. If you want to sync your bookmarks or use Reading List to move the occasional link from your iPhone to your Mac, you also have to enable history syncing.

The history data is only secured by your Apple ID password, which means that Apple has full access to it. And there have been bugs where deleted history was not actually deleted.

With Chrome, your data syncs to Google if you create an account and log in. With Safari, you never really get a chance to opt in. macOS strongly encourages you to sign into iCloud during installation, and many apps won’t work without having it enabled in some fashion. You can opt out of iCloud’s Safari features, if you know to look for the checkbox tucked away in System Preferences.

Update (2018-03-06): Jason:

I appreciate the granularity Chrome enables with their syncing, even amongst individual instances. I can sync my themes and extensions on my work computer without syncing my browse history, for example.

It confounds me that Safari still doesn’t sync extensions between Macs.

Streaming Your Own Music

Amazon Echo used to let you upload 250 of your own music files to the cloud, or up to 250,000 if you paid $25/year.

HomePod lets you upload 100,000 songs to iTunes Match for $25/year. It cannot initiate streaming from your Mac, even if you use Home Sharing.

Google Home Max lets you upload 50,000 songs for free.

I still use iTunes to sync music to my iPhone, like an animal, and stream from the phone to a Logitech Bluetooth speaker. So I can use Siri to play my own music for free. Right now, I use my own phone for this, but the downside is that as I move around there can be interference or I can get totally out of range. Also, my iPhone SE is full, so much of my music doesn’t fit on it. It might be better to dedicate an old iOS device as a stationary music controller, but that would make controlling it less convenient.

The other option, which I’ve used in the past, is to stream from iTunes on my Mac to the Bluetooth speaker. This can be controlled from the Remote app on my phone, but that is slower and less nice than Cesium and doesn’t work with Siri.

The Mystery of the Slow Downloads

Cabel Sasser:

Our downloads really were slow — but seemingly only to Comcast users, and only during peak internet usage times. Something was up. At first we thought, maybe Comcast bandwidth is just naturally more congested in the evening as people come home from work and begin streaming Netflix, etc. But that didn’t explain why the connections to our Linode control server from Comcast, during the exact same time windows for each tester, were downloading with good speeds. We wondered, is Comcast intentionally “throttling” Cogent customers? And if so, why?


It felt like there was no way this should have worked. If I had to guess, I’d say it’s simple: in the middle of a serious ongoing debate over net neutrality, the last thing Comcast wanted to look like was a network-throttling bad guy in this blog post. But then again, maybe I’m still being too cynical — maybe they just saw a problem they hadn’t noticed and fixed it. (But really, did they really not notice that pipe was full until I asked? Surely there are network monitoring tools?) Frankly, I have to stop thinking about it, because I’ll never know. But no matter the reason, I’m very grateful: thanks for listening to us, Comcast.)

A Year Away From macOS

Wesley Moore (via Hacker News):

At this point I can’t see myself switching back to Mac OS. There is only one task (MoneyWell) that I haven’t been able to achieve with my new Linux or FreeBSD systems.


Over the year I think what I value in an operating system has shifted. I went in valuing design, consistency, and attention to detail. I definitely still value those things but I think I’ve softened on them. I’m willing to settle for a few rough edges. In return I get:

  • Systems that are always up to date
  • More hardware options
  • Upgradeable hardware
  • The ability to build an environment that works for me
  • “The freedom to study how the program works, and change it so it does your computing as you wish”.

That last one has come as a bit of a surprise. I’ve always been a fan of open source but was happy to use well-made proprietary software. It turns out that when a huge portion of your system is open source your perspective changes. Jumping through hoops to install proprietary software (that’s not in the system package repos) is kind of a drag, and feels sort of wrong for the system.

There’s also something wonderful about public bug trackers. You can search and track the progress of an issue instead of just submitting it into the void.

Previously: Finding an Alternative to Mac OS X.

GitHub Survived the Biggest DDoS Attack Ever Recorded

Lily Hay Newman (via Dave Mark):

Akamai defended against the attack in a number of ways. In addition to Prolexic’s general DDoS defense infrastructure, the firm had also recently implemented specific mitigations for a type of DDoS attack stemming from so-called memcached servers. These database caching systems work to speed networks and websites, but they aren’t meant to be exposed on the public internet; anyone can query them, and they’ll likewise respond to anyone. About 100,000 memcached servers, mostly owned by businesses and other institutions, currently sit exposed online with no authentication protection, meaning an attacker can access them and send them a special command packet that the server will respond to with a much larger reply.

Unlike the formal botnet attacks used in large DDoS efforts, like against Dyn and the French telecom OVH, memcached DDoS attacks don’t require a malware-driven botnet. Attackers simply spoof the IP address of their victim and send small queries to multiple memcached servers—about 10 per second per server—that are designed to elicit a much larger response. The memcached systems then return 50 times the data of the requests back to the victim.