Can’t use iCloud with “true” as the last name
twitter.com
twitter.com
https://support.apple.com/guide/tv/use-siri-dictation-atvb21...
I have enabled the tv remote on control center - I’m not sure if it’s there by default. You should be able to toggle it in settings
In my opinion, it is more reasonable to assume that most websites will behave correctly with even longer passwords, and solve the odd misbehaving ones on a case by case basis.
I haven't yet, in my many years of "being on the web" encountered a single website with the truncated password problem described above, so for me, it's a weird statistical anomaly to be ignored.
If you have been burned repeatedly by some such websites, you will have a different outlook, and will generate your own passwords accordingly.
I use “correct horse battery staple”-style[1] passphrases now because they're still long and secure, but also memorable, so I don't have to enter passwords character-by-character, and I've memorized all of my most-used accounts now and don't need to look them up. 1Password can even generate these types of passwords automatically.
The only annoying bit is when services have arbitrary restrictions like “no spaces”, or “mix of capitals, lower-case, numbers, and symbols”. In those cases I use hyphens instead of spaces, or stick “A1!” on the end.
There's no concern about dictionary attacks, since there are too many "words" of multiple "symbols". The symbols just happen to be composed of sequences of ASCII characters, instead of single characters. The analog for regular passwords would be a dictionary consisting only of single letters/numbers/symbols.
The input type="password" element allows for passing information to browsers / password managers what the limitations:
* https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
maxlength, minlength, pattern ("A regular expression the value must match in order to be valid").
Until relatively recently, they silently truncated the password that literally protected your bank account to 8 characters.
But I’ve used other services (Facebook, for example) that interpret my last name as a boolean and throw errors.
Edit, just looked up the mail
- It was an 'equals' sign
- the reply was:
" It sounds like you cannot cause someone else's account to be in this state, only your own account. Is this correct? How would you get someone else to change their account name so that it includes an equals sign?
It appears that there's no way to cause another user's account to get into this state, and in this case, I do not see a security implication here. "
They tend to react with "either you can show us that this is a real danger or we'll ignore it".
It seems pretty clear that this bug shows something is terribly wrong and probably dangerous. But the reporter might have limits in analyzing the bug, while the company could easily figure out what's going on and fix it.
This is a bit of a Catch-22 situation, as I get the feeling that proving the danger would often involve doing things that bounty programs specifically forbid, such as "Moving beyond “proof of concept” repro steps"[0]. That may be part of the reason why Microsoft got away with such a stingy response to the RCE vulnerability found in Teams by Oskars Vegeris.[1]
[0] https://www.microsoft.com/en-us/msrc/bounty-online-services?...
[1] https://github.com/oskarsve/ms-teams-rce/blob/main/README.md
I regularly encounter services that does not handle it very well
https://crd.ndl.go.jp/reference/modules/d3ndlcrdentry/index....
That's not the issue ... I have not personally tried this or examined it, it looks like you can change the state of the header parser by including interesting characters in your name. I am not sure if this is server-side or client-side. If the problem is server side, there is a chance you could tweak the strings to get interesting results. But trying to prove that this is a serious problem without explicit authorization will likely have adverse consequences for anyone who does, so only people who are already doing shady stuff explore it.
the one I run into a lot is a + in an email address.
I like to use them on sites I think will likely sell my email address so I'll do something like "my.normal.email+websitename@gmail.com"
I rarely have trouble signing up with this email address, nor verifying it, but then you go to login and splat.
but not properly escaping the lastname of "true" just seems way to basic for a service as large as icloud.
Re: validating login/signup, I never had an issue immediately. However in practice it happens often when there's one validator but it changes over time during a big rewrite. So you sign up, all works, rewrite lands, can't log in anymore.
I love when people argue that it isn't valid even after you contact support.
Generally a sign I don't want to do business with them.
A sibling comment mentions Swift, but I doubt all components of iCloud are written in it.
https://docs.swift.org/swift-book/LanguageGuide/Enumerations...
1> let _: Bool = "true"
error: repl.swift:1:15: error: cannot convert value of type 'String' to specified type 'Bool'
let _: Bool = "true"
^~~~~~The reason I say Swift "has" stringly-typed enums is that Objective-C has them (typedefs of NSString where the values are actually strings, and are of course implicitly convertible), and Swift imports them as enums with string-typed raw values.
Anyway, I mostly just meant to suggest that this particular iCloud bug is probably not Swift-related.
> temp0.innerHTML = true // no error
> "true" == true
false
> true == "true"
false var foo = null;
foo.lastName = "anything"; // TypeError, cannot set property "lastName" of nullcountry: xx
... and get to Norway?
I am convinced that TOML is the _only_ reasonable configuration format, but very few seem to be swayed.
JSON and YAML are really not made for humans. Configuration must always be a hash. Configuration must allow for expository organization of the content to help humans understand what they are editing (comments, whitespace, section headings are very helpful). Parsing configuration should not result in unexpected code execution.
TOML satisfies those criteria.
I would love to see widespread adoption, but people still seem convinced that storing configuration in JSON is human friendly.
HCL suffers from only having a reasonable implementation in Go, however.
It's just that it's badly made for humans, in that it tries to be too helpful, leading to the various footguns scattered around the format.
TOML can be a bit verbose, especially if you have a case where your keys are more like sentences than they are like symbols. But there are no surprises, and it's quite pleasant to write by hand. I agree that it should be the first choice.
A format that allows references to other sections is not a configuration language that is usable by humans.
I understand the people who created it thought it would be usable by humans, but clearly it is too complicated for anyone to be able to understand a YAML file that is bigger than a dozen or so lines.
I don't mean this in a "if you just swap the parser" way. I mean that in the "if you provide JSON to a program that expects YAML, it will parse it". JSON is a subset of YAML
So not only do you have a way of not using YAML, you can also force this decision onto most third-party services as well, and no-one will know the difference.
That's false. http://p3rl.org/JSON::XS#JSON-and-YAML
Some parsers intentionally support subsets of the spec for this reason, and there's multiple specs (like 1.2 which dropped support for things like 'no' to mean false), but that also just means you need to be 100% certain your parser is set up correctly. It's just not worth the extra headache to me.
country_code: NOTrue as you know it can by any of true, “true”, 1, “1”, >0 and most likely more.
And there, it is handled by a clear and dedicated layer: ActiveModel::Type::Boolean.new.cast(value)
The only thing you can complain about is that Rails loves implicit magic, which will call this layer for you. Without you needing to set it up, or call it yourself. Many people love this about Rails. (I prefer explicitness over magic.)
Rails does not do this entirely "magic", though: it derives it from the database.
And true: you can follow the logic along: the magic can be researched easily. But still: I really prefer a system in which I write all that boilerplace (my IDE/vim can do this for me really well) instead of relying on convention, heuristics and magic.
I am a lot more humble about handling people’s names when writing systems these days...
Many, many moons ago, my employer generated an email address for me, first.o'last@example.com. This is technically valid, but yes, problems everywhere. I put in a ticket asking if I could change it, or at least alias it to first.olast@, for obvious reasons. They never replied.
Over the years, I put in a few more tickets for this. Nada.
Over a decade later, they got in touch and asked if they could change my email address. Turns out they never received my pleas. Turns out our ticket system was one of the systems I had issues with.
It literally means nothing. "May"? contain. It either contains or not. Why is that a problem? Even better it stating it as a statement, like "yes, your name may contain a profanity" (but you don't like it?)
He always said he was very very afraid of being pulled over by police in the States and asked his name.
I wonder if this will be the new anonymity in the future, sort of being like a "john smith" in the past
Long story short use a text field that takes UTF-8.
The simple answer is _not to_. Use something you can stuff a bunch of arbitrary bytes into, that will fit the byte encoding that the system is currently using.
Don't sanitise it. Have no expectations about what it can contain. Have a length, have some bytes, and don't ever dare to try and look inside it.
When dealing with anything near banking and human life and anything regulated really, I strongly suggest heavily sanitizing all of inputs. No control characters, no invalid utf-8, no weird whitespace and white list characters you want to allow. Actual list is domain-specific, of course. Limiting input field to reasonable 20 characters will help defence in depth too.
For ex - why are you collecting gender? If it's for some kind of medical process, the requirements of that will tell you what you actually need to know. If it's for some kind of dating thing, you can also figure out from that what you really need to know. If you don't actually know what you need it for, then maybe just don't collect it at all, and you have nothing to worry about.
Ditto most other requirements. Do you need a name for a user in order to meet some kind of legal requirement, or do you just want to be able to put "Hello Username" on the page somewhere? Things tend to get sticky when you might have to interact with multiple external systems with different requirements. Maybe you help run people through some kind of legal process in various countries, and country A's system doesn't support people having a middle name, but in country B this is common and necessary and their systems require it.
I will show myself out.