The BBC isn't the rights holder to most of the stuff it broadcasts, so it isn't really up to them.
Sure it's up to them - they negotiate the distribution rights when they negotiate the contracts with the content producers. They already negotiate for un-DRM'd PAL distribution in the UK, un-DRM'd DVB-S distribution in the UK, un-DRM'd DVB-T distribution in the UK and un-DRM'd DVB-C distribution in the UK. Why can't they negotiate for un-DRM'd IP distribution in the UK too?
Also, they are insisting on DRMing all content, even stuff they _do_ own the rights to.
They have to have some sort of DRM because some of the stuff they broadcast is not theirs and they only have rights to broadcast it in the UK.
DRM is not required to limit the broadcast to the UK only - that can be done simply by filtering based on IP address. I don't really see a big difference between broadcasting un-DRM'd content to UK residents over IP (which they allegedly "can't" do), and broadcasting un-DRM'd content to UK residents over DVB (which the BBC campaigned for the ability to do and have been doing (along with a load of other channels) for several years now).
Sure, the content producers don't like this idea of broadcasting to the public without DRM, but the BBC does it already over DVB and has enough muscle to push the content producers into letting them do it over IP.
So you can see the why people distribute closed source application for one OS - the costs of supporting more platforms far outweighs the benefit
Weighing up the "benefits" isn't really the issue. The BBC has a mandate to distribute their content in a platform agnostic way - this is something they are now refusing to do. This is pretty similar to saying "You can only receive BBC TV channels on Sony TVs". And frankly, just extending support to a limited number of platforms isn't good enough. Sure, they might support Windows, OS X, Linux on x86, but what happens if I want to use a Symbian device to watch the content? Or Linux running on an ARM?
Using propriatory formats and only allowing 3 platforms (windows, os x, linux) to play them does _not_ constitute "platform agnostic" - platform agnostic means that there would be no artificial limitation preventing me from writing a player for *any* platform using publicly available specifications.
You don't think it's important that everyday people can actually listen/watch the material? How strange.
I do think it's important... how would using an open format prevent everyday people from using the material? Seems to me it would enable _more_ everyday people to use the material by allowing them to use whatever player they are already familiar with rather than having to learn a propriatory one.
You think it's wrong to support the current version of the most popular operating system first?
I think it's wrong to use a propriatory format. If they used an open format for the system, producing a "iplayer" application for each OS wouldn't be important.
How do you know the "temporary" code produced "exactly the same results"? Where does it say that? I didn't see that anywhere.
It didn't. It also didn't say it produced different results. Infact they basically seemed to assert that any code marked as "temporary" renders the whole thing untrustworthy, which quite frankly is bollocks. If you want to draw any conclusions you need to do an analysis on the code itself, not just draw (possibly unfounded) conclusions from the comments for which you don't know the history.
More like the sober driver is going to get the book thrown at him due to a machine whose "temporary" code ignores errors until they happen more than a certain amount of the time.
My point was that whichever way you look at it, you can't make a decision one way or the other based purely on a comment stating that it is temporary code.
It really depends on the person. I'm in favor of "walk a line" style of tests. I don't care if you've had 100 beers if you can walk in a straight light, are in control of your faculties, and can drive as well as you could sober.
The "walk a line" tests don't test your reaction times. I know from experience of playing games requiring fast reactions that 30 minutes after drinking a pint of european lager with my lunch my reactions are slower, yet I would still pass both the "walk a line" tests and the breathalyser.
Considering this is shipping code in a device that doesn't exactly do automatic updates over a wireless network, I'm not sure when, exactly, you're anticipating that this testing" code will be replaced with the "real thing".
You could release the device with a non-optimal but completely functional piece of code due to time pressures in the development schedule. Maybe it's slow, or memory-hungry, but it still does the job just fine.
You mark the code as "temporary".
At a later date, you decide to release a new revision of the device - replacing the "temporary" code with a more optimal algorithm might provide cost savings by reducing the CPU spec needed, or the amount of RAM. Or maybe it just makes the device faster or extends the life of the batteries.
Given that the "temporary" code produced exactly the same results as the revised code, why is it important to this case? Is a drink-driver going to be let off because the manufacturer intended to release a later revision of the device which had a better battery life by running more efficient algorithms?
I'm not saying the manufacturer is in the right or in the wrong here, but it seems to me that you can't assume that code isn't production-quality just because there's a comment in there that states it's temporary.
You could rename the SSID to OPEN2PUBLIC, BUT even then most people would wish to have some terms and conditions, or provide some info.
Many public access points already exist with SSIDs that don't make it entirely clear, so the general public can't make the assumption that an access point not called "public" isn't supposed to be open. And we don't need a new convention to make it clear what is open or not - the protocol _already_ has the ability to tell people if the access point is open. The problem is that people are setting up access points which are publishing themselves as "open" using the standard protocol and then complaining when people think they are open - a new naming convention is just going to muddy the waters further.
I think something like a.here tld would be more useful to the world (much like the RFC1918 IP addresses) but I'm biased...
I think the summary is quite right in pointing out UMPCs and similar devices instead.
Not entirely sure why we specifically need x86 for embedded stuff like PVRs though... It's not like you're having to run something Windows on it, which is tied to specific architectures.
Well maybe you'd like car designs where you'd have to find or pay someone with "special knowledge" to help you configure your car door so that random strangers can't _trivially_ use your car.
Car analogies are pretty poor in this case because people don't legitimately leave cars for the general public to use. Whereas people _do_ intentionally leave access points open and there is no way for the general public to know if an AP was left open intentionally or not.
In any case, I would say that if someone "breaks into" a car that was supplied without the locks being enabled by default then the manufacturer can be held partly responsible - the same needs to happen with access point vendors.
If someone uses your network because you didn't secure it, it is _your_ fault for not securing it and also the _vendor's_ fault for supplying hardware that defaults to an unsecured mode. It is not the fault of the person who was using your network since they can't be expected to "magically" know that you didn't intend it to be open.
But I suppose, nobody is really interested in making significantly better stuff.
The thing is, there's nothing in it for the manufacturers. The people who know about this stuff are quite happy securing the networks themselves and everyone else doesn't know any better, so making them secure by default just increases the vendor's support costs.
What is needed to drive the vendors to produce a better security model is for them to be partly held responsible for the security problems associated with bad security. If someone connected to your network and copied all the financial records from your computer you might think about suing the access point vendor, but with these cases the losses to the access point owner are so tiny (if any) that they are never going to bother taking action against the vendor.
That's why I was lobbying for years to have an additional identifier bit added to the 802.11N specification. The "misconfigured bit" would be required to be set by the operator if they did not properly configure their access point.
Sounds like a bad idea to me - it would end up much like the "hide SSID" option, promoting a false sense of security.
Why not just default to having encryption turned on? The first time the device is turned on it generates a random key which the user can view by connecting to the web interface.
Ultimately I think 802.11 needs some kind of "pairing" system, even if it's just a button on the front of the access point that allows a device to request the key (and then immediately turns off "pairing" mode once it's done) so the user doesn't have to type it in themselves.
Obviously, if I'm in the burbs and I see a network called "The Johnsons", then I can safely assume that is *not* a public network, and for anyone to try to pass off the "how am I supposed to know" argument deserves to be smacked in the head for dishonesty.
It's often not that clearcut. If you see a network called "BT Voyager", are you going to assume it's someone using a BT router in their private residence, or is it a public BT hotspot? (in actualy fact, "BT Voyager" is a model of router, but it takes some knowledge to know that, and I _have_ accidentally connected to one in the past thinking it was a BT hotspot.)
Where I live there's a good collection of:
- Private secured networks - Private unsecured networks - Private unsecured networks where I _know_ the owner intended to allow the public to have access - Public subscription hotspots (put your credit card number into a web page to get access) - Public free hotspots
How am I supposed to tell which one I'm dealing with? Which brings me neatly to a question: how did you know "The Johnsons" didn't intend their network to be usable by the public?
What you have to bear in mind is that the wireless aspect is largely irrelevant; it is only the delivery method.
The issue is that the delivery mechanism provides a way for the owner to say "yes, I want to let the public connect" or "no, I want to keep the connection private". It is the owner's responsibility to set this option appropriately - sure the access points should come preconfigured with the security turned on, but since there's no other way for anyone else to know if the AP is supposed to be public or not, the general public should be well within their rights to assume the owner has set the option to match her wishes.
if you aren't sure whether they are intentionally providing free connectivity or not, you can always find them and ask.
This raises 2 problems - how do you actually know who's providing the connection, and how do you find them in order to ask if it's ok?
Also, how is this different from any other network service - do you go and find Google's CEO and ask if it's ok to use their website? No? Why not?
You have a power socket mounted in a housing at the edge of your front yard that you use for your xmas displays. OK if I plug my AC into it?
If there were a standard method of securing it built into the socket which I hadn't enabled, and plenty of other people willingly offering free power to the public by installing similarly unsecured power sockets then yes - it would seem you're well within your rights to assume that my power socket is available for your use.
The fact of the matter is that the security setting on the access point is _the_ way to tell whether the owner wants the public to connect to it - there is no other method of announcing it. It is impossible for the public to tell the difference between the (many) free public hotspots and the misconfigured private routers.
It's equivalent to you sticking a sign on your power socket saying "free power" - sure, the power sockets probably shouldn't come with the "free power" sign on them by default, but I don't see why the public should be held responsible for the network owner's failure to remove the sign if he didn't like it.
To use your analogy, the water isn't going into your garden, you're catching it by leaning over the fence.
No, you're not venturing onto their property at all - their wifi signal is spilling out past their property and there's no way to tell that they aren't intentionally providing free connectivity. What if the water is spilling onto the road - would you be arrested for putting your potted plants there?
most people not locking down their APs and only a small proprotion doing so, all because it's "too hard"
Yeah, I don't replace the brake pads on my car because it's "too hard"... I imagine the person I crash into will be arrested instead of me if I have an accident so that's ok.
In any case, if you want "easy" I think you should look to the bluetooth pairing mechanism - push a button on each device and let them pair with eachother - no need for the user entering their own encryption keys (which are probably dictionary word passwords anyway).
How would you, you should ask, tell inability from apathy? What if the person running the router really does not know how to secure it?
I'm not sure why the ability of the network owner enters into the discussion. Pretty poor analogy, but: if the brakes failed on your car and you had an accident, I'm not sure the police would look too kindly on you defending yourself with "I didn't know I had to get the brake pads changed every few years".
The fact remains that there _is_ a way of securing networks, even if the owner doesn't know how, and there is no way for the general public to tell whether they are connecting to a misconfigured AP or a legitimately open AP.
It's precisely because people don't accept them, and precisely because they don't know how to protect themselves against them.
Why should we outlaw a completely legitimate activity (using intentionally open access points) just because some people are not educated and don't want to pay someone who is? How about we outlaw people accessing web sites just incase someone left an unpassworded private page somewhere public...
It isn't theft, but it is ethically analogous to trespassing in an unlocked house or on unfenced property; let me tell you why.
So if you walked into a pub which had an open door and a "free beer" sign outside, would you expect to be arrested for trespass? No? How are you proposing we tell the difference between the buildings advertising "free beer" on purpose and those who accidentally put the "free beer" sign out?
A quick look at my wardriving log on Google Earth indicates that whilest there are still a lot of unsecured routers the vast majority are secured. And of course, you have no idea how many of those open APs are legitimately open...
so yes, if Starbucks decided they didn't want people on the connection people should fuck off. it isn't vital to anyone's survival that they get that connection
Seems to me there's a bit of a difference between the owner of the connection asking you not to use it and the police turning up and arresting you without warning.
and it won't hurt them a bit to at least check if it is ok for them to access the connection.
You're assuming someone's around to ask. If you're at an airport, who do you ask to see if the open access point you picked up is for public use?
Your first hint that you might not be allowed to use the connection is when you realize you don't have permission and admit it to the local constabulary.
With respect, you have no idea how the conversation went. Maybe it was something like:
Police: What are you doing? Defendent: Just getting the bus timetable off the internet so I can get home Police: How are you connecting to the internet Defendent: There seems to be a free wifi hotspot here Police: Did you get express permission from the owner of the hotspot? Defendent: Uh no.. I assumed it was a free public hotspot since it allowed me to connect without authenticating. [Defendent gets arrested for "using an internet connection without permission (and admitting to it)]
It doesn't seem much different than: Police: What are you doing? Defendent: Searching the internet for a bus timetable so I can get home Police: How are you searching? Defendent: Using Google Police: Did you get express permission from the owner of Google? Defendent: Uh no.. I assumed it was a free public website since it allowed me to connect without authenticating. [Defendent gets arrested for "using a web server without permission (and admitting to it)]
The second example would be laughed out of court - why should the first example be any different?
Here's an analogy that possibly works, but even then I feel dirty coming up with one:
Here's a better analogy:
You set up a web server which doesn't ask for authentication and serves up web pages without telling me I shouldn't be using it. Am I justified in connecting to it?
If you answer "no" then I'm sure you get permission from Google, Slashdot, etc in writing before you try connecting to their web servers.
If you answer "yes" then I'm sure you will explain what the difference is between a web server that _could_ be passworded, and an access point that _could_ be passworded. There are plenty of web sites and access points that are intentionally left unpassworded, and there are plenty of web sites and access points that have been left unpassworded by accident.
Unless the SSID is something like "public" or "freewifi" then you do not have a reasonable expectation that it is there for you to use.
So when I see an access point broadcasting a SSID of "MyCloud", "BT OpenZone", "TMobile" or "Eurospot" I don't have a reasonable expectation that it is there for me to use?
The truth of the matter is that it's often impossible to tell what access points are supposed to be open and what access points are just misconfigured. It takes knowledge of the various hotspot providers on the market to know that "BT OpenZone" is a 802.11 hotspot and "BT Voyager" is someone's home router (BT provide both hotspots and residential ADSL connections with 802.11 routers).
Slashdot Mirror
The BBC isn't the rights holder to most of the stuff it broadcasts, so it isn't really up to them.
Sure it's up to them - they negotiate the distribution rights when they negotiate the contracts with the content producers. They already negotiate for un-DRM'd PAL distribution in the UK, un-DRM'd DVB-S distribution in the UK, un-DRM'd DVB-T distribution in the UK and un-DRM'd DVB-C distribution in the UK. Why can't they negotiate for un-DRM'd IP distribution in the UK too?
Also, they are insisting on DRMing all content, even stuff they _do_ own the rights to.
They have to have some sort of DRM because some of the stuff they broadcast is not theirs and they only have rights to broadcast it in the UK.
DRM is not required to limit the broadcast to the UK only - that can be done simply by filtering based on IP address. I don't really see a big difference between broadcasting un-DRM'd content to UK residents over IP (which they allegedly "can't" do), and broadcasting un-DRM'd content to UK residents over DVB (which the BBC campaigned for the ability to do and have been doing (along with a load of other channels) for several years now).
Sure, the content producers don't like this idea of broadcasting to the public without DRM, but the BBC does it already over DVB and has enough muscle to push the content producers into letting them do it over IP.
So you can see the why people distribute closed source application for one OS - the costs of supporting more platforms far outweighs the benefit
Weighing up the "benefits" isn't really the issue. The BBC has a mandate to distribute their content in a platform agnostic way - this is something they are now refusing to do. This is pretty similar to saying "You can only receive BBC TV channels on Sony TVs". And frankly, just extending support to a limited number of platforms isn't good enough. Sure, they might support Windows, OS X, Linux on x86, but what happens if I want to use a Symbian device to watch the content? Or Linux running on an ARM?
Using propriatory formats and only allowing 3 platforms (windows, os x, linux) to play them does _not_ constitute "platform agnostic" - platform agnostic means that there would be no artificial limitation preventing me from writing a player for *any* platform using publicly available specifications.
You don't think it's important that everyday people can actually listen/watch the material? How strange.
I do think it's important... how would using an open format prevent everyday people from using the material? Seems to me it would enable _more_ everyday people to use the material by allowing them to use whatever player they are already familiar with rather than having to learn a propriatory one.
You think it's wrong to support the current version of the most popular operating system first?
I think it's wrong to use a propriatory format. If they used an open format for the system, producing a "iplayer" application for each OS wouldn't be important.
How do you know the "temporary" code produced "exactly the same results"? Where does it say that? I didn't see that anywhere.
It didn't. It also didn't say it produced different results. Infact they basically seemed to assert that any code marked as "temporary" renders the whole thing untrustworthy, which quite frankly is bollocks. If you want to draw any conclusions you need to do an analysis on the code itself, not just draw (possibly unfounded) conclusions from the comments for which you don't know the history.
More like the sober driver is going to get the book thrown at him due to a machine whose "temporary" code ignores errors until they happen more than a certain amount of the time.
My point was that whichever way you look at it, you can't make a decision one way or the other based purely on a comment stating that it is temporary code.
It really depends on the person. I'm in favor of "walk a line" style of tests. I don't care if you've had 100 beers if you can walk in a straight light, are in control of your faculties, and can drive as well as you could sober.
The "walk a line" tests don't test your reaction times. I know from experience of playing games requiring fast reactions that 30 minutes after drinking a pint of european lager with my lunch my reactions are slower, yet I would still pass both the "walk a line" tests and the breathalyser.
Considering this is shipping code in a device that doesn't exactly do automatic updates over a wireless network, I'm not sure when, exactly, you're anticipating that this testing" code will be replaced with the "real thing".
You could release the device with a non-optimal but completely functional piece of code due to time pressures in the development schedule. Maybe it's slow, or memory-hungry, but it still does the job just fine.
You mark the code as "temporary".
At a later date, you decide to release a new revision of the device - replacing the "temporary" code with a more optimal algorithm might provide cost savings by reducing the CPU spec needed, or the amount of RAM. Or maybe it just makes the device faster or extends the life of the batteries.
Given that the "temporary" code produced exactly the same results as the revised code, why is it important to this case? Is a drink-driver going to be let off because the manufacturer intended to release a later revision of the device which had a better battery life by running more efficient algorithms?
I'm not saying the manufacturer is in the right or in the wrong here, but it seems to me that you can't assume that code isn't production-quality just because there's a comment in there that states it's temporary.
You could rename the SSID to OPEN2PUBLIC, BUT even then most people would wish to have some terms and conditions, or provide some info.
.here tld would be more useful to the world (much like the RFC1918 IP addresses) but I'm biased...
Many public access points already exist with SSIDs that don't make it entirely clear, so the general public can't make the assumption that an access point not called "public" isn't supposed to be open. And we don't need a new convention to make it clear what is open or not - the protocol _already_ has the ability to tell people if the access point is open. The problem is that people are setting up access points which are publishing themselves as "open" using the standard protocol and then complaining when people think they are open - a new naming convention is just going to muddy the waters further.
I think something like a
Whats wrong with the conventional "localnet"?
I think the summary is quite right in pointing out UMPCs and similar devices instead.
Not entirely sure why we specifically need x86 for embedded stuff like PVRs though... It's not like you're having to run something Windows on it, which is tied to specific architectures.
Well maybe you'd like car designs where you'd have to find or pay someone with "special knowledge" to help you configure your car door so that random strangers can't _trivially_ use your car.
Car analogies are pretty poor in this case because people don't legitimately leave cars for the general public to use. Whereas people _do_ intentionally leave access points open and there is no way for the general public to know if an AP was left open intentionally or not.
In any case, I would say that if someone "breaks into" a car that was supplied without the locks being enabled by default then the manufacturer can be held partly responsible - the same needs to happen with access point vendors.
If someone uses your network because you didn't secure it, it is _your_ fault for not securing it and also the _vendor's_ fault for supplying hardware that defaults to an unsecured mode. It is not the fault of the person who was using your network since they can't be expected to "magically" know that you didn't intend it to be open.
But I suppose, nobody is really interested in making significantly better stuff.
The thing is, there's nothing in it for the manufacturers. The people who know about this stuff are quite happy securing the networks themselves and everyone else doesn't know any better, so making them secure by default just increases the vendor's support costs.
What is needed to drive the vendors to produce a better security model is for them to be partly held responsible for the security problems associated with bad security. If someone connected to your network and copied all the financial records from your computer you might think about suing the access point vendor, but with these cases the losses to the access point owner are so tiny (if any) that they are never going to bother taking action against the vendor.
That's why I was lobbying for years to have an additional identifier bit added to the 802.11N specification. The "misconfigured bit" would be required to be set by the operator if they did not properly configure their access point.
Sounds like a bad idea to me - it would end up much like the "hide SSID" option, promoting a false sense of security.
Why not just default to having encryption turned on? The first time the device is turned on it generates a random key which the user can view by connecting to the web interface.
Ultimately I think 802.11 needs some kind of "pairing" system, even if it's just a button on the front of the access point that allows a device to request the key (and then immediately turns off "pairing" mode once it's done) so the user doesn't have to type it in themselves.
Obviously, if I'm in the burbs and I see a network called "The Johnsons", then I can safely assume that is *not* a public network, and for anyone to try to pass off the "how am I supposed to know" argument deserves to be smacked in the head for dishonesty.
It's often not that clearcut. If you see a network called "BT Voyager", are you going to assume it's someone using a BT router in their private residence, or is it a public BT hotspot? (in actualy fact, "BT Voyager" is a model of router, but it takes some knowledge to know that, and I _have_ accidentally connected to one in the past thinking it was a BT hotspot.)
Where I live there's a good collection of:
- Private secured networks
- Private unsecured networks
- Private unsecured networks where I _know_ the owner intended to allow the public to have access
- Public subscription hotspots (put your credit card number into a web page to get access)
- Public free hotspots
How am I supposed to tell which one I'm dealing with? Which brings me neatly to a question: how did you know "The Johnsons" didn't intend their network to be usable by the public?
What you have to bear in mind is that the wireless aspect is largely irrelevant; it is only the delivery method.
The issue is that the delivery mechanism provides a way for the owner to say "yes, I want to let the public connect" or "no, I want to keep the connection private". It is the owner's responsibility to set this option appropriately - sure the access points should come preconfigured with the security turned on, but since there's no other way for anyone else to know if the AP is supposed to be public or not, the general public should be well within their rights to assume the owner has set the option to match her wishes.
if you aren't sure whether they are intentionally providing free connectivity or not, you can always find them and ask.
This raises 2 problems - how do you actually know who's providing the connection, and how do you find them in order to ask if it's ok?
Also, how is this different from any other network service - do you go and find Google's CEO and ask if it's ok to use their website? No? Why not?
You have a power socket mounted in a housing at the edge of your front yard that you use for your xmas displays. OK if I plug my AC into it?
If there were a standard method of securing it built into the socket which I hadn't enabled, and plenty of other people willingly offering free power to the public by installing similarly unsecured power sockets then yes - it would seem you're well within your rights to assume that my power socket is available for your use.
The fact of the matter is that the security setting on the access point is _the_ way to tell whether the owner wants the public to connect to it - there is no other method of announcing it. It is impossible for the public to tell the difference between the (many) free public hotspots and the misconfigured private routers.
It's equivalent to you sticking a sign on your power socket saying "free power" - sure, the power sockets probably shouldn't come with the "free power" sign on them by default, but I don't see why the public should be held responsible for the network owner's failure to remove the sign if he didn't like it.
To use your analogy, the water isn't going into your garden, you're catching it by leaning over the fence.
No, you're not venturing onto their property at all - their wifi signal is spilling out past their property and there's no way to tell that they aren't intentionally providing free connectivity. What if the water is spilling onto the road - would you be arrested for putting your potted plants there?
most people not locking down their APs and only a small proprotion doing so, all because it's "too hard"
Yeah, I don't replace the brake pads on my car because it's "too hard"... I imagine the person I crash into will be arrested instead of me if I have an accident so that's ok.
In any case, if you want "easy" I think you should look to the bluetooth pairing mechanism - push a button on each device and let them pair with eachother - no need for the user entering their own encryption keys (which are probably dictionary word passwords anyway).
How would you, you should ask, tell inability from apathy? What if the person running the router really does not know how to secure it?
I'm not sure why the ability of the network owner enters into the discussion. Pretty poor analogy, but: if the brakes failed on your car and you had an accident, I'm not sure the police would look too kindly on you defending yourself with "I didn't know I had to get the brake pads changed every few years".
The fact remains that there _is_ a way of securing networks, even if the owner doesn't know how, and there is no way for the general public to tell whether they are connecting to a misconfigured AP or a legitimately open AP.
It's precisely because people don't accept them, and precisely because they don't know how to protect themselves against them.
Why should we outlaw a completely legitimate activity (using intentionally open access points) just because some people are not educated and don't want to pay someone who is? How about we outlaw people accessing web sites just incase someone left an unpassworded private page somewhere public...
It isn't theft, but it is ethically analogous to trespassing in an unlocked house or on unfenced property; let me tell you why.
So if you walked into a pub which had an open door and a "free beer" sign outside, would you expect to be arrested for trespass? No? How are you proposing we tell the difference between the buildings advertising "free beer" on purpose and those who accidentally put the "free beer" sign out?
A quick look at my wardriving log on Google Earth indicates that whilest there are still a lot of unsecured routers the vast majority are secured. And of course, you have no idea how many of those open APs are legitimately open...
so yes, if Starbucks decided they didn't want people on the connection people should fuck off. it isn't vital to anyone's survival that they get that connection
Seems to me there's a bit of a difference between the owner of the connection asking you not to use it and the police turning up and arresting you without warning.
and it won't hurt them a bit to at least check if it is ok for them to access the connection.
You're assuming someone's around to ask. If you're at an airport, who do you ask to see if the open access point you picked up is for public use?
Your first hint that you might not be allowed to use the connection is when you realize you don't have permission and admit it to the local constabulary.
With respect, you have no idea how the conversation went. Maybe it was something like:
Police: What are you doing?
Defendent: Just getting the bus timetable off the internet so I can get home
Police: How are you connecting to the internet
Defendent: There seems to be a free wifi hotspot here
Police: Did you get express permission from the owner of the hotspot?
Defendent: Uh no.. I assumed it was a free public hotspot since it allowed me to connect without authenticating.
[Defendent gets arrested for "using an internet connection without permission (and admitting to it)]
It doesn't seem much different than:
Police: What are you doing?
Defendent: Searching the internet for a bus timetable so I can get home
Police: How are you searching?
Defendent: Using Google
Police: Did you get express permission from the owner of Google?
Defendent: Uh no.. I assumed it was a free public website since it allowed me to connect without authenticating.
[Defendent gets arrested for "using a web server without permission (and admitting to it)]
The second example would be laughed out of court - why should the first example be any different?
Here's an analogy that possibly works, but even then I feel dirty coming up with one:
Here's a better analogy:
You set up a web server which doesn't ask for authentication and serves up web pages without telling me I shouldn't be using it. Am I justified in connecting to it?
If you answer "no" then I'm sure you get permission from Google, Slashdot, etc in writing before you try connecting to their web servers.
If you answer "yes" then I'm sure you will explain what the difference is between a web server that _could_ be passworded, and an access point that _could_ be passworded. There are plenty of web sites and access points that are intentionally left unpassworded, and there are plenty of web sites and access points that have been left unpassworded by accident.
Unless the SSID is something like "public" or "freewifi" then you do not have a reasonable expectation that it is there for you to use.
So when I see an access point broadcasting a SSID of "MyCloud", "BT OpenZone", "TMobile" or "Eurospot" I don't have a reasonable expectation that it is there for me to use?
The truth of the matter is that it's often impossible to tell what access points are supposed to be open and what access points are just misconfigured. It takes knowledge of the various hotspot providers on the market to know that "BT OpenZone" is a 802.11 hotspot and "BT Voyager" is someone's home router (BT provide both hotspots and residential ADSL connections with 802.11 routers).
I want to agree with you, however have you read the manual, or looked at the default settings for some home networking kit?
Maybe it's time to start pressing charges against the manufacturer?