Yea! And if your kid is born with a hair-lip, don't you dare mutilate that poor child by making him look like everyone else!
Childhood cancer? Too fuckin' bad, chief, we ain't torturing your kid by cutting out that perfectly natural tumor!
Ordinarily, males are born with a foreskin, so it is entirely unlike a hair-lip (indeed it would be more like a hair lip to be born without a foreskin). The increased risk of illness as a result of having one is clearly marginal, which is unlike the childhood cancer. However, you have produced two great examples of why analogy often fails as a reasoning tool.
Jumpin' Jesus on a pogo-stick, the ignorant shit some people expound...
Are you saying that email sent via the Android GMail app isn't encrypted between the device and Google's servers?
No, I'm not saying that GMail for Android (or via a browser, or iPhone) doesn't use SSL. However, GMail is an e-mail service using a client (on Android) which doesn't have support for encryption apart from SSL to the server. Sure, if I'm sending GMail to GMail that's fine - it falls into the same boat as MSN Messenger. If I'm sending to a non-GMail recipient, then that goes out the window.
There are other apps which can use GMail, and do provide encryption functionality, but as with TextSecure - how common is their use (with encryption)?
And it is probably also worth pointing out that this means that RIM's BIS service provides better content protection than SMS/MMS, unencrypted email (which is virtually all e-mail, and indeed all Android phones using the inbuilt GMail app), and almost any IM out there. I've also missed other equally unprotected means of communication.
Why? Because at least BIS is encrypted in transit to and from RIM. (To be fair, services like MSN Messenger in which all messages go through a central server could be considered more secure than BIS communications, as long as both clients are connecting to the server via SSL). Hell, even BB PIN-to-PIN messaging is more secure than many or most of the aforementioned modes of communication.Yes, the key used for encryption is present on each and every handset - but random MITM sniffer can't get the content without at least having to decrypt it.
Sure, an Android user could get TextSecure for encrypted SMS, but does anyone actually know anyone who USES this tool?
Don't forget that he can appeal the decision. The Home Secretary can agree to whatever she wants, but the courts are not necessarily going to agree. It isn't like the courts and the government always agree on issues regarding rights and security (e.g. regarding a writ of habeas corpus in the UK: http://www.nytimes.com/2012/02/13/opinion/prisoners-are-not-pawns.html). Mind you, the courts don't have impunity - they are bound by the law, so who knows how that will fall out.
Regardless of whether the venue pays or the D.J. plays, the point remains valid. The D.J. has already paid for a license to the music in purchasing the original media, and *someone* is paying for the right to have the music played publicly.
So what you are saying is that it is a security risk that all users of the computer need to be able to decrypt the system partition?
If the user doesn't have the password for the system partition, they can not boot the system at all. That isn't a security risk.
If the complaint is that when the system is running the drive is decrypted, then I think you misunderstand disk encryption. I mean, for a non-system partition it would be nice to be able to limit which processes can access the partition, but for a system partition that is likely a bit problematic. That, and multiple users on the same system logged on simultaneously will be sharing a kernel anyway, so longing to specific processes wouldn't help.
Fundamentally, what it comes down to is this: Yes, when the partition is mounted it gets decrypted as required by anyone who has access to the partition.
This entire comment is absurd - it makes so many assumptions it ceases to be relevant.
Let us assume that, for the sake of argument, he was not acting suspiciously and the ID check was based on race, a personal dislike of the checker to the checkee, or was entirely random. For whatever reason, the man did not want to leave, and the campus police for one reason or another were unable to get him to leave so contacted the UCPD. For whatever reason, the did not want to present any ID he may have had and was not entirely compliant. etc.
If you make enough assumptions, you can suppose any situation you want, but in this case the assumptions have no basis in fact.
Re:What's been the problem with encrypted voice?
on
PGP Is 15 Years Old
·
· Score: 2, Informative
Yes, yes there are.
Twinkle (Linux) supports both SRTP and ZRTP. Minisip and Minisplat (both Linux) presently support SRTP and are working toward ZRTP support. Eyebeam (Windows) supports SRTP ZFone (Windows, Linux, MacOSX) uses ZRTP and can work with any SIP-based software (because it intercepts and encrypts the stream). OpenWengo (Windows, Linux) is in the process of implementing SRTP, with some automated key exchange, and later ZRTP is planned.
So really, the answer is: yes, yes there are implementations.
There is still a margin of error. A stray electron may have tunnelled into the machine at just the right moment to drop that vote. That said, I'm guessing that is not a large margin of error. Certainly not enough to expect incorrect addition of a single vote across the whole damn U.S. election. Margin of error. Bah. Margins of error are for statistical analysis or empirical instrumentation... or other things I can't think of right now that are not electronically-tallied ballots.
If it is anything other than a randomly occurring hardware failure that could not be predicted or accounted for, then it is the system and therefore is systemic, right?
Whether it changes the outcome is entirely irrelevant. For people to be able to trust a voting system it must be beyond reproach, be it electronic or otherwise. How does one ensure that the electronic voting machines are in fact doing their job correctly? If you assume errors will occur consistently, it is essential that a randomly selected set of machines be opened and their internal tally be compared to the printed paper record. If this does not match, then all machines need to be opened and have the internal tally checked. Of course, anyone who has worked in software development will know that while errors may be consistent, they can be triggered by an obscure sequence of events - there may be an error only every 104th time, or only every 104th time if the previous vote was for X if a buffer is not cleared properly, or if someone presses a touch-screen in too rapid succession, or any of the other many possibilities.
Without an transparent testing regime, carried out by an independent organisation according to strict rules, the validity of the recorded votes must inevitable come into question.
Furthermore, random selection and count-checking of some machines will not necessarily turn up deliberate vandalism against particular machines. While it is possible that a random selection of machines may include such a modified machine, especially if the attack is widespread enough to have a significant impact, it does increase the risk of the problem being missed.
Frankly, I believe that the only real way to have safe, reliable electronic voting systems which may be trusted is through having a well organised, multiple independent source-code and hardware review, multiple independent black-box testing, and scanning of physically marked ballots that may be kept for validation counts and that do not rely on the machine printing correctly what has been entered. In that case, source code review should find problems, black-box testing should verify the absence of problems, and a random sample comparison of original hand-marked ballots to machine records can validate that the machines are correctly recording votes and permit a guaranteed-correct fallback paper vote if the machines prove to be untrustworthy.
I'm sure that will happen eventually; maybe right after world peace.
In the Simpsons, Mr. Burns built a giant sunshade to block the free source of energy that is the sun. In Futurama, a giant mirror is launched into space to block the rays of the sun, and reduce global warming. A small meteor hits it, causing it to turn, focus the light on the surface of the Earth, and cut a swathe through the arena from which the scientists (and Nixon's head) look on.
That's fine and all, but your 'secure chat' uses symmetric rather than asymmetric encryption (which relies on a pre-shared key), doesn't hide the endpoints of the conversation, and provides no authentication of the other user, or any of the array of features that this tool has. Your implementation is a nice curiosity, but in the context being discussed, I don't think it is any more than that.
You make a valid point - encryption != digital signature.
When the system is initially setting up encryption, the public key for the user's signing key is sent. Unless the signature keys are single-use, this reveals the user's identity. Sure, the session key protects the conversation itself, but it reveals with certainty who is involved in the conversation. Furthermore, should the conversation encryption be broken, there is no deniability.
This strikes me as a little odd, as the use of Tor in this context seems somewhat redundant given that public/private keypairs are being used for the communication, meaning that a the participants can be easily identified in a conversation as being user A and user B. That said, the use of Tor may make it more difficult to track that back to Person A and Person B.
The problem is that because the key pairs are persistant, a user need only connect without Tor once, and suddenly it is possible to identify the person demonstratably responsible for a potentially large number of conversations. As another person here has mentioned, OTR would have probably been a better choice due to the deniability aspect. In conjuction with Tor, this would mean that tracking (and proving) a conversation is connected to a person would be more difficult. The exception may be if users had already exchanged public keys, in which case the ability to use those public keys may be conventient. Of course, those keys can still be taken advantage of in the first-step verification of the user for OTR communication.
It seems like a good idea, just the choice of method of encrypted communication of messages seems a strange.
As has been (loosely) pointed out, despite the AOL/ICQ and YIM/MSN network linking, Google Talk/Jabber/Gizmo do it in a much more socially acceptable way.
Google Talk, Gizmo, and Jabber all communicate using the conveniently open XMPP protocol (yes, like ATM machine, I know). This means new networks can connect to Google Talk (and the others I believe) without having to go through the absurd process of forging inter-company relationships and the like. It also means that new networks that appear using XMPP can easily join the existing networks.
To those who claim that Google Talk is little used - I agree to some extent. MSN and remarkably enough YIM have, since the near-demise of AIM and ICQ, enjoyed significant market dominance. Since the appearance of Google Talk, I have observed many users (including my own father; hardly a technical fiend) transitioning to Gmail and Google Talk, in part because of the simple web interface. I doubt (with no evidence at all) that the actual Google Talk client is seeing wild success, but I think that many users of Gmail and probably an even greater proportion of GAIM users are connecting to the Google Talk network. Of course, these days you don't have to - you can connect to Gizmo or Jabber and communicate with Google Talk users.
Try using PortableGaim. I believe it has its own GTK DLLs, so it can use a different GTK version to the rest of the software on your system. In my case, I was using GTK 2.8.something so I could use recent GIMP builds, and running Gaim Beta 2 (portable) quite happily.
Failing that, or if you are in the mood for some pain, install the latest gaim beta normally, install GTK 2.6, copy the GTK 2.6 DLLs into the same directory as gaim, copy the locale and other subfolders into that directory also. Run gaim and voila! either it will work (which it did for me) or go down in flames (in which case you might need to jiggle DLLs around a bit more to check all are in the correct directories etc).
Basically, this works because (to my knowledge) Windows will use DLLs from an executed program's own directory before using the registered ones. It is worth remembering for when you hit those various DLL incompatibilities (MFC anyone?).
Zfone, like Off-the-Record Messaging, doesn't use a pre-shared key to prevent man-in-the-middle attacks. Rather, it uses a code (conceptually similar to a key fingerprint) which each person reads for the key they have from the other person, to the other person. By ensuring this code matches what is expected, and observing that the voice is not being artificially replaced between the two people.
As long as those codes are correct, the call is secure.
The second part is that a bit of information is kept from each call, and used in an authentication process in the next call. Because both systems will know this information (if they are the same systems), authentication can occur without either person needing to deal with it directly. If the systems for the second coll are not the same as for the first, the code-reading process must occur again.
As another has pointed out, there are a number of exemptions:
Eg. Schedule 1, Object, Note 2: Designated commercial electronic messages are exempt from section 16 (unsolicited commercial electronic messages must not be sent) and section 18 (commercial electronic messages must contain a functional unsubscribe facility).
Those 'designated commercial electronic messages' include:
Government bodies, political parties, religious organisations and charities (a) the sending of the message is authorised by any of the following bodies:
(i) a government body;
(ii) a registered political party;
(iii) a religious organisation;
(iv) a charity or charitable institution; and
(b) the message relates to goods or services; and
(c) the body is the supplier, or prospective supplier, of the goods or services concerned. Educational institutions
(a) the sending of the message is authorised by an educational institution; and
(b) either or both of the following subparagraphs applies:
(i) the relevant electronic accountholder is, or has been, enrolled as a student in that institution;
(ii) a member or former member of the household of the relevant electronic accountholder is, or has been, enrolled as a student in that institution; and
(c) the message relates to goods or services; and
(d) the institution is the supplier, or prospective supplier, of the goods or services concerned Factual information (a) the message consists of no more than factual information (with or without directlyrelated comment) and any or all of the following additional information:
(i) the name, logo and contact details of the individual or organisation who authorised the sending of the message;
(ii) the name and contact details of the author;
(iii) if the author is an employee--the name, logo and contact details of the author's employer;
(iv) if the author is a partner in a partnership--the name, logo and contact details of the partnership;
(v) if the author is a director or officer of an organisation--the name, logo and contact details of the organisation;
(vi) if the message is sponsored--the name, logo and contact details of the sponsor;
(vii) information required to be included by section 17;
(viii) information that would have been required to be included by section 18 if that section had applied to the message; and
(b) assuming that none of that additional information had been included in the message, the message would not have been a commercial electronic message; and
(c) the message complies with such other condition or conditions (if any) as are specified in the regulations.
After all that, I don't really see how it will help one bit.
To my interpretation (wrong though it may be) we can still get spam but we have to know who it is coming from, and if it is from a business (for profit) it may not be more than a business card.
On the other hand, from a govt body, political party, religious crazies (or otherwise), and charities, you den't even need to be able to unsubscribe. It must relate to goods or services (uh huh... big protection there. The catalogues in my mailbox do that too) and they must be the prospective supplier. That's what they are hoping, anyway.
Also, a uni, or school, may cheerfully spam all their students. What fun.
All seems to be a waste of time to me.
As for Alston... if anyone sees him, punch him in the face for me, or somesuch.
Ahh.. kinda OT but your numbers are wrong. CDs are 1.4112Mb/s Most mp3s are 96Kb/s - 192Kb/s Just being a pedantic bastard
Piracy is illegal (excluding real fair use) no matter how much the media companies are screwing you. Not to say you shouldn't do it, just that eventually you need to bite the bullet, accept it is against the law, and decide you don't care. Though I know you weren't disputing the illegality of it.
Of course, in this case I can understand the guy's frustration - getting distribution must be very difficult when you are getting problems like this because of a giant media conglomerate... especially given that they are your competition. Maybe thinking about it in the 'competition' way it all makes a lot more sense... hmm.
Slashdot Mirror
Yea! And if your kid is born with a hair-lip, don't you dare mutilate that poor child by making him look like everyone else!
Childhood cancer? Too fuckin' bad, chief, we ain't torturing your kid by cutting out that perfectly natural tumor!
Ordinarily, males are born with a foreskin, so it is entirely unlike a hair-lip (indeed it would be more like a hair lip to be born without a foreskin). The increased risk of illness as a result of having one is clearly marginal, which is unlike the childhood cancer. However, you have produced two great examples of why analogy often fails as a reasoning tool.
Jumpin' Jesus on a pogo-stick, the ignorant shit some people expound...
Some people being you in this instance.
Are you saying that email sent via the Android GMail app isn't encrypted between the device and Google's servers?
No, I'm not saying that GMail for Android (or via a browser, or iPhone) doesn't use SSL. However, GMail is an e-mail service using a client (on Android) which doesn't have support for encryption apart from SSL to the server. Sure, if I'm sending GMail to GMail that's fine - it falls into the same boat as MSN Messenger. If I'm sending to a non-GMail recipient, then that goes out the window.
There are other apps which can use GMail, and do provide encryption functionality, but as with TextSecure - how common is their use (with encryption)?
And it is probably also worth pointing out that this means that RIM's BIS service provides better content protection than SMS/MMS, unencrypted email (which is virtually all e-mail, and indeed all Android phones using the inbuilt GMail app), and almost any IM out there. I've also missed other equally unprotected means of communication.
Why? Because at least BIS is encrypted in transit to and from RIM. (To be fair, services like MSN Messenger in which all messages go through a central server could be considered more secure than BIS communications, as long as both clients are connecting to the server via SSL).
Hell, even BB PIN-to-PIN messaging is more secure than many or most of the aforementioned modes of communication.Yes, the key used for encryption is present on each and every handset - but random MITM sniffer can't get the content without at least having to decrypt it.
Sure, an Android user could get TextSecure for encrypted SMS, but does anyone actually know anyone who USES this tool?
Of course, if you are not on BES, then your phone uses exactly the same encryption key as every other Blackberry.
At least you don't need to worry about a MITM attack, right?
Don't forget that he can appeal the decision. The Home Secretary can agree to whatever she wants, but the courts are not necessarily going to agree. It isn't like the courts and the government always agree on issues regarding rights and security (e.g. regarding a writ of habeas corpus in the UK: http://www.nytimes.com/2012/02/13/opinion/prisoners-are-not-pawns.html). Mind you, the courts don't have impunity - they are bound by the law, so who knows how that will fall out.
Oh, and the obligatory IANAL.
I guess maybe the inquisition could have produced selective pressure to evolve brain areas associated with religion. Right?
Regardless of whether the venue pays or the D.J. plays, the point remains valid. The D.J. has already paid for a license to the music in purchasing the original media, and *someone* is paying for the right to have the music played publicly.
So what you are saying is that it is a security risk that all users of the computer need to be able to decrypt the system partition?
If the user doesn't have the password for the system partition, they can not boot the system at all. That isn't a security risk.
If the complaint is that when the system is running the drive is decrypted, then I think you misunderstand disk encryption. I mean, for a non-system partition it would be nice to be able to limit which processes can access the partition, but for a system partition that is likely a bit problematic. That, and multiple users on the same system logged on simultaneously will be sharing a kernel anyway, so longing to specific processes wouldn't help.
Fundamentally, what it comes down to is this: Yes, when the partition is mounted it gets decrypted as required by anyone who has access to the partition.
This entire comment is absurd - it makes so many assumptions it ceases to be relevant.
Let us assume that, for the sake of argument, he was not acting suspiciously and the ID check was based on race, a personal dislike of the checker to the checkee, or was entirely random.
For whatever reason, the man did not want to leave, and the campus police for one reason or another were unable to get him to leave so contacted the UCPD. For whatever reason, the did not want to present any ID he may have had and was not entirely compliant.
etc.
If you make enough assumptions, you can suppose any situation you want, but in this case the assumptions have no basis in fact.
Yes, yes there are.
Twinkle (Linux) supports both SRTP and ZRTP.
Minisip and Minisplat (both Linux) presently support SRTP and are working toward ZRTP support.
Eyebeam (Windows) supports SRTP
ZFone (Windows, Linux, MacOSX) uses ZRTP and can work with any SIP-based software (because it intercepts and encrypts the stream).
OpenWengo (Windows, Linux) is in the process of implementing SRTP, with some automated key exchange, and later ZRTP is planned.
So really, the answer is: yes, yes there are implementations.
There is still a margin of error. A stray electron may have tunnelled into the machine at just the right moment to drop that vote. That said, I'm guessing that is not a large margin of error. Certainly not enough to expect incorrect addition of a single vote across the whole damn U.S. election.
Margin of error. Bah. Margins of error are for statistical analysis or empirical instrumentation... or other things I can't think of right now that are not electronically-tallied ballots.
If it is anything other than a randomly occurring hardware failure that could not be predicted or accounted for, then it is the system and therefore is systemic, right?
Whether it changes the outcome is entirely irrelevant. For people to be able to trust a voting system it must be beyond reproach, be it electronic or otherwise. How does one ensure that the electronic voting machines are in fact doing their job correctly? If you assume errors will occur consistently, it is essential that a randomly selected set of machines be opened and their internal tally be compared to the printed paper record. If this does not match, then all machines need to be opened and have the internal tally checked.
Of course, anyone who has worked in software development will know that while errors may be consistent, they can be triggered by an obscure sequence of events - there may be an error only every 104th time, or only every 104th time if the previous vote was for X if a buffer is not cleared properly, or if someone presses a touch-screen in too rapid succession, or any of the other many possibilities.
Without an transparent testing regime, carried out by an independent organisation according to strict rules, the validity of the recorded votes must inevitable come into question.
Furthermore, random selection and count-checking of some machines will not necessarily turn up deliberate vandalism against particular machines. While it is possible that a random selection of machines may include such a modified machine, especially if the attack is widespread enough to have a significant impact, it does increase the risk of the problem being missed.
Frankly, I believe that the only real way to have safe, reliable electronic voting systems which may be trusted is through having a well organised, multiple independent source-code and hardware review, multiple independent black-box testing, and scanning of physically marked ballots that may be kept for validation counts and that do not rely on the machine printing correctly what has been entered. In that case, source code review should find problems, black-box testing should verify the absence of problems, and a random sample comparison of original hand-marked ballots to machine records can validate that the machines are correctly recording votes and permit a guaranteed-correct fallback paper vote if the machines prove to be untrustworthy.
I'm sure that will happen eventually; maybe right after world peace.
In the Simpsons, Mr. Burns built a giant sunshade to block the free source of energy that is the sun.
In Futurama, a giant mirror is launched into space to block the rays of the sun, and reduce global warming. A small meteor hits it, causing it to turn, focus the light on the surface of the Earth, and cut a swathe through the arena from which the scientists (and Nixon's head) look on.
That's fine and all, but your 'secure chat' uses symmetric rather than asymmetric encryption (which relies on a pre-shared key), doesn't hide the endpoints of the conversation, and provides no authentication of the other user, or any of the array of features that this tool has. Your implementation is a nice curiosity, but in the context being discussed, I don't think it is any more than that.
You make a valid point - encryption != digital signature.
x t
When the system is initially setting up encryption, the public key for the user's signing key is sent.
Unless the signature keys are single-use, this reveals the user's identity. Sure, the session key protects the conversation itself, but it reveals with certainty who is involved in the conversation. Furthermore, should the conversation encryption be broken, there is no deniability.
That is my understanding based on: http://www.scatterchat.com/docs/crypto_protocol.t
This strikes me as a little odd, as the use of Tor in this context seems somewhat redundant given that public/private keypairs are being used for the communication, meaning that a the participants can be easily identified in a conversation as being user A and user B. That said, the use of Tor may make it more difficult to track that back to Person A and Person B.
The problem is that because the key pairs are persistant, a user need only connect without Tor once, and suddenly it is possible to identify the person demonstratably responsible for a potentially large number of conversations.
As another person here has mentioned, OTR would have probably been a better choice due to the deniability aspect. In conjuction with Tor, this would mean that tracking (and proving) a conversation is connected to a person would be more difficult. The exception may be if users had already exchanged public keys, in which case the ability to use those public keys may be conventient. Of course, those keys can still be taken advantage of in the first-step verification of the user for OTR communication.
It seems like a good idea, just the choice of method of encrypted communication of messages seems a strange.
As has been (loosely) pointed out, despite the AOL/ICQ and YIM/MSN network linking, Google Talk/Jabber/Gizmo do it in a much more socially acceptable way.
Google Talk, Gizmo, and Jabber all communicate using the conveniently open XMPP protocol (yes, like ATM machine, I know).
This means new networks can connect to Google Talk (and the others I believe) without having to go through the absurd process of forging inter-company relationships and the like. It also means that new networks that appear using XMPP can easily join the existing networks.
To those who claim that Google Talk is little used - I agree to some extent. MSN and remarkably enough YIM have, since the near-demise of AIM and ICQ, enjoyed significant market dominance. Since the appearance of Google Talk, I have observed many users (including my own father; hardly a technical fiend) transitioning to Gmail and Google Talk, in part because of the simple web interface. I doubt (with no evidence at all) that the actual Google Talk client is seeing wild success, but I think that many users of Gmail and probably an even greater proportion of GAIM users are connecting to the Google Talk network. Of course, these days you don't have to - you can connect to Gizmo or Jabber and communicate with Google Talk users.
Ahh, the sweet flexibility.
Try using PortableGaim. I believe it has its own GTK DLLs, so it can use a different GTK version to the rest of the software on your system.
In my case, I was using GTK 2.8.something so I could use recent GIMP builds, and running Gaim Beta 2 (portable) quite happily.
Failing that, or if you are in the mood for some pain, install the latest gaim beta normally, install GTK 2.6, copy the GTK 2.6 DLLs into the same directory as gaim, copy the locale and other subfolders into that directory also.
Run gaim and voila! either it will work (which it did for me) or go down in flames (in which case you might need to jiggle DLLs around a bit more to check all are in the correct directories etc).
Basically, this works because (to my knowledge) Windows will use DLLs from an executed program's own directory before using the registered ones. It is worth remembering for when you hit those various DLL incompatibilities (MFC anyone?).
Zfone, like Off-the-Record Messaging, doesn't use a pre-shared key to prevent man-in-the-middle attacks. Rather, it uses a code (conceptually similar to a key fingerprint) which each person reads for the key they have from the other person, to the other person. By ensuring this code matches what is expected, and observing that the voice is not being artificially replaced between the two people.
h tmlt ml (not the same, but very similar)e cya nn-avt-zrtp-01.txt
As long as those codes are correct, the call is secure.
The second part is that a bit of information is kept from each call, and used in an authentication process in the next call. Because both systems will know this information (if they are the same systems), authentication can occur without either person needing to deal with it directly. If the systems for the second coll are not the same as for the first, the code-reading process must occur again.
There is more to it than that, but that's the quick dirty summary.
For more details, try:
http://www.philzimmermann.com/EN/zfone/index-faq.
http://www.cypherpunks.ca/otr/Protocol-v2-3.0.0.h
http://en.wikipedia.org/wiki/Perfect_forward_secr
http://www.ietf.org/internet-drafts/draft-zimmerm
Hate to be rude, but I didn't think DMCA had anything to do with patents, and everything to do with copyrights.
hence Digital Millenium Copyright Act.
Anti-circumvention is in the WIPO Copyright treaty.
If that is your gripe, how did you feel about the content laws for things being hosted in Australia (being managed by the ABA).
Not to mention Using internet for offensive and menacing purposes to be outlawed (and EFA's response).
It will take a lot more than this (and even this I am not convinced is a + rather than a -) to make me have any respect for Alston and his cronies.
As another has pointed out, there are a number of exemptions:
Eg. Schedule 1, Object, Note 2:
Designated commercial electronic messages are exempt from section 16 (unsolicited commercial electronic messages must not be sent) and section 18 (commercial electronic messages must contain a functional unsubscribe facility).
Those 'designated commercial electronic messages' include:
Government bodies, political parties, religious organisations and charities
(a) the sending of the message is authorised by any of the following bodies:
(i) a government body;
(ii) a registered political party;
(iii) a religious organisation;
(iv) a charity or charitable institution; and
(b) the message relates to goods or services; and
(c) the body is the supplier, or prospective supplier, of the goods or services concerned.
Educational institutions
(a) the sending of the message is authorised by an educational institution; and
(b) either or both of the following subparagraphs applies:
(i) the relevant electronic accountholder is, or has been, enrolled as a student in that institution;
(ii) a member or former member of the household of the relevant electronic accountholder is, or has been, enrolled as a student in that institution; and
(c) the message relates to goods or services; and
(d) the institution is the supplier, or prospective supplier, of the goods or services concerned
Factual information
(a) the message consists of no more than factual information (with or without directlyrelated comment) and any or all of the following additional information:
(i) the name, logo and contact details of the individual or organisation who authorised the sending of the message;
(ii) the name and contact details of the author;
(iii) if the author is an employee--the name, logo and contact details of the author's employer;
(iv) if the author is a partner in a partnership--the name, logo and contact details of the partnership;
(v) if the author is a director or officer of an organisation--the name, logo and contact details of the organisation;
(vi) if the message is sponsored--the name, logo and contact details of the sponsor;
(vii) information required to be included by section 17;
(viii) information that would have been required to be included by section 18 if that section had applied to the message; and
(b) assuming that none of that additional information had been included in the message, the message would not have been a commercial electronic message; and
(c) the message complies with such other condition or conditions (if any) as are specified in the regulations.
After all that, I don't really see how it will help one bit. To my interpretation (wrong though it may be) we can still get spam but we have to know who it is coming from, and if it is from a business (for profit) it may not be more than a business card. On the other hand, from a govt body, political party, religious crazies (or otherwise), and charities, you den't even need to be able to unsubscribe. It must relate to goods or services (uh huh... big protection there. The catalogues in my mailbox do that too) and they must be the prospective supplier. That's what they are hoping, anyway.
Also, a uni, or school, may cheerfully spam all their students. What fun.
All seems to be a waste of time to me.
As for Alston... if anyone sees him, punch him in the face for me, or somesuch.
Ahh.. kinda OT but your numbers are wrong.
CDs are 1.4112Mb/s
Most mp3s are 96Kb/s - 192Kb/s
Just being a pedantic bastard
Piracy is illegal (excluding real fair use) no matter how much the media companies are screwing you. Not to say you shouldn't do it, just that eventually you need to bite the bullet, accept it is against the law, and decide you don't care.
Though I know you weren't disputing the illegality of it.
Of course, in this case I can understand the guy's frustration - getting distribution must be very difficult when you are getting problems like this because of a giant media conglomerate... especially given that they are your competition.
Maybe thinking about it in the 'competition' way it all makes a lot more sense... hmm.
gnoshi
Quick point of note: FLAC has been around for a couple of years - it is far from new.
Perhaps the appropriate approach is to not only argue against the new levy, but also use this as an opportunity to push for better 'fair use' law.
If you can dodge the slap in the face, you may be able to swing back with the iron bar.
gnoshi