litchralee @ litchralee @sh.itjust.works

Posts

121

Comments

1,127

Joined

2 yr. ago

Fairness? Journalism? Did we read different articles?

The link in question is for a blog post on the website of a law firm specializing in bicycle injuries. The entire point of every single article is to frame every bicycle-related current event to fit the byline: "Don’t try to navigate the aftermath of a crash alone. Contact

<our law firm>

There is no ad revenue because the blog posts are the ads. And being a law firm, they should know better than to irresponsibly use generated content without vetting it.

No, law is definitely not a "best use case" for AI and this is definitely not exemplar of that notion. And even if it were, slop has zero value to the reader, because if they couldn't be bothered to write it, I and everyone shouldn't be bothered to read it.

Same article, but with fewer GDPR/CCPA/privacy policy pop-ups: https://www.nbcnews.com/news/us-news/electric-scooter-scam-lightning-shared-scooter-co-investors-rcna226832

This "article" has the hallmarks of badly-written AI slop. It is wrong that the law prohibits all speed modifications, it is wrong that an out-of-spec ebike automatically becomes a motor vehicle, it is wrong that modifying ebikes became illegal starting with this bill.

AB 1774 is quite simple, in that it added a blurb to an existing paragraph and added a new paragraph. This is the entirety of the operative changes, with the new stuff in bold:

(d) A person shall not tamper with or modify an electric bicycle described in subdivision (a) of Section 312.5 so as to change the speed capability of the bicycle, unless the bicycle continues to meet the definition of an electric bicycle under subdivision (a) of Section 312.5 and the person appropriately replaces the label indicating the classification required in subdivision (c) of Section 312.5.

(e) A person shall not sell a product or device that can modify the speed capability of an electric bicycle such that it no longer meets the definition of an electric bicycle under subdivision (a) of Section 312.5.

