[RESOLVED] Problem with AirDoid

[kalhimeo]

Dear NoScript users,

I have a problem using the web portal "AirDroid" when NoScript is activated in FireFox.

I tried to disable ABE, added the website "web.airdroid.com" to the whitelist, tried to play with most of the NoScript options, with no success.

If I disable NoScript, it works like a charm.

Any suggestion would be very welcome.

Regards,
Laurent

[Thrawn]

What kind of failure is there? The page doesn't load? Things don't work when you click them?

Are there any errors or messages in the Error Console (Ctrl+Shift+J)?

[kalhimeo]

What kind of failure is there? The page doesn't load? Things don't work when you click them?

Are there any errors or messages in the Error Console (Ctrl+Shift+J)?

In fact I should have given more details. When I visit the link above (http://web.airdroid.com) the page does not load as it should and a popup shows up "Failed to load configuration file, please click OK to sign-up again". If I click OK the page reload with the same error message.

If I disable NoScript in FF modules, the page will load as it should and looks like this:


From the error console, I found this :

Code: Select all

[NoScript] Blocking cross-site Javascript served from http://d3kw9cbwoqg2ak.cloudfront.net/1304282114/assets/config/intl/web.conf?&callback=_jqjsp&_1367229905144= with wrong type info application/octet-stream and included by http://web.airdroid.com/

I tried to add cloudfront.net to the whitelist with no success.
There are also plenty of other errors in the console, but I think that those result from the NoScript blockage.

You may give it a try yourself, the page does not require any login information to load.

Thank you very much for your help.

[Thrawn]

OK, this is a known issue of websites behaving badly, although when the source of the script is Cloudfront, rather than a public code repository, it's probably somewhat safer.

As Giorgio has previously advised in a similar situation, you'll need to add d3kw9cbwoqg2ak.cloudfront.net to your noscript.inclusionTypeChecking.exceptions about:config preference (space-separated).

[kalhimeo]

That made it, thank you so much for your help Thrawn.

Best regards,
Laurent

[s3drghkei]

As Giorgio has previously advised in a similar situation, you'll need to add d3kw9cbwoqg2ak.cloudfront.net to your noscript.inclusionTypeChecking.exceptions about:config preference (space-separated).

Is it possible to solve this problem by adding some kind of ruleset to noscript.ABE.rulesets.USER instead of using noscript.inclusionTypeChecking.exceptions? I ask because I found this posting which claims something similar.

My situation is that I need to roll out an AirDroid/NoScript solution that works for numerous Firefox profiles and we do this kind of thing with a global Firefox configuration file. If I use noscript.inclusionTypeChecking.exceptions, then a later NoScript update that might need to change that preference would be overridden by my global setting. The same is true for noscript.ABE.rulesets.SYSTEM, but noscript.ABE.rulesets.USER is clearly designed for end users to make use of without worrying that Giorgio will ever want to set that preference in any future update.

I freely admit I don't have a good grasp of how ABE works and I can't find any documentation for what noscript.inclusionTypeChecking.exceptions actually does. I tried the following in noscript.ABE.rulesets.USER, but achieved no success:

Code: Select all

Site web.airdroid.com
Accept GET from 192.168.76.10?
Accept GET from .web.airdroid.com
Accept GET from d3kw9cbwoqg2ak.cloudfront.net
#Accept GET from d2g5qgpq0ondj5.cloudfront.net
Deny

The commented out reference to d2g5qgpq0ondj5.cloudfront.net was because I saw that a style sheet was being pulled from there while watching with Firebug.

[Thrawn]

Is it possible to solve this problem by adding some kind of ruleset to noscript.ABE.rulesets.USER instead of using noscript.inclusionTypeChecking.exceptions? I ask because I found this posting which claims something similar.

In short: no. The feature that is firing here is completely separate to ABE, and ABE only applies extra restrictions, it doesn't relax any restrictions imposed by other features.

However, if Giorgio considers this situation to merit an exception, he might add that to the next NoScript release.

My situation is that I need to roll out an AirDroid/NoScript solution that works for numerous Firefox profiles and we do this kind of thing with a global Firefox configuration file.

Cool .

If I use noscript.inclusionTypeChecking.exceptions, then a later NoScript update that might need to change that preference would be overridden by my global setting.

True. I'm pretty sure that if you customise that setting, then future updates won't automatically update it.

On the other hand, exceptions don't often get added to that list, and it's usually just for specific sites. Sounds like the interaction with Airdroid is more important to you, so unless Giorgio decides to add this to the official release, I'd suggest just going ahead and adding it to your custom profile.

The same is true for noscript.ABE.rulesets.SYSTEM, but noscript.ABE.rulesets.USER is clearly designed for end users to make use of without worrying that Giorgio will ever want to set that preference in any future update.

True. Anything globally applicable would go in SYSTEM.

I freely admit I don't have a good grasp of how ABE works and I can't find any documentation for what noscript.inclusionTypeChecking.exceptions actually does. I tried the following in noscript.ABE.rulesets.USER, but achieved no success:

Code: Select all

Site web.airdroid.com
Accept GET from 192.168.76.10?
Accept GET from .web.airdroid.com
Accept GET from d3kw9cbwoqg2ak.cloudfront.net
#Accept GET from d2g5qgpq0ondj5.cloudfront.net
Deny

Well, ABE can't fix your problem, but just so you know, that rule is backward. ABE rules are oriented around the destination of requests. It should be more like:

Code: Select all

Site d3kw9cbwoqg2ak.cloudfront.net
Accept from SELF
Accept GET from .airdroid.com
Deny

[s3drghkei]

Is it possible to solve this problem by adding some kind of ruleset to noscript.ABE.rulesets.USER instead of using noscript.inclusionTypeChecking.exceptions? I ask because I found this posting which claims something similar.

In short: no. The feature that is firing here is completely separate to ABE, and ABE only applies extra restrictions, it doesn't relax any restrictions imposed by other features.

Thanks, Thrawn. So that other author missed the boat entirely, or are there two unrelated problems using AirDroid with NoScript that both need to be addressed? I assume not since kalhimeo seems to be happy now without mentioning ABE problems. But what is confusing me is that AirDroid is triggering a Firefox infobar to appear saying:

Code: Select all

Request {GET http://192.168.76.105:8888/ <<< http://web.airdroid.com/ - 6} filtered by ABE: <LOCAL> Deny"

which seems rather ABE-specific, and Error Console is generating 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/

[Thrawn]

Thanks, Thrawn. So that other author missed the boat entirely, or are there two unrelated problems using AirDroid with NoScript that both need to be addressed? I assume not since kalhimeo seems to be happy now without mentioning ABE problems. But what is confusing me is that AirDroid is triggering a Firefox infobar to appear saying:

Hmm...looks like there is indeed an ABE issue. Maybe kalhimeo still has ABE disabled?

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?

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.

[s3drghkei]

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

[s3drghkei]

I spoke too soon. ABE is still getting in my way for some things in AirDroid. From the Error Console I see this sort of thing when trying to upload a file using AirDroid:

Code: Select all

[ABE] <^https?://192\.168\.76\.10[0-9]:8888/?.*> Deny on {OPTIONS http://192.168.76.105:8888/sdctl/comm/upload/dir?7bb=8a8a8a8a8a8a8a8a8a8a8a8a8a8a8a8a8a8a8a8a8a&fn=afile.png&d=%2Fsd%2Fairdroid%2Fupload%2F&after=0&fname=afile.png <<< http://web.airdroid.com/ - 11}
SYSTEM rule:
Site ^https?://192\.168\.76\.10[0-9]:8888/?.*
Accept GET from web.airdroid.com
Accept from LOCAL
Deny

Note that I sanitized the "8a8a..." string, but it was originally still just hexadecimal characters.

I've played with that regular expression to no avail. It wouldn't be the first time I made a dumb mistake with regular expressions, but where have I gone wrong here?

[Thrawn]

Ah. Looks like GET is not enough. How interesting; I'd never before seen a website actually use the HTTP OPTIONS method. However, it's supported in ABE.

Please change the 'Accept GET from web.airdroid.com' to simply 'Accept from web.airdroid.com' (to accept all HTTP methods).

[s3drghkei]

Ah. Looks like GET is not enough. How interesting; I'd never before seen a website actually use the HTTP OPTIONS method. However, it's supported in ABE.

Please change the 'Accept GET from web.airdroid.com' to simply 'Accept from web.airdroid.com' (to accept all HTTP methods).

Much thanks, Thrawn, that fixed it!

This is the ABE ruleset I'm now using successfully, although I will yet tweak the regular expression a bit to account for our address allocation scheme.

Code: Select all

# Allow AirDroid to talk to its Android web server LAN address.
Site ^https?://192\.168\.76\.10[0-9]:8888(/.*)?
Accept from web.airdroid.com
Accept from LOCAL
Deny

# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny

[kalhimeo]

Hi guys,

Sorry I only had a daily notification for this thread, so I only see your posts now.

I always had ABE disabled, that's why I had no problem with that.

In the meantime, I see that you found a solution, which is always nice

Regards,
Laurent

[Thrawn]

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?

No, USER rules can never override SYSTEM rules, only supplement them.

The original purpose of ABE was to protect sensitive sites from cross-site request forgery. Giorgio provided a built-in rule that protects your LAN from tampering by websites (which is why Airdroid runs into trouble; it's being blocked by design). You can supplement this built-in rule with extras to protect Facebook, or your webmail, your bank, etc. That's why 'Site' refers to the destination of the HTTP requests; it's meant to mean 'the site that I'm writing a rule to protect'. People often trip over at this step and get rules backwards, because they don't understand this crucial point about ABE's original design.

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.

True, but they almost never happen. The original LOCAL rule has remained untouched since it was added.

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.

'Globbing' in this case just means asterisks, as far as I'm aware. You could try that instead of the question mark. Or, as you've discovered, you can give up and use a full regex.

@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.

I'm not sure what you mean by this, apart from the existing 'LOCAL' keyword? If you really want to apply this to multiple LANs, and if you're very confident that no-one on those LANs has access to sensitive sites by virtue of their network location (router admin pages, local servers, etc), then you could just modify the built-in rule. But you've already indicated that you don't want non-Android systems to be included.

You should be able to write a regex that would cover all of your LANs, though. Or, multiple regexes; you can put multiple (space-separated) entries in the Site expression.

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.

It's by design, I'm afraid. Airdroid wants to talk to a device on your LAN, and NoScript considers that to be suspicious behavior (by default).

Thrawn, your help is very much appreciated

You're quite welcome . It's what the support team is here for.

You know, this discussion has reminded me of a thought that I've had before, about the idea of having a keyword available in ABE rules, eg 'TRUSTED', to refer to the regular site whitelist, so you can have rules that take into account whether you trust a site. Then you could have a rule such as:

Code: Select all

Site LOCAL
Accept from LOCAL
Accept GET HEAD OPTIONS from TRUSTED
Deny