The judge did rule that interfaces are not copyrightable but that got overturned on appeal. He then asked the jury to decide if it was fair use. The jury voted yes to that.

Everything becomes a little bit cheaper because society now has to spend less money on launches. You have to pay less tax because the government get cheaper launches. Your internet may become a little cheaper because internet companies have to pay less for launches. You can get slightly more TV for the same money because broadcast companies pay less for launches. And so on.

You can also reverse the question. What would happen if launches became much more expensive? We would get less satellites and that might include less accurate weather forecasts, less service for farmers to optimise production, less optimal GPS service and so on.

Everyone benefits from this. Even the launches not made by SpaceX are going to be cheaper, because competitors have to do it cheaper to compete.

Better than being identified as a phone or giraffe.

IPv6 please. It is easy. A tech site for geeks should have had IPv6 a decade ago.

readObject is not something on the server, it is just a method signature defined by the serializable interface in the Java standard. The vulnerable code needs to be on the server of course, or there is nothing to abuse. The vulnerable code is in the Apache commons library, which has a class that implements serializable and therefore provides a readObject method, that can be abused.

But then you write something like "Serialized objects in Java is no difference than SOAP requests or JSON objects, or CORBA or other means to do RPC/RMI". But that is completely wrong in this context. The reason we have this bug is exactly because there is a difference from java serialization and all of the others that you mention. And that difference is that the serialization data includes arbitrary class names that allows the attacker to cause your code to load _any_ class that implements the serializable interface, no matter if that has anything to do with what you are working with here or not.

If you use JSON you will not have that. JSON can only cause strings, numbers, arrays and hashmaps to load.

This is also wrong: "Finally: serialized objects are just data, they contain no code. So there is nothing to execute. If you read the article, you see: the only code executed is the "readObject" method that already is on the server!!" - yes the exploit is in a readObject implementation, but that exploit allows the attacker to transmit arbitrary code and have it executed. Code that was in no way on the server already.

"First of all: there is no outside code executed when you transfer an object, the article is wrong with that. So you need a way to execute your code. The only way I can imagine is" - or the way the article describes. Which is not a derived object. He sends a serialization of a completely different object, namely the vulnerable class in Apache commons. The deserialization in Java just returns "Object" - there is no expectation here that the returned object be of the type that you, the programmer, expects. You will then of course get a class cast exception if you just cast it, or your code will notice something is not right if you do a isInstanceOf on it. But by then it is too late, he already had his custom code executed by Apache commons when the readObject method in there was called.

You need to know absolutely nothing about the system you want to attack. You only need two things, one is for the system to be vulnerable (=Apache commons needs to be on the classpath) and the other is that you need to find something the system serializes. You do not need to care about what it is that it serializes, because you will provide it with your hacked object, and the deserialization will fail but by then you already got what you want.

So if your web application does not use serialization the second prerequisite will fail and you are safe. But if you did something like putting a serialized object into a cookie, then you are done for.

Did YOU read the article? The serialized objects are just data - well except if someone made a readObject that as part of the deserialization process executes steps based on that data. Programs are just data.

The "bug" is that someone did exactly that and put it into a very common library. If you have that library on your classpath, and chances are very high that you do, then you have no defense against this. You lose the moment you try to deserialize the data. It does not matter that you are expecting the data to deserialize to something completely different.

Say you make a class called UserInfo and put that into a cookie using serialization. If you did that, you are a goner. There is no way you can deserialize that cookie without risking that somebody replaced the cookie value with serialized data from Apache commons. You will not know that it is not actually UserInfo data anymore until after he rooted your system.

The only solution is to a) do not deserialize data that could be modified by an adversary. Or b) if you must, make sure Apache commons is not on the classpath while you do so (could be done with a custom classloader).

Personally I would ditch the build in java serialization and use another serialization library, one which does not allow arbitrary class names in the serialization data. I switched to Scala long ago and in the Scala world most serialization libraries do not use reflection to (de)serialize, and therefore fulfill that requirement.

It may not be worse but it will have programmed sense, so it will refuse to attempt it.

Port numbers is only useful and needed if you are dealing with carrier NAT. That is NAT performed by the ISP, such that multiple customers share the same ISP. This happens to be somewhat common with apartment networks.

If RIAA/MPAA records the address 2001:db8:a55:beef::2af6 only the "2001:db8:a55:beef" part is actually useful. The remaining part of the address will typically be a randomized privacy extension address. They are therefore still unable to prove which machine was used to download the content.

If you are one of the persons that want to use easy to remember addresses, you can still use privacy extensions. With IPv6 it is normal to have many address on each computer. You can have your easy to remember address (2001:db8:a55::2) that you use for ingoing connections. And the machine will prefer the random privacy extension address for outgoing connections (2001:db8:a55::9b43:82dd:2239:10bc - right now but in an hour it will be completely different).

There is also some big sites that are available:

baldur@ballerup1:~$ for i in google.com facebook.com www.netflix.com akamai.com cloudflare.com rackspace.com wikipedia.org; do ping6 -c1 -n $i | grep bytes; done
PING google.com(2a00:1450:4005:801::1000) 56 data bytes
64 bytes from 2a00:1450:4005:801::1000: icmp_seq=1 ttl=50 time=28.8 ms
PING facebook.com(2a03:2880:20:4f06:face:b00c:0:1) 56 data bytes
64 bytes from 2a03:2880:20:4f06:face:b00c:0:1: icmp_seq=1 ttl=43 time=191 ms
PING www.netflix.com(2a01:578:3::36e4:ea94) 56 data bytes
64 bytes from 2a01:578:3::36e4:ea94: icmp_seq=1 ttl=46 time=38.0 ms
PING akamai.com(2a02:26f0:103:186::22df) 56 data bytes
64 bytes from 2a02:26f0:103:186::22df: icmp_seq=1 ttl=54 time=22.3 ms
PING cloudflare.com(2400:cb00:2048:1::c629:d59d) 56 data bytes
64 bytes from 2400:cb00:2048:1::c629:d59d: icmp_seq=1 ttl=57 time=10.6 ms
PING rackspace.com(2001:4801:1221:101:1c10:0:f5:116) 56 data bytes
64 bytes from 2001:4801:1221:101:1c10:0:f5:116: icmp_seq=1 ttl=43 time=127 ms
PING wikipedia.org(2620:0:862:ed1a::1) 56 data bytes
64 bytes from 2620:0:862:ed1a::1: icmp_seq=1 ttl=52 time=20.7 ms

The CDNs in there means that you will get some content over IPv6 even from sites that are not IPv6 enabled as such.

IPv6 Neighbour Discovery protocol (ND) https://tools.ietf.org/html/rf... is the protocol used by IPv6 hosts to find each other. It is the IPv6 equivalent of ARP. And ND is based on multicast. Without multicast, nothing would work with IPv6.

An IPv4 host needs to use broadcast ARP packets to every host on the same network. This was fixed in IPv6, so each host uses the last 32 bits of its address as a multicast group. When you need to contact someone, you will take the last 32 bits of his address and then multicast your ND packets to that multicast group. That way only hosts that share the same last 32 bits will receive the ND packet. This dramatically reduces the amount of broadcast/multicast chatter received by each host.

The downside is that it only works on networks with MLD enabled switches. That is very rare. Without MLD the system will fall back to broadcast.

But just to point out that you are wrong to believe that multicast is experimental when in fact it was baked in from the very start.

You need to read up on IPv6 privacy extensions: https://tools.ietf.org/html/rf...

Your computer will generate a random IPv6 address and change that random address at regular intervals (typically a few hours before it changes). Therefore they will be unable to track the exact computer, because there is no way to know which computer had that random address at the time.

They will get you anyway due to cookies and device fingerprinting, but that is no different than the situation with IPv4 and NAT.

Also with carrier NAT ISPs in most countries are by law required to record the port numbers assigned to each user. Your IP might be shared with multiple other users, but as long they also recorded the port number, they will be able to find the user. RIAA and MPAA knows this - I get a ton of email from them every day complaining about users that download their stuff with Bittorrent and every complaint includes port numbers.

Try "Network Prefix Translation" instead: https://tools.ietf.org/html/rf...

"This document describes a stateless, transport-agnostic IPv6-to-IPv6
      Network Prefix Translation (NPTv6) function that provides the
      address-independence benefit associated with IPv4-to-IPv4 NAT
      (NAPT44) and provides a 1:1 relationship between addresses in the
      "inside" and "outside" prefixes, preserving end-to-end reachability
      at the network layer."

Although personally I believe it is seldom needed. In practice a IPv6 home network can renumber every device within 30 seconds of the ISP changing the prefix on you. That is less time than it takes for your CPE router to reboot.

Nope, all three protocols will work fine with any prefix size. Only SLAAC need a /64 prefix

If you did a /120 you would use RA to tell your network about it. You would then need to set the managed config flag, so your devices can use DHCPv6 to acquire an address. After getting an address through DHCPv6 the devices will use the DAD process to check that the address is unused. And they will use ND to be able to communicate with other devices.

The majority of internet service providers will give you a /48 prefix. Meaning that you decide what to do with the remaining 80 bits. If you make them all zero, your IPv6 address can indeed be shorter than the typical IPv4.

Example:

2001:db8:123:: (that would be your router)
2001:db8:123::2 (that would be your web server or whatever).
2001:db8:123::3 (that would be your mail server or whatever).

Compare to:

198.51.100.250 (that would be your router - and also your web/mail server because it is all you got).

Blocks less than a /24 are not routable on the Internet. For some reason it was RIPE that tested that with a loaned block from ARIN.

One can hope that ARIN will recognize the need to be able to route this on the internet as sufficient reason to get a /24 instead of a /28.

There is one other difference to the RIPE policy and that is the IPv6 requirement. There is no such requirement by RIPE. You will get your /22 from RIPE and you can continue to ignore IPv6 and just use it with carrier NAT or whatever. RIPE will ask you to take an IPv6 assignment as well, but they do not ask if you are going to use it for anything.