At large, it was already illegal for an end-user to modify their ebike beyond its classification. If they do and introduce the bike to a public road, the act of modification is an infraction, punishable by a fine. If a rider is pulled over for an out-of-spec ebike, the charge depends on whether this two-wheeler could fall into the "moped" category (which isn't legally a motor vehicle) or if it would be a motorcycle, which is definitely a motor vehicle.

Not having moped plates -- probably an infraction, plus maybe DMV late fees -- will be a lot less bad than failure to register a motorcycle, failure to keep proof of insurance, riding without a license, and so many other charges.

Before this law applied, the existing law could punish end-users caught riding, and could punish vendors that sold out-of-spec ebikes. But the law couldn't punish the vendors of devices solely designed to allow such modifications. So they changed the law to do exactly that. Today, any device that is sold for that explicit purpose, and is capable of taking a lawful ebike beyond the three-claas system, cannot be sold in California, with penalties on the seller.

Caveat: this new law is unclear on "multi use" devices. What if the only device needed is a UART to USB interface? This law only bans hardware, so wouldn't prohibit open-source software that writes commands to "unlock" an ebike to overspeed.

Caveat: a device is banned if it has any possibility of exceeding the three-class system. If the device can allow raising the speed above 28 MPH (45 kph), that is automatically banned. That is to say, a lawful device must stop after modifying an ebike to the max specs of class 3.

Caveat: the sale of modification devices is illegal, but not giving away or building such devices. FOSS hardware may one day exist to do this, and a tinkerer could legally build their own. Of course, actually doing the modification is still illegal per the older laws. But the point stands that only the for-money trade of these devices is what's prohibited, not their possession.

The article mentions none of this, and seems to have been generated by an LLM seeking to summarize the entire section CVC 24016, most of which is unchanged.

The practice of handwritten paystubs is deeply suspicious, in an era where even the most basic of business payroll software can easily generate and print out a paystub directly. But I want to focus on the request for $1232 for 8.8 hours of apparent effort.

That divides out into an hourly rate of $140 per hour! Such a high rate is the near-exclusive domain of a lawyer's billable hours, as suggested from this 2002 survey by the Oregon State Bar. It is patently absurd to request the services of a lawyer for 8 hours when all it would have taken is an hour for a skilled accountant, or two hours if performed by even the most confused of small-business entrepreneurs.

Unless your employment records extended for decades across multiple corporate entities that went through mergers and acquisitions, that is an unreasonable charge. Your former employer may be confusing the "reasonable fee" provisions for preparing documents persuant to a subpoena.

im not much of a writer, im sure its more clear from AI than if i did it myself

Please understand this in the kindest possible way: if you were not willing to write documentation yourself, why should I want to want review it? I too could use an AI/LLM to distill documentation rather than posting this comment but I choose not to, because I believe that open discussion is a central tenant of open-source software. Even if you are not great at writing in technical English, any attempt at all will be more germane to your intentions and objectives than what an LLM generate. You would have had to first describe your intentions and objectives to the LLM anyway. Might as well get real-life practice at writing.

It's not that AI and LLMs can't find their way into the software development process, but the question is to what end: using an AI system to give the appearance of a fully-flushed out project when it isn't, that is deceitful. Using an AI system to learn, develop, and revise the codebase, to the point that you yourself can adequately teach someone else how it works, that is divine.

With that out of the way, we can talk about the high-level merits of your approach.

how the authentication works: https://positive-intentions.com/docs/research/authentication

What is the lifetime of each user's public/private keypair? What is the lifetime of the symmetric key shared between two communicating users? The former is important because people can and do lose their private key, or have a need to intentionally destroy the key. In such instance, does the browser app explicitly invalidate a key and inform the counterparty? Or do keys silently disappear and also take the message history with it?

The latter is important because the longer a symmetric key is used, the more ciphertext that a malicious actor can store-and-decrypt later in time, possibly in the future when quantum computers can break today's encryption. More pressing, though, is that a leak of the symmetric key means all prior and future messages are revealed, until the symmetric key is rotated.

how security works: https://positive-intentions.com/blog/security-privacy-authentication

I take substantial notice whenever a promise of "true privacy" is made, because it either delivers a very strange definition of privacy, or relies upon the reader to supply their own definition of what privacy means to them. When privacy is on offer, I'm always inclined to ask: privacy from whom? From network taps? From other apps running in the same browser?

This document pays only lip service to some sort of privacy notion, but not in any concrete terms. Instead, it spends a whole section on attempting to solve secure key exchange, but simply boils down to "user validates the hash they received through a secure medium". If a secure medium existed, then secure key exchange would already be solved. If there isn't one, using an "a priori" hash of the expected key is still vulnerable to hash attacks.

this is my sideproject and im trying to get it off the ground

I applaud you for undertaking an interesting project, but you also have to be aware that many others have also tried their hand at secure messaging, with more fails than successes. The blog posts of Soatok show us the fails within just the basic cryptography, and that doesn't even get to some of the privacy issues that exist separately. For example, until Signal added support for username, it was mandatory to reveal one's phone number to bootstrap the user's identity. That has since been fixed, but they go into detail about why it wasn't easy to arrive at the present solution.

am i a cryptographer yet?

I recall a recent post I saw on Mastodon, where someone who was implementing a cryptographic library made sure to clarify that they were a "cryptography engineer" and not a cryptographer, because they themselves have to consult with a cryptography regarding how the implementation would work. That is to say, they recognized that although they are writing the code which implements a cryptographic algorithm, the guarantees comes from the algorithm itself, which are understood by and discussed amongst cryptographers. Sometimes nicely, and other times necessarily very bluntly. Those examples come from this blog post.

I myself am definitely not a cryptographer. But I can reference the distilled works of crypgraphers, such as from this 1999 post which still finds relevancy today:

The point here is that, like medicine, cryptography is a science. It has a body of knowledge, and researchers are constantly improving that body of knowledge: designing new security methods, breaking existing security methods, building theoretical foundations, etc. Someone who obviously does not speak the language of cryptography is not conversant with the literature, and is much less likely to have invented something good. It’s as if your doctor started talking about “energy waves and healing vibrations.” You’d worry.

I wish you the very best with this endeavor, but also caution as the space is vast and the pitfalls are manifold.

I legit ran it over with a forklift the other week

I have to ask: what circumstance led to this particular incident?

Aiming to create the worlds most secure messaging app

For anyone else that was looking for it, this is the link to the threat model: https://positive-intentions.com/docs/research/threat-model/

That said, it seems quite thin on hard details, such as how identities (ie usernames) are managed -- eg are they unique? How can users cross-check an online identity to a real person? Fingerprints? QR codes? SHA256 hashes? -- and whether they are considered publicly-exchangeable. Plus how users are bootstrapped so they can find each other.

While a threat model is the minimum to even beginning an assessment of anything that utters the word "security", I do have to ask:

• Was that document crafted for this project specifically?
• Was it prepared by a cryptographer?
• And was it generated using an AI/LLM?

The link -- which basically rehashes the press release from KiwiRail, the New Zealand rail network owner, and who also runs many of the freight trains -- notes that recent improvements came from upgrading to more efficient diesel locomotives.

Diesel locos hauling freight would reasonably be expected to produce fewer emissions than diesel road vehicles, and it also means further network upgrades such as electrification could deliver even lower emissions. That said, KiwiRail seems to only have electric infrastructure in major metro areas.

The country's energy mix seems to rely on a lot of imported fossil fuels, so consolidation of electricity generators alongside electrified railways should still yield an improvement. And of course, an electric grid can always introduce more and more renewable sources. Whereas diesel will always have to be imported.

I suppose the first question is whether you had the baud rate set correctly. The photo of the "cleaned up signals" (not entirely sure what you did, compared to the prior photo) seems to show a baud rate of 38400, given that each bit seems to take about 25 microseconds.

As for the voltage levels, the same photo seems to show 5v TTL. So it doesn't seem like you would need a level converter from 15v RS-232 levels. This is one of the few times where the distinction between a "serial port" and an RS-233 port makes a difference, but a lot of data center switches will deal using 5v TTL, because the signals aren't having to travel more than maybe 5 meters

If this happens, I expect these unregulated motorbikes to become as unpopular as regulated ones, as former riders go with the next most convenient way to do 55mph, a car.

I'm not following how an automobile would be the "next most convenient" method, if the existing laws that classifies over-powered two-wheelers as motorcycles were properly enforced. This is how I imagine it would look:

Current riders of over-powered two-wheelers might be categorized as any of: 1) minors who don't qualify for any type of driving license, plus adults that have too many driving record points, yet still have places to go, 2) minors who could obtain a driving license but can't afford an automobile, and still have places to go, 3) minors or adults who are not interested in dealing with mainline road traffic and would rather over speed on trails and off-street paths, 4) they are simply unaware of the legal quagmire that regulated over-powered two-wheelers but are otherwise happy with their choice of transportation.

