German situation is mostly/rarely/never. Small businesses have their DSL line where their cheapo router will announce an IPv6 prefix which almost all ISPs over here provide. Medium to large businesses usually have some braindead security policies that include switching off all IPv6 functionality in devices.
On our end, it's all electronic - we never print anything out. So yeah, on our side, "email with extra steps". But I have no idea how the mortgage companies handle it on their end.
Ink on paper, where I work. There have been court decisions that have seen Fax as "remote copying". And said that those remote copies only had any legal value if there was an actual paper original. Thus the workflow always has to involve paper that is then archived as paper in a folder...
I once had to print a form and fax to a company with a signature and the instructions said specifically that "signing with a computer and sending digitally is not allowed".
I just signed with macOS Preview, applied some random noise filter and used a one-off online fax service. ¯\_(ツ)_/¯
> Medium to large businesses usually have some braindead security policies
what's the argument behind that? are they scared they might configure their firewall bad and have no NAT to safe them from accidentally making all devices public?
It comes from the same place as "passwords expire every 30 days".
People don't understand something and just apply the most annoying rule possible.
The craziest one I saw in Germany was "cookies are allowed, localStorage is not", that was for our app. CTO overrode the CISO on the spot and called him an idiot for making rules he doesn't understand. Interesting day.
Usually there is no official justification given, just a list (in excel...) of security requirements that have to be ticked off. One of them is "Disable IPv6".
I've heard some ex-post justifications, make of them what you will: Existing infrastructure like firewalls, VPNs and routers might not be able to handle IPv6 properly. Address distribution in IPv6 is unpredictable. No inhouse knowledge of IPv6. Everything has an address in IPv6, so the whole internet can access it. No NAT in IPv6, so it is insecure. IPv6 makes things slow.
Yes, and the three western allies agreed to let their occupation zones form a German state. Which the Soviets opposed and had their occupation zone form an East German state, thus dividing Germany at their zone boundary. The Soviets did the dividing, the other allies did no such thing.
"Against Soviet protests, the two English-speaking powers pushed for a heightened economic collaboration between the different zones, and on 1 January 1947 the British and American zones merged to form the Bizone. Over the course of 1947 and early 1948, they began to prepare the currency reform that would introduce the Deutsche Mark and ultimately lead to the creation of an independent West German state.
When the Soviets learned about these plans, they claimed that they were in violation of the Potsdam Agreement, that obviously the Western powers were not interested in further regular four-power control of Germany and that under such circumstances the Allied Control Council had no further purpose." [0]
There is ample precendent for impounding the assets of hostile nations. The Soviets did it to Germany in WW2, so they cannot really claim that they are opposed to that practice.
The only reason why this seizure of russian money in Belgium might be a bad idea is reciprocity. Russia would of course then try to seize European assets in Russia.
And regarding ships, prize law is still internationally accepted and in effect. Ukraine can offer prize letters to privateers or foreign navies, allowing the seizure of Russian ships. Or they can seize ships themselves. When those ships are then in a Ukrainian or allied harbor, a Ukrainian admirality court then assigns ownership of the vessel and all goods to the ones who brought it up. https://en.wikipedia.org/wiki/Prize_(law)
Oil tankers are basically "weapons of mass environment destruction" (slight hyperbole, sorry ;). When you shoot at them, or their captains have the valves opened, their oil will devastate a sizable chunk of sea and coastline.
So you really need to tread lightly around enemy oil tankers.
Internal Propaganda. You show to your own people, that you can cut off the enemies' communication lines easily.
External Propaganda. You show to the enemies that they are vulnerable, spreading fear and doubt in their own strength.
Exercises for larger operations. You train ships' crews for those kinds of maneuvers, in case you need to to it a large number of times, e.g. to cut off all baltic cables at once, cut all transatlantic cables, cut all cables to some important island like Iceland, etc.
Internal Normalisation. You get the ships' crews, your population and your governance structures used to a more aggressive mode of operations.
External Normalisation. You get the enemies' population and governance structures used to those kinds of pinpricks. So when the large-scale operation starts, they will ignore the first signs as "just the usual irrelevant pinpricks".
Testing and mapping connectivity. When the cable goes down, you can have your spies look at which relevant infrastructure goes down at the same time.
This is one of the best, succinct lists of motivations for hybrid warfare i've seen.
But i could suggest another potential benefit for russia:
If russia already operates under the assumption that they are in a (cold) war with EU/NATO, and they don't care about the effects on the relationship with Finland. Then this may simply be a really low cost, high damage operation. That not only imposes the replacement cost of the cable, but also forces countries to invest in counter measures.
In a democracy, "We The People" is the sovereign. It is in the hands of the voters, and it is their responsibility to choose leaders wisely and shape their overall legal system. In democracies, the population doesn't get to use the "but its just our evil leaders" excuse. Only in other less democratic forms of government.
And yes, this means that in a democracy, the opposition's voters are screwed because they share in the responsibility, even if they were right. Why? Because they were unable to convince the majority of the wrongness of the majority vote.
Is supposed to be the sovereign/source of all legitimate authority.
But it's not as a practical matter in the US, or even in legalistic practice. Most legalistic factions in the US plainly treat the constitution itself (and/or its authors) as the source of its own authority.
> We the People of the United States [, in Order to ...,] do ordain and establish this Constitution for the United States of America.
That is the literal first paragraph of the US constitution. I cannot imagine a valid legalistic argument that ignores that. When first establishing the constitution, it also didn't appear in a vacuum, the pre-existing states and confederation were already democratic for some time. So all authority/validity/legitimacy the US constitution has comes from the population, back then. And through continuing use, participation and broad acceptance until present.
And of course, as a practical matter in a representative democracy, between elections, the people do have far less of an influence. They can basically only voice their opinions, threaten to vote differently in the next election, or start a revolution. But that doesn't absolve them of their responsibility on election day.
> So all authority/validity/legitimacy the US constitution has comes from the population, back then
Exactly, back then. But those people are dead to a man. They are no longer people of the United States. Even if you count them as such, they would be extremely outnumbered by currently living people of the United States, and thus, democratically they can no longer confer any legitimate authority to the constitution. If they do confer any authority, it isn't democratic authority, because it has to be based on something else than the people.
> And through continuing use, participation and broad acceptance until present.
I think that's a pretty tenuous argument, all the time people constantly point to the constitution itself as authority for why they accept the constitution, rather than pointing to themselves as they should if they truly believed in the people's authority as opposed to gods, kings and holy texts. But even accepting that argument, at the very least you'd have to agree that if the people decided to change the constitution through means other than those the constitution propose, then that could still be perfectly democratic.
> But even accepting that argument, at the very least you'd have to agree that if the people decided to change the constitution through means other than those the constitution propose, then that could still be perfectly democratic.
Yes, of course. If the voters, or at least their democratically elected representatives, decide that a new and different constitution is necessary, that's totally fine and expected. Some more modern constitutions even point this out explicitly.
I'm baffled, this is one of the worst comments i've read on HN. It's hard to answer without using insults. Seems i'm really triggered by Blaming The Victim.
"Benevolent" more in the sense of "currently unable to order the next massacre". The German unification only went ahead because soviet troops didn't intervene like they did in many prior instances:
Glasnost and Perestroika under Gorbachev were not benevolence but necessary because the centralized power of the Soviet Union was dwindling. The SU became more and more occupied with fixing its own problems and could no longer hold together the Eastern Bloc by influence or force. Which is why the Eastern Bloc then slowly dissolved. This didn't start with the German unification, but earlier, and encompassed Poland, Hungary, Romania, Yugoslavia:
The SU (who are actually dominated by, but different from "the Russians") certainly would have liked to hold it together. And while under Yeltsin, there was a period of acceptance of the dissolution of the SU, currently Putin seems to want to revive it, at least in terms of territory.
Scales of goodness of expressions are shifted relative to English: "good" (gut) to a German means "it totally fulfills all my needs and expectations, so it is perfect for my purpose". "very good" (sehr gut) means "it exceeds all my expectations" and to a German already sounds like total hyperbole. Anything like "delightful" or "excellent" to a German sounds either totally sleazy or sarcastic.
When something is not perfect but adequate and we are happy with it, we would say something like "not bad", "it's fine" or "you can leave it like that". Which to the english speaking world has totally different connotations and can lead to rather interesting misunderstandings.
And especially "not bad" ("nicht schlecht") can be confusing in that it is sometimes something rather positive. It, in German and said in the right tone of voice" can mean "this is suprisingly good".
All the issues basically boil down to "nobody wants to do the busywork of CVE filtering, triage, rejections, changes".
As a developer, kernel or otherwise, you get pestered by CVE hunters who create tons of CVE slop, wanting a CVE on their resume for any old crash, null pointer deref, out of bounds read or imaginary problem some automated scanner found. If you don't have your own CNA, the CVE will get assigned without any meaningful checking. Then, as a developer, you are fucked: Usually getting an invalid CVE withdrawn is an arduous process, taking up valuable time. Getting stuff like vulnerability assessments changed is even more annoying, basically you can't, because somebody looked into their magic 8ball and decided that some random crash must certainly be indicative of some preauth RCE. Users will then make things worse by pestering you about all those bogus CVEs.
So then you will first try to do the good and responsible thing: Try to establish your own criteria as to what a CVE is. You define your desired security properties, e.g. by saying "availability isn't a goal, so DoS is out of scope", "physical attacker access is not assumed". Then you have criteria by which to classify bugs as security-relevant or not. Then you do the classification work. But all that only helps if you are your own CNA, otherwise you will still get CVE slop you cannot get rid of.
Now imagine you are an operating system developer, things get even worse here: Since commonly an operating system is multi-purpose, you can't easily define an operating environment and desired security properties. E.g. many kiosk systems will have physical attackers present, plugging in malicious hardware. Linux will run on those. E.g. many systems will have availability requirements, so DoS can no longer be out of scope. Linux will run on those. Hardware configurations can be broken, weird, stupid and old. Linux will run on those. So now there are two choices: Either you severely restrict the "supported" configurations of your operating system, making it no longer multi-purpose. This is the choice of many commercial vendors, with ridiculous restrictions like "we are EAL4+ secure, but only if you unplug the network" or "yeah, but only opensshd may run as a network service, nothing else". Or you accept that there are things people will do with Linux that you couldn't even conceive of when writing your part of the code and introducing or triaging the bug. The Linux devs went with the latter, accept that all things that are possible will be done at some point. But this means that any kind of bug will almost always have security implications in some configuration you haven't even thought of.
That weird USB device bug that reads some register wrong? Well, that might be physically exploitable. That harmless-looking logspam bug? Will fill up the disk and slow down other logging, so denial of service. That privilege escalation from root to kernel? No, this isn't "essentially the same privilege level so not an attack" if you are using SElinux and signed modules like RedHat derivatives do. Since enforcing privileges and security barriers is the most essential job of an operating system, bugs without a possible security impact are rare.
Now seen from the perspective of some corporate security officer, blue team or dev ops sysadmin guy, that's of course inconvenient: There is always only a small number of configurations they care about. Building webserver has different requirements and necessary security properties than building a car. Or a heart-lung-machine. Or a rocket. For their own specific environment, they would actually have to read all the CVEs with those requirements in mind, and evaluate each and every CVE for the specific impact on their environment. Now in those circles, there is the illusion that this should be done by the software vendors, because otherwise it would be a whole lot of work. But guess what? Vendors either restrict their scope so severely that their assessment is useless except for very few users. Or vendors are powerless because they cannot know your environment, and there are too many to assess them all.
So IMHO: All the whining about the kernel people doing CVE wrong is actually the admission that the whiners are doing CVE wrong. They don't want to do the legwork of proper triage. But actually, they are the only ones who realistically can triage, because nobody else knows their environment.
The CVE system would be greatly improved by a "PoC or GTFO" policy. CVSS would still be trash, but it'd simplify triage to two steps: "is there a proof-of-concept?" and "does it actually work?". Some real vulns would get missed, but the signal:noise ratio of the current system causes real vulns to get missed today so I suspect it'd be a net improvement to security.
But you cannot PoC most hardware and driver related bugs without lots of time and money. Race conditions are very hard to PoC, especially if you need the PoC to actually work on more than one machine.
So while a PoC exploit does mean that a bug is worthy of a CVE, the opposite isn't true. One would overlook tons of security problems just because the discoverer of them wasn't able to get a PoC working. But it could be worth it, to maybe also keep the slop out.
The alternative is to treat all bugs as security bugs, which is valid since they by definition prevent the expected functionality of the program and are thus at least a DoS. This is essentially what Linux does. People don't like this because they often don't care about DoS bugs and it makes the CVE system pretty useless if they only want to see other sorts of security issues.
Depends on the location, but around here solar for heating is completely useless.
In Germany (which is farther south than the nordics and gets far more sunlight), solar panels are already insufficient for heating half of the year. On a typical single-family home, you will get at most 10kW peak power solar on the roof, which you can reach in the summer months when there are no clouds. In winter, those 10kWp will generate at most 5kWh of energy per day. Which is a factor of 4 to 5 below the 20 to 30kWh per average day for heating (with generous insulation). The farther north you go, the worse this gets. Half of the nordics get essentially no sun at all in winter, and are quite a bit colder than Germany.
So you need something other than the sun to heat your home in winter. A heat pump can double, maybe triple the solar energy you might get on sunny winter days, but that doesn't usually cut it. So you need grid electricity, wood or fossil fuels. And when electricity prices are as low as in the nordics (around or below 20ct/kWh), heat pumps are totally viable.
Adding solar can be sensible for cooling in the summer months, and maybe a bit of hot water, and heating in late spring, early autumn. But for winter? Totally useless.
And while you could do long-term storage, that will cost you several arms and legs, tons of space and a huge maintenance hassle. And if anything should go wrong with your storage, you have no heat all winter and better have an emergency plan...
There's a surprising amount of earth architecture in Germany. The walls are your storage ... not enough to last all winter, and not enough to make your house actually "warm", but enough to provide a baseline that smooths over energy availability issues.
Of course, it works even better with higher levels of insolation, since the exterior surfaces of the walls receive more energy during the day.
