My go-to for situations like these: Assume that the offender _clearly_ didn't mean to behave incorrectly, and help them overcome the mistake.
Person in a public space listening to reels at full volume? Get their attention, then loudly point out that their headphones got disconnected and everybody can hear the audio.
People leaving a train or bus and leaving behind trash? Loudly let them know that they forgot their water bottle or paper bag. If it's a single item, this works doubly well if you helpfully hand them the item, too.
> AFAIR they don't do multilingual restreams (automated or otherwise) like some other online events.
They do. There's a team of interpreters at CCC who translate most talks between English and German, and to some other languages. As with most things CCC, it's all volunteer-driven and done on a best-effort basis, but it's there.
When interpretation is available, I prefer talks that are given in whichever language the presenter is most comfortable in. Presenting in front of a large audience is stressful enough as it is, so IMO it makes a ton of sense _not_ to worry about doing that in a second/third language, and delegating that part of the presentation to someone else instead.
My favorite anecdote from riding a German train in Switzerland was a journey from Interlaken (Switzerland) to Frankfurt in Germany. Now if you're not used to train schedules: Stops are quick, and trains are punctual. It's fairly common for stops to just be 2-3 minutes. Connections between trains are often around 5 minutes, sometimes shorter.
So, this Intercity Express departed Interlaken perfectly on schedule, made a bunch of scheduled stops in Spiez, Thun, Bern, and continued on to the border city of Basel. Everything running perfectly on schedule, the train arrived at the Swiss station in Basel, continued (on time) to the German train station that's still in the same city, just a few minutes farther. Having had 3-5 minute stops all the way from early morning to lunchtime, the train then sat in the German station for about 15 minutes, departed with only a minor delay, and just a few yards after exiting the station proceeded to stop, sit on the tracks for half an hour ("to catch up with the prevalent delay conditions on the German rail network"), before starting to move again.
Waiting in a comfy seat on a train with working AC isn't the worst of fates, and we made the final destination within half an hour of the scheduled time, so it all went well -- just funny to observe how different parts of this interconnected network had very different ideas of scheduling.
> [Piracy:] When I download a movie this way, I truly own it.
When you download a pirated copy, it's more likely that you _possess_ it, rather than _owning_ it. You are in control of the bits and bytes, they will not just disappear; but since your copy is unlicensed and illicit, the copyright holder could take legal steps to make you delete your copy (and pay for your infringement on their copyright).
> Same as I own a DVD disk.
That's different. You own the physical disc, and the right to re-sell or potentially lend out that physical disc. (However, you can't take the data from that disc, and stream it to a public audience on the internet.)
> [...] rewatch some episodes just plugging the disk via USB
Depends on your jurisdiction, but in many places it is legal for you to create a backup of a physical disc that you own, and make personal use of that backup. In some places you are allowed to share your backup copy with friends and family (on a non-commercial basis, of course). It gets nuanced.
Ripping is pretty much undetectable though unless they decide to torrent it for others. So in practice they own it.
As to the 2nd point, it's not really 1:1, a more accurate equivalent would be a netflix dvd rather than a bought one.
Some emoji, for example, are combinations of multiple other emoji, and a given combined emoji may not be uniquely represented by a sequence of codepoints. In the pathological case, this could mean that an OS update on the user's system changes the composition of the same emoji, which might make it impossible for them to input their password. It is probably prudent for a system to disallow emoji passwords.
One step away from Emoji, Unicode also allows for other m̸̱̜̅ͅȋ̴̩̠̀s̸̺͐c̶͈͇͉̐͛̚h̸̤̣̆i̴͍͍͒͌e̴̲̽̓f̸̞̽̊. Chances are, full-on Zalgo passwords can lead to problems. Again, there are probably prudent reasons to restrict some characters. On the other hand, those modifiers exist for a reason, and disallowing phrases in the user's native language doesn't make for great UX.
Towards the more common use of Unicode, there is a pretty good _practical_ reason to restrict the use of some non-ASCII characters: if your system accepts ç, ö and ø as characters in passwords, and non-technical users venture into a part of the world where the keyboard layout doesn't, your helpdesk is going to have to deal with the occasional annoyed customer. From a systems design perspective, those characters seem fine -- operationally, they may cause headaches.
Finally, we've arrived at printable ASCII characters. Restrictions on maximum length (usually 6 or 8 characters), and on certain characters (%, & or :) tend to be based on interactions with legacy systems (e.g. DES crypt() used to have an 8-character minimum), or on bad input handling. Either way, it's probably a bad sign.
> It is probably prudent for a system to disallow emoji passwords
In addition, not all keyboard environments are capable of inputting the same set of emoji. A coworker once got locked out of his macbook because the UX when changing the password when already logged in allowed inputting emoji, but the OS login screen did not (could be misremembering some specifics, but the broad point remains).
Which I suppose is really a subset of the sorts of issues around ç, ö and ø, but how it can happen even on the same system in different contexts.
I don’t think it’s prudent for a system to disallow emoji passwords. Or to restrict various characters. I say: let the user do what they want to do; on their own heads be it if they do something that doesn’t work for them in all circumstances, and the end result is practically not much different from forgetting a password, which is normal.
In general, passwords are not treated as essential for access, and there will be recovery techniques, and the number of password resets or whatever required because they can’t type such-and-such a character any more or on this new device will be a minuscule fraction of the total. Resetting passwords and other forms of lost account access is typically not an exceptional path. From what I’ve seen, for business-to-customer businesses that don’t have some form of self-serve account recovery, “I’ve lost access to my account” will routinely be half your ticket volume.
In those fairly uncommon situations where passwords are essential for access (e.g. where it’s an encryption key), well, it’s still up to the user, and the user is somewhat more likely to be aware of any potential hazards in such fanciness.
Overall, I say: stop trying to be clever; accept what is set before you without asking questions on the grounds of compatibility. Let the user do what they try to do.
Maybe normalise Unicode; it’s a harmless thing to do and has the potential to improve compatibility slightly on very unusual input devices. (I don’t think I’d bother, myself.) But beyond that, I’m not sold on the arguments for restricting possibilities.
I see where you're coming from, and looking at the problem from a purely technical perspective, I agree with you. A password is just a string of codepoints. Accept what you get, yeet it into a password hashing function, and be done with it.
However, in my opinion, for real-world systems, you need to strike a balance between technical and operational, and user experience concerns. If restricting your password space to printable ASCII characters can meaningfully decrease the amount of the tickets that generate half of your ticket volume, you should give it some serious thought.
There are good arguments for both approaches, and the right way also depends on your user base. There was a story about WhatsApp a while ago, criticizing that WhatsApp would only notify users when their contacts' security code had changed, whereas Signal (and other secure messengers) would block and ask for confirmation first. Signal currently sits at 100M+ downloads in Play store, WhatsApp sits at 5B+. The numbers are very vague, but WA has 1-2 orders of magnitude more users than Signal.
In the WhatsApp example, a small change in the process can mean that good security becomes accessible to a pool of billions of users, vs. excellent security to millions. Restricting the password character set (to a sensible set of characters, and with a sensible length limit) comes with no security drawbacks, and good chances of some process/usability improvements. For a real-world deployment, I would argue it's very prudent.
I expect the number of tickets induced by supporting Unicode to be a negligible fraction. (I offer no support for this expectation.) Depending on the type of service you’re running, you might even avoid a few tickets from people that might complain about the restrictions, though certainly most of the time people will just sigh and choose something else and not even think of contacting to complain.
No security drawback? You make it harder for people to use the password they want to use. There is a real cost to that, encouraging bad password hygiene. Provided you support at least printable ASCII it’s unlikely to be a significant cost, but it is a cost, and I remain entirely unconvinced of the practical benefits of the restriction.
Reversing the argument a bit: what incentive does the dev have to not restrict characters and be done with it? It's basically getting rid of various problems at no cost. And the type of customer demographic annoyed by this will not only be tiny in number but will also probably be annoyed by other things as well anyway.
My favorite experience was with the backspace character. One of our cli tools accidentally saved them in a password store. The user can show his password but the console interpreted the backspace and therefore everything looked normal. That discovery was truly funny. Null byte characters create a funny user experience too. A user has an issue with an input, then I go and fix the problem by typing the same thing again and it works. These can end up in passwords too.
I used the same mod to turn a few older, passive hi-fi speakers into Sonos-enabled wireless speakers. They sound (and look) a lot better than the Symfonisk, and putting the DAC and amp right into the speaker enclosure is more convenient than an external amp and wiring.
If you use them to bi-amp speakers with two drivers, the TruePlay calibration works great.
The _actual_ sharing economy is great. Your beef is probably with corporations that masquerade as part of the sharing economy in order to exploit regulatory loopholes (e.g. Uber, Airbnb).
For an example of the actual sharing economy: I'm a member of a local cooperative that owns and maintains a fleet of ~3k cars, distributed across the country at most train stations and in many neighborhoods. For an initial deposit of $1k, "my car" is whatever I need it to be at that moment. If I need to transport furniture in the morning, it's a Mercedes Vito. For a leisurely drive in the countryside at lunch, it's an Audi convertible. And for a quick grocery run before stores close, a cheap Citroën C1 will do the trick. And because the whole thing is a cooperative, per-km prices are around what I'd pay if I owned any of the cars myself.
Sharing is great. Regulatory arbitrage masquerading as the sharing economy, less so.
I know this is 9 hours old, but this is 100% not for me.
I want to leave items in my car for tomorrow: my face mask, (previously) CDs and tapes, etc.
I want to spend the extra money for 'grippy' tires on my car, or do other mods like use sticky notes on the dash. I want my seat to be in the same position I left it in: It can take a day or two to get it just right. I want to have the option to use a seat cover for comfort.
I want to eat my lunch in my car: I control the climate, I control the music, and I can vape or smoke to my hearts content. It's mine to do that with.
I want to put off unloading my vehicle after a long and arduous camping trip, It's already 8PM when I get home. It can wait for tomorrow, and doesn't cost me anything.
I want to let my muddy dog jump into the back seats, I don't care if they get 'ruined', that's my choice about my property. I don't want a cleaning fee.
Lastly, I want to know for sure my dog won't eat the used condom the last person left under the seat. People are animals, no amount of cleaning between uses can ensure cleanliness 100% of the time. But I can in my car.
That's fair. I can see the benefits in most of the things you listed. Chances are, this boils down to whether you regard your car as sort-of an extension to your home. I don't, so I'm perfectly happy to have _a_ car available to me at a moment's notice. I understand that many people do, and they'll prefer being able to own a car and really make it their own. The whole car sharing thing is also predicated on good availability of cars near where you need them. It works great for me, in an urban setting; it would be wholly useless if I lived somewhere out in the sticks.
The point I want to make: SaaS, RegArb and the sharing economy are different things. If VW tries to charge you per-hour to use the software installed on your car, then let's talk about abusive software licensing. If Uber skirts regulations to muscle into the transportation market, let's frame the discussion around employment law and transport regulations. RegArb startups make it a habit of framing their business model as something else; and we're all better off if we don't fall for that trap :)
reply