Thrawn wrote:
Hmm...looks like there is indeed an ABE issue. Maybe kalhimeo still has ABE disabled?
That is a distinct possibility. Prior to looking for help in this thread, I sampled eight different Firefox profiles on the subject of ABE settings and found one of them with ABE disabled. Since the user in question had no idea what ABE was, it's extremely unlikely that he'd disabled it. I have no explanation for this.
Code: Select all
[NoScript] Blocking cross-site Javascript served from https://d3kw9cbwoqg2ak.cloudfront.net/1304282114/assets/config/intl/web.conf?&callback=_jqjsp&_1367389987863= with wrong type info application/octet-stream and included by http://web.airdroid.com/
That is a separate issue, solved by modifying the inclusionTypeChecking preference. Bear in mind that airdroid should not really be doing this. The reason for the error is that cloudfront is declaring the type of the script file to be an attachment, meant to be downloaded, not a script meant to be executed on the page, and NoScript is warning you about the site's incorrect behavior.
After my last post I tried your
noscript.inclusionTypeChecking.exceptions suggestion. It did indeed get rid of that "Blocking cross-site..." error and the proper
http://web.airdroid.com/ login dialog then appeared. I then attempted to use the QR Code login method. Unfortunately, that didn't work, yielding only a dialog containing this Alert message:
Code: Select all
To sign in via QR code, it's required to sign in to an account on the device, unless the device and computer are on the same WiFi network.
Both the Android device and computer were on the same LAN subnet connected to the same router, but the Android device was connected via Wi-Fi and the computer via wired connection. Strictly speaking then, it is true that the computer isn't even on Wi-Fi, so the message is semantically correct but it's misleading because the AirDroid folks were just sloppy -- the problem is ABE, as we will see. I should mention that the Android device I'm experimenting with has no data plan for mobile network, so there's no debate as to which network its using.
I went back to the Error Console and found this new error:
Code: Select all
[ABE] <LOCAL> Deny on {GET http://192.168.76.105:8888/sdctl/comm/ping/?product=intl&7bb=undefined&callback=_jqjsp&_1367448383627= <<< http://web.airdroid.com/ - 2}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
And so we arrive at your next suggestion, Thrawn:
If airdroid.com wants to talk to a local address, then you need an ABE rule. However, the one in the post that you linked seems too broad. Instead of modifying your built-in rule, I would add a second rule above it:
Code: Select all
# Allow web.airdroid.com to talk to its LAN address
Site 192.168.76.105:8888
Accept GET from web.airdroid.com
Accept from LOCAL
Deny
# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny
Does that work?
It certainly does
but I ran into a couple of caveats. First, the new ABE rules cannot be added to
noscript.ABE.rulesets.USER -- it really does need to be added to
noscript.ABE.rulesets.SYSTEM, which is what you were implying by showing them with the pre-existing LOCAL rules. This seems somewhat counter-intuitive to me since the point of USER rules would, in part, be to override SYSTEM rules, no? The unfortunate corollary for me is that not only will my global setting of
noscript.inclusionTypeChecking.exceptions override any updates Giorgio might roll out for that preference, but now the same will be true for
noscript.ABE.rulesets.SYSTEM. The second caveat is that my originally suggested ABE
<resource> syntax of "192.168.76.10?" does not work. Despite Giorgio's ABE Rules Syntax and Capabilities document claiming that glob matching is supported, it apparently doesn't support the full definition of glob as implemented in most shells. My inclination was to further tweak my final
<resource> glob to limit the ABE rule to the part of our subnet allocated to Android devices only, as it would be poor security practise to expose other systems to
http://web.airdroid.com/ -- apparently this isn't possible with NoScript globs, so I switched to a regular expression and it worked.
Here's my current experimental setting for
noscript.ABE.rulesets.SYSTEM:
Code: Select all
# Allow AirDroid to talk to its Android web server LAN address.
Site ^https?://192\.168\.76\.10[0-9]:8888/?.*
Accept GET from web.airdroid.com
Accept from LOCAL
Deny
# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny
@Giorgio: It would be much appreciated if there were a way to specify a regular expression
<resource> utilizing a token of some kind to represent a generic local network. Specifying the subnet explicitly as I have done means that a simple rule will not work for multiple offices.
The solution at this point apparently doesn't solve quite everything though, as I still get this new message in Error Console:
Code: Select all
Timestamp: 2013-05-01 5:14:42 PM
Error: The connection to ws://ws.airdroid.com:8090/webNode?code=airdroid:<UUID-CENSORED-HERE> was interrupted while the page was loading.
Source File: http://d3kw9cbwoqg2ak.cloudfront.net/1304282114/js/widget/Login.js
Line: 1
As far as I can tell from my limited testing though, I've got full AirDroid 2 functionality now
I'd apologize to the TLDR crowd for being long-winded, but they didn't get this far
Seriously, there seems to be an awful lot of people very unhappy with AirDroid 2 not working for them, so I figured some explanation might be useful to those running into AirDroid/NoScript problems.
To the AirDroid developers (should they ever read this), this thread implies some improvements that should be made to your application. We NoScript users shouldn't be having this much difficulty with AirDroid.
Thrawn, your help is
very much appreciated