In this breakdown, riders in categories 1 and 3 would not consider switching to an automobile as a viable alternative, because of the licensure and complexity/boringness of driving a car. A crackdown on overpowered two-wheelers leaves these riders with basically nothing.

For category 2 rider, a legal ebike would be cheaper than buying and maintaining a car. Though this is muddled because riders in this category might already have had cars, but had reduced their mileage because they had a two-wheeler to use instead.

For category 4 riders, if they were happy with their mode of transportation, then some might continue to operate illegally and accept that. But others might pursue a motorcycle license, seeing as they have no issue running at higher speeds and powers alongside mainline road traffic. The primary disincentive for riding motorcycles in the USA is not licensure or wearing safety gear, but is one's personal level of acceptable risk when riding alongside automobiles driven by distracted drivers. Since category 4 riders had no qualms about that before, getting these riders licensed and insured is a more-surmountable obstacle.

And motorcycles are cool.

My point is that it's nowhere near a "ban ebikes and they'll all suddenly drive cars" scenario, but there's a substantial amount of nuance in what constitutes good public policy, whether that's to increase enforcement of existing laws for two-wheelers, add new redundant law, enforce laws against motorists, develop more public transit options for riders in categories 1-3, or something else.

Earlier comment:

A minor note: in the name Doai-eki (土合駅), the eki (駅) part means "train station". So "Doai eki train station" in English is a tad redundant. Kinda like The La Brea Tar Pits.

A minor note: in the name Doai-eki (土合駅), the eki (駅) part means "train station". So "Doai eki train station" in English is a tad redundant. Kinda like The La Brea Tar Pits.

I'm in full agreement, and want to note that the confusion regarding enforcement started well before ebikes became a thing, at least in California.

To see why, we have to turn back to the 1970s, when mopeds -- legally, a "motorized bicycle" -- were introduced. At the time, the definition described a "device" (so not a vehicle in California) with a max 30 MPH (48 kph) limit on level ground, a 4 HP (3 kW) max engine output, an automatic transmission , and operative pedals. This hewed almost identically to the original Swedish mopeds, which existed in the context of a max 50 kph speed limit in urban areas.

Fast forward to sometime in the 2000s or early 2010s, the California definition of moped gained a proviso for electric-powered mopeds, with a max motor output of 3 kW but removed the requirements for an automatic transmission (bc irrelevancy) and the pedals.

So since that time, enforcement of mopeds would have been confusing, since an electric motorcycle (always has been legal) and an electric moped can share the same appearance but differ only in limited power output and speed. Though the market for electric mopeds didn't explode anywhere near what happened in the 2010s and 2020s with ebikes.

But the problem was always there, just now exacerbated. But I do think even the three-class system as implemented in California has other problems with enforcement as well.

For example, a class 2 and class 3 ebike have different operating requirements. To ride a class 3, the rider must be 16+ years old and a helmet is mandatory, even if over 18 years old. Under the law, to stop an underage rider on suspicion of operating a class 3 ebike would require separate information that the rider is not at least 16. In practice, this is an invitation for police profiling, stopping riders because "you look too young" and that's patently objectionable.

If a rider is stopped for something else (eg the helmet requirement for class 3) and their age is noticed from their ID during the stop, then that's a fair cop. But anytime that enforcement results in unjustified profiling and stops that are not premised by reasonable suspicion, that's where civil rights erode. Not just for those riders that are pulled over, but everyone who travels the roads. No one would be safe.

P.S. Anyone looking through the history of the California Vehicle Code should be aware that there were once two definitions of "motorized bicycle", one which meant moped and another which was the early prototype that preceded the ebike class system. The latter was removed circa 2018, after the class system was already in use for two years. That's... totally not confusing at all, legislators...

with astounding nakedness

Clearly they should have shrouded the bribe within a bag of sour cream and onion chips.

A new take on the phrase "chips on the table" lol

Inside a gasket-sealed motor housing, gasoline that remains stuck inside would have nowhere to evaporate to, and would dissolve and interact with the new grease. Plus, stuffing a motor housing full of grease would be more relevant for marine applications, where the grease keeps water out. But in a land vehicle, the grease just needs to coat the moving parts for lubrication. A correctly-chosen grease won't fling off the gears at high RPM.

I think for gasoline, it is so volatile that it will readily evaporate from all cavities if shaken out and left to dry for a while. But during this time, the vapors must be managed because it's all combustible. Still, I'd rather not do that unless I have to, and the brake cleaner suggestion from earlier would still be an easier idea.

I should clarify that when I say "motor", I mean the motor housing plus the stator, as I can easily remove the electronic control board, the rotor, and the intermediate and final gears. The housing appears to be cast aluminum so that alone could be submerged, but it's the stator that I'd rather not have in gasoline.

I have no idea if the insulation on the windings or the glue attaching the stator to the housing would dissolve in gasoline. And removing the stator seems to be more effort than a toothbrush and brake cleaner.

I have a dual-battery Bikonit MD750, but I really wouldn't recommend it as it's an older design (circa 2022) mid-drive ebike. There are newer models that have the same (or more) power while being lighter and quieter. My particular use-case was to have as much endurance as possible, hence the dual-batteries.

I'll have to check the local Tractor Supply Co. Thanks!

This doesn't answer OP's question, but is more of a PSA for anyone that seeks to self-host the backend of an E2EE messaging app: only proceed if you're willing and able to upkeep your end of the bargain to your users. In the case of Signal, the server cannot decrypt messages when they're relayed. But this doesn't mean we can totally ignore where the server is physically located, nor how users connect to it.

As Soatok rightly wrote, the legal jurisdiction of the Signal servers is almost entirely irrelevant when the security model is premised on cryptographic keys that only the end devices have. But also:

They [attackers] can surely learn metadata (message length, if padding isn’t used; time of transmission; sender/recipients). Metadata resistance isn’t a goal of any of the mainstream private messaging solutions, and generally builds atop the Tor network. This is why a threat model is important to the previous section.

So if you're going to be self-hosting from a country where superinjunctions exist or the right against unreasonable searches is being eroded, consider that well before an agent with a wiretap warrant demands that you attach a logger for "suspicious" IP addresses.

If you do host your Signal server and it's only accessible through Tor, this is certainly an improvement. But still, you must adequately inform your users about what they're getting into, because even Tor is not fully resistant to deanonymization, and then by the very nature of using a non-standard Signal server, your users would be under immediate suspicion and subject to IRL side-channel attacks.

I don't disagree with the idea of wanting to self-host something which is presently centralized. But also recognize that the network effect with Signal is the same as with Tor: more people using it for mundane, everyday purposes provides "herd immunity" to the most vulnerable users. Best place to hide a tree is in a forest, after all.

If you do proceed, don't oversell what you cannot provide, and make sure your users are fully abreast of this arrangement and they fully consent. This is not targeted at OP, but anyone that hasn't considered the things above needs to pause before proceeding.