Follow

Hey Fediverse!

qcard.link/

Published another update to my FOSS project: QCard

Added more information about how it all works.

Please drop me any feedback!

--

Boosts Appreciated, I think this has a really cool use-case! 🚀

@arran I like the concept! So now, I should design a business card that I don't give away but simply show to others that they can quickly scan?

@Doudouosm @yarmo Even better, render the QR code the epaper card 😂

Thats a cool project

@yarmo Thanks! Exactly, I have a couple screenshots or the QR codes on my homrscreen for different purposes - Eg work and hobbies.

@arran How is this private? Don't the contact details get sent to the qcard server when somebody decodes the URL? Maybe they promise not to do anything with the data now but if this gets widely adopted it'd be a very tempting target for advertisers and TLAs.

They could put the data in a fragment identifier (after a #) so it doesn't go to the server then have the fragment decoded by JavaScript in the web page. The fact they don't makes me very suspicious.

@yarmo

@edavies @arran that's a valid point, curious to the answer. I probably wouldn't put my email in there anyway, just a link to my website.

@edavies @yarmo

Definitely open to suggestions to make this more private! Thanks for your concern.

So using a fragment identifier, it's guaranteed it won't be sent to the web server?

@edavies @yarmo

I did some research and I will make this change today.

Thanks for pointing it out, it's a big help

@arran @edavies @yarmo @Doudouosm > just another centralized webshit instead of encoding vcard into a qr code directly

@L29Ah Agreed for the simple use case. However, there's no reason an application can't ignore the web site and use the “qcard.link/?v=” prefix simply to identify the Q code as a base64-encoded vcard. I.e., treat it as a URI rather than a URL.

@arran @yarmo @Doudouosm

@arran @yarmo Excellent, thanks for that.

Not quite a guarantee but a strong pointer that the fragment should not be sent, RFC 3986 section 3.5 says: “…instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme.” The surrounding text gives useful context.

@edavies @yarmo

Updated, now we're using the Fragment Identifier!

@edavies @arran @yarmo

I'm confused why it needs to go to a server at all - couldn't all data be embedded in the code, e.g. like with qr-code-generator.com/solution ?

@raboof @edavies @yarmo

You're right, technically it could be - But I found when testing many QR apps don't recognise it, so I opted for a client side web approach for ubiquity.

It also doesn't force the recipient into saving the contact data on their phone, if they just wanted their email for example.

@L29Ah

@arran very nice idea to add the context.

my former company printed the vcard qrcode on the business card

@arran neat, just doan get the "private" part of it, AFAIR encoding doesnt make data more private

@vv01f Thanks. It's private in regards to it's all client side without a server collecting the any contact data.

Sign in to participate in the conversation
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.