"With JavaScript off, the page cannot tell you what your browser disclosed. The data is still there. The disclosure still happened. Only the telling of it stops."
I've never seen a bullying program which acknowledged that there were multiple types of bullying with different causes:
- Some Stephen King-styled cretin who is just big and dumb and wants to hurt people.
- Kids vying for status in an unhealthy way and trying to cut people down.
- That weird "smelling blood in the water" problem that happens when a group of people come across someone who is just _too_ weak and their biology just seems to rev them up.
- A weird kid who is socially maladjusted and thinks they're being bullied, but actually it's just that no one likes them.
This API also works on the desktop. In fact, you can't use this system without a phone if your browser isn't Google enough.
We are going to see sooooo many scams out there. No wonder Google is locking down third party Android apps outside of their control, getting a user to install "device verification.apk" will become super trivial after people have clicked through these popups a couple times.
A smart phone _could_ be legitimate and free and open, but in practice it's not. This is a constraint based on the reality of the market, not really based on what is strictly possible with the technology. I don't get too deep into this, but at a very high level, this is what I dislike about smartphones.
- Touchscreen user interface is objectively worse than a mouse and keyboard. Portability is the the only benefit to this interface, but this also works strongly to attack impulse control. It's always on you, just a moment away.
- Smartphones are significantly worse for privacy. In a LOT of ways. We can discuss this if you're interested.
- Many smartphone apps exist solely because a website would be less addicting and would also not be able to collect as much data as an app. ie, it's a choice that's worse for you and better for the company.
- They're significantly less open. Yes, grapheneOS and other alternatives exist, however it's not like a computer where I can just install whatever I want without asking the provider permission to unlock the device.
- I touched on this in two other bullets, but it's worth highlighting here: they're built intentionally to be addictive.
- The operating system and hardware are effectively interlocked. (yes, I know grapheneOS exists) but for any modern thing you might actually require a smartphone for (banking app, OTP app, etc) you must be using Apple or Google.
- Providers don't produce security updates well enough; Apple is "better" here, but my 10-15 year old computer can run modern Linux. People brag about 7 years of support on an iPhone. I'm under the impression that Android is better than it used to be, but in the old days any random vendor would give you about 1 year of update support and then you'd be hosed running old Android until you bought a new phone.
- Nobody cares if I own a desktop computer or not, but it's getting to the point that businesses will not work with me unless I have a modern smartphone.
I could probably go on, but I really hate these things.
> Touchscreen user interface is objectively worse than a mouse and keyboard
au contraire, touch screen is objectively better, and i dont buy laptops where the screen isnt a touch screen. cursors and mice and focus on laptop+mouse UXs is just horrible, and for keyboard only even worse.
the touch screen is much simpler, in that you touch or swipe on the thing, and it makes the motion in direct response to what you touched. the input is physically linked into the interaction, rather than some changing relative position.
Yeah I'm aware of all of this, it's just the framing that confused me. A lot of these boil down to "nobody should own or use a smart phone to do anything" which is a bit of a different and less specific pitch than "nobody should browse the web on a smart phone".
It is, just like a calculator is a small computer. It's not a personal computing device though, in the sense that the user can't develop and deploy their own software/tools on it.
No one should ever browse the web from an ESP32 either. Like seriously the dark patterns are bad enough from a desktop where you've actually got the screen real estate to see the whole page, have other sites open for comparison, have a keyboard to type your own notes, etc. Most browsing can simply wait, especially the adversarial-commercial type we're talking about here.
A device I have no choice in owning because modern employers assume you have sometime to install an authenticator app on. That's what it is for me. Also, sadly, it's an anchor for Signal. Otherwise I don't use the stupid thing.
and it seems Google wants to support people like you!
That entire QR barcode thing is so that you can browse the web on your laptop/desktop, and _still_ rely on smart phone's attestation, no mobile browser needed.
The modern discourse is quite rough -- people have been making these equivalencies for quite some time -- but as the US behavior becomes worse and worse, these equivalencies become more and more true. And as they become truer, the people who have always been pushing them only feel vindicated.
It's quite unfortunate, but I can't say I blame them. From their perspective the tiger is finally showing its stripes.
I've been saying for years that it does not make sense to browse the web on a smartphone. Eventually things will get bad enough that people will agree with me.
“On an infinite timescale, I’m eventually right, so it never makes sense to not heed my advice” is silly. We’re all going to die eventually so it’s not worth browsing the web on any device.
I’m familiar with projects like them. I just don’t think any of them are going to break through in a meaningful way anytime soon, if ever. They have very niche markets. I hope they are always an option though.
The prospects for growth are better than ever. GrapheneOS by installer download stats looks to have approximately a quarter of a million users, and the new Motorola partnership should cause that to increase significantly.
Graphene is still tied directly to Android and Pixel devices. It is always at risk. Good luck if Google decides they don’t like the project enough. I went through that nonsense with Canon and magic lantern years ago. Firmware 2.3 was specifically designed to break it on all DSLR’s
The Magic Lantern Canon thing was terrible. Although I heard it is back, for whatever that is worth.
But that is a fair concern. While GrapheneOS will continue to support Pixel devices as long as they can, they will not be beholden to Pixel devices once the Motorola partnership is up and running.
They will be beholden to Motorola, instead! But it is a non-exclusive partnership and it sounds like the intention is to move beyond a single OEM. I am hoping that within a few years we see a small number of OEMs all meeting the device requirements GrapheneOS has set, with real consumer choice and more room for the project to maneuver as it sees fit.
In terms of being tied to AOSP, that is a given for the near term. It is still the best option out there and offers the most robust existing ecosystem of apps that has both FOSS options and highly useful closed source options. Major banks are not going to tell Motorola that their customers can't use their banking apps, though I still use 4 or 5 major banking apps on my GrapheneOS devices without issue beyond one bug where it was quickly fixed.
That will probably happen before modern chipset makers open source their blobs (never?), so I view that as a great compromise that should result in devices that are even more secure, even more private, but still usable by people who live in a society. And it will reduce the dependency on Google significantly as it will give room to non-AOSP apps to run on contemporary hardware with contemporary security.
This is Walter Schulz, core team member of the Magic Lantern project and been there back then when Canon introduced firmware 1.3.6 for EOS 5D3. Not sure what you mean by "Firmware 2.3".
Let's clear this up:
- Canon came up with 1.3.3 to 1.3.5. This disabled in-cam downgrade via Canon Menu. But it was still possible to use EOS Utility's firmware update option to install 1.1.3 or 1.2.3 (or any other version up to 1.3.5).
- There were no additional locks installed. We always had the option to port ML to 1.3.3 or 1.3.5. We could but we don't wanted to and there was no need.
- Other cams didn't get this treatment.
Then came 1.3.6 which disabled the EOS Utility option, too.
Now it looked like Canon forced our hand and we were forced to port ML to 1.3.6.! Meh! But no additional locks either. Porting ML to 1.3.6 essentially was the same as for 1.2.3.
Some users got 1.3.6 installed during maintainance because Canon Support installed this version without asking.
Some (singel one or more, don't remember) went back and asked for downgrade in order to use ML again. And Canon Support did that. Not exactly the action you expect from a company with the intention to block ML, right? ;-)
It didn't take long and user Apollo7 came up with a method to bypass this downgrade lock.
Which came handy because of a publicity stunt by someone: https://research.checkpoint.com/2019/say-cheese-ransomware-i...
"Strange" attack vector for sure. Well, it made news and Canon reacted by patching several camera firmwares for ML-enabled cams (but not all of them!).
But again: There was no lock making ML development for patched firmware more difficult or even disabling it! It would still be possible to port ML to any new firmware. We just wanted to avoid the load of unwanted work. Porting is no joke and may result in headache. Lot of work.
But today Canon upped their game. They learnt how to use real security features and newer cams won't allow our old methods to work. True.
So ... can you please stop the nonsense "was specifally designed to break it on all DSLRs", please?
With all due respect, this event was literally over a decade ago so yes I apologize that I got some numbers/info wrong, but the light derision at the end is unnecessary. I distinctly remember the firmware update they did making it so you couldn’t boot magic lantern on the 5d3 which caused a problem for us on a shoot where we had the raw pipeline ready to go. I thought it was broader. Clearly my memory is mistaken, I was just using an example that I (apparently incorrectly) recalled. https://www.eoshd.com/news/canon-blocking-magic-lantern-late...
I was and still am a big fan of the project. I have a t3i still in service because of it. But it is disappointing to receive the tail end of that comment from your account you apparently made just because I gave a quick, flawed example to make a larger point that in no way reflected on your efforts or magic lantern. It was to illustrate how quickly things can go south if a company determines to make it so. Which it sounds like is currently the case with Canon.
Appreciate the clarification nonetheless and have a nice weekend. I know it wasn’t the rudest thing online but for some reason your tone there just kind of got to me. Apologies if it seems like an overreaction. I was a long time admirer of your work so that’s probably why
I researched a phone which should work with lineageOS.
When I received it, I had to find some archaic website and _ask permission_ from a vendor to have the phone unlocked.
From there, I tried to image it from adb and using "guides" (ie, forum posts) and nothing that worked for everyone else ever worked for me.
On paper, installing an aftermarket OS on a phone is not much more difficult than installing an aftermarket OS on a computer. In practice, it's incredibly frustrating and a bit of a crap shoot.
The number of people worried about a slightly thicker phone are absolutely baffling to me. I honestly think there is no hope for us broadly. Normally I'd say that people cannot deal with minor inconveniences -- but this does not even register as an inconvenience.
From my view, this is a _perceived_ downgrade in luxury status. Not even a real downgrade in luxury status -- and not a downgrade in convenience whatsoever.
A slightly thicker back so that in four years time it will take me 5 minutes versus 60 minutes to change the battery? Yes, that sounds like something I am not interested in.
Because the reason for it is not valued by most of us. I do not care about a removable battery. I do not care. I value it at zero. So yes, I do not want to be inconvenienced for something I value at zero.
Well ... I don't have an Apple Store anywhere near me, so ... Or anything else, really.
And having multiple batteries would enable me to swap the battery and charge the expended one in near real time. No cord, no puck, nothing. And if the phone had an internal 100 or so mah battery also, I wouldn't even have to restart the phone!
I'd like a thicker, smaller phone (like 5") which can actually be operated with one hand. Ideally it should also be durable enough to not need a protective cover.
(My Kyocera Duraforce came close; too bad it was locked to AT&T.)
How tf did phones even become a "luxury" status symbol? They're just portable computers that also happen to be covered in nasty germs. People are freaking weird.
Anything can become a status symbol; humans love showing off. An expensive high-tech piece that's thinnest in the world? Yes please. Shoes or neckties seem to be even less probable status symbols, but.
This is just flat out wrong. Making it removable means making it less effective, meaning using more materials etc.
What is much more concerning is that you seem to be totally fine with the government deciding how something should be designed for not reason what so ever.
Ladybird, at least initially, will be niche enough that I think this won't be a problem. It'll be tech enthusiasts who use multiple browsers. If it can get a foothold, then I think there will be many more bars to clear.
>If they have custromer feedback and focus groups like they mention how did it happen in the first place?
This is part of the modern UI paradox. Never before has UI and UX gotten so much attention, and logging, and tracking, and research, etc. But of course with all that additional attention UI and UX is generally getting worse over time. I have my theories why, but I'd bet they're paying for decent talent here and are coming to the wrong conclusions.
They aren't doing all that research to make their product better for you, they're doing it to make their product better for them. Those metrics help them design to keep you on [platform] for as long as possible, consuming as much [product] from [company] as possible. It benefits them to be easy to do the things they want (buy something or view ads) and hard to do things they don't want you to do (leave, change settings, generally take any kind of control)
This is the only topic that tempts me to create a throwaway account. (I have not given in) None of the IPv6 proponents are willing to acknowledge that IPv6 is a pain.
All of them seem to have gone to some secret seminar somewhere where they receive their talking points:
- Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall.
- There's absolutely no downside whatsoever to being publicly addressable. (also this is a good time to reiterate that NO ONE understands that NAT is not a firewall)
- 128 bit addresses are exactly as convenient and memorable as as 32-bit addresses.
- The entire internet would be hosting home servers if not for the evils of NAT.
On my network, if it's not DNS, it's IPv4. IPv6 just works. I wish websites would hurry up and get with the times so I could turn off this old pile of hacks already.
> Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall.
It would be easier if IPvOld proponents didn't keep saying that it is. Seriously, every time this topic comes up, at least one person expresses horror at the idea of running IPv6 without a firewall, unlike their safely NAT-firewalled IPv4 setup.
> There's absolutely no downside whatsoever to being publicly addressable.
I won't say there's no downside, because such a thing is possible. It's just that I've never actually heard one outside weirdly contrived scenarios like "but what if they're not using a firewall", which is something you'd have to go out of your way to do.
> 128 bit addresses are exactly as convenient and memorable as as 32-bit addresses.
It's more realistic to say that IPv4 addresses are less horrid than IPv6, while still horrid. Who are all these people who don't like using DNS?
> The entire internet would be hosting home servers if not for the evils of NAT.
Um, true. I was on the Internet before NAT became popular, and P2P connections were the norm, not some weird thing you had to hack up with a STUN broker or such. NAT, more than any other single technology, worked to turn the Internet from a collection of peers to a producer-consumer arrangement. There's no scheme in which having the possibility of P2P connections is worse than only allowing client-server.
How do I use DNS on my home network to set up my home router? It's the same problem as TLS certificates on web interfaces for infrastructure.
And the commercial solution is going to be "pay us a subscription fee so your home device can get an Internet management interface on top of all the egregious data collection".
I think if they just double the address length the people would still cry about how 111.211.234.231.189.243.253.100 too hard to write and remember... There is no helping with people.
On extra byte shoved in a reserved field would have created 256 internets. That's two more for big countries and another for each small country and other planets. Then write in hex so addresses are shorter, require dhcp/sec etc, solved. My proposal for IPv7. ;-)
> On extra byte shoved in a reserved field would have created 256 internets.
Ah yes, the old IPv4 with 'just' adding more address byte(s) idea (you "IPv7"):
So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv7" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
Deploying the new "IPv7" code will take time, there will partial deployment of IPv7 is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:
(This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.)
A node having 198.51.100.42 and 7.198.51.100.42 (or 198.51.100.42.7) is dual-stack: one address is for the IPv4 protocol and other is for the IPv7 the protocol.
You need different DNS records for IPv7 and new API calls. You need Happy Eyeballs so that if 7.198.51.100.42 fails your application falls back to 198.51.100.42. It's the exact same situation.
There’s not two there’s one, the longer. There will be old equipment that can’t handle the new but would have been mostly replaced over time, perhaps a deadline. Like phone numbers or hdtv.
yeah and the global migration to add bits is already so expensive, if you're adding bits you shouls add a lot of bits so it only has to be done once. Wish they'd made it 256 bits actually, it could fit cryptographic hashes for secure routing protocols of the future.
You forgot important thing: There will always be some security guy yelling that leaking your internal IP structure is bad.
There will also be another clown that does IP whitelisting as security measure and refuses to just whitelist single /64|/24 network "because it is too wide" (I literally had this conversation last week with one of the clients)
> - The entire internet would be hosting home servers if not for the evils of NAT.
But NAT is _not_ a firewall. It's entire purpose is to allow traffic through. There's a million dozen tricks attackers can play, e.g. tricking a PC into sending traffic to some address will usually allow all traffic from that address back into one's precious network.
This is a common misconception and very dangerous -- I see a lot of people, ISPs even, who seem to think NAT is enough and you only need the firewall for IPv6.
Their NAT-phobia was legendary, and it carried through to other WGs as well like IPsec. The fact that IPsec broke NAT was a feature because it would force everyone to move to IPv6 ,for example.
The downside of publicly-addressable hosts is actually acknowledged in things like RFC 6092, but REC-49 is that routers provide a clear firewalling option that MAY be default-allow.
Works but addresses are unreadable. Ensuring security on a small network is more difficult than it needs to be when addresses are gibberish. Still not sure mine is on IPv6.
SLAAC and link-local is very different from DHCP/NAT/etc. in IPv4 world. Link-local addresses are pretty arcane in IPv4 while they are a central idea in IPv6.
That’s fine. As pointed out elsewhere, DHCP was relatively new when IPv6 was introduced. But it is a learning curve well past just knowing the difference between NAT and stateful firewall.
This is surely only partially true.
reply