Hacker Newsnew | past | comments | ask | show | jobs | submit | error503's commentslogin

They don't even need to know it is a thing that exists. The defaults (ie. the status quo of implied trust in the OS vendor) are fine for this type of user.

Sure. Now how are we going to stop them being talked into changing that by scammers, given that we’re not even explaining what that does?

Ultimate control over devices you own should be a basic right. Apple's wanton abuse of users and developers via the control they have over their platform, and Google's nipping at their heels, should be evidence enough of that.

Fundamentally, it is a trust issue. Why should I be forced to trust Google or Apple has my best interests in mind (they don't)? That is not ensuring 'device integrity', it's ensuring that I am at the whims of a corporation which doesn't care about me and will leverage what it can to extract as much blood as it can from me. You can ensure 'device integrity' without putting any permanent trust in Google or Apple.


Why should I be forced to trust Google or Apple.

You are not.

It's certainly convenient in this modern world to pay for and use one of their devices though.


That was intended to be a generic 'device manufacturer', not calling out Google and Apple specifically. It's my device. I should control it, full stop. It should simply not be legal for a device manufacturer to lock me out of a device I own, post sale. In the past it wasn't _possible_, so we didn't need to worry about it. But now the tech is at the point where manufacturers can create digital locks which simply cannot be broken, and give them full control of devices they sell (ie. which they no longer own), which are being used in anti-consumer ways.

Considering market forces are against it, I believe the only practical way to accomplish this in the long term is for this to be a right that is enforced by legislation. I don't think it is even far from precedent surrounding first sale doctrine and things like Magnuson-Moss, that the user should be the ultimate one in control post-purchase, it just takes a different shape when we're talking about computing technology.


It's my device. I should control it, full stop.

No one is forcing you to buy a particular device.


> No one is forcing you to buy a particular device.

True. But society in practice requires a smartphone with one of two operating systems to live a normal life without significant efficiency losses in your day. Now all phones with both of those will be completely walled off. You'll be forced to participate or make your life a lot less convenient.

Surely you wouldn't defend absolutely anything happening to say roads just because you're not forced to drive, technically speaking?


So you think it's okay for manufacturers to take advantage of users as long as they continue buying the locked-down devices? I disagree, and I think this argument is incredibly disingenuous. You could make the same specious argument about nearly any consumer protection or antitrust case. Just because consumers will put up with it, or because they are manipulated into believing it's good for them, doesn't mean they shouldn't be protected.

Furthermore, if you fundamentally allow this behaviour, the market forces are sure to push us to an end state where users simply have no control, and there are no viable alternatives. We are most of the way there already when it comes to smartphones. The cost of entry to this market (many $billions over many years, if you can even manage to gain meaningful marketshare at all), and the amount of money that is on the table (30% of the $billions transacted on a successful platform today, but who knows how far they push with a real stranglehold) means that it is virtually impossible for competition to solve this problem.


You are forced to trust Google or Apple if you want a smartphone. They own the whole market, it's a duopoly. You already have no power to install an OS without such limitations on most smartphones.

Limitations because it's not just protection - you don't get to choose which authorities you trust. Defaulting to manufacturer/OS vendor as the default authority would be ok, but there is no option to choose. Users have no power over their own device. That's not ok even if most choose to never execute it or don't know about it, it will lead to abuse of power.


Modern life without either of these OS (or like a phone number) is pretty difficult, i.e. you can't charge your car or access e-government without an app.

Time to support open source mobile OS's then.

I’m willing to sacrifice your rights if it means that there’s less incentive to steal my phone

why do you think you have any say over others' rights? using that same logic, you know what? i think you're going to steal my phone. so do you mind if i sacrifice your rights and install a camera right in your room? wouldn't want you to plot the theft of my phone now would i

If they're injecting targeted ads in the stream, then the stream producer must be 'smart'. It's not much of a stretch for it to enforce playing out the segments at approximately realtime (or whatever speedup they want to allow), and to force the advert segments to play out before anything past them. Some sidechannel could be used to inform the client about what's going on and produce a sensible playhead position.

It seems inevitable that this is the end game, and I don't really see viable ways around it for realtime playback. For offline playback, yeah, presumably that sidechannel includes enough information to cut out the ads.


Recovery codes is an option, for one.

Since we're talking about a legacy bank here, going to a branch and proving your identity is an option.

Worst case, you could always call and speak to a human who will do whatever verification they do if you forgot your password, which is functionally equivalent.


Do TOTP authentication apps typically provide recovery codes option? Can they squash all of the added TOTP codes you have in the app into one code?



There is a distinction between the variable itself and its name. Const (and Rust's immutability-by-default) ensures that the variable does not change after assignment. This holds true even as references to it are passed to other functions or stored for later use. You "can't" accidentally pass a reference to that variable which will then be unexpectedly mutated a dozen calls deep into a library function you didn't write.

If you have shadowing, it simply means you can have a different variable with the same name later in the same (or child) scope, this usually must be explicit. The same name now refers to a different variable, but the original variable still exists and remains valid.

It's quite a useful pattern, particularly where the old value is no longer useful (for example transforming input), especially when using the old value might be valid code but would be a mistake.


It's a bit ironic that this page doesn't include a usage of the icon or any localization at all.


The 'fan' in this very video is pretty dangerous, even ignoring its cobbled-together nature.


If nothing live or valuable is on the plane of it, absolutely no.


Did you even watch the video? He walks directly beside it several times.


It's an old anecdote, but years ago Samsung refused a warranty claim for a _failed USB port_ that would no longer charge the phone _because I had rooted it_ and the fuses were burnt. I think this was unreasonable of them, but it's not like I had any recourse. If vendors were really worried about this aspect, they would/could implement such draconian policies.


> I hadn't even imagined this constituting "brute force". Is my phone using "brute force" to find the WiFi router? At some point it's not really "Brute force" it's "There are a handful of options, try all of them" and GPS seems past that point especially on modern hardware.

Your phone only needs to listen to the WiFi router on one channel at a time in operation, and the signal parameters are well enough defined that they can be scanned quickly. A GPS receiver requires at least 4 parallel channels to achieve a position solution, and there are up to 32 possible codes the satellites could be at. Scanning 6 channels across 32 codes, and then also sweeping phase and doppler shift to lock them , just to 'discover' if there is a valid signal there takes time, and this is what older receivers had to do. Modern receivers tend to just 'brute force' this by having an entire receive pipeline dedicated to every possible PRN all the time, and possibly even correlate multiple doppler shifts simultaneously as well, so they effectively have 32 (or more) receive channels, despite only ever expecting a maximum of 12 birds being visible. The extra channels are necessary more or less exclusively to reduce acquisition time, so I think it's fair to call them 'brute force'.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: