Idk about zero, my Android device has SMS spam filtering, putting them in a separate inbox, hiding the notification, and with big red warnings if I indeed open them.
Agree. I do a lot of travel and in 3rd-world countries it is quite common to get 2g spam, it's really unacceptable that Apple doesn't offer a way to turn off 2g short of lockdown mode.
Are you sure it's not sourced from the visited network? In that case, 3G or beyond wouldn't help you, as mutual authentication does not imply end-to-end authentication of all traffic between you and your home provider.
It's always amusing to me how apple tries to hide basic security features behind there super duper totally secure mode which nobody will enable because it destroys usability.
Meanwhile GrapheneOS in the default mode is as much or much more secure (and private duh) than there marketing mode with little to no usability decrease.
I was curious about this so I looked around a bit. My interpretation is that GrapheneOS still has not cracked this nut. Neither has iPhone, unless you enable "Lockdown Mode"
It doesn't matter what the network is doing; the phone needs to disable 2g. There's various ways to get the phone to downgrade to 2g otherwise, eg https://montsecure.com/files/2021_downgrade.pdf
And if you have a modern enough SIM+phone combo, it won’t even display the 2g network as an available network, nor 3G on my device.
I wonder if this mostly hit international SIMs, since they wouldn’t be running the same level of SIM code to prefer various network locks like a local SIM.
Helps you stay under the radar and gov services over SMS is a lot more advanced outside of Canada if you want to do some fraud.
>And if you have a modern enough SIM+phone combo, it won’t even display the 2g network as an available network, nor 3G on my device.
Source? It might just be that your carrier retired its 2g/3g network, not that the phone/sim refuses 2g/3g connections. If some cell tower popped up claiming to 2g/3g, your phone still might happily connect.
Unfortunately, I think there's no way for a SIM card to indicate to the phone that it would like it to please never connect to any 2G (or any non-mutually-authenticated) network.
Absent that, maybe this happens via a carrier profile (or equivalent mechanism)?
I don't think that matters, since the phone has no way of knowing from the SIM card alone whether it should still connect to 2G networks or not.
It sounds like a good idea to at least restrict 2G connections to non-roaming scenarios, but then you have the next practical problem: How does your baseband know that you're abroad?
Sure, all solvable at the application layer (the phone could use location heuristics to figure out where it is etc.), but not trivial and full of edge cases that could easily result in your phone mysteriously not connecting while abroad or, worse, not being able to make an emergency call or similar.
I also kinda figure there’s some magic running to “stick” to your home network where available/visible because of international border areas and people historically getting regularly upset about being roaming charges despite never leaving their home country.
SIMs can define both their home network (both implicitly since the IMSI starts with MCC/MNC of the issuer/home network, and explicitly in the form of a list of "equivalent networks", which is useful for MVNOs with their own MNC that don't want the "roaming" icon to show up) and a ranked list of preferred roaming networks. The phone should usually define those.
Of course, in some situations you might only get signal from across the border, and then none of these mechanisms can help.
I’d add in some high buildings in Toronto, if I did a network scan with a foreign SIM, I could see some US networks from over the lake, but with a Rogers SIM, they would not be visible in the scan.
That's incredible, here in Australia they not only shut down all 2G networks almost a decade ago, but they've already shut down 3G as well!
Although now looking at Wikipedia there are a lot more 2G networks sticking around than I realised, still hard for me to believe given what's happened here!
Funny enough its the tower that tells the cellphone modem which network is "better" and it does this in an unencrypted cell reselection message. So it is easy to force a phone to select 2G.
Probably some IoT/M2M contracts. Telus/Bell has really cut down on the spectrum allotted to their 3G that’s still up, and I doubt much is still assigned on Rogers’ 2G side.
Squash merge is the only reasonable way to use GitHub:
If you update a PR with review feedback, you shouldn’t change existing commits because GitHub’s tools for showing you what has changed since your last review assume you are pushing new commits.
But then you don’t want those multiple commits addressing PR feedback to merge as they’re noise.
So sure, there’s workflows with Git that doesn’t need squashing. But they’re incompatible with GitHub, which is at least where I keep my code today.
Is it perfect? No. But neither is git, and I live in the world I am given.
Yes, I think people who are anti squash merge are those who don't work in Github and use a patch based system or something different. If you're sending a patch for linux, yes it makes sense that you want to send one complete, well described patch. But Github's tooling is based around the squash merge. It works well and I don't know anyone in real life who has issues with it.
And to counter some specific points:
* In a github PR, you write the main commit msg and description once per PR, then you tack on as many commits as you want, and everyone knows they're all just pieces of work towards the main goal of the eventually squashed commit
* Forcing a clean up every time you make a new commit is not only annoying extra work, but it also overwrites history that might be important for the review of that PR (but not important for what ends up in main branch).
* When follow up is requested, you can just tack on new commits, and reviewers can easily see what new code was added since their last review. If you had to force overwrite your whole commit chain for the PR, this becomes very annoying and not useful to reviewers.
* In the end, squash merge means you clean up things once, instead of potentially many times
> If you had to force overwrite your whole commit chain for the PR, this becomes very annoying and not useful to reviewers.
I'd say that optimizing for reviewers who don't know "git range-diff" exists has even less merit that optimizing for contributors who don't know how to edit their commit graph.
I'm regularly using GitHub, GitLab, Gerrit, Phabricator and mailing lists and while some make it more pleasant than others, none of them really put any actual obstacles on your path when manipulating the commit graph mid-review.
Forcing a single commit per PR is the issue imo. It's a lazy solution. Rebase locally into sensible commits that work independently and push with lease. Reviewers can reset to remote if needed.
If your goal here is to have linear history, then just use a merge commit when merging the PR to main and always use `git log --first-parent`. That will only show commits directly on main, and gives you a clean, linear history.
If you want to dig down into the subcommits from a merge, then you still can. This is useful if you are going back and bisecting to find a bug, as those individual commits may hold value.
You can also cherry pick or rollback the single merge commit, as it holds everything under it as a single unit.
This avoids changing history, and importantly, allows stacked PRs to exist cleanly.
The cases where bisect fails you are, basically, ones where it lands on a merge that does too much - you now have to manually disentangle the side that did too much to find out exactly what interaction caused the regression. But this is on the rarer side because it's rare for an interaction to be what caused the regression, it's more common that it's a change - which will be in a non-merge commit.
The squash merge workflow means every single commit is a merge that does too much. Bisect can't find anything useful for you by bisection anymore, so you have to get lucky about how much the merge did, unenriched by any of the history that you deleted.
> But then you don’t want those multiple commits addressing PR feedback to merge as they’re noise.
They're not noise, they tell future maintainers why something is the way it is. If it's done in an unusual way they can see in the blame that a couple of lines were changed separately from the rest and immediately get an explanation by checking that commit.
It says: CAs MUST properly parse and interpret the integer timestamp value as a UNIX timestamp (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds) and apply the expiration correctly.
DNSSEC prevents any modification of records, but isn’t widely deployed.
We query authoritative nameservers directly from at least four places, over a diverse set of network connections, from multiple parts of the world. This (called MPIC) makes interception more difficult.
We are also working on DNS over secure transports to authoritative nameservers, for cases where DNSSEC isn’t or won’t be deployed.
This wasn’t the first version of the ballot, so there was substantial work to get consensus on a ballot before the vote.
CAs were already doing something like this (CNAME to a dns server controlled by the CA), so there was interest from everyone involved to standardize and decide on what the rules should be.
reply