dual_sport_dork 🐧🗡️

Progenitor of the Weird Knife Wednesday feature column. Is “column” the right word? Anyway, apparently I also coined the Very Specific Object nomenclature now sporadically used in the 3D printing community. Yeah, that was me. This must be how Cory Doctorow feels all the time these days.

  • 0 Posts
  • 251 Comments
Joined 1 year ago
cake
Cake day: July 20th, 2023

help-circle

  • Manufacturers absolutely do make only-for-sale-in-California-variant cars. Motorcycles, also. They’re not as common as they used to be because emissions laws elsewhere are also starting to become as stringent as the CARB rules these days as well, so it’s becoming more cost effective to just make everything the “California version.”

    Throughout the early 2000’s, the distinction was much more relevant. The last vehicle I had to work on that I know for a fact to be a “California version” was a 2014 KLR650. It has additional (unreliable…) emissions control equipment that is not present on otherwise identical bikes from the same model year that were not intended for sale in California.

    Furthermore, California will refuse to plate any vehicle that does not specifically have a California compliant emissions certification if it has fewer than 7500 miles on it, i.e. if it is new. Those that don’t meet California’s standards are labeled “49 state” vehicles.







  • You should probably have some safeguard to prevent jokers from uploading 14.2 gigabytes of absolute nonsense into your system’s password field just to see if they can make it crash. But I think limiting it to, like, 8 kB ought to be quite lenient for anything with a modern internet connection.

    As others have noticed, various hashing functions have an upperbound input length limit anyway. But I don’t see any pressing reason to limit your field length to exactly that, even if only not to reveal anything about what you might be feeding that value into behind the scenes.




  • That works great until some dickhole implements the old, “New password cannot contain any sequence from your previous (5) passwords.”

    This also of course necessitates storing (multiple successive!) passwords in plain text or with a reversible cipher, which is another stupid move. You’d think we’d have gotten all of this out of our collective system as a society by now, and yet I still see it all the time.

    All of these schemes are just security theater, and actively make the system in question less secure while accomplishing nothing other than berating and frustrating its users.



  • Don’t bug users to change passwords periodically. Only do it if there’s evidence of compromise.

    This is a big one. Especially in corporate environments where most of the users are, shall we say, not tech savvy. Forcing people to comply with byzantine incomprehensible password composition rules plus incessantly insisting that they change their password every 7/14/30 days to a new inscrutable string that looks like somebody sneezed in punctuation marks accomplishes nothing other than enticing everyone to just write their password down on a Post-It and stick it to their monitor or under their keyboard.

    Remember: Users do not care about passwords. From the perspective of anyone who isn’t a programmer or a security expert, passwords are just yet another exasperating roadblock some nerd keeps putting in front of them that is preventing them from doing whatever it is they were actually trying to do.


  • Who cares? It’s going to be hashed anyway. If the same user can generate the same input, it will result in the same hash. If another user can’t generate the same input, well, that’s really rather the point. And I can’t think of a single backend, language, or framework that doesn’t treat a single Unicode character as one character. Byte length of the character is irrelevant as long as you’re not doing something ridiculous like intentionally parsing your input in binary and blithely assuming that every character must be 8 bits in length.



  • I briefly touched on this in a lengthy comment when this scheme was originally floated a few months ago. Your prediction, which granted is something that Youtube/Google absolutely would try if they thought they could get away with it, would only work on viewers that remained within the confines of Youtube’s native player.

    Any third party app capable of bullying or tricking Youtube into handing them the video data is free to do whatever it wants to with it afterwards, even if this ultimately means impeccably pretending to be the official Youtube player in order to get the server to fork over the data. Furthermore, video playback is buffered so a hypothetical pirate client would have several seconds worth of upcoming video to analyze and determine what it wants to do with it.

    Youtube could certainly make this process rather difficult by including some kind of end-to-end DRM or something, but at the end of the day you need to make a playable video stream arrive on the client’s device or computer somehow, and if you can’t guarantee full control of the entire environment in which that happens, dedicated nerds will find a away to screw with that data.