I think that with the current iteration of Play Integrity (that more strictly enforces hardware-based security where available), Google actually introduced an additional certification level for "genuine OS and has recent security updates".
The difference though is that there are many more people with outdated phones than there are people with unlocked bootloaders and/or root, so a company might be loath blocking a sizeable fraction of customers with outdated phones, but have no compunctions about the latter, much smaller group.
The Digitale-Dienste-Gesetz (https://www.gesetze-im-internet.de/ddg/__5.html) in § 5 imposes this requirement on "geschäftsmäßige, in der Regel gegen Entgelt angebotene digitale Dienste", i.e. "services operated in a business-like manner, usually against payment". The key word here is "geschäftsmäßig" (literally translated "in the manner of a business", "business-like"), which within German law is held to be a weaker requirement than "gewerbsmäßig", that is "commercial".
"Geschäftsmäßig" can be anything you keep on doing regularly, independently of any profit motives – you can find a few discussions of that online, and amongst other things, the same term was also used in now-overturned legislation against commercial assisted-suicide, where it caused the same interpretation problems whether doctors or non-profit associations nonetheless might be construed to be acting "geschäftsmäßig" even if they didn't take any payments.
The "usually against payment" bit means that anything done for money can unambiguously by default be presumed to be business-like (and even worse, one possible additional interpretation is that anything other people usually do for money can be argued to be "geschäftsmäßig", too, even if you yourself offer it for free), but the reverse isn't necessarily true.
The other relevant law is the Medienstaatsvertrag (https://www.die-medienanstalten.de/fileadmin/user_upload/Rec...), where an exception from the imprint requirements in § 18 is made only if operated for "persönlichen oder familiären Zwecken", i.e. for "personal or family purposes". (And journalistic offerings, which can potentially cover some blogs or forums for example, are even subject to extended imprint requirements.)
The "family" bit is relatively clear, but "personal" purposes are once again more interpretable. A wide reading of "personal" would indeed cover all sorts of non-commercial hobby pages, though in that case you could ask yourself the question why a separate exception for family purposes would then still be required, too?
A narrower reading of "personal" on the other hand would only cover stuff that's literally only intended for you, like login pages to your personal webmail or Nextcloud instances, your private picture or file hosting and similar things. Some lawyers even go as far as including a private diary (that for some reason however you decide to publish online and even without password protection) within the category of "personal" things (though depending how much your diary refers to identifiable outside entities, it could also be construed to be a journalistic offering and therefore definitely subject to imprint requirements), but that's about the limit.
Hobby pages intended for the non-specific general public (outside of just family and friends) are therefore very much in a grey area as to when exactly the imprint requirements are starting to become applicable even if you don't do any ads at all.
Given how on the other hand a few years ago there was this big brouhaha about full WHOIS data being publicly available (it no longer is), it seems a bit schizophrenic, but there you are…
(That said, while I do think that the full imprint requirements are a bit overblown for private hobby pages, the reverse situation in the US also seems a bit weird, where even seemingly legitimate smaller online shops often don't seen to provide any proper contact data beyond some anonymous e-mail or contact form…)
Especially among business accounts, "power users" shouldn't be that uncommon, though, because I don't think that wanting to directly access your bank accounts via your accounting software is that exotic an usecase.
Though on the other hand, from some point of view maybe business accounts enjoy less legal protections against customer stupidity, so banks might be more willing to offer direct access there…?
Re Fallersleben, I think you're confusing Fallersleben (2002) and Leiferde (2022).
The former was an actual safety-critical error in the LZB software, leading to the rear train getting an erroneous movement authority after a restart of the LZB control centre. This was fixed with a corresponding software update.
The latter was indeed somewhat comparable to the current situation – a train operating under LZB in partial block mode dropped out of LZB, and the signaller didn't properly verify whether the line ahead was clear before authorising the train to restart and did lead to on-sight running being mandated for that kind of situation (dropping out of LZB in partial block mode).
> If we can design self-driving cars, that operate safely in far less controlled environments
Self-driving cars aren't supposed to drive quicker than they can look ahead, which makes the problem way easier because you don't have to figure out how to detect obstacles ahead of time and can simply rely on vehicle-local information to stop if necessary. And because cars can brake way more rapidly than trains, it means you can still drive reasonably quickly even within that limitation.
Plus in an emergency, cars have steering as an additional degree of freedom to attempt getting out of any nasty situation that may have developed.
(And of course the socially expected safety standards for cars are quite a bit lower than for public transport…)
Trains on the other hand have braking distances on the order of a kilometre or so, and high-speed trains at full speed several kilometres, so trying to get by on local data only is hopeless and the usual strategy is instead having central signalling system that can accurately track trains and coordinate their movements.
Yes, but as long as the central signalling system is working, it already knows where the train is, with no need to involve GPS. (And where modern signalling and train protection systems need increased precision as compared to the granularity of track circuits/axle counter sections, the solution usually involves a combination of on-train odometry plus track balises at occasional intervals in order to reset any inaccuracies that might have accumulated.)
What we're talking about here is some sort of TCAS-equivalent for the case where the central signalling is down – while it's easy to accurately localise trains with the aid of a central signalling system that authoritatively knows about the infrastructure layout, it's quite more difficult when you're trying to do the same thing in a decentralised, train-local fashion.
And as of now, I suppose that RCAS (or RCAS-like systems) is best suited for (especially minor) single track branch lines that don't currently have a full-scale signalling system already up-and-running, but instead still rely on "Timetable & Train Order" and similar systems.
Single track means that at least outside of stations, collisions can be reliably identified without much danger of false positives (and for station areas you can just institute a blanket speed limit to compensate for the gap in RCAS coverage, which might not even be any lower than the speed limit required for traversing diverging/spring-operated/hand-operated points there anyway), and no already existing full-scale signalling system means that RCAS actually provides a significant safety benefit and is therefore likely worthwhile from a cost-benefit-analysis point of view, too, if you're actually regularly operating multiple trains simultaneously on that kind of infrastructure.
Whereas on multi-track mainline railways avoiding false positives is much harder and normally you should already have proper signalling and train protection systems in place anyway, so the additional safety benefits of RCAS would be much more marginal.
> Update. A second security system should had stopped the train automatically in the next red semaphore (or reduced the velocity to 40Km/h) without machinist intervention. That system was down also.
No, it wasn't, from the way things have presumably played out, the scenario has simply hit an inherent design limitation. Namely LZB (https://en.wikipedia.org/wiki/Linienzugbeeinflussung) is the primary signalling and train protection system, but as a fallback, conventional colour-light lineside signalling together with the corresponding conventional train protections system (ASFA) has also been provided.
As a fallback system however, the lineside signalling has been set up with much longer signalling sections than the LZB, i.e. one conventional signalling section comprises multiple LZB signalling section. As such, it is still perfectly safe and serviceable, with the only immediate drawback that capacity will be significantly reduced due to the longer signalling sections (and also slower running speeds – the lineside signalling is limited to 200 km/h max).
The only problem comes in when you need to make an unscheduled transition from LZB to lineside signalling because of an LZB fault – while at first the trains will be safely braked to an immediate stop, you may now have ended up with multiple trains (all safely inside their own LZB block section) within the same lineside signalling block section. Which means that now there is no "next red semaphore" to prevent the second/third/… train from running into the train in front.
The proper procedure therefore is to untangle the trains by running them out of that accidentally shared block section one at a time and most likely at a reduced speed, too, but for some reason that procedure wasn't followed here…
> TPWS is where a little light comes on saying it would be a good idea to brake now because you passed a signal at danger. Only very fancy versions of TPWS will actually apply the brakes for you.
You're confusing AWS and TPWS – AWS is the older system (based on pre-WW II technology but only deployed nationwide after WW II) which sort of roughly fits your first sentence, while TPWS will actually stop you if you're trying to pass a signal at danger (with the caveat that most automatic signals on the plain line aren't fitted on the basis that a train will relatively rarely actually have to stop at one – statistically that's absolutely sensible if you only have a limited amount of money and want to cover the higher risk signals first, but unfortunately the recent Elstow train crash did manage to hit that particular gap in the system…).
> But even then, an inquiry asked to look specifically into ATP determined we were right to reject it, it was just Too. Fucking. Expensive.
But you did eventually get TPWS which does deliver a quite large fraction of the safety benefits of ATP at a significantly smaller fraction of the costs.
You're conflating multiple things – 1. train detection (which can be track circuits, as described by you, axle counters or on the most modern systems even train-based train detection), 2. how to transmit the stop/go information to the train (driver), and 3. how to ensure that the train (driver).
LZB (the "German system that is more advanced that basic electrical fault based system") does 2. and 3., but in its usual mainline implementations still needs a conventional train detection system.
> it was just switched off because it was broken. That's downright reckless, and it shouldn't be a normal behavior.
The Spanish line in question is actually equipped with conventional colour-light signalling (and the corresponding conventional train protection system) as a fall back, which is perfectly safe, too.
The only critical bit (which by the looks of it unfortunately failed here) is managing an unplanned transition between the two, because for reasons of cost, the fallback signalling utilises much longer block sections than the LZB signalling, so if the LZB fails unannouncedly, you can end up with multiple trains (each inside its own dedicated LZB block section) inside the same line-side signalling block section, so restarting the train needs to be safely managed by getting them out of the accidentally shared block section one at a time.
The difference though is that there are many more people with outdated phones than there are people with unlocked bootloaders and/or root, so a company might be loath blocking a sizeable fraction of customers with outdated phones, but have no compunctions about the latter, much smaller group.
reply