What do you think of Nvidia Shield? I haven't tried it, but I think it should also belong to 2). It's clearly much more expensive than a FireTV, but as you say it shouldn't be subsidized by ads. As an Android device it should be more open than an Apple TV. While I recognize the near flawless UI and high hardware quality of most Apple devices, I disagree with their "golden cage" or walled garden approach.
The Shield Pro is perfect for me and I have no reason to upgrade. Have mine downgraded and de-bloated using this guide [0] running a custom launcher. Like you said being Android and more open helps a lot.
I see many people liking their shield, and with good reason it seems, but is it a worthy ecosystem to buy in to when it has not seen a new hardware revision since 2019?
This. The lack of a Shield hardware refresh seems insane.
I get Nvidia (the company) has other priorities with higher revenue.
But they have a product, with proven product-market fit, that gives them a last mile connection with end users, in one of the highest utilization home spaces.
How has no one at Nvidia looked at that and said "I'm not saying we orient our entire focus around it, but shouldn't we at least fund it as a strategic priority?"
If datacenter revenue falls off, it's going to look awfully short-sighted not to have diversified customer base when they had the chance.
What benefits would a hardware upgrade bring the end user? Not releasing a new model every year sounds like a perfectly good thing to me as long as they keep updating the software without introducing performance problems.
My biggest gripe with the Shield is the newest one has a remote that I really don’t like. Luckily it can be replaced with a third party remote!
I too think yearly updates are a bit too much and I too want to keep my devices for a long time. Still rocking an iPhone 12 (mini).
But support for newer codecs like AV1 and general hardware refreshes to keep up with the underlying Android base would still seem like good ideas to me.
Reading the specs it seems that the Shield also would benefit from being able to detect frame rate to auto-switch via HDMI.
Higher network bandwidth to play UHD Blu-ray rips seems like something people want.
I use the non-Pro version for 1080p streaming and have for years. It’s great, does what I want and gets out of the way. Some years ago they were forced by Google to use the standard AndroidTV UI instead of their own custom one, which means it now shows ads on the home screen (a carousel of “watch this on service X”), which are inoffensive enough I haven’t bothered to circumvent them. You can swap to your own custom UI if you want with some ssh futzing.
This is a good defense for malware that only has read access to the filesystem or a stolen hard drive scenario without disk encryption, but does nothing against the compromised dev machine scenario.
This seems to be the standard thing people miss. All the things that make security more convenient also make it weaker. They boast about how "doing thing X" makes them super secure, pat on the back and done. Completely ignoring other avenues they left open.
A case like this brings this out a lot. Compromised dev machine means that anything that doesn't require a separate piece of hardware that asks for your interaction is not going to help. And the more interactions you require for tightening security again the more tedious it becomes and you're likely going to just instinctively press the fob whenever it asks.
Sure, it raises the bar a bit because malware has to take it into account and if there are enough softer targets they may not have bothered. This time.
Classic: you only have to outrun the other guy. Not the lion.
Like, I see the comment about the Keychain integration and all that. But in the end I fail to see (without further explanation but I'm eager to learn if there's something I am unaware of) where this isn't different from what I am saying.
Like yes, my ssh key has a passphrase of course. Which is different from my system one actually. As soon as I log into the system I add the key, which means entering the passphrase once, so I don't have to enter it all the time. That would get old real fast. But now ssh can just use my key to do stuff and the agent doesn't know if it's me or I got compromised by npm installing something. And if you add a hardware token you "just have to tap" each time that's a step back into more security but does add tedium. Depending on how often my workflow uses ssh (or something that uses the key) in the background this will become something most people just blindly "tap" on. And then we are back towards less security but with more setup steps, complications and tedium.
I saw the "or allow for a session", which is a step towards security again, because I may be able to allow a script that does several things with ssh with a single tap, which is great of course. Hopefully that cuts the taps down so much that I don't just blindly tap on every request for it. Like the 1password thing you mentioned. If I do lots of things that make it "ask again" often enough I get pushed into "yeah yeah, I know the drill, just tap" security hole.
Keep in mind that not every agent is so naive as to allow a local client to connect to it without reauthenticating somehow.
1Password, for example, will, for each new application, pop up a fingerprint request on my Mac before handling the connection request and allow additional requests for a configurable period of time -- and, by default, it will lock the agent when you lock your machine. It will also request authentication before allowing any new process to make the first connection. See e.g. https://developer.1password.com/docs/ssh/agent/security
There is no defense against a compromised laptop. You should prevent this at all cost.
You can make it a bit more challenging for the attacker by using secure enclaves (like TPM or Yubikey), enforce signed commits, etc. but if someone compromised your machine, they can do whatever you can.
Enforcing signing off on commits by multiple people is probably your only bet. But if you have admin creds, an attacker can turn that off, too. So depending on your paranoia level and risk appetite, you need a dedicated machine for admin actions.
It's more nuanced than that. Modern OSes and applications can, and often do, require re-authentication before proceeding with sensitive actions. I can't just run `sudo` without re-authenticating myself; and my ssh agent will reauthenticate me as well. See, e.g., https://developer.1password.com/docs/ssh/agent/security
The malware can wait until you authenticate and perform its actions then in the context of your user session. The malware can also hijack your PATH variable and replace sudo with a wrapper that includes malicious commands.
It can also just get lucky and perform a 'git push' while your SSH agent happens to be unlocked. We don't want to rely on luck here.
Really, it's pointless. Unless you are signing specific actions from an independent piece of hardware [1], the malware can do what you can do. We can talk about the details all day long, and you can make it a bit harder for autonomously acting malware, but at the end of the day it's just a finger exercise to do what they want to do after they compromised your machine.
Do you have evidence or a reproducible test case of a successful malware hijack of an ssh session using a Mac and the 1Password agent, or the sudo replacement you suggested? I assume you fully read the link I sent?
I don't think you're necessarily wrong in theory -- but on the other hand you seem to discount taking reasonable (if imperfect) precautionary and defensive measures in favor of an "impossible, therefore don't bother" attitude. Taken to its logical extreme, people with such attitudes would never take risks like driving, or let their children out of the house.
You get the idea. It can do something similar to the git binary and hijack "git commit" such that it will amend whatever it wants and you will happily sign it and push it using your hardened SSH agent.
You say it's unlikely, fine, so your risk appetite is sufficiently high. I just want to highlight the risk.
It could have created a bash alias then. And I don't think a dev wants to be restricted in creating executables. Again, if a dev can do it, so can the malware.
A compromised laptop should always be treated as a fully compromised. However, you can take steps that drastically reduce the likelihood of bad things happening before you can react (e.g. disable accounts/rotate keys).
Further, you can take actions that inherently limit the ability for a compromise to actually cause impact. Not needing to actually store certain things on the machine is a great start.
What they should be tracking is average delayed journeys. A train may be late by 15 minutes, but if that means I'll miss a connecting train, that might delay my journey by an hour or more. That would also take care of the issue you're describing.
Indeed, that'd be a more useful metric. Very hard to measure well though and probably actually leaves open more room for them to game the metrics than the current system does.
Keep in mind that for the majority of trains in Germany, nobody bought a specific ticket for that journey. We just use the DeutschlandTicket which is a flat subscription of 58€/month, which gives unlimited access to busses, trams, and regional trains (basically everything but high speed trains).
With the deutschalnd ticket, you typically just walk onto a train of your choice and go wherever you want. They dont actually know where all the travellers are going or even how many people there are
Yeah I know you cannot track all journeys. Deutschlandticket, BahnCard 100, and similar things will be invisible. You can track the ones booked through the app though, and with a high enough sample rate you should get sufficiently close to the truth, unless there is a bias I haven't thought of yet.
You could also select random virtual journeys, I suppose. In arbitrary units you should at least be able to measure whether DB is improving or not. You could even delegate this to an independent organization. Actually, now that I think of it, isn't the API public? I'm reminded of the talk by D. Kriesel about DB data mining.
>> The main thing people dont understand about Germany's train system is the scale of it. The network is physically very large, but also very densely packed, and has very frequent trains.
> A train may be late by 15 minutes, but if that means I'll miss a connecting train, that might delay my journey by an hour or more.
Speaking from experience taking the subway in Shanghai, if a train is 15 minutes late, and it still manages to arrive before the train that was scheduled to follow it, it cannot be true that the network is "very densely packed" or that it has "very frequent trains".
A subway is very different from an intercity railway network. For one, there's probably fewer different routes on the subway so trains conflict with each other less. Also, a subway doesn't have to accomodate freight traffic as well.
The German intercity rail network certainly identifies more lines, around 57 to Shanghai's 18, but this isn't directly related to the complexity of the topology. For example, line 14 appears to begin in Aachen and dead-end into Berlin, at which point line 95 begins in Berlin and runs out to Poland. As far as the routing is concerned, those could be the same line. But they're given different numbers. When the same thing happens (at a smaller scale) in Shanghai at the west end of line 9, the tail bit of the line going to Songjiang is still called "line 9". Note that if you want to ride out to Songjiang, at some point you're going to have to get off your "line 9" train and walk over to another station where a different "line 9" train will take you the rest of the way.
Discounting that, the two layouts appear to be roughly similar on the fundamentals, if differently scaled.
The most obvious difference is that the routes between major German cities are served by several lines. This is clearly meaningful in some cases; line 29 from Munich to Nuremberg continues north to Hamburg via Berlin while line 41 from Munich to Nuremberg continues northwest to Dortmund via Frankfurt and Cologne. On the other hand, line 8 from Munich to Nuremberg parallels line 29 for the entire length of line 8 (line 8 stops in Berlin, but line 29 doesn't).
My first guess would be that conflicts arise from the fact that the German trains are on the ground, and when their tracks cross, conflict can occur. This isn't true of a subway system; when subway tracks cross, they do it at different altitudes, allowing both tracks to be in use simultaneously.
Not only do tracks cross, trains also share tracks and platforms. In Shanghai only Line 3 and 4 share tracks and platforms.
Your map only shows ICE/IC lines, there are many more other lines which share the same tracks. This shows a more complete picture: https://www.deviantart.com/costamiri/art/Transit-diagram-of-... but it still doesn't show international trains and freight.
How does that affect the question of whether the network is densely packed or whether it has frequent trains?
Passenger trains from Frankfurt to Cologne are infrequent because there is virtually no demand to move between cities 120 miles apart. Because the trains are infrequent, they aren't dense on the tracks.
But that's the opposite of saying that they are frequent and densely packed.
Read up on what affects railway bandwidth. A densely packed 250km/h line won't appear similar to a densely packed subway line to a bystander despite of maxing out its abilities.
I agree. Funnily enough I had a journey sped up due to a delay recently. I had a change, and the train I was changing to was delayed so that I could make the earlier one which I should have missed had it been on time.
I have a fire tv and run adguard, which does the same thing as pihole, and I can barely tell it's on. It may block some tracking, but I get an increasing amount of ads in the fire tv GUI, not to speak of YouTube ads.
Sometimes I wonder if the people recommending pihole actually tried it. You get much better value out of ublock, smarttube, and so on.
That's the conventional wisdom, undercut by the fact that people have guessed (and bet their fortunes) that previous bubbles were bubbles well before they popped.
Its more accurate to say that bubbles rely on most people being blind to the bubble's nature.
A lot? Also irrelevant. All it takes is one for the statement "nobody can see the bubble" to be false. Take the housing bubble for instance. Do you think the people who called that one were successful purely by chance, or does the fact that a few investors observed that mortgage lenders were underwriting loans to people with extremely poor credit and approving loan applications the lenders knew to be materially fraudulent at a massive scale indicate that the call was more of an educated wager? Did they know to a certainty it was a bubble? No, of course not. Was it a very reasonable guess? Absolutely.
reply