It would have to check hashes on everything being loaded in to execution and maybe even memory, not just the original EXE. Sorry if I was overly simplistic in my original explanation. I can see how it might reduce security slightly, but I think the majority of what UAC is designed to do would still be preserved.
Hmm, I'll have to look in to that, I don't mind the risks of certain apps having attack vectors utilize them if I use them frequently anyway (since it could compromise and simply wait for me to launch anyway).
That's a fair point, though wouldn't that really still be a problem with UAC? If the application is a known good executable that can be compromised, by altering a library, then when someone legitimately uses it, it would still be compromised. If you are worried about automatic exploits that would compromise and then self launch, I suppose those would be a concern, though you could also probably check hash values from anything getting loaded in to a privileged state (program and dll atleast). It would still leave corrupt documents as an issue, but even those could theoretically have hashes stored and then updated on save. It does add some complexity to the system though.
Sorry for two posts, but also, how would they become an attack vector. That's the point of having a hash. If you could compromise the system, then sure it would be a viable vector, but if you can do that, why not simply have your malware sit waiting for you to launch the app and when the app launches, exploit your legitimate authorization? It might delay the exploit, but wouldn't prevent it from eventually occurring. It just slows it down a little. Granted in a small number of cases, that might make a difference if virus defs were updated before you ran the affected program or had a chance to update the program. That said, you presumably wouldn't save authorization on apps you didn't use frequently.
Not that that is a bad approach, but if something manages to compromise the integrity of the UAC screen to be able to click the approve button, couldn't it also then compromise the integrity of the password entry and log your password off of a legitimate authentication? It is still another hurdle to overcome, but I'm not sure that it is significantly more or a hurdle than managing to somehow interface with the accept button to bypass UAC.
On the flip side, if the car could drive itself, would people need to know how to drive? Initially, yeah, they probably would in case things don't work right, but eventually it wouldn't really be necessary. I'm not saying that your point doesn't have validity either, but trying to point out that that line is constantly moving. The average consumer doesn't know how to hook up their TV either and buys $40 3 ft monster cable HDMI cables and thinks they got a good deal cause it was 20% off. At the end of the day, once a network is setup, it really shouldn't have to be touched. I'd say they should probably have an idea how to join a wireless network, but not necessarily the knowledge to understand the configuration options and setup a base station. I'd argue the ability to remember I was using that WPA thing with this password is probably sufficient. The rest can be magic that they have someone setup or some fancy wizard from the vendor helps configure.
There is one thing I don't understand why they don't do. Why not store a hash of an executable and allow storage of the approval? If the same program, in an unaltered state wants to run again later, it should be allowed to without prompting. (If the user chose to approve it for future use.) Personally, I'm willing to use it even if I have to click every time, but this would be more convenient without noticeably impacting security. (Technically there are executable stuffing approaches that could match the hash, but that would seem to be tricky, particularly if rewriting the file became a protected operation itself.)
They were conservative on the transformer. Ive gotten more than 18 hours of use out of mine with dock or 11 with just the tablet and the prime should be longer still.
Yeah, I'd agree that iPad 2 is still slightly more responsive than the Transformer, but only by measure of how occasionally an app might lag loading. The performance increase in the Prime's quad core Teggra3 is supposed to more than offset this though and make it smoother than iPad 2 (as it really should since it is newer). Also, it's worth pointing out that the Transformer particularly, and the Prime as well are both cheaper devices. Not trying to bash the iPad2, it's decent kit if you don't mind the walled garden, but it probably isn't the best deal and with the Prime is no longer the best performing (though it still has the app market going for it for now).
Funny that you comment on my literacy, but can't see the fact that the person I was responding to said nothing about fragmentation what so ever. If you must know, I was responding to "There is absolutely no use in shelling out good money for an inferior Android product and then trying to get it to work correctly and efficiently." in the actual post that I responded to.
And I'm not sure how my rant about Cocoa Touch documentation or XCode documentation says anything about my literacy. If I wanted a work of literature, it is great, but if I wanted easily accessible documentation that is easy to find the information I want, then it is very sorely lacking. Take a look at the number of hyperlinks and the organization of information in something like MSDN documentation or PHP documentation and it is easy to see what I am referring to.
I should also point out I don't hate the iOS platform (though I will admit I have a strong dislike, bordering on hatred for Apple the company), it isn't personally for me, but I still DO develop for it. I hate however, the fact that people feel the need to over glorify it and spread FUD about Android at the same time because it threatens their precious walled garden.
Interesting, I have never had any noticeable issue when scrolling on my Transformer and I got a very early 32gb model. When do you notice the lag? Do you have any apps that might be misbehaving in the background and do you have it rooted and/or running alternate roms? Mine is pure stock.
Have you ever used an Android tablet? Wait, don't answer that, I can answer it for you. No Android tablet I've ever used has issues working correctly or efficiently. The Prime that was initially mentioned actually performs faster, lighter and cheaper than the iPad 2 in both real world tests and raw benchmarks and I've yet to find an app on the Android market that doesn't work without issue on my Transformer.
Also, the supposed well documented joys of iOS development is a total joke. If you grew up Apple, then maybe it could be ok, but trying to transition to cocoa touch and trying to use that POS called XCode made me want to poke my eye out with a needle and eat it (along with the needle). The documentation reads like a novel rather than technical docs and was next to useless. But by all means, keep drinking your koolaid, I'm sure it tastes great. Never mind the slight taste of almonds.
I'm not sure how I seemed to be expressing certainty in my earlier post. Perhaps something was simply miscommunicated. I know for a fact that such arrangements exist (that make it cheaper for monthly, recurring transactions, but I don't know the internals of their business. I was just making the statement that there are many reasons why a business would consider it cheaper to have monthly recurring payments processed without a fee while one off payments would have one. The company I work for has the type of arrangement I described where recurring is cheaper than one off (substantially).
I have done a lot of consulting work with credit card and ACH processing for many companies and would argue that ACH or EFT is the much more standard way of moving money around. Credit cards simply take too high of a cut of the funds in any transfer to be worth it to anything but retailers that make up for the cost in sales that would not happen if people needed to use cash. Credit cards are something to be avoided in doing business unless you feel that you would lose more than 3% or so of your business by not using them.
To address your points, it is entirely possible that they process the regularly scheduled payments differently. There are credit card clearing houses that look for easy, repeat business and charge less for the service. (It is considered lower risk.) Even if they are not using one of these clearing houses, it is possible that they simply see the predictability of their income stream as enough reason to be worth the cost.
That said, I don't even think that matters. The vast majority of online bill payment systems I know of do not allow you to pay with credit. Effectively, your bill is like giving you credit for the service you received during the month. Effectively, Verizon is already taking an income hit to bill you at the end of the month. To take the hit again by allowing payment by credit card is not typical behavior for a company that does monthly billing, at least from any companies I've worked with.
The fact that Verizon allows it at all, let alone for free if you schedule it to be automatically paid, is a plus in my opinion. Since I already see the credit card payment option for a monthly bill as a plus, I don't see how charging a fee that will only recover part of their costs in comparison to bank transfers is unreasonable. It is perhaps less awesome than it was, but I still think the balance is in the consumer's favor.
Apparently I should have RTFA before replying to comments. It appears the summary is misleading (shocker, I know). This fee ONLY applies to credit card payments made over the phone or through the internet and ONLY to non-automatic online payments. In that case, yeah, it is simply a cost recovery for credit card processing fees and I see no problem with it what-so-ever. Hell, when I pay my bill with Verizon with my credit card, I personally get more than $2 back on it and I pay automatically each month anyway, so I'm not even effected by the decision. I've always thought it was unfair in my favor that they accept credit card for monthly billing, but hey, if they want to offer, who am I to turn them down?
Sounds like you have a bad IT department. I'm glad that the IT department at my office is great to work with (from my perspective as a developer). I know most of business still thinks that IT uses a magic wand to make things work though and has little or no interest in wanting to know more. They actually seem to tend to work more directly with the software development side of the house to move things in to place and then development works with IT on the server side. Obviously client issues still go direct to IT though, but those are normally minor issues.
Thanks for that great write up. That made a lot of sense and kind of confirmed what my initial guess was. (That a lot of the issues early on were probably related to poor compiler behavior (or perhaps poor instruction choice), since the instructions were not getting well used.) It also gave a lot of accessible insights from a software developer's perspective. I'd agree that Intel would have to get their fab costs down to compete with ARM plus I get the feeling a lot of the manufacturers like being able to make their own die to add features as necessary. That's always going to give a power advantage I'd think if you can put more on the die.
It will be interesting to see what happens in the server and desktop market, but for the moment, I think that Intel will keep a hold there due to how entrenched x86 is. (People simply won't want to have to get new software.) The one thing that could change that is if the ARM based Windows 8 takes off, but I personally have my doubts about tablet style computing supplanting the traditional desktop, but rather see it emerging as a parallel branch where ARM will dominate.
Perhaps you could explain this since you seem to be one of the most level headed posters. I work on the software side of the IT house with a fair bit of knowledge in to the electron pushing side, but only in so far as it is necessary for software development, but I've never understood the RISC is better argument. From a purely software implementation standpoint, I've almost universally ended up with significantly faster execution on x86 (and particularly x64) than with anything ARM based, even at similar clock frequencies.
From a developer's mindset, it seems like this should be the case too since a CISC gives you more optimized targets to hit for assembly calls provided your compiler and software design are optimized to be able to use them. The obvious primary concern would simply be price and if the added complexity resulted in a slower number of effective operations per second, but that hasn't seemed to be that significant, at least as long as I've been in that level of the game. (Again, talking purely from a software developer's viewpoint.)
My recommendation is the same as Benaiah's, work at the level you want to be paid for, not the level you are being paid for. If the company doesn't respond in turn and offer you better pay, then you did your best effort and find a new job using your experience as a resume builder. Thus far it has gotten me to a well paid Senior Developer by the time I was 25.
This is truly paranoid. A couple years back the document of TSA procedures was accidentally leaked on to the internet by the TSA themselves (some idiot thought that putting boxes in Acrobat over classified text would prevent someone from being able to read it). They only take note if they find you are actually doing something you shouldn't. As long as the more invasive screening doesn't find anything, there is no reason for them to take note, nor did they at the time of the leak. Now, if you were to have actually had say a knife in your bag that they had to have you check, then you might end up on some list of note, but I still wouldn't worry about it too much since it would just be to look if there was a pattern of things getting left in your bag.
While I can see that you are clearly very upset about a situation that occurred to you personally, you are also being quite paranoid. Yes, sometime extra screening may be necessary at the airport, but that is why they say you should get there early. I too have been pulled aside for additional screening in the past (prior to the body scanners) and found the entire process to be quite acceptable. I'm not sure why people would look at you accusingly on the plane or in the concourse since they wouldn't have any idea about what happened at the checkpoint.
What I can agree with you on is that there have been a number of situations where the screeners did not behave as well as they could have for doing the screening. It should be made very clear to the individual why they are getting taken aside and every effort should be made to make the process go quickly and comfortably. Thankfully, my local airport has TSA agents that are very good about this, but some of the larger airports seem to have more issues with bad TSA agents.
The process shouldn't make people feel uncomfortable and good communication should allow it to not be uncomfortable. As for the inconvenience, that is part of life. The point of a filtered security process is actually to increase convenience rather than make things less convenient. If it wasn't for the chemical sniffers, to get the same level of real, meaningful security, they would have to put every single passenger through what you went through. This would be incredibly inconvenient. You were certainly unlucky to have failed the test and had to go through it, but that's what happened. You don't have to be a chemist to fail the test or come in to contact with the chemicals either. Working in the yard (ammonium nitrate in fertilizer, cleaning the house (bleach and ammonia) and any number of other mundane activities can result in trace amounts of the chemicals on your person.
Security is always going to be somewhat invasive if the non-invasive checks reveal that there may be a problem. There isn't any way around that. My entire point is that subjecting everyone to invasive checks doesn't give any measurable advantage over using the non-invasive checks and only screening further when the non-invasive process can't show there is no issue.
Now I'll assume you are trolling me since you keep trying to put words in my mouth. I never suggested that guns should be used against any current government and I never said there wasn't corruption. What I did say is that the more reason a government has to fear its people, the less likely it is to go as far with the corruption. Power simply comes down to what people think they can get away with. Voting gives no more power than those with power allow it to have. The foundation of democracy is that the people, as a society hold that power and allow the government to rule by voting to allow it. If the people give up that power then votes can and will eventually beome meaningless.
This is the system working as intended. You don't show up in any database now, just like you don't show up in some DB for setting off the metal detector with a coin in your pocket. The entire point of security screening is to quickly determine reliable indicators that there MAY be a problem and do further screening when they say their might be an issue. If your CPAP machiene set it off, you likely had some chemical that could be a component of an explosive on it. There are many chemicals that can do this legitimately, but the majority of people and devices wouldn't have a detectable amount on them, but it would have a good chance of detecting someone who was actually handling the chemicals recently as well.
The process is the exact same if you set off the metal detector, though they normally do give you one chance to remove things from your pockets to see if it still reads. This doesn't apply to chemical sniffers as you can't take off whatever made it detect the chemical. What happened to you is the way security is supposed to work. Allow the bulk to pass nearly freely and only perform additional screening when a top level is failed. That is exactly what happened.
Slashdot Mirror
It would have to check hashes on everything being loaded in to execution and maybe even memory, not just the original EXE. Sorry if I was overly simplistic in my original explanation. I can see how it might reduce security slightly, but I think the majority of what UAC is designed to do would still be preserved.
Hmm, I'll have to look in to that, I don't mind the risks of certain apps having attack vectors utilize them if I use them frequently anyway (since it could compromise and simply wait for me to launch anyway).
That's a fair point, though wouldn't that really still be a problem with UAC? If the application is a known good executable that can be compromised, by altering a library, then when someone legitimately uses it, it would still be compromised. If you are worried about automatic exploits that would compromise and then self launch, I suppose those would be a concern, though you could also probably check hash values from anything getting loaded in to a privileged state (program and dll atleast). It would still leave corrupt documents as an issue, but even those could theoretically have hashes stored and then updated on save. It does add some complexity to the system though.
Sorry for two posts, but also, how would they become an attack vector. That's the point of having a hash. If you could compromise the system, then sure it would be a viable vector, but if you can do that, why not simply have your malware sit waiting for you to launch the app and when the app launches, exploit your legitimate authorization? It might delay the exploit, but wouldn't prevent it from eventually occurring. It just slows it down a little. Granted in a small number of cases, that might make a difference if virus defs were updated before you ran the affected program or had a chance to update the program. That said, you presumably wouldn't save authorization on apps you didn't use frequently.
Not that that is a bad approach, but if something manages to compromise the integrity of the UAC screen to be able to click the approve button, couldn't it also then compromise the integrity of the password entry and log your password off of a legitimate authentication? It is still another hurdle to overcome, but I'm not sure that it is significantly more or a hurdle than managing to somehow interface with the accept button to bypass UAC.
On the flip side, if the car could drive itself, would people need to know how to drive? Initially, yeah, they probably would in case things don't work right, but eventually it wouldn't really be necessary. I'm not saying that your point doesn't have validity either, but trying to point out that that line is constantly moving. The average consumer doesn't know how to hook up their TV either and buys $40 3 ft monster cable HDMI cables and thinks they got a good deal cause it was 20% off. At the end of the day, once a network is setup, it really shouldn't have to be touched. I'd say they should probably have an idea how to join a wireless network, but not necessarily the knowledge to understand the configuration options and setup a base station. I'd argue the ability to remember I was using that WPA thing with this password is probably sufficient. The rest can be magic that they have someone setup or some fancy wizard from the vendor helps configure.
There is one thing I don't understand why they don't do. Why not store a hash of an executable and allow storage of the approval? If the same program, in an unaltered state wants to run again later, it should be allowed to without prompting. (If the user chose to approve it for future use.) Personally, I'm willing to use it even if I have to click every time, but this would be more convenient without noticeably impacting security. (Technically there are executable stuffing approaches that could match the hash, but that would seem to be tricky, particularly if rewriting the file became a protected operation itself.)
They were conservative on the transformer. Ive gotten more than 18 hours of use out of mine with dock or 11 with just the tablet and the prime should be longer still.
Yeah, I'd agree that iPad 2 is still slightly more responsive than the Transformer, but only by measure of how occasionally an app might lag loading. The performance increase in the Prime's quad core Teggra3 is supposed to more than offset this though and make it smoother than iPad 2 (as it really should since it is newer). Also, it's worth pointing out that the Transformer particularly, and the Prime as well are both cheaper devices. Not trying to bash the iPad2, it's decent kit if you don't mind the walled garden, but it probably isn't the best deal and with the Prime is no longer the best performing (though it still has the app market going for it for now).
Funny that you comment on my literacy, but can't see the fact that the person I was responding to said nothing about fragmentation what so ever. If you must know, I was responding to "There is absolutely no use in shelling out good money for an inferior Android product and then trying to get it to work correctly and efficiently." in the actual post that I responded to.
And I'm not sure how my rant about Cocoa Touch documentation or XCode documentation says anything about my literacy. If I wanted a work of literature, it is great, but if I wanted easily accessible documentation that is easy to find the information I want, then it is very sorely lacking. Take a look at the number of hyperlinks and the organization of information in something like MSDN documentation or PHP documentation and it is easy to see what I am referring to.
I should also point out I don't hate the iOS platform (though I will admit I have a strong dislike, bordering on hatred for Apple the company), it isn't personally for me, but I still DO develop for it. I hate however, the fact that people feel the need to over glorify it and spread FUD about Android at the same time because it threatens their precious walled garden.
Interesting, I have never had any noticeable issue when scrolling on my Transformer and I got a very early 32gb model. When do you notice the lag? Do you have any apps that might be misbehaving in the background and do you have it rooted and/or running alternate roms? Mine is pure stock.
Have you ever used an Android tablet? Wait, don't answer that, I can answer it for you. No Android tablet I've ever used has issues working correctly or efficiently. The Prime that was initially mentioned actually performs faster, lighter and cheaper than the iPad 2 in both real world tests and raw benchmarks and I've yet to find an app on the Android market that doesn't work without issue on my Transformer.
Also, the supposed well documented joys of iOS development is a total joke. If you grew up Apple, then maybe it could be ok, but trying to transition to cocoa touch and trying to use that POS called XCode made me want to poke my eye out with a needle and eat it (along with the needle). The documentation reads like a novel rather than technical docs and was next to useless. But by all means, keep drinking your koolaid, I'm sure it tastes great. Never mind the slight taste of almonds.
Transformer Prime's hardware outperforms iPad 2 significantly, with better battery life, and as I recall is smaller and lighter.
I'm not sure how I seemed to be expressing certainty in my earlier post. Perhaps something was simply miscommunicated. I know for a fact that such arrangements exist (that make it cheaper for monthly, recurring transactions, but I don't know the internals of their business. I was just making the statement that there are many reasons why a business would consider it cheaper to have monthly recurring payments processed without a fee while one off payments would have one. The company I work for has the type of arrangement I described where recurring is cheaper than one off (substantially).
I have done a lot of consulting work with credit card and ACH processing for many companies and would argue that ACH or EFT is the much more standard way of moving money around. Credit cards simply take too high of a cut of the funds in any transfer to be worth it to anything but retailers that make up for the cost in sales that would not happen if people needed to use cash. Credit cards are something to be avoided in doing business unless you feel that you would lose more than 3% or so of your business by not using them.
To address your points, it is entirely possible that they process the regularly scheduled payments differently. There are credit card clearing houses that look for easy, repeat business and charge less for the service. (It is considered lower risk.) Even if they are not using one of these clearing houses, it is possible that they simply see the predictability of their income stream as enough reason to be worth the cost.
That said, I don't even think that matters. The vast majority of online bill payment systems I know of do not allow you to pay with credit. Effectively, your bill is like giving you credit for the service you received during the month. Effectively, Verizon is already taking an income hit to bill you at the end of the month. To take the hit again by allowing payment by credit card is not typical behavior for a company that does monthly billing, at least from any companies I've worked with.
The fact that Verizon allows it at all, let alone for free if you schedule it to be automatically paid, is a plus in my opinion. Since I already see the credit card payment option for a monthly bill as a plus, I don't see how charging a fee that will only recover part of their costs in comparison to bank transfers is unreasonable. It is perhaps less awesome than it was, but I still think the balance is in the consumer's favor.
Apparently I should have RTFA before replying to comments. It appears the summary is misleading (shocker, I know). This fee ONLY applies to credit card payments made over the phone or through the internet and ONLY to non-automatic online payments. In that case, yeah, it is simply a cost recovery for credit card processing fees and I see no problem with it what-so-ever. Hell, when I pay my bill with Verizon with my credit card, I personally get more than $2 back on it and I pay automatically each month anyway, so I'm not even effected by the decision. I've always thought it was unfair in my favor that they accept credit card for monthly billing, but hey, if they want to offer, who am I to turn them down?
So only accept bank transfers that don't have the same fees. ACH works great for this and is far cheaper than printing and postage.
Sounds like you have a bad IT department. I'm glad that the IT department at my office is great to work with (from my perspective as a developer). I know most of business still thinks that IT uses a magic wand to make things work though and has little or no interest in wanting to know more. They actually seem to tend to work more directly with the software development side of the house to move things in to place and then development works with IT on the server side. Obviously client issues still go direct to IT though, but those are normally minor issues.
Thanks for that great write up. That made a lot of sense and kind of confirmed what my initial guess was. (That a lot of the issues early on were probably related to poor compiler behavior (or perhaps poor instruction choice), since the instructions were not getting well used.) It also gave a lot of accessible insights from a software developer's perspective. I'd agree that Intel would have to get their fab costs down to compete with ARM plus I get the feeling a lot of the manufacturers like being able to make their own die to add features as necessary. That's always going to give a power advantage I'd think if you can put more on the die.
It will be interesting to see what happens in the server and desktop market, but for the moment, I think that Intel will keep a hold there due to how entrenched x86 is. (People simply won't want to have to get new software.) The one thing that could change that is if the ARM based Windows 8 takes off, but I personally have my doubts about tablet style computing supplanting the traditional desktop, but rather see it emerging as a parallel branch where ARM will dominate.
Perhaps you could explain this since you seem to be one of the most level headed posters. I work on the software side of the IT house with a fair bit of knowledge in to the electron pushing side, but only in so far as it is necessary for software development, but I've never understood the RISC is better argument. From a purely software implementation standpoint, I've almost universally ended up with significantly faster execution on x86 (and particularly x64) than with anything ARM based, even at similar clock frequencies.
From a developer's mindset, it seems like this should be the case too since a CISC gives you more optimized targets to hit for assembly calls provided your compiler and software design are optimized to be able to use them. The obvious primary concern would simply be price and if the added complexity resulted in a slower number of effective operations per second, but that hasn't seemed to be that significant, at least as long as I've been in that level of the game. (Again, talking purely from a software developer's viewpoint.)
My recommendation is the same as Benaiah's, work at the level you want to be paid for, not the level you are being paid for. If the company doesn't respond in turn and offer you better pay, then you did your best effort and find a new job using your experience as a resume builder. Thus far it has gotten me to a well paid Senior Developer by the time I was 25.
This is truly paranoid. A couple years back the document of TSA procedures was accidentally leaked on to the internet by the TSA themselves (some idiot thought that putting boxes in Acrobat over classified text would prevent someone from being able to read it). They only take note if they find you are actually doing something you shouldn't. As long as the more invasive screening doesn't find anything, there is no reason for them to take note, nor did they at the time of the leak. Now, if you were to have actually had say a knife in your bag that they had to have you check, then you might end up on some list of note, but I still wouldn't worry about it too much since it would just be to look if there was a pattern of things getting left in your bag.
While I can see that you are clearly very upset about a situation that occurred to you personally, you are also being quite paranoid. Yes, sometime extra screening may be necessary at the airport, but that is why they say you should get there early. I too have been pulled aside for additional screening in the past (prior to the body scanners) and found the entire process to be quite acceptable. I'm not sure why people would look at you accusingly on the plane or in the concourse since they wouldn't have any idea about what happened at the checkpoint.
What I can agree with you on is that there have been a number of situations where the screeners did not behave as well as they could have for doing the screening. It should be made very clear to the individual why they are getting taken aside and every effort should be made to make the process go quickly and comfortably. Thankfully, my local airport has TSA agents that are very good about this, but some of the larger airports seem to have more issues with bad TSA agents.
The process shouldn't make people feel uncomfortable and good communication should allow it to not be uncomfortable. As for the inconvenience, that is part of life. The point of a filtered security process is actually to increase convenience rather than make things less convenient. If it wasn't for the chemical sniffers, to get the same level of real, meaningful security, they would have to put every single passenger through what you went through. This would be incredibly inconvenient. You were certainly unlucky to have failed the test and had to go through it, but that's what happened. You don't have to be a chemist to fail the test or come in to contact with the chemicals either. Working in the yard (ammonium nitrate in fertilizer, cleaning the house (bleach and ammonia) and any number of other mundane activities can result in trace amounts of the chemicals on your person.
Security is always going to be somewhat invasive if the non-invasive checks reveal that there may be a problem. There isn't any way around that. My entire point is that subjecting everyone to invasive checks doesn't give any measurable advantage over using the non-invasive checks and only screening further when the non-invasive process can't show there is no issue.
Now I'll assume you are trolling me since you keep trying to put words in my mouth. I never suggested that guns should be used against any current government and I never said there wasn't corruption. What I did say is that the more reason a government has to fear its people, the less likely it is to go as far with the corruption. Power simply comes down to what people think they can get away with. Voting gives no more power than those with power allow it to have. The foundation of democracy is that the people, as a society hold that power and allow the government to rule by voting to allow it. If the people give up that power then votes can and will eventually beome meaningless.
This is the system working as intended. You don't show up in any database now, just like you don't show up in some DB for setting off the metal detector with a coin in your pocket. The entire point of security screening is to quickly determine reliable indicators that there MAY be a problem and do further screening when they say their might be an issue. If your CPAP machiene set it off, you likely had some chemical that could be a component of an explosive on it. There are many chemicals that can do this legitimately, but the majority of people and devices wouldn't have a detectable amount on them, but it would have a good chance of detecting someone who was actually handling the chemicals recently as well.
The process is the exact same if you set off the metal detector, though they normally do give you one chance to remove things from your pockets to see if it still reads. This doesn't apply to chemical sniffers as you can't take off whatever made it detect the chemical. What happened to you is the way security is supposed to work. Allow the bulk to pass nearly freely and only perform additional screening when a top level is failed. That is exactly what happened.