Hopefully (though doubtfully) the OEMs will be eating a lot of warranty returns. It is only if this costs the OEMs money that the problems will be fixed.
Such warranty return are mandatory for the OEM to accept in Europe, at least 24 months (I think, it might by 36) and given how recent this IoT craze is, most devices still qualify for such returns.
The cost might not get all the way to the cheap-ass chinese no-name manufacturer who did actually commit a device with such atrocious security. But the cost won't burden the end user, it would at least be a problem for the brand that decided to have their device manufactured, without exerting the necessary caution regarding security. If you're ready to import the device and stick your branding on it, you need to be held responsible for its security.
Depends on the jurisdiction but in Europe companies are required to cover warranty for quite a significant period of time (at least 24 months in this case. It might even be 36 months but I'm too lazy to google. Anyway given how recent this IoT craze is, most of the devices are definitely more recent than their warranty period and thus of course still covered)
The constructor *HAS* to replace such bricked devices through warranty, with the user only bearing the cost of sending the bricked device and the manufacturer covering the cost of the new replacement and shipping that back to the user. (During the first few months the shop that did sell the device can even handle the replacement themselve and ship the defective through their own channels. The user will become the replacement immediately and 100% for free).
So there is *definitely a strong economic incentive* to make the device secure. If the device is vulnerable, it is going to cost a lot due to warranty replacement and shipping.
(And as pointed by others: if the replacements keep getting broken again, consumer will switch brands)
and after you factor everything (including battery manufacture), only China and a few others (India, Australia) end up having similar emission between both types of car.
On every other country, it range from "a bit better" (like in the US - where fossils are still burned for power generation, but efficiency is better as suggested by parent poster) to "really definitely better" (like TFA's Norway or Switzerland, etc. - where power generation emits very little pollution, thanks to [alpine/cold climate] hydro, etc.)
*sigh*. Electric cars cause emissions- they're just externalized at the generating station.
Which usually given the electricity generation available in the country, tends to be much more efficient than the ICE in a car. (with a few exception like China, India and Australia - according to source which are easy to Google, but I'm too lazy to find yet again for the nth argument about the same subject).
Yes, the US burns fossils to create electricity, but over the life time of a car, even taking into account the initial manufacture (a battery is more complex to build), an electrical car in the US still causes less emissions than a gaz-powered one.
In TFA's Norway, electricity comes mainly from hydro. And even if it's not an Alpine region, the climate is more or less comparable and thus hydro has a very tiny output of green-house gazes and other pollution.
Electricity is *definitely* cleaner there.
You need to travel to a country that produce most of its electricity by burning coal (like China) to find a situation where there isn't much difference between an ICE car and an electric one.
(And in that last situation: well if China adds more clean energy production to its power offering, all the electric car suddenly get better emissions as a consequence. Whereas all the ICE cars would need an engine swap to suddenly have better).
In that case, then what's the point of using Bitcoin?
The point of bitcoin (the protocol), is that it is distributed. There's (theoretically) no central authority. Any two endpoint can exchange currency (usually BTC) as long as they both follow the protocol.
(anonymity was never a point. And goes against the way bitcoin works as every single (full) node on the network needs a local copy of the whole ledger to be useful. So ever node gets to see every transaction ever done).
You can run a perfectly functional digital economy with yen or any other real currency.
Yeah, and how do you send those yens around ? Say you want to send me 1'000¥. You'll need to use some system like PayPal (where we need to both have an account) and further down the line you'll need a credit card (so you'll need to also have a card at MasterCard or VISA). So for our transfer to work, there are a couple of companies (PayPal, MasterCard, etc.) that have central authority over any transaction we attempt. They could even block us (that actually hapenned to WikiLeaks and was part of the reasons bitcoin got popular).
As opposed to the bitcoin protocol : - you could be using anything - e.g.: local bitcoin to buy a faction of BTC for some ¥s in your local market. or e.g.: use some exchange platform (whatever has currently replaced MtGOX and BTC-e) - I could be using some coin processor to convert them to real money (e.g.: BitPay or Coinbase) or simply store them into my local wallet (e.g.: Bitcoin Classic)
As long as the end-point we each chose follows the protocol, the transaction can happen. There's no single central "Bitcoin Inc." that could control the transaction (massive mining pools aside) and freeze your account. There's no single BTCcard that we all must obtain in order to do the trasaction.
And unlike PayPal, nobody can block donations to wikileaks.
The closest to this type of freedom of choice is european payment system like SEPA. As long as your and my bank follow this system, we can send money accross accounts.
This makes me wonder why we have not moved back to a Harvard architecture {...} Having separate data and code spaces would stop this line of attack cold.
The problem is that the vast amount of modern thing isn't code that is executed as-is on the CPU, the vast majority of modern apps are written in some high-level extremely abstract language that gets interpreted.
(That includes executable script portion on most web pages and macros embed in nearly every modern format - including docx - with maybe the exception of a few plain boring image formats)
So either you end up with code running in code space that reacts and changes behaviour (interprets scripts) based on data located in the data space. Or you need to consider nearly everything as code, including.docx files, and only consider data a few. Like the README file and... huh... that's about it.
(For fuck's sake, even some text/image formats like Post-Script are turing complete).
They aren't as much *late* as *not member of any large app eco-system*.
There's a really strong networking effect. People want to use smartphone also for the app featured
It's a catch-22 : nobody is going to write application for Windows 10 Mobile because there aren't as many user as Android and iOS, and nobody is going to use Windows 10 Mobile because there aren't as many apps on it.
Microsoft *was* aware of the problem. They *did* want to find a way to run android apps on Windows 10 mobile phone. But that's an extremely difficult task when you're not even running a Linux kernel. The only thing that came out of thes failed experiment is WSL (Windows Service Linux - a minimalistic Linux API layer that the NT kernel can expose in addition to Win32 etc. and that enables you to run a few unmodified Ubuntu console applications directly under Windows 10).
We'll see how it goes with Ubuntu. Canonical has toyed with the idea of running android apps.
Meanwhile Jolla's Sailfish OS isn't doing that bad, because it's designed on purpose to run android apps in addition to native QML apps. (Official commercial version feature aliendalvik, community version relies on sfdroid). So their users aren't left in the dust.
just rip off any other successful app and cha ching!
The problem is that the features aren't the only reason SnapChat is successful. It's not like the kids are there only for the emoji-stickers, face-tracking "doggy-face" filters, and "don't over-think you posts, it's for ephemeral consumption" agument... (Though these are part of the reason why Snapchat started to get popular).
Now there's also a set of network and anti-network effect into play.
The kids are currently flocking to Snapchat because that where all their friends are already on. And the kids are also flocking to Snapchat because it's explicitely NOT facebook, i.e.: it's *NOT* where their parents are, and neither the teachers, nor all the other people they with whom they don't want to be on the same network and in front of which they don't want to be embarrassed.
i.e.: At the current point of time, Snapchat not being Facebook IS one of the main reason of it's popularity.
Thus: - Facebook trying to acquire Snapchat to avoid getting over-taken by it (like they've done in the past with Instagram, WhatsApp and any other popular platform) was their only hope, but they didn't manage to catch that boat. - Facebook trying to integrate Snap-like features in their offering is not going to help them much. It's going to help them retain some of their current (ageing) user base. (Those who are already there and might be interested in the features : I've seen it on Instagram). But it's not going to help re-capture the current "new generation", those are already building their network elsewhere.
For once, Zuckerberg is at the receiving edge of the network effect.
Giving a dead serious response to an obvious joke, but...
How about caramel, or blueberries, or carrots, or ketchup, or seafood.....
The tongue is an extremely limited organ in sensing capacity. Basically it can detect sweet (presence of small molecule with a surface vaguely shaped like glucose), salt (basiclly "there are ions here"), acid/sour (simplistic pH) and umame (detects if there are animo acids in the mix). that's about it. and due to their function "satly" (basically a ion flux) and "pH" (bascially a specialised ion flux) are the easiest to simulate with electrodes (cause a flux of electricity, i.e.: ions when in a liquid medium like saliva), so that's why they went for "shitty cheap lemonade" (basically citric acid/citrate sodium with some tasteless yellow dye) instead of anything else more complex.
The organ which is responsible to detect that caramel is in fact caramel and not only sweet with a touch of salty is the nose. (In addition of sampling air as it goes by (= sense of smell), the nose can sample small molecule that are present inside the mouth cavity and diffuse to the nose thorugh the back or over the humid surface (= sense of taste, complementing what the tongue is doing). There are a huge amount of different receptors, enabling you nose to detects the shape of an incredible amount of different small molecules (usually some fatty acids, but lots of others too).
To create a realistic simulation of blueberry flavor you'll need to stimulate all the various receptors inside the nose that detects shapes present on the various volatile component found in blueblerries. (Which is incidently what the food industry is also trying : find a few dead cheap stuff, that stimulates the nose in the right way to make you things you're tasting which has spent time growing on plant being taken care of, instead of tasting whatever was the cheapest compatible chemical)
In theory, there's no fundamental technological reason why it shouldn't work, given a sufficiently fine electrode matrix, that can pinpoint the various chemical receptors precisely enough (it's "just" an engineering problem). (There's no new hidden tech to be discovered in doing it).
In practice, it's going to be extremely complex just to build and test the appropriate electrode array. It's going to cost a lot, not bring anything new to research, and not do anything that can't already be done much cheaper and simpler by blowing the correct dosage of small chemicals into the nose.
And over all, TFA is also a measure of the gullibility of the brain : giving a liquid that is more or less the correct colour (yellow. done by LEDs here or by adding color dyes in the industry) and vaguely stimulates the taste buds in the right way (salty acidic) and the person will be fooled into thinking that they are drinking lemonades made out of actual lemons. (Which is incidently, again, what the food industry is doing, but with chemicals instead of electronics. Can't get the blueberry mix precise enough ? Well... add some deep blue/purple paint, make sure it's sweat and a bit acidic and you're goign to fool enough gullible customers. Some of them have never even seen an actual blue berry anyway, they won't notice).
wouldn't an I-Pad packed with explosives stick out on an x-ray like a sore thumb?
Have you already had a look on say x-ray image of a tablet or smartphone ?
A very big part of the volume is occupied by the battery (intentionnally bigger to store as much power as possible), with extremly tiny electronic components and board push to the edge around it (intentionnally small, to use low-power components).
In theory it should be very easy to replace the battery (on an X-ray it's just a big slab of homogenous-looking chemical) with another similarly looking slab of explosive chemicals... i mean, intentionally explosive chemincals (lithium is also explosive, but that is not its intended main use, no matter what was happeinning to Samsung smartphones, "Hoverboard" hands-free segway-like and old Sony laptop batteries). A bomb-containing or battery containing tablet will look the same on X-rays.
In practice, a tablet isn't big : you can't pack that much destructive energy in such a small form-factor. For enough destructive power, you would probably need to go for a volume that ends-up looking similar to a laptop's battery. (if you think about it, lithium batteries are already about packing as much energy as possible inside a device).
No, but it IS the filesystems fault for corrupting itself no?
File systems with a lesser tendency to corrupt themselves : file systems that do not over-write themselves.
such as Copy-on-Write filesystems (Btrfs, Zfs, etc.) and Log-structured filesystems (F2FS, UDF, etc.)
according to source, APFS is also going to be copy-on-write, making it similarly more resilient to corruption.
(if system crashes or loses power mid-write, you don't end-up with a corrupted file system. You end up with the previous version of the filesystem, plus new copies of data that may or may not be corrupted. For those copies which are corrupted, you can trivially revert to previous copy)
In other words, it functions the same way as copy-on-write filesystems such as Btrfs and ZFS, or log-structured filesystems such a various flash-oriented systems (F2FS and the likes) or as the venerable UDF.
Or thank you apple for finally having a filesystem that is not decades out-dated, but finally joining the club of other modern Unices.
I am just wondering why they needed to re-invent their own wheel, instead of opting for re-using ZFS.
That's why some browsers like Firefox checks it for you and display it right in the URL bar. You can't miss it.
What you really need is the domain registrars to check that if sites are being registered that are similar to a company name or trademark that they have a legitimate right to use that name.
The problem with "check that if sites are being registered that are similar to a company name or trademark" is that it's a complex task require some thinking that it's not trivial to automate for absolutely free (and in a way that won't be trivially circumvented by attackers). It goes beyond the point of Let's Encrypt (whose point is, as the name indicate, just to make encryption available).
Or build a chain-of-trust system where people can blacklist a bad domain by voting it down
Which isn't an easy task to do (how many - outside of/. - to use PGP on a regular basis ?) Chain-of-trust system aren't easy.
Blacklist aren't silver bullet neither : an attacker could still bank on a quick attack trying to scam as many users as possible before getting flagged. (See all the "software to make a millionaire out of you on binary option sites !" scam that are popping every where. Site costs under a couple of hundred in stock-photos / fiverr actors / ads promotion to set up, and can manage to make a few thousands selling snake oil before getting reported and shut down).
Neither of them have anything to do with HTTPS.
Which brings us back to the point : Let's Encrypt's purpose, as it names implies, is to bring the S in HTTPS and nothing more. It's not their job solving the certification of owner in an easy way.
In other words, the business model of Let's Encrypt is to sell digital certificates that aren't worth the electrons they are printed on.
Let's encrypt is a free (price as-in-beer, code as-in-speech) service. They don't have a business model.
They have a purpose (the same as CACert, by the way), to issue simple certificates that can verify that "blah.com" is indeed "blah.com". (As opposed to some man-in-the-middle attacker mascarading as "blah.com" using a different 3rd server).
They do not certify any thing else, and indeed the certificates' fields. This certificate doesn't certify any organisation name.
This is even reflected in some browser's URL bar. e.g.: in Mozilla's Firefox.
- Go to a "let's encrypt" website (like here on/. ) or one certified by CACert : you only get the green padlock (sign that the communication is encrypted) and no other indication. let's encrypt only checked that slashdot.org is indeed slashdot.org, but didn't check anything regarding ownership. (it might as well be someone trying to impersonate Slash, DJ Slash or Fat Boy Slim)
- Go to paypal : in addition to the padlock, you get an indication that certificate is certifying that the server is owned by PayPal Inc. (Symantec actually checked that PayPal Inc is indeed own
Issuing a certificate to BobsCarRepair.com is one thing. Obviously you have no way of knowing whether or not Bob is a reputable business.
Even further : it doesn't even certify that owner of the website is someone called bob. It only certifies you that it is indeed bobscarrepair.com It might as well be owned by Alice, for what you know. It only certifies that Eve isn't wiretapping you when you give your credit card number to buy parts.
However, Issuing 14,000+ certificates that contain the word PayPal, to domains not owned by the real PayPal, is incompetence on a massive scale and calls into question Let's Encrypt's honesty and trustworthiness.
Nope. There's a difference between guaranteeing a secure channel (against 3rd party eaves dropping). And guaranteeing identity. is These are 2 different concepts. Let's encrypt only takes care of the first one and has never ever hoped to tackle the second problem. They DO NOT certify owners, this field is intently left blank on their certificates.
The point of Let's Encrypt (as its name says) is that encryption becomes the norm on the web. In order to avoid massively stupid blunders, like the dead easy identity theft demonstrated by FireSheep.
That's something that CAN BE achieved for free, on a massive scale, like Let's Encrypt and CACert are doing.
There's no realistic way that let's encrypt could in any way confirm owner identity for free on this massive scale.
That's something which is very easy to understand for people who have some basic knowledge of security.
Saddly, sheeple are stupid. So you need to educate them and try to find ways to make them understand. (e.g.: the above mentionned "show certified owner in the URL bar if provided" that Firefox is doing).
But sapping efforts like "Let's Encrypt" which are providing very valuable service (bringing the availability of HTTPS, TLS/SSL, etc. on a massice scale), simply because some idiot can't make the difference between "protection against 3rd party eavesdrop" and "identity of the owner" is counter-productive
I suggest you read up on what sudo is capable off. You can easily setup sudo via its configuration file (/etc/sudoers) that will allow users that require elevated privileges (eg. Database and Web Administrators) to do their work without needing root access.
The parent poster was referring to a different approach to security.
with sudo, you set up a list of commands that a database or web admin can run. you limit user access by restricting which commands the user can run. But said commands will be run with root privileges. In case of a bug in the command, you could use it for privileges escalations (*you* were only restricted to run this command. but *this command* runs as root and could do anything).
what the parent refers to is more closely related to the various "CAP_*" capabilities used in the linux kernel. i.e.: even if you run a command as root, that command would never, even in the case of a bug, reconfigure the network interface, because the corresponding CAP_{blah} capability isn't enabled. By carefully crafting a very precise set of capabilities that you hand out to administrative programs, you make sure that they only do what they are supposed to do, even if an attacker manage to find a way to force a program running as root to do arbitrary actions.
(It's a bit similar like how some smartphone apps come with a whitelist of API calls that you need to validate before installing : "can access your contacts list", "can access your webcam", etc. Even if the weather app get hacked, it can never be used to spy on you, because it's not whitelisted to access your mic and your cam... Well except that nowadays every single last app seems to be obliged to ask access for nearly anything (Hey, now your Weather app can automatically recognise the city you're travelling into simply by flashing the QR code of your travel ticket ! Needs cam privileges !). Under Linux the same granularity exists, except that this done at the kernel API level, instead of the Java user libraries like on Android)
In the past few years Windows has been implementing similar restrictions. That's what the poster was referring to.
On Linux, the facility to apply this king of control exist in the kernel too (the various capabilities). But there aren't many software using them. I only know of SELinux and AppArmor. And they are not used system-wide, but only to put specific software into cages (those software for which they have rulesets).
I think this is dues to the fact that the basic user/group access rights of Unix can provide already quite some security if you take the time to organise enough granularity in your groups and memberships, instead of making everything restricted to root-only and needing thus to be root for nearly any action.
(Because of the Unix philosophy, lots of things are represented in unix as files. Therefore, lots of the actions controlled by capability can be mapped to file accesses (e.g.: to device files in/dev/ ). Putting correct group access on files can acheive the same results. e.g.: a virtual machine might need USB passthrough. One way would be to grant the corresponding capability to it. The way VirtualBox does it, is that it runs as "vbox" goup, and there's a script that hands out USB devices nodes with that as group access)
In practice, distributions such as Debian have been using tons of specific groups to control access to specific resources precisely, years before SELinux was a thing.
on Linux you need to suid yourself to root to do just about anything,
...said the guy who used to run Windows XP. You know, this OS where the user has admin rights by default, so even normal everyday tasks are done with admin privileges.
There are tons of advantage of IPv6 over IPv4. One of them being a vast supply of addresses (128bits vs. the overcrowded 32bits of IPv4). It's auto-configured (you just plug a device into a network and it automatically gets IPv6 working. Routers directly hand out prefixes, no need to organise stuff through DHCP. In IPv6 DHCPv6 is only used to hand out configuration options) Every device gets a single address that is routable anywhere on the internet. (No need of NATs, masquarading, and private address ranges).
People still can go to Google with IPv4, so no reason there.
...for now. As IPv4 address space gets depleted you'll soon reach the point where some machine are only IPv6 addressable, and thus some servers can only be accessed over IPv6.
They would need to invest and that is never a nice thing to do. They need to replace a lot of hardware or at least reconfigure it and that will cost money.
Nope. The whole point of technologies like 6rd is that you deploy IPv6 as a tunnel over the IPv4 infrastructure that you already have. No new hardware needed (beside the tunnel server), specially not needing to replace the thousands of expensive routers scattered accross the city that you cover with your services.
As a business I would also be against it. I hope I am wrong and somebody can tell me a lot of advantages that would make them money, save them money or a combination of both.
That the problem with IPv6. There isn't a simply clear immediate money benefit. The benefit isn't ultra-short term. The benefits are instead long-term : IPv4 is an old technology that is slowly reaching its limits (e.g.: number of available addresses) and that requires more and more layers to circumvent (e.g.: NAT to get around addresses limitation. e.g.: using relay servers on the cloud instead of devices talking p2p with each other, etc.) From a technological point of view, we are running straight against a wall. But ISPs are complaining that they are not going make tons of money immediately by switching to IPv6 so they stay on course headed for the wall collision.
You won't be required to use cloud service for every single small thing you need to talk to. (security cameras, weather station, talking toy, etc.), instead you can trivially access any gizmo directly over the web simply by opening it in your router/firewall.
IPv4 remote access : you need to sign up an account at their service. You gizmo and the app on your smartphone are constantly talking to this server. This makes a big central failure point : the company server can get hacked, leading to thousands of account information leaking (see HaveIBeenPwnd for your weekly example), or if the device is insecure that's a single point from which to attack all devices. Also if the company goes belly up and the server is shut down, your gizmo becomes an expensive brick. And these kind of server still costs a little bit of money, so either you're going to need to pay for the service. Or you're going to get ads-bombed as shit.
IPv6 remote access : you need to open a port (or a whole device) in *your* router. Your smartphone app is directly talking to your gizmo without any 3rd party getting involved. There's no big server with a treasure trove of personal data to leak. If attackers want to hack an insecure gizmo, they need to find them one by one on the web. Even if the company fails, you can still use your app to talk to the device, you don't rely on a 3rd party server. There are no server costs to cover.
(Previously, similar things would have required fiddling with NAT, port forwarding and other such remapping to get done on IPv4. Trivial for most/.ers, but not necessarily with random users).
So basically all the money the government has collected as fines and penalties is distributed evenly to all taxpayers. That money was collected as compensation for crimes against society, and this way it gets distributed back to society.
That's exactly how it works in other countries (e.g.: Switzerland). Fines don't go to the department (e.g.: to the police) Fines go to the public spending budget, so the country has more money to do things (in addition to the tax money), or more practically, gets less indebted to do the same things...
i will admittedly say i have no idea what sixxs is
SixXS was a free IPv6 tunneling service, so that people with only IPv4 provider can still get access to IPv6 addresses through a 3rd party. (But more reliably than 6in4 which is dependent on the dynamic IPv4 address, and relies on volunteer servers reached though anycast).
The idea was to break the chicken-and-egg problem faced by IPv6 migration : - content provider don't care about moving to IPv6 because nobody is using it and most people are still on IPv4 - and ISP not spending the effort to provide IPv6 to their clients, because there's no IPv6 content to justify the move.
SixXS provided a 3rd party with a very reliable way to get onto IPv6, so at least the "there are no users" excuse isn't valid anymore.
Now fast forward a decade and a half later and nowadays a lot of content providers *ARE* on IPv6 (e.g.: Google, most universities, etc.), but there are still ISP not providing IPv6 on their network (e.g.: using something like 6rd, which basically works like 6in4 but relies on official servers with fixed address that is owned and operated by the ISP), Instead of that ISPs let the users go use SixXS, for the users who want IPv6. So rely on a free 3rd party service, instead of putting the efforts themselves to enable IPv6 for their own users as they should be doing.
So SixXS is shutting down to force ISPs to setup and listen to their users and provide IPv6, instead of deferring it to SixXS.
its sad to see them go since it was a free service, providing a service for people without means.
The thing is, SixXS was providing a service that should in theory be provided by the ISPs themselves, but some are too lazy to implement IPv6 even after almost 2 decades.
(and it's not for people without means. Technically, it's for people who have the means to pay an ISP for a connection, but said ISP is damn shit lazy and doesn't care to provide something more modern than last century's IPv4)
Given that SixXS has been free-as-in-beer regarding their services (and free-as-in-speech regarding some of their client side code), it's hard for them to be money hungry.
Given Europe's attitude towards hate speech and how they enforce "right to be forgotten", I'm surprised that they haven't already erected a GFW at this point
...said the main living in the glorious country where the simple apparition of a nipple is considered a major mediatic catastrophe, where breast feeding is a public offense, and where anything remotely sexual is sure to traumatise the next few generations of youth. (and where nude bodies are probably terrorism-level material).
To each country and culture its own taboos. For Germany, it might be hate speech, for France it might be "right to be forgotten", and for the USA it's anything which isn't missionary position with the sole purpose to procreate.
Slashdot Mirror
Hopefully (though doubtfully) the OEMs will be eating a lot of warranty returns. It is only if this costs the OEMs money that the problems will be fixed.
Such warranty return are mandatory for the OEM to accept in Europe, at least 24 months (I think, it might by 36) and given how recent this IoT craze is, most devices still qualify for such returns.
The cost might not get all the way to the cheap-ass chinese no-name manufacturer who did actually commit a device with such atrocious security.
But the cost won't burden the end user, it would at least be a problem for the brand that decided to have their device manufactured, without exerting the necessary caution regarding security.
If you're ready to import the device and stick your branding on it, you need to be held responsible for its security.
Depends on the jurisdiction but in Europe companies are required to cover warranty for quite a significant period of time
(at least 24 months in this case. It might even be 36 months but I'm too lazy to google. Anyway given how recent this IoT craze is, most of the devices are definitely more recent than their warranty period and thus of course still covered)
The constructor *HAS* to replace such bricked devices through warranty, with the user only bearing the cost of sending the bricked device and the manufacturer covering the cost of the new replacement and shipping that back to the user. (During the first few months the shop that did sell the device can even handle the replacement themselve and ship the defective through their own channels. The user will become the replacement immediately and 100% for free).
So there is *definitely a strong economic incentive* to make the device secure.
If the device is vulnerable, it is going to cost a lot due to warranty replacement and shipping.
(And as pointed by others: if the replacements keep getting broken again, consumer will switch brands)
and after you factor everything (including battery manufacture), only China and a few others (India, Australia) end up having similar emission between both types of car.
On every other country, it range from "a bit better" (like in the US - where fossils are still burned for power generation, but efficiency is better as suggested by parent poster) to "really definitely better" (like TFA's Norway or Switzerland, etc. - where power generation emits very little pollution, thanks to [alpine/cold climate] hydro, etc.)
*sigh*. Electric cars cause emissions- they're just externalized at the generating station.
Which usually given the electricity generation available in the country, tends to be much more efficient than the ICE in a car. (with a few exception like China, India and Australia - according to source which are easy to Google, but I'm too lazy to find yet again for the nth argument about the same subject).
Yes, the US burns fossils to create electricity, but over the life time of a car, even taking into account the initial manufacture (a battery is more complex to build), an electrical car in the US still causes less emissions than a gaz-powered one.
In TFA's Norway, electricity comes mainly from hydro. And even if it's not an Alpine region, the climate is more or less comparable and thus hydro has a very tiny output of green-house gazes and other pollution.
Electricity is *definitely* cleaner there.
You need to travel to a country that produce most of its electricity by burning coal (like China) to find a situation where there isn't much difference between an ICE car and an electric one.
(And in that last situation: well if China adds more clean energy production to its power offering, all the electric car suddenly get better emissions as a consequence. Whereas all the ICE cars would need an engine swap to suddenly have better).
In that case, then what's the point of using Bitcoin?
The point of bitcoin (the protocol), is that it is distributed.
There's (theoretically) no central authority.
Any two endpoint can exchange currency (usually BTC) as long as they both follow the protocol.
(anonymity was never a point. And goes against the way bitcoin works as every single (full) node on the network needs a local copy of the whole ledger to be useful. So ever node gets to see every transaction ever done).
You can run a perfectly functional digital economy with yen or any other real currency.
Yeah, and how do you send those yens around ? Say you want to send me 1'000¥.
You'll need to use some system like PayPal (where we need to both have an account) and further down the line you'll need a credit card (so you'll need to also have a card at MasterCard or VISA).
So for our transfer to work, there are a couple of companies (PayPal, MasterCard, etc.) that have central authority over any transaction we attempt.
They could even block us (that actually hapenned to WikiLeaks and was part of the reasons bitcoin got popular).
As opposed to the bitcoin protocol :
- you could be using anything - e.g.: local bitcoin to buy a faction of BTC for some ¥s in your local market. or e.g.: use some exchange platform (whatever has currently replaced MtGOX and BTC-e)
- I could be using some coin processor to convert them to real money (e.g.: BitPay or Coinbase) or simply store them into my local wallet (e.g.: Bitcoin Classic)
As long as the end-point we each chose follows the protocol, the transaction can happen.
There's no single central "Bitcoin Inc." that could control the transaction (massive mining pools aside) and freeze your account.
There's no single BTCcard that we all must obtain in order to do the trasaction.
And unlike PayPal, nobody can block donations to wikileaks.
The closest to this type of freedom of choice is european payment system like SEPA.
As long as your and my bank follow this system, we can send money accross accounts.
This makes me wonder why we have not moved back to a Harvard architecture {...} Having separate data and code spaces would stop this line of attack cold.
The problem is that the vast amount of modern thing isn't code that is executed as-is on the CPU,
the vast majority of modern apps are written in some high-level extremely abstract language that gets interpreted.
(That includes executable script portion on most web pages and macros embed in nearly every modern format - including docx - with maybe the exception of a few plain boring image formats)
So either you end up with code running in code space that reacts and changes behaviour (interprets scripts) based on data located in the data space. .docx files, and only consider data a few.
Or you need to consider nearly everything as code, including
Like the README file and... huh... that's about it.
(For fuck's sake, even some text/image formats like Post-Script are turing complete).
Like windows mobile, Ubuntu is years late.
The only viable mobile OS's are Android and iOS.
They aren't as much *late* as *not member of any large app eco-system*.
There's a really strong networking effect. People want to use smartphone also for the app featured
It's a catch-22 : nobody is going to write application for Windows 10 Mobile because there aren't as many user as Android and iOS, and nobody is going to use Windows 10 Mobile because there aren't as many apps on it.
Microsoft *was* aware of the problem. They *did* want to find a way to run android apps on Windows 10 mobile phone. But that's an extremely difficult task when you're not even running a Linux kernel. The only thing that came out of thes failed experiment is WSL (Windows Service Linux - a minimalistic Linux API layer that the NT kernel can expose in addition to Win32 etc. and that enables you to run a few unmodified Ubuntu console applications directly under Windows 10).
We'll see how it goes with Ubuntu. Canonical has toyed with the idea of running android apps.
Meanwhile Jolla's Sailfish OS isn't doing that bad, because it's designed on purpose to run android apps in addition to native QML apps.
(Official commercial version feature aliendalvik, community version relies on sfdroid).
So their users aren't left in the dust.
There's no point in visiting this site again until over a day has passed.
Given dupes, slow news, slow editorial (...huh ?) process, etc.
I would say waiting a until over a week has passed is better.
and due to their function "satly" (basically a ion flux) and "pH" (bascially a specialised ion flux) asiest to simulate with electrodes
Silly question, is this why licking batteries taste the way they do?
Bascially yes.
Those receptors are the most sensitive to the type of activity that happens when licking batteries.
just rip off any other successful app and cha ching!
The problem is that the features aren't the only reason SnapChat is successful.
It's not like the kids are there only for the emoji-stickers, face-tracking "doggy-face" filters, and "don't over-think you posts, it's for ephemeral consumption" agument...
(Though these are part of the reason why Snapchat started to get popular).
Now there's also a set of network and anti-network effect into play.
The kids are currently flocking to Snapchat because that where all their friends are already on.
And the kids are also flocking to Snapchat because it's explicitely NOT facebook, i.e.: it's *NOT* where their parents are, and neither the teachers, nor all the other people they with whom they don't want to be on the same network and in front of which they don't want to be embarrassed.
i.e.: At the current point of time, Snapchat not being Facebook IS one of the main reason of it's popularity.
Thus:
- Facebook trying to acquire Snapchat to avoid getting over-taken by it (like they've done in the past with Instagram, WhatsApp and any other popular platform) was their only hope, but they didn't manage to catch that boat.
- Facebook trying to integrate Snap-like features in their offering is not going to help them much. It's going to help them retain some of their current (ageing) user base. (Those who are already there and might be interested in the features : I've seen it on Instagram).
But it's not going to help re-capture the current "new generation", those are already building their network elsewhere.
For once, Zuckerberg is at the receiving edge of the network effect.
Hillary shares responsibility starting from the day she first had sex with Bill Clinton
...but I thaugh Monica was the one having "not sex" with him ?
Giving a dead serious response to an obvious joke, but...
How about caramel, or blueberries, or carrots, or ketchup, or seafood.....
The tongue is an extremely limited organ in sensing capacity.
Basically it can detect sweet (presence of small molecule with a surface vaguely shaped like glucose), salt (basiclly "there are ions here"), acid/sour (simplistic pH) and umame (detects if there are animo acids in the mix).
that's about it.
and due to their function "satly" (basically a ion flux) and "pH" (bascially a specialised ion flux) are the easiest to simulate with electrodes (cause a flux of electricity, i.e.: ions when in a liquid medium like saliva), so that's why they went for "shitty cheap lemonade" (basically citric acid/citrate sodium with some tasteless yellow dye) instead of anything else more complex.
The organ which is responsible to detect that caramel is in fact caramel and not only sweet with a touch of salty is the nose.
(In addition of sampling air as it goes by (= sense of smell), the nose can sample small molecule that are present inside the mouth cavity and diffuse to the nose thorugh the back or over the humid surface (= sense of taste, complementing what the tongue is doing).
There are a huge amount of different receptors, enabling you nose to detects the shape of an incredible amount of different small molecules (usually some fatty acids, but lots of others too).
To create a realistic simulation of blueberry flavor you'll need to stimulate all the various receptors inside the nose that detects shapes present on the various volatile component found in blueblerries.
(Which is incidently what the food industry is also trying : find a few dead cheap stuff, that stimulates the nose in the right way to make you things you're tasting which has spent time growing on plant being taken care of, instead of tasting whatever was the cheapest compatible chemical)
In theory, there's no fundamental technological reason why it shouldn't work, given a sufficiently fine electrode matrix, that can pinpoint the various chemical receptors precisely enough (it's "just" an engineering problem).
(There's no new hidden tech to be discovered in doing it).
In practice, it's going to be extremely complex just to build and test the appropriate electrode array. It's going to cost a lot, not bring anything new to research, and not do anything that can't already be done much cheaper and simpler by blowing the correct dosage of small chemicals into the nose.
And over all, TFA is also a measure of the gullibility of the brain : giving a liquid that is more or less the correct colour (yellow. done by LEDs here or by adding color dyes in the industry) and vaguely stimulates the taste buds in the right way (salty acidic) and the person will be fooled into thinking that they are drinking lemonades made out of actual lemons.
(Which is incidently, again, what the food industry is doing, but with chemicals instead of electronics. Can't get the blueberry mix precise enough ? Well... add some deep blue/purple paint, make sure it's sweat and a bit acidic and you're goign to fool enough gullible customers. Some of them have never even seen an actual blue berry anyway, they won't notice).
wouldn't an I-Pad packed with explosives stick out on an x-ray like a sore thumb?
Have you already had a look on say x-ray image of a tablet or smartphone ?
A very big part of the volume is occupied by the battery (intentionnally bigger to store as much power as possible), with extremly tiny electronic components and board push to the edge around it (intentionnally small, to use low-power components).
In theory it should be very easy to replace the battery (on an X-ray it's just a big slab of homogenous-looking chemical) with another similarly looking slab of explosive chemicals... i mean, intentionally explosive chemincals (lithium is also explosive, but that is not its intended main use, no matter what was happeinning to Samsung smartphones, "Hoverboard" hands-free segway-like and old Sony laptop batteries).
A bomb-containing or battery containing tablet will look the same on X-rays.
In practice, a tablet isn't big : you can't pack that much destructive energy in such a small form-factor.
For enough destructive power, you would probably need to go for a volume that ends-up looking similar to a laptop's battery.
(if you think about it, lithium batteries are already about packing as much energy as possible inside a device).
No, but it IS the filesystems fault for corrupting itself no?
File systems with a lesser tendency to corrupt themselves :
file systems that do not over-write themselves.
such as Copy-on-Write filesystems (Btrfs, Zfs, etc.) and Log-structured filesystems (F2FS, UDF, etc.)
according to source, APFS is also going to be copy-on-write, making it similarly more resilient to corruption.
(if system crashes or loses power mid-write, you don't end-up with a corrupted file system.
You end up with the previous version of the filesystem, plus new copies of data that may or may not be corrupted.
For those copies which are corrupted, you can trivially revert to previous copy)
In other words, it functions the same way as copy-on-write filesystems such as Btrfs and ZFS, or log-structured filesystems such a various flash-oriented systems (F2FS and the likes) or as the venerable UDF.
Or thank you apple for finally having a filesystem that is not decades out-dated, but finally joining the club of other modern Unices.
I am just wondering why they needed to re-invent their own wheel, instead of opting for re-using ZFS.
and very few people would check EV
That's why some browsers like Firefox checks it for you and display it right in the URL bar.
You can't miss it.
What you really need is the domain registrars to check that if sites are being registered that are similar to a company name or trademark that they have a legitimate right to use that name.
Hey, then you need to ban slashdot.org, because it's name is similar to Slash. Or to DJ Slash. Or to Fatboy Slim's song.
The problem with "check that if sites are being registered that are similar to a company name or trademark" is that it's a complex task require some thinking that it's not trivial to automate for absolutely free (and in a way that won't be trivially circumvented by attackers).
It goes beyond the point of Let's Encrypt (whose point is, as the name indicate, just to make encryption available).
Or build a chain-of-trust system where people can blacklist a bad domain by voting it down
Which isn't an easy task to do (how many - outside of /. - to use PGP on a regular basis ?) Chain-of-trust system aren't easy.
Blacklist aren't silver bullet neither : an attacker could still bank on a quick attack trying to scam as many users as possible before getting flagged.
(See all the "software to make a millionaire out of you on binary option sites !" scam that are popping every where. Site costs under a couple of hundred in stock-photos / fiverr actors / ads promotion to set up, and can manage to make a few thousands selling snake oil before getting reported and shut down).
Neither of them have anything to do with HTTPS.
Which brings us back to the point : Let's Encrypt's purpose, as it names implies, is to bring the S in HTTPS and nothing more.
It's not their job solving the certification of owner in an easy way.
In other words, the business model of Let's Encrypt is to sell digital certificates that aren't worth the electrons they are printed on.
Let's encrypt is a free (price as-in-beer, code as-in-speech) service. They don't have a business model.
They have a purpose (the same as CACert, by the way), to issue simple certificates that can verify that "blah.com" is indeed "blah.com".
(As opposed to some man-in-the-middle attacker mascarading as "blah.com" using a different 3rd server).
They do not certify any thing else, and indeed the certificates' fields. This certificate doesn't certify any organisation name.
This is even reflected in some browser's URL bar.
e.g.: in Mozilla's Firefox.
- Go to a "let's encrypt" website (like here on /. ) or one certified by CACert :
you only get the green padlock (sign that the communication is encrypted) and no other indication.
let's encrypt only checked that slashdot.org is indeed slashdot.org, but didn't check anything regarding ownership.
(it might as well be someone trying to impersonate Slash, DJ Slash or Fat Boy Slim)
- Go to paypal :
in addition to the padlock, you get an indication that certificate is certifying that the server is owned by PayPal Inc.
(Symantec actually checked that PayPal Inc is indeed own
Issuing a certificate to BobsCarRepair.com is one thing. Obviously you have no way of knowing whether or not Bob is a reputable business.
Even further : it doesn't even certify that owner of the website is someone called bob. It only certifies you that it is indeed bobscarrepair.com
It might as well be owned by Alice, for what you know.
It only certifies that Eve isn't wiretapping you when you give your credit card number to buy parts.
However, Issuing 14,000+ certificates that contain the word PayPal, to domains not owned by the real PayPal, is incompetence on a massive scale and calls into question Let's Encrypt's honesty and trustworthiness.
Nope.
There's a difference between guaranteeing a secure channel (against 3rd party eaves dropping).
And guaranteeing identity.
is
These are 2 different concepts.
Let's encrypt only takes care of the first one and has never ever hoped to tackle the second problem. They DO NOT certify owners, this field is intently left blank on their certificates.
The point of Let's Encrypt (as its name says) is that encryption becomes the norm on the web. In order to avoid massively stupid blunders, like the dead easy identity theft demonstrated by FireSheep.
That's something that CAN BE achieved for free, on a massive scale, like Let's Encrypt and CACert are doing.
There's no realistic way that let's encrypt could in any way confirm owner identity for free on this massive scale.
That's something which is very easy to understand for people who have some basic knowledge of security.
Saddly, sheeple are stupid. So you need to educate them and try to find ways to make them understand.
(e.g.: the above mentionned "show certified owner in the URL bar if provided" that Firefox is doing).
But sapping efforts like "Let's Encrypt" which are providing very valuable service (bringing the availability of HTTPS, TLS/SSL, etc. on a massice scale), simply because some idiot can't make the difference between "protection against 3rd party eavesdrop" and "identity of the owner" is counter-productive
I suggest you read up on what sudo is capable off. You can easily setup sudo via its configuration file (/etc/sudoers) that will allow users that require elevated privileges (eg. Database and Web Administrators) to do their work without needing root access.
The parent poster was referring to a different approach to security.
with sudo, you set up a list of commands that a database or web admin can run.
you limit user access by restricting which commands the user can run. But said commands will be run with root privileges.
In case of a bug in the command, you could use it for privileges escalations (*you* were only restricted to run this command. but *this command* runs as root and could do anything).
what the parent refers to is more closely related to the various "CAP_*" capabilities used in the linux kernel.
i.e.: even if you run a command as root, that command would never, even in the case of a bug, reconfigure the network interface, because the corresponding CAP_{blah} capability isn't enabled.
By carefully crafting a very precise set of capabilities that you hand out to administrative programs, you make sure that they only do what they are supposed to do, even if an attacker manage to find a way to force a program running as root to do arbitrary actions.
(It's a bit similar like how some smartphone apps come with a whitelist of API calls that you need to validate before installing : "can access your contacts list", "can access your webcam", etc. Even if the weather app get hacked, it can never be used to spy on you, because it's not whitelisted to access your mic and your cam... Well except that nowadays every single last app seems to be obliged to ask access for nearly anything (Hey, now your Weather app can automatically recognise the city you're travelling into simply by flashing the QR code of your travel ticket ! Needs cam privileges !).
Under Linux the same granularity exists, except that this done at the kernel API level, instead of the Java user libraries like on Android)
In the past few years Windows has been implementing similar restrictions. That's what the poster was referring to.
On Linux, the facility to apply this king of control exist in the kernel too (the various capabilities). But there aren't many software using them. I only know of SELinux and AppArmor. And they are not used system-wide, but only to put specific software into cages (those software for which they have rulesets).
I think this is dues to the fact that the basic user/group access rights of Unix can provide already quite some security if you take the time to organise enough granularity in your groups and memberships, instead of making everything restricted to root-only and needing thus to be root for nearly any action.
(Because of the Unix philosophy, lots of things are represented in unix as files. Therefore, lots of the actions controlled by capability can be mapped to file accesses (e.g.: to device files in /dev/ ). Putting correct group access on files can acheive the same results.
e.g.: a virtual machine might need USB passthrough. One way would be to grant the corresponding capability to it.
The way VirtualBox does it, is that it runs as "vbox" goup, and there's a script that hands out USB devices nodes with that as group access)
In practice, distributions such as Debian have been using tons of specific groups to control access to specific resources precisely, years before SELinux was a thing.
on Linux you need to suid yourself to root to do just about anything,
...said the guy who used to run Windows XP. You know, this OS where the user has admin rights by default, so even normal everyday tasks are done with admin privileges.
What are the reasons for an ISP to do IPv6?
There are tons of advantage of IPv6 over IPv4.
One of them being a vast supply of addresses (128bits vs. the overcrowded 32bits of IPv4).
It's auto-configured (you just plug a device into a network and it automatically gets IPv6 working. Routers directly hand out prefixes, no need to organise stuff through DHCP. In IPv6 DHCPv6 is only used to hand out configuration options)
Every device gets a single address that is routable anywhere on the internet. (No need of NATs, masquarading, and private address ranges).
People still can go to Google with IPv4, so no reason there.
...for now. As IPv4 address space gets depleted you'll soon reach the point where some machine are only IPv6 addressable, and thus some servers can only be accessed over IPv6.
They would need to invest and that is never a nice thing to do.
They need to replace a lot of hardware or at least reconfigure it and that will cost money.
Nope. The whole point of technologies like 6rd is that you deploy IPv6 as a tunnel over the IPv4 infrastructure that you already have.
No new hardware needed (beside the tunnel server), specially not needing to replace the thousands of expensive routers scattered accross the city that you cover with your services.
As a business I would also be against it.
I hope I am wrong and somebody can tell me a lot of advantages that would make them money, save them money or a combination of both.
That the problem with IPv6. There isn't a simply clear immediate money benefit. The benefit isn't ultra-short term.
The benefits are instead long-term : IPv4 is an old technology that is slowly reaching its limits (e.g.: number of available addresses) and that requires more and more layers to circumvent (e.g.: NAT to get around addresses limitation. e.g.: using relay servers on the cloud instead of devices talking p2p with each other, etc.)
From a technological point of view, we are running straight against a wall. But ISPs are complaining that they are not going make tons of money immediately by switching to IPv6 so they stay on course headed for the wall collision.
One very direct effect of all of the above :
You won't be required to use cloud service for every single small thing you need to talk to.
(security cameras, weather station, talking toy, etc.),
instead you can trivially access any gizmo directly over the web simply by opening it in your router/firewall.
IPv4 remote access : you need to sign up an account at their service. You gizmo and the app on your smartphone are constantly talking to this server.
This makes a big central failure point : the company server can get hacked, leading to thousands of account information leaking (see HaveIBeenPwnd for your weekly example), or if the device is insecure that's a single point from which to attack all devices. Also if the company goes belly up and the server is shut down, your gizmo becomes an expensive brick.
And these kind of server still costs a little bit of money, so either you're going to need to pay for the service. Or you're going to get ads-bombed as shit.
IPv6 remote access : you need to open a port (or a whole device) in *your* router. Your smartphone app is directly talking to your gizmo without any 3rd party getting involved.
There's no big server with a treasure trove of personal data to leak. If attackers want to hack an insecure gizmo, they need to find them one by one on the web.
Even if the company fails, you can still use your app to talk to the device, you don't rely on a 3rd party server.
There are no server costs to cover.
(Previously, similar things would have required fiddling with NAT, port forwarding and other such remapping to get done on IPv4. Trivial for most /.ers, but not necessarily with random users).
So basically all the money the government has collected as fines and penalties is distributed evenly to all taxpayers. That money was collected as compensation for crimes against society, and this way it gets distributed back to society.
That's exactly how it works in other countries (e.g.: Switzerland).
Fines don't go to the department (e.g.: to the police)
Fines go to the public spending budget, so the country has more money to do things (in addition to the tax money), or more practically, gets less indebted to do the same things...
i will admittedly say i have no idea what sixxs is
SixXS was a free IPv6 tunneling service, so that people with only IPv4 provider can still get access to IPv6 addresses through a 3rd party.
(But more reliably than 6in4 which is dependent on the dynamic IPv4 address, and relies on volunteer servers reached though anycast).
The idea was to break the chicken-and-egg problem faced by IPv6 migration :
- content provider don't care about moving to IPv6 because nobody is using it and most people are still on IPv4
- and ISP not spending the effort to provide IPv6 to their clients, because there's no IPv6 content to justify the move.
SixXS provided a 3rd party with a very reliable way to get onto IPv6, so at least the "there are no users" excuse isn't valid anymore.
Now fast forward a decade and a half later and nowadays a lot of content providers *ARE* on IPv6 (e.g.: Google, most universities, etc.), but there are still ISP not providing IPv6 on their network (e.g.: using something like 6rd, which basically works like 6in4 but relies on official servers with fixed address that is owned and operated by the ISP),
Instead of that ISPs let the users go use SixXS, for the users who want IPv6. So rely on a free 3rd party service, instead of putting the efforts themselves to enable IPv6 for their own users as they should be doing.
So SixXS is shutting down to force ISPs to setup and listen to their users and provide IPv6, instead of deferring it to SixXS.
its sad to see them go since it was a free service, providing a service for people without means.
The thing is, SixXS was providing a service that should in theory be provided by the ISPs themselves, but some are too lazy to implement IPv6 even after almost 2 decades.
(and it's not for people without means. Technically, it's for people who have the means to pay an ISP for a connection, but said ISP is damn shit lazy and doesn't care to provide something more modern than last century's IPv4)
Finally a company thats not money hungry alone.
Given that SixXS has been free-as-in-beer regarding their services (and free-as-in-speech regarding some of their client side code), it's hard for them to be money hungry.
Given Europe's attitude towards hate speech and how they enforce "right to be forgotten", I'm surprised that they haven't already erected a GFW at this point
...said the main living in the glorious country where the simple apparition of a nipple is considered a major mediatic catastrophe, where breast feeding is a public offense, and where anything remotely sexual is sure to traumatise the next few generations of youth. (and where nude bodies are probably terrorism-level material).
To each country and culture its own taboos.
For Germany, it might be hate speech, for France it might be "right to be forgotten", and for the USA it's anything which isn't missionary position with the sole purpose to procreate.
Beware of the nude-nipple-terrorists, America !