This isn't firefox specific, any software be it open or proprietary works the same way - the engineers must be able to recreate the problem themselves in order to fix it. There is no other option.
But there is another option for the users: they can use other software.
I sympathise with the frustrations of software developers, but the idea that any normal user (most of whom aren't going to be programmers or sysadmins themselves) is going to set up a virtual machine, reduce a bug they see down to a minimal test case, and then file a detailed bug report is crazy. It just isn't going to happen.
If a project has to keep relying on this, instead of being able to do good quality control and testing itself, the inevitable result is perpetually beta quality software, and getting left behind by other projects that are capable of doing proper quality control and testing.
This is all way off-topic by now, but my point is still the same: MojoKid's position is probably correct. There are significant costs for servers and for bandwidth for any site that scales up, and they can easily become more than it's reasonable to expect a hobbyist to pay out of their own pocket if the site becomes popular.
Of course, this is all before there is any actual content on the site! Doing the planning and research and writing and editing and presentation of original material takes about as much time and money on a web site as in any other medium.
You know somewhere that provides reliable hosting for five servers supplying 40MB/s each for less than 5-10 bucks? I doubt that very much. For the dedicated servers I use on one of the commercial sites I mentioned, I'd be running at over $1,000 per day for that kind of traffic.
Obviously no-one running at that kind of scale is still on the same kind of hardware and pricing set up that my little site is on, but dedicated/unmetered lines aren't cheap either. In any case, you get the point: the servers aren't the problem for high traffic sites, the network bandwidth is.
And ad blocking. Don't even get me started. So many ad blockers are so proud of what they do, like it's some badge of honor to block. If everyone blocked ads, many quality web sites would likely cease to exist, including Slashdot.
I suspect in reality that the best sites would continue, but there would be a lot more paywalls around, probably less editorial integrity on open sites as things like product placements and affiliate referral fees became more reliable revenue streams, and maybe over time we'd eventually get somewhere with micropayments. In some ways, moving to more "honest" funding via paywalls and/or micropayments might be a better long-term model for the people who do produce good content and run valuable sites than what we have today, though no doubt it would be a painful transition with many casualties.
The thing that makes me a little sad inside is that the aggressive, irresponsible advertisers have spoiled the model for the moderate, responsible ones. Because of the former group, I do block very aggressively when I'm browsing, and I don't feel any guilt about it because my motivations are security, privacy and performance. However, I also have no problem with people who just want to make a bit of money from running a decent site, and I wouldn't block their ads if there were a reliable way to allow those while still eliminating the rest. Unfortunately, I don't see that being possible any time soon, which is why none of the commercial sites I've ever run myself has relied on ads as a business model.
A domain is around 5-10 bucks and you can get hosting for less.
Sure you can. I've run various personal or social group sites over the years that just paid a little to keep things running, without expecting any sort of income in return. For the personal sites, I do it for the satisfaction of giving something back, and sometimes starting enjoyable discussions with others who share my interests.
I also run some commercial sites, aiming at a wider audience, charging real money for signing up. This is a completely different scale of commitment in terms of hardware, connectivity, and operating costs.
If you're running a discussion forum that you share with 50 friends, sure, it can be in the first category and you can do it for peanuts and enjoy all the high quality interaction you like. But running a significant news or social networking site with thousands of participants? Not even close.
I use POP3, so I can have local copies of all emails.
What I'd really like with modern trends is more emphasis on "private clouds". I want to put my data on my own server on my own network, so it can be accessed from any of my devices around the house and over VPN if I'm out, but with the data always securely under my control and backed up according to my wishes.
This is easy for some formats, including plain files obviously. However, it's surprisingly awkward for stuff like e-mail, where there are plenty of relevant concepts like IMAP and mail stores and smart hosts and web mail systems, but actually setting them up in a useful combination if you're not an experienced sysadmin is quite a challenge.
Sadly, it seems even the best FOSS client software is dying out these days, often because "everyone has Google Whatever". As far as I know there hasn't yet been a lot of movement in the FOSS world towards having easily-deployable private clouds for e-mail, shared documents, and so on, which always surprises me given the implicit freedom, independence, privacy and security.
You might not have much recourse even if it's a commercial service you're using. Ironically, on-line back-up services are among the worst offenders. If you use one, go ahead and check its terms, and see whether any of those lovely restoration options they offer will still be there if they decide to close down on a whim. (Hint: Probably they won't, and all you'll get is maybe 48 or 72 hours to download as much as you can at the same time as every other customer they have is trying to do the same.)
If it matters, back it up on systems you control yourself. If it's private, don't upload it to anything, and encrypt the back-ups. It's really that simple. Then again, so is "make sure you back up your important files", and how many people don't do that because it's mildly inconvenient? Maybe those on-line back-up services aren't quite so bad after all...
It takes very little effort to realize that the most useful and needed excuse to shut down cell phones by the police will be to prevent citizens from recording their behavior in the absence of police body cams.
Indeed, and yet I'm dozens of posts into this discussion before you were the first person I saw even notice.:-(
This could in theory be used to prevent something like a phone triggering a bomb, though if there is a genuine threat of something like that happening, I would think that restricting or turning off transmission over the network was a much more reliable method than assuming that someone willing to blow up a bomb was also obliging enough not to mod their phone to ignore the kill switch.
Meanwhile, it has now been demonstrated beyond any doubt that video recording of police officers at work reduces both complaints of excessive force against officers and instances of violence toward officers, both of which are surely good things. It has also been demonstrated on numerous occasions that officers who did cross the line may then attempt to destroy evidence such as photographs or recordings on electronic devices held by passers by. Obviously if all it takes is accessing some centralised police system with insufficient safeguards and oversight to remotely destroy that evidence, as opposed to potentially physically confronting someone who is just an innocent third party and making their situation worse, there is less deterrent to the minority of officers who do abuse their position.
Ah, I see. I had intended the IPS/DLP example to demonstrate both the fact that it was technically possible to MITM SSL traffic if you have control of the client and the fact that this is actually done in practice. I didn't mean to imply that routine logging was necessarily going on in any particular organisation; I don't expect that it is in most places, at least not intentionally, for all the reasons we've talked about. Apologies if that wasn't clear.
You can post credentials as much as you like. I've worked in the industry, and I know who some of the big customers are. (Given your background and the nature of the discussion, I hope you'll take my word for that and understand why I'm not going to post a list similar to yours here.)
I said before but will repeat: your liability concerns are fair and valid. In fact, there is a significant side market in devices that can pick out parts of the network traffic that might be sensitive one way or another and mask out or truncate the unwanted details, and that market is driven in party by exactly the kinds of liability concerns you mentioned.
The fact remains that from a technical point of view, if corporate IT want to log your traffic and if you're working on a company machine and talking over the company network, there are tools available that will do that for them and you would never know it was happening without inside information. Everything else is down to legal issues and how much you trust your employer to behave responsibly.
I get the feeling that we would agree about the fundamental ethics of the situation anyway. This little discussion started when BitZtream argued that a good sysadmin can control "what his company does and doesn't see on company time, company equipment, and company networks". Zero__Kelvin seemed to think SSL would be a barrier to that. It is not.
Just to be clear, I'm not talking about small companies. IME, the smaller companies I've worked with have been far less likely to do this kind of thing, because the level of trust is greater when "everyone knows everyone".
The liability issue you raise with regulated external sites is a fair point, and so are your comments about internal segregation in some contexts. However, please remember that not everywhere has the same legal rules and precedents as the US.
This whole field is rather young to make too many general claims about what is and isn't considered acceptable, particularly if an employee has been explicitly told that company equipment and networks are monitored and use may be recorded. How much employees should be explicitly warned about -- for example, whether this kind of SSL-defeating technique should be highlighted even if you're already saying you might read communications -- is something of an open question at least ethically and possibly legally as well. Heck, workplace surveillance generally is a very two-sided issue, and even where the law is relatively settled already, it can be a source of serious problems and disagreements.
But the general principle we were discussing was that sysadmins can have a lot of control about what happens on company networks, and that stands. Even if, for legal, moral or ethical reasons, an organisation chooses not to log the content of things like IM and e-mail communications, the technical tools to do so exist right now. And while you (and I, for the record) might choose to avoid working for an employer who we knew to use such monitoring, the reality is that unless you actually work in their IT department, you're never going to be able to determine reliably what is actually being done and it's all a matter of trust.
As I said, IPS and DLP devices are routinely used to MITM SSL connections. There's not much point having some stupidly expensive firewall setup at the edge of your corporate network if all its takes for malware to get in is Joe from Accounts opening his GMail and running cute_kitty_photoz.exe.
Typically, the volume of data transmitted through these kinds of links makes comprehensive long-term recording and storage prohibitively expensive. However, logging everything normally sent over plain-text, human-speed communications channels such as e-mail or IM is quite achievable, as is logging a complete traffic stream identified by some trigger.
Incidentally, these devices are often used precisely because they allow you to control and limit your liability. For example, it's easier to argue you're in compliance with regulations like HIPAA or PCI-DSS if you can demonstrate reliably that traffic leaving your network was scanned and nothing fitting certain suspicious patterns was sent. A simpler but no less significant consideration is the damage any large organisation could suffer if malware did somehow get into their network.
They don't have to block SSL, they just have to MITM the connection if they need to analyse or log the traffic. IPS and DLP devices that can do this for all the major protocols have been available to professional sysadmins for some time. If you access the Internet from a company device at an organisation that is either very large or working in a particularly sensitive field, there is a good chance your traffic is already being processed in this way.
If you want some communications to be private from your employer, use your own device, not a company-administered one. It's really as simple as that these days.
Conditions of entry don't have any effect on copyright law, as far as I know.
Not by default, but I know of no legal reason an admission contract couldn't include a clause transferring copyright in any recordings made to the organisers.
... under UK Copyright law there is no "fair use" exception
That is correct. There are some specific exceptions, commonly referred to as "fair dealing" over here, and there have been some recent developments that will expand the scope of the exceptions, but there is no generic limitation on copyright determined by a set of qualitative tests like the Fair Use rules in the US. However, if we're talking about someone's own footage of the goals, the more important issue might be what the contract was when they bought their admission ticket.
If the conditions of entry clearly say no recording is allowed and that if any recordings are made anyway then all rights are assigned to the organisers, then my expectation is that the uploaders won't have a leg to stand on here. It would be very surprising in this day and age if such terms weren't routinely included, and I fully expect that this is how any debate about legality will wind up being resolved.
On the other hand, if there's nothing prohibiting the use of recording devices and nothing claiming any rights over recordings made by spectators, it might be tough to argue successfully in court along the lines that someone's personal recording was a copy or derivative work of some official recording that the organisers sell to TV networks. It's not an unprecedented idea: publishing photos of major public landmarks like the Hollywood sign or Eiffel Tower can be legally hazardous, particularly if commercial use is involved. However, those restrictions tend to result from some carefully contrived/created edge cases in the legal position for specific places, and it's hard to see how anything similar applies to a football match.
(IANAL so obviously you shouldn't trust anything you just read if it actually matters to you.)
You seem to be conflating several issues, as well as setting up some straw men, neither of which encourages constructive debate.
One issue is statutory licensing, which may artificially limit the number of people who can drive for-hire vehicles in a given area. It is true that such regimes are vulnerable to local politics and regulatory capture, pushing expenses up for drivers and reducing competition. There are also some arguments in favour of reasonable licensing regimes, not least because there is only so much road space and so much demand for hire vehicles. There is certainly room for debate about how this side of the industry works and whether newer alternative models might be better.
Another issue is safety regulations, which typically restrict things like permitted time behind the wheel without a break or how often vehicles must be maintained and tested. This is quite a different thing from licensing to limit supply in the market, though clearly some method of identifying who is subject to the safety regulations is needed. Here it is common, at least in my country, for professional drivers who spend many hours behind the wheel to be regulated. For example, lorry drivers and coach drivers also have to comply with regulations that don't apply to individuals driving private vehicles for their own purposes. Here, there is much less room for debate. Normal people don't spend the equivalent of an entire working day behind the wheel, day in and day out, with relatively little to keep their attention focused on driving. Even when private individuals make long journeys by car, they rarely spend as long behind the wheel as lorry drivers do daily. And of course the service and mandatory testing intervals for private cars are set with private driving in mind, while vehicles used commercially tend to do much higher mileage.
As a third related issue there is insurance. It is a legal requirement in my country for every driver to have proper insurance to certain minimum standards. Note that this is primarily for the protection of others: as far as I know, you can still drive a personal car without insurance to cover wrapping it around a tree and writing it off, but you may not legally drive it without "third party" insurance that would cover any damage you do if you wrap it around someone else's car and write off both vehicles. Insurance policies typically specify things like the type of vehicle and how it will be used and are priced accordingly, and the insurance industry probably has a better understand of the true risks of different types of driving than anyone else. So letting people drive commercially when their insurance doesn't cover it would just be a loophole and a clear risk to other road users who won't be protected as the law requires in the event of an accident.
I don't think the people who question services like Uber on regulatory grounds are necessarily against competition or innovation in the marketplace. I'm certainly not; I write software every day for businesses that do stuff no-one has done before that is only possible because of that software, so why would I want to hold back progress? But some of those regulations really are there for good, sensible, practical reasons, and I don't think a new entrant into the market should get a free pass on breaking the rules that apply to everyone else just because they're new.
This is not one of those things where you need to "compromise" so that some people are disadvantaged SO THAT another group may be disadvantaged.
Unless you're the person in the lane next to the Uber car when its high-mileage, improperly-maintained components break, or the person crossing the road in front when the Uber driver falls asleep, and then you get to be in the accident too.
Regulations on commercial drivers exist for a reason, and it's not just for the benefit of the passengers inside a commercial vehicle.
Providing an alternative that is competitive merely by virtue of not following the same rules as everyone else isn't an improvement. Compete on the same basis as everyone else, and then if your service is otherwise better you can enjoy all the well-deserved support you like. Otherwise, you should expect regulators to close you down.
Better idea: Give up on this stupid everything-as-to-be-on-the-Internet bullshit.
That's a good idea, but it doesn't solve the problem for devices that actually do have good reasons to be connected: streaming media players, IP-based phones/faxes, consoles with multiplayer games, and so on. Many of these devices are connected to household networks these days, both to access the Internet and to communicate for legitimate reasons with other devices also on that home network. The devices themselves or other devices on the home network may store sensitive data. They may also have sensors, and while cameras and microphones are the most obvious risks, less obvious things like accelerometers in mobile devices and GPS can also create huge security/privacy holes.
Sooner or later, we're going to have to confront the implications of connecting all of this stuff together, and we're going to need a more sophisticated strategy than "just don't do it", because a lot of the time doing it is very useful but also dangerous without proper limitations.
Getting a signed certificate for an embedded device may cost more than manufacturing the device... per year.
It's actually worse than that, because you don't even have a fixed target to price up. You have to consider how long a certificate needs to be valid for, the longer the more expensive but if it's not enough for the working lifetime of the device people are going to get upset. There's also the risk that a link in the certification chain could disappear, which is presumably more likely the longer the certificate lasts. For serious equipment running on corporate networks you might also have to consider letting them install their own certs backed by their own in-house CA, which introduces overheads of its own for your technical implementation. And none of this matters for devices that aren't going to be available from a machine with Internet access, because then there's no way to verify certs signed by the major public CAs anyway.
But the AC's basic point is sound. There are genuine concerns being raised here, but there's also a degree of FUD. If you see "10 year old Linux kernel" and assume "security flaw", you're the guy embedded software developers hate. That's not because they don't like criticism, it's because what really happens is they get a report back from some suit in the sales team saying a customer ran a "vulnerability scanner" and it flagged something based on a simple version check or other heuristic and that "vulnerability" must be fixed before you can get the sale. When they point out that patches have been applied for all known vulnerabilities that are relevant to their system and ask the sales guy what actual vulnerability the customer is concerned about, all they get back is crickets.
Then you get someone from management being told by the sales guy who just lost his commission that the engineering team is incompetent, and wanting to know how much it would cost to upgrade the entire system to the latest Linux kernel. Manage gets told by engineering leadership about the cost, the time required to do the work, the time required for a complete regression test, and the risk of some regressions slipping through anyway because you're giving up tried and tested code and maybe being forced to change fundamental things like what kind of filesystem you're using on your internal flash storage. Somewhere around the point where the half dozen guys who normally work on the firmware for that product now need six more guys whose only job is to watch for every relevant update to any software component in the system, integrate it, regression test the results, issue the firmware update, and brief sales and marketing because reading a changelog is too difficult, the manager usually loses interest. It's a huge amount of wasted time and effort all around, for something that in many cases was never actually a real problem in the first place.
ABS cant be broken into externally because it's not connected to your stereo.
The major security concern in this debate is whether essential vehicle control systems like ABS can in fact be influenced remotely, because they are connected to non-essential systems that (some of us are arguing) they shouldn't be.
Frankly, the existing systems are enough to scare me away from them, just for the privacy implications.
I share those concerns as well. I'm just trying to avoid conflating them with the security risks that pose a direct threat to life and limb.
But there are some very nice cars out there which don't have a navigation system built in
The trouble is, these remote functions are useful and they are seen as purely beneficial by people who don't yet understand the implications of the technology, which of course means most people who are going to buy a car. And so more and more cars, starting from the high end and pushing down over time, have this crazy stuff built into them.
I'm happy to see this campaign starting now, because hopefully by the time the technology is effectively mandatory at the price point where I want to buy a car, some degree of sanity will have been restored. I fear it may take a horrifically expensive lawsuit where the damages were multiplied up and maybe even some executives wind up facing jail time personally because the auto makers had been explicitly warned of the risks and failed to act on those warnings, though.
Fair point, but perhaps not the one you intended to make: my house has high-spec security doors and windows.:-)
No doubt someone sufficiently determined and well-equipped could still break through, and this is deliberate, because that person might be a paramedic or fireman trying to reach a child in an emergency. However, no casual burglar stands much chance of getting inside, and even a professional thief has poor odds of getting inside, collecting valuables, and getting away again before someone arrives to arrest them.
I suppose this is equivalent to saying you could still cause a car with properly secured modern electronic technologies to crash, but beyond a certain point it would become easier to do so by simply running the car off the road with a big truck than by cracking its wireless link. What is out there in car security today is sometimes more like trusting that I won't even need a working lock on my front door because no-one bad would ever try to open it.
As the old saying goes "It's not arrogance if you can back it up."
Which the overwhelming majority of them can't. That's kinda the point.
The culture in tech hubs today is in a very real sense based on gambling. VCs bet 7-8 figures on a company that might be the one to make 10 figure returns. It's a high variability strategy that rarely pays off, but pays out staggering amounts of money when it does. And because any VC always has a pool of investments on the go, they can stand to play the long game knowing their mean return is always going to be astronomical.
Many founder/entrepreneur types are playing the same game, just with fewer zeroes and one big shot at a time. Some will make it. Most will fail. Some of them will come back and try again. Many of them won't. It's just like the VCs, but a whole lot more personal, because VCs are the house that always wins, while first-time founders are more like the whales who bet it all on number 3.
Almost everyone else working at these businesses is just along for the ride, because the amount of money they're making is relatively good and they have a chance for a nice windfall if their employer's exit strategy does work out. Neither the founders nor the VCs much care because the salary and perks for decent technical staff are just table stakes in a much bigger game.
But you only have to look at the kind of recruitment processes and qualifications some of these big name SV firms advertise/leak, and then look at the quality of the software they actually produce and/or what some people who used to work there can (or can't) do when they move on, and you can see that having Google or Facebook on your resume doesn't actually prove that you're some sort of super-elite 10x genius geek demigod. Unfortunately, a significant proportion of the people working inside the bubble didn't get the memo.
I couldn't agree more. I was just challenging the idea that not using modern technologies at all was a viable solution to the problem. Some technologies do make cars safer, more reliable, and more efficient, and the important practical question is how we secure those technologies, not whether we should use them in the first place.
And in the winter, I'd love to be able to warm the engine and the interior from inside my house while I gather my things for work.
This is clearly a case of prioritising convenience over security, which you're welcome to do as your own personal preference but I would never choose myself.
This data is used to help triage the severity of the crash before the EMTs roll out.
Well that's probably the single most disturbing thing I've seen in this whole discussion. Are you really telling me that in the event of a known road traffic accident, which is severe enough that no-one on the scene can immediately respond to verbal contact, they don't routinely send the full works where you are?
In any case, I would point out that this is purely status reporting, i.e., read-only data. There is no need for anyone to control anything remotely in this situation.
Also, in extreme cases, the OnStar / Bluelink / et al. system can actively end a felon's joyride by cutting throttle, braking, or cutting the engine entirely. Then it can honk and flash the lights to attract the authorities' attention.
This is my main problem with the whole debate: any system that can do this kind of thing can also be used for less welcome purposes.
Car theft is essentially a solved problem without any remote control needed. Technologies like immobilisers have become so good that stealing the car keys has been the preferred technique for some time. Trackers, which need no integration with any control system, provide an effective deterrent and means for police to locate a vehicle that has literally been put on the back of a lorry.
Again, YMMV, but personally I would rather be careful about where I keep my keys than risk a hostile party, or simply a human error or software bug, doing something like cutting the engine and applying the brakes when I'm driving at high speed or through a hazardous area.
Slashdot Mirror
This isn't firefox specific, any software be it open or proprietary works the same way - the engineers must be able to recreate the problem themselves in order to fix it. There is no other option.
But there is another option for the users: they can use other software.
I sympathise with the frustrations of software developers, but the idea that any normal user (most of whom aren't going to be programmers or sysadmins themselves) is going to set up a virtual machine, reduce a bug they see down to a minimal test case, and then file a detailed bug report is crazy. It just isn't going to happen.
If a project has to keep relying on this, instead of being able to do good quality control and testing itself, the inevitable result is perpetually beta quality software, and getting left behind by other projects that are capable of doing proper quality control and testing.
This is all way off-topic by now, but my point is still the same: MojoKid's position is probably correct. There are significant costs for servers and for bandwidth for any site that scales up, and they can easily become more than it's reasonable to expect a hobbyist to pay out of their own pocket if the site becomes popular.
Of course, this is all before there is any actual content on the site! Doing the planning and research and writing and editing and presentation of original material takes about as much time and money on a web site as in any other medium.
You know somewhere that provides reliable hosting for five servers supplying 40MB/s each for less than 5-10 bucks? I doubt that very much. For the dedicated servers I use on one of the commercial sites I mentioned, I'd be running at over $1,000 per day for that kind of traffic.
Obviously no-one running at that kind of scale is still on the same kind of hardware and pricing set up that my little site is on, but dedicated/unmetered lines aren't cheap either. In any case, you get the point: the servers aren't the problem for high traffic sites, the network bandwidth is.
And ad blocking. Don't even get me started. So many ad blockers are so proud of what they do, like it's some badge of honor to block. If everyone blocked ads, many quality web sites would likely cease to exist, including Slashdot.
I suspect in reality that the best sites would continue, but there would be a lot more paywalls around, probably less editorial integrity on open sites as things like product placements and affiliate referral fees became more reliable revenue streams, and maybe over time we'd eventually get somewhere with micropayments. In some ways, moving to more "honest" funding via paywalls and/or micropayments might be a better long-term model for the people who do produce good content and run valuable sites than what we have today, though no doubt it would be a painful transition with many casualties.
The thing that makes me a little sad inside is that the aggressive, irresponsible advertisers have spoiled the model for the moderate, responsible ones. Because of the former group, I do block very aggressively when I'm browsing, and I don't feel any guilt about it because my motivations are security, privacy and performance. However, I also have no problem with people who just want to make a bit of money from running a decent site, and I wouldn't block their ads if there were a reliable way to allow those while still eliminating the rest. Unfortunately, I don't see that being possible any time soon, which is why none of the commercial sites I've ever run myself has relied on ads as a business model.
A domain is around 5-10 bucks and you can get hosting for less.
Sure you can. I've run various personal or social group sites over the years that just paid a little to keep things running, without expecting any sort of income in return. For the personal sites, I do it for the satisfaction of giving something back, and sometimes starting enjoyable discussions with others who share my interests.
I also run some commercial sites, aiming at a wider audience, charging real money for signing up. This is a completely different scale of commitment in terms of hardware, connectivity, and operating costs.
If you're running a discussion forum that you share with 50 friends, sure, it can be in the first category and you can do it for peanuts and enjoy all the high quality interaction you like. But running a significant news or social networking site with thousands of participants? Not even close.
I use POP3, so I can have local copies of all emails.
What I'd really like with modern trends is more emphasis on "private clouds". I want to put my data on my own server on my own network, so it can be accessed from any of my devices around the house and over VPN if I'm out, but with the data always securely under my control and backed up according to my wishes.
This is easy for some formats, including plain files obviously. However, it's surprisingly awkward for stuff like e-mail, where there are plenty of relevant concepts like IMAP and mail stores and smart hosts and web mail systems, but actually setting them up in a useful combination if you're not an experienced sysadmin is quite a challenge.
Sadly, it seems even the best FOSS client software is dying out these days, often because "everyone has Google Whatever". As far as I know there hasn't yet been a lot of movement in the FOSS world towards having easily-deployable private clouds for e-mail, shared documents, and so on, which always surprises me given the implicit freedom, independence, privacy and security.
You might not have much recourse even if it's a commercial service you're using. Ironically, on-line back-up services are among the worst offenders. If you use one, go ahead and check its terms, and see whether any of those lovely restoration options they offer will still be there if they decide to close down on a whim. (Hint: Probably they won't, and all you'll get is maybe 48 or 72 hours to download as much as you can at the same time as every other customer they have is trying to do the same.)
If it matters, back it up on systems you control yourself. If it's private, don't upload it to anything, and encrypt the back-ups. It's really that simple. Then again, so is "make sure you back up your important files", and how many people don't do that because it's mildly inconvenient? Maybe those on-line back-up services aren't quite so bad after all...
It takes very little effort to realize that the most useful and needed excuse to shut down cell phones by the police will be to prevent citizens from recording their behavior in the absence of police body cams.
Indeed, and yet I'm dozens of posts into this discussion before you were the first person I saw even notice. :-(
This could in theory be used to prevent something like a phone triggering a bomb, though if there is a genuine threat of something like that happening, I would think that restricting or turning off transmission over the network was a much more reliable method than assuming that someone willing to blow up a bomb was also obliging enough not to mod their phone to ignore the kill switch.
Meanwhile, it has now been demonstrated beyond any doubt that video recording of police officers at work reduces both complaints of excessive force against officers and instances of violence toward officers, both of which are surely good things. It has also been demonstrated on numerous occasions that officers who did cross the line may then attempt to destroy evidence such as photographs or recordings on electronic devices held by passers by. Obviously if all it takes is accessing some centralised police system with insufficient safeguards and oversight to remotely destroy that evidence, as opposed to potentially physically confronting someone who is just an innocent third party and making their situation worse, there is less deterrent to the minority of officers who do abuse their position.
Ah, I see. I had intended the IPS/DLP example to demonstrate both the fact that it was technically possible to MITM SSL traffic if you have control of the client and the fact that this is actually done in practice. I didn't mean to imply that routine logging was necessarily going on in any particular organisation; I don't expect that it is in most places, at least not intentionally, for all the reasons we've talked about. Apologies if that wasn't clear.
Thanks for the courteous dialogue!!
Likewise.
You can post credentials as much as you like. I've worked in the industry, and I know who some of the big customers are. (Given your background and the nature of the discussion, I hope you'll take my word for that and understand why I'm not going to post a list similar to yours here.)
I said before but will repeat: your liability concerns are fair and valid. In fact, there is a significant side market in devices that can pick out parts of the network traffic that might be sensitive one way or another and mask out or truncate the unwanted details, and that market is driven in party by exactly the kinds of liability concerns you mentioned.
The fact remains that from a technical point of view, if corporate IT want to log your traffic and if you're working on a company machine and talking over the company network, there are tools available that will do that for them and you would never know it was happening without inside information. Everything else is down to legal issues and how much you trust your employer to behave responsibly.
I get the feeling that we would agree about the fundamental ethics of the situation anyway. This little discussion started when BitZtream argued that a good sysadmin can control "what his company does and doesn't see on company time, company equipment, and company networks". Zero__Kelvin seemed to think SSL would be a barrier to that. It is not.
Just to be clear, I'm not talking about small companies. IME, the smaller companies I've worked with have been far less likely to do this kind of thing, because the level of trust is greater when "everyone knows everyone".
The liability issue you raise with regulated external sites is a fair point, and so are your comments about internal segregation in some contexts. However, please remember that not everywhere has the same legal rules and precedents as the US.
This whole field is rather young to make too many general claims about what is and isn't considered acceptable, particularly if an employee has been explicitly told that company equipment and networks are monitored and use may be recorded. How much employees should be explicitly warned about -- for example, whether this kind of SSL-defeating technique should be highlighted even if you're already saying you might read communications -- is something of an open question at least ethically and possibly legally as well. Heck, workplace surveillance generally is a very two-sided issue, and even where the law is relatively settled already, it can be a source of serious problems and disagreements.
But the general principle we were discussing was that sysadmins can have a lot of control about what happens on company networks, and that stands. Even if, for legal, moral or ethical reasons, an organisation chooses not to log the content of things like IM and e-mail communications, the technical tools to do so exist right now. And while you (and I, for the record) might choose to avoid working for an employer who we knew to use such monitoring, the reality is that unless you actually work in their IT department, you're never going to be able to determine reliably what is actually being done and it's all a matter of trust.
As I said, IPS and DLP devices are routinely used to MITM SSL connections. There's not much point having some stupidly expensive firewall setup at the edge of your corporate network if all its takes for malware to get in is Joe from Accounts opening his GMail and running cute_kitty_photoz.exe.
Typically, the volume of data transmitted through these kinds of links makes comprehensive long-term recording and storage prohibitively expensive. However, logging everything normally sent over plain-text, human-speed communications channels such as e-mail or IM is quite achievable, as is logging a complete traffic stream identified by some trigger.
Incidentally, these devices are often used precisely because they allow you to control and limit your liability. For example, it's easier to argue you're in compliance with regulations like HIPAA or PCI-DSS if you can demonstrate reliably that traffic leaving your network was scanned and nothing fitting certain suspicious patterns was sent. A simpler but no less significant consideration is the damage any large organisation could suffer if malware did somehow get into their network.
They don't have to block SSL, they just have to MITM the connection if they need to analyse or log the traffic. IPS and DLP devices that can do this for all the major protocols have been available to professional sysadmins for some time. If you access the Internet from a company device at an organisation that is either very large or working in a particularly sensitive field, there is a good chance your traffic is already being processed in this way.
If you want some communications to be private from your employer, use your own device, not a company-administered one. It's really as simple as that these days.
Conditions of entry don't have any effect on copyright law, as far as I know.
Not by default, but I know of no legal reason an admission contract couldn't include a clause transferring copyright in any recordings made to the organisers.
... under UK Copyright law there is no "fair use" exception
That is correct. There are some specific exceptions, commonly referred to as "fair dealing" over here, and there have been some recent developments that will expand the scope of the exceptions, but there is no generic limitation on copyright determined by a set of qualitative tests like the Fair Use rules in the US. However, if we're talking about someone's own footage of the goals, the more important issue might be what the contract was when they bought their admission ticket.
If the conditions of entry clearly say no recording is allowed and that if any recordings are made anyway then all rights are assigned to the organisers, then my expectation is that the uploaders won't have a leg to stand on here. It would be very surprising in this day and age if such terms weren't routinely included, and I fully expect that this is how any debate about legality will wind up being resolved.
On the other hand, if there's nothing prohibiting the use of recording devices and nothing claiming any rights over recordings made by spectators, it might be tough to argue successfully in court along the lines that someone's personal recording was a copy or derivative work of some official recording that the organisers sell to TV networks. It's not an unprecedented idea: publishing photos of major public landmarks like the Hollywood sign or Eiffel Tower can be legally hazardous, particularly if commercial use is involved. However, those restrictions tend to result from some carefully contrived/created edge cases in the legal position for specific places, and it's hard to see how anything similar applies to a football match.
(IANAL so obviously you shouldn't trust anything you just read if it actually matters to you.)
You seem to be conflating several issues, as well as setting up some straw men, neither of which encourages constructive debate.
One issue is statutory licensing, which may artificially limit the number of people who can drive for-hire vehicles in a given area. It is true that such regimes are vulnerable to local politics and regulatory capture, pushing expenses up for drivers and reducing competition. There are also some arguments in favour of reasonable licensing regimes, not least because there is only so much road space and so much demand for hire vehicles. There is certainly room for debate about how this side of the industry works and whether newer alternative models might be better.
Another issue is safety regulations, which typically restrict things like permitted time behind the wheel without a break or how often vehicles must be maintained and tested. This is quite a different thing from licensing to limit supply in the market, though clearly some method of identifying who is subject to the safety regulations is needed. Here it is common, at least in my country, for professional drivers who spend many hours behind the wheel to be regulated. For example, lorry drivers and coach drivers also have to comply with regulations that don't apply to individuals driving private vehicles for their own purposes. Here, there is much less room for debate. Normal people don't spend the equivalent of an entire working day behind the wheel, day in and day out, with relatively little to keep their attention focused on driving. Even when private individuals make long journeys by car, they rarely spend as long behind the wheel as lorry drivers do daily. And of course the service and mandatory testing intervals for private cars are set with private driving in mind, while vehicles used commercially tend to do much higher mileage.
As a third related issue there is insurance. It is a legal requirement in my country for every driver to have proper insurance to certain minimum standards. Note that this is primarily for the protection of others: as far as I know, you can still drive a personal car without insurance to cover wrapping it around a tree and writing it off, but you may not legally drive it without "third party" insurance that would cover any damage you do if you wrap it around someone else's car and write off both vehicles. Insurance policies typically specify things like the type of vehicle and how it will be used and are priced accordingly, and the insurance industry probably has a better understand of the true risks of different types of driving than anyone else. So letting people drive commercially when their insurance doesn't cover it would just be a loophole and a clear risk to other road users who won't be protected as the law requires in the event of an accident.
I don't think the people who question services like Uber on regulatory grounds are necessarily against competition or innovation in the marketplace. I'm certainly not; I write software every day for businesses that do stuff no-one has done before that is only possible because of that software, so why would I want to hold back progress? But some of those regulations really are there for good, sensible, practical reasons, and I don't think a new entrant into the market should get a free pass on breaking the rules that apply to everyone else just because they're new.
This is not one of those things where you need to "compromise" so that some people are disadvantaged SO THAT another group may be disadvantaged.
Unless you're the person in the lane next to the Uber car when its high-mileage, improperly-maintained components break, or the person crossing the road in front when the Uber driver falls asleep, and then you get to be in the accident too.
Regulations on commercial drivers exist for a reason, and it's not just for the benefit of the passengers inside a commercial vehicle.
Providing an alternative that is competitive merely by virtue of not following the same rules as everyone else isn't an improvement. Compete on the same basis as everyone else, and then if your service is otherwise better you can enjoy all the well-deserved support you like. Otherwise, you should expect regulators to close you down.
Better idea: Give up on this stupid everything-as-to-be-on-the-Internet bullshit.
That's a good idea, but it doesn't solve the problem for devices that actually do have good reasons to be connected: streaming media players, IP-based phones/faxes, consoles with multiplayer games, and so on. Many of these devices are connected to household networks these days, both to access the Internet and to communicate for legitimate reasons with other devices also on that home network. The devices themselves or other devices on the home network may store sensitive data. They may also have sensors, and while cameras and microphones are the most obvious risks, less obvious things like accelerometers in mobile devices and GPS can also create huge security/privacy holes.
Sooner or later, we're going to have to confront the implications of connecting all of this stuff together, and we're going to need a more sophisticated strategy than "just don't do it", because a lot of the time doing it is very useful but also dangerous without proper limitations.
Getting a signed certificate for an embedded device may cost more than manufacturing the device... per year.
It's actually worse than that, because you don't even have a fixed target to price up. You have to consider how long a certificate needs to be valid for, the longer the more expensive but if it's not enough for the working lifetime of the device people are going to get upset. There's also the risk that a link in the certification chain could disappear, which is presumably more likely the longer the certificate lasts. For serious equipment running on corporate networks you might also have to consider letting them install their own certs backed by their own in-house CA, which introduces overheads of its own for your technical implementation. And none of this matters for devices that aren't going to be available from a machine with Internet access, because then there's no way to verify certs signed by the major public CAs anyway.
But the AC's basic point is sound. There are genuine concerns being raised here, but there's also a degree of FUD. If you see "10 year old Linux kernel" and assume "security flaw", you're the guy embedded software developers hate. That's not because they don't like criticism, it's because what really happens is they get a report back from some suit in the sales team saying a customer ran a "vulnerability scanner" and it flagged something based on a simple version check or other heuristic and that "vulnerability" must be fixed before you can get the sale. When they point out that patches have been applied for all known vulnerabilities that are relevant to their system and ask the sales guy what actual vulnerability the customer is concerned about, all they get back is crickets.
Then you get someone from management being told by the sales guy who just lost his commission that the engineering team is incompetent, and wanting to know how much it would cost to upgrade the entire system to the latest Linux kernel. Manage gets told by engineering leadership about the cost, the time required to do the work, the time required for a complete regression test, and the risk of some regressions slipping through anyway because you're giving up tried and tested code and maybe being forced to change fundamental things like what kind of filesystem you're using on your internal flash storage. Somewhere around the point where the half dozen guys who normally work on the firmware for that product now need six more guys whose only job is to watch for every relevant update to any software component in the system, integrate it, regression test the results, issue the firmware update, and brief sales and marketing because reading a changelog is too difficult, the manager usually loses interest. It's a huge amount of wasted time and effort all around, for something that in many cases was never actually a real problem in the first place.
ABS cant be broken into externally because it's not connected to your stereo.
The major security concern in this debate is whether essential vehicle control systems like ABS can in fact be influenced remotely, because they are connected to non-essential systems that (some of us are arguing) they shouldn't be.
Frankly, the existing systems are enough to scare me away from them, just for the privacy implications.
I share those concerns as well. I'm just trying to avoid conflating them with the security risks that pose a direct threat to life and limb.
But there are some very nice cars out there which don't have a navigation system built in
The trouble is, these remote functions are useful and they are seen as purely beneficial by people who don't yet understand the implications of the technology, which of course means most people who are going to buy a car. And so more and more cars, starting from the high end and pushing down over time, have this crazy stuff built into them.
I'm happy to see this campaign starting now, because hopefully by the time the technology is effectively mandatory at the price point where I want to buy a car, some degree of sanity will have been restored. I fear it may take a horrifically expensive lawsuit where the damages were multiplied up and maybe even some executives wind up facing jail time personally because the auto makers had been explicitly warned of the risks and failed to act on those warnings, though.
Fair point, but perhaps not the one you intended to make: my house has high-spec security doors and windows. :-)
No doubt someone sufficiently determined and well-equipped could still break through, and this is deliberate, because that person might be a paramedic or fireman trying to reach a child in an emergency. However, no casual burglar stands much chance of getting inside, and even a professional thief has poor odds of getting inside, collecting valuables, and getting away again before someone arrives to arrest them.
I suppose this is equivalent to saying you could still cause a car with properly secured modern electronic technologies to crash, but beyond a certain point it would become easier to do so by simply running the car off the road with a big truck than by cracking its wireless link. What is out there in car security today is sometimes more like trusting that I won't even need a working lock on my front door because no-one bad would ever try to open it.
As the old saying goes "It's not arrogance if you can back it up."
Which the overwhelming majority of them can't. That's kinda the point.
The culture in tech hubs today is in a very real sense based on gambling. VCs bet 7-8 figures on a company that might be the one to make 10 figure returns. It's a high variability strategy that rarely pays off, but pays out staggering amounts of money when it does. And because any VC always has a pool of investments on the go, they can stand to play the long game knowing their mean return is always going to be astronomical.
Many founder/entrepreneur types are playing the same game, just with fewer zeroes and one big shot at a time. Some will make it. Most will fail. Some of them will come back and try again. Many of them won't. It's just like the VCs, but a whole lot more personal, because VCs are the house that always wins, while first-time founders are more like the whales who bet it all on number 3.
Almost everyone else working at these businesses is just along for the ride, because the amount of money they're making is relatively good and they have a chance for a nice windfall if their employer's exit strategy does work out. Neither the founders nor the VCs much care because the salary and perks for decent technical staff are just table stakes in a much bigger game.
But you only have to look at the kind of recruitment processes and qualifications some of these big name SV firms advertise/leak, and then look at the quality of the software they actually produce and/or what some people who used to work there can (or can't) do when they move on, and you can see that having Google or Facebook on your resume doesn't actually prove that you're some sort of super-elite 10x genius geek demigod. Unfortunately, a significant proportion of the people working inside the bubble didn't get the memo.
I couldn't agree more. I was just challenging the idea that not using modern technologies at all was a viable solution to the problem. Some technologies do make cars safer, more reliable, and more efficient, and the important practical question is how we secure those technologies, not whether we should use them in the first place.
And in the winter, I'd love to be able to warm the engine and the interior from inside my house while I gather my things for work.
This is clearly a case of prioritising convenience over security, which you're welcome to do as your own personal preference but I would never choose myself.
This data is used to help triage the severity of the crash before the EMTs roll out.
Well that's probably the single most disturbing thing I've seen in this whole discussion. Are you really telling me that in the event of a known road traffic accident, which is severe enough that no-one on the scene can immediately respond to verbal contact, they don't routinely send the full works where you are?
In any case, I would point out that this is purely status reporting, i.e., read-only data. There is no need for anyone to control anything remotely in this situation.
Also, in extreme cases, the OnStar / Bluelink / et al. system can actively end a felon's joyride by cutting throttle, braking, or cutting the engine entirely. Then it can honk and flash the lights to attract the authorities' attention.
This is my main problem with the whole debate: any system that can do this kind of thing can also be used for less welcome purposes.
Car theft is essentially a solved problem without any remote control needed. Technologies like immobilisers have become so good that stealing the car keys has been the preferred technique for some time. Trackers, which need no integration with any control system, provide an effective deterrent and means for police to locate a vehicle that has literally been put on the back of a lorry.
Again, YMMV, but personally I would rather be careful about where I keep my keys than risk a hostile party, or simply a human error or software bug, doing something like cutting the engine and applying the brakes when I'm driving at high speed or through a hazardous area.