Thanks for letting me know. It seems like when Brave is set to aggressively block tracking, it also blocks the canvas since it could be used for fingerprinting a device.
I'll see if an avg version is viable in the future.
If you are serious about sharing written ideas, I suggest you avoid using this type of prompts at all cost. I've worked with LLMs to write on my blog and they are pretty good at first glance [0]. But do it a few time and you'll notice that those tropes are the least of your problems. Not only all your articles will sound the same, but you'll see that same voice on other blogs, news articles, white paper, etc. It's as if they were all written by Mo Samuels. Readers are often here for the author's voice, not just the content of the text.
I often hear this here: "if you don't bother writing, why should I bother reading?" In fact, save us some time and just share the prompt.
I have seen people suggest that the problem is that LLMs let you express any of your ideas, but the number of people with ideas worth expressing is limited.
In a sense I think this is accurate, but not inevitable. I think there is a lack of creative thinking, but it has come from a world that doesn't value it and suppresses difference.
There is a brilliant line in Treehouse of Horrors IV where Principle Skinner says "Now I've gotten word that a child is using his imagination, and I've come to put a stop to it." Which is just the perfect comment on the modern education system.
Models trained on the lack of diversity will push one way, but I think it will also avenues for expression that didnb't exist before. The balance will come from how we react and support what we would like to have happen
I think it has more to do with LLM's being statistical models than human creativity lacking in the input. The creativity and millions of voices and tones may be there, but since these models tend to go for the most likely next words, polishing this away becomes a feature.
A text by a human mind may be seen as a jagged crystal with rough edges and character. Maybe not perfectly written but it's special.
An LLM takes a million of crystals and trims the most likely tokens to be chosen into what would rather appear as a smooth pebble; the common core of all crystals. And everyone using the LLM will get very similar pebbles because to the LLM, regardless who is speaking to it, it will provide the same most likely next tokens. It's not that creativity is lacking in the input, but the LLM picks the most commonly chosen words by all humans in given contexts.
For that to sound imaginative and great as you go, it would have to not only exist in the data, but be a common dominating voice among humans. But if it was, it wouldn't be seen as creative because it would be the new normal.
So I'm not sure how there's a good way out of this. You could push LLM temperature high so that it becomes more "creative" by picking less popular tokens as it writes, but this instead tend to make it unpredictable and picking words it shouldn't have. I mean, we are still dealing with statistical models here rather than brains and it's a rough tool for that job.
>I think it has more to do with LLM's being statistical models than human creativity lacking in the input. The creativity and millions of voices and tones may be there, but since these models tend to go for the most likely next words, polishing this away becomes a feature.
I have always thought this is a rather misguided view as to what LLMs do and indeed what statistical models are. When people describe something as 'just statistics' I feel like they have a rather high-school-ish view of what statistics represents and are transferring this simplistic view to what is going on inside a LLM. Notably they do not find the most probable next word. They find the probability of every word that could come next. That is a far richer signal than most imagine.
And ultimately it's like saying that human brains are just chemical bonds changing and sometimes triggering electrical pulses that causes some more chemicals to change. Complex arrangements of simple mechanisms can produce human thought. Pointing at any simple internal mechanism of an entity without taking into account the structural complexity would force you to assume that both AI and Humans are incapable of creativity.
Transformers are essentially multi-layer perceptron with a mechanism attached to transfer information to where it is needed.
> They find the probability of every word that could come next.
If we're being pedantic, they find a* probability for every token (which are sometimes words) that could come next.
What actually ends up being chosen depends on what the rest of the system does, but generally it will just choose the most probable token before continuing.
* Saying the probability would be giving a bit too much credit. And really calling it a probability at all when most systems would be choosing the same word every time is a bit of a misnomer as well. During inference the number generally is priority, not probability.
> I have seen people suggest that the problem is that LLMs let you express any of your ideas, but the number of people with ideas worth expressing is limited.
It doesn't just have to be one problem.
1. Laundering your "ideas" through an LLM makes them less of your ideas, at best you get the classic two sentences of content embedded in two pages of padding.
2. LLMs removed a filter that help cut down on the amount of useless writing we'd have to wade through. The difficulty of expressing an idea acts as a filter to weed out many (but not all) ideas not worth expressing. That applies to both to people with ideas worth expressing and those without.
On the former, I've had the experience of having an idea, then witnessing it fall apart as I try to express it, as I think about it more deeply. LLMs let you avoid that.
> I often hear this here: "if you don't bother writing, why should I bother reading?"
That is an opinion somebody shared on X which has been mindlessly repeated over and over again in other places such as this site.
Why do you value those comments when all they are doing is parroting something they didn’t think themselves? It seems to undermine your point entirely. There is zero originality or effort in those comments. Why are you bothering to read them?
Copying and pasting somebody else’s opinion from one social media site to another is no more virtuous than what you are complaining about.
I value that opinion because it resonates with me. When I use an LLM to write an article, it's usually because I don't have the time or energy to go through my normal process of writing.
Sure, I still end up with a polished article, but a lot of it is not entirely my idea or something I would have written through the filter of my own experience. So in order to share my true take on a subject, I have to go through the struggle of writing and bouncing of ideas in my head, which almost always results in a better output.
"Sharing the prompt" is a category error. It assumes the value of a piece is in the instructions given to the model, rather than the proprietary input or the iterative editing that follows. There is a hard line between using an LLM to generate content from a void and using it to synthesize specific ideas.
If someone asks a model to "write a post about X," they are outsourcing the thinking, which results in the homogenized voice everyone is tired of.
As someone working for a telco, not Vodafone, this would be my assumptions: A developer mistakenly grabbed a real MSISDN, instead of a QA one, while testing a promo still in development.
I only say this because there's no identifier to differenciate a real phone number from a test one. Subscribers often called to report those gibberish text messages they received. It's always a dev entering an incorrect number while testing.
When I worked for an Australian telco (not Vodafone), some developers on another team had used a very conspicuous mobile phone number in their integration tests, which actually connected to a real SMS service somewhere else in the company. No idea why they would do this. It turned out that this number belonged to a real person, who got absolutely buried in test SMS messages, when the integration tests ran as part of a CI/CD pipeline. The owner raised a complaint to the ombudsman, which led to all kinds of trouble for the developers.
I worked for an Australian insurance company and we physically DDOSed a poor man's real mailbox with printed policy documents as we used their address during e2e testing and we mistakenly didn't put a testing flag somewhere.
I lost a Nationwide Building Society account I've had for forty years last year because the bank bought some extremely poor online-ID-verification system.
The bank forgot it had customers in a Crown Dependency. It forgot those countries issues their own ID, their own passports, their own drivers' licences. It forgot it closed its branches in those countries: it told me I had to go into my branch. My nearest branch is a £200 airfare away. It was not paying, naturally.
The crappy online-verification tool only recognises UK documents. It can't handle Isle of Man ones. They did not think.
The documents pack is like an A4 folder 1cm thick. He received close to 100 in one day. Enough for his mailbox to get full and for the postie to dump most of it on the lawn
In the 1970s, a German rock group had a one-hit wonder with a protest song against Munich's sex trade licensing (Skandal im Sperrbezirk). In the lyrics, they had a made-up (so they thought) phone number 32-16-8 that fit the meter of their lyrics in German.
Unfortunately, that was a real phone number in many cities, you could dial the short/local number directly without a 0 and the area code back then. Cue prank calls across the country and quite a few scandals since the topic of the song was, after all, the sex trade.
I worked at a grocery retailer, and we had the same exact thing. The CI/CD pipeline was firing out order related SMS messages to a contractor's number during test runs for years.
Someone I know who works at a telco (no idea if Vodafone is a thing in Belgium, but whatever: not Vodafone) was talking about a number someone has: 0411 11 11 11, and they got over a hundred operator messages every day.
I was slightly more inclined to think it might be some bored employee somewhere acting in a sort of Robin Hood capacity just because it's unusually accurate and thorough for a test message. I'd expect more like TEST TEST test DFOIUHDFUOHDFOIUHDFROIHDSFOIHDSF LOREM IPSUM 999999.
Sometimes enthusiastic or particularly bored developers do put in the effort to write things out like a real message though.
In my first job we had warehouse management system, and for testing new versions we allowed users to log-in to test environment.
Some employees didn't knew they were supposed to only log in to prod and happily worked in their warehouse accepting deliveries, stocktaking, moving stuff in real world using test db instead of the prod one. We only realized when they moved so much stuff that the inconsistencies db vs reality triggered alarms.
There was a tool shared here that could show which accounts belong to the same person based on the writing patterns. Can't remember the name, but it found my old accounts on HN pretty accurately.
I used to take Uber to work daily in 2016. It cost around 3 - 4 dollars per 5 miles ride. Now the same ride cost $24 [0]. There's no indication that AI coding tools won't follow the same path given they are funded by VC.
But I think what matters is that the new generation of coders will adopt it as the norm. Gone are the days where you download a free text editor and just trial and error with the documentation one tab away. Every bootcamp is teaching react with clause and cursor. You have to pay to for a subscription to build your BMI calculator.
I'm happy to see that in a sea of commenters who'd hate for anyone to strike a conversation with them, there are people who still enjoy connecting with others.
We are in a public forum afterall and we are all strangers here. I'm always happy when random person sends me an email.
One thing to take into account, this will now be a large source of revenue for them. You thought you would get away with the free tier, but now as a tax payer, we are all funding it.
Lovable is marketed to non developers, so their core users wouldn't understand a security flow if it flashed red. A lot of my non dev friends were posting their cool new apps they built on LinkedIn last year [0]. Several were made on lovable. It's not on their users to understand these flaws
The apps all look the same with a different color palette, and makes for an engaging AI post on LinkedIn. Now they are mostly abandoned, waiting for the subscription to expire... and their personal data to get exposed I guess
Developers with decades of experience still make basic security holes. The general public are screwed once they start hosting their own apps and serving on the Internet.
There's something so innocent about the early days when even Microsoft thought we'd be running Personal Web Servers and hosting our own websites in a peer-to-peer fashion.
Although cynically, in 1996 Microsoft would probably tell you anything you wanted to hear if it got you using Internet Explorer.
The Personal Web Server is ideal for intranets, homes, schools, small business workgroups and anyone who wants to set up a personal Web server.
I always held the belief that we (as programmers and industry) failed the initial premise of the "distributed internet". On one hand, the core of the internet (whether its arpanet or even tcp/ip) was designed to be fully distributed, trustless, selfhostable, etc. The idea that you if you want an email you do a `pkg_add email`, want a file server, `pkg_add file-server`, want remote access, `pkg_add openssh` and you're done. But what we have today is [1].
Securing all that got very technical and nuanced with hundreds of complex scenarios and tools and protocols. Tech companies raced to produce services the mass public can use, hiring hordes of very smart, expensive and technical developers to develop and secure, and they still get it wrong frequently. While the FOSS community adopted the "get good or gtfo" approach as in [1].
The average person has no chance. That's why closed wall-gardened platforms like iOS and Android are winning.
Author here. I posted this on Sunday for a light read, but I guess it got traction today.
Based on the comments I see here, I think the focus is going on the turnstiles just as it did when I worked there. While the cookie credentials are pushed aside. I think that's the security theater. We are worried about supposed active shooters, different physical threats while a backdoor to the company is left wide open. The turnstiles are not useless, they give an active record of who is in the building, and stop unauthorized people. But they also give so much comfort that we neglect the other types of threats.
> Based on the comments I see here, I think the focus is going on the turnstiles just as it did when I worked there.
You titled the piece after the turnstiles and spent the overwhelming majority of the post talking about them (and surrounding physical features). The Jira ticket felt secondary, and when it was introduced in the middle of the post I was genuinely confused, thinking why the heck the card system was contacting Jira.
People reading your writing are going to focus on whatever you did when you wrote it. The turnstiles read like the important part.
The part about Jira is important because it highlights that while the company claims to take security seriously, they in fact do not take it seriously.
The incompetence of the turnstiles makes it a good focus for the story while the juxtaposition of the turnstiles with Jira exposes the company's hypocrisy.
What's the threat model for cookie theft? That if someone gets access to your company hard drive, but not enough access to install a keylogger, then instead of invalidating a session you also have to invalidate the password too?
It's an issue but I wouldn't call it a particularly big issue. I don't think it's very damning for how much the company cares about security.
And it sounds like the turnstiles did work for actual security? Sure, they gave up on per-floor security, but that's a lot less important.
Edit: And if employees are reusing passwords then we should be getting them password managers (or SSO) as the top priority, much more than we worry about logins in cookies inside the building. I mean, there's a point where a single purpose password and a login token become the same thing.
A threat model is you can steal the creds of any high clearance officer in the organization. If they reuse the password on the network, you now have unfettered access.
SSO is much more common these days, but that it wasn't the case back then.
A third party script that's embedded into the task management website? Otherwise I don't see how it's going to get to the cookie. And if it is embedded into the website, it can force a fresh login and steal the cookie that way.
And you can set HttpOnly to stop javascript from being able to access the cookie... but that still won't stop the attack of making them log in again.
1. Initial access to physical machine, most likely via phishing malware, reckless employees downloading untrusted content, or bad luck.
2. Malware looks for browser cookies, hoping to steal temporary credentials but instead gains persistent creds, which grant Jira access. People re-use passwords; malware tries this password against AdUser and any other systems or other corp user accounts it can find
3. Direct Jira access used to pivot, that custom Jira app is probed for app vulns (likely given design).
So with a better system the malware has to wait an extra couple hours to get the password (by dropping the non-password authentication cookie and making the user log in again), and it can still prod Jira in the meantime. That doesn't strike me as a very big difference. It's an improvement in security but not a big one.
I care a lot more about my life (or my car's catalytic converter, which was stolen off my car in my work parking lot before they inatalled a gate for the lot) than any of my work-related IT credentials. Health and safety threats are a much bigger deal to people than nebulous, difficult to exploit threats to IP.
Except the turnstiles and swipe cards do almost nothing against an active shooter situation.
But missing in this discussion is a risk and consequence analysis. If the risk is armed attackers, do something that targets that. For physical theft, target that. Likewise IT risks. The core problem is that risks were not being identified (systematically or in response to expert feedback) and prioritised.
Incidentally, the solution to car park access is ALPRs, and the solution to most of the physical security is solid core doors at the workgroup level with EACS swipe and surveillance cameras there, and at the front desk have face level 4k video surveillance. With an on duty guard to resolve issues with access.
It seems much more a compliance and auditing goal. To meet some objective of knowing who is in the office at what time, which informs office space leasing decisions, return to office mandates, decisions of charging for staff parking, etc. Personnel protection seems almost an afterthought.
Protecting JIRA auth tokens is quite likely low down the list for IT security. Making sure your workers are not remote North Koreans is indeed a security benefit of secured physical offices with regular on-site work.
But the author did have a deeper point -- visible security theatre gets lots of money and management attention, while meaningful expert driven changes are mired in bureaucracy.
I still challenge whether his proposal was actually "meaningful, expert driven changes" - is this actually a serious threat vector? How would you actually exploit it, without having access to dozens of other vectors? Can you even meaningfully resolve that vulnerability when you have people walking in off the streets due to a lack of physical security?
I don't think you could take over the company with a jira token. Another factor for consideration with turnstiles is disability access and fire egress. Those are covered by building code but since this is a parable, it's worth noting that physical security has often caused tragic stampedes that have killed many.
You are right, it's much harder to compromise a system with the jira token, which is why it was the solution for the username/password stored as cookies. Plus the token was never exposed to the client.
Perhaps part of the problem is that an active shooter is easy to visualize and understand whereas unsecured credentials stored in cookies are an abstract and difficult to visualize problem for management.
Furthermore, turnstiles are easy to promote and take credit for. Secure web authentication would have to be explained to and understood by the boss's boss before credit for it could be claimed.
I suspect it's these aspects of organizational reality that results in security theater.
I think it has less to do with ease of visualization and more to do with priority of consequences.
Do a poll of whether people would prefer that a mass shooting or a mass data breach occur at their place of work while they are there. I bet I know which one wins.
[0]: https://idiallo.com/blog/surviving-the-hug-of-death
reply