Google has introduced FLoC:
Federated Learning of Cohorts (FLoC) proposes a new way for businesses to reach people with relevant content and ads by clustering large groups of people with similar interests. This approach effectively hides individuals “in the crowd” and uses on-device processing to keep a person’s web history private on the browser.
This has been released to customers right now, according to this website:
Google has launched trials of FLoC in Chrome browser version 89 on March 30th, 2021 in the USA, Canada, Australia, Brazil, Japan and several other countries for millions of users. FLoC is a part of the Chrome browser’s source code and it helps them do cookie-less and consent-less ad targeting.
From reading about FLoC it's clear it's part of the Google Chrome browser, but I can't figure out if it's also part of Chromium, the underlying open-source browser project?
This isn't to start a FLoC war or discuss the pros and cons of the technology, I just want to understand where exactly it fits into the technology stack to understand when and where I might encounter it.
You can find FLoC code in Chromium here: source.chromium.org/search?q=floc
To try FLoC in Chromium, download Chromium... chromium.org/getting-involved/download-chromium
...then run it with flags as per the instructions at floc.glitch.me.
I was thinking also about this and didn't found something straight ahead.
Here is a potential answer for this question:
http://dev.chromium.org/Home/chromium-privacy/privacy-sandbox/floc
Related
My company writes software that installs on client machines to perform point-of-sale transactions. The software interfaces with a variety of external peripherals (receipt printers, bar code scanners, credit-card readers, etc). We do this with a WinForms app that we created in Visual Studio using the Microsoft OPOS library, which in turn communicates with our cloud server.
There are obvious inefficiencies in this model, primarily with updates. I'm researching other ways to communicate with these peripherals over the web, preferably via web browser. So far as I can tell, Java is one of the only technologies out there that can do what we're looking for (via applet), and I assume Adobe Flash can as well (via the Air platform). These are viable, but not preferable because we want to run our software on web-enabled mobile devices.
Does anybody have suggestions for other ways to communicate with external peripherals over the web?
UPDATE (Jan 16th, 2019): The Credential Management API has been announced. It's currently only supported on Chrome and Opera but it's looking promising. Google Developers wrote an article elaborating on the spec.
UPDATE (Dec 28th, 2016): Another couple years gone, and another update. This one will be more focused on two new developments than anything else. See the new "WebUSB & Web BlueTooth" section under "Full Device API". But the answer remains the same.
UPDATE (Nov 3rd, 2014): It's been just over two years since the original post was made, but the answer remains mostly the same for now. We are, however, closer to your original goal in several areas.
ORIGINAL ANSWER:
There would be a number of ways to go about this.
Background
The HTML5 specification has entered into the "Recommendation" state. This means that HTML5 is pretty much set for what it looks like. However, I will be using HTML5 in the same way that every marketing person in the world has decided is best. That is, I will not be talking about HTML. Well, I will, in so far as you will utilize it from an HTML page, but not really. What I'll actually be discussing is JavaScript (JS) and that's a horse of a different color. But for all intents and purposes, we're putting it all under the same heading as HTML5, which has been decided to mean "shiny and new" now.
Also, the items which I am discussing will vary in support. Some are very browser dependent projects (like Chromium specific implementations), and some are more standards driven projects that may not have browsers implementing or experimenting with them yet. I'll try to distinguish between the two as I go along.
Full Device API
Status: Incoming, but not ready
Being able to access devices from the browser is making slow but steady progress. Right now, many modern browsers have access to some of the more common devices like the camera or gamepads, but they are all high level APIs. Browser vendors, the standards groups, and lots of companies involved with the web are all trying to make webapps just as powerful as your local applications.
But the APIs you are looking for are still in progress and a ways off. For your particular case, and for the more general case of connecting your webapp to most devices, we're still a few years away from something we can use. If you want to see what awesome things are coming up in that field, here are just a select few items that may help you directly:
Web Near Field Communication (NFC) API
This one unfortunately may be dead in the water for now. But it looks like originally some folks at the W3C (mostly Intel it looks like) were looking at adding a NFC API to the web.
Media Capture Streams
The WebRTC group is working on programmatic access to media streams like the camera which would allow to integrate things like barcode scanning or other features. This has reached CR status and is available in browsers, but is less helpful on its own.
Web Bluetooth
If you had bluetooth capable tools, this API would help you connect with them from computers and devices that were able to listen and connect. The primary driver for this at the moment seems like it is the Chrome team, including an experimental implementation, but I wouldn't consider it anywhere ready to use yet (See "WebUSB & Web BlueTooth" section).
WebUSB
This would allow full access to low level USB information including listing devices and interacting with them. Same as Web BlueTooth, this seems to be current Chrome pet project, but I also wouldn't rely on it (See "WebUSB & Web BlueTooth" section).
Network Service Discovery
If you have other devices or items on the network which broadcast and use HTTP, this API would allow you to discover and interact with these services. No browser implementation, but it is in a working draft for the W3C.
Originally, Mozilla was pushing a number of these forward because of Boot2Gecko (or Firefox OS). However, with that project officially cancelled, we aren't seeing much progress from them in these areas now.
Members of the Chrome team, however, seem to have decided to dive in and start not only working towards these, but putting them live in browsers. Which leads us to...
WebUSB & Web BlueTooth
Like sausages, it's better to not know how Web Standards are made
-Abraham Lincoln (probably)
There's been a little bit of buzz in this area as it looks like the Chrome team snuck in these as experimental features and developed their own specification for it. Which is great! Just maybe not in the way that you were hoping for.
Each browser vendor and W3C contributor group has their own style and makes contributions towards the specs in their own way. The result is usually a fairly decent specification that the browsers have agreed upon. But getting from nothing to something is... messy. Real messy. And is quite a process a lot of times. It doesn't always result in a good spec (yeah, I'm talking about you Florian compromise...) but even when it does, it takes a while.
However, It seems like Google developed this version of the spec all on their own. And, in my experience, Google's approach to the specs is always a little... well... setting my personal opinions aside we'll say "gung-ho". They tend to just dive right into the deep end. And that seems to be what they've done here.
I highly doubt these specs or implementations will look anything like this when they become standards. And there's nothing wrong with that. That's part of the process. But I wouldn't go relying on this implementation or developing any code or products against it. This is an unprecedented feature on the web and all the browser vendors are gonna want a big say in this.
That said, this is actually good. One of the things Google often does (for better or worse) with situations like this is forces the conversation and it can push things along. And having a feature shipped in the browser, even an experimental feature, can turn up the heat on the demand for it. So we may see more progress in this area soon.
PhoneGap Apache Cordova. You know, for your phone
Status: Not fully featured and phone only
Apache Cordova, previously Adobe PhoneGap, is a way to write your program in HTML, CSS, and JS that allows you to access lower level functionality on things like phones, and compile across devices. This would be a way to implement your program, but it would be a phone application, not necessarily a desktop one. An option to consider, and something I figured I would mention.
Cordova implements a few of the above features already, but doesn't have some of the more powerful ones like NFC or BlueTooth.
The Native-App solution (for Windows 8)
Status: Possible, but OS specific and desktop app
Windows 8 offers the ability to build applications in HTML and JS. This would allow you to easily access lower level functionality on the OS via their API. From the looks of it, it is pretty extensive and you can do a lot. You mentioned cross OS support, however, and this obviously limits you to one OS.
It's so Flash-y!
Status: Dying/Dead, not possible as a web app
Flash won't have direct access to the system through the web. You could create an AIR application, but that will sort of defeat the purpose of having it web based. In addition, Flash support on mobile, and on the web it would seem, is on the decline.
NodeJS
Status: Can be a bit of a pain and only possible as a desktop app
NodeJS and JS applications have sort of been a hot topic the last couple years. I didn't discuss it in my original post because I felt it wasn't quite there yet. However, things have progressed and it is much closer to being ready for this sort of thing, and has the support and power of a growing user base. That said, for your particular case, I wouldn't recommend using it. It would have to be local on the users machine, and because of how NodeJS (and similar engines) are at the moment, it would require a lot of extra configuration and setup that would complicate things a bit.
So you could build an app using HTML, CSS and JS with NodeJS or similar engines and have low level access to what you need, but it has to be local, and it would take more work than I'm sure you want to do every time you'd like to install it for a customer.
... Now where was I?
So where does that leave us? Well, simple: if you want a single language/set of code as your code base, HTML/CSS/JS aren't a great option... yet. But they could be some day. For now, your options are limited to what you feel is best for your customer. Java is a stable option you listed, but obviously comes with its own drawbacks. As the web develops, I think we'll see a lot of really cool things coming out of the new functionality, but we've got a ways to go still.
More reading:
Brian.IO: Beyond HTML5
HTML5 Apps on Windows 8
Wikipedia list of projects built using JS
This is possible, but it would have to be done indirectly. In theory, you could write a socket-server in a low level language, which gets I/O, and sends the I/O through the socket (relaying, I guess). HTML5 uses WebSockets, or some equivalent to communicate with this socket-server.
Now it can be achieved with WebUSB API.
It is available in Chrome since version 54.
It is a W3C editor's draft so we can expect (hope) that it will be adopted by other browser vendors...
I've been thinking about this a lot lately... have a POS app mostly written in VB6, considering what to do next. HTML5 is an option and I was thinking I'd use VSPE to get the serial stuff into the JS.
http://www.eterlogic.com/Products.VSPE.html
Love this product! Works very well for getting serial traffic where you need it, so I think it would work well, at least as a proof-of-concept to get you going. You'll want to use a combination of "connector" types along with the "tcpclient" and "tcpserver".
Just for the record, a method that works well in 2016 (since chrome 26), but is to be withdrawn over the next 2 years is to deploy your html5 as a chrome app and use chrome.usb (or chrome.serial or chrome.bluetooth).
I am currently using chrome.usb and planning to migrate to a web app using WebUSB API (see Supersharp's answer), which I hope will be adopted by the time Google discontinue chrome apps 🤞.
I'm doing a mobile WebApp using HTML5. My problem is that the "post-login" pages cached by the HTML5 application cache, from what i understand, remain still unsafe. Is there a solution? What is the best way to ensure an offline authentication hiding user/pass and "post-login" pages from intruders?
I am just starting to delve into HTML5 usage of local storage via the Manifest option (http://diveintohtml5.info/offline.html) and this too is a concern for me as much for privacy as security. Two things came to mind: Ezncrypt and the Editor's Draft on Web Storage (Privacy and Security), links to both below...
While I do not know if this will be the 'best' answer, figured anything would be better than nothing and after all you posted this question back on Feb 2, 2012 and no one else has offered anything.
Caveats (ezNcrypt):
It works on Linux
Its a Commercial product with a 30 day trial, honestly do not know the cost as I am not affiliated with them, just heard of what they do via a local meetup, LAPHP, LAMySQL or LAWebspeed last year, and it sounded interesting enough to note for future reference. Transparent encryption will be huge.
Google Ezncrypt products to get a link, I am limited to two here.
Even if its not the 'right' solution for you or others, perhaps it will point you in a good direction with some decent search terms to find more.
If the encryption is handled "transparently" below the application / data layers, it will just work regardless of the IT knowledge of the user.
If you are willing to share some contact information with them, you get this PDF file with 4 case studies, FTP, NoSQL, SQL and something else... its free.
http://blog.gazzang.com/white-paper-unifying-data-encryption-liberating-transparent-encryption-for-any-purpose-/?utm_campaign=Whitepaper&utm_source=Whitepaper
I should get a commission, lol. Hey if it helps us find a solution, that is all that matters.
Whatever your decision make sure you go through the Editor's Draft, Privacy and Security to dot your i's and cross your T's, especially sections 6 Privacy and 7 Security.
http://dev.w3.org/html5/webstorage/#the-localstorage-attribute
Just thought of another, I did not look except to provide a URL to their checklists (cheat sheets) , but my guess is OWASP would have one or two checklists that might lead you to something. Just think of your device as a little desktop/server and see if any of those apply. To bad my Nokia N800 broke on me, a full blown Linux computer in my hand circa 2006 and the new Linux handhelds circa 2012 are so much more powerful. Just use a Linux distro with a small footprint on a device with exchangeable storage (Micro SSD Cards would work...the Nokia N800 had two slots in 2006) and there is no limit to what you could store locally and run offline. Here is the URL to the OWASP checklists:
Sorry limited to two links, google OWASP cheet sheets and you will find them.
If a handheld is truly 'smart' you will have root (administrator) access to the device and underlying operating system / file system. Every operating system has methods to encrypt data on the fly, but you have to have access to utilize them. A device that does not give you this access (usually for proprietary reasons, most often to force you to buy a new device in 6 mos to 1 year) is limiting your options artificially for the wrong reasons and is simply not smart. Remember that all versions of Android (Linux) are not open and rootable, so do your homework or you will end up with an expensive paper weight in the near future.
I would recommend only buying smart handhelds that allow for root/admin access.
Does anyone know how I can purchase the above SDKs? Calling the standard Sony / Microsoft Sales numbers does not seem to get me anyone who knows what I'm talking about.
Firstup the SDKs are free, though not publicly available. If you're really keen you can probably find them floating around on torrent sites. They're interesting but of little use without any actual hardware..
So I suspect your real question is "how can I buy development hardware?"
Devkits are only available to approved developers and publishers, and cost substantially more than the consumer hardware. A simple test station (runs unsigned code) can cost several thousand, a full devkit is in the region of $10k. (they used to be around $20k but things are 'cheaper' now).
To have any chance of purchasing you need to become a registered developer, which ranges from "hard" to "impossible" based on your company, your track record, & your publisher/financial backing. If you're a new developer without either a publisher or an extremely good demo your chances are effectively nil I'm afraid.
One alternative is to look at something like XNA studio which allows you to develop on the consumer Xbox hardware, and possibly sell your game via Xbox Live later. This is one way you could create a demo to try and attract interest, though you may later have to port from C# to C/C++ if it's to become a 'proper' Xbox or Xbox Live Arcade title.
If you're interested here are the links;
http://www.scedev.net/common_licensing_info.php
http://www.xbox.com/en-US/dev/regdev.htm
http://creators.xna.com
You cant just purchase them. First you have to register with either company, and then once approved, you have to fork over $20K+ in order to buy the unit. For MS, I would try one of their XNA sites
After delving into the world of opensource I have found implementation is emphasised over design. Version control allows for a project to branch off in many directions, which projects may do; this suggests lack of consensus or direction amongst the participants.
What software or websites are useful for collaborative design?
There are literally hundreds more collaboration apps out there and more keep appearing by the day, but these should get you started:
Source Control (Online):
Assembla - Public source is
free, private repositories are paid
Source Forge - Open source only
Google Code - Open source only
Git Hub - Public source is free,
private repositories are paid
Bug Tracking/Project Management
LightHouse - Unlimited open source, paid private projects
FogBugz - Full version is free for up to two developers
BaseCamp - Paid only
Trac - Not hosted (although Assembla hosts it), open source - Python
Bugzilla - Not hosted, open source - Python
Mantis - Not hosted, open source - PHP
Mind Mapping
MindMeister - Free for small
plans, with options to upgrade
Documents
Google Docs - Free
Buzzword - By Adobe - free
Scribd - Free
Graphics
Aviary - I'm not quite sure how
collaborative they are, but I think
you can use their tools that way
Photoshop Express - Another
Adobe product
Picnik - Free
Whiteboards
Scriblink - Free with paid
options
skrbl - Free for public, paid
for private
Dabbleboard - Free and paid
plans
Hosted Wikis
pbwiki - Paid plans
Wikidot - Free with paid plans
Miscellaneous
Acrobat - Part of Adobe's
online suite
Zoho - Fits into a lot of
categories
I've been studying collaborative design early in my Ph.D. (contact me if you want a literature survey draft that I wrote about it a back in 2003).
Anyway, collaborative design applications (as in UML modelers) fall into three categories in terms of timing:
Synchronous - Two people or more editing at same time
Asynchronous - Check-in check-out model, a mess if multiple people edit at the same time.
Hybrid (can share certain things in real time).
In addition, they fall into three categories in terms of metaphores:
- Desktop based - Essentially something like rationale rose with multiple user support
- Whiteboard based - Free canvas, not necessarily structured, sometimes has support for UML recognition. Usually a mess to manage multiple models.
- Hybrids
So this gives you a 3x3 "design space" of tools, and there are research tools inside every one of them.
The problem is that in switching to collaborative work there are many usability issues that are difficult to address. For example, access control, synchronization, awareness, shared viewports, etc. There are some academic advances on these, but they're not necessarily in tools yet.
If this is the topic you're interested in, comment, and I'll post some of the tools I'm familiar with.
I would suggest using a Wiki to document/explore the design.
A mailing list. And opensource projects argue on enough of them. I doubt lack of collaborative tools is where the lack of design emphasis comes from.
In no particular order:
A good email client (I use gmail)
Good wiki software (I use media wiki)
Github or an evolved source repository that allows for easy branching and comments on check ins
A chat room, plain old irc or that built in messenger one
A news group or mailing list (I use the free google one)
Skype
I am somewhat skeptical about collaborative design. From Scobleizer: Why Facebook has never listened and why it definitely won’t start now:
My former boss, Jim Fawcette, used to
say that if you asked a group of
Porsche owners what they wanted they’d
tell you things like “smoother ride,
more trunk space, more leg room, etc.”
He’d then say “well, they just
designed a Volvo.”
also from the comment:
Apple never listens to its customers.
In fact, it prides itself on not
listening. If you listen to your
customers, you will never innovate and
you will never be ahead of the curve.
You will always tweak and fix minor
things on what is top of customer mind
that day, week or month.
I agree with the wiki answer. I'd suggest looking at MindTouch. Our company uses them for our Intranet and for other internal and external project collaboration/management.
A wiki (such as ScrewTurn, or MediaWiki) is a good tool to document a project.
BaseCamp by 37 Signals
Microsoft Office Live Meeting
For us, all we use is Adobe Version Cue, Google Docs, Google Calendar and Gmail.
Design wise, Version Cue does the trick in terms of file management really well.
As for Google, well, it helps organizing all of my activities more than very well. I find most collaboration tools, like Basecamp, a tad too restrictive or just not exactly right. Google lets me organize my stuff just the way I want it to be.
For collaborative design ... without a doubt, it's
http://conceptshare.com
I friend asked me this today.
Picasa Web has a cool (and frightening :-) feature where it will recognize all the faces in your photo album.
But the PC (desktop) version doesn't have this.
Several reasons I can think of:
They just haven't gotten around to writing the PC version of the code.
They are licensing that feature and it costs a lot more (or isn't available) on the PC.
Takes a lot of processing power (this seems odd b/c MY PC cycles are free to Google, but they have to pay for for cycles consumed on their server.
Any other thoughts?
I'm certain it'll make it out in coming releases but Google is a funny company when it comes to its own competing/complementing services. One thing is for sure, only somebody on the Picasa team could give an accurate answer.
But we could hypothesise several things...
They don't want their code reverse-engineered.
(As you say), they aren't licensed to redist
It's blocked in the dev version by other new features that aren't complete yet
They don't want to release it because they want people to use PicasaWeb as a social photo network.
I don't think processing power is an issue. If they're running it in bulk on their own servers for free, a modern desktop could probably run it without issue.
From my limited contact with face recognition software, it's probably the redistribution issue. When I dealt with it, face recognition was its own little world with extremely high per-CPU licensing costs and tremendous paranoia about code getting loose.
I'm not so sure it's not a processing issue. It took Google's massive servers 30 minutes to run through all my photos. I can only imagine that same task would have taken days on my local machine.
Actually, its in, just in limited functionality when you do a search, there's an icon to find only photos with faces. The experimental passport feature also works that way.
So the answer is:
Not the same base (APIs) available or used and not the same language so its not directly portable.
Not the same software and there are no stated goals to make both apps feature equivalent.
Programmers are limited and their time is too. They make choices as to what implement now.
No idea if this is the case for Picasa, but there's another case where licensing could be the issue. If the server-side code is using code with a restrictive license with DRM (GPL, for example) which restricts how you can distribute modules using the code. Running that module on a web server, where the user only gets the output, is legal under such licenses. If that code was distributed, there would be many legal requirements attached which would likely be very undesirable for commercial software companies, including google. This is one very good reason to have some capabilities only accessible through web services.
This was also the case with Riya (who was arguably the first to market with reliable facial recognition for consumer photo collections).
The biggest reasons are likely:
Processing Time (they can't control
how fast your CPU is and therefore
they can't control the experience).
Facial recognition is very likely to
be process intensive (this was Riya's
stated reason for not doing it
client-side)
The recognition process requires a
LARGE volume of data for processing
that is only accessible on the
server? (In other words, the process needs to spin through millions of faces, not just the faces that you have on your hard drive?)