[Pythonmac-SIG] appscript terminology caching #2

[has]

Ronald Oussoren wrote:

>>>>There's all sorts of issues with starting daemons (like: will the
>>>>daemon be system-wide or per-user?
>>>
>>>It's a user-level process, so I guess that makes it per-user. Out 
>>>of interest, does [Mac]Python run anything at any other level?
>>
>>No, what I meant was "if user Jack starts ATS, then user Has logs 
>>in (either via the net or with fast user switching), will he use 
>>Jack's ATS?". Because that could have security implications (such 
>>as allowing access to terminology for apps to which Jack has access 
>>but Has not).
>>
>>But it turns out this is probably not a problem: as ATS uses OSA 
>>any problem will exist with AppleScript without ATS too.
>
>Depending on how ATS works there could be other problem: there is no 
>reason to assume that user Jack started a real ATS. What if he 
>started a modified version of ATS that returns garbage?

Then appscript will fail. But this would be true for any scriptable 
application. You can only use Remote Apple Events when both client 
and server can be completely trusted, otherwise it's a massive 
security hole.


>What happens when two users are logged on at the same time (Fast 
>User Switching)?

Don't know how FUS works, so hoping somebody else can tell me how 
application scripting, RAE, etc. work under it. It's a question that 
definitely needs answered.


>I don't like a hidden daemon, especially when it accesses the 
>network and can be accessed across the network.

ATS only operates across the network when an ATS client such as 
appscript asks it to, and provides it with IP address, username and 
password for the remote machine in question. And ATS can only be 
accessed from the network when the machine it's running on has RAE 
enabled and the other party has valid access permissions. It has no 
independent network access priviledges - it's merely a gopher for 
priviledged third parties.

Again, this is an issue that applies to _all_ scriptable 
applications. In remote scripting, ATS and other scriptable 
applications never open their own ports, they use a port that's been 
explicitly opened by the sysadmin with (one hopes!) full knowledge of 
the security implications of doing so. I suspect you're addressing 
your security concerns to ATS when they actually belong to RAE. With 
RAE there is no application-level security, only system-level. If a 
hostile party breaches your system-level RAE security, you're screwed 
regardless of whatever apps you're running.


Note: All these security questions are absolutely valid so please 
keep raising them, and it's essential that we bang out some 
convincing answers to them 'cos if folk here are asking them then 
sure as hell every future appscript user is going to ask them too. 
(BTW, I'm really quite peeved Apple doesn't have a decent discussion 
of RAE security issues prominently located on their site, especially 
when they like to rattle on about how much more secure MacOS X is 
compared to Windows, etc. I'll definitely mention this as well when I 
raise the concerns discussed here on AS-Implementors next week.)


>What about writing the cache in ~/Library/Python/appscript.cache?

Because nobody's yet managed to come up with a solution for a 
file-based cache that didn't require lots of manual maintenance work 
by the user, which completely defeats the point of something like 
appscript whose whole raison-d'etre is ease of use. :)


>Or why use a cache at all?

1. As a useful performance enhancer that gives us a fighting chance 
at matching AppleScript for application scripting speed.

2. As an essential source of terminology data for remote application 
scripting (as Apple's APIs do not currently support retrieving 
terminology from a remote machine).

ATS takes care of both tasks with a minimum of fuss and complexity 
and requires near-zero user interaction, which is why I'm currently 
preferring it to a file-based cache.


>I agree with Bob: if you want the extra performance you can 
>explicitly create a cache module.

Except this creates extra maintenance hassles for the user, and we're 
back to having inferior application scripting support compared to 
AppleScript. Which simply isn't good enough: either we kick 
AppleScript's butt or else we're just wasting our time, because 
nobody is going to use a second-rate technology. That's the problem 
we gotta solve, and it's a bit bigger than simply finding 'something 
that works'. But then, isn't that half the fun o' programming anyway? 
;)


Many thanks,

has


p.s. Here's an idea for an interesting side project if somebody was 
interested in pursuing it: an XML-RPC/Apple event bridge. (I read it 
off some Lisp guy's blog entries while googling for RAE info so can't 
claim originality, but they were dated 2003 so I guess he never 
pursued it himself.) Something that hooks a Python-based XML-RPC 
server to aem, allowing any language that speaks XML-RPC to control 
applications, and, unlike Remote Apple Events, is designed 
specifically for use in untrusted environments.

p.p.s. Another nifty-cool idea is a CGI frontend to iTunes; e.g. 
there's a guy sells an Apache ACGI extension for OS X, and this is 
one of the demo projects he includes. With Python's excellent (and 
free!) support for web programming and a copy of appscript, we could 
easily go one better.
-- 
http://freespace.virgin.net/hamish.sanderson/