> What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside.
The problem is that strict file system sandboxing in particular also breaks a substantial number of workflows that can't be modelled as 'only ever open the exact file the user explicitly' picked. (Any multi-file file formats are particularly affected, as well as any UI workflows that don't integrate well with strictly having to use the OS file picker.)
So you need some escape hatch for optionally allowing access to larger swathes of the file system, or even really everything as before, but that in turn then risks being abused again by malicious actors. And then…?
Plus things like Android's implementation initially using an API completely incompatible with classical file APIs, as well as causing some noticeable performance overhead even today if you need more than simply accessing the occasional single file here and there.
I think had the problem is that the toolbox we can deploy to solve these problems is so empty.
For example, it’s useful for a music player with metadata editing features to have read/write access to the whole filesystem, but that constitutes a significant risk since all we can do is wholesale allow or prevent access to the whole filesystem. What if the system could allow it to access only music files, though? That’d scope the risk back down to almost nothing while also allowing the music player to do its job.
This is the kind of thing I’ve been getting at in the other replies. Nobody has really sat down and given system level security controls a deep rethink.
I think Apple's implementation in macOS is the only one that offers some slightly more advanced features, but even those don't get you that far
(Some sort of way to store permission references with relatives paths in a file, but which most probably wouldn't work with files being exchanged cross-platform, and other than that mainly being able to get automatic access to 'related' files, i.e. same file name, but a differing extension – that solves some sidecar files, like video subtitles, or certain kinds of georeferenced images, but large capability gaps still remain – even the video subtitle example stops working if the file name is no longer 100 % the same, like if you have multiple subtitle files for differing languages, where VLC for example supports prefix-matching the video file name with the subtitle files.)
And while your idea does have its merits, I fear that pretty soon you still hit a point where you can't sensibly and succinctly display those more complex types of permissions in the UI.
> And while your idea does have its merits, I fear that pretty soon you still hit a point where you can't sensibly and succinctly display those more complex types of permissions in the UI.
I could very well be wrong, but my inclination is that it's possible, but it's going to take the sort of fundamentals R&D that desktop operating systems haven't seen in decades. It can't just be tacked on, everything to be designed with this new system in mind.
> I vaguely recall it not being compatible with either 25kV electrification or high-speed rail in general, and most modern tracks therefore using axle counters instead.
Track circuits aren't incompatible with that per se, but axle counters are simply easier to install and much more maintenance-friendly – no longer having to worry about
- mixing track circuit currents and traction return currents together
- having to keep the rails sufficiently isolated from the ground and each other to prevent the track circuits from falsely showing occupied
- insulated block joints
- having to use each bit of track once every twenty-four hours to prevent rust from falsely showing a track as clear
- extreme leaf fall and/or sanding potentially causing false clears, too
- length restrictions on the maximum length of a single track circuit, although that's only really a problem on more sparse trafficked lines with long block sections
In return, axle counters have the drawback that they
- don't detect broken rails (although it needs to be said that track circuits very much aren't perfect broken rail detectors, either)
- can be falsely reset (with more or less protections, depending on local operating practices)
- don't detect maintenance vehicles freshly placed upon a track until they enter the next axle counter section
but since most to almost all new installations seem to use axle counters, the trade-offs are apparently worth it to infrastructure operators.
Airplanes might be designed in mm, but airports are most likely designed in metres, and whoops, suddenly you need to convert between the two.
Actually civil engineering as a whole is probably a relatively mixed bunch – vehicles drawings (when you need to design the infrastructure to fit specific vehicles for example) and other small-scale details might be dimensioned in mm, the standard curbstone naming system in Germany is based on centimetres, while infrastructure design itself (definitely including the CAD drawings) usually works in metres.
Vehicle drawings (maybe mechanical engineering in general) might be in millimetres, but a lot of civil engineering works in metres, so when designing some bit of infrastructure to fit certain kinds of vehicles, I do need to convert between the two, and the easier, the better.
For practical purposes there's the problem (at least a few years ago?) though that Akamai in particular uses DNS to steer you to the correct portion of its CDN and the default IPs returned by independent DNS resolvers tended to have relatively abysmal peering with the Telekom network that was getting completely overloaded at peak times.
Unfortunately "use <insert favourite DNS provider here> everywhere except for Akamai CDN, for which use the Telekom DNS" isn't something that consumer routers support, so you'd have to start running your own custom DNS resolver to work around that problem…
> Miles are great to estimate time of travel by car, take 1 minute per mile of distance on a highway and 2 minutes in the city and you will be pretty close.
That might be true where you live, but it's hardly a universal constant. 1 minute per mile might be sort-of-universal for long distance Interstate driving, but then again, you can just as easily phrase that as ~1 hour per 100 km in metric.
I'm rather doubtful about your 2 minutes per mile (= 30 mph average speed) figure for "city" driving, though – how's that even possible when urban maximum speeds are usually in the 25 – 40 mph range, and that's not counting time lost for traffic lights and other intersections, general congestion and parking?
Checking a few destinations around where I live in Germany, non-Autobahn cross-country driving is closer to 2 minutes per mile rather than 1 minute per mile (and highly variable depending on your exact destination, so no point trying to estimate driving times to the nearest minute, anyway), and never mind actual urban driving.
>That might be true where you live, but it's hardly a universal constant.
I have not said it's a universal constant, it's true in the US, where we use miles. ~1 hour per 100km is not as easy.
I cannot say I care much if you are doubtful, especially if you live in Germany and not in the US, I doubt many people in the US will care about your doubts too.
The problem is that strict file system sandboxing in particular also breaks a substantial number of workflows that can't be modelled as 'only ever open the exact file the user explicitly' picked. (Any multi-file file formats are particularly affected, as well as any UI workflows that don't integrate well with strictly having to use the OS file picker.)
So you need some escape hatch for optionally allowing access to larger swathes of the file system, or even really everything as before, but that in turn then risks being abused again by malicious actors. And then…?
Plus things like Android's implementation initially using an API completely incompatible with classical file APIs, as well as causing some noticeable performance overhead even today if you need more than simply accessing the occasional single file here and there.
reply