If you're running SSH open to the world you SHOULD be forcing keys not passwords. It only takes one user with a poor password to allow an attacker access to try a local admin exploit or use you as a 'bounce server'.
RDP cannot be put into a key/certificate only mode.
Add to that Microsoft's past performance with security applications (eg pptp) and I have always strongly recommended that RDP be only used within some sort of secure pipe (VPN, ssh!!, zebedee etc). or at the very least moved off the default port and given an IP address filter.
It seems I was right.
As for SSH, despite random number 'issues' I believe overall that it is still more trustworthy and the only protection I think it needs is to have a rate limiter so that the "skiddies" trying passwords go off and bother someone else.
Tell me about it, when I first came across MIME itself it was a real WTF moment!
I hated quoted printable on sight. HTML(SGML) entities are blissful in comparison (Though I think my favourite idea at the time was the 8bit T.61 character set) . Base64 was good, but hardly unique, XXEncode had been using a similar character encoding for a while.
But this was small change to the (IMO) real nasty, instead of just having the old RFC822 messages as a pure carrier they were trying to merge it into the standard. To tie it to RFC822 messages and, I've now realised, make it look like a smaller change. Of course the only part that highlighted was the 'MIME-Version' header which was an improvement on hunting the message for a 'xxbegin' header.
I would have left just a 'Content-Encapsulation' header (Like Content-Encoding but I've just renamed it 'cause it's a lot simpler) in the SMTP headers and put everything else in the body of the message, All this header would tell you is how to unwrap the body into a collection of parts; things like "SMTP", "base64", attached-base64-files, eightbit-metafile, etc etc. Just one token to describe the archive you'd have to look inside for the metadata attached to each file (including checksums of course).
They never did seem to realise that the separation of the container and the data contained INCLUDING it's metadata was actually important, so we have the current mess.
You know most people on usenet never actually switched to MIME, they used uuencode until it was replaced by 'yenc' (and that's another story)
Okay, I think the ISP should have some sort of penalty here, but, sorry, yes, the criminal courts aren't the right place. It may be reasonable for the ISP's paying customers to feel that they deserve a refund and perhaps they can sue for it in a civil court. I suppose that's how you see the ISP's insurance being likely to change.
"No reason to be trusted in the first place (being self signed)."
At first this struck me as wrong. Mostly because all CA certificates are self signed.
The I found a question, "why don't the CAs sign each other's certificates?"
It's possible, they just never do it.
Is it perhaps that they don't trust each other! If they don't trust each other why should we trust them ?
Oh okay, I obviously didn't go far enough up the thread.
But that does make me wonder why people would be so enamoured with this chip, a video controller that can't (it appears) share the memory with some other DMA/CPU etc chip and forces all accesses to it's memory to be made through a 'pin hole' of a couple of I/O ports really strikes me as a bit of a deal killer whatever other features it might have.
The vast majority of people throughout history died before the age of 25. We as a species would not have survived with such a serious mistake in our makeup.
The brain does continue to change, because at that age the human brain has more interconnectivity that at any other time. Most of those paths are never used and get reabsorbed. Somewhere after about 18 most of the paths that will be deleted are gone and many people basically stop learning.
So these 'mature' brains are ones that will never learn and will never discover anything new. That doesn't sound right, that's not 'mature' that's ossified.
Children have fully adult brain function at an average of age eight. The rest of childhood, as far as the brain is concerned, is learning stuff, beginning with the word "WHY"!
The only reason that a 17 year old makes a bad decision is lack of experience and lack of knowledge. In everything except sex (and in America alcohol) children are explicitly taught about "important things".
As for the word "Pedophilia" it's been redefined (like Moron, Idiot and Hacker) by the media to mean something like "a creepy picture of an older guy who's rumoured or 'proven' to have sex with a female of 18 or under". Yes according to the media having "legal sex" can be "Pedophilia", it's hardly surprising, after all you've just done it, the age of consent in most America states is 16.
Then we have the law, it's just made up of people, often they get things right, but ignorance, peer pressure and propaganda can make fools of anyone.
Actually, VDP RAM isn't memory mapped on any platform that I know of. But other systems have CPU-addressable memory that you could store a shadow copy of data in at least. The paltry 256 bytes on the TI-99/4A, though, are far from enough in many cases.
On the contrary, many 8-bits had memory mapped video. Commodore (VIC/64/Amiga), Sinclair (Spectrum, zx81, zx80, dist by Timex in the US) Atari, VT100... etc etc. Not that there weren't machines with distinct video RAM, the Commodore PET had specific video memory, though it was still mapped into the address space like a modern PC video card. Having the video RAM in a inaccessible (I/O bus) location was rare.
The reason was simple, at that point in time only a relatively small amount of RAM was needed for the machines and it ended up being faster than the CPU. So much so that you could assign 50% of the RAM bandwidth to the video subsystem without impacting the speed of the processor at all.
The ZX81, however, was a bit of a foreshadowing of things to come. It was built really, really, cheaply and they used really cheap DRAM. This cheap RAM wasn't fast enough to feed both the CPU and the video at the same time so the CPU was basically turned off when the video was being displayed (In fact it was physically used as a counter chip by the ultra cheap video controller).
Nowadays people want astronomical quantities of RAM so it basically has to be the cheapest design possible; this type of RAM can't keep up with just one CPU, let alone multiple CPUs and a video controller. So the video controller has to reduce the performance of the main CPUs by stealing cycles, or it gets it's own RAM.
Note: There are several Intel video controllers for PC clones that use main memory as the video RAM, they get added as a cheap motherboard video controller. Because of the fact that they're using slow RAM and stealing cycles from the CPU these are rightfully seen as very low performance.
On the other side, a common mistake for designs with distinct video RAM is that the CPU only ever needs to write to this RAM, unfortunately the problem is frequently only recognised in production.
I managed to resist in that message, but I still want to know why the slashdot programmers are happy looking like complete morons.
Will they ever get unamerican character sets working, or are they just bigots.
I've heard they think they have a problem with unicode control and composing characters, give me a break! A level 1 filter to filter everything that isn't a graphic LTR character is a couple of minutes work!!
Slashdot is advert supported (in part) the next line is what they are losing.
If you're afraid of losing it, burn it onto a DVD. That DVD you burned will outlast any VHS tape
Um, no. It's true if you play the disk/tape every day the VHS will wear out in less than 100 passes. But even if you leave them on the shelf the DVD±R will rot, it will get harder to play it will skip and judder until the day, very soon, that it's no longer seen as a DVD±R. The VHS will just sit there for decades.
Pressed silver DVDs do last longer, but repeated handling will eventually make them delaminate.
At this point in time I understand the best high capacity digital archive format is the DLT/LTO style tape cassette, it should reliably last at least 20 years on the shelf or 250 full passes whichever is sooner with no handling issues. Writeable DVDs usually die in less than five years.
If you want lots of playbacks, put it on the hard disk in your PVR.
heh, heh. I had to look up the guy's name, Dijkstra's algorithm is probably the worst algorithm you can use that will actually get the job done. It's a simple brute force breadth first search, no good programmer has to remember it. Like "bubble sort", "selection sort", "linear search" and a load of similar algorithms it's something that'll be reinvented when you run out of ideas.
Hell, it doesn't even have the simple optimisation of starting from both ends.
Don't be silly. Putting stuff under the GPL is the closest thing to abolishing copyright that you (as an individual) can do. It gives out your code in a public domain equivalent and makes sure that nobody can slap their own copyright onto it. It's been described as judo against the copyright system.
It is a reasonable position for the court to take, but I don't think it's completely correct.
The difference between this and your bank account is that this is an unregulated account directly controlled by a company that the victim has a direct contract with. A bank account is not controlled to the same extent; a bank cannot just increase the numbers in the account without decreasing another or getting into a lot of trouble.
It is reasonable for the court to take measures to get this transfer reverted or corrected. Whereas a bank transfer is likely to have been converted into physical cash and so be very difficult to reverse.
It all comes down to real world consequences. Does the victim have a reasonable chance of recovering the objects of value that were given to the attacker. If the objects had no value (eg: they can be recreated or recovered on demand) it becomes an attempted robbery or just threats/assault. If the objects have value, (eg: acquired through 'effort and time investment,') but the victim can obviously get the things back it's a really dumb attempted robbery. Only if the attacker takes something of value away is it a robbery.
So in this case we have a foreign company in an industry that's notoriously unresponsive, so yes it looks like something of value that they couldn't get back and I too think a full robbery charge may well be justified in this case. But definitely not in general.
Well, yes, I am leaving out assumptions. The biggy is probably that I'd be assuming both traffic and errors come in bursts. If they're continuous people would be complaining about slow performance and it would normally get fixed. But a bursty one would get the "looks okay to me" response every time. The 16bit checksum can't survive that, the 32bit CRC will (yup, no problem, definitely... okay, probably) hold the data together long enough for the complaints to mount.
Though, I'd never suggest using a 48/64 bit CRC, if I decide that 32bit isn't enough (say like I'm feeling now!) I'd definitely step up to a full cryptographical checksum. If nobody can break it on purpose it ain't gonna break by accident!
Yup, just like that one; I really wish it was always checked. But many cheap and nasty ethernet adaptors don't seem to bother because it's so difficult for an end user to actually confirm that they're good adaptors.
Also remember, a checksum at the OS level will cover a different set of bytes to those that the HW level so two CRCs really does get you most if not all of the extra protection the extra bits imply.
No definitely not. Debian do nothing wrong in respect of the GPL or other licenses. Unlike the FSF they don't write licenses and so it is in no respect hypocritical for them to class some licenses as incompatible with the project.
The license grant for the Firefox name and branding is incompatible with the methods of the Debian project. For Debian stable the application code is frozen before a release is declared stable, the only changes allowed are direct bug fixes and security fixes. The license for the Firefox branding requires that only unmodified code is used to build the executables so that the firefox developers are not chasing bugs in other people's code that they don't have.
Both of these stances are good and reasonable, but Debian will not accept 'the current build' of firefox into stable just to fix a minor bug and Mozilla will not allow a version with an unverified 'minor bug bug fix' to be branded 'Firefox'.
Incompatible
As for the name; neither Debian nor Mozilla care. The just want something that's not 'fire fox'; 'ice cat', 'ice dog', 'ice bear'... all have Google hits.
The SCTP checksum (same as zip IIRC) is mostly of use in a lan environment IMO. Across the internet you're very likely to either have an archive file which a good or even a cryptographical checksum or an encrypted connection with a message authentication code which is by definition a cryptographical checksum.
The TCP checksum is a bad joke. Not only is it small it's a bad example of a checksum so some estimates say that one in ten thousand errors will get through. This is really scary when you remember that a gigabit ethernet can transfer at least 80000 packets per second.
I have seen corruption due to lan errors that bypass the TCP checksums and I've had a serious corruption issue in one application that assumes the TCP channel is error free. Most applications tend to drop the connection or crash with protocol errors because they don't really trust the peer at the other end. OTOH a proper 32bit CRC is big enough to push the likelyhood of an undetected error from "may happen a few times a year" to "not in your, or your kids lifetime".
Both, just half size all over... interesting times.
It's like "poser movies", if the thing that's distributed is just a "text description" it cannot be illegal. But feed it into the machine and things change, except no one would ever know and so once again the law is an ass.
That's a really poor way of describing SCTP. Firstly the relationship between TCP and UDP is such that TCP could be built entirely ontop of UDP, the only reason it isn't physically is so that the port numbers for UDP and TCP are distinct. On the other side the best description of UDP is actually "Bare IP packets with port numbers".
SCTP is not that, it would probably be most accurate to describe it as being a protocol with multiple TCP streams in both directions within one connection. Because it's within a single connection a 'stream' can be very small (ie a little message) and still be efficient and because there are multiple streams messages don't have to wait for each other; though they can if you want. It is probably simpler that TCP, but only because TCP has had so much bolted on.
But you are absolutely correct, this would be a very good protocol for throwing a load of tiny requests at a web server and getting the results back as soon as they're ready. BUT, mixing it with SSL would not be very simple, I guess you'd have to do what OpenVPN does.
Thanks, seems like you have to add &tbs=li:1& to your URL to turn this verbatim thing on.
So now my "do what you're fucking told to" string is:
&safe=off&nfpr=1&tbs=li:1&
I've also more or less given up search from any google page because of this crap called "instant search", it's far too slow to keep up with my typing and usually buggers up and loses part of the string (especially when I try to go back and fix a typo)
Slashdot Mirror
If you're running SSH open to the world you SHOULD be forcing keys not passwords. It only takes one user with a poor password to allow an attacker access to try a local admin exploit or use you as a 'bounce server'.
RDP cannot be put into a key/certificate only mode.
Add to that Microsoft's past performance with security applications (eg pptp) and I have always strongly recommended that RDP be only used within some sort of secure pipe (VPN, ssh!!, zebedee etc). or at the very least moved off the default port and given an IP address filter.
It seems I was right.
As for SSH, despite random number 'issues' I believe overall that it is still more trustworthy and the only protection I think it needs is to have a rate limiter so that the "skiddies" trying passwords go off and bother someone else.
Tell me about it, when I first came across MIME itself it was a real WTF moment!
I hated quoted printable on sight. HTML(SGML) entities are blissful in comparison (Though I think my favourite idea at the time was the 8bit T.61 character set) . Base64 was good, but hardly unique, XXEncode had been using a similar character encoding for a while.
But this was small change to the (IMO) real nasty, instead of just having the old RFC822 messages as a pure carrier they were trying to merge it into the standard. To tie it to RFC822 messages and, I've now realised, make it look like a smaller change. Of course the only part that highlighted was the 'MIME-Version' header which was an improvement on hunting the message for a 'xxbegin' header.
I would have left just a 'Content-Encapsulation' header (Like Content-Encoding but I've just renamed it 'cause it's a lot simpler) in the SMTP headers and put everything else in the body of the message, All this header would tell you is how to unwrap the body into a collection of parts; things like "SMTP", "base64", attached-base64-files, eightbit-metafile, etc etc. Just one token to describe the archive you'd have to look inside for the metadata attached to each file (including checksums of course).
They never did seem to realise that the separation of the container and the data contained INCLUDING it's metadata was actually important, so we have the current mess.
You know most people on usenet never actually switched to MIME, they used uuencode until it was replaced by 'yenc' (and that's another story)
[[ Button pushed, venting complete! ]]
The only problem with this is what's you've done when you fuck up your server.
who? Oh? but the ISP isn't on trial.
Okay, I think the ISP should have some sort of penalty here, but, sorry, yes, the criminal courts aren't the right place. It may be reasonable for the ISP's paying customers to feel that they deserve a refund and perhaps they can sue for it in a civil court. I suppose that's how you see the ISP's insurance being likely to change.
I dunno about the exact rules for high security locks and so forth, but insurance companies will refuse to pay out if you left the door unlocked.
Plus if you've already been broken into they will not insure you unless you've increased the security since then.
So yes, most people will "get fined" even if they don't know it yet.
I'm company IT, I own that laptop I can make it do anything I want, I can install a boot rom that means I own any OS that's installed on the machine.
The laptop is for company use only, it's camera will be used to photograph everyone who uses the machine.
If you attempt to wipe the disk it will start up it's 3G chip and send a photo of you to the police.
Every keystroke you make will be recorded and sent to HR for analysis.
All photos will be archived for later perusal.
All attached USB devices will be copied and archived.
All local networks will be monitored for illicit content.
But of course you can trust me, I only have your best interests at heart.
From your link it wasn't a root certificate when it was signed, ie: by the "in the browser definition".
Basically you've given me proof that they could sign each other's certificates. But that they don't because they're untrustworthy.
Hmmm.
"No reason to be trusted in the first place (being self signed)."
At first this struck me as wrong. Mostly because all CA certificates are self signed.
The I found a question, "why don't the CAs sign each other's certificates?"
It's possible, they just never do it.
Is it perhaps that they don't trust each other!
If they don't trust each other why should we trust them ?
Oh okay, I obviously didn't go far enough up the thread.
But that does make me wonder why people would be so enamoured with this chip, a video controller that can't (it appears) share the memory with some other DMA/CPU etc chip and forces all accesses to it's memory to be made through a 'pin hole' of a couple of I/O ports really strikes me as a bit of a deal killer whatever other features it might have.
The vast majority of people throughout history died before the age of 25. We as a species would not have survived with such a serious mistake in our makeup.
The brain does continue to change, because at that age the human brain has more interconnectivity that at any other time. Most of those paths are never used and get reabsorbed. Somewhere after about 18 most of the paths that will be deleted are gone and many people basically stop learning.
So these 'mature' brains are ones that will never learn and will never discover anything new. That doesn't sound right, that's not 'mature' that's ossified.
Children have fully adult brain function at an average of age eight. The rest of childhood, as far as the brain is concerned, is learning stuff, beginning with the word "WHY"!
The only reason that a 17 year old makes a bad decision is lack of experience and lack of knowledge. In everything except sex (and in America alcohol) children are explicitly taught about "important things".
As for the word "Pedophilia" it's been redefined (like Moron, Idiot and Hacker) by the media to mean something like "a creepy picture of an older guy who's rumoured or 'proven' to have sex with a female of 18 or under". Yes according to the media having "legal sex" can be "Pedophilia", it's hardly surprising, after all you've just done it, the age of consent in most America states is 16.
Then we have the law, it's just made up of people, often they get things right, but ignorance, peer pressure and propaganda can make fools of anyone.
Actually, VDP RAM isn't memory mapped on any platform that I know of. But other systems have CPU-addressable memory that you could store a shadow copy of data in at least. The paltry 256 bytes on the TI-99/4A, though, are far from enough in many cases.
On the contrary, many 8-bits had memory mapped video. Commodore (VIC/64/Amiga), Sinclair (Spectrum, zx81, zx80, dist by Timex in the US) Atari, VT100 ... etc etc. Not that there weren't machines with distinct video RAM, the Commodore PET had specific video memory, though it was still mapped into the address space like a modern PC video card. Having the video RAM in a inaccessible (I/O bus) location was rare.
The reason was simple, at that point in time only a relatively small amount of RAM was needed for the machines and it ended up being faster than the CPU. So much so that you could assign 50% of the RAM bandwidth to the video subsystem without impacting the speed of the processor at all.
The ZX81, however, was a bit of a foreshadowing of things to come. It was built really, really, cheaply and they used really cheap DRAM. This cheap RAM wasn't fast enough to feed both the CPU and the video at the same time so the CPU was basically turned off when the video was being displayed (In fact it was physically used as a counter chip by the ultra cheap video controller).
Nowadays people want astronomical quantities of RAM so it basically has to be the cheapest design possible; this type of RAM can't keep up with just one CPU, let alone multiple CPUs and a video controller. So the video controller has to reduce the performance of the main CPUs by stealing cycles, or it gets it's own RAM.
Note: There are several Intel video controllers for PC clones that use main memory as the video RAM, they get added as a cheap motherboard video controller. Because of the fact that they're using slow RAM and stealing cycles from the CPU these are rightfully seen as very low performance.
On the other side, a common mistake for designs with distinct video RAM is that the CPU only ever needs to write to this RAM, unfortunately the problem is frequently only recognised in production.
I managed to resist in that message, but I still want to know why the slashdot programmers are happy looking like complete morons.
Will they ever get unamerican character sets working, or are they just bigots.
I've heard they think they have a problem with unicode control and composing characters, give me a break! A level 1 filter to filter everything that isn't a graphic LTR character is a couple of minutes work!!
Slashdot is advert supported (in part) the next line is what they are losing.
Â¥  £  â  $    â  â  ⣠ â  ⥠ ⦠ â  â  ⩠ â  â  â  ⮠ â
If you're afraid of losing it, burn it onto a DVD. That DVD you burned will outlast any VHS tape
Um, no. It's true if you play the disk/tape every day the VHS will wear out in less than 100 passes. But even if you leave them on the shelf the DVD±R will rot, it will get harder to play it will skip and judder until the day, very soon, that it's no longer seen as a DVD±R. The VHS will just sit there for decades.
Pressed silver DVDs do last longer, but repeated handling will eventually make them delaminate.
At this point in time I understand the best high capacity digital archive format is the DLT/LTO style tape cassette, it should reliably last at least 20 years on the shelf or 250 full passes whichever is sooner with no handling issues. Writeable DVDs usually die in less than five years.
If you want lots of playbacks, put it on the hard disk in your PVR.
heh, heh. I had to look up the guy's name, Dijkstra's algorithm is probably the worst algorithm you can use that will actually get the job done. It's a simple brute force breadth first search, no good programmer has to remember it. Like "bubble sort", "selection sort", "linear search" and a load of similar algorithms it's something that'll be reinvented when you run out of ideas.
Hell, it doesn't even have the simple optimisation of starting from both ends.
Don't be silly. Putting stuff under the GPL is the closest thing to abolishing copyright that you (as an individual) can do. It gives out your code in a public domain equivalent and makes sure that nobody can slap their own copyright onto it. It's been described as judo against the copyright system.
No contradiction.
It is a reasonable position for the court to take, but I don't think it's completely correct.
The difference between this and your bank account is that this is an unregulated account directly controlled by a company that the victim has a direct contract with. A bank account is not controlled to the same extent; a bank cannot just increase the numbers in the account without decreasing another or getting into a lot of trouble.
It is reasonable for the court to take measures to get this transfer reverted or corrected. Whereas a bank transfer is likely to have been converted into physical cash and so be very difficult to reverse.
It all comes down to real world consequences. Does the victim have a reasonable chance of recovering the objects of value that were given to the attacker. If the objects had no value (eg: they can be recreated or recovered on demand) it becomes an attempted robbery or just threats/assault. If the objects have value, (eg: acquired through 'effort and time investment,') but the victim can obviously get the things back it's a really dumb attempted robbery. Only if the attacker takes something of value away is it a robbery.
So in this case we have a foreign company in an industry that's notoriously unresponsive, so yes it looks like something of value that they couldn't get back and I too think a full robbery charge may well be justified in this case. But definitely not in general.
Not only that, if you live in a rented house and are robbed. You are the official victim even if it's some of your landlord's stuff that's stolen.
But this doesn't change that the stuff belongs to the landlord when you move out (or get evicted).
Still, I ain't sure this is right for virtual stuff belonging to a virtual-land lord.
Well, yes, I am leaving out assumptions. The biggy is probably that I'd be assuming both traffic and errors come in bursts. If they're continuous people would be complaining about slow performance and it would normally get fixed. But a bursty one would get the "looks okay to me" response every time. The 16bit checksum can't survive that, the 32bit CRC will (yup, no problem, definitely ... okay, probably) hold the data together long enough for the complaints to mount.
Though, I'd never suggest using a 48/64 bit CRC, if I decide that 32bit isn't enough (say like I'm feeling now!) I'd definitely step up to a full cryptographical checksum. If nobody can break it on purpose it ain't gonna break by accident!
Yup, just like that one; I really wish it was always checked. But many cheap and nasty ethernet adaptors don't seem to bother because it's so difficult for an end user to actually confirm that they're good adaptors.
Also remember, a checksum at the OS level will cover a different set of bytes to those that the HW level so two CRCs really does get you most if not all of the extra protection the extra bits imply.
No definitely not. Debian do nothing wrong in respect of the GPL or other licenses. Unlike the FSF they don't write licenses and so it is in no respect hypocritical for them to class some licenses as incompatible with the project.
The license grant for the Firefox name and branding is incompatible with the methods of the Debian project. For Debian stable the application code is frozen before a release is declared stable, the only changes allowed are direct bug fixes and security fixes. The license for the Firefox branding requires that only unmodified code is used to build the executables so that the firefox developers are not chasing bugs in other people's code that they don't have.
Both of these stances are good and reasonable, but Debian will not accept 'the current build' of firefox into stable just to fix a minor bug and Mozilla will not allow a version with an unverified 'minor bug bug fix' to be branded 'Firefox'.
Incompatible
As for the name; neither Debian nor Mozilla care. The just want something that's not 'fire fox'; 'ice cat', 'ice dog', 'ice bear' ... all have Google hits.
The SCTP checksum (same as zip IIRC) is mostly of use in a lan environment IMO. Across the internet you're very likely to either have an archive file which a good or even a cryptographical checksum or an encrypted connection with a message authentication code which is by definition a cryptographical checksum.
The TCP checksum is a bad joke. Not only is it small it's a bad example of a checksum so some estimates say that one in ten thousand errors will get through. This is really scary when you remember that a gigabit ethernet can transfer at least 80000 packets per second.
I have seen corruption due to lan errors that bypass the TCP checksums and I've had a serious corruption issue in one application that assumes the TCP channel is error free. Most applications tend to drop the connection or crash with protocol errors because they don't really trust the peer at the other end. OTOH a proper 32bit CRC is big enough to push the likelyhood of an undetected error from "may happen a few times a year" to "not in your, or your kids lifetime".
Both, just half size all over ... interesting times.
It's like "poser movies", if the thing that's distributed is just a "text description" it cannot be illegal. But feed it into the machine and things change, except no one would ever know and so once again the law is an ass.
That's a really poor way of describing SCTP. Firstly the relationship between TCP and UDP is such that TCP could be built entirely ontop of UDP, the only reason it isn't physically is so that the port numbers for UDP and TCP are distinct. On the other side the best description of UDP is actually "Bare IP packets with port numbers".
SCTP is not that, it would probably be most accurate to describe it as being a protocol with multiple TCP streams in both directions within one connection. Because it's within a single connection a 'stream' can be very small (ie a little message) and still be efficient and because there are multiple streams messages don't have to wait for each other; though they can if you want. It is probably simpler that TCP, but only because TCP has had so much bolted on.
But you are absolutely correct, this would be a very good protocol for throwing a load of tiny requests at a web server and getting the results back as soon as they're ready. BUT, mixing it with SSL would not be very simple, I guess you'd have to do what OpenVPN does.
Thanks, seems like you have to add &tbs=li:1& to your URL to turn this verbatim thing on.
So now my "do what you're fucking told to" string is:
&safe=off&nfpr=1&tbs=li:1&
I've also more or less given up search from any google page because of this crap called "instant search", it's far too slow to keep up with my typing and usually buggers up and loses part of the string (especially when I try to go back and fix a typo)