Proxy server for Siri | Hacker News Reader

Proxy server for Siri

github.com

214 pointsfriggeri41 comments

I'm actually wondering if it'd be possible to get this to work over 3G without jailbreaking. Can somebody smarter than me tell me if this would work:

- Installing root CA. - Setting up the proxy on ec2 instance. - Setting up a custom DNS server on that instance, to override the Siri domain. - Setting up the iPhone to use that DNS server, or if not possible, setting it up to use a VPN and through the custom DNS.

And the end result is a Siri that always works and that you can use to run code on an ec2 instance. You'd be able to hook it up to third parties APIs, like Twitter or Facebook.

I've been trying to figure this out too... I think the VPN is the only way to get it working over 3g, as there's no way to override the DNS on the cell connection. Thanks for that idea, VPN hadn't occurred to me! I'm going to give it a shot; I'll report back if successful.

Edit: Success! I'm not running it on EC2 yet, just my home network. Basically I've got dnsmasq on my router redirecting guzzoni.apple.com to my home fileserver with SiriProxy running. The router is also running a PPTP VPN server. I can use the VPN over 3g to make Siri requests and see the output on my local machine. Thanks again for the VPN idea; that's gold. Next step - to the cloud!

You can also setup an APN Proxy using the iPhone Configuration Utility.

Oh, awesome. Thanks!

Uhm, running a Ruby script as root? No...

If you're running it on Linux, use iptables to redirect the port to something you can use without root: http://www.cyberciti.biz/faq/linux-port-redirection-with-ipt...

or start as root, bind to the port and then drop privileges, but it's easier said that done properly. i'm no ruby expert either.

I'm all for avoiding running things as root, but what does it being written in Ruby have to do with it?

It probably has a greater attack surface that can be exploited. The advantage of iptables is that it does the barest minimum at a high privilege level: http://en.wikipedia.org/wiki/Principle_of_least_privilege

Beware that there is no consensus that this is a good thing.

From Daniel Bernstein(qmail creator) at http://cr.yp.to/qmail/qmailsec-20071101.pdf

"I have become convinced that this “principle of least privilege” is fundamentally wrong. Minimizing privilege might reduce the damage done by some security holes but almost never ﬁxes the holes. Minimizing privilege is not the same as minimizing the amount of trusted code, does not have the same beneﬁts as minimizing the amount of trusted code, and does not move us any closer to a secure computer system."

There's no consensus that "reducing the damage done by some security holes" is a good thing? Bernstein mentions it as a distraction (which may be true), but it's better than doing nothing.

I feel that fixing the security holes has little to do with reducing the damage done due to increased attack surface.

If you're a software developer who is not doing security research, and who is mainly interested in some functionality offered by a module, you'd be better off giving the module exactly the privileges it needs, not more and not less. If not, wouldn't OS's run all user-space programs in ring-0? (Maybe I am stretching it a bit)

If Bernstein meant that this principle has been misquoted/abused/understood in all wrong ways (like most of the "premature optimization" quotes), then perhaps it makes some sense. :)

Nothing against Ruby specifically, 'though I guess I do have a prejudice (in terms of security) against interpreted languages in general compared to something written in C.

Dumb question: wouldn't it be more secure to use languages that are immune to C issues like buffer overflows?

That's actually a good question. The lack of buffer overflow vulnerabilities does make interpreted languages safer to a point. Still anything that listens on an open port shouldn't run as root, there are still plenty of vulnerabilities besides buffer overflows out there.

At least they didn't provide a one-line install from a non-https server, too.

Just use "curl http://www.example.com/install_this.sh | sudo sh"!

Can anyone explain to me how does relaying in a proxy like this work?

Since you're not tampering with the iPhone's hosts file, and use, let's say, your home PC for handling the guzzoni.apple.com dns + CA for level certs.. I'm wondering how you send the request to the actual guzzoni.apple.com? I mean, if you do $ curl -s https://guzzoni.apple.com on the home PC, it would respond with the localhost server as you've rerouted it to 127.0.0.1 in the home PC's hosts file - or am I missing something here?

Should I use two PC's, one for handling the iPhone interaction, and one as "backbone" which can reach the real guzzoni.apple.com?

Or am I suppose to run a dns service which responds <internal ip of home PC> for SOME devices, but real dns for others (e.g. home PC)?

As the page says,

  make sure that computer is not using your DNS server!

So, your iPhone uses your special DNS server, while your computer doesn't.

This is pretty neat. You could potentially link Siri up with all kinds of crazy stuff.

"Siri start my truck" "Siri feed the dog"

You mean "Siri charge my leaf" and "Siri trurn on heating in my leaf"? They'r coming this christmas, when I get my Nissan Leaf :)

Twisted implementation: https://github.com/wrboyce/sirious

I am waiting for the standalone one. Without using an iPhone.

Probably in less than one month will be available.

Apple will probably lock down the protocol if that happens. They're not Google, giving away search for free.

There is only so much they can do to lock it down; like all DRM, the system is inherently insecure since the client can't be trusted.

In any case, I don't see why would they care unless more than one person starts using the same UUID. If you bought an iPhone to use the service, they already got the money.

That is one way of looking at it. Consider the hardware your ticket to Siri, and as long as you don't place abnormal demand on the service, there's really no reason Apple should care.

It's not possible to do that from the security point of view, you are the owner of the device. They can make it difficult to massively "scrape" Siri using the same device identification.

Nothing is really free if you're getting from a large publicly traded company. They also don't use Siri to target ads towards the user such as Google and Facebook.

They don't, so far.

In the future, they will sell analytics, access to be included and potentially ads.

Will they? Any reference to back that up? I don't think Apple has done this in the past, and I don't think they've said they will either.

Apple themselves acknowledge that they use location information gleaned from iphones to build a location database.

https://www.apple.com/pr/library/2011/04/27Apple-Q-A-on-Loca...

Excuse my direct language, I should've phrased it more clearly as a thoughtful guess. Seems like an obvious bet too.

At some point in the past they hadn't broken into the phone market, or had a music store, right? Think of it a bit like how Google created AdWords/AdSense alongside their search engine.

I got a 4s the other day and outside of the US at this point, Siri is pretty basic. Can't ask for directions. Can't find a business. Too many things get directed to a basic web search which I could've pulled up myself in the time being. Didn't take too long to realise how quickly they could monetise the experience my charging for third-party involvement, for data, etc. "When's the next SportsTeam game?" "April 1, do you need tickets?"

Apple is a company. They're there to make money. I can't see how they could not take that route if they handled it very carefully.

From what I can get from the applidium stuff, you only need an iPhone for the uids, for now.

Technically, I suppose they could be shared, but I guess Apple would find out and terminate the account pretty soon.

The session validation data expires after a few hours, and at least one of the other identifiers is subject to being changed by the server. As of now there's no practical way to share your authorization info.

Pretty neat, nice work.

Before we know it, someone will have made an app that fully integrates Siri into the Android workflow.

Why would Android (3rd party developers) want to be so obviously using Apple's hard work? In the middle of a patent trial? I'd expect all the big markets to not allow the app.

> Why would Android (3rd party developers) want to be so obviously using Apple's hard work?

Unlike iOS develoeprs, Android developers are not a homogenous group with a single vision. They are a diverse group of people, and there will no doubt be someone amongst them who will make such an app.

> In the middle of a patent trial?

I don't see the relevance of "a patient trial" to a 3rd party developer unaffiliated with Google making an app to harness Siri on Android.

> I'd expect all the big markets to not allow the app.

Fortunately, unlike iOS, Android doesn't suffer from a locked down app installation procedure that prevents sideloading. So the developer could just offer the .apk file on his site for all and sundry to download and use.

What's the legality of distributing an app like that, though?

I(ANAL) can't think of any laws being violated, can you?

Using Apple's server processing that they don't even want to offer to the current ipod touch?

Unless user-based authentication is necessary to use Siri (and the unofficial version "breaks into" the Siri servers), I don't see how this is any different from a website saying you can only use one browser to access the site, and you choosing to use another.

However, IANAL, and I would definitely wait for at least a few weeks after release before trying it out myself.

Yes they are all different people, but it'd help Apple's case publically, but probably no differnce in court.

Reply on news.ycombinator.com