gepeto42

Yes, and that is great, because iCloud backups are not. So I assume (TBD) that if you enable iMessages in iCloud, they do not need to be backed up as a part of the end to end encrypted iCloud backups, which would increase security for anyone backing up to iCloud or anyone communicating with those who do!

There is always a delay. Usually the e-mail distribution goes out an hour or two after the update itself is released, and the support page gets updated a little bit after that.

The state of SOHO router security is pretty sad. Sure, most of those infected were probably unpatched, possibly had remote-admin pages enabled, or were using default credentials but... why is it even possible to open the remote admin interface with default passwords?

Why don't they all auto-update by default for critical vulnerabilities?

Not sure who said it first, but cryptocurrency truly is the Internet-wide bug bounty.

That is exactly what I was hoping for.

Too bad it'll take forever before iOS can use it, because the current state of VPN on Wi-Fi is terrible (I understand that is not the first thing WireGuard is looking to solve, but it'll be great when it gets there).

I have not tried WireGuard yet. Is it more reliable than existing methods over "bad Wi-Fi"?

I find that one of the best ways to make bad hotel or plane Wi-Fi completely unusable is to use a VPN, and having something more reliable on bad links would be great.

Encryption plugins on top of other mail clients has always been a recipe for disaster.

That being said, why would EFF tell people to completely uninstall it? When I hear that, I think "There is a crazy, in the wild, no user interaction needed remote code execution vulnerability". If someone had a use for PGP/GPG email (assuming they understand the threat model and the metadata that is not encrypted), surely they're better off with a buggy version that with pure cleartext?

The BSSID can be read too, so I don't think it's worth trying to figure out ways to add some obscurity to the SSID (no matter what downsides would come with that).

Yeah, it was supposed to be - https://developer.apple.com/documentation/networkextension/n...

Around iOS 9, Apple deprecated some of the Captive Portal APIs, then re-instated them, a lot of changes that went back and forth, but my conclusion is that today, years later, way too many apps seem to read my SSID. Doesn't really matter how they do it, but I wish there was a prompt for it and no way for an app to directly fetch it.

They need to be much more aggressive towards apps that request access to the SSID of the current network. This is supposed to be limited, but in my experience, apps you would not expect to be doing that are doing it, and it's basically the same thing as location data.

Yes, it would be better if those businesses had systems/APIs for those transactions to be done, but we still live in a world where scanning a sheet of paper that was printed and mailed to you with a phone often reduces friction on the action of moving money between two accounts.

That being said, as someone who has used "assistant as a service" stuff before, I wonder how well this will work or how limited it will have to be, and not just because of the AI itself.

Even with humans on both sides, it's amazing how hard it can be to get an answer let alone a request fulfilled in a single phone call.

Questions about table placement, food allergies or other restrictions could come up, which I wouldn't want going to an operator. I'd rather be told in advance that it is calling the restaurant and have it send me questions in real-time with suggested answer buttons until it learns enough about me not to need them.

In other cases, just having it call and stay on hold for me would be useful. "Ok Google, call my mobile operator so I can talk to someone at around 10am" and having it use data it already has from other calls to place the call at around 9:45 and patch me in at the right time would be useful.

Yes. This is a very old article I had written back in the iOS 9 days, it still mostly applies.

A few warnings:

1 - Changing an iOS device to "Supervised" will wipe it (so you can't supervise someone else's device and data).

2 - Backing up iOS devices over USB after requires that you keep the keypair, and makes restoring to new devices much more complicated. I would not recommend relying on USB backups if using this method unless you play around and understand it well.

3 - Be sure you set the profile to be removable only by wiping the device, or using Device Configurator, otherwise, the profile could be deleted to enable USB.

4 - One could wipe the keys completely to be sure that NO machine has USB access to the phone, meaning it would need to be restored to factory defaults for USB to work again.

https://blog.rapid7.com/2015/11/26/reduced-annoyances-and-in...

Or, you could make your device supervised via MDM or Apple Device Configurator, and disable "Allow devices to pair with other computers". This will generate a keypair on the machine running Device Configurator + the iPhone, and no other USB data connection will be allowed - you won't get prompted for "Trust" at all (except for CarPlay etc.).

On top of that, since iOS 11 (or maybe 10), trusting a USB device requires the passcode by default, so even having your phone ripped out of your hands unlocked does not lead to the ability to take a USB backup directly anymore.

Apple knows. Look at the security content of iOS 7.1.

http://support.apple.com/kb/HT6162

I reported CVE-2013-6835. They fixed Facetime-Audio from Safari, but not from other browsers (yet?). This is quite a wide issue. I do not think letting every individual developer know is feasible. I did it for a few bad issues, but there's a limit to what can be done.

And a lot of these can be found in a matter of minutes anyways.

Chromium Bug Thread about this: https://code.google.com/p/chromium/issues/detail?id=329259

"In practice, the closest to 'malicious' use I've seen the redict-to-app-store-from-ad case"

Hi guys,

I just did a talk during BSidesLV on the subject of URL Schemes and dangerous implementations.

For those who want all the details:

http://youtu.be/rJroherlZVo?t=1m33s

For those who want to skip explanations on how they work and see the bad examples, auto skipping about 10min:

http://youtu.be/rJroherlZVo?t=10m24s

One example that I have in there is Yo. Yo will automatically Yo someone on your behalf. So if an inline frame has yo://gepeto42 (basically), and you have Yo installed, I have just "de-anonymized" your Yo account as you browsed my website (or any page where I could inject that iframe). A good tip on where to find out about those is to buy Launch Center Pro and to extract the plist it has. This has info about hundreds of iOS apps and how their URL Schemes work.

Happy hunting